<set_>
GenTooMan: I am learning bit-specific addressing! Nifty is an understatement! Ha.
<set_>
Took a while, heh? But now, I can do-eeee and do-eeee w/ ease. Man, it took a lifetime of jumping back and forth.
<set_>
I was like frogger but in the life of programming. Heh? I must have been hit by chompers too many times. Sheesh.
<set_>
Now...if I could only make this Cortex-M4 work on the AI, AI, AI! Send rations until I configure it, please.
SJFriedl has joined #beagle
h_ has quit []
hays has joined #beagle
starblue1 has quit [Ping timeout: 256 seconds]
starblue1 has joined #beagle
thinkfat has quit [Ping timeout: 250 seconds]
thinkfat_ has joined #beagle
rcn-ee_ has quit [Remote host closed the connection]
rcn-ee__ has joined #beagle
russ has quit [Ping timeout: 256 seconds]
russ has joined #beagle
Shadyman has joined #beagle
buzzmarshall has quit [Quit: Konversation terminated!]
rob_w has joined #beagle
florian has joined #beagle
javaJake_ has joined #beagle
javaJake has quit [Ping timeout: 240 seconds]
javaJake_ is now known as javaJake
starblue1 has quit [Ping timeout: 240 seconds]
starblue1 has joined #beagle
rcn-ee__ has quit [Remote host closed the connection]
rcn-ee__ has joined #beagle
mag has quit [Ping timeout: 240 seconds]
mag has joined #beagle
lucascastro has quit [Remote host closed the connection]
lucascastro has joined #beagle
M-blaise has joined #beagle
M-blaise has quit [Ping timeout: 256 seconds]
ikarso has joined #beagle
Shadyman has quit [Remote host closed the connection]
rcn-ee has joined #beagle
rcn-ee__ has quit [Ping timeout: 256 seconds]
M-blaise has joined #beagle
xet7 has quit [Quit: Leaving]
xet7 has joined #beagle
ogra` is now known as ogra
ogra has quit [Changing host]
ogra has joined #beagle
Konsgn has joined #beagle
<Konsgn>
Hi All, How would one modify u-boot so it doesn't load the am335x-pocketbeagle.dtb file? I see the findfdt script, but not where in the u-boot it is instantiated.
rob_w has quit [Quit: Leaving]
rcn-ee_ has joined #beagle
rcn-ee has quit [Read error: Connection reset by peer]
CrazyEddy has quit [Ping timeout: 240 seconds]
<zmatt>
Konsgn: you can just override the dtb in /boot/uEnv.txt
<zmatt>
dtb=my-custom-board.dtb
<zmatt>
and findfdt is invoked from bootcmd
rcn-ee_ has quit [Ping timeout: 240 seconds]
thinkfat_ has quit [Quit: Konversation terminated!]
<Konsgn>
gotcha, if the dtb is invalid, would it fall back to the eeprom detected one?
<zmatt>
nope
rcn-ee has joined #beagle
hays has quit [Ping timeout: 240 seconds]
<Konsgn>
hmmm. alright then. This yocto based tuild seems to be doing something different.
<zmatt>
oh yeah I don't know anything about yocto, I was assuming rcn's u-boot
thinkfat has joined #beagle
<rcn-ee>
Konsgn, yocto is probally using mainline u-boot.. which really doesn't have a *dtb overide, just rename your version as the dfault..
<zmatt>
that sounds awful
<zmatt>
patching u-boot sounds saner
<rcn-ee>
exactly, i enjoy making u-boot follow our directions..
hays has joined #beagle
<zmatt>
or even just patching a new default dtb into u-boot
<zmatt>
better than risking confusion between the normal am335x-pocketbeagle.dtb and a customized am335x-pocketbeagle.dtb
<Konsgn>
would that script override a declared fdtfile in the uEnv.txt file?
<Konsgn>
I think that would explain what I was seeing
<rcn-ee>
problem is, "run findfdt" is run early and set's fdtfile... however fdtfile would be something you could define in uEnv.txt
thinkfat has quit [Quit: Konversation terminated!]
<Konsgn>
hmm, side question, Can i just put whatever I want in the "compatible" declaration of the root node of the custom dts file instead of ti,pocketbeagle and others?
<zmatt>
Konsgn: typically you'd add a custom entry in front
<zmatt>
in the list
<zmatt>
as usual with compatible-strings they go from most specific to least specific
<Konsgn>
Gotcha, Thank you!.. does it do anything? i understand calling out peripherals to get the right driver, but is that relevant for the root node too?
<zmatt>
not sure what exactly might test the board's compatible-string, but if your board embeds a pocketbeagle or is based on one you'll probably want to keep the existing ones in addition to your custom one
<zmatt>
not afaik no, but like... it there's code that needs to apply some board-specific hack, then it'll probably make that decision based on the root node's compatible-string
<zmatt>
*if there's code
<Konsgn>
Alright, Thank you!
<zmatt>
I personally don't bother overriding the root node's compatible-string
PhotoJim has quit [Ping timeout: 240 seconds]
hays has quit [Ping timeout: 256 seconds]
Angel_Sosa has joined #beagle
<Angel_Sosa>
Does anyone know or have an article I can look at that explains how to do the following in C the actions of config-pin for example config-pin P9_18 spi, config-pin P9_17 spi_cs, config-pin P9_22 spi_sclk.
<zmatt>
it's basically just writing the desired pinmux state to the appropriate sysfs attribute (open() + write() + close())
<zmatt>
with the main annoyance being that the exact path is kernel version dependent
<zmatt>
hence my use of glob
<Angel_Sosa>
Is there a C library that interfaces with the BeagleBone Black like in Python?
<zmatt>
I mean, what I linked isn't a library, it's a tiny snippet of code
<zmatt>
generally speaking I wouldn't recommend replicating the work of config-pin in application code, it's better to just do one-time setup during boot before your application code runs, or use an overlay and avoid the need for runtime pin configuration entirely
<zmatt>
unless you actually need to change pinmux on the fly of course
<SJFriedl>
maybe in a shell wrapper before calling the C program?
<Angel_Sosa>
I am looking to develop a dynamic environment and I do appreciate the heads up but conifig-pin is as an active example of what can be donew from the command line. Python is doing it and Javascript
<zmatt>
okay, if you want to change things dynamically then just rewrite my snippet of python code as C code
<Angel_Sosa>
So I just want to see if there is a C library an actual "C" ecosystem. What is it
<zmatt>
config-pin itself is written in C, but I recall glancing at its source code and being horrified
<SJFriedl>
I've never seen one, I've always just looked at the Python bindings.
<zmatt>
but like I said, replicating its functionality is pretty trivial: just use glob() to locate the appropriate sysfs attribute and then write the desired state to it (simply open(), write(), close())
<Angel_Sosa>
I get what your saying. I am just looking for C examples. I thought conifig-pin bad or not would be an example
<zmatt>
symlinks to the pinmux-helper devices in sysfs are found in /sys/bus/platform/drivers/bone-pinmux-helper/ ... I don't quite remember what kernel-version-dependent variations exist, currently it's e.g. "ocp:P8_03_pinmux" for P8_03
<SJFriedl>
the variations are really maddening.
<zmatt>
I'm honestly not 100% sure whether the name actually varies, it's possible just the path varies and I solved that by using the symlinks in /sys/bus/platform/drivers/bone-pinmux-helper/, and just used the very non-specific glob as extra robustness
hays has joined #beagle
<zmatt>
I probably didn't like hardcoding the ocp: prefix since pimux-helper devices really don't belong inside the ocp node at all, but that's never going to change because of backwards compatibility anyway
<Angel_Sosa>
They are and I know I am asking trivial question but quality up to date information on foundational is pretty poor when it comes to all of the Beagle boards and Bones this group is all I have for information
<zmatt>
yup
<zmatt>
documentation has indeed always been a big problem
<zmatt>
unfortunately
<Angel_Sosa>
To gain the know how I wouldn't mind getting involved in elevating the documentation
<Angel_Sosa>
It just getting to know who to communicate with and whoever they are do they need the want the documentation help
* SJFriedl
and many others would sure be grateful for better doco
<zmatt>
I can't help you with that, I'm also just a random beaglebone user
<Angel_Sosa>
I work with MircoChip and some of the other SBC's and the documentation is not as and I am afraid to say as colloquial
<zmatt>
uhh I can't parse that sentence
<Angel_Sosa>
Zmatt you are very smart and its obvious you have provided tid bits of information for me and thanks
<Angel_Sosa>
colloquial meaning the information is kept local to the person that knows the information. The information is not generally publicly available
<zmatt>
that's not what that word means
<zmatt>
perhaps you meant "confidential" instead, but I still don't know what you were trying to say
<Angel_Sosa>
Information known by one or a group and is local access only. Proprietary to an individual would be the type of application I used for the word. A slang is known to a group or a person so is information is specific in its origin and access
<zmatt>
???
<Angel_Sosa>
That's why this group exists. How else would the experience each of you have would be shared
<zmatt>
oh you're saying that your experience with other SBCs is that people don't really share information?
<zmatt>
(I'm really just guessing here what you're trying to say, I'm having a lot of trouble understanding you)
<Angel_Sosa>
Really never mind. All I was doing today is looking for C code examples I could view? That I can use to program the BeagleBone at a pure "C" level and not have to venture out of the C ecosystem. So let me ask the group and as straight forward as possible again is there a C api available that I can use. If not I will look at Python and Javascript
<Angel_Sosa>
to convert to see.
<Angel_Sosa>
thats to "C" not see
<SJFriedl>
I've never seen one of those libraries but would sure love one.
<SJFriedl>
There just isn't that kind of ecosystem as far as I can tell: it's mostly built around Python or node.js, and even if you found simple pinmux bindings - which seems straightforward enough - you'd still need next-level hardware support
<SJFriedl>
such as talking to an LCD or a temp sensor or a servo driver or whatever. These are commonly provided in Python (Adafruit is very active in this).
<SJFriedl>
Hmm, I'm using Python and Adafruit_BBIO, and when I try to change the I/O mode of P9_12, it works fine as an output, but for input it fails w/ a device-not-found error
<SJFriedl>
P9_12 is GPIO_60, and many other /sys/devices/platform/ocp/ocp:P9_*_pinmux exist, but not P9_12
<zmatt>
/sys/devices/platform/ocp/ocp:*_pinmux is for pin configuration and has nothing to do with gpio
<SJFriedl>
running strace on the code shows that it's involved.
<Konsgn>
.... crap, let me grab popcorn.
florian has quit [Quit: Ex-Chat]
<zmatt>
well that's Adafruit_BBIO's problem :P but normally P9.12 should be reconfigurable though, if it's not then that would suggest the pin is in use by something, such as a cape
<SJFriedl>
Hmm, does this suggest it's used by Bluetooth?
<SJFriedl>
P9.12 30 fast up 7 gpio 1.28 <! P9_12 (pinmux_bt_pins)
<zmatt>
you're using a beaglebone green wireless?
<Konsgn>
yup +1 to making a device tree overlay. outside of being a bit tricky to debug, it's pretty straight forward how to declare to the linux kernel that you are using x pin for y peripheral and have that driver loaded into the devicetree.
<rcn-ee>
looks like green wireless..
<SJFriedl>
yes that's me.
<SJFriedl>
I haven't yet disabled Bluetooth like I usually do on this one.
<rcn-ee>
SJFriedl, just remove the BLE firmware.. it wont' work. ;)
<zmatt>
oh never mind, bluetooth does use pins
<zmatt>
basically the same ones as hdmi audio on the BBB (+ one more pin, P9.30)
<SJFriedl>
is there any reason I would prefer the BBGW instead of BBBW ? Only thing I care about is wifi.
<SJFriedl>
these are for small industrial control purposes but I don't use them quite enough to get really good at them.
<rcn-ee>
The BBBW came out mostly because of the pin messup of BBGW...
<zmatt>
my advice on the BBGW would generally be: don't
<SJFriedl>
that's super helpful information; I'll order a bunch of them so I have them in stock.
<SJFriedl>
and thankfully Mouser has them in stock.
<rcn-ee>
the bbgw also has the mcsasp wired to the ble... so in theory (it was shown to work once) ble audio...
<SJFriedl>
Understand some need that, I don't.
<rcn-ee>
no one's needed it. ;)
<zmatt>
you can use software decoding as alternative anyway
<zmatt>
SJFriedl: anyway, if you install the green-wireless version of my show-pins script, it'll mention BBGW-specific pin usage in the description column
<zmatt>
the only thing worse than no documentation is wrong documentation
<SJFriedl>
I need to either do this *more* (where I'd get good at it) or *less* (where I wouldn't trip over these kinds of things) :-)
<zmatt>
rcn-ee: it's not correct though, P8.14 (wifi enable) and P9.12 (bluetooth enable) are in use whenever the level shifter is enabled, regardless of whether you have any need for wifi or bluetooth respectively
<zmatt>
the only way to recover them is by deasserting the I/O enable (P8.26)
<zmatt>
(which obviously means losing both wifi and bluetooth)
<zmatt>
and P9.30 is part of the audio interface (if it's declared as gpio, that's a DT mistake)
<SJFriedl>
should I be concerned that the current that the latest IoT image is almost two years old?
<zmatt>
"capabilities does not survive tar" ... that's what I meant with missing the right flags
<zmatt>
for tarring a rootfs I use --numeric-owner --acls --xattrs
<rcn-ee>
image is tar'ed by: sudo tar cvf ${export_filename}.tar ./${export_filename}
<zmatt>
for untar I use --numeric-owner --acls --xattrs-include='*'
<rcn-ee>
for untar: tar --numeric-owner --preserve-permissions --verbose -xf "${DIR}/${ROOTFS}" -C ${TEMPDIR}/disk/
<zmatt>
that indeed does not suffice for ping to survive intact
<zmatt>
it's not the only thing either tohugh
<zmatt>
*though
<SJFriedl>
wow, no kidding BBGW uses a lot of the I/O pin. I'd have had a miserable time.
<SJFriedl>
thank you
<zmatt>
SJFriedl: yep, and totally unnecessary... the pins that are freed up by removing ethernet contains _exactly_ the functionality needed for the wifi/bluetooth chip
<zmatt>
but they left those unused (and unusable for other purposes) while pointlessly stealing a whole bunch of expansion header pins
<SJFriedl>
That seems obvious enough that *I* could have figured that out, and I'm an amateur.
<SJFriedl>
maybe they were thinking "We'll eventually add in Ethernet as well"?
<zmatt>
rcn-ee: the fact that specifying --xattrs when untarring is not sufficient to actually preserve capabilities is highly non-obvious, it's something I ran into too
<zmatt>
SJFriedl: no they used a few of the pins
<SJFriedl>
ugh. so just bad design with no "I guess I can see their point" factor?
<zmatt>
correct
<SJFriedl>
ugh.
<zmatt>
rcn-ee: I didn't include --preserve-permissions since it's the default for root
<zmatt>
and I used --numeric-owner to avoid any risks of mismatching uids/gids between the host and target systems
<zmatt>
though that depends on how the rootfs is made I guess
<balrog>
Hey! Is there a reason the Bullseye images don't have CONFIG_UIO_PRUSS set?
<balrog>
I'm trying to run some older code and don't want to port it to rproc, which seems to be quite a pain
<zmatt>
the trivial changes needed to make uio-pruss work probably haven't been forward-ported yet
<zmatt>
the mainline uio-pruss doesn't include am335x support
<balrog>
ahhh. :(
<zmatt>
I've been meaning to look at this, but haven't gotten around to it
<balrog>
Which image should I be running then? I'm running into that CDC-ECM issue on macOS (which I don't believe is intentional breakage on the part of Apple, so I filed a feedback under FB9848616)
<zmatt>
(since imho uio is superior to remoteproc)
<zmatt>
the latest buster-testing image presumably fixes that
<zmatt>
or you can use bullseye with a 4.19-ti kernel
<balrog>
I think I got most of the code converted to clpru, but now I have to figure out how to use the linker. There isn't as much documentation as I wish... the TI stuff isn't the most user friendly
<balrog>
I'm fine running buster-testing;
<balrog>
but... where should I be getting the image from?
<zmatt>
rcn-ee: what do you recommend for buster? (with cdc-ncm instead of cdc-ecm)
<balrog>
(re the cdc-ecm problem, feel free to file another bug with Apple, more duplicate bugs helps)
<balrog>
(I can see that the Apple driver loads but then crashes for some reason)
<zmatt>
balrog: of course connecting via ethernet would dodge the issue
<balrog>
zmatt: yeah I'm doing that anyway, but I don't like running an image *that* old :)
<zmatt>
like I said, you can also just downgrade the kernel on bullseye
<balrog>
I'll try that first :)
<zmatt>
I'm actually running bullseye with a 4.14 kernel on our development beaglebone since I haven't gotten around to forward-porting our kernel patches
<balrog>
which kernel package is the right one?
<balrog>
bbb.io-kernel-4.19-ti or bbb.io-kernel-4.19-ti-am335x?
<zmatt>
I'm unfamiliar with rcn's kernel metapackages, they're quite new
<zmatt>
looks like they pull in the same kernel but the -am335x one has additional 'Recommends' dependencies on the sgx modules and u-boot
set_ has quit [Ping timeout: 256 seconds]
<balrog>
hmm do I need to get anything special to get /dev/uio stuff to show up?
<rcn-ee>
zmatt, Mac doesn't like ecm anymore, everything should be ncm on usb1..
<zmatt>
rcn-ee: yes I know, that's why I asked
<zmatt>
I think ecm is still default on the released image
<balrog>
rcn-ee: yeah I know, I'm saying I think it's an Apple bug so I reported it, I can see the driver attempting to load and crashing in the Mac logs
<rcn-ee>
so we changed the default 2 years ago...
<balrog>
rcn-ee: I also filed a separate bug report asking Apple to implement RNDIS, but I'm not holding my breath
<zmatt>
they're not going to, RNDIS is microsoft-proprietary
<zmatt>
just like microsoft is probably never going to care about or implement actual standards
<rcn-ee>
Apr 9, 2020 that was our change... any image before that assumes ecm... everything after is ncm..
<balrog>
It is and it isn't — Microsoft has documented it rather well. It's a huge annoyance because many Android phones only support RNDIS and don't support ECM/NCM for tethering, so people end up using HoRNDIS which at this point I want to kill off
<balrog>
(I helped maintain it for a bit)
<zmatt>
balrog: anyway, uio-pruss needs to be enabled through an overlay in /boot/uEnv.txt
<balrog>
(I could port it to a Driver Extension but I don't want to)
<balrog>
zmatt: does the overlay have to be before the cmdline?
<zmatt>
cmdline has nothing to do with overlays
<rcn-ee>
balrog, on older images, just do: cd /opt/scripts/ ; git pull
<balrog>
only asking because I had already added it at the end of the uEnv.txt and it didn't seem to have any effect
<rcn-ee>
that'll update the ecm -> ncm change over... today it's ncm by default.
<rcn-ee>
So u-boot on eMMC might be breaking it... remove the "spaces" in uboot_overlay_pru = /lib/firmware/AM335X-PRU-UIO-00A0.dtbo not sure how smart u-boot is..
<rcn-ee>
you can update u-boot on the emmc via: sudo /opt/u-boot/bb-u-boot-am335x-evm/install.sh
<zmatt>
or just wipe eMMC with sudo blkdiscard /dev/mmcblk1
<zmatt>
if there's nothing on it you care about
<balrog>
I had previously flashed the board with another image, hmm lemme check
<balrog>
I think it used to be there as `am335x-pru-package`
<rcn-ee>
the old am335x_pru_package was a very old fork of ti's project..
<balrog>
ah...
<balrog>
rcn-ee: that thing seems to be remoteproc based
<zmatt>
rcn-ee: the pru support package is just for clpru and remoteproc
<balrog>
the old am335x-pru-package is meant for uio
<rcn-ee>
exactly... 6.0.1 is rproc only (5.10.x-ti) and 5.9.x seems work form v4.14-ti -> 5.4.x-ti..
<balrog>
is capemgr dead?
<zmatt>
replaced by u-boot overlays and cape autodetection in u-boot
<balrog>
got it
<rcn-ee>
balrog, it's not 100% dead... they are still discusising it mainline..
<rcn-ee>
probally for another 10 years...
<zmatt>
honestly, clpru and remoteproc are kinda dumb, the PRU architecture was never designed to be targeted by a C compiler, and using C/C++ or using remoteproc's rpmsg mechanism destroys the deterministic timing which is PRU's key asset
<balrog>
yep
<rcn-ee>
At this point, the best supported "capemgr" is in Renesa's ARM mainline tree, he's still actively using it.. and has time to suport it. ;)
<balrog>
(I'm not familiar with rpmsg)
<balrog>
(but I get the C/C++ part. It would only work with heavy inline asm, and do they even support that?)
<zmatt>
balrog: rpmsg is basically a kind of socket interface implemented using an extremely convoluted ringbuffer system in DDR3 memory
<balrog>
*WHY*
<zmatt>
inline asm doesn't really help, you'd need to put the timing-critical parts entirely in separate asm code... and that's generally most of the code anyway
<zmatt>
but I'll be fair, there are some use-cases where C/C++ is fine
<zmatt>
like, if people need stuff done "within a few microseconds" or something, something that's so trivial for PRU that you can afford to waste undefined amount of time, yet which are too timing-critical for linux userspace
<zmatt>
and "WHY" is the only correct reaction to rpmsg
<zmatt>
it's an abomination
<zmatt>
I looked into how it works because I thought about implementing it in py-uio just for fun and to be able to run most if not all code designed for remoteproc-pru via uio-pruss instead
<zmatt>
but after seeing how it works, I realized I was a happier person back when I didn't know
mag has quit [Remote host closed the connection]
mag has joined #beagle
<balrog>
how do you load an extra dtbo overlay without capemgr
<balrog>
?
<zmatt>
via one of uboot_overlay_addr4..7 or dtb_overlay ... they're all equivalent but each only accepts one overlay path (I'm not sure why there isn't simply one variable that accepts a list of overlays)
<balrog>
but it does require a reboot?
<zmatt>
yes, runtime loading of overlays is theoretically still supported but it has always been buggy and is deprecated
<balrog>
aha, got it
<zmatt>
basically, there's too much kernel code that was never designed to cope with the DT changing at runtime
<rcn-ee>
balrog, dtb_overlay was the first variable name i came up with when starting on u-boot overlays, it only exists as i told users to try it.. it's still enabled..
<rcn-ee>
in the order of execution, it's the last one to load..
jfsimon1981 has quit [Ping timeout: 240 seconds]
<balrog>
rcn-ee: got it :)
<balrog>
can you set up gpio direction in an overlay?
<zmatt>
you'd need to make sure cape-universal is disabled however
<zmatt>
since there's currently no way to disable individual gpios of cape-universal's gpio-of-helper device
<zmatt>
or wait... did I write a patch for that? rcn-ee?
vagrantc has joined #beagle
<zmatt>
yeah I did write a 2-line patch for that, and rcn-ee merged it
<zmatt>
balrog: so with a sufficiently recent kernel it's possible to declare your own gpio-of-helper without being forced to disable cape-universal entirely, you can disable individual gpios in cape-universal
vagrantc has quit [Quit: leaving]
<zmatt>
e.g. &ocp { cape-universal { P8_03 { status = "disabled"; }; }; };
thinkfat has joined #beagle
vagrantc has joined #beagle
<balrog>
zmatt: how recent?
<balrog>
like, would a "stable" image be recent enough?
<zmatt>
if you update the kernel to the latest within its series (4.19-ti for current stable images except TIDL images)
<zmatt>
exclusive-use is metadata for the overlay manager, and actually ignored by u-boot overlays
<balrog>
ahhhh!
<balrog>
yeah, these overlays were meant to be run by the overlay manager, but that means it's stuck on an ancient kernel and image
<zmatt>
all properties at the top level (/) of an overlay are purely metadata
<zmatt>
also, that overlay is broken
<zmatt>
it has multiple references to the same pinmux node
<balrog>
is there an overlay validator?
<zmatt>
that would be nice, wouldn't it
<balrog>
yeah...
<zmatt>
given how simple this overlay is, you may want to consider rewriting it using my overlay-utils... using macros instead of magic hex constants will make things a lot more readable
<zmatt>
plus the overall structure/syntax is nicer
<balrog>
yeah, I agree
<balrog>
this thing is really the sort of project where it works so no one's touching it
<zmatt>
no fragment@N or __overlay__ nodes
nparafe has quit [Ping timeout: 240 seconds]
<balrog>
(the "thing" itself is a board that emulates or reads a vintage MFM hard drive)
<balrog>
one reason I asked about pasm being packaged... is that it *is* BSD-licensed open source, while the "newer" TI compiler is not
<zmatt>
note btw that the IN and OUT in the pinmux block is misleading... pinmux nodes have no influence over direction, that's controlled by the peripheral to which the pin is muxed
<zmatt>
what it actually sets is whether the input receiver is enabled or disabled... if disabled the pin will always appear to be low
<zmatt>
(as far as I know there's no reason to disable the receiver other than a miniscule amount of power saving, hence the macros in overlay-utils always simply enable the receiver)
thinkfat has quit [Quit: Konversation terminated!]
thinkfat has joined #beagle
nparafe has joined #beagle
lucascastro has quit [Ping timeout: 256 seconds]
<balrog>
zmatt: got it, I'll keep you updated :)
PhotoJim has joined #beagle
otisolsen70 has quit [Quit: Leaving]
jfsimon1981 has joined #beagle
<balrog>
zmatt: does the state of the receiver affect the pin impedance?