<rcn-ee>
@jkridner rwmem is now in the package feed for buster/bullseye
<jkridner>
well, I think I was able to change the I2C clock speed, but I'm still getting "Remote I/O error" on this device. other devices are working. they tried swapping the sensor it in the field, but same result. guess I have to assume multiple bad sensors.
jfsimon1981 has quit [Ping timeout: 250 seconds]
jfsimon1981 has joined #beagle
starblue has quit [Ping timeout: 240 seconds]
starblue has joined #beagle
thinkfat_ has joined #beagle
thinkfat has quit [Ping timeout: 250 seconds]
sicelo has quit [Quit: Bye!]
sicelo has joined #beagle
sicelo has joined #beagle
sicelo has quit [Changing host]
vagrantc has quit [Quit: leaving]
jfsimon1981 has quit [Ping timeout: 256 seconds]
jfsimon1981 has joined #beagle
KartikANK has joined #beagle
ikarso has joined #beagle
KartikANK has quit [Quit: Leaving]
rob_w has joined #beagle
otisolsen70 has joined #beagle
vigneshr has joined #beagle
nslu2-log has quit [Remote host closed the connection]
nslu2-log has joined #beagle
florian has joined #beagle
Shadyman has quit [Remote host closed the connection]
indigaz6 has joined #beagle
indigaz has quit [Ping timeout: 240 seconds]
indigaz6 is now known as indigaz
starblue has quit [Ping timeout: 272 seconds]
starblue has joined #beagle
buckket has quit [Quit: buckket]
buckket has joined #beagle
set_ has quit [Remote host closed the connection]
vigneshr has quit [*.net *.split]
jfsimon1981 has quit [*.net *.split]
mag has quit [*.net *.split]
hays has quit [*.net *.split]
pbrobinson has quit [*.net *.split]
vitorio has quit [*.net *.split]
paulbarker has quit [*.net *.split]
samnob has quit [*.net *.split]
marcheu has quit [*.net *.split]
[j0rd] has quit [*.net *.split]
paulbarker has joined #beagle
mag has joined #beagle
vitorio has joined #beagle
[j0rd] has joined #beagle
samnob has joined #beagle
vigneshr has joined #beagle
hays has joined #beagle
pbrobinson has joined #beagle
jfsimon1981 has joined #beagle
marcheu has joined #beagle
Abhishek_ has joined #beagle
buzzmarshall has joined #beagle
Shadyman has joined #beagle
rob_w has quit [Remote host closed the connection]
vagrantc has joined #beagle
mag has quit [Remote host closed the connection]
mag has joined #beagle
Guest27 has joined #beagle
Guest9312 has joined #beagle
<Guest9312>
I was wondering if there were any other good documentation on PRU for BBAI besides the PRU cookbook. Specifically my team needs to gather samples with a consistent sampling frequency to recreate a FFT. I am a little confused on the current PRU syntax and functionality.
<zmatt>
what sort of sampling frequency are you aiming for?
<zmatt>
(and what are you sampling?)
<zmatt>
at its core the "PRU syntax and functionality" has never really changed, just some tooling around it has... although you can even still use uio_pruss and the old pasm assembler if you wanted to
<Guest9312>
A microphone around 4Khz, we had tried analog but the sampling frequency was inconsistent due to the operating system.
<zmatt>
the integrated ADC absolutely does support sampling at a consistent rate
<Guest9312>
Okay so it might be the way we take in data cause it is inconsistent
<zmatt>
if you were reading from sysfs then yes that will be inconsistent since those are individual single samples rather than setting up periodic sampling
<zmatt>
presumably iio supports periodic sampling, I've never looked into it
<Guest9312>
Thank you that makes sense
<zmatt>
worst case you could setup the adc from userspace and use pru as a crude dma controller to stream the data to a buffer, although if that turns out to be necessary that should be pretty embarassing to whoever wrote the adc kernel driver
<zmatt>
glancing at the adc kernel driver, I immediately see dma buffer swapping and comments that mention "cyclic DMA period"
<zmatt>
so like I assumed, it's absolutely designed to support periodic sampling and using dma to stream that data
<zmatt>
so it's just a matter of figuring out how to use that functionality
<zmatt>
Guest9312: iio_readdev does seem to work, although it's not immediately clear how to configure the samplerate, and it says "WARNING: High-speed mode not enabled" (I'm trying to determine what exactly that means)
<zmatt>
okay it's bad, that means it's not using cyclic mode
<Guest9312>
So I need to find another periodic library?
<zmatt>
I'm still trying to find out what's going on
<Guest9312>
Okay
<zmatt>
oh maybe this doesn't mean what I think it means and it still uses periodic sampling, just a less efficient way to transfer the data
<Guest9312>
How would we know the sampling rate? Can we get it from ADC
<zmatt>
good question, it ought to be configurable via iio but I don't see a device attribute for it, it's possible the kernel driver didn't bother to support changing its config via iio and only gets it from the DT config
<Guest9312>
Either way I need to get a consistent sampling rate.
<zmatt>
it'll be consistent (as long as you're only using the adc as adc and not also as resistive touchscreen controller)
<zmatt>
the question is just how it's been setup and what sampling rate that yield
<zmatt>
(still digging)
<Guest9312>
We are opening the #include <stdio.h> to fopen and fclose to get data.
<Guest9312>
So it made sense to me why it was inconsistent. Cause it had to do with the operating system
<Guest9312>
But I was trying to see how we could implement directly to only using the adc as adc
<Guest9312>
Sorry I am very new to microcontrollers
<Guest9312>
Rn we have written code in c
<zmatt>
Guest9312: yes, that's not how iio was designed to be used, reading the value from sysfs is basically more a debug mechanism
Guest27 has quit [Quit: Client closed]
<Guest9312>
Is there a library in c to read in vales consistently.
<zmatt>
also btw I recommend using low-level calls (open, close, read or pread) when reading sysfs attributes, since they don't really behave like normal files. and using pread instead of read avoids having to close and reopen an attribute, but that aside
<zmatt>
libiio
<Guest9312>
But I though libiio had a problem
<zmatt>
?
<zmatt>
what problem?
<Guest9312>
Guest9312: iio_readdev does seem to work, although it's not immediately clear how to configure the samplerate, and it says "WARNING: High-speed mode not enabled"
<Guest9312>
I also am confused how we set the sampling frequency
<zmatt>
also, here is the current default configuration used for the adc (by the BB-ADC.dtsi overlay): https://pastebin.com/Dsm7sTLf ... I have no idea _why_ it's configured like this, it doesn't really make any sense to me. I'd use a higher sampledelay and zero opendelay, and if you're going to do your own signal analysis anyway you'll probably want to disabling averaging
<zmatt>
Guest9312: I don't think that's an actual problem, it just means a newer high-speed mechanism of reading the data doesn't work (I think that's kernel version dependent)
<zmatt>
rcn-ee: do you have any idea where the adc config in BB-ADC.dtsi originally came from? it looks totally bizarre to me, and the fact that numerical values (measured in adc clock cycles) are being configured in hex rather than decimal inspires even less confidence in them
<rcn-ee>
should i just force the version you posted ^..
<zmatt>
no!
<zmatt>
what I just posted is the current config, not a config I think makes sense
<zmatt>
(current in bb.org-overlays)
<zmatt>
yeah what you linked is the same thing (but in hex)
<zmatt>
and no, you didn't get it from me
<zmatt>
it's been like this since ancient history
<zmatt>
which is also why this magic 0x98 got copied into many cape overlays that configure the adc
<zmatt>
I have no idea what the purpose of opendelay is or why you'd ever want to set it to a nonzero value except maybe if you want to fine-tune a specific sampling frequency
<zmatt>
setting opendelay to zero would increase samplerate (with 8 channels enabled) from 0.957 kHz to 1.5625 kHz
<zmatt>
also disabling averaging would increase it to 25 kHz which is something I'd recommend to people using libiio to stream data, though for people who use sysfs (i.e. pretty much everybody) it may be better to leave averaging enabled
<zmatt>
it's kinda stupid this can't be changed at runtime via sysfs or iio