I have a scope on the SPI signals there is nothing I can see that is a problem. The SPI hardware module is doing its job and clocking all the bits. It's recognizing the data ready, doing the SPI transfer, saving the data with time to spare. (99% of the time anyway)
To clarify, it's not overrunning a bit in the SPI word. The problem is that the data ready bit comes at a steady 3200Hz and sometimes it just doesn't get back in time for the next data transfer. As far as I can tell no fault of the code I'm running. The code is focused only on the tight loop that monitors the data ready bit and then uses the SPI to transfer the data. I assume there must be things going on in Linux like WiFi communications and Ethernet communications that interrupt my code. I'm using a somewhat older image. What image should I use to get started working with the PRU? Kirk On Wednesday, August 3, 2016 at 3:25:12 PM UTC-7, William Hermans wrote: > > *On thing I should clarify. The loop that is polling and grabbing the >> data keeps up with no problem.* >> *It is SPI. The problem is when Linux gets buys with something it just >> "goes away" for multiple milliseconds or more and data is lost* >> > > Very unlikely. First of all. The SPI is an actual hardware module. Second > of all, SPI in terms of simple peripherals is the fastest simple bus on any > system. > > The problem you're likely experience is in how Linux communicates with the > SPI module. Or, you're doing something silly like trying to print the > output to screen every read. In code. > > Anyway, if you use the PRUs, all those problems will go away. > > On Wed, Aug 3, 2016 at 11:04 AM, Kirk <[email protected] <javascript:>> > wrote: > >> It is SPI and it keeps up with data collection with no problem. The >> problem is when Linux gets busy with something else and interrupts the data >> collection. >> Going as fast as I can with SPI helps because sometimes the Linux >> "interrupts" are short and it has enough time. But when a multiple >> millisecond interruption happens the data is missed. >> >> Kirk >> >> >> >> On Tuesday, August 2, 2016 at 5:05:18 PM UTC-7, H wrote: >>> >>> Kirk, >>> >>> What bus are you using (SPI or I2C)? Both are "slow" buses which can >>> sleep on >>> you. In addition, are you using the FIFO? >>> >>> Scheduling your reads and using a fast enough SPI setting along with the >>> FIFO >>> should let you acquire at 3.2KHz w/o drops. >>> >>> On Tuesday, August 02, 2016 15:17:02 Kirk wrote: >>> > All, >>> > >>> > I'm working on a Beaglebone Black project using a MEMS accelerometer >>> chip, >>> > the ADXL312. >>> > >>> > The accelerometer has a pin which goes active each time a new data >>> sample >>> > is available to be read. >>> > It runs at 3200 Hz. (about 1/3 of a ms per sample) >>> > >>> > The pin is connected to a GPIO input and I've written code to monitor >>> this >>> > pin and grab the data each time. >>> > The sampling normally runs for several seconds continuously. >>> > >>> > The problem is, every once in a while Linux gets busy and apparently >>> > interrupts my code and I miss samples. >>> > (an overrun bit lets me know this is happening) >>> > >>> > >>> > I'm looking for ideas on how to improve this so data samples are not >>> missed. >>> > >>> > Any ideas? >>> > >>> > Kirk >>> >>> -- >>> Hunyue Yau >>> http://www.hy-research.com/ >>> >> -- >> For more options, visit http://beagleboard.org/discuss >> --- >> You received this message because you are subscribed to the Google Groups >> "BeagleBoard" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/beagleboard/418d0ced-9b81-4db5-bd88-a49a17b39f91%40googlegroups.com >> >> <https://groups.google.com/d/msgid/beagleboard/418d0ced-9b81-4db5-bd88-a49a17b39f91%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> >> For more options, visit https://groups.google.com/d/optout. >> > > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/31dc161e-3fba-4fbb-b62f-ee54d7ca84a8%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
