**** BEGIN LOGGING AT Fri Oct 23 10:59:57 2020 Oct 23 16:25:34 please forgive my ignorance, I am a first time on site and have not worked with an actual beagleboard yet. I am finding myself needing to obtain a BeagleBoard Black and touch screen for a project which will include programming in C++ for integration with some high end servos with software controlled motion (step and direction). I have done some Pi Oct 23 16:25:34 projects, and many Arduino... but would like some recommendations for touchscreen integration with BeagleBone and any common recommended C++ touchscreen libraries. Thank you! Oct 23 16:50:45 sounds really cool Oct 23 16:50:57 qt for c++ i would imagine Oct 23 16:51:12 that is their bag Oct 23 16:51:43 i bought the newhaven display and it works nice once you modify and void your warrenty Oct 23 16:51:58 i just ordered a 4d 7" cape Oct 23 16:52:04 we shall see how that goes Oct 23 16:52:08 welcome though Oct 23 19:00:48 ok I am doing something wrong Oct 23 19:10:45 I am wired and can see the bbai in my file directory Oct 23 19:10:53 but i get cannot resolve hostname Oct 23 19:10:59 made the update to .ssh/config Oct 23 19:20:59 15 Oct 23 19:38:53 ok so I just added a host key Oct 23 19:39:00 the ssh is incredibly slow Oct 23 19:39:08 i have a delay in keys regiserting Oct 23 19:39:33 key presses show up with a 1 second delay Oct 23 19:39:37 any ideas? Oct 23 19:46:33 is the board in australia and you're not? Oct 23 20:56:07 Mattboone: has the cpu throttled to almost nothing due to overheating? :P Oct 23 20:56:37 even when doing nothing sheesh Oct 23 20:56:47 how do I check temp Oct 23 20:58:22 are you running an image with or without TIDL ? Oct 23 20:59:53 for temperature monitoring you can try this: https://pastebin.com/Cj1hQuUr Oct 23 21:00:01 (control-C to stop) Oct 23 21:31:04 I had TIDL but this is happening soon after powering on Oct 23 21:31:40 I asked because I know the TIDL firmware causes additional heating even if you don't really use TIDL Oct 23 21:32:21 anyway, the overheating theory is really easy to test: let it cool down for a bit, try again, or actively cool it somehow Oct 23 21:37:00 Fan! Oct 23 21:40:16 I asked the other day about getting SPI to work on the BB AI, but sadly I was disconnected after only the answer on using kernel 5.4. I tried that and I'm still not having any success. When I run show-pins, the pins show up right, but when I test spidev I get nothing on the line. Does anyone have advice or an example of a working dts for spi2? Oct 23 21:41:52 using kernel 5.4 sounds like a bad idea Oct 23 21:42:18 current recommended kernel series are 4.14-ti when using TIDL or 4.19-ti otherwise Oct 23 21:42:54 example for mcspi2: https://pastebin.com/iXbGGtzz Oct 23 21:48:36 pwhudson11: Hello, I am sorry for the other day. I thought you were trying to get a Cape to work w/ the AI. Oct 23 22:02:15 zmatt I tried to build this, but I got an error saying there was no rule to make a temporary directory needed. Does it have to do with this header file that I downloaded with it? Oct 23 22:02:36 how did you try to build it? Oct 23 22:03:48 using the MakeFile that was given in the git repo of beagle device trees Oct 23 22:06:10 just tested it, it compiles fine (with the example saved as "src/arm/bbai-mcspi2.dts", the bbai-pins.h header saved in the same directory, using "make src/arm/bbai-mcspi2.dtb") Oct 23 22:06:38 all in a checkout of the BeagleBoard-DeviceTrees repo Oct 23 22:15:43 this shows the steps: https://pastebin.com/Br7j4bB5 Oct 23 22:16:28 note that I'd expect something like bbai-pins to be upstream sooner or later, at which point you'd probably get conflicts from it and can stop using it Oct 23 22:20:36 whats an appropriate temp Oct 23 22:21:03 I let it sit for a bit and at 71C Oct 23 22:21:18 i may go and just switch away from TIDL Oct 23 22:21:25 get the other image Oct 24 00:07:59 I am struggling with switching on/off gpio output pins with the config-pin utility in 10.3 . Perhaps not possible anymore? I can see that the config-pin utility has changed from the last debian image I used (9.3 I think). What would be the easiest way to do this currently? Oct 24 00:08:29 honestly I didn't know that was ever part of the old config-pin... setting up gpios doesn't really have anything to do with pinmux config Oct 24 00:08:54 (didn't know until recently that is) Oct 24 00:11:05 hmm, looks like gpio functionality has been added though Oct 24 00:13:37 1 or 0, right? So, it would be config-pin p9.xx 1 for HIGH. Oct 24 00:13:45 set_: uhh no Oct 24 00:13:51 never seen that syntax before Oct 24 00:14:17 Well, not the xx part. xx is short hand for the available GPIO pins. Oct 24 00:14:33 1 or 0 is all that is available right now, I thought. Oct 24 00:14:41 outrageous: the thing is, when you switch a pin to output you also want to specify whether it should be initially high or initially low, so normally you just do that in your application Oct 24 00:14:51 I tried +, -, hi, high, low, lo. Oct 24 00:14:59 None of those worked. Oct 24 00:15:47 neither does 0 or 1, and I see no support for it in the source code Oct 24 00:15:53 yeah, pins can be set to gpio, but not turned on/off. Something like "config-pin 912 out", "config-pin 912 1" used to work Oct 24 00:16:24 outrageous: ah, setting level also used to work? that definitely hasn't been reimplemented (yet) in the C version of the utility Oct 24 00:16:38 Nope, seems not. Oct 24 00:16:46 like I said, it seems like a bit strange feature for config-pin to have Oct 24 00:17:49 Perhaps yes. Somehow I figured it was an easy way to get it done on the last image I played with. Oct 24 00:18:06 on the other hand, config-pin already has pin parsing so it does make some sense to make it a simple way to configure a gpio Oct 24 00:19:48 https://github.com/beagleboard/bb.org-overlays/blob/143420d94c90561a4df6e6530246ba5c33028edb/tools/beaglebone-universal-io/config-pin#L1077 Oct 24 00:19:50 I personally have a udev rule that creates symlinks for gpios based on name (declared in DT), so e.g. changing P9_12 to output high-level is then simply "echo high >/dev/gpio/P9_12/direction" Oct 24 00:21:17 okay, I regret having looked at the source code of the "C" version of the config-pin utility.. I now feel the urge to wash my eyes with bleach Oct 24 00:21:27 lol Oct 24 00:21:44 I put it "C" in quotes since it somehow still manages to be a shell script, except written in C Oct 24 00:22:08 like, strcpy(cmd, "gpioinfo | grep "); is not something I'd be happy to see in a C program Oct 24 00:23:03 oh this is terrible Oct 24 00:23:30 i am sorry Oct 24 00:23:35 zmatt: Best not dig any deeper haha Oct 24 00:24:36 why don't they just use udev to locate the gpio /o\ Oct 24 00:24:41 libudev Oct 24 00:32:47 renrelkha: if you create a file /etc/udev/rules.d/gpio-symlinks.rules containing https://pastebin.com/36Q3Vpxz and then run "sudo update-initramfs -u" and reboot you should have a /dev/gpio/ directory with the aforementioned symlinks Oct 24 00:35:32 thanks :) Oct 24 00:35:44 ah I meant outrageous Oct 24 00:35:55 :( Oct 24 00:36:09 I mean, if it's something that makes you happy too then all the better ;) Oct 24 00:44:21 zmatt: Thanks! appreciate it :) Oct 24 01:23:04 and here's how to find a sysfs gpio in C/C++ without relying on convenient symlinks setup by an udev rule Oct 24 01:23:12 https://pastebin.com/KbdqKDTz Oct 24 01:23:21 (although I'd just rely on a convenient udev rule instead :P ) Oct 24 02:54:57 wow, that udev scan is slow as fuck though Oct 24 03:07:23 growing to hate pyqt Oct 24 03:07:28 and qt in general Oct 24 03:09:05 how so? Oct 24 03:11:19 these signals and slots Oct 24 03:11:32 what about them? Oct 24 03:11:34 and passing arguments maybe it the mixing with python Oct 24 03:11:49 seems clunky hooking them up Oct 24 03:12:47 though probably the only way to do it Oct 24 03:12:49 example? I mean, it can often be tricky to make a really nice interface between different languages, especially their approaching to typing are totally different Oct 24 03:12:58 *if their Oct 24 03:13:15 if you wanted to make a custom signal and slot Oct 24 03:13:38 it is both the sender and receiver Oct 24 03:14:24 so custom_signal(blah, blah) and then you need to self.custom_signal.connect(self.slot_function) Oct 24 03:14:50 and then finally emit the thing self.custom_signal.emit(23,24) or something like that Oct 24 03:15:55 I mean, that's how signals and slots are supposed to work... Oct 24 03:16:07 whether custom or not Oct 24 03:17:01 that is how all frameworks do it Oct 24 03:17:05 ? Oct 24 03:18:00 no, that's the whole idea behind signals and slots... a signal is used to broadcast some event that other objects might be interested in, and if they are they hook up a slot function to that signal in order to receive these events Oct 24 03:18:16 it's intended to decouple these Oct 24 03:18:50 the code emitting the signal doesn't need to know or care who he's calling (if anyone at all) Oct 24 03:20:14 i guess it is confusing to send stuff between objects that way Oct 24 03:20:23 so I have my 2nd thread working and it polls the PRU Oct 24 03:20:39 why? you don't need a thread and shouldn't use one Oct 24 03:20:42 especially not in python Oct 24 03:20:48 now I need to emit those values back to the main thread where I have an slot which will update Oct 24 03:21:01 you're just making things unnecessarily complicated for yourself Oct 24 03:21:15 i want the user to be able to do other things while the PRU is doing its thing Oct 24 03:21:33 so I move the polling to a sepereate thread and allow the user to continue to do stuff on the main thread Oct 24 03:21:44 yes, so use a timer (which I'm very sure qt produces) to poll the pru at some sensible interval Oct 24 03:21:51 in the main thread Oct 24 03:22:20 i am plotting stuff so I want as much data a possible so I am always polling Oct 24 03:22:51 oh god please no, this assumption here was that this just for status monitoring Oct 24 03:23:00 this is not a suitable interface for transferring a stream of data Oct 24 03:23:16 what do you mean Oct 24 03:23:21 /o\ Oct 24 03:23:25 lol Oct 24 03:23:42 it was working ok outside of that quirk with the process events Oct 24 03:23:51 or good enough for me Oct 24 03:23:56 if you want a graph over time, log it into a ringbuffer that you can consume at your leasure Oct 24 03:24:10 ok whats a ring buffer Oct 24 03:24:15 is that python thing Oct 24 03:24:19 instead of having to poll shared memory variables like crazy Oct 24 03:24:39 so it is a c thing? Oct 24 03:25:01 no, it's a common technique of using shared memory to transfer a stream of things from a producer (e.g. pru) to a consumer (e.g. your GUI) Oct 24 03:25:16 ok I will google it, I never heard of it Oct 24 03:25:23 but that is not surprising Oct 24 03:25:27 is it a basic concept? Oct 24 03:28:37 basically you write the data items into an array and when you reach the end you just start overwriting it from the start again... and the other side does the same except for reading, with some bookkeeping to ensure the reader doesn't try to faster than the writer (and optionally for the writer to detect when it is about to overwrite something that hasn't been consumed yet so it can throw an error) Oct 24 03:29:10 *the reader doesn't try to _read_ faster Oct 24 03:32:36 anyway, your idea of using a thread to be able to poll pru as fast as possible without blocking the UI wouldn't work anyway, since like I said last time: only one thread can be executing python code at any given time, so whenever the main thread is executing python code it would prevent your pru thread from running and vice versa Oct 24 03:33:00 oh I thought it would run in parallel Oct 24 03:33:16 why even have threads then Oct 24 03:33:37 unless I'm misremembering, but I'm pretty sure I'm not Oct 24 03:34:53 it's to allow multiple threads in parallel to be blocking on system calls or otherwise be executing non-python code Oct 24 03:36:28 and using multiple threads with blocking calls can yield code that seems simpler (but is in fact harder to reason about) than e.g. using an event loop Oct 24 03:37:29 ok sounds like I have more work to do =( Oct 24 03:39:30 on the bright side, if it had "proper" threads then you'd have terrible problems safely passing data from your pru thread to your main thread.. it'd be basically as tricky as passing data from pru itself in the first place Oct 24 03:40:20 (since two preemptive threads behaves more or less like two separate cores) Oct 24 03:42:49 lol Oct 24 03:42:57 i guess that is a bright side Oct 24 03:42:58 lol Oct 24 03:43:14 apparently Qt signals can invoke slots on another thread? that's interesting, that's a highly non-trivial piece of infrastructure then Oct 24 03:43:37 that is why I was complaining Oct 24 03:43:43 maybe Oct 24 03:43:45 i think Oct 24 03:43:46 lol Oct 24 03:43:55 so basically you were complaining about qt doing a lot of work to try to make inter-thread communication simpler Oct 24 03:44:08 yes Oct 24 03:44:09 lol Oct 24 03:44:23 you know what makes inter-thread communication even simpler Oct 24 03:44:25 not using threads Oct 24 03:44:39 noted Oct 24 03:47:33 basically when signal and slots are on different threads it uses some sort of asynchronous message passing between threads (so calling the signal on one thread _eventually_ causes the slot to be invoked on its thread) Oct 24 03:48:06 unlike the normal same-thread situation where it just behaves like a function call Oct 24 03:48:53 very different semantics... actually kinda gross that it treats these very different things uniformly by default Oct 24 03:51:03 bbl **** ENDING LOGGING AT Sat Oct 24 10:59:57 2020