> > *The PRU loop runs fine indefinitely using the analog log to display RMS > in the python code space. However, the PRU loop continues running after the > load is switched on or off but the PRU continues looping only > intermittently. * >
Outside looking in, this initially seems like a program flow error in your code. It would help to see the actual code, but a couple other things come to mind when thinking of your problem. #1 I seem to recall reading *somewhere* that the ADC can be configured to fill a buffer, and then stop taking samples until a related bit is "flipped". Not sure I'm remembering this correctly or if I am if it actually applies to this ADC module, or one on another embedded platform I've been toying with lately . . . #2 How is the beaglebone isolated from the electrical? On Wed, Mar 9, 2016 at 5:17 PM, <[email protected]> wrote: > > I am working on a project where I have made modifications to the > beaglebone_pru_adc package available on GitHub here: > https://github.com/pgmmpk/beaglebone_pru_adc > > The code loads in firmware as a *.bin file to run on the pru. It is > complied PRU assembly from a *.p file. > > My modifications were to implement a circular buffer in DDR based on the > oscilloscope_data() function in the module. This code grabs samples from > the adc like in the original code and stick the samples in DDR, but it also > updates memory pointers to wrap around. It loops indefinitely and respects > the cap_delay attribute. > > The board is connected to provide fine grain analog data logging via > current transformer and voltage transformer on demand courtesy of the PRU. > For instance enabling RMS waveform calculation. I have also written a > python class that drives a latching relay. For test purposes I hooked a > heavy ~10A load to the relay. The PRU loop runs fine indefinitely using the > analog log to display RMS in the python code space. However, the PRU loop > continues running after the load is switched on or off but the PRU > continues looping only intermittently. The load is resistive, yet clearly > the interruption is correlated with switching the load on or off. Sometimes > the PRU continues running and sometimes it stops running but only during a > switching event. > > I understand BeagleLogic.net may be a good lead to follow. In the > meantime, I watch for the PRU to stop loading new samples into the DDR. > Then I restart it. Very kludgy. My question is have you seen anyone with > similar problems switching heavy load and using the PRU? Is there maybe an > interrupt you think might be breaking the PRU out of its loop? I can post > code if it helps. > > I really like these PRUs. Very slick to get real-time capabilities plus > the convenience of linux and speed of python prototyping. > > Thanks, > Cressel Anderson > > -- > 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]. > 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]. For more options, visit https://groups.google.com/d/optout.
