**** BEGIN LOGGING AT Mon Feb 08 03:01:12 2021 Feb 08 03:35:45 Is there a config-pin usage for SPI? Feb 08 04:09:46 I got one master and two slaves, i.e. BBGW and SPI cam. and another LCD Display. Feb 08 04:10:17 Now, I guess I have to configure how make two slaves work w/ one master. Feb 08 04:10:33 Dang. Past 10:00 again. Sorry. Feb 08 09:27:06 Show of hands who is looking forward to using RISCV as a daily driver? Feb 08 10:34:47 Regarding BBAI for me kernel 4.14 scaled very badly regarding cppufreq, kernel 5 is soo much better, but it's missing the 450MHz stepping completely which is a shame. I'm looking for some documentation about building the kernel for the AM57xx bit to no avail. Feb 08 10:35:47 well the low-frequency stepping was never an official OPP anyway Feb 08 10:36:29 since it doesn't allow for lowering the voltage, if cpuidle is working correctly there'd be no benefit from running at a lower frequency than the lowest defined OPP Feb 08 10:37:03 (OPP = Operating Performance Point, combination of clock frequency settings and supply voltage settings) Feb 08 10:37:08 Oh ic Feb 08 10:37:18 That's good to know Feb 08 10:39:11 as for building a customized kernel (which I might add you don't need if you just want to customize the DT), see: https://pastebin.com/eLhrp1Hg ... for the BBAI you need the -ti kernel series Feb 08 10:39:39 I was worrying, as I'd like to use with as low noise as possible, I gathered the shedutil governor does a fantastic job on thermal thotteling (at leas I assume that's what is responsible for it) Feb 08 10:40:39 i cloned the https://github.com/beagleboard/linux/ assuming it contains all the needed pathces Feb 08 10:40:58 it does but I'd still recommend using the build repo instead Feb 08 10:42:32 you can just run its ./build_deb.sh and it'll git-clone the upstream kernel tree, apply the patches, apply the defconfig, run menuconfig to give you an opportunity to customize the kernel config, compile the kernel, modules, and dtbs, and builds a debian package from it Feb 08 10:44:11 that's most appreciated, although I might not recoompile it at all for now, after hearing that 450MHz might be out of spec. Feb 08 10:44:30 and adding it doesn't require rebuilding the kernel Feb 08 10:47:04 How would I do that? Feb 08 10:48:19 and it's not that it's "out of spec", you can of course always run at a lower clock frequency, it's just that _if_ cpuidle is working correctly (it seemed broken last time I checked, which was a while ago) running at a lower frequency than the lowest defined OPP should actually cause _higher_ power consumption for the same workload Feb 08 10:49:05 because it would mean each unit of work takes more time, thus the cpu will idle less Feb 08 10:49:43 makes perfect sense, the powersave?ondemand governer on Kernel 4 was unbearably slow Feb 08 10:49:57 keeping the CPU under high load all the time Feb 08 10:50:32 frequency scaling is a completely separate matter from what I'm talking about though Feb 08 10:51:51 Shure, but as it almost exclusively was running on 450MHz it gave a good look at low frequency operation. so to speak. Feb 08 10:55:13 On a quick glance there exists a opp_table, you are implying this can be modified at run time or do i need to modify the dts? Feb 08 10:57:40 you can modify the DT, easiest using an overlay but you can also just create a customized dts using https://github.com/beagleboard/BeagleBoard-DeviceTrees (pick correct branch for kernel series) ... Feb 08 10:58:13 I'll figure, thank you very much. Feb 08 11:02:40 On a totally different matter. I'm running a BBB with the Waveshare-RS485-Can Cape, during boottime it completely blocks my CAN bus until boot has been completed. This is probably due to some pins are at specific states on power up. Is there anything I can do to alter some of those states? Feb 08 11:04:43 if it's the default pinmux causing it, you could configure that in u-boot Feb 08 11:05:02 that would reduce the time at least Feb 08 11:05:58 default pin level should be ensured by external pull-up/down (whichever CAN needs, probably pull-up) Feb 08 11:06:13 so that would be a deficiency of that waveshare cape Feb 08 11:06:25 do the pins default to input? Feb 08 11:06:29 yes Feb 08 11:06:42 All of them? Feb 08 11:06:45 yes Feb 08 11:07:36 and they have either weak pull-up or weak pull-down by default, but that varies per pin Feb 08 11:07:59 that should be perfect, thes cape is crap anyway I have to exchange it for something better like comms. Feb 08 11:08:21 so if the default pull is inconvenient for the specific application and there's no alternative pin available that has the desired default pull, the default pull should be overridden using stronger external pull Feb 08 11:08:35 in cases where the default level at power-up is important Feb 08 11:09:23 It's a RS485/CAN cape which provides CAN OR RS485 so not recommendet anyways Feb 08 11:09:36 yeah I think I've seen that cape, it looked like a mess Feb 08 11:10:27 But sadly much more readily available than the Comms cape Feb 08 11:10:53 I mean, you can probably find some CAN transceiver breakout and just wire that up directly Feb 08 11:14:46 I was planning on a homegrown cape, but you are right, I have some tranceivers around. As of now the reboots are seldom enough to be not a big issue, if it could have been fixed in soft it would be a quick fix. Feb 08 11:15:33 well you can't fix the default level at reset in software, all you could hope to do is reduce the time until the pinmux is set correctly Feb 08 11:15:40 using an overlay instead of config-pin would help Feb 08 11:16:10 That I have already implemented. Feb 08 11:17:05 The acceptance for non working light switches is not great though. ;) Feb 08 11:17:29 ? Feb 08 11:18:05 Our light switches are failing if the CAN bus is blocked. Feb 08 11:19:45 The BBB is implementing the can2mqqt, mqtt, node-RED part of my home automation. Feb 08 11:21:10 I see Feb 08 11:21:30 then I'd suggest adding a pull-up resistor Feb 08 11:21:46 assuming my memory is right about can-tx being idle high Feb 08 11:22:00 (I've only very briefly done anything with CAN, a long time ago) Feb 08 11:22:36 I'LL probably do just that, maybe I can utilize one of the many jumpers *rolleye* Feb 08 11:23:22 Many tranceivers sport a enable pin which would be even better Feb 08 11:30:36 Great,the tranceivers I use on the other nodes (sn65hvd232) even supports just that exact use case as if the input is high impedance the output get's recessive. so the designers of that cape must have really screwed thinggs up. Feb 08 11:31:57 And yes pull-up would be correct, or everything not pulling down in that case. Feb 08 11:38:41 yeah so they must have used pins that have default internal pull-down Feb 08 11:40:10 you can find the default pull direction for pins on the P9/P8 tabs of my pins spreadsheet: https://goo.gl/Jkcg0w#gid=1775283126 Feb 08 11:47:27 Sou your suggesting, that those internal pulls are always present also on input, right? Feb 08 11:49:20 They must have srewed it internally as all the CAN related pins are pulled high, as seems reasonable. Feb 08 11:52:27 Whatever, thank you so much, this was most informative. Feb 08 11:52:36 the internal pulls are configurable along with pinmux; the default is gpio mode with either internal pull-up or internal pull-down enabled (and all gpios default to input) Feb 08 11:52:58 hmm, what pins does it use though? Feb 08 11:53:12 since the options I see for CAN all seem to have internal pull-up Feb 08 12:01:36 it can be choosen by the jumpers, I opted for can0 so probably the TX gets loaded low on the cape somehow. Feb 08 12:05:02 I'm too lazy to check the schematic, but I vaguely recall this cape can create a drive conflict on the can tx input by cross-connecting it to rs485 rx Feb 08 12:06:48 needless to say, if I indeed remember this correctly, it is important to ensure this drive conflict doesn't happen, either via jumper settings (if that can fix it) or by not using this cape :P Feb 08 12:11:15 Schematic is not available (any more!?) but The RX/TX of CAN is hard wired to TX/RX of the RS485 tranceiver, so what could poossibly go wrong. *rolleye* Feb 08 12:11:51 note that RX of can is connected to TX of RS485 and vise versa. Feb 08 12:14:32 Maybe I simply apply my heat gun to that RS485 tranceiver. Feb 08 12:15:03 https://www.waveshare.com/img/devkit/accBoard/RS485-CAN-CAPE/RS485-CAN-CAPE-3.jpg for reference, makes no sense at all. Feb 08 12:15:08 okay so there's your problem: drive conflict Feb 08 12:16:00 so the can being dominant during powerup is the least of your problems, you're probably damaging the beaglebone (depending on how much current the rs485 rx output can sink) Feb 08 12:16:55 It's working now for the better part of the last 4 years, so not that big of an issue Feb 08 12:19:13 hmm, maybe the rs485 rx output can't sink enough current to be a problem Feb 08 12:19:24 so it's just acting like a strong pull-down Feb 08 12:21:59 Probably, I still don't get how this cape could have gotten designed this way. But ok there are alternatives. Feb 08 12:22:29 because it was designed without attention or competence? Feb 08 12:22:57 good work guys Feb 08 12:24:02 It's such a niche product I had expected better, but ok then. Feb 08 12:24:08 like, you could just as easily ask why the beaglebone green wireless sacrifices a whole bunch of expansion header pins for its wifi chip while leaving the pins formerly used for ethernet (which happen to have everything you need for that wifi chip on alternate mux modes) unused Feb 08 12:24:56 which wifi chip does it use? Feb 08 12:25:44 same as BBBW, wl1835 Feb 08 12:25:57 sdio? Feb 08 12:26:21 oh my, good think I not got that one. Those thiongs are easy to miss before an purchase. Feb 08 12:26:40 sdio for wifi, uart for bluetooth, optional bluetooth audio Feb 08 12:27:12 and none of them work quite right, I guess Feb 08 12:27:14 wl18xx pinout options on the VDDHD5 ios (which are the ones used for ethernet normally): https://goo.gl/Jkcg0w#gid=146612406 Feb 08 12:27:23 mru: what do you mean? Feb 08 12:27:36 show me a wireless module that works properly Feb 08 12:27:42 and has mainline kernel support Feb 08 12:27:47 and isn't unobtanium Feb 08 12:27:55 wl18xx has mainline kernel support and seems to work okay usually? Feb 08 12:28:04 like, not flawless, but okay Feb 08 12:28:20 hmm, why is it so rare then? Feb 08 12:28:34 expensive? Feb 08 12:28:40 dunon Feb 08 12:28:42 *dunno Feb 08 12:29:07 everybody seems to use nasty chinese things with no documentation and worse drivers Feb 08 12:29:28 probably cheaper Feb 08 12:29:46 until you start counting support cost Feb 08 14:20:22 het Feb 08 14:28:00 i Feb 08 23:32:04 GenTooMan: I got that sucka' to show up! Feb 08 23:32:13 FLIR at its finest! Feb 08 23:33:02 * GenTooMan clears debris just in case. Feb 08 23:33:19 It seems there is an issue w/ two resistors on the BBGW that prevent spi0 from working correctly. Feb 08 23:33:33 So, chipped off and cleaned and poof! Feb 08 23:33:37 FLIR live! Feb 08 23:33:45 But... Feb 08 23:34:00 I cannot get the pop up on the LCD just yet and I am out of ideas. Feb 08 23:34:43 GenTooMan: Would you know how to get an app, Qt app, to show up on a LCD screen? Feb 08 23:38:43 I think I know now what I did wrong. Feb 08 23:38:49 Up, up, and Otay! Feb 08 23:42:50 Sorry I am not following what's going on very well. In order for GUI based application to show up on a display X support is required and display needs connected. Feb 08 23:43:23 That's the simple method, you don't HAVE to do that but in order to use a QT app you have to do it that way. Feb 08 23:45:23 Okay. Feb 08 23:45:45 My LCD is connected via many wires and the FLIR is a slave and the LCD is a slave to the master BBGW. Feb 08 23:46:42 So, my wires are set up to handle this idea of SPI0 for the master on CS, CLK, and MISO. Feb 08 23:47:28 For some reason, the Qt app does not pop up on the slim autoconfigured sign in screen on the LCD. Feb 08 23:48:08 is it installed? Feb 08 23:48:13 slim? Feb 08 23:48:17 or the qt app? Feb 08 23:48:30 Or the LCD? Feb 08 23:49:03 your QT app I'm most uncertain about slime but if you say so :D Feb 08 23:49:17 I have slim installed, qt installed, and the LCD is powered and connected via a lot of wires. Feb 08 23:49:35 is the LCD displaying anything? Feb 08 23:49:53 yes. Feb 08 23:50:00 It shows beagleboard.org and the beagle. Feb 08 23:51:05 I can show the script on vncserver but not on the pop up on the LCD for some reason. Feb 08 23:51:09 is the QT application listed in a menu item Feb 08 23:51:22 I have no menu(s) on slim. Feb 08 23:51:37 Hmm. Maybe I should have kept xfce4 instead. Feb 08 23:51:55 so how do you run an application under slime? Feb 08 23:52:18 It is booted from the get-go. I typed a couple of commands to run the script from boot. Feb 08 23:53:23 and how do you run an application under slim? or more appropriately how do you run anything under slim :D Feb 08 23:53:59 Ha. No clue. Feb 08 23:54:04 I really have no clue. Feb 08 23:54:10 Let me show you. Feb 08 23:54:35 well that might explain you difficulty. Feb 08 23:54:39 :D Feb 08 23:55:21 your even. I suggest you write down the details to run something under slim, you can't pick and choose after slim is running apparently. Feb 08 23:55:29 https://pastebin.com/VkUYtYUt Feb 08 23:55:51 Supposedly, that is supposed to handle the boot script. So, I thought? Feb 08 23:58:17 I thought that the '&' was for background processes. Feb 08 23:58:23 Let me go and check. Feb 09 00:00:44 that has naught to do with slim but it appears to be using openbox for the menu system. Feb 09 00:00:45 GenTooMan: Right, slim has no way to start or stop processes from the touch screen. Feb 09 00:00:55 Oh. Feb 09 00:01:10 Openbox has no way to start processes from the touch screen. Feb 09 00:01:31 That is why they are started in the .config file. Feb 09 00:01:34 it appears you are running everything BUT your QT application. Feb 09 00:01:39 Ha. Feb 09 00:01:57 So try starting it in the config file perhaps? Feb 09 00:01:57 The ./bbb file is the qt file. Feb 09 00:02:02 Okay. Feb 09 00:02:12 worse that could happen is it doesn't work. Feb 09 00:02:20 you are already that so no loss. Feb 09 00:02:29 Right, right. Feb 09 00:02:42 The line in .config is there right now. Feb 09 00:03:10 This, the line, is the ./bbb file starter script for the FLIR cam boot script. Feb 09 00:06:06 looks like the autostart file is running bbb for the lepton module but ... Feb 09 00:06:53 But not the qt app. Got it. Feb 09 00:07:13 Oh. Feb 09 00:10:35 Well anyway, I will start a server and see if i can get it showing. Feb 09 00:10:51 The LCD for now is out b/c I do not know enough or something. Feb 09 00:19:02 ha. Feb 09 00:19:16 It seems I need a mouse and keyboard for the Cape. Oops. Feb 09 00:24:43 don't you have a USB host port and a USB hub? Feb 09 00:24:52 Yes. Feb 09 00:24:57 I do, I do. Feb 09 00:25:02 I do! Feb 09 00:25:13 So, it is time. Feb 09 00:26:48 * GenTooMan waits several hours while actually doing something. Feb 09 00:31:59 Okay. Bootin' now! Feb 09 00:32:34 Right. Just wait and while waiting, a video will be on the way. Feb 09 00:37:53 right click! Feb 09 00:38:33 * GenTooMan quietly listens to the fireworks and rates them. Feb 09 00:38:47 Presidents Day fireworks? Feb 09 00:44:29 Poof, pow, bang, splash, spadoof! Feb 09 00:44:38 Oh and pop! Feb 09 00:55:42 Well... Feb 09 00:56:24 well Feb 09 00:56:43 I got nowhere b/c I received the red sqaure and not the video channel on the qt app. vncserver shows the live stream but the qt app, and maybe it was made this way, does not show the live stream of the FLIR cam. Feb 09 00:57:04 I will have to review some qt ideas. Feb 09 01:04:15 That makes no sense...right? What should stream on the server should stream on the LCD, right? Feb 09 01:04:31 I am running the same command w/ the same source. Feb 09 01:09:26 Anyway, probably the wiring. Let me double check. Feb 09 01:12:07 I got it. CS is impossible to get to right now for SPI_1.0 and the i2c channel for the Cape comm. Feb 09 01:26:51 So the only difference is the LCD correct? Feb 09 01:39:30 Supposedly. I got it. I goofed up the wiring w/ the wrong overlay. Feb 09 01:39:36 oops. Feb 09 01:39:41 So, rewiring now. Feb 09 01:39:57 what the overlay was wrong or the wiring was wrong? Feb 09 01:40:12 Neither/Both. Feb 09 01:40:21 My bad and board bad. Feb 09 01:40:33 The BBGW has an issue w/ the SPI1. Feb 09 01:41:06 So another axiom of the past flares up. Measure twice cut once... Feb 09 01:42:11 That and measure once cut twice? Feb 09 01:42:20 bzzt, bzzt? Feb 09 01:43:06 seems to be your motis operandi unfortuitously. Feb 09 01:51:45 It seems CS is needed twice, i.e. CS1 and CS2 for the FLIR and LCD. Feb 09 01:52:05 But...I thought I would tie in MISO and CLK. Feb 09 01:52:32 So, would I really need more than one SPI channel to handle both slaves from the BBGW master? Feb 09 01:57:30 Or...is using multiple CSs from the BBGW okay? Feb 09 02:22:48 set_ how can you read from the FLIR and LCD without having separate CS outputs? Answer is you can't. Even if you used one SPI port for both. Feb 09 02:23:21 secondly the CS can be automatically controlled but it's best not to do that. Feb 09 02:24:23 Right. Feb 09 02:24:30 I just figured that out. Oops. Feb 09 02:24:49 LCD Pins and i2c are for the LCD. Feb 09 02:24:55 Ha. Feb 09 02:25:10 shocking isn't it Feb 09 02:25:55 I know. I think I am learning a valuable lesson by workin' on this idea. Feb 09 02:26:03 Not everything is interconnected. Oops. Feb 09 02:28:42 also have you written anything down? Feb 09 02:28:57 * GenTooMan gives a notoriously loud cough afterward. Feb 09 02:39:15 Ha. Feb 09 02:39:26 Give me five minutes and then I will record video. Feb 09 02:39:50 double checking here! Feb 09 02:40:12 umm no it's more important you take notes so you remember what you were doing. I have had to do that myself and I use to have near total recall. Feb 09 02:42:44 Okay. I cannot take notes now. I am having too much fun ringing in circles. Ha. Feb 09 02:49:51 Oh well. Five minutes are up and it is over. I have to cancel operations for now. Feb 09 02:49:54 Boo! Feb 09 02:50:05 I cannot get the FLIR to work just yet on the LCD. **** ENDING LOGGING AT Tue Feb 09 03:00:29 2021