Hmm thats interesting. I think I have narrowed my issue a littler more. It seems to ONLY occur when the motor system being powered by the PWM is actually running, i.e. given a supply voltage. If the power is off or even if the power is on and I simply disconnect the wire it works fine. (Well the PRU part. Sysfs still has issues) So naturally I thought EMI from the motors. I moved the wires, board, and motors as far apart as I could and still the issue persists. Again only when the motors are actually running. I then thought maybe it is an over voltage spike, but the same behavior occurs even when the wires are not connected that is floating pins or connected to a quite separate trim pot fed by VDD_ADC.
It is driving crazy. Is it possible that EMI at a different part of the board could affect the ADC? For example the P9_01 pin is pretty close to the motor system under normal setup but would EMI there cause issues with pin P9_36 (AIN5) ? On Tuesday, November 24, 2015 at 5:37:19 PM UTC-5, William Hermans wrote: > > *1) Has anyone run into this issue before?* >> >> *2) Does anyone have a possible solution?* >> >> *3) Does anyone have an effectively working method of driving a motor >> with on board PWM while simultaneously reading analog values with the on >> board ADC? * >> > > I have seen this issue before. In the two different ways I've used the > ADC. But it's not that the values simply repeat every sample. It's that the > values repeat in some context related to the FIFO. > > e.g. I see different value, for maybe( I have not actually counted ) let's > say 100 values ? Where then the values all repeat. Actually, I've used the > ADC three different ways technically. Used sysfs one-shot mode, and > continuous mode. As well as directly mapping the ADC module registers > through /dev/mem/ + mmap(). Using the later here is very similar to using > the PRU's to achieve the same, except the executable scope is all on the > main processor - Of course. > > A couple things to keep in mind. While I might be considered somewhat of > an expert when it comes to programming with a few different languages. I am > in no way an expert when it comes to this hardware. I am also relatively > new to writing software for / on Linux ( couple years hands on now ). > Another thing to consider is that I did not use any PWM module, and the ADC > values I read in were from floating pins( nothing connected to the pins ). > > SO here is one thing I've read about somewhere ( possibly the TRM ). Once > you're done reading from the FIFO, you're supposed to clear it somehow. I > think what I read was you need to write a "1" to a certain register . . . > and I experimented with clearing the FIFO manually, but all that gave back > in return was all zero's . . . I've since gotten side tracked and have not > looked into this issue any further. > > I honestly do not think this is a kernel module problem however . . . I > think this is more of "user not understanding the hardware completely" > issue. Definitely in my case. > > On Tue, Nov 24, 2015 at 9:39 AM, TJF <[email protected] <javascript:>> > wrote: > >> Hi! >> >> I can confirm the ADC issues with sysfs (, but didn't test sysfs PWM yet). >> >> Why don't you use libpruio features for PWM? >> >> BR >> >> -- >> 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:>. >> 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.
