**** BEGIN LOGGING AT Thu Mar 03 02:59:56 2022 **** BEGIN LOGGING AT Thu Mar 03 07:45:18 2022 Mar 03 18:21:08 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. Mar 03 18:22:19 what sort of sampling frequency are you aiming for? Mar 03 18:22:32 (and what are you sampling?) Mar 03 18:24:27 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 Mar 03 18:24:29 A microphone around 4Khz, we had tried analog but the sampling frequency was inconsistent due to the operating system. Mar 03 18:24:56 the integrated ADC absolutely does support sampling at a consistent rate Mar 03 18:25:52 Okay so it might be the way we take in data cause it is inconsistent Mar 03 18:26:28 if you were reading from sysfs then yes that will be inconsistent since those are individual single samples rather than setting up periodic sampling Mar 03 18:26:43 presumably iio supports periodic sampling, I've never looked into it Mar 03 18:27:10 Thank you that makes sense Mar 03 18:28:10 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 Mar 03 18:29:40 glancing at the adc kernel driver, I immediately see dma buffer swapping and comments that mention "cyclic DMA period" Mar 03 18:30:01 so like I assumed, it's absolutely designed to support periodic sampling and using dma to stream that data Mar 03 18:30:16 so it's just a matter of figuring out how to use that functionality Mar 03 18:40:53 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) Mar 03 18:42:41 okay it's bad, that means it's not using cyclic mode Mar 03 18:43:28 So I need to find another periodic library? Mar 03 18:45:50 I'm still trying to find out what's going on Mar 03 18:46:56 Okay Mar 03 18:49:22 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 Mar 03 18:51:49 How would we know the sampling rate? Can we get it from ADC Mar 03 18:59:00 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 Mar 03 19:00:50 Either way I need to get a consistent sampling rate. Mar 03 19:01:31 it'll be consistent (as long as you're only using the adc as adc and not also as resistive touchscreen controller) Mar 03 19:01:45 the question is just how it's been setup and what sampling rate that yield Mar 03 19:04:03 (still digging) Mar 03 19:07:55 We are opening the #include to fopen and fclose to get data. Mar 03 19:08:30 So it made sense to me why it was inconsistent. Cause it had to do with the operating system Mar 03 19:09:22 But I was trying to see how we could implement directly to only using the adc as adc Mar 03 19:09:40 Sorry I am very new to microcontrollers Mar 03 19:11:06 Rn we have written code in c Mar 03 19:22:09 Guest9312: yes, that's not how iio was designed to be used, reading the value from sysfs is basically more a debug mechanism Mar 03 19:22:53 Is there a library in c to read in vales consistently. Mar 03 19:23:26 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 Mar 03 19:23:30 libiio Mar 03 19:25:02 But I though libiio had a problem Mar 03 19:28:48 ? Mar 03 19:29:00 what problem? Mar 03 19:29:39 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" Mar 03 19:30:14 I also am confused how we set the sampling frequency Mar 03 19:31:41 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 Mar 03 19:32:23 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) Mar 03 19:33:46 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 Mar 03 19:34:02 BB-ADC-00A0.dts I mean Mar 03 19:36:10 zmatt: i thought i got these from you.. ;) https://github.com/beagleboard/BeagleBoard-DeviceTrees/blob/v5.17.x/src/arm/overlays/BB-ADC-00A0.dts Mar 03 19:37:09 should i just force the version you posted ^.. Mar 03 19:39:20 no! Mar 03 19:39:33 what I just posted is the current config, not a config I think makes sense Mar 03 19:39:59 (current in bb.org-overlays) Mar 03 19:40:40 yeah what you linked is the same thing (but in hex) Mar 03 19:40:44 and no, you didn't get it from me Mar 03 19:40:51 it's been like this since ancient history Mar 03 19:41:17 which is also why this magic 0x98 got copied into many cape overlays that configure the adc Mar 03 19:42:12 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 Mar 03 19:46:19 they come from John Syne from 2016... https://github.com/beagleboard/bb.org-overlays/commit/4b28e0564189e5ed07fd6696d85672b518486198 Mar 03 19:46:28 https://www.mail-archive.com/beagleboard@googlegroups.com/msg35831.html Mar 03 19:47:36 tuned for v4.1.x era... Mar 03 19:48:40 no explanation seems to be offered though Mar 03 19:49:27 can we just nuke step-avg, opendelay, sampledelay and just leave it to the kernel driver default? if someone wants to change it go head.. basicly back before this commit: https://github.com/beagleboard/bb.org-overlays/commit/4b28e0564189e5ed07fd6696d85672b518486198 Mar 03 19:51:33 or atleast commit them out, and add your detailed notes, that way the next person can mess around if they want.. Mar 03 19:51:48 turns out, these values *are* the kernel defaults o.O wtf Mar 03 19:52:21 ... so i should... add //kernel defaults... change as you wish? ;) Mar 03 19:52:51 so the next question becomes, why the fuck were these defaults set Mar 03 19:53:09 and does anyone TI even remember if they work.. Mar 03 19:53:43 and were these values chosen before or after the adc clock rate was changed? Mar 03 19:53:52 (which changes the meaning of these values) Mar 03 19:54:21 to be far... am43xx support was 'just' added 4 months ago.... https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/drivers/iio/adc/ti_am335x_adc.c?h=v5.17-rc6 Mar 03 20:22:14 rcn-ee: I've updated the comments of https://pastebin.com/Dsm7sTLf Mar 03 20:24:08 thanks zmatt! Mar 03 20:25:11 and pushed... https://github.com/beagleboard/bb.org-overlays/commit/8e8d67056d07b1728573f2b03d8f22ae57f719e5 Mar 03 20:25:58 setting opendelay to zero would increase samplerate (with 8 channels enabled) from 0.957 kHz to 1.5625 kHz Mar 03 20:26:57 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 Mar 03 20:28:47 it's kinda stupid this can't be changed at runtime via sysfs or iio Mar 03 22:56:24 rcn-ee: one final update to the comments: https://pastebin.com/raw/Dsm7sTLf (I promise I'm done now) Mar 03 22:56:59 zmatt: no worries, we are never done. ;) Mar 03 22:57:38 *sigh* .... you're not wrong Mar 03 22:59:51 but I've closed every window related to this now so I can't be tempted to review/reword it again ;) Mar 03 23:04:31 i know that... best thing about a kernel update... i reboot and all y problems "tabs" get to start over.. Mar 03 23:04:39 hehe Mar 04 00:03:09 hey matt, did you give me a response on why my i2c wasn't working? i had to bail last minute on that but my image is correct, library is up to date, and im still getting that i2c error Mar 04 00:04:43 that's weird.. I 'm not very familiar with librobotcontrol though, nor do I have a beaglebone blue to test things Mar 04 00:05:42 yeah, thats why im so confused, i followed the guide on installation to a t and im still getting that error Mar 04 00:06:13 could it be something to do with the i2c bus in general? Mar 04 00:06:46 which guide? Mar 04 00:07:04 lemme pull up the link quick, one sec Mar 04 00:07:16 Hey guys. I have a bbblue here. Mar 04 00:07:27 http://www.strawsondesign.com/docs/librobotcontrol/installation.html Mar 04 00:07:41 Maldark909: I mean, the bus they're on (i2c2) is entirely internal to the beaglebone blue, so it doesn't seem likely there'd be anything specific wrong with it Mar 04 00:08:27 ok.... hey set_ did you ever get this problem? Mar 04 00:08:35 Here: https://beagleboard.org/static/librobotcontrol/ is something I found a while back. Mar 04 00:08:43 Maldark909: uh so what part of it did you "follow" ? since as it says, it's already installed by default Mar 04 00:08:54 On the newer kernel yes and the newer image yes. Mar 04 00:08:57 the testing portion Mar 04 00:09:17 Maldark909: so rc_test_drivers fails? Mar 04 00:09:29 that all passes, its on rc_test_mpu that it fails Mar 04 00:10:24 set_ what did you do to fix it? Mar 04 00:10:47 Nothing yet. Sidetrack is my name. Mar 04 00:10:56 But... Mar 04 00:11:04 I just plugged in. Let me see what I can get done. Mar 04 00:11:38 Maldark909: my guess would be there's just some kind of issue with rc_test_mpu Mar 04 00:12:54 The older image from the bbb.io/latest-images is outdated and so is the kernel. I think some people are passing the torch on testing it any further but I am sure some will want to keep it around for functionality, i.e. librobotcontrol. Mar 04 00:13:21 I mean, it's still stable and supported Mar 04 00:13:42 and it's not like i2c changed since then :P Mar 04 00:14:16 well my main hope is to get this to work so i can use that mpu on the board, cause i just don't have the time to learn i2c to make it work on my own without this library Mar 04 00:14:33 Maldark909: note btw that since the imu is simply an i2c-attached device, there's nothing beaglebone-specific about using it, so any code you may find on the internet for using this imu on linux should work Mar 04 00:14:46 Hey Maldark909: Here is what I made in the repos for the "updated items" (kernel and image): https://github.com/beagleboard/librobotcontrol/issues/213 . Mar 04 00:14:47 afaik it also has a kernel driver, not sure why that isn't being used Mar 04 00:15:11 A long list! Mar 04 00:15:34 set_: how is this relevant here? Mar 04 00:15:46 It is about librobotcontrol so far. Mar 04 00:15:49 and... Mar 04 00:15:52 ... and? Mar 04 00:15:54 I still like to mingle w/ it. Mar 04 00:16:03 It is an awesome lib. Mar 04 00:16:41 what was the exact model of the mpu on the board again? Mar 04 00:16:50 mpu9250 Mar 04 00:17:11 ok, lemme see if the internet can bring me some code then Mar 04 00:17:50 Maldark909: I will work w/ you on the errors you are seeing if necessary. I am booting now. I forgot to add the uSD Card. Mar 04 00:18:00 Oops. Mar 04 00:18:04 (which is apparently equivalent to a mpu6500 with an ak8963 magnetometer attached) Mar 04 00:18:16 set_: you really don't need to :P Mar 04 00:18:21 Fine. Okay. Mar 04 00:18:34 set_ the error i am getting is the following: (give me one sec to putty into my board to have it activate the error) Mar 04 00:18:41 Okay. Mar 04 00:20:03 in rc_i2c_write_byte, system write returned -1, expected 2 (repeats this line again) Mar 04 00:20:04 resetting MPU, I2C write to reset bit failed Mar 04 00:20:04 failed to reset_mpu9250 Mar 04 00:20:05 rc_mpu_initialize_failed Mar 04 00:20:49 also zmatt would an arduino lib work with the bbblue? Mar 04 00:21:05 not without major changes no Mar 04 00:21:16 yep thats what i was expectin Mar 04 00:21:34 something for the rpi probably would work though Mar 04 00:22:22 Hmm. Mar 04 00:22:36 https://github.com/Alexgichamba/mpu9250-with-raspberrypi you think this would work then zmatt Mar 04 00:22:54 Okay. I will see if 4.19.94-ti-r70 w/ librobotcontrol prompts this errors and then I will research. Mar 04 00:23:25 Maldark909: uh, wtf that uses gpio instead of an i2c bus? Mar 04 00:24:00 Maldark909: okay I guess I underestimated the bizarre things people make for the rpi Mar 04 00:24:26 Uh duh. Mar 04 00:24:45 Have you not seen the quad-ped for the Pi yet? Mar 04 00:25:02 Yikes. It is like an attack dog. I get scared watchin' the productions. Mar 04 00:25:15 * set_ runs for cover! Mar 04 00:26:06 ah geez Mar 04 00:26:37 Maldark909. My image was bare. I am updating and upgrading librobotcontrol now. Mar 04 00:26:47 roger that Mar 04 00:27:04 Maldark909: can you try: i2cget -y 2 0x68 0x6b Mar 04 00:27:18 yep, lemme run the command here Mar 04 00:27:35 Error: Read failed Mar 04 00:29:21 let me double-check I got the right numbers Mar 04 00:29:44 ok, i think the 68 was correct, lemme see if i can find the command to get the bus location Mar 04 00:30:03 Maldark909: it's i2c2 Mar 04 00:30:18 (there's no command to get that, I checked the schematic) Mar 04 00:30:29 something like this idea: https://pastebin.com/pzvE5DR5 Mar 04 00:30:49 set_: no, that looks like you broke something completely Mar 04 00:30:56 since that path is nonsense Mar 04 00:31:04 Okay! Mar 04 00:31:16 Sorry. I am denser than dense this afternoon. Mar 04 00:31:47 you good set_ Mar 04 00:31:53 Ha. Mar 04 00:32:05 Maldark909: just as a sanity-check, can you try using the blue version of my show-pins utility: https://github.com/mvduin/bbb-pin-utils/tree/blue#show-pins to double check that the pins are muxed right (show-pins -v | grep imu) Mar 04 00:32:44 rc_version is 1.0.5 and I am drained. Please forgive me. Mar 04 00:32:59 Droops one eye lid to see better. Mar 04 00:33:09 pretty sure the one installed by default is 1.0.4 Mar 04 00:33:18 Hmm. Mar 04 00:33:20 Okay. Mar 04 00:33:34 So, can we both say I am futuristic? Mar 04 00:33:46 or maybe you just used apt upgrade :P Mar 04 00:33:51 Ha. Okay. Mar 04 00:34:36 1.0.5 still. Mar 04 00:34:47 Oh. Mar 04 00:34:56 I got what you were saying now. Mar 04 00:35:05 Yes. I did upgrade librobotcontrol. Mar 04 00:35:17 It is right there in the headlines. Mar 04 00:35:18 Maldark909: register 0x6b is the PWR_MGMT_1 register which is also the first register librobotcontrol tries to write Mar 04 00:36:35 Maldark909: yeah I'm pretty sure that read ought to work Mar 04 00:36:52 whats the command to register that to pwr Mar 04 00:37:04 to what? Mar 04 00:37:28 how do i register 0x6b to PWR_MGMT_1 Mar 04 00:37:33 ???? Mar 04 00:37:48 0x6b is the address of the register named PWR_MGMT_1 Mar 04 00:38:00 oh my bad i misread Mar 04 00:38:08 i2cget -y 2 0x68 0x6b is how you'd read that register Mar 04 00:38:13 set_: does that command work for you? Mar 04 00:38:19 Let me check. Mar 04 00:39:28 Oh and by the way, sorry for interjecting here. I like the lib. and have found it dangerous yet fun. Mar 04 00:39:54 They should put some starter props on the machines to start. Mar 04 00:39:57 I do vaguely recall having previously messed with some imu (can't remember if it's this one) that turned out to just vanish from the i2c bus if you confused it by making some kind of request it didn't understand Mar 04 00:40:04 i also just got my bbblue online to get that show pins application, can we upload images to this chat? Mar 04 00:41:06 Maldark909: you cannot, but its output is text so you can just use pastebin... although show-pins -v | grep imu should yield only two lines of output anyway (but preferably still use pastebin for that) Mar 04 00:41:19 or maybe three lines Mar 04 00:41:26 @zmatt: No. I received an error...here it is! Error: Could not open file `/dev/i2c-2': Permission denied Mar 04 00:41:36 set_: okay so your system is completely broken Mar 04 00:41:40 yes! Mar 04 00:41:53 set_: stick sudo in front of it? Mar 04 00:41:58 Time to do a fix-a-roo! Mar 04 00:41:59 Aw. Mar 04 00:42:05 Okay. Mar 04 00:42:08 then again, your system is completely broken so I'm not sure this is a useful test anyway Mar 04 00:42:12 I will try that idea. Mar 04 00:42:14 Ha. Mar 04 00:42:42 imu irq          107      fast      rx     up    7     gpio 3.21      ocp/helper   (pins) Mar 04 00:42:47 I got a reply on output! Mar 04 00:43:08 Maldark909: like I said, use pastebin Mar 04 00:43:21 to my knowledge putty doesn't let me Mar 04 00:43:28 I don't know if you tried to paste multiple lines, but only one got through (and it's the one that doesn't matter) Mar 04 00:43:33 Maldark909: uhh, what do you mean? Mar 04 00:43:49 i wasn't able to paste from putty to here Mar 04 00:44:03 imu irq                          107 fast rx  up  7 gpio 3.21        ocp/helper (pins) Mar 04 00:44:08 ow wait now it works Mar 04 00:44:38 you can definitely copy/paste from putty, but I think you just select the text in putty or something, you don't copy with ctrl-C since that just sends ctrl-C into the terminal Mar 04 00:44:38 but that was all i got with the show-pins -v | grep imu command Mar 04 00:44:47 uhhh Mar 04 00:45:22 hold on Mar 04 00:45:26 So, anyway. Droop here needs a break unless I can add anything else. Mar 04 00:45:52 other than my bbblue is just being weird apparently? no not really Mar 04 00:46:00 enjoy your break! Mar 04 00:46:24 Okay. No issue. Thank you. It is hot outside and it just turned march. We have had an extremely hot winter. Mar 04 00:46:25 Maldark909: ah, show-pins -vv | grep imu Mar 04 00:46:27 I run w/ mowers. Mar 04 00:46:36 * set_ and out. Mar 04 00:46:54 I²C (imu, barometer)              94 fast rx  up  3 i²c 2 sda        i2c@4819c000 (pinmux_i2c2_pins) Mar 04 00:46:54 I²C (imu, barometer)              95 fast rx  up  3 i²c 2 scl        i2c@4819c000 (pinmux_i2c2_pins) Mar 04 00:46:55 imu irq                          107 fast rx  up  7 gpio 3.21        ocp/helper (pins) Mar 04 00:47:03 Maldark909: also like I said, use pastebin instead of pasting into chat :/ Mar 04 00:47:13 but okay, the pins are setup fine Mar 04 00:47:30 i thought that was *im bad with certain things my apologies* Mar 04 00:47:49 pastebin is a website for sharing text snippets Mar 04 00:48:04 ..... oh. i thought it was a special paste Mar 04 00:48:47 I probably should have said pastebin.com .. that would have been clearer Mar 04 00:49:12 https://pastebin.com/NEVgdBQT like this? Mar 04 00:51:14 indeed! Mar 04 00:51:58 can you try: i2cget -y 2 0x76 0xd0 Mar 04 00:52:16 0x58 Mar 04 00:52:39 okay so the bmp280 barometer that's on the same i2c bus is reachable just fine Mar 04 00:53:09 did i just get a bad board then? Mar 04 00:53:17 cause set was able to read his mpu Mar 04 00:53:25 was he? Mar 04 00:53:30 thought so Mar 04 00:53:57 yeah he said he got a reply after sudo-ing Mar 04 00:54:11 before you ask, already tried sudo-ing Mar 04 00:54:31 Maldark909: just to be on the safe side, can you try power-cycling (not merely rebooting) the board and then try i2cget -y 2 0x68 0x6b again (without running any other tests) Mar 04 00:54:39 gotcha Mar 04 00:54:50 ah I missed that Mar 04 00:55:03 ok, power cycling the board Mar 04 00:55:10 you don't need sudo, he needed it because his system is just really fucked somehow Mar 04 00:55:56 Now, did someway someone somehow talk about me? Yes! Mar 04 00:56:12 Does this mean I am popular now? Mar 04 00:56:24 Just kiddin'. Mar 04 00:56:35 nope, still get a read failed Mar 04 00:57:31 Maldark909: it's actually starting to sound like an issue with the imu itself on your board yeah Mar 04 00:57:53 weird Mar 04 00:58:27 well i can at least console myself that its not me, its my board Mar 04 01:02:21 ok yeah, i was able to find the command to list i2c devices and i only have 76 Mar 04 01:06:11 beware of usign i2cdetect, i2c is not a discoverable bus and i2cdetect basically just guesses whta kind of transfer it could do to try to see if a device is there, but that's 1. not guaranteed to work 2. not guaranteed to be harmless Mar 04 01:06:49 I can't remember what device it was, but I've once encountered an i2c device that got so confused by what i2cdetect was doing that it completely disappeared from the i2c bus as a result Mar 04 01:08:40 ok, ill keep that in mind going forward. Is there a way to get it on the i2c bus? Mar 04 01:09:31 I was just saying to beware of using i2cdetect or assuming its output is right, the appropriate way to test an i2c device is by making a request for it that is correct for the device (which we've already done) Mar 04 01:10:32 ok **** ENDING LOGGING AT Fri Mar 04 02:59:56 2022