**** BEGIN LOGGING AT Wed Feb 28 03:00:02 2018 Feb 28 05:58:41 I have a stupid question, are there any updated drivers for the beaglebone black? The digital signatures on the drivers are expired and will not install Feb 28 06:05:07 latest images don't need drivers on windows 10 Feb 28 06:05:30 but you didn't care enough to stick around to get an answer Feb 28 06:06:50 (or rather, windows 10 simply understands to use its own drivers if you get the usb descriptors right, instead of requiring a signed ini file telling windows to use its own drivers) Feb 28 07:33:14 Morning folks. I'm looking to report a bug about the default uEnv.txt / universal cape overlay in the default Debian IoT image, but I can't quite find what the appropriate place for that is. I found https://github.com/beagleboard/image-builder but I couldn't find the right uEnv.txt in there. I found https://github.com/cdsteinkuehler/beaglebone-universal-io/ but it seems the dt overlays in there are not the Feb 28 07:33:16 same ones shipped in the image. Any suggestions? Feb 28 07:34:18 As for the actual issue I want to report: It seems confusing that the universal cape overlay enables the SPI hardware, but does not set up the pins to output, since this makes /dev/spidev.* available, but they do not actually work... Feb 28 08:22:56 hello Feb 28 08:23:55 BBB with LCD4 cape: where can i find the definition of the GPIO used as keyboard keys, and how can i change the emulated keycodes? Feb 28 08:25:55 parduz: I *think* they are defined in the device-tree overlay loaded for that cape. And I *think* the source for the default one might be here: https://github.com/RobertCNelson/bb.org-overlays/blob/master/src/arm/BB-BONE-LCD4-01-00A1.dts Feb 28 08:26:04 blathijs: cape-universal enables most peripherals, you select pin functionality at runtime using the config-pin utility Feb 28 08:26:13 that's the whole concept of cape-universal Feb 28 08:27:09 the peripherals themselves are unaware of the pinmux, so they show up in /dev/ regardless of whether they're usable Feb 28 08:27:15 zmatt: I understand *how* it works now (after spending a day debugging to figure out why SPI didn't work anymore), I'm just saying the defaults are confusing and might need to be reconsidered... Feb 28 08:27:27 everything defaults to gpio Feb 28 08:27:32 I don't have an easy solution, though. Feb 28 08:27:34 that's not going to change Feb 28 08:28:41 blathijs, I'm not sure what the lcd4 is but I have an lcd made by 4d systems that fits on the bbb Feb 28 08:29:00 you should be aware that one of the spi mosi pins is used as a button Feb 28 08:29:12 Ideally, opening the spi device would configure the pins, but I guess the kernel doesn't support that. Feb 28 08:29:23 p9.30 Feb 28 08:29:46 blathijs: it doesn't, and moreover quite a few peripherals can be mapped to different pins. how would it choose? Feb 28 08:29:49 mattvenn_: Ah, thanks. My BBB is in a case without access to the buttons, so that has not been a problem so far. Feb 28 08:30:10 zmatt: Good point. Feb 28 08:30:19 blathijs: I think mattvenn_ just confused you with parduz Feb 28 08:30:33 but the button has a pullup and extra wiring. the mosi signall will be distorted at clock frequencies above 5mhz (In my experience) Feb 28 08:30:47 woops, sorry! Feb 28 08:30:52 since you were talking about spi, and parduz has a cape with buttons Feb 28 08:31:14 Ah, I thought mattvenn_ meant a button on the BB itself :-) Feb 28 08:32:04 just ignore me Feb 28 08:32:06 lol Feb 28 08:32:21 no. the only one of those that can interfere with signals is S2 (the boot mode button), it pulls P8.43 down to ground via a 100 ohm resistor (but that's not where any spi functionality lives) Feb 28 08:32:34 ok, let me be more detailed Feb 28 08:32:37 As for the universal cape, I could imagine it being disabled by default, so anyone who wants to use it enables it in uEnv.txt and can be exposed to proper caveats about how hardware is enabled without setting up the pins for it. Feb 28 08:32:52 Might not be as convenient for users, though. Feb 28 08:33:04 blathijs: I don't like cape-universal either, but in practice it's user-friendlier than previous solutions Feb 28 08:33:29 Another approach could be to improve documentation about this, though I'm not sure what the canoncial place for that would be... Feb 28 08:33:41 we're building our own cape, starting by emulating the 4dSystem LCD cape and then changing it for our purpose.... Feb 28 08:34:06 (it will be not a general purpose LCD cape) Feb 28 08:34:10 I'd still be strongly in favor of some gui tool to configure the various functionality and produce a device tree for it Feb 28 08:35:43 we'd like to use what was defined as keys for the LCDcape as "events" in our GUI app. Having them as keyboard, we thought that it could be easier to change the keycodes insted of using something different and "build" the whole event mechanism Feb 28 08:36:21 I think when using gpio-keys you can configure the keycodes? Feb 28 08:37:00 yup, https://github.com/RobertCNelson/bb.org-overlays/blob/master/src/arm/BB-BONE-LCD4-01-00A1.dts#L207-L254 Feb 28 08:37:39 okay did that links paste okay? irssi seems to be glitching up for me or something Feb 28 08:37:51 seems ok to me Feb 28 08:37:51 wtf Feb 28 08:38:02 yeah it's some sort of weird redraw glitch it seems Feb 28 08:38:23 so weird Feb 28 08:39:02 BRB Feb 28 08:39:30 ok, now it's a little quieter I'd like to continue on the whole cape thing Feb 28 08:40:08 that link that zmatt pasted , I found I couldn't use along with spi, because the spi mosi pin was used by one of the buttons Feb 28 08:40:14 zmatt: If I wanted to share my experience about the universal-cape and SPI in order to spark discussion, any suggestions for a mailing list of bug tracker that would be appropriate? Or does it not seem worth the trouble? Feb 28 08:40:38 blathijs: you're simply saying "I don't like how cape-universal works" Feb 28 08:40:49 I don't think there's much valuable feedback in it Feb 28 08:43:03 blathijs, I've also had a lot of confusion and difficulty with the system Feb 28 08:43:14 zmatt: I'm mostly thinking there is a documentation problem here, though I can't really point out a good place to fix it... Feb 28 08:43:25 documentation is a problem in general Feb 28 08:44:21 there isn't enough of it, it seems scattered, it's often out of date, etc Feb 28 08:44:40 write a clear process of how you got your setup working and post it to the google group with a lot of easy to search tags in the subject Feb 28 08:44:43 ? Feb 28 08:44:54 at least other people will be able to easily find it then Feb 28 08:45:10 mattvenn_: that's not documentation Feb 28 08:45:16 I know Feb 28 08:45:32 if you search, you'll find tons of info... much of it wrong or outdated Feb 28 08:45:35 but better than doing all that work and then shearing it Feb 28 08:45:39 not sharing it Feb 28 08:45:45 adding more to the pile isn't necessarily helpful in the long run Feb 28 08:45:57 I mean, I guess it's better to have it than not Feb 28 08:46:17 zmatt: In practice, it does work like that, since it shows up when you google for docs (and it's timestamped, which helps to determine the accurateness of it) Feb 28 08:46:17 but it's not a substitute for authoritive and uptodate docs Feb 28 08:46:17 one thing I got burnt on early on wasa how fast the documentation / examples go out of date Feb 28 08:46:28 zmatt: But indeed, proper docs would be better... Feb 28 08:48:23 going back to the 4d cape and spi issue I had - what is the best way to fix this as of now? Feb 28 08:48:48 I made my own dts by removing the offending pin from the lcd dts and then loaded both that and the spi Feb 28 08:48:59 oh and spi has to be loaded at boot for it to work I recall Feb 28 08:50:30 mattvenn_: uhh, so you basically have a customized cape where you remove that button and use an (otherwise conflicting) spi bus instead? Feb 28 08:50:48 customize the overlay to reflect these changes Feb 28 08:51:21 yes the cape managed to interfere with both spi ports, so I had to pick the one with least interfeance and modify the cape and dts Feb 28 08:51:57 I just want to know that this is the 'correct' way of solving it, or if I missed something Feb 28 08:52:05 mattvenn_: Are you offering help to parduz? If so, I don't think he said he's using SPI, that was only me. Though if parduz is going to build his own cape, then it might be good advice to pick different pins without conflicts :-) Feb 28 08:52:23 (if you really want to be slick, change the cape's identification eeprom to reflect that it's customized, and name your customized overlay accordingly. then the correct overlay will be automatically loaded for your customized CAPE while retaining normal functionality on unpatched lcd capes) Feb 28 08:52:25 no, it's a question about how I solved my own issue Feb 28 08:52:41 mattvenn_: Ok :-) Feb 28 08:52:59 mattvenn_: the device tree (overlay, in case of capes) describes the hardware Feb 28 08:53:10 if you change the hardware, changing the device tree is the correct thing to do Feb 28 08:53:27 ok thanks Feb 28 08:53:54 another question - why does spi have to be loaded at boot by modifying uEnv, rather than loaded at run time as a dts? Feb 28 08:55:01 (and like I said, the way CAPEs are supposed to work is that they can be recognized based on their eeprom, so a customized cape *ought* to have different identification... you may or may not care) Feb 28 08:55:25 loading overlays at runtime is buggy and has limitations, it's also deprecated and no longer used at all in current images Feb 28 08:55:46 overlays are now loaded by u-boot and applied to the device tree before it's passed to the kernel Feb 28 08:57:05 so the whole cat $SLOTS and echo 'my-dts' > $SLOTS is gone? Feb 28 08:57:12 that never worked well for me Feb 28 08:57:18 yep Feb 28 08:57:40 ok, so you have to reboot every time you make a change to the dts but pretty much you had to anyway ;) Feb 28 08:57:58 ok cool, that is clearer for me now, thanks Feb 28 08:58:30 hehehe, unloading an overlay was already a great way to get a kernel panic Feb 28 08:58:40 yeah Feb 28 08:59:11 it gave me a bad impression of the board at the start Feb 28 08:59:59 runtime overlays have always been really hacky... making runtime changes to the DT simply violated assumptions made by kernel and drivers all over the place afaik Feb 28 09:00:40 I remember thinking - why is this so hard - it all just works on the raspberry pi. But then I found that the rpi had the same system but hard coded Feb 28 09:00:55 and all these big arm chips have basically the same issue - tons of functionality and limited pins Feb 28 09:01:00 how do you configure pinmux on the rpi? Feb 28 09:01:17 well it's all the same now I think - you have a dts that gets loaded at boot Feb 28 09:01:27 With overlays, too Feb 28 09:01:42 there is an equivalent of uEnv called config.txt I think Feb 28 09:01:53 not sure if it uses uboot Feb 28 09:02:27 there was that funny post by Linus Torvalds about the state of the pinmuxing on ARM Feb 28 09:02:31 Looks like it either uses u-boot, or something that does the same as u-boot with overlays Feb 28 09:02:36 well that's basically where the bbb seems to be headed, with config options to toggle various chunks of functionality Feb 28 09:02:43 but the bbb has tons more i/o and peripherals than the rpi Feb 28 09:02:57 ohh, have a link? Feb 28 09:03:49 Can you pass arguments to overlays using u-boot? That's what RPI can do in config.txt, which allows more flexible overlay definitions. Feb 28 09:04:21 http://thread.gmane.org/gmane.linux.ports.arm.kernel/113895 Feb 28 09:04:26 pass arguments to overlays? what? Feb 28 09:04:34 how would that even work? Feb 28 09:05:52 zmatt: https://www.raspberrypi.org/documentation/configuration/device-tree.md#part2.2 and https://www.raspberrypi.org/documentation/configuration/device-tree.md#part3.2 Feb 28 09:07:45 o.O Feb 28 09:07:47 okay then Feb 28 09:08:12 let's make overlays even uglier and harder to than they already are Feb 28 09:08:34 I suspect this __overrides__ thing in the DTS might be a RPI-specific kernel patch, not usre Feb 28 09:09:12 not kernel, they also combine overlays into the DT before passing it to the kernel Feb 28 09:09:32 I really don't understand this whole messy scheme... just make a nice generator tool that turns config file into DT Feb 28 09:11:00 +1 Feb 28 09:11:17 instead of having, effectively, a really awkward and limited generator tool for the DT execute at boot before the kernel Feb 28 09:11:34 Well, this parameter thing does seem friendly to me. You can specify e.g. dtoverlay=gpio-ir,gpio-pin=123 to set up an IR receiver attached to a specific gpio. Feb 28 09:11:41 i am encounturing errors while installing bone d64 in windows Feb 28 09:11:45 and being able to take a dts and load it into the tool that would set all the options as they are for that specific dts Feb 28 09:12:23 blathijs: using a config-tool would allow that too, and better Feb 28 09:12:42 e.g. interactively inspect and configure the config parameters Feb 28 09:12:42 zmatt: But yeah, having a proper offline DT generator also seems reasonable. It might still effectively need the same code that the rpi has now, to define and apply options, though. Feb 28 09:13:06 In internet it is given that due to secure boot these error are occuring. I dont know how to disable this secure boot Feb 28 09:13:09 I am new to BBB Feb 28 09:13:52 aitha: I'm not sure what you're saying, but if you're talking about windows drivers, then you don't need any if you're using windows 10 and there's sufficiently recent software flashed onto the BBB Feb 28 09:13:53 zmatt: OTOH, you could probably use a proper templating solution for variables, instead of resorting to the clunky and limited DT-approach Feb 28 09:14:16 blathijs: exactly Feb 28 09:15:58 You would still need something for plug-and-play like the current cape detection thing, though the current mechanism of loading an overlay for each cape probably suffices. If you want to customize options for your cape, generate an overlay for it using the tool. Feb 28 09:17:11 you can do that in userspace and reboot after auto-reconfiguring. the only thing you may want to have in u-boot is a quick check that specific cape(s) are still installed, and if not then go back to a "safe" dt and let userspace deal with the changes Feb 28 09:17:12 zmatt: I am talking about 64 bit installer which need to be installed in pc for conecting to BBB. While installing this i am encoutering errors Feb 28 09:17:46 zmatt: Ah, good point :-) Feb 28 09:17:52 aitha: What windows version do you have? Feb 28 09:18:21 zmatt: On an related note: When looking through the uboot config earlier, I was a bit worried about the amount of stuff that is hardcoded inside u-boot.img, especially considering that when booting from SD, the u-boot from the EMMC seems to be used. Wouldn't it be better of u-boot on the EMMC would start u-boot on the SD instead of starting the kernel directly? Or is that harder than it sounds? Feb 28 09:19:56 I agree, and I don't think it would be very hard Feb 28 09:20:21 blathijs : i am using windoes 10 Feb 28 09:21:29 you'd just need some detection logic whether a bootable sd card is present. if so, you can change the sysboot register and jump back into bootrom to let it proceed as if you held down the S2 button during power up (except software changes to the sysboot register are undone when resetting) Feb 28 09:22:03 aitha: Then you should not need those drivers, if you use a recent firmware image on the BB Feb 28 09:23:11 how to know whether recent firmware image is on BB?? Feb 28 09:23:20 zmatt: Except that booting with the button pressed also boots from other sources (SPI IIRC?) Feb 28 09:24:06 aitha: Updating to the current Debian Stretch image would be a sure way. Not sure how to check the current version. Feb 28 09:25:30 blathijs: well you don't have to exactly simulate pressing the S2 button... switching to boot mode 0b10111 would make the boot device order { sd, spi, uart, usb } Feb 28 09:25:47 there Feb 28 09:26:50 there's no easy way to change the boot mode from 11100 to 10111 with a single pushbutton in hardware, which is why the sd button selects mode 11000 instead (boot order spi, sd, usb, uart), but software changes to sysboot obviously aren't bound to such restrictions Feb 28 09:27:31 zmatt: Ah, I thought you meant there was a "S2-is-pressed" bit, but this sounds more flexible :-) Feb 28 09:29:43 S2 pulls the sysboot2 pin to ground (it normally has a pull-up). sysboot0-15 are latched at power-on and these latched values are loaded into a register at reset. bootrom inspects this register to know, among other things, which boot device list to use Feb 28 09:29:54 that register can be modified by software Feb 28 09:30:15 hence change what bootrom will do when you reexecute it Feb 28 09:30:35 Makes sense. Slowly I'm puzzling together how this stuff works on the BB :-p Feb 28 09:31:28 it's much more flexible on the OMAPs Feb 28 09:32:05 there software can leave a custom boot device list (and other stuff) in internal RAM, which overrides the default behaviour and even persists across warm reset Feb 28 09:41:42 zmatt: Fun stuff :-) Feb 28 09:42:13 sorry guys, got a call from Karawang (i don't even know where that place it). I've read all your message but i'm still lost. Feb 28 09:43:20 do changing that code linked let me change the keycodes send to the system when the input is ON? Feb 28 09:43:52 parduz: I believe you will need a custom device-tree overlay, based on the one linked by zmatt, which tells the kernel what gpios to configure and how to map them to keys Feb 28 09:44:26 (or just custom device-tree rather than an overlay) Feb 28 09:45:41 ok, so my cape have to identify as something different than the LCDCape, so that my device-tree will be "loaded", right? Feb 28 09:45:48 parduz: To install the changed overlay (probably using a different name), you will need to compile it using the device-tree-compiler package, dump it in /lib/firmware, possibly update initramfs (but I think this is no longer needed with u-boot overlays), and then update uEnv.txt to load the overlay. Feb 28 09:46:01 parduz: or you can override it in /boot/uEnv.txt Feb 28 09:46:17 parduz: Or instead of updating uEnv, you can use the eeprom identification and name your overlay appropriately so it gets loaded Feb 28 09:47:10 blathijs: yep, that's what i meant in my last message. Ok. Feb 28 09:48:16 for in-house application, either can be fine Feb 28 09:50:04 we will sell the BBB+OutCape as a single "closed" product, so i guess we have some freedom of choice wthout having to be "formal" about generic capes Feb 28 09:50:14 *OurCape* Feb 28 09:50:22 exactly Feb 28 09:51:04 it's the same with us, the "cape" is typically actually the mainboard of a product and the bbb plugs onto it Feb 28 09:51:42 we don't use cape identification at all, in fact we frequently reuse P9.19/P9.20 for other purposes Feb 28 09:52:36 If you don't use hotplugging, then you probably want to statically configure things (though I'd think that an overlay, statically loaded from uEnv.txt, might be better than a complete devicetree, since that is easier to manage and update?) Feb 28 09:53:08 that's up to preference. I've been using custom dts for a long time now Feb 28 09:54:49 Understood. We're not so fond on linux and embedded stuffs (right now the thing closer to a BBB we used is a ZWorld Rabbit board) Feb 28 09:55:21 well, baremetal programming is fun too :) Feb 28 09:55:41 So, as we need a Touchscreen, the fastest way seemed to start from the LCD Cape and then start changing it Feb 28 09:56:50 right now we have a ATmega emulating the eeprom and managing a multiplexed little keyboard Feb 28 09:56:56 or grab a hdmi display with usb touch sensor Feb 28 09:57:43 emulate the eeprom? but why? Feb 28 09:58:17 'cause with a single "chip" we can do the whole "OurCape" Feb 28 09:58:46 oh and you hadn't realized yet that you don't actually need an eeprom at all Feb 28 09:59:15 (since you can force an overlay to be loaded in /boot/uEnv.txt) Feb 28 09:59:48 via i2c i read/write at an address and i get the hardware keys, and toggle leds, Feb 28 10:00:22 that is something we did'nt know, in fact Feb 28 10:00:34 not enough gpios available for keys/leds ? Feb 28 10:01:38 note btw that some led triggers don't work for leds connected via i2c instead of gpio (e.g. 'cpu0' and 'panic') Feb 28 10:01:59 the BBB will run a GUI app that basicalli ask via serial to a device realtime data and graph it.... we dont want to manage multiplexing and polling hardware Feb 28 10:03:20 anyway, i'm a programmer.... not all hardware choice depends by me ;) Feb 28 10:03:47 and we have some old-school boss, here :D Feb 28 10:04:07 ah you have a keyboard scan matrix, yes okay then it makes sense to do it via i2c (and use an interrupt line to avoid having to poll it). there is a kernel driver for handling a key matrix via gpios, but I don't know how efficient it is Feb 28 10:04:53 (in theory it shouldn't have to poll when no keys are being pressed) Feb 28 10:05:08 (I think?) Feb 28 10:05:48 well, that's another question: how can i get an "interrupt" (i'd call it an "event") in my GUI app from "the system" when an input is detected? Feb 28 10:06:15 uhh, you'd get a key event? Feb 28 10:06:32 the details depend on what gui toolkit you use Feb 28 10:07:34 i'd stay more generic than key event. My question is: can i get an event from an input? I'm using c++ + wxWidgets Feb 28 10:09:06 well if you're using an i2c keyboard matrix controller then its kernel driver would produce key events Feb 28 10:09:55 sorry, zmatt, i'm not clear enough (and english is not my language): Feb 28 10:11:08 but if you're doing the i2c transactions from userspace (since apparently you're using some custom protocol over i2c), and you want events on its irq line, you can get events on gpios via sysfs and an fd polling mechanism of your choice Feb 28 10:11:48 you set the 'edge' attribute of the gpio to 'rising', 'falling', or 'both' Feb 28 10:14:12 wait (and sorry): Feb 28 10:14:56 you're telling me that i could get event from the i2c lines without being "master" (so polling the keyboard matrix)? Feb 28 10:16:20 you'd use a separate interrupt line so the keyboard matrix scanner (your ATmega I presume?) can notify the beaglebone when there's an event Feb 28 10:16:34 and then have the beaglebone read the event via i2c Feb 28 10:17:12 ok. So an output from the ATmega to the BBB will call the event, and then my app will read the data via i2c Feb 28 10:17:34 understood Feb 28 10:17:49 so, is the ATmega just for the keyboard events? (if we ignore the unnecessary eeprom functionality) Feb 28 10:18:22 and managing some leds Feb 28 10:19:06 since if you use an off-the-shelf i2c keyboard scanner which has a linux driver, or simulate the behaviour of one, you can just let the kernel deal with all the low level stuff Feb 28 10:19:13 why not gpios for leds? too many? Feb 28 10:20:04 although there too, if you behave like a standard i2c gpio expander then the kernel can treat those pretty much the same as normal gpios Feb 28 10:21:47 we have 4 leds, which have to blink, or pulse. The main concern was not "stealing" time from the app, that HAVE TO BE FAST as it can. Feb 28 10:22:17 well are you concerned by the blinking of the other four leds on the beaglebone? Feb 28 10:22:35 lol Feb 28 10:22:53 we (they) take them as "mandatory", i guess. Feb 28 10:23:22 that's a serious question, since if you connect your leds to gpios and use the 'gpio-leds' driver then your four leds are indistinguishable from the four on the beaglebone Feb 28 10:24:04 but there's no led trigger for very fancy blinking patterns or such I think, just 'timer' which has an on-time and an off-time Feb 28 10:24:52 doing an i2c transfer on the other hand is sloooooooow Feb 28 10:25:26 ok, let we live with that we have right now :) .... we're still prototyping, so i guess we could step back when we're more expert... Feb 28 10:26:06 i'm really eager to learn how to get the interrupts from the inputs Feb 28 10:26:39 i've read your message about sysfs and fd polling but i have to google and learn what it means Feb 28 10:27:04 or listen to you if you have time to waste with me :D Feb 28 10:27:10 well just keep in mind that if you change the hardware to something saner then the effort you're putting into this weird custom stuff via i2c in userspace will be wasted :) Feb 28 10:28:04 no problem, i2c communication has been the easiest thing i stumbled on the BB. Feb 28 10:28:55 sure... I guess the effort has already been expended (e.g. programming that ATmega) Feb 28 10:29:12 although you'll also need to inject your key events into your gui framework I'm guessing Feb 28 10:29:25 since you'll be getting those keys via i2c instead of the kernel just sending key events Feb 28 10:29:34 (via i2c in userspace I mean) Feb 28 10:31:18 mh.... what i would like to do is: 1) Get an event (interrupt) from the ATmega 2) ask data via i2c from my app. Feb 28 10:31:56 i mean: i could live without having the keys seen from my app as "keyb events". Feb 28 10:32:29 set the 'edge' attribute of the gpio as I mentioned above, open its 'value' attribute. its file descriptor will get a POLLPRI | POLLERR event when the edge is detected Feb 28 10:32:45 how to receive that depends on which i/o polling mechanism is used Feb 28 10:33:05 if using poll(), well then literally those events are generates Feb 28 10:33:13 for epoll it would be EPOLLPRI | EPOLLERR Feb 28 10:33:48 for select() the POLLERR means the fd shows up in exceptfds (the third fd set) Feb 28 10:34:44 k Feb 28 10:35:21 thanks a lot, i'm gonna learn about this all. Feb 28 10:35:36 really: thanks, zmatt Feb 28 10:39:36 parduz: https://pastebin.com/wEjWpEC9 pseudo-example of how to synchronously monitor one gpio for changes Feb 28 10:40:08 great Feb 28 10:41:09 if your event loop is managed by a framework that can only produce events when an fd is readable or writeable then a workaround would be to stick the gpio value fds into an epoll fd, and attach that epoll fd to your main event loop Feb 28 10:41:59 uh... you're running too fast. Feb 28 10:43:24 that's no problem, you can read back what I just said once you've caught up Feb 28 10:43:41 yep Feb 28 10:43:51 I'm just anticipating a potential headache further down the line, and suggested a workaround for it Feb 28 10:47:11 ok :) Feb 28 10:51:16 I love this channel - I learn so much Feb 28 10:53:11 :) Feb 28 10:53:51 the sysfs notification mechanism is kinda awkward, with this seldom-used POLLPRI event Feb 28 10:54:03 zmatt: how come you have so much time to help out on this channel? Feb 28 10:54:24 I don't have a life Feb 28 10:54:29 lol Feb 28 10:54:42 do you have a deep love for the beaglebone? Feb 28 10:54:58 or did you just end up with it for some reason and get involved with the community? Feb 28 10:55:31 I like 'em, but also we use lots of them at work Feb 28 10:56:02 (we embed them in our products) Feb 28 10:56:33 a literal bbb, or do you use the chips on your own boards? Feb 28 10:56:42 literal bbb Feb 28 10:57:22 not worth the effort to build your own hardwrae? Feb 28 10:58:45 not yet Feb 28 10:58:58 what's the product? got a www? Feb 28 10:59:18 http://dutchdutch.com/ Feb 28 11:00:11 audio processing? Feb 28 11:00:18 speakers Feb 28 11:00:34 I can see from the website, but why would you put a bbb in a speaker? Feb 28 11:01:13 ah "network control and filtering" Feb 28 11:01:26 wow Feb 28 11:01:33 i want to be rich :D Feb 28 11:02:02 yeah, the bbb controls the dsp and handles networking stuff Feb 28 11:02:13 audio streaming via network is also being worked on Feb 28 11:02:32 ok, you use it as a controller rather than doing the dsp in the prus Feb 28 11:03:02 the prus aren't particularly well suited to signal processing Feb 28 11:03:36 no but maybe good enough for HQ adc/dac capture of the audio and then process in userspace? Feb 28 11:03:58 Really nice stuff. As a hobbyst composer, i'd like some serious studio monitor for mixing. As a father of two, i don't have money for anything :D Feb 28 11:04:35 parduz: I got some second hand genele 8020s and they are great Feb 28 11:04:43 *genelec* Feb 28 11:04:46 mattvenn_: if you're going to do audio processing in linux userspace I don't understand what purpose you'd have for the prus Feb 28 11:05:06 but no, the dedicated dsp is much better suited for this and has guaranteed low latency Feb 28 11:06:54 I was thinking parallel dac/adc for audio capture Feb 28 11:07:23 I've never seen an audio dac/adc use a parallel interface Feb 28 11:07:35 they use i²s or something similar Feb 28 11:12:47 while we're here: do you have some tips about async non-blocking serial communication? (so, i guess, using a thread to listen it) Feb 28 11:13:01 otherwise i'll go looking for the boost libraries. Feb 28 11:13:29 uhh, same as any other non-blocking i/o ? Feb 28 11:13:57 open the file descriptor with O_NONBLOCK and hook it up into your event loop Feb 28 11:14:12 avoid threads, they're headaches and inefficient on a single-core system Feb 28 11:15:25 mh.... ok, thanks again. Feb 28 11:17:19 gui frameworks already have an event loop, so usually they make it easy to attach your own file descriptors to that Feb 28 11:18:12 so far not really clear with wxWidgets though Feb 28 11:21:08 why are you using wxWidgets anyway for an inherently unportable application? since it looks like it may be hard to hook stuff into the event loop because that wouldn't be portable between linux and windows Feb 28 11:21:17 (at least i'm guessing that's the reason) Feb 28 11:27:19 well there's the "heartbeat" trigger ;) Feb 28 11:27:33 :P Feb 28 11:35:44 well, if you want really fancy led control, you can always get an LP5569 ;) Feb 28 11:36:50 you know a led controller is fancy when its datasheet has a table of branch instructions Feb 28 11:38:39 I'd not really trust any ui framework to give me fd notifications with any reproducable latency Feb 28 11:39:24 on the other hand, with Qt you could start a thread and within that thread run a local event loop. Feb 28 11:40:25 you could, but it sounds rather pointless since the event he's getting indicates a key has been pressed, which needs to be injected into the gui framework anyway Feb 28 11:42:50 "why are you using wxWidgets anyway for an inherently unportable application?" 'cause fast UI developement without the licensing obligation of QT Feb 28 11:42:53 and yes using a dedicated thread might in some cases yield better latency, but it's just as plausible that if the event occurs while the gui thread is running, it will keep running until the next time it blocks (unless this really takes too long) and then you add context switch overhead on top of that Feb 28 11:45:56 with licensing obligation you mean the patent clause of the LGPLv3 or... ? Feb 28 11:47:49 zmatt: no, but there was talking about audio processing and I thought the async io question was with regards to that topic Feb 28 11:47:59 no Feb 28 11:48:17 but now your remark does make more sense :) Feb 28 13:42:45 I am having issues receiving BLE signals on my wifi/bluetooth interface, has anyone seen slow performance ? Feb 28 15:09:22 Has anybody used the blue tooth interface on the BBBW for collecting BLE beacons? **** BEGIN LOGGING AT Wed Feb 28 16:15:33 2018 Feb 28 18:23:28 Hi. Can I change the shared ram between PRU and host while the pru is running from the host side? It seems to me that this is not working. But when the PRU changes anything in the shared ram I can read it from the host. Feb 28 18:23:32 I am using the Beagle Bone Green. Feb 28 19:22:50 All these warnings in the manual about do not have any voltages on any I/O pins before the board is powered on. Does that also apply to the analog A/D channels? That seems extremely limiting if true. Feb 28 19:26:42 the A/D channels are very sensitive in themselves. not sure how they react to voltage while off Feb 28 20:27:37 well you don't want the board powered thru its i/o pins Feb 28 20:27:44 you almost certainly don't want it powered thru your a/d pins Feb 28 23:35:25 Hello...I found this online: https://www.tartssensors.com/product/tarts-beaglebone-black-cape/ Feb 28 23:35:32 I am going to try it soon. Feb 28 23:37:05 I have not tried a new cape in some, good amount of time. Feb 28 23:44:18 Can someone point me to the file that contains the pinmux configuration for the mmc1 interface? I have found the mmc2 (emmc) pinmux configuration but where I expected to find the mmc1 pinmux config, all I find is a config for the SDCD pin. Feb 28 23:45:56 I have followed through am33xx.dtsi, am335x-bone-common.dtsi, and am335x-boneblack.dts Feb 28 23:49:01 I see the node that sets up the mmc1 device, I just can not find the pinmux references for IOPAD 0x8f0, 0x8f4, 0x8f8, 0x8fc, 0x900, 0x904 Feb 28 23:50:44 So I went and decompiled the dtb my board is booting, still no mention of the pinmux settings for the SDCard interface. Only 0x960 which is pin C15 (SDCD) Feb 28 23:52:11 ... Feb 28 23:52:22 Not I but stick around. I am sure there are other people getting off work soon. Feb 28 23:53:50 I will hang out while I continue to search Mar 01 00:22:16 Hey, I'm trying to use a bunch of GPIO pins. Some of them work, and some of them don't. I can't figure out why. I've disabled eMMC (I think). Mar 01 00:23:10 For example, following the method here: Mar 01 00:23:11 https://www.allaboutcircuits.com/projects/how-to-use-the-digital-i-o-on-a-beaglebone/ Mar 01 00:24:08 I can output to P8_3 (gpio38), but not P8_5 (gpio34) Mar 01 00:25:00 any ideas how to troubleshoot this? Mar 01 00:38:48 what software are you using to make or not make the GPIO pins do stuff? Mar 01 00:39:22 just a bash command Mar 01 00:39:28 Oh. Mar 01 00:40:06 So, you are interfacing w/ the GPIO pins w/ something like going to where the GPIO pins are located on the system and then typing... Mar 01 00:40:14 dir out or direction in? Mar 01 00:41:29 eg 'echo 1 > /sys/class/gpio/gpio34/value' Mar 01 00:42:02 I have not tried that since Angstrom but I am sure it is available. Mar 01 00:42:32 Let me see something...try config-pin P9.05 gpio Mar 01 00:42:39 I'm really trying to use Adafruit_BBIO python library Mar 01 00:42:40 Then run your bash cmd. Mar 01 00:42:43 Oh. Mar 01 00:43:02 Ok Mar 01 00:43:42 I use the Adafruit_BBIO library too. GPIO works well. I have only had trouble w/ the I2C interfacing so far on their 1.0.10 library...long story. Mar 01 00:44:20 k, config-pin says "Pin is not modifyable" Mar 01 00:44:29 So...w/ Adafruit_BBIO use this GitHub.com page: https://github.com/adafruit/adafruit-beaglebone-io-python Mar 01 00:44:34 ... Mar 01 00:44:34 Oh. Mar 01 00:44:46 Maybe you have to try to cancel out audio and video too. Mar 01 00:44:52 in your uEnv.txt file. Mar 01 00:45:17 I do not know your set up. Are you connected via PuTTY or do you use Debian or Ubuntu? Mar 01 00:45:43 I use ubuntu Mar 01 00:46:16 Okay...so in your terminal on the BBB, go to cd /boot. sudo "Your text editor" uEnv.txt. Mar 01 00:46:29 so, for nano it would be sudo nano uEnv.txt. Mar 01 00:46:36 Pastebin what you have listed. Mar 01 00:47:03 ... Mar 01 00:47:15 I typed about the audio and video b/c they take up pins too. Mar 01 00:47:20 My uEnv.txt file says "dtb=am335x-boneblack-overlay.dtb" if that's the important bit Mar 01 00:47:44 Not really...try to pastebin your uEnv.txt file and I will comment on it. Mar 01 00:49:10 https://pastebin.com/kvVM58Ju Mar 01 00:49:33 ^That's my uEnv.txt file. Mar 01 00:49:50 For instance...I run uname -r and I get: 4.9.82-ti-r102 Mar 01 00:49:54 That is my system for now. Mar 01 00:49:57 I tried following instructions elsewhere for disabling emmc and hdmi. Mar 01 00:50:20 uname -r gives: 4.9.78-ti-r94 Mar 01 00:50:40 Well, if you are running a SD Card, disabling the eMMC is okay but if you have a eMMC enabled board, that would create a boot issue. Mar 01 00:50:51 Okay. Let me look at your pastebin. Mar 01 00:51:15 I'm just running off of the SD card. Mar 01 00:51:18 Okay. Mar 01 00:51:29 I saw the uEnv.txt file and you have no info. on it. Mar 01 00:51:52 Hold. I am going to recreate what you did and get back to you. Mar 01 00:52:34 No info? Did I not do the pastebin link right? Mar 01 00:53:27 I looked, yes. Mar 01 00:53:46 You must have held some info. on that .txt file back. Mar 01 00:54:56 argentum2f_2: I see where the P8.5 pin is used. It is for eMMC but we do not have write authority for some reason. Mar 01 00:55:07 Yeah, just the commens I think. Here's all of it: https://pastebin.com/rsbjezwu Mar 01 00:55:45 I did get a cmd though. SUDO_ASKPASS is the cmd. I am not sure how to use it. I will find out. Mar 01 00:55:56 yeah, but I can write to P8.3 and P8.8, just not P8.5 or P8.6 Mar 01 00:56:20 Okay... Mar 01 00:56:44 See where it states under Disable auto loader of virtual capes? Mar 01 00:57:00 BBB, right? Mar 01 00:57:24 yeah Mar 01 00:57:54 should I uncomment those lines instead? Mar 01 00:58:08 when you comment something out, you take away the "#" mark. Try to take away the "#" mark from where you believe the pins are used up. Mar 01 00:59:32 So...if the pins are used at uboot__overlay_video=1, try there to uncomment it but if the pins are used elsewhere, try to uncomment that line in that .txt file. Mar 01 00:59:40 ok, I don't need any of those for now so I uncommented them all. I'm rebooting to see if that helped. Mar 01 00:59:46 Okay. Mar 01 00:59:47 Cool! Mar 01 01:00:09 So, you use your terminal only, right? Mar 01 01:02:14 yeah Mar 01 01:02:22 just ssh Mar 01 01:02:26 Okay. Mar 01 01:02:52 I am going to find out about SUDO_ASKPASS now. Mar 01 01:02:54 Please hold. Mar 01 01:03:22 I thought, based on what was here: https://elinux.org/BeagleBone_DTBs, that just changing the dtb line to what I had it should do the trick though. Mar 01 01:04:19 Oh. I know we use U-boot overlays now. I guess it depends on which blob you get. I am clueless on that matter. Mar 01 01:04:32 on the DTB matter. Mar 01 01:05:32 k, cause I see different stuff all over, and I'm not clear on how all this works yet. Mar 01 01:06:38 I have seen this work, I have used capes before that have were not accessible b/c of used pins. I had to stop using the required pins for video and audio to make my cape work. Mar 01 01:07:05 ... Mar 01 01:07:31 Hey...did you get an error that told you about SUDO_ASKPASS at all when you tried sudo config-pin P8.5 gpio? Mar 01 01:09:44 No, just: Mar 01 01:09:46 P8_05 pinmux file not found! Pin has no cape: P8_05 Mar 01 01:09:51 Oh. Mar 01 01:10:05 Are you sure you are using kernel 4.9.x? Mar 01 01:10:30 what image do you have? cat /etc/dogtag? Mar 01 01:11:07 ... Mar 01 01:11:12 BeagleBoard.org Debian Image 2018-02-18 is mine. Mar 01 01:11:42 BeagleBoard.org Debian Image 2018-01-28 Mar 01 01:11:48 Okay. Mar 01 01:12:06 That is new enough for you to use U-boot instead of all that cape_mgr stuff. Mar 01 01:12:22 ok, what is u-boot? Mar 01 01:12:30 can you point me to some resources? Mar 01 01:12:43 Sure. Mar 01 01:13:09 http://processors.wiki.ti.com/index.php/Linux_Core_U-Boot_User%27s_Guide Mar 01 01:13:41 Oh and you can see some dude talk from TI about it too at: https://training.ti.com/linux-board-porting-series-module-4-linuxu-boot-source-code-structure?cu=399066 Mar 01 01:13:53 ... Mar 01 01:14:28 I am going to change my .txt file to suit the needs of this change. I will reboot and I will be back to tell you if it worked fo rme. Mar 01 01:14:45 cool, thanks Mar 01 01:17:12 https://eewiki.net/display/linuxonarm/BeagleBone+Black is another resource for the BBB. Mar 01 01:18:12 argentum2f_2... Mar 01 01:18:19 Look at the bottom of that last link. Mar 01 01:18:38 They have most things dedicated to u-boot and u-boot overlays. Mar 01 01:19:30 ok Mar 01 01:22:03 Currently, I am digging through the /sys/devices/platform/ocp dir. It does not show the P8.5 pinmux. It must be located somewhere. Mar 01 01:29:12 I tried checking if there is a conflic by looking at 'cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pingroups ' as per a suggestion elsewhere Mar 01 01:29:28 What happened? Mar 01 01:29:46 The pins I'm trying to use all say: Mar 01 01:29:47 pin 38 (PIN38): (MUX UNCLAIMED) (GPIO UNCLAIMED) Mar 01 01:30:04 Oh. Maybe they help the device, BBB, wake up. Mar 01 01:30:33 So, if you wrote a u-boot overlay for that specific pin for gpio, it may produce? Mar 01 01:30:45 or...you could use it! Mar 01 01:31:22 Well, most of the pins work. I can't find anything different about the pins that don't. Mar 01 01:31:28 https://github.com/RobertCNelson I think is sort of in control of things w/ u-boot. I am not really sure, though. Mar 01 01:31:30 Okay. Mar 01 01:32:27 If you were to look at his page, there might be some clues as to how to make that .txt file work for you in your case. Mar 01 01:33:54 Well arg: I am sorry I failed you. I thought that I was right. Mar 01 01:34:14 No prob, I appreciate the help :) Mar 01 01:34:27 <<<<< smoke break Mar 01 01:35:30 I'll try some more options with the uEnv.txt file and read up on the uboot stuff. I'm also curious if it could be a hardware issue (maybe I 'burned out' that pin or something) Mar 01 01:36:05 Cause I thought I had successfully used it before. Mar 01 01:36:24 Anyways, I'll give it another try tomorrw. Mar 01 01:36:34 Thanks! Mar 01 01:39:23 I have burned a pin or two, i.e. so I thought. Mar 01 01:39:36 Luckily, they have multiple use pins. Mar 01 01:39:44 and many! Mar 01 01:45:43 arg: Look here: https://github.com/RobertCNelson/beaglebone-universal-io. This might be helpful w/ the condition that you are having. Mar 01 01:45:45 ... Mar 01 01:47:00 config-pin -l P8.5 is default gpio gpio_pu gpio_pd gpio_input Mar 01 01:48:59 dafualt? I guess you can use it as a gpio as is. I am just not sure b/c of how it is currently used on your system. **** ENDING LOGGING AT Thu Mar 01 02:59:59 2018