buzzmarshall has quit [Quit: Konversation terminated!]
mvaittin has quit [*.net *.split]
mvaittin has joined #beagle
moto-timo has quit [*.net *.split]
vigneshr has quit [*.net *.split]
linkliu60 has quit [*.net *.split]
ketas has quit [*.net *.split]
vigneshr has joined #beagle
linkliu60 has joined #beagle
ketas has joined #beagle
moto-timo has joined #beagle
ikarso has joined #beagle
thinkfat has joined #beagle
thinkfat_ has quit [Ping timeout: 265 seconds]
otisolsen70 has joined #beagle
thinkfat has quit [Ping timeout: 264 seconds]
thinkfat has joined #beagle
thinkfat has quit [Ping timeout: 265 seconds]
thinkfat has joined #beagle
thinkfat has quit [Remote host closed the connection]
thinkfat has joined #beagle
florian has joined #beagle
behanw has quit [Quit: Connection closed for inactivity]
Shadyman has quit [Quit: Leaving.]
M-blaise has joined #beagle
alan_o has quit [Ping timeout: 268 seconds]
M-blaise has quit [Ping timeout: 265 seconds]
alan_o has joined #beagle
ArchismanDey[m] has quit [Quit: You have been kicked for being idle]
vigneshr has quit [Quit: Connection closed for inactivity]
M-blaise has joined #beagle
M-blaise has quit [Ping timeout: 252 seconds]
M-blaise has joined #beagle
otisolsen70_ has joined #beagle
otisolsen70 has quit [Ping timeout: 264 seconds]
otisolsen70_ has quit [Quit: Leaving]
buzzmarshall has joined #beagle
otisolsen70 has joined #beagle
behanw has joined #beagle
av500 has quit [Read error: No route to host]
av500 has joined #beagle
CrazyEddy has quit [Ping timeout: 260 seconds]
rcn-ee has quit [Remote host closed the connection]
rcn-ee has joined #beagle
the_person48 has joined #beagle
<the_person48>
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
<the_person48>
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:
<the_person48>
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
<the_person48>
2) the adc pins don't show up at all for some reason
<the_person48>
I was wondering if anyone knew why either/both of these might be occuring?
<the_person48>
here are my udev rules. in /etc/udev/rules.d:
<the_person48>
this is my dtsi overlay, which I compiled using overlay utils "make new_boot_overlay.dtbo", compiled succesfully: https://pastebin.com/GCRw9E0m
<the_person48>
notably, the gpio names seemed to be working better before I gave them the physical pin names (P8_24, P9_15, etc.)
<the_person48>
so possibly this is part of the problem? not sure
<zmatt>
the_person48: can you pastebin the output of ls -l /dev/gpio/
<zmatt>
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?
<zmatt>
*to include
<the_person48>
yes, they are
<the_person48>
notably, I tried changing the pin names to PP8_14, PP9_15, etc., and that fixed the links for all but one
<the_person48>
so maybe there's something about a reserved name set?
<the_person48>
and sure, one sec
<zmatt>
there is not
<zmatt>
so please just change them back so we can diagnose whatever the hell is going on
<the_person48>
ok
<zmatt>
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
<the_person48>
the /sys/bus/iio/devices directory is empty for me
<the_person48>
so sounds like that might be the issue?
waldo323__ has joined #beagle
<zmatt>
if the adc isn't enabled then obviously no symlink will be created either
<zmatt>
anyway, let's figure out gpio first, go grab that ls -l showing the bogus entries
<zmatt>
(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)
<zmatt>
udevadm test --action=add /sys/class/gpio/gpio32
<zmatt>
can you pastebin the output of that?
<zmatt>
OHHHH
<the_person48>
that's a good call
<zmatt>
never midn, I get it!
<the_person48>
oh you got it?
<zmatt>
yeah, P8_11 etc are macros used for pinmuxing
<the_person48>
yeah it's the same names I have in the second half in the pinmux
<the_person48>
so I guess that's causing some kind of weird conflict?
<zmatt>
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
<the_person48>
ahhh
<the_person48>
I see
<the_person48>
so maybe an escape character or similar?
<zmatt>
you could name them P8.11 etc
<zmatt>
I think . is allowed in node names
<the_person48>
ok, that works
<the_person48>
I'll do that
<zmatt>
or p8_11, or P8-11, or anything else that's not literally P8_11
<the_person48>
ok, will adjust! I think I'll use dots
florian has quit [Quit: Ex-Chat]
<zmatt>
or just cease the bad practice of naming the gpios after the BBB header pin and give them meaningful names instead :P
<zmatt>
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
<the_person48>
haha, well I appreciate the suggestion but I'm still gonna stick with this for now
<zmatt>
since you're initializing the gpios in DT, you're already making the DT dependent on which pin is used for what purpose
<the_person48>
it's more of a which-software-my-coworkers-want-to-mess-with kind of thing
<zmatt>
so making that purpose clear in the name would make a lot more sense
<the_person48>
they'd rather mess with their software than the low level DT overlay stuff
<the_person48>
so I'm trying to set it up such that they (hopefully) don't have to change it
<zmatt>
why would it be more likely they need to change the name in DT than changing the gpio config in DT ?
<zmatt>
if anything the gpio initialization seems more likely to require modification than the gpio names
<the_person48>
name change can be syntatitcal
<the_person48>
while changing the pin function would require a functional change, which is less likely
<zmatt>
the name should reflect the function hence also not be subject be change without hw change
<zmatt>
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
<the_person48>
well, you could have two names that have slightly different letters but have the same function
<zmatt>
?
<zmatt>
I have no idea what you mean by that
<zmatt>
the gpio name should just reflect what it's connected to in hardware
<the_person48>
12V_Power vs Power_12V
<the_person48>
anyway, it's not super important
<zmatt>
who cares which of those is used? pick one, it's fine
<the_person48>
changing to dots worked!
<zmatt>
(I'd power-12v-en or something probably)
<the_person48>
for sure
<zmatt>
any of those options is still way better than "P8_11" which requires consulting the schematic to know wtf it does
<the_person48>
yeah true, and noted
<the_person48>
ok, so I think the last thing I'm trying to figure out then is how to enable the analog pins in the overlay
<zmatt>
(and it's not like renaming them is difficult... just change the name and rebuild dtbo)
<zmatt>
though this adc configuration looks bizarre to me
<zmatt>
I don't know why you'd want to configure minimum sampling time and configure a large open-delay between sampling
<zmatt>
(I don't really know when you'd want to use opendelay in the first place)
<the_person48>
ok, so this is the general format, but you're reccomending different numbers/specifics I take it?
<the_person48>
I just want the adc's in their default configuration, if that's possible to specify
<zmatt>
there's no such thing
<zmatt>
but yeah, this config is silly
<the_person48>
what configuration would they be in if I didn't use a boot overlay?
<zmatt>
the opendelays should be zero
<zmatt>
none
<zmatt>
since your overlay is not touching the adc right now you can see what its default is: adc not enabled
<the_person48>
weird
<the_person48>
my adc was working before I added the overlay, actually
<the_person48>
after adding the udev rule, at least
<zmatt>
you're probably thinking of when you had cape-universal enabled
<zmatt>
which enables everything and the kitchen sink
<the_person48>
oh yeah that might have been it
<zmatt>
anyway, I wouldn't want this default config anyway
<zmatt>
at the very least swap the values of opendelay and sampledelay
<the_person48>
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"
<the_person48>
swap them, or just set opendelays to 0?
<zmatt>
opendelays to 0, sampledelays should be configured correctly for the application
<the_person48>
ok, and what do sampledelays do?
<zmatt>
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
<zmatt>
the correct value depends on the output impedance of whatever is driving the analog inputs
<zmatt>
or rather, the minimum correct value, larger is always fine from an accuracy point of view
<the_person48>
ok, I'm gonna have to check with my coworkers then
<the_person48>
will just make my best guess for now and see if it shows up when I add this:
<zmatt>
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
charlie5 has quit [Ping timeout: 265 seconds]
<zmatt>
(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)
<zmatt>
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
<the_person48>
gotcha
<the_person48>
ok, I will pass that along and talk to them to decide
<the_person48>
they are wondering what "chan-step-avg" is?
<zmatt>
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
<zmatt>
it can be configured to 1, 2, 4, 8, or 16
<the_person48>
gotcha
<zmatt>
the adc clock rate is 3 MHz btw, so the delays are in units of 1/3 μs
<the_person48>
also, the analog pins are showing up now
<the_person48>
for sure
<zmatt>
the total time per step is open_delay + num_averages * ( 2 + sample_delay + 13 ) adc clock cycles
<zmatt>
(the 13 is the conversion time)
<the_person48>
gotcha
<zmatt>
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)
<zmatt>
actually, now that I think of it I'm pretty sure the kernel gives 12-bit output regardless of averaging configured
<zmatt>
now I'm questioning whether the adc even outputs the extra precision from averaging... I might just have misremembered
<the_person48>
ok cool
<zmatt>
(if it doesn't then averaging merely acts as a mediocre low-pass filter)
charlie5 has joined #beagle
<zmatt>
yeah it always produces 12-bit output
<zmatt>
which is kind of dumb but *shrug*
<zmatt>
it's not a particularly good way to filter a signal in the first place
<zmatt>
you're configuring opendelay to get some specific samplerate?
<the_person48>
I'm not sure
<the_person48>
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"
<the_person48>
so maybe we're not understanding those ones
<zmatt>
opendelay is time wasted doing nothing whatsoever between channels
ikarso has quit [Quit: Connection closed for inactivity]
<the_person48>
so it should be 0?
<zmatt>
unless you have a specific reason to waste time e.g. to get some very particular samplerate
<the_person48>
no, we don't
<zmatt>
like I said, the total time per is open_delay + num_averages * ( 2 + sample_delay + 13 ) adc clock cycles
<the_person48>
ok
<zmatt>
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
<zmatt>
(2+sample_delay)/3 μs needs to be enough time for your source to charge the adc's 5.5 pF internal capacitor
<zmatt>
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)
<zmatt>
so you need sample_delay >= 9.7 * 5.5e-12 * R * 3e6 - 2 ... I think?
<zmatt>
where R is the output impedance of your source
<zmatt>
which actually means sample_delay=0 is fine if your output impedance is below 12.5 kΩ
<zmatt>
and all this is only true if I didn't completely fuck up the calculation
<zmatt>
(and I know this is probably chinese to you but it may be useful for the hw guys :P )
<the_person48>
haha well put
<the_person48>
will pass along
<the_person48>
and either way, the analog and GPIO pins are all working now, so thanks!
charlie5 has quit [Read error: Connection reset by peer]