**** BEGIN LOGGING AT Sat Jun 13 02:59:57 2020 Jun 13 03:11:40 I don't think this touchscreen cape consumes unusually many pins Jun 13 03:12:17 why, what problem did you run in this time? Jun 13 03:12:32 *run into Jun 13 03:20:47 lol Jun 13 03:21:22 sort of stuck in 1st gear, I was thinking if I can find one that uses less pins I could use the eQEP rather than make my own decoder Jun 13 03:21:34 also I cannot turn on the screen again Jun 13 03:21:50 there is something up with boot up sometimes it works sometimes it doesnt Jun 13 03:21:55 most of the time it doesnt Jun 13 03:22:03 yesterday I had no issues Jun 13 03:22:29 today immediate shutoff Jun 13 03:23:04 I just need to bite the bullet and move on from the LED blink examples and get to it Jun 13 03:24:51 I mean, I gave an actual example of a decoder fairly recently Jun 13 03:24:56 untested, but still Jun 13 03:33:46 yeah Jun 13 03:34:27 I get the basic premise Jun 13 03:35:03 just wondering if there is an easier route. Just a steep learning curve Jun 13 03:35:15 IMHO Jun 13 03:36:29 there are no doubt many routes to one's goal, selecting one is up to you Jun 13 03:36:49 yup that is the problem need a pick a path and start walking Jun 13 03:36:59 also it sucks that debugging is not trivial Jun 13 03:37:21 one of the benefits of high level languages Jun 13 03:45:26 using a high-level language (C) for PRU does not make it easier to debug Jun 13 03:45:50 talking about non PRU programming in general Jun 13 04:44:01 mattb0ne you can debug using eclipse I believe on your PC however it's a non trivial setup. I haven't looked at it in 6 months. Jun 13 04:44:41 ah as per usual he's gone. Jun 13 11:18:24 Hi, I posted here some days ago about my beaglebone suddently stops working, where i cannot connect to it. It have no ip, when looking at the router, it doesn't respond on serial communication and the heartbeat has stopped. Does anyone know how to fix this issue ? Jun 13 12:08:09 Munken: does it boot at all anymore? what leds turn on when you connect power to the beaglebone? what were you doing when it suddenly stopped working? Jun 13 12:16:14 @zmatt yes it boots fine, it just stops working after some time idling. When it stops responding the USR0 and USR2 leds are solid blue. Jun 13 12:18:06 so to be clear; when pressing the reset button it boots and it gets the same ip as always. When it fails USR0 and 2 are solid blue (sometimes only USR2), there is no pattern to it, other than it is just idling, sometimes this happens after an hour, others (like this last time) several days Jun 13 12:18:33 usr2 is cpu activity, so this sounds like probably a kernel panic Jun 13 12:19:50 (usr0 just blinks in a heartbeat pattern, so it'll be essentially random: stuck in whatever state it happened to be in when the system crashed) Jun 13 12:20:03 what kernel version are you using? Jun 13 12:20:06 (uname -r) Jun 13 12:23:36 actually, full version info may be useful. since your bbb is connected to a router, I assume it has internet access? can you run: sudo /opt/scripts/tools/version.sh | pastebinit Jun 13 12:25:48 (or if it doesn't have internet access just run "sudo /opt/scripts/tools/version.sh" and manually share its output using pastebin.com or some other paste service) Jun 13 12:29:46 4.19.94-ti-r43 - and here you go https://paste.debian.net/1151892/ Jun 13 12:32:17 ok Jun 13 12:32:22 booting from sd card I see Jun 13 12:32:36 yep, quite new to this platform, is that bad ? Jun 13 12:33:12 at the very least it's slower, and consumer sd cards are not known for their high reliability Jun 13 12:36:05 and weird problems can happen if there's a bootloader on eMMC (which will be used in preference over the one on sd card) that's much older than the system on sd card (as a result of it not understanding modern directives in the /boot/uEnv.txt config file on sd card)... however it looks like the bootloader on your eMMC, although older than the one on sd card (2018.09 as opposed to 2019.04), is still ... Jun 13 12:36:11 ...recent enough to be okay Jun 13 12:36:50 when you said "it doesn't respond on serial communication", did you mean the actual serial console or were you talking about usb ? Jun 13 12:37:00 yea actual serial console Jun 13 12:37:12 is anything logged to the serial console when this crash happens? Jun 13 12:37:30 used a raspberry pi for that, but at the request on someone on this chat i've also got a proper usb serial device Jun 13 12:38:06 well as this happens between several days, i do not have the connection open at the time of the crash Jun 13 12:38:19 rpi is fine too... just don't leave it connected while the rpi is powered off but the bbb powered on Jun 13 12:38:57 actually the pi was also online while it died... wait a minute Jun 13 12:39:05 ok, well I suggest you leave an rpi or whatever hooked up to the bbb's serial console to log everything to file Jun 13 12:39:44 and maybe remove the "quiet" directive from the kernel parameters of the bbb (configured via the "cmdline" variable in /boot/uEnv.txt) to increase the verbosity of serial console logging Jun 13 12:39:48 ok, I'll just start a serial console with screen and leave it in the background Jun 13 12:40:01 or do you have any suggestions as to how to log this better ? Jun 13 12:40:09 ok will do Jun 13 12:42:03 do I need to reboot to make the quiet change to take effect ? Jun 13 12:42:03 if you pass the -L option to screen it will log to file Jun 13 12:42:06 yes Jun 13 12:42:11 ok, will do Jun 13 12:42:20 I also have this in my .screenrc to make its log more useful: https://pastebin.com/raw/QskwbcWB Jun 13 12:42:51 (it will add timestamps so you have some idea of when the bbb logged what) Jun 13 12:43:49 note that those lines in .screenrc will just configure logging but not enable it, that still requires the -L option (or "log on" in .screenrc) Jun 13 12:44:45 you'll immediately see the difference the "quiet" option makes on the serial console, you'll get quite some spam while booting :P Jun 13 12:46:02 that's great, thanks :D Jun 13 12:47:20 if you want the bbb to automatically reboot when a kernel panic happens (or some equally serious system lockup), enable the hardware watchdog by changing #RuntimeWatchdogSec=0 to e.g. RuntimeWatchdogSec=30s in /etc/systemd/system.conf Jun 13 12:48:30 (not sure if it requires reboot, it might suffice to do "sudo systemctl daemon-reexec") Jun 13 12:53:29 Munken: just to confirm, this system is basically in a default state? you didn't like, install some obscure custom kernel module or whatever ;-) Jun 13 12:53:31 I guess that solution would have its pros and cons, I would rather be aware that there is an issue and fix it, than not. Jun 13 12:53:59 No I didn't, I thought the system was bloated and started removing stuff Jun 13 12:55:28 haha, yes it is bloated. it sounds like you may be interested in the console image, which is basically a minimal debian system for people who are happy to just install the packages they want: https://elinux.org/Beagleboard:Latest-images-testing#Debian_10_.28Buster.29_Console Jun 13 12:56:13 But I don't really care about the os at this point, I just want something that is slim and stable. I will be developing my own software for it, for an application that should run for years in my friends backyard. So if you have any suggestions as how I would do anything different or "proper" to this solution I welcome any help you can provide :) Jun 13 12:56:39 huh, yea that might be better :) Jun 13 12:57:42 if I were forced to make a guess, my candidates are: something wonky going on with the sd card (resulting in the rootfs vanishing), or something wonky with the wifi driver Jun 13 13:00:00 I've personally never seen this kind of instability though, including on the black-wireless Jun 13 13:00:31 huh.. just saw this in my journalctl Jun 13 13:00:31 Jun 13 12:49:54 beaglebone kernel: pvrsrvkm: loading out-of-tree module taints kernel. Jun 13 13:00:46 tainted kernel on a stock image :O Jun 13 13:01:57 yeah, that's the out-of-tree kernel module for the 3d gpu which nobody uses... I don't think the driver really does anything though until it's initialized by the userspace tools that aren't installed Jun 13 13:04:33 Can the BBBW use (AM335x based BeagleBone's and PocketBeagle) type images ? Jun 13 13:06:51 yes, every BeagleBone variant has an AM335x except the new BeagleBone AI (which is a totally different beast that just has the same form-factor) Jun 13 13:10:43 Ok and you would just use the eMMC flasher ? Jun 13 13:15:36 to flash to eMMC you can either download an eMMC flasher image and write that to sd card, or convert a normally bootable sd card into an eMMC flasher by uncommenting one line in /boot/uEnv.txt (iirc it's at the bottom, something like cmdline=init=..something involving eMMC flasher) Jun 13 13:15:52 and then if you boot from that flasher sd card, it will proceed to reflash eMMC Jun 13 13:17:14 btw I do actually recommend the console image over the iot image if you're comfortable with linux systems, especially if you already started trying to remove crap... starting with a clean image and installing stuff you want is generally less hassle than starting with a bloated image and trying to figure out what's unnecessary Jun 13 13:19:37 yea that is what I would like better actually. I think I'll start over with the console image, this might also fix if anything have gone corrupt on the SD side of things. Jun 13 13:20:09 it's a good idea to verify the contents of an sd card after flashing Jun 13 13:20:17 And then flash it to the eMMC instead of running off the SD card. Jun 13 13:20:45 I think that is already done by tools like balena, or am i wrong ? Jun 13 13:20:52 etcher does that yes Jun 13 13:21:07 I didn't know if you were maybe a "dd" sort of guy ;) Jun 13 13:21:57 I actually have a microsd card where certain 1KB pages read differently each time you read them Jun 13 13:22:03 quite fascinating Jun 13 13:22:16 trying to boot a system from that card did not work out well Jun 13 13:23:23 yea well, for new products depends on the recommended process :) Jun 13 13:26:14 heh, yea SD cards are really something to be careful with. At my work I did some testing of the expected lifetime of different providers, I'm fascinated that I haven't in my own projects experienced any more issues with them, than I have.. Some of them are really not to be trusted Jun 13 13:48:49 what does the PRU cape do exactly Jun 13 13:48:55 Munken: even the console image still has some pointless packages though: https://pastebin.com/M9qX9Js1 Jun 13 13:50:55 uio Jun 13 13:52:26 Munken: I personally also disable the default usb gadget (and optionally replace it with just g_ether) and replace connman and a flurry of other networking-related packages and use systemd-networkd instead... I still need to do a write-up on how to perform that switch on the bb.org images Jun 13 13:52:59 MattB0ne: you mean the pru overlay? (the "pru cape" is some old piece of hardware intended to serve as a demo for various pru functionality) Jun 13 13:53:33 i was referring to the old HW. Everything on the PRU is so dated Jun 13 13:53:45 uhh what Jun 13 13:53:54 these ti training Jun 13 13:54:15 i have been ping ponging back and forth between uio and remoteproc way of doing things Jun 13 13:54:30 this is the "pru cape" => https://processors.wiki.ti.com/images/8/85/Pru_cape-wiki-blockdiagram.png Jun 13 13:54:43 i am worried about going uio beacuse all your tools are python based Jun 13 13:54:44 yeah Jun 13 13:54:51 i am not sure what it buys you Jun 13 13:55:02 it's pretty pointless Jun 13 13:55:06 it's just a demo basically Jun 13 13:55:27 if I am using python scripts to put stuff onto the PRUs not sure how I can eventually pull it together with the gui i made Jun 13 13:55:43 also if you get hit by a bus (knock on wood) I would really be up the creek Jun 13 13:56:11 anyway, the pru overlay (configured in uboot_overlay_pru) selects between the two drivers for pru: uio-pruss and remoteproc-pru Jun 13 13:56:23 right Jun 13 13:56:40 so I would disable remoteproc in favor of uio-pruss Jun 13 13:57:14 @zmatt: Well I might just help you with that, I'm going throught the process now. Jun 13 13:57:16 and since remoteproc-pru felt the need to change incompatibly with every major kernel version that had it so far (4.4, 4.9, 4.14, 4.19) there are also four versions of that overlay Jun 13 13:57:28 right Jun 13 13:57:37 i also do not like this whole resource table config thing Jun 13 13:57:43 no documentation on it Jun 13 13:57:49 so that makes me want to use uio Jun 13 13:57:50 Munken: you'll probably want to disable generic-board-startup.service Jun 13 13:58:07 like it is a black art to set up an interrupt in remote proc Jun 13 13:58:15 so I am thinking uio would be easier Jun 13 13:58:20 it certainly is Jun 13 13:58:23 but there are less examples out there that I can put my hands on Jun 13 13:58:44 remoteproc also doesn't really offer shared memory mapping Jun 13 13:58:44 like does my code change. really the uio vs remote proc is just handling the data storage right ? Jun 13 13:59:04 I think that settles it Jun 13 13:59:11 dont get hit by a bus ok? Jun 13 13:59:14 lol Jun 13 13:59:17 I'll try Jun 13 13:59:21 @zmatt: ok, what does it do ? Jun 13 13:59:31 Munken: make boot slower Jun 13 13:59:38 Munken: also setup the usb gadget Jun 13 13:59:38 uio pruss Jun 13 14:00:21 Ok, It'll die then Jun 13 14:00:35 Munken: at least I assume it's still as unnecessary as it was in the previous image, haven't re-checked it on the latest :P Jun 13 14:01:12 oh well, it probably won't burn ;) Jun 13 14:01:42 MattB0ne: anyway, uio obviously doesn't require python.. though the old C library for uio (libprussdrv) is honestly kinda ew and I haven't gotten around yet to making a better C/C++ library for uio-pruss Jun 13 14:02:24 MattB0ne: but you can also use py-uio to just setup pru and then map its shared memory in some other application (written in C/C++ or whatever programming language you prefer) Jun 13 14:02:58 ok Jun 13 14:03:05 is uio not installed by default Jun 13 14:03:20 and likewise you can setup the irq using py-uio but then have another program actually receive it: https://pastebin.com/u/zmatt/1/dckSTayR Jun 13 14:03:44 "uio" is a kernel framework and userspace API, there's nothing to install Jun 13 14:04:03 "uio-pruss" is a kernel driver and installed by default (part of the kernel) Jun 13 14:04:51 so not sure what you mean by "is uio not installed by default" Jun 13 14:05:54 if I do lsmod | grep uio I do not see it Jun 13 14:06:30 then you probably don't have it enabled in /boot/uEnv.txt Jun 13 14:07:08 kernel modules for drivers get automatically loaded when the kernel finds devices that require those drivers Jun 13 14:07:35 anyone want to try a kernel stack buffer overflow? Jun 13 14:07:47 so if you enable the uio-pruss overlay, the kernel will load the drivers for that. if you enable the remoteproc-pru overlay, the kernel will load the modules for that Jun 13 14:09:25 and I can only have one active at a time righr Jun 13 14:09:35 so comment out that overlay Jun 13 14:09:44 you can't have two drivers for the same device at the same time no Jun 13 14:09:52 (that's true in general, not just for pru) Jun 13 14:10:54 only one uboot_overlay_pru= line should be uncommented in /boot/uEnv.txt ... (if multiple are uncommented I presume the last one will take effect and the others are ignored) Jun 13 14:18:50 where is the dts file to make that new version of the uio dtb Jun 13 14:19:34 grab my https://github.com/mvduin/overlay-utils project and do "make uio-pruss.dtbo" in that directory Jun 13 14:21:18 (overlay-utils builds overlays from DT fragments in a .dtsi, it uses a perl script to convert that to the ugly dts structure actually needed for an overlay) Jun 13 14:21:44 ok and the proper home for this is lib/firmware Jun 13 14:22:21 you can put it anywhere since you configure the full path in /boot/uEnv.txt anyway Jun 13 14:23:26 but you can put it in /lib/firmware for convention of course, just be careful to avoid overwriting any existing dtbos Jun 13 14:24:11 (you could also make a subdir /lib/firmware/custom/ and put custom overlays there, that would guarantee you can't conflict with existing overlays Jun 13 14:24:14 ) Jun 13 14:30:19 for comparison, without overlay-utils you'd write it like this: https://pastebin.com/raw/PDS0CBPs Jun 13 14:30:48 if you compare that to the uio-pruss.dtsi in overlay-utils, its benefit should be quite obvious :) Jun 13 14:32:25 do I need to reboot for it to load the overlay Jun 13 14:32:32 always Jun 13 14:33:21 overlays are basically patches applied to the main .dtb by the bootloader (u-boot) before it passes the dtb to the kernel Jun 13 14:34:59 ok now I got uio_pdrv_genirq and uio running Jun 13 14:35:04 so I am all set there correct? Jun 13 14:35:31 uhh no those are generally always there, they have nothing to do with pru specifically Jun 13 14:36:51 so I need uio-pruss Jun 13 14:37:08 not seeing it let me check my uEnv.txt for a typo Jun 13 14:40:01 nm it is loaded Jun 13 14:40:13 uio* and uio are different for grep it seems Jun 13 14:40:35 uio 20480 2 uio_pruss,uio_pdrv_genirq Jun 13 14:40:49 is that ok to have two things on one line like that Jun 13 14:41:06 two drivers on one device rule you were saying Jun 13 14:41:21 grep uio searches for lines containing "uio" Jun 13 14:41:32 grep 'uio*' searches for lines containing "ui" Jun 13 14:42:16 grep uio* will ask your shell to find files/directories in the current directory whose names start with "uio" and passes those names as arguments to grep, the first of which will be interpreted as regex by grep Jun 13 14:42:37 lsmod doesn't show devices Jun 13 14:42:44 lsmod shows modules and module-dependencies Jun 13 14:42:58 (the module "uio" is required by both uio_pruss and uio_pdrv_genirq) Jun 13 14:49:17 i should have a /dev/uio folder now but i do not Jun 13 14:49:25 looking at your examples for py-uio Jun 13 14:49:52 damn, if only py-uio came with a README containing installation instructions... oh wait, it does Jun 13 14:50:09 lol i am working through it Jun 13 14:50:34 specifically the Additional installation instructions under https://github.com/mvduin/py-uio#uio_pruss Jun 13 14:51:27 you've obviously already done the second step, so just install the uio-pruss.rules file, update your initramfs, and reboot Jun 13 14:56:26 am I restricted to assembly with uio-py Jun 13 14:56:32 i havent written anything so not a biggie Jun 13 14:56:41 just noticed all your PRU code is in assembly Jun 13 14:57:04 that's a question I've already answered _and_ which is answered by reading the readme Jun 13 14:58:02 i should spend a few hours reading all this stuff Jun 13 14:58:06 before I ask some more questions Jun 13 14:58:09 i will be back tonight Jun 13 14:58:14 since it mentions loading an ELF executable produced by clpru (the C compiler) and it mentions "the C example" Jun 13 14:58:21 you suspect you have a lot of them asnwwered Jun 13 14:58:23 I mean, "all this stuff" literally fits on one screen Jun 13 14:58:32 for me it still a lot Jun 13 14:58:35 there's very little in the README, I'll admit that Jun 13 14:59:06 would you recommend assembly working a better and causing less issues Jun 13 14:59:16 i remember you talking to someone about the c compiler being shotty Jun 13 15:00:22 the c compiler is crap, in part because PRU was never designed to be targeted by a C compiler (so the C compiler has a difficult job), and in part because the compiler is just stupid (in ways that can't be excused by the intrinsic difficulties of targeting PRU) Jun 13 15:00:54 and using C also negates some of the biggest benefits of PRU Jun 13 15:01:56 at the same time, there's still some range of PRU applications that can be usefully written in C despite its drawbacks Jun 13 15:02:52 if the performance requirements are sufficiently loose (yet still too tight for linux userspace) Jun 13 15:04:04 e.g. for the decoder it will depend on how fast the signals will be changing Jun 13 15:25:33 @zmatt, the console image seems quite a bit faster than what I've been using, maybe it is also something to do with the eMMC vs SD card. Jun 13 15:25:45 but that is really great :) Jun 13 15:25:52 Munken: eMMC is quite a bit faster than SD yeah Jun 13 15:26:07 mainly because eMMC uses an 8-bit interface while SD uses a 4-bit interface Jun 13 15:26:17 (and reads are typically limited by the interface speed) Jun 13 15:27:58 oh, actually didn't know that, but that is great, also I wasn't aware that it was "so large", I think i can keep my entire system with application there and use SD for logging and databases. Jun 13 15:28:13 that's quite great as well :) Jun 13 15:31:24 i will go for assembly Jun 13 15:38:45 MattB0ne: it's up to you Jun 13 15:38:46 Oh that is old school... Jun 13 15:38:59 Are you forced to do it, or why ? Jun 13 15:39:07 Munken: look a few lines up Jun 13 15:39:53 i am not forced too Jun 13 15:39:54 MattB0ne: in your case I think C could probably be fine. the tricky bit is that if you don't know pru assembly, you also won't know which things in C to avoid Jun 13 15:40:40 from the pseudo code for decoding i think loops will be simpple enough Jun 13 15:40:57 what I shared wasn't pseudo-code, it was probably-working-code Jun 13 15:41:01 I do not know either really well Jun 13 15:41:09 although it could probably be simpler Jun 13 15:41:33 yeah I was googling a few other examples Jun 13 15:41:52 I want to learn good habits Jun 13 15:41:54 depends a bit on whether you want to count on every edge of either signal or if counting only on the edges of one of the signals suffices Jun 13 15:42:00 the former gets you twice the resolution Jun 13 15:42:11 right Jun 13 15:47:58 encoder Jun 13 15:53:43 decoder Jun 13 15:54:26 wrong box Jun 13 15:54:35 I am tempted to do everything in python Jun 13 15:54:42 to leverage what you have out on github Jun 13 15:54:49 it is much eaiser to understand what is going on Jun 13 15:55:00 so comparing the c example of test Jun 13 15:55:39 writing a variable to memory you just use "int far volatile" Jun 13 15:55:53 and python can still find it Jun 13 15:56:03 I am probably not being clear Jun 13 15:56:21 if you declare a variable the processor still controls where it sits in the 8kb Jun 13 15:56:31 if I declare a registry then I am specifying exactly where it goes Jun 13 15:56:38 is that a fair statement? Jun 13 15:59:46 i am going to read up on the memory mapping thing again going AFIAK. Jun 13 16:00:09 thanks for putting this stuff up there, much tighter than anything else I have seen Jun 13 16:00:27 be on later Jun 13 16:02:52 MattB0ne: hold on Jun 13 16:03:08 ok Jun 13 16:03:17 MattB0ne: https://pastebin.com/PDgJtiuy with the updated makefile and linker script in py-uio/pru-examples/fw-c this C code seems to compile to pretty decent output Jun 13 16:03:39 this only counts on edges of one input though Jun 13 16:04:03 (which simplifies things but doesn't get you optimal resolution) Jun 13 16:04:16 i think for my use case that is fine Jun 13 16:04:55 though I cannot determine direction with just looking at the edge of one channel right Jun 13 16:04:59 I need bot Jun 13 16:05:02 I can try and modify Jun 13 16:05:03 it uses both channels Jun 13 16:05:10 but it only counts on edges of A Jun 13 16:05:21 (but looks at B to determine the direction) Jun 13 16:05:31 ehh, I mean both signals of the channel Jun 13 16:05:33 not both channels Jun 13 16:05:59 I mean, you can just look at the code, if you ignore the magic declarations at the top it's pretty self-explanatory Jun 13 16:06:22 yeah Jun 13 16:06:27 i am going to port to python Jun 13 16:06:35 and roll with it Jun 13 16:06:48 I can learn C later Jun 13 16:06:59 too much ground to cover with my current level of understanding Jun 13 16:07:08 you did 95% of the heavy lift in the repository Jun 13 16:07:09 that's your call, like I said it's perfectly possible to use py-uio only for initialization Jun 13 16:07:35 true but I rather not bounce around and I understand python much more Jun 13 16:08:12 the magic at the top is what scares me in the C code Jun 13 16:08:21 the python i kind of get Jun 13 16:29:35 MattB0ne: https://pastebin.com/raw/i14YGS4H assembly version that does the same thing as the C code Jun 13 16:31:15 SWEET thank you kindly Jun 13 16:31:55 gonna have to cite you on this publication Jun 13 16:33:15 ah actually these are not equivalent I think Jun 13 16:34:25 ok maybe they are.. I probably wasn't looking right Jun 13 16:36:04 we shall find out gonna wire up the motor after lunch Jun 13 16:43:12 they're equivalent Jun 13 16:43:29 (in fact the exact same instructions up to register choice) Jun 13 16:46:21 MattB0ne: oh, for both versions (C and asm) you need to do 'core.c28 = 0x10000' in python before starting the core (e.g. right after loading the program) to ensure the counter will end up in pru shared memory (pruss.dram2 aka core.shared_dram) Jun 13 16:47:24 not sure why I put the variable in that memory anyway, but *shrug* Jun 13 16:47:38 ok Jun 13 16:59:30 can I plug in a 12V 5amp adapter into the beagle without frying it Jun 13 16:59:53 I have a suspicion that the adapter I have is not sufficient Jun 13 17:01:50 no Jun 13 17:01:53 5V Jun 13 17:02:47 5V 2A (and 2A is the absolute worst case, the BBB usually draws far less) Jun 13 17:03:21 that lcd manufacturer said "Please check that the 5v power source can support at least 2.5 to 3 amps to the Beaglebone and the display." Jun 13 17:03:40 was going to get a 3 amp adapter to check Jun 13 17:03:58 has to be a power thing because it has turned on but it appears random Jun 13 17:03:58 the lcd manufacturer is an idiot Jun 13 17:04:04 lol Jun 13 17:04:18 i mean i guess I can try and pull that resistor out Jun 13 17:04:24 its a brick now anyways Jun 13 17:05:02 if you can wiggle it back and forth it'll probably break off Jun 13 17:05:20 (avoid pulling since that can more easily damage the pcb itself) Jun 13 17:07:43 ok I will wiggle out R1 Jun 13 17:25:01 MattB0ne: actually this might be an even better loop: https://pastebin.com/raw/jWZXPi3k it counts on all four phases, but it has one phase of hysteresis to make it noise-resistant: if it's right on an edge and one of the two input lines is going back and forth as a result (e.g. due to vibration) then the counter will nevertheless remain stable Jun 13 17:26:27 (especially useful for encoders on some knob that's handled by a human, but perhaps it's also useful for motor encoders) Jun 13 17:28:57 ok cool Jun 13 17:30:53 (for initial testing it may be informative to connect two switches instead of the motor encoder, so you can control the inputs manually and see how the count changes) Jun 13 17:34:08 i can do that Jun 13 17:34:22 I just need to ensure my voltage is 3.3V Jun 13 17:34:53 connect switch between BBB pin and ground, make sure internal pull-up enabled on the pin (in your overlay) Jun 13 17:35:46 ensure the voltage is what is 3.3V ? Jun 13 17:37:50 wow I just looked at what I typed Jun 13 17:37:57 ensure what voltage is 3.3V ? Jun 13 18:27:08 nm Jun 13 18:27:37 i was referring to power the switich but If I have it pulled up that is enough Jun 13 18:36:04 yeah the switch is just between pin and ground Jun 13 18:46:33 i got R1 out Jun 13 18:46:42 should I just join the pads with solder? Jun 13 18:49:55 NO Jun 13 18:50:03 ok Jun 13 18:50:11 it should be open, not connected Jun 13 18:50:17 let try and turn it on Jun 13 18:51:08 joining the two pads would force the backlight permanently full-on and short-circuit the BBB's pwm output controlling the backlight Jun 13 18:53:33 you sir are a genius Jun 13 18:53:43 just power cycled 5 times Jun 13 18:53:48 works Jun 13 18:55:11 btw, when you're going to try the decoder with switches, you should be able to use the pru-examples/debugging.py example to see what PRU is doing when you toggle the switches. just change which program it loads, change "single = False" to "single = True" and pipe the output of the script through uniq to make sure you don't get a flood of the same line repeated over and over while the pru program is ... Jun 13 18:55:17 ...polling for a pin change Jun 13 18:55:46 yep that's what I expected Jun 13 18:55:56 I don't understand why they'd turn the backlight on by default in the first place Jun 13 19:02:39 saved me 100 bucks Jun 13 19:02:49 I need to get aligator clips Jun 13 19:02:57 i have wire leads from the encoder Jun 13 19:03:07 and I need to get into the female headers Jun 13 19:03:22 been using jumpers and alligator clips for the time beign Jun 13 19:04:59 have a link to that encoder (or the motor it's part of) that you intend to hook up? have you ascertained how to properly connect it? Jun 13 23:34:49 ok my overlay sucks Jun 13 23:38:02 https://pastebin.com/y1afuafy Jun 13 23:38:09 when i use the pin tool Jun 13 23:38:49 one pin comes up P9.30 102 fast rx down 7 gpio 3.16 << lo P9_30 Jun 13 23:39:25 the other P9.27 105 fast rx down 7 gpio 3.19 << hi P9_27 (pinmux_edt_ft5x06_pins) Jun 13 23:39:54 pin 27 might of worked not sure Jun 13 23:43:17 what's that "pinmux_edt_ft5x06_pins" ? Jun 13 23:43:28 it's conflicting with your overlay Jun 13 23:44:18 I am not sure Jun 13 23:44:19 P9.27 is in use Jun 13 23:44:22 by your cape Jun 13 23:45:04 P9.27 and P9.14 are used by the cape, and of course P9.19/20 is cape i2c, other P9 pins are available Jun 13 23:47:04 P9.30 is open I am going to switch to P9.22 Jun 13 23:47:20 how can I find what pinmux_edt does Jun 13 23:47:28 look for it uEnv.txt Jun 13 23:47:29 ? Jun 13 23:48:36 it's part of the cape overlay Jun 13 23:48:54 edt_ft5x06 is the touchscreen controller Jun 13 23:49:11 (connected via i2c, but P9.27 is its interrupt line) Jun 14 00:00:38 what about P9_25 Jun 14 00:00:42 what is Audio osc Jun 14 00:00:47 irrelevant for you Jun 14 00:01:01 you have it red colored Jun 14 00:01:04 is that significant Jun 14 00:01:12 I literally just told you which P9 pins are used by your cape Jun 14 00:01:41 if you're talking about my P9/P8 summary sheets, there's a legend at the bottom of each sheet Jun 14 00:01:42 its not Jun 14 00:02:17 your cape does not have an audio interface so this is not relevant for you Jun 14 00:03:14 I am going to use it. Also why wont your code let me use P9.41 or P9.42 Jun 14 00:03:17 it gives me an error Jun 14 00:03:39 those expansion header pins connect to two processor pins each Jun 14 00:03:55 hence my headers have P9_41a and P9_41b and likewise for P9_42 Jun 14 00:05:00 I listed a/b in this overview I gave you: https://pastebin.com/XPaY9xF8 Jun 14 00:06:22 https://pastebin.com/raw/XPaY9xF8 (things don't line up right in the not-raw version due to pastebin stubbornly using 4-space tab width) Jun 14 00:10:06 ok got it Jun 14 00:10:14 rebooting Jun 14 00:10:49 am I wrong to assume that my ecap activity must happen on P9.42a Jun 14 00:12:09 not sure why you think you need to "assume"_ that when the overview I just linked explicitly lists the pruss ecap as being on P9.42a Jun 14 00:13:19 of course strictly speaking you don't necessarily need to use the pru ecap, but it is the simplest, most convenient, and most efficient for pru to access Jun 14 00:13:38 using one of the other pwm outputs would be more hassle Jun 14 00:13:40 any way i do not feel like my overlay is taking Jun 14 00:13:49 P9.30 102 fast rx down 7 gpio 3.16 << lo P9_30 Jun 14 00:13:56 check kernel log Jun 14 00:14:15 also check /proc/device-tree/chosen/overlays to confirm your overlay is listed Jun 14 00:15:16 it is listed Jun 14 00:15:20 checking the log Jun 14 00:15:36 what does your overlay look like right now? Jun 14 00:17:35 pinctrl-single 44e10800.pinmux: pin PIN109 already requested by ocp:P9_41_pinmux; cannot claim for 4a300000.pruss Jun 14 00:18:08 you forgot the USES_PIN directives Jun 14 00:19:14 https://pastebin.com/mvdTthJ1 Jun 14 00:19:18 I had it Jun 14 00:22:12 ah, yeah so USES_PIN() is just a macro that disables runtime pinmux devices from cape-universal... which unfortunately uses a different way of dealing with P9.41/42 Jun 14 00:23:35 it's just P9_41 in this case (and what I call P9_41b, cape-universal calls P9_91 .. I have no idea who thought that was a good idea) Jun 14 00:23:49 lol Jun 14 00:23:55 should I just chose a different pin Jun 14 00:24:00 no? Jun 14 00:24:40 why? also there isn't a different pin available for pruss ecap (or rather its only alternative is on P8 and used by the cape) Jun 14 00:25:19 restarting Jun 14 00:25:32 anyway, I honestly wasn't even sure which one is "P9_41" and which one is "P9_91" according to cape-universal, but fortunately the error you quoted contains the answer: "already requested by ocp:P9_41_pinmux" Jun 14 00:25:41 that's showing that it's P9_41 Jun 14 00:27:13 ok getting something different Jun 14 00:27:24 P9.41 106 fast rx down 7 gpio 3.20 << hi P9_91 (pinmux_P9_91_default_pin) Jun 14 00:27:35 there is that 91 Jun 14 00:27:49 for the other one P9.30 102 fast rx up 2 INVALID pruss@4a300000 (pruss) Jun 14 00:28:17 P9.30 seems closer Jun 14 00:28:18 it is up Jun 14 00:28:28 is it invalid because the PRU is not initialized? Jun 14 00:29:24