**** BEGIN LOGGING AT Sun Jan 31 02:59:57 2021 Jan 31 15:57:27 thinkfat: I've had the same wish but I've not found any Jan 31 16:15:03 zmatt I assume that can't be done using the I2C enumeration for add on boards, I only recall pin configuration but nothing more Jan 31 16:15:57 GenTooMan: you mean cape autodetection? that has no direct influence on any aspect of the kernel, it is only used to select an overlay to be applied Jan 31 16:24:13 zmatt hmm no hook for drivers and configuration of anything attached. That has to be done in init.d then? Jan 31 16:24:45 that is all stuff configured it DT by the overlay Jan 31 16:24:50 *in DT Jan 31 16:25:40 capes normally do not cause any specific userspace activity (with a few rare exceptions hardcoded into rcn's scripts) Jan 31 16:28:55 I can see wanting but definitely now allowing such magic. It's the same issue windows had with USB and attacking machines via "Microsoft magic and hocus pocus" Jan 31 17:18:17 ehe Jan 31 17:18:22 sry Jan 31 17:19:21 when will there be response about the early bird applications for the risc-v beagleboard? Jan 31 20:25:02 Here is some source, https://pastebin.com/FrfRpGPw, but would I need to account for each, separate motor in another way? Jan 31 20:25:44 I am asking b/c the source seems to think that one "state" controls all motors at once instead of by themselves as a single entity. Jan 31 20:26:17 Would I need something like a single function in Python to handle each, separate motor? Jan 31 20:27:19 So...def MotorOne(state, v1): && another one as MotorTwo(state, v2): and so on? Jan 31 20:36:30 I am handling four dc motors, linear actuators, on the BBBW and MotorCape w/ GPIO as on/off and PWM w/ duty_cycle and period. Jan 31 21:37:50 Well, I got it sort of. Jan 31 21:38:49 So, the motors each handle their own UI interface node but the source is iffy b/c 0 overwrites 0 in the source, i.e. so I had to use 0, 1, 2, 3 instead of 0, 0, 0, 0. If that makes sense. Jan 31 21:40:35 So, in instead of each motor(1 - 4) stopping at 0, one must be slowly moving w/ a 1% duty_cycle and so on w/ the other motors. Jan 31 21:40:37 Blah. Jan 31 22:25:20 Anyway, I had to perform a lot of reiteration, something that is frowned upon in the programming field. I will keep testing until the bot is active and working. Jan 31 23:49:20 garsh constant broken pipes Feb 01 01:40:30 ayjay_t: time to call a plumber ;) Feb 01 02:28:42 I wish I needed a plumber? Feb 01 02:28:45 Ha. Feb 01 02:41:41 Does anyone have a clue as how to solve my issue of this source, https://pastebin.com/EZUdgQ5H, and it currently not accepting more than one 0 value for motorNumberTwo. Feb 01 02:41:41 ? Feb 01 02:43:05 For instance, I use the value 0 (duty_cycle) to stop the bot on one motor. But motor number two throws an error if I put a value of 0 (duty_cycle) in the place where the value 0 "belongs." Feb 01 02:43:42 Do I need to work towards the beginning of the source or later in the source to handle this issue? Feb 01 02:51:48 All the legs work. This is good news and the value for duty_cycle close to 0 all stop the motors but do not disable the line/pin. Feb 01 02:51:52 This is the issue. Feb 01 02:52:50 I cannot disable the pin w/ the values 1 or 2 or 3. It has to be 0 but my source is laughing in my face every time I type 0 in its respective place. Feb 01 02:53:23 Anyway...I will try to get this source out and see if anyone has a clue. **** ENDING LOGGING AT Mon Feb 01 02:59:57 2021