**** BEGIN LOGGING AT Mon Sep 20 02:59:57 2021 Sep 20 16:25:42 hi guys, I am running debian 9.5 on a beaglebone black rev C. I am working on setting up a boot overlay for the GPIO and other pins. I cloned overlay-utils and show-pins from github to do the overlay, and check the configuration, respectively Sep 20 16:25:48 the overlay seems to be working! however, when I then added udev rules to name the gpio and adc pins in /dev, I encountered two issues: Sep 20 16:25:54 1) the names for the gpio pins are screwed up--they are mostly not the names I gave them, and the total number is wrong as well Sep 20 16:26:01 2) the adc pins don't show up at all for some reason Sep 20 16:26:10 I was wondering if anyone knew why either/both of these might be occuring? Sep 20 16:26:20 here are my udev rules. in /etc/udev/rules.d: Sep 20 16:26:37 gpio-symlinks.rules: https://pastebin.com/RHpxYLuq Sep 20 16:26:44 and ain-symlinks.rules: https://pastebin.com/t0wFVERT Sep 20 16:27:21 this is my dtsi overlay, which I compiled using overlay utils "make new_boot_overlay.dtbo", compiled succesfully: https://pastebin.com/GCRw9E0m Sep 20 16:27:27 notably, the gpio names seemed to be working better before I gave them the physical pin names (P8_24, P9_15, etc.) Sep 20 16:27:39 so possibly this is part of the problem? not sure Sep 20 16:27:45 also, here is my /boot/uEnv.txt (not sure if it's relevant): https://pastebin.com/sA7X3wT7 Sep 20 16:56:18 the_person48: can you pastebin the output of ls -l /dev/gpio/ Sep 20 16:57:48 the_person48: just to be sure, those .rules files are exactly what you have on your filesystem? you didn't forget the include the backslashes at the end of some of the lines? Sep 20 16:57:52 *to include Sep 20 16:58:06 yes, they are Sep 20 16:58:34 notably, I tried changing the pin names to PP8_14, PP9_15, etc., and that fixed the links for all but one Sep 20 16:58:44 so maybe there's something about a reserved name set? Sep 20 16:58:47 and sure, one sec Sep 20 16:58:48 there is not Sep 20 16:59:07 so please just change them back so we can diagnose whatever the hell is going on Sep 20 16:59:17 ok Sep 20 17:01:00 also, does the adc show up in /sys/bus/iio/devices/ ? if not then your overlay will need to explicitly enable (and probably configure) the adc Sep 20 17:01:37 the /sys/bus/iio/devices directory is empty for me Sep 20 17:01:46 so sounds like that might be the issue? Sep 20 17:04:22 if the adc isn't enabled then obviously no symlink will be created either Sep 20 17:05:02 anyway, let's figure out gpio first, go grab that ls -l showing the bogus entries Sep 20 17:05:19 ok Sep 20 17:05:19 https://pastebin.com/5uA32baQ Sep 20 17:05:33 that's ls -l /dev/gpio Sep 20 17:05:58 cat /sys/class/gpio/gpio32/label Sep 20 17:07:30 (btw I do suggest at least using e.g. P8_03 instead of P8_3 as label, both for consistency with other things and to ensure they get sorted correctly, but that aside) Sep 20 17:08:45 udevadm test --action=add /sys/class/gpio/gpio32 Sep 20 17:08:52 can you pastebin the output of that? Sep 20 17:09:55 OHHHH Sep 20 17:09:56 that's a good call Sep 20 17:10:00 never midn, I get it! Sep 20 17:10:06 oh you got it? Sep 20 17:10:28 yeah, P8_11 etc are macros used for pinmuxing Sep 20 17:10:55 yeah it's the same names I have in the second half in the pinmux Sep 20 17:11:16 so I guess that's causing some kind of weird conflict? Sep 20 17:11:17 the c preprocessor has no way of knowing you're trying to use them as node names here instead of as constants in pinmux expressions, it simply replaces the tokens Sep 20 17:11:24 ahhh Sep 20 17:11:26 I see Sep 20 17:11:35 so maybe an escape character or similar? Sep 20 17:11:44 you could name them P8.11 etc Sep 20 17:11:57 I think . is allowed in node names Sep 20 17:12:15 ok, that works Sep 20 17:12:17 I'll do that Sep 20 17:12:38 or p8_11, or P8-11, or anything else that's not literally P8_11 Sep 20 17:13:11 ok, will adjust! I think I'll use dots Sep 20 17:15:34 or just cease the bad practice of naming the gpios after the BBB header pin and give them meaningful names instead :P Sep 20 17:15:59 the argument that they're generic and software should sort it out ceased to be true the moment you started configuring their default state in DT Sep 20 17:17:02 haha, well I appreciate the suggestion but I'm still gonna stick with this for now Sep 20 17:17:04 since you're initializing the gpios in DT, you're already making the DT dependent on which pin is used for what purpose Sep 20 17:17:20 it's more of a which-software-my-coworkers-want-to-mess-with kind of thing Sep 20 17:17:22 so making that purpose clear in the name would make a lot more sense Sep 20 17:17:31 they'd rather mess with their software than the low level DT overlay stuff Sep 20 17:17:44 so I'm trying to set it up such that they (hopefully) don't have to change it Sep 20 17:18:00 why would it be more likely they need to change the name in DT than changing the gpio config in DT ? Sep 20 17:18:38 if anything the gpio initialization seems more likely to require modification than the gpio names Sep 20 17:19:05 name change can be syntatitcal Sep 20 17:19:24 while changing the pin function would require a functional change, which is less likely Sep 20 17:20:19 the name should reflect the function hence also not be subject be change without hw change Sep 20 17:21:01 I mean, yes, you could decide to change it on aesthetics, but given that it's just an identifier used by software it's not like the precise wording is super critical Sep 20 17:21:10 well, you could have two names that have slightly different letters but have the same function Sep 20 17:21:18 ? Sep 20 17:21:31 I have no idea what you mean by that Sep 20 17:21:40 the gpio name should just reflect what it's connected to in hardware Sep 20 17:21:44 12V_Power vs Power_12V Sep 20 17:21:55 anyway, it's not super important Sep 20 17:21:59 who cares which of those is used? pick one, it's fine Sep 20 17:22:12 changing to dots worked! Sep 20 17:22:31 (I'd power-12v-en or something probably) Sep 20 17:22:37 for sure Sep 20 17:22:54 any of those options is still way better than "P8_11" which requires consulting the schematic to know wtf it does Sep 20 17:23:18 yeah true, and noted Sep 20 17:23:20 ok, so I think the last thing I'm trying to figure out then is how to enable the analog pins in the overlay Sep 20 17:23:51 (and it's not like renaming them is difficult... just change the name and rebuild dtbo) Sep 20 17:24:01 I'm thinking there's maybe an example on that somewhere here? https://github.com/mvduin/overlay-utils Sep 20 17:24:07 yeah also true Sep 20 17:24:21 I don't think I have an adc example, but maybe I do and forgot Sep 20 17:25:39 ok, I'll look around in here at leats Sep 20 17:25:55 this is what the BB-ADC-00A0 overlay does: https://pastebin.com/VEzmnyJe Sep 20 17:26:03 though this adc configuration looks bizarre to me Sep 20 17:26:29 I don't know why you'd want to configure minimum sampling time and configure a large open-delay between sampling Sep 20 17:26:56 (I don't really know when you'd want to use opendelay in the first place) Sep 20 17:27:17 ok, so this is the general format, but you're reccomending different numbers/specifics I take it? Sep 20 17:27:31 I just want the adc's in their default configuration, if that's possible to specify Sep 20 17:28:12 there's no such thing Sep 20 17:28:28 but yeah, this config is silly Sep 20 17:28:35 what configuration would they be in if I didn't use a boot overlay? Sep 20 17:28:39 the opendelays should be zero Sep 20 17:28:41 none Sep 20 17:29:08 since your overlay is not touching the adc right now you can see what its default is: adc not enabled Sep 20 17:29:46 weird Sep 20 17:29:55 my adc was working before I added the overlay, actually Sep 20 17:30:06 after adding the udev rule, at least Sep 20 17:30:45 you're probably thinking of when you had cape-universal enabled Sep 20 17:30:50 which enables everything and the kitchen sink Sep 20 17:30:54 oh yeah that might have been it Sep 20 17:31:12 anyway, I wouldn't want this default config anyway Sep 20 17:31:20 at the very least swap the values of opendelay and sampledelay Sep 20 17:31:48 but yeah I don't really know what the configuration settings mean, so I'm just trying to take my best guess as to what would be "normal" Sep 20 17:31:58 swap them, or just set opendelays to 0? Sep 20 17:32:15 opendelays to 0, sampledelays should be configured correctly for the application Sep 20 17:33:00 ok, and what do sampledelays do? Sep 20 17:34:19 it specifies the sampling time in adc clock cycles, or rather the additional sampling time on top of the minimum of 2 adc clock cycles Sep 20 17:34:44 the correct value depends on the output impedance of whatever is driving the analog inputs Sep 20 17:35:00 or rather, the minimum correct value, larger is always fine from an accuracy point of view Sep 20 17:35:54 ok, I'm gonna have to check with my coworkers then Sep 20 17:36:08 will just make my best guess for now and see if it shows up when I add this: Sep 20 17:36:15 https://pastebin.com/RzR5f0cB Sep 20 17:36:17 basically, during sampling a 5.5 pF capacitor inside the ADC is connected to the input being samples, and it needs to (dis)charge to the analog voltage Sep 20 17:37:21 (specifically TI recommends setting sampling time large enough to allow the source to charge/discharge the capacitor to within 0.25 LSB, which is 440 μV for a single-ended input with 1.8V reference voltage) Sep 20 17:39:02 setting it lower than necessary means the measurements will be inaccurate, setting it higher than needed means it'll take longer to sample hence the rate at which the inputs are sampled is lower Sep 20 17:39:48 gotcha Sep 20 17:39:56 ok, I will pass that along and talk to them to decide Sep 20 17:40:39 they are wondering what "chan-step-avg" is? Sep 20 17:41:29 that configures averaging, so 16 (the max value) means it'll sample the input 16 times and take the average... this increases the number of bits of precision at the expense of being slower Sep 20 17:41:36 it can be configured to 1, 2, 4, 8, or 16 Sep 20 17:41:44 gotcha Sep 20 17:42:10 the adc clock rate is 3 MHz btw, so the delays are in units of 1/3 μs Sep 20 17:42:17 also, the analog pins are showing up now Sep 20 17:42:29 for sure Sep 20 17:45:20 the total time per step is open_delay + num_averages * ( 2 + sample_delay + 13 ) adc clock cycles Sep 20 17:45:28 (the 13 is the conversion time) Sep 20 17:47:01 gotcha Sep 20 17:47:59 with num_averages=1 you get 12-bit output, with num_averages=16 you get 16-bit output ... how many bits of the output are actually _useful_ is of course a separate matter ;) (and will depend on the sampling time amoung other things) Sep 20 17:49:04 actually, now that I think of it I'm pretty sure the kernel gives 12-bit output regardless of averaging configured Sep 20 17:49:57 now I'm questioning whether the adc even outputs the extra precision from averaging... I might just have misremembered Sep 20 17:49:59 ok cool Sep 20 17:50:26 (if it doesn't then averaging merely acts as a mediocre low-pass filter) Sep 20 17:55:49 yeah it always produces 12-bit output Sep 20 17:58:04 which is kind of dumb but *shrug* Sep 20 17:58:24 it's not a particularly good way to filter a signal in the first place Sep 20 18:04:53 gotcha Sep 20 18:10:36 &tscadc { Sep 20 18:10:37 status = "okay"; Sep 20 18:10:37 adc { Sep 20 18:10:38 ti,adc-channels = <0 1 2 3 4 5 6 7>; Sep 20 18:10:38 ti,chan-step-avg = <16 16 16 16 16 16 16 16>; Sep 20 18:10:39 ti,chan-step-opendelay = <3 3 3 3 3 3 3 3>; Sep 20 18:10:39 ti,chan-step-sampledelay = <6 6 6 6 6 6 6 6>; Sep 20 18:10:40 }; Sep 20 18:10:40 }; Sep 20 18:10:42 OI Sep 20 18:10:43 this is what we settled on Sep 20 18:10:46 haha the heart Sep 20 18:11:05 you're configuring opendelay to get some specific samplerate? Sep 20 18:11:30 I'm not sure Sep 20 18:11:36 my coworker said "The open delay and sample delay I'm not sure of. is that in 1/3 us as well? If so, set them at 3 to 6" Sep 20 18:11:40 so maybe we're not understanding those ones Sep 20 18:11:57 opendelay is time wasted doing nothing whatsoever between channels Sep 20 18:13:00 so it should be 0? Sep 20 18:13:25 unless you have a specific reason to waste time e.g. to get some very particular samplerate Sep 20 18:13:33 no, we don't Sep 20 18:13:54 like I said, the total time per is open_delay + num_averages * ( 2 + sample_delay + 13 ) adc clock cycles Sep 20 18:14:28 ok Sep 20 18:14:54 open_delay cycles of doing nothing, then it samples the input num_averages times, taking 2+sample_delay cycles of sampling time + 13 cycles of conversion time Sep 20 18:16:32 (2+sample_delay)/3 μs needs to be enough time for your source to charge the adc's 5.5 pF internal capacitor Sep 20 18:18:49 if I didn't fuck up the calculation it takes 9.7 RC-times to get to within 0.25 LSB (as recommended by TI) Sep 20 18:21:39 so you need sample_delay >= 9.7 * 5.5e-12 * R * 3e6 - 2 ... I think? Sep 20 18:22:04 where R is the output impedance of your source Sep 20 18:22:31 which actually means sample_delay=0 is fine if your output impedance is below 12.5 kΩ Sep 20 18:22:41 and all this is only true if I didn't completely fuck up the calculation Sep 20 18:24:45 (and I know this is probably chinese to you but it may be useful for the hw guys :P ) Sep 20 18:34:58 haha well put Sep 20 18:35:16 will pass along Sep 20 18:36:38 and either way, the analog and GPIO pins are all working now, so thanks! Sep 20 18:52:00 \o/ Sep 20 18:52:14 ah he left Sep 21 02:52:31 zmatt: quick query if you're around .. /sys/class/leds .. I'm guessing needs to be defined in DT, and not also defined in /sys/class/gpio [or such] ? ie. if there is data present in the GPIO section, and you want it as a led 'item' you need to Move It :D Sep 21 02:52:47 (or anyone similarly versed in DT/sys/class-fu) Sep 21 02:53:12 correct Sep 21 02:53:37 damn, when the brain works .. XD Sep 21 02:53:42 thanks Sep 21 02:53:55 sanity-check: PASS - you /are/ insane :d Sep 21 02:54:03 of course not all led drivers are gpio, there's also pwm-led and such Sep 21 02:54:28 oooh, can I have a fading 'heartbeat' led?! :p Sep 21 02:54:55 but yeah, gpio-leds or whatever it's called will claim those gpios, which is mutually exclusive with exporting to sysfs... or at least it should be, iirc rcn's kernel has some check patched out Sep 21 02:55:06 I can usefully port the beagle* over to my pine64 :D Sep 21 02:55:10 DT* **** ENDING LOGGING AT Tue Sep 21 02:59:57 2021