Re: [beagleboard] Recommended Image

Kennel, google PREEMPT RT if you want to know what rt *is*. You'll find plenty of information on the subject. In short though, the RT kernel is a lower latency kernel. Meaning processes should "hog" CPU time less. As far as the 4.x kernel in General, for the most part it is fine, but there are a f

Re: [beagleboard] Recommended Image

Err, Kenneth . . . not kennel . . . ^^ On Sat, Dec 26, 2015 at 1:13 PM, William Hermans wrote: > Kennel, google PREEMPT RT if you want to know what rt *is*. You'll find > plenty of information on the subject. In short though, the RT kernel is a > lower latency kernel. Meaning processes should "h

Re: [beagleboard] Recommended Image

Robert, do you have a link discussing pros/cons of which kernel to use; for example, what does "rt" give? Also, x-ti vs x? On 15-12-16 02:44 PM, Robert Nelson wrote: On Wed, Dec 16, 2015 at 1:08 PM, Kenneth Martin wrote: Robert, I haven't used dtb-rebuilder, does one need to recompile the Ker

Re: [beagleboard] Recommended Image

William, yes, indeed much of my code is based on some of the approaches of Abhiskek; he did a real nice job, and I borrowed some of his techniques with some changes (I only go up to a maximum of 50MS/s whereas Abhiskek goes up to 100MS/s and I don't use the new TI assembler or the Pru-C compile

Re: [beagleboard] Recommended Image

Kenneth, Have you looked into Beaglelogic ? https://github.com/abhishek-kakkar/BeagleLogic On Wed, Dec 16, 2015 at 4:13 PM, Kenneth Martin wrote: > John, I haven't heard of McSPI, but I'm running the SPI from a python > program on the Arm side based on some Pyside Qt controllers, I'm using the >

Re: [beagleboard] Recommended Image

> On Dec 16, 2015, at 3:13 PM, Kenneth Martin wrote: > > John, I haven't heard of McSPI, but I'm running the SPI from a python program > on the Arm side based on some Pyside Qt controllers, I'm using the PRU for a > logic analyzer and the logic analyzer pins are not available for the SPI, so

Re: [beagleboard] Recommended Image

John, I haven't heard of McSPI, but I'm running the SPI from a python program on the Arm side based on some Pyside Qt controllers, I'm using the PRU for a logic analyzer and the logic analyzer pins are not available for the SPI, so this could be the reason. I may also use the PRU IEP timer in t

Re: [beagleboard] Recommended Image

> On Dec 16, 2015, at 3:07 PM, William Hermans wrote: > > No need to bitbang unless you want additional SPI ports available. Simply use > the McSPI port controlled from the PRU. > > If the module is true hardware SPI, you do not even need a PRU involved. > Except perhaps to move the data into

Re: [beagleboard] Recommended Image

> > *No need to bitbang unless you want additional SPI ports available. Simply > use the McSPI port controlled from the PRU.* > If the module is true hardware SPI, you do not even need a PRU involved. Except perhaps to move the data into LInux through some form of shared memory. *That doesn’t mak

Re: [beagleboard] Recommended Image

> On Dec 16, 2015, at 2:38 PM, Robert Nelson wrote: > >>> >>> SPI works great on v4.1.x now, just pay attention this this little >>> spi-dma-disable hack: >>> >>> https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/BB-SPIDEV0-00A0.dts#L54 >>> >>> "ti,pio-mode;" >>> >>> Otherwi

Re: [beagleboard] Recommended Image

>> >> SPI works great on v4.1.x now, just pay attention this this little >> spi-dma-disable hack: >> >> https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/BB-SPIDEV0-00A0.dts#L54 >> >> "ti,pio-mode;" >> >> Otherwise, the spidev interface will lock up on the 160'th bit... >> >> (3.8

Re: [beagleboard] Recommended Image

> On Dec 16, 2015, at 7:24 AM, Robert Nelson wrote: > > On Wed, Dec 16, 2015 at 9:20 AM, William Hermans wrote: >>> I use uio_pruss; I am not at all familiar with remoteproc + rpmsg for the >>> pru (have never even seen any doc on it). I strongly prefer systemd to init. >>> My largest concern

Re: [beagleboard] Recommended Image

No need to bitbang unless you want additional SPI ports available. Simply use the McSPI port controlled from the PRU. Regards, John > On Dec 16, 2015, at 1:37 PM, William Hermans wrote: > > Normally SPI's are good up to 100MHz, but this is seldom needed. I normally > set them up at 1MHz fo

Re: [beagleboard] Recommended Image

> > *Normally SPI's are good up to 100MHz, but this is seldom needed. I > normally set them up at 1MHz for initial debug (allows for cheaper > instruments) and then usually go to 10MHz which normally makes speed a > non-issue and allows for longer wires. 16MHz should be fine as well. I2C's > often

Re: [beagleboard] Recommended Image

> Currently I'm fighting with WiFi; I had scripts to detect the wlanx device > using iw dev | grep "Interface" | awk '{printf $2}' but this is failing at > boot; it works fine after boot. I tried hard coding the wlanx device, but > now it seems to change; when I specify wlan0, it comes up as wlan1,

Re: [beagleboard] Recommended Image

On Wed, Dec 16, 2015 at 1:08 PM, Kenneth Martin wrote: > Robert, I haven't used dtb-rebuilder, does one need to recompile the Kernel > to use it? Also, in the main dts, it appears only spi0 is enabled, but I use > spi1 due to pin conflicts on the BBB cape headers; does dtb-rebuilder > support spi1

Re: [beagleboard] Recommended Image

Normally SPI's are good up to 100MHz, but this is seldom needed. I normally set them up at 1MHz for initial debug (allows for cheaper instruments) and then usually go to 10MHz which normally makes speed a non-issue and allows for longer wires. 16MHz should be fine as well. I2C's often run aroun

Re: [beagleboard] Recommended Image

Robert, I haven't used dtb-rebuilder, does one need to recompile the Kernel to use it? Also, in the main dts, it appears only spi0 is enabled, but I use spi1 due to pin conflicts on the BBB cape headers; does dtb-rebuilder support spi1? Currently I'm fighting with WiFi; I had scripts to detect

Re: [beagleboard] Recommended Image

> On Dec 16, 2015, at 10:13 AM, John Syne wrote: > > > >> On Dec 16, 2015, at 7:41 AM, Robert Nelson > > wrote: >> >> >> >> On Wed, Dec 16, 2015 at 9:31 AM, William Hermans > > wrote: >> SPI works great on v4.1.x now, just pay attent

Re: [beagleboard] Recommended Image

> On Dec 16, 2015, at 7:41 AM, Robert Nelson wrote: > > > > On Wed, Dec 16, 2015 at 9:31 AM, William Hermans > wrote: > SPI works great on v4.1.x now, just pay attention this this little > spi-dma-disable hack: > > https://github.com/beagleboard/bb.org-overlays/blo

Re: [beagleboard] Recommended Image

On Wed, Dec 16, 2015 at 9:45 AM, William Hermans wrote: > Hmm according to that device tree source, max frequency is 16Mhz. I thought > the SPI was capable of 30Mhz or more. Maybe I'm remembering wrongly. the old 3.8 tree also had 16Mhz.. https://github.com/beagleboard/linux/blob/3.8/firmware/ca

Re: [beagleboard] Recommended Image

Hmm according to that device tree source, max frequency is 16Mhz. I thought the SPI was capable of 30Mhz or more. Maybe I'm remembering wrongly. On Wed, Dec 16, 2015 at 8:41 AM, Robert Nelson wrote: > > > On Wed, Dec 16, 2015 at 9:31 AM, William Hermans > wrote: > >> *SPI works great on v4.1.x

Re: [beagleboard] Recommended Image

On Wed, Dec 16, 2015 at 9:31 AM, William Hermans wrote: > *SPI works great on v4.1.x now, just pay attention this this little* >> * spi-dma-disable hack:* >> >> * >> https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/BB-SPIDEV0-00A0.dts#L54 >>

Re: [beagleboard] Recommended Image

> > *SPI works great on v4.1.x now, just pay attention this this little* > * spi-dma-disable hack:* > > * > https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/BB-SPIDEV0-00A0.dts#L54 > * > >

Re: [beagleboard] Recommended Image

On Wed, Dec 16, 2015 at 9:20 AM, William Hermans wrote: >> I use uio_pruss; I am not at all familiar with remoteproc + rpmsg for the >> pru (have never even seen any doc on it). I strongly prefer systemd to init. >> My largest concern is the device trees overlays (for uio_pruss and pinmux); >> if

Re: [beagleboard] Recommended Image

> > *I use uio_pruss; I am not at all familiar with remoteproc + rpmsg for the > pru (have never even seen any doc on it). I strongly prefer systemd to > init. My largest concern is the device trees overlays (for uio_pruss and > pinmux); if they work, then I think I can get SPIs going. I just got a

Re: [beagleboard] Recommended Image

On Tue, Dec 15, 2015 at 9:10 PM, Kenneth Martin wrote: > I use uio_pruss; I am not at all familiar with remoteproc + rpmsg for the > pru (have never even seen any doc on it). I strongly prefer systemd to init. > My largest concern is the device trees overlays (for uio_pruss and pinmux); > if they

Re: [beagleboard] Recommended Image

I use uio_pruss; I am not at all familiar with remoteproc + rpmsg for the pru (have never even seen any doc on it). I strongly prefer systemd to init. My largest concern is the device trees overlays (for uio_pruss and pinmux); if they work, then I think I can get SPIs going. I just got a BBB ru

Re: [beagleboard] Recommended Image

What I personally use, and this is not for a production system per se is Wheezy 7.8. Once that image is installed, I then upgrade to a newer 4.1.x kernel, and that's where I've been happy lately. I do a lot of personal testing of various hardware modules, etc, and have found this setup mostly solid

Re: [beagleboard] Recommended Image

Both will work, however you have to answer this question for yourself. Would you prefer to use systemd, or init as an init daemon ? Debian 8.x is Jessie, and will have newer packages. 7.x is Wheezy, and will have older packages, but also has been "proven". On Tue, Dec 15, 2015 at 1:45 PM, Bit Push

[beagleboard] Recommended Image

I'm starting to update from an outdated image and to be clean am planning on starting from scratch with a newly flashed image. On http://beagleboard.org/latest-images there are two possible Debian images from Nov. 12'th, Wheezy 7.9 and Jessie 8.2. It is not clear which image I should use. I'm usi