**** BEGIN LOGGING AT Tue Jun 23 03:03:14 2020 Jun 23 03:06:58 what is the difference between 5V VDD Jun 23 03:07:01 and 5V sys Jun 23 03:07:49 and would anything cause the VDD to stop working Jun 23 03:08:31 KenUnix came back trippin'. Jun 23 03:10:39 quiet today Jun 23 03:12:31 MattB0ne: vdd_5v is primarily a way to supply power _to_ the BBB as alternative to usb or the 5V barrel... it actually ties directly to the 5V barrel Jun 23 03:12:51 sys_5v is the switched 5V output from the BBB for external use Jun 23 03:13:18 ok Jun 23 03:14:26 so I got my LED wired up Jun 23 03:14:31 (sys_5v is also the main internal supply from which all 3.3V and lower voltage supplies are generated) Jun 23 03:14:44 checked with 5V output so the bread board circuit is correct Jun 23 03:14:51 the ecap code is working Jun 23 03:15:11 and my pins are setup without any conflict on the pull up/down Jun 23 03:15:22 anyway, I'm off to bed Jun 23 03:15:38 I cannot see the thing flicker though I have it set for 0.5 hz Jun 23 03:15:39 ok Jun 23 03:18:49 Hey! Jun 23 03:20:51 I am using the ServoCape and I need to know something; does the file /sys/bus/i2c/drivers/pca9685-pwm/ have any files in it to you? Jun 23 03:21:11 I only have bind, uevent, and unbind for some reason. Jun 23 03:26:24 Those three files do not lead me to another directory. They are all just files that are unusable for now. Jun 23 03:37:10 I am trying to compile a .c program now. How can I use sqrt and pow w/ #include ? Jun 23 03:37:19 I am receiving errors and it is getting funky. Jun 23 03:40:19 Was math.h taken off the BBB for any reasoning? Jun 23 03:45:42 I am chatting w/ myself again. Later for now. Jun 23 03:46:55 Sorry. math.h was not taken away. I am getting a linker error. Sorry. Jun 23 03:48:21 Off to read about the darn other section of the C library for the math section. Sheesh. Who'd a thunked it? Jun 23 03:57:14 good luck Jun 23 03:59:06 https://pastebin.com/w8SD2wVT is my error is you know anything about linking and .c files. Jun 23 03:59:17 Thank you. Jun 23 04:13:54 set_: add the -lm linker flag Jun 23 04:14:00 (to link to the math library) Jun 23 04:15:23 Okay. Jun 23 04:15:47 I just tried to turn it to an object file to run both in compilation mode. Was that a mistake? Jun 23 04:16:01 I have no idea what you mean by that Jun 23 04:16:06 I then tried to use libtool. Jun 23 04:16:17 please don't Jun 23 04:16:19 https://www.gnu.org/software/libtool/manual/html_node/Creating-object-files.html Jun 23 04:16:21 Okay. Jun 23 04:16:23 Sorry. Jun 23 04:17:25 That worked. Sheesh. Jun 23 04:17:46 also, instead of manually invoking the compiler it's easier to use make. just create a Makefile containing something like: https://pastebin.com/LWHvBRHW and you can simply type "make" Jun 23 04:18:23 Okay. Jun 23 04:18:31 anyway, back to attempting to sleep Jun 23 04:18:34 I looked over the paste. Jun 23 04:18:38 Sleep! Jun 23 04:18:46 Thank you. Jun 23 09:00:40 lol: https://pastebin.com/RAMgL91f Jun 23 09:12:07 I wanted to import the CAD File BB_X15_revB1_public.brd found on the Github Repo, but it requires an additional library which could not be found. Whre can I find this library or a working CAD file showing the outline of the beagleboard-X15? Jun 23 10:38:56 what would be a minimal xorg install for the BBB? It pulls a lot of stuffs i guess is not useful (like "xserver-xorg-video-radeon") but i don't know what's needed Jun 23 10:39:22 define need Jun 23 10:39:59 running a wxWidgets GUI app in "kiosk mode", the display being a LCD4 cape Jun 23 10:40:22 do you have it working? Jun 23 10:41:21 i have another BBB with openbox (and so xorg) and it works, yes. I would like to keep the new BBB i'm configuring to the "minimum" Jun 23 10:42:09 check the log file and see what it's using Jun 23 10:42:34 I guess some fbdev variant or whatever it's called these days Jun 23 10:43:05 i'm somewhat a noob for linux. What log? Jun 23 10:43:29 the X log, probably /var/log/Xorg.0.log Jun 23 10:49:53 @mru: would you teach me what to look for, in that log? Jun 23 10:52:34 https://pastebin.com/aACP3E1j Jun 23 10:53:09 yeah, it's using fbdev Jun 23 10:54:18 so what's the answer to my initial question? Jun 23 10:54:22 or how i get it? Jun 23 10:58:01 you can get a list of the modules it loads by looking for "Loading" lines Jun 23 10:59:46 in your case, this is the list: https://termbin.com/jw41 Jun 23 11:00:00 now match those files to xorg-foo packages Jun 23 11:00:44 you'll obviously also need some generic packages like xorg-server Jun 23 11:01:11 the exact names depend on what distro you're using Jun 23 12:08:21 thanks mru, i looking at it now Jun 23 14:37:32 there's a way to show an image during boot? i may don't mind the penguin (which is by kernel, i believe), but showing the company logo instead of the black screen until the GUI is ready could be nice. Jun 23 14:38:15 i see raspebbry related post about this but are 5/8 years old and i learned to avoid obsolete tutorials. Jun 23 16:48:08 zmatt: I got my LED flickering Jun 23 16:48:15 woohoo!!!! Jun 23 16:48:23 you must cherish the small victories Jun 23 16:50:23 A journey of a thousand miles begins with a single step Jun 23 16:50:48 couple questions 1) could I change those settings while the core is running. You stated that I could write to ECAP_LD_MAXIMUM and ECAP_LD_COMPARE after initialization but I am wanting to do so while running so I could ramp motor speed Jun 23 16:51:47 RobertClean: indeed.... this aside has been frustrating and fun at the same time Jun 23 16:52:02 I also officially ruled out a career in embedded systems LOL Jun 23 16:52:35 i was reading that they get all the responsiblity but no salary premium because managment doesnt understand their importance Jun 23 16:53:02 granted you need to take internet grievance with a grain of salt but I could see it being somewhat thankless Jun 23 16:56:57 2) I have no means of stoping the PRU from python do I? Jun 23 16:57:18 I tried halt() I did not get an error but it doesnt stop the light from doing its thing Jun 23 16:58:16 MattBOne, it definitely is something you have to want to do. Mind you appreciation varies, one company had key man insurance on me., other's completely ignored my adivice in favour of their own pre-determined solutions. Jun 23 17:11:51 well that is certainly a broad spectrum Jun 23 17:12:29 i think I see it being a big thing going forward with the IOT push Jun 23 17:12:33 and AI being a thing Jun 23 17:13:22 thanks for the referral for robotdigg btw Jun 23 17:13:32 great website Jun 23 17:13:54 wish I would of found it earlier. I thiink my PI is gonna want to see how far we can get with my gear motor but Jun 23 17:14:17 I will try and push for an upgrade to some of the parts offerred here Jun 23 17:14:38 and my personal project of making an auquaponics system Jun 23 21:39:15 On my servoCape, how can I test to see if the 5v IN MAX screw terminal works or not? Jun 23 21:39:55 Like I said before today, the terminal is loose but I do not know how I can test to see if indeed it needs to be taken off. Jun 23 21:45:51 the what? Jun 23 21:47:28 oh that, because of course they didn't bother labeling the connectors on the silkscreen with the same names as in the schematic Jun 23 21:49:39 Yea. Jun 23 21:49:45 It is the 5v input. Jun 23 21:50:00 The 5v input for the Cape is a screw terminal. Jun 23 21:50:20 I mean, it's just to power the supply pin on the servo outputs Jun 23 21:50:46 that's all it's for, so it's entirely up to you whether you want to use it at all Jun 23 21:51:05 it's not used to power anything on the cape itself Jun 23 21:51:12 Oh? Jun 23 21:51:38 So, if I do not power that 5v screw terminal, I can still use the Cape? Jun 23 21:51:59 of course, the cape is powered by the beaglebone Jun 23 21:52:06 like any cape Jun 23 21:52:47 That is what I thought. It seems like people, GenTooMan and another individual, are thinking the Cape is powered by way of the 5v input screw terminal. Jun 23 21:53:00 Okay, okay. Jun 23 21:53:35 that would be nonsensical Jun 23 21:53:43 Okay. Jun 23 21:54:34 So, the Cape is not powered externally unless i need to have a dedicated supply outside of the Cape functionality? Jun 23 21:55:07 the cape is not powered externally, period. it's powered by the 3.3v supply of the beaglebone Jun 23 21:55:49 Oh. Jun 23 21:56:02 and for your convenience you can optionally provide it with some supply that's passed to pin 2 of each output header Jun 23 21:56:26 Okay. Jun 23 21:57:25 P9? Jun 23 21:57:39 Oh. Jun 23 21:58:22 GND and 3.3v only, got it. Jun 23 22:00:17 @zmatt: There is this fellow. He seems to think that w/ a particular overlay, the ServoCape can be controlled via the file system onboard the BBB. Jun 23 22:01:09 Do you think that statement can ever be true? Jun 23 22:04:43 The files should be listed here but, /sys/bus/i2c/drivers/pca9685-pwm/2-0070/pwm/pwmchipX, the files stop at /pca9685-pwm/ on my system w/ the required overlay. Jun 23 22:05:16 yes the kernel has a driver for the pca9685, I've mentioned that Jun 23 22:06:15 Yes. But, my filesystem stops at /pca9685-pwm/bind /uevent and /unbind. Jun 23 22:06:17 then the overlay isn't working Jun 23 22:06:26 I cannot do anything w/ those three files. Jun 23 22:06:30 Okay. Jun 23 22:06:32 No issue. Jun 23 22:06:36 * GenTooMan peers and looks a trite confused. Jun 23 22:06:39 you are not expected to do anything with those files Jun 23 22:06:56 * set_ GenTooMan sold set_ bad info! Jun 23 22:07:12 @zmatt: Okay. Jun 23 22:07:24 to clarify what the screw terminals connect to: https://liktaanjeneus.nl/servo-cape.png Jun 23 22:07:31 I am stuck like Chuck. Jun 23 22:07:32 (green = GND) Jun 23 22:08:29 Okay. I got it. So, please let me get this correct... Jun 23 22:09:20 The Cape is powered "internally" by the BBB via 3.3v (as usual), the Cape can be powered externally via 5v MAX to make the servos work, and has to be grounded at any of those pins? Jun 23 22:09:43 ehh what Jun 23 22:09:54 `lol Jun 23 22:09:58 Okay... Jun 23 22:10:10 So, the 5v MAX is what comes out of the Cape? Jun 23 22:10:27 I have no idea why they labeled it "5V max" Jun 23 22:10:45 it doesn't connect to anything on the cape, so I don't understand why they claim to care Jun 23 22:10:53 Oh. Jun 23 22:10:54 Okay. Jun 23 22:10:59 zmatt: if I wanted to stop the pwm with a firmware that lacks a HALT I would need to incorporate an interrupt right ? Jun 23 22:11:21 MattB0ne: I am almost done. Please hold. Jun 23 22:11:30 ok Jun 23 22:11:34 set_: whatever voltage you want to come out of pin 2 of the servo output (if any) is what should go into those screw terminals Jun 23 22:11:34 Thank you, sir. Jun 23 22:11:46 Okay. Jun 23 22:11:55 GOt it. SO, it is an output? Jun 23 22:11:56 MattB0ne: I see you're teaming up with set_ in trying to make me as confused as possible Jun 23 22:12:02 Ha. Jun 23 22:12:06 set_: no Jun 23 22:12:11 No? Jun 23 22:12:14 (evil grin) Jun 23 22:12:15 Aw! Jun 23 22:12:30 set_: see the red line? that's everything it connects to Jun 23 22:12:36 how can it be an output? Jun 23 22:12:41 I see the photo you provided. Jun 23 22:12:46 Internally? Jun 23 22:12:46 what would it output? where would that output come from? Jun 23 22:12:52 BBB? Jun 23 22:12:55 it's not connected to anything internally Jun 23 22:12:59 it's not connected to the BBB Jun 23 22:13:00 Okay. Jun 23 22:13:01 ? Jun 23 22:13:12 Let me review this photo again. Jun 23 22:13:21 the red line shows literally _all_ it connects to: pin 2 of each servo header Jun 23 22:13:25 that's it Jun 23 22:13:54 it just goes from one external connector (the screw terminal) to other external connectors (the servo headers) Jun 23 22:14:09 So, I have to power the HEader Pins on the Cape w/ the positive of the 5v IN MAX? Jun 23 22:14:16 What? Jun 23 22:14:20 AAAAAAAAAAAAAAAAAAAAAAAAAA Jun 23 22:14:22 Ha. Jun 23 22:14:37 SErvo Headers. Yes sir. Jun 23 22:15:10 set_: okay, I'm putting you on /ignore for now before my brain starts to leak out of my ear Jun 23 22:15:32 So, I use a wire! This wire goes to positive on 5v IN MAX to the Servo Header? Jun 23 22:15:44 my turn my turn Jun 23 22:15:48 Fine. Jun 23 22:15:50 MattB0ne: there's generally no reason to stop ecap once you've started it, just set the duty cycle to 0 Jun 23 22:15:58 ok Jun 23 22:16:03 whether you do that via py-uio or using pru doesn't matter Jun 23 22:16:09 ok Jun 23 22:16:18 and I don't understand what you mean by "that lacks HALT" or why you think you need an interrupt Jun 23 22:17:27 hmm actually it has a halt. Jun 23 22:18:18 so here is a recap First I did all the hardware testing with the multimeter and breadboard and confirmed my circuit with the led and resistor was correct. 2 Jun 23 22:19:01 okay, so you've confirmed the pwm output is working? Jun 23 22:19:11 using py-uio ? Jun 23 22:19:12 When I ran the code I would not get voltage from P9_42 and the LED would not flicker. I referred to our past convo saying that the snippet you provided does all the initialization Jun 23 22:19:17 yes I got it to work Jun 23 22:19:20 now I want to stop it Jun 23 22:19:23 it doesnt stop Jun 23 22:19:31 of course it doesn't stop Jun 23 22:19:48 py-uio is merely changing the settings of the hardware pwm controller Jun 23 22:21:04 OK, so I edited the firmware to do nothing but the run part Jun 23 22:21:27 added a load and run command to the python script and it works Jun 23 22:21:40 so I wanted to do something like stop it from a gui Jun 23 22:21:51 but first I wanted to do a timed start and stop for 10 seconds Jun 23 22:22:17 so right now I tried sleep(10) then core.halt() obviously that did not work Jun 23 22:23:01 what was the core doing that you thought there was any point in halting it? Jun 23 22:23:43 what were you using the core for at all in your test? given that you were going to use py-uio to initialize ecap, and it doesn't sound like your test was doing anything yet besides initializing it Jun 23 22:23:43 the ecap is completely distinct from the PRU core ? Jun 23 22:24:12 yes, it has nothing to do with it Jun 23 22:24:31 my thinking was py-uio to set variables and the PRU to run it. But it sounds like there is nothing to run Jun 23 22:24:45 i started tinkering with it since it was not working otherwise Jun 23 22:24:48 pruss contains two pru cores, some memories, and a bunch of peripherals, all connected via a local interconnect... ecap is one of those peripherals Jun 23 22:25:21 ecap can be configured/controlled via py-uio, by one of the pru cores, or any mix thereof Jun 23 22:25:57 so I may be mixing things then Jun 23 22:26:12 here is my script Jun 23 22:26:45 to stop the pwm output you'd do pruss.ecap.pwm.ld_compare = 0 in python Jun 23 22:26:52 https://pastebin.com/KhRVQc4C Jun 23 22:26:53 ok Jun 23 22:27:02 or if pru wants to do it, you'd do something like: https://pastebin.com/raw/b2RbB6cN Jun 23 22:27:32 please look at what you're pasing before you share a link... it's garbage gagain Jun 23 22:27:38 *what you're pasting Jun 23 22:27:55 https://pastebin.com/X4sViX4j Jun 23 22:28:11 The Cape does not have Singal In on it. The header for Signal In is not on my Cape. Jun 23 22:28:13 lol that was my firmware Jun 23 22:28:20 I mean all the ~ ~ ~ ~ Jun 23 22:28:25 oh Jun 23 22:28:31 sorry will trim next time Jun 23 22:29:01 so I do not need the load or run at all Jun 23 22:29:24 well your initialization will set the pwm output to 0% Jun 23 22:29:30 your pru program set it to 50% Jun 23 22:30:10 i see i see Jun 23 22:30:24 let me mess with it and drop the firmware Jun 23 22:33:00 also, your pru program is once again missing a halt at the end, at least in what you pasted Jun 23 22:33:28 i did not grab that last line it is there Jun 23 22:33:35 ok Jun 23 22:33:57 anyhow, that also means that core.halt() is quite pointless: your pru program executes two instructions and then halts Jun 23 22:34:53 so it'll be halted so fast that it'll probably be halted before core.run() has even returned in python Jun 23 22:35:00 lol Jun 23 22:35:41 also is it necessary to do the offsets and stuff since py-uio was setting all these values Jun 23 22:36:05 I assume py-uio may put them in different spots rather than the offsets specified here Jun 23 22:36:08 if you mean all the #defines, those are just constants Jun 23 22:36:19 no, they're describing the structure of ecap Jun 23 22:36:29 py-uio has no influence over that Jun 23 22:37:12 but you don't actually need all those constants in python if you're doing initialization in py-uio. as shown in the snippet I gave only 10 minutes ago: https://pastebin.com/raw/b2RbB6cN Jun 23 22:37:56 whether you prefer to make the 0x14 a named constant or have a comment explaining what the store does is up to you, it's just about aesthetics and readability Jun 23 22:38:06 ok Jun 23 22:38:17 so I am going for the pure py-uio approach Jun 23 22:38:41 I mean, you obviously still need to be able to update the duty-cycle from pru, that was the whole point of this exercise Jun 23 22:38:49 and that's exactly what that snippet doet Jun 23 22:38:55 *does Jun 23 22:39:26 those two lines of pru code are equivalent to doing pruss.ecap.pwm.ld_compare = 0 in python Jun 23 22:39:34 (i.e. set the pwm output to zero) Jun 23 22:41:32 so no PRU here is my code which is not functional at the moment (no flicker) Jun 23 22:41:41 I will try and do it both ways for my learning Jun 23 22:41:42 https://pastebin.com/R1aJPWT9 Jun 23 22:41:50 this is pur py-uio Jun 23 22:42:39 pure* Jun 23 22:43:38 that looks like it should work Jun 23 22:44:17 doesn't =( Jun 23 22:44:26 please do not write to ecap.pwm.compare outside of initialization. after that, write to pruss.ecap.pwm.ld_compare instead (like I've been saying, many times) Jun 23 22:44:42 actually, you're setting it to 50 cycle width, i.e. a pulse of 250 nanoseconds Jun 23 22:44:51 I imagine you're not going to see that Jun 23 22:45:48 like, humans can see pretty brief flashes of light, but this might be a bit too difficult to see :P Jun 23 22:47:02 ok that was it Jun 23 22:47:06 too fast for my eyes Jun 23 22:47:14 yay Jun 23 22:47:45 another way to increase readability in pru code might be by using a macro: https://pastebin.com/raw/cQkG9EY4 Jun 23 22:47:45 OK I will skip town while I am ahead of the game and you are not super annoyed with me yet Jun 23 22:48:31 my HW for the night is to do this with the PRU Jun 23 22:48:45 but I have enough snippets from you to pull that off Jun 23 22:48:46 (this defines a "est_pwm" macro which you can then use later in your code as if it's a pru instruction) Jun 23 22:48:49 *set_pwm Jun 23 22:49:04 ok cool Jun 23 22:50:07 and optionally you can stick such macros into a header file that you #include from your main program, just to keep those ugly things out of sight ;) ehh I mean just to make those handy macros easy to reuse Jun 23 22:50:23 lol Jun 23 22:50:52 how would you rate your assembly skills Jun 23 22:51:05 i know you said you did not use python to frequently Jun 23 22:51:07 btw base register "c3" for sbco/lbco instruction refers to pru ecap (at least on the AM335x) Jun 23 22:51:18 py-uio is my only python project basically Jun 23 22:52:06 and you would know "c3" corresponds to that based on the TRM? Jun 23 22:52:09 "assembly" as a general term is fairly meaningless, since every cpu architecture has its own assembly, different from other cpu architectures Jun 23 22:52:34 so everything I am learning here is arm specific Jun 23 22:52:39 pru specific Jun 23 22:52:46 you're not writing ARM assembly Jun 23 22:53:41 how different is it moving from chip to chip Jun 23 22:53:56 I can see that being annoying having everything switch on you Jun 23 22:55:33 define "moving from chip to chip" ... PRU cores in different TI SoCs all work basically the same... there's one older revision of it on some older SoCs, but since the AM335x there has not yet been any changes to the PRU core itself (although extra stuff has been added to the PRU subsystem) Jun 23 22:56:16 there are definitely similarities between PRU and other modern 32-bit RISC cores like ARM, although also many differences Jun 23 22:56:49 but e.g. "add r0, r1, r2" means the same thing for ARM and for PRU: set r0 to r1 + r2 Jun 23 22:57:38 oh as for how you know what "c3" is: yeah it's somewhere in the TRM, or you can use this overview: https://pastebin.com/raw/JmbLe3T5 Jun 23 22:58:15 (this is for the AM335x specifically, other SoCs should have different values, corresponding to addresses that are likely to be useful for PRU programs) Jun 23 22:58:43 ok cool. I think that is enoguh info for today my head will explode =? Jun 23 22:59:06 I will leave you to the relentless onslaught known as set_ Jun 23 22:59:09 lol Jun 23 22:59:11 swollen head syndrome can be dangerous to those around you too.. :D Jun 23 22:59:17 oh I still have him on /ignore Jun 23 22:59:35 also, I lied, PRU "add" is equivalent to ARM "adds", not "add" Jun 23 22:59:43 just realized that Jun 23 23:00:04 and messy if it explodes Jun 23 23:00:13 that is why I tap out quick Jun 23 23:00:34 I can probably drive the UART stuff completely through py-uio as well Jun 23 23:00:40 but I will save that for tomorrow Jun 23 23:00:54 thank you sir Jun 23 23:01:11 with set on ignore no one can see what he types Jun 23 23:01:13 yep, you can use it to initialize the uart and tell the load cell to start continuous transmission Jun 23 23:01:19 I can't see what he types Jun 23 23:01:35 lol Jun 23 23:01:40 /ignore is a client-side thing, it doesn't affect anyone but the person who uses it Jun 23 23:02:04 basically anything set types is ignored is all it does. Jun 23 23:34:20 I am ignoramous at all times b/c you people, you people. Jun 23 23:34:41 Aw! Jun 23 23:35:53 Will someone in their right state of mind tell me how this darn Cape works already? Jun 23 23:36:02 Jesus, man. Jun 23 23:36:36 I am over here trying to push some buttons and yelling. it is not working, okay! Jun 23 23:37:28 Oh and I do not know if you read what I typed earlier. The SIGNAL IN on the Cape is not populated. Jun 23 23:37:42 I do not have the dang pins on my Cape! Jun 23 23:37:50 That is partially why I did not understand. Jun 23 23:42:27 ... Jun 23 23:42:39 Okay. Please forgive me. /me I like bacon. Jun 23 23:42:41 Ha. Jun 23 23:44:05 link to cape Jun 23 23:44:15 which ape? I mean cape Jun 23 23:47:31 SErvoCape! Jun 23 23:48:09 down the page: https://beagleboard.org/capes Jun 23 23:49:08 GenTooMan: Please leave me alone. YOu told me to plug in 5v from the BBB to the Cape. Jun 23 23:49:23 You are lower than low. YOu are a bad boy. Jun 23 23:49:49 Oh! ANd... Jun 23 23:50:02 You told me to plug the LED right into the BATTERY 12V! Jun 23 23:50:09 Sheesh. Jun 23 23:50:12 Just quit it. Jun 23 23:51:24 GenTOoMan: They are making another Super Collider! Enjoy. Jun 23 23:51:41 hmm I think something happened several moons ago huh? Jun 23 23:51:55 Moonie took teh cake, yep. Jun 24 00:55:59 set_: Try following this -> https://lorforlinux.github.io/GSoC2020_BeagleBoard.org/2020/06/20/testing-servo-cape-on-BBBW/ to test your Servo cape :) Jun 24 00:56:39 You Rule! Jun 24 00:56:55 I am learning from my BOOK! I will test it soon! Jun 24 00:57:33 I forgot I had an LPIC-1 book laying around covered in dust. Jun 24 00:57:56 It is actually a neat read w/ a TON of info. Jun 24 00:58:35 no problemo, let us know how it goes! Jun 24 00:59:35 Yes sir. Jun 24 00:59:53 I should test it right now. Jun 24 00:59:56 Brb Jun 24 01:04:27 Getting close...I feel like it is Thanksgiving dinner all over again! Jun 24 01:07:42 lorforlinux: Sir, the "issue" I found so far is this... Jun 24 01:08:44 the dir. /sys/class/i2c-adapter/i2c-2/ has a file but it is not 2-0070. It is 2-007f. Jun 24 01:11:21 what's inside that directory? Jun 24 01:13:45 I suggest you to start all over again, remove the previous overlay file by executing `sudo rm /opt/source/bb.org-overlays/src/arm/BBORG_SERVO-00A2.dts` Jun 24 01:14:16 modalias name of_node power subsystem uevent and etc... Jun 24 01:14:26 Okay. Jun 24 01:14:33 Restarting the whole thing again. Jun 24 01:15:30 just the .dts or the dtbo too? Jun 24 01:15:47 just .dts Jun 24 01:15:50 Okay. Jun 24 01:19:20 I am booting now. Please be patient. Jun 24 01:19:36 lorforlinux: you're using the pca9685's all-call address (0x70) ? a bit weird, but I guess it works and i has the benefit of being a valid address unlike its actual address (which the cape misconfigured to 0x7f, unless some of those solder jumpers are actually soldered on real devices) Jun 24 01:22:25 @zmatt: Hold on please. I am trying this technique for making the Cape work. Jun 24 01:22:37 lorforlinux: Okay. Jun 24 01:22:53 The filesystem is there now. Jun 24 01:23:26 So, I saw in your instructions that i need to put 5v to the screw terminal? Jun 24 01:23:28 Is that right? Jun 24 01:24:10 Is it okay if I put power to the screw terminal via the BBB's sys_5v? Jun 24 01:24:21 lorforlinux: also why are you using gpio-leds for a servo-enable signal? that's not a led Jun 24 01:24:28 Or...should i use vdd_5v? Jun 24 01:24:29 lorforlinux: use gpio-of-helper Jun 24 01:24:52 First I was using 0x7f but it didn't work, then i2cdetect was detecting something on 0x70 and jkridner also used 0x70 in beagle-tester for servo cape so I switched to that. I was confused why the address is 0x70 when all address pins are high? Jun 24 01:25:14 lorforlinux: read the datasheet :P Jun 24 01:25:38 yeah I got it after reading datasheet Jun 24 01:25:57 it's an "all-call" address that's at 0x70 by default, intended to configure multiple pca9685 devices at the same time Jun 24 01:27:09 normally you wouldn't use it when you only have a single device, but since the servo cape configured an illegal address as the primary address, I guess it's a usable workaround Jun 24 01:27:29 okay, I will update it to use gpio-of-helper! Jun 24 01:27:30 Illegal Beagle? That should be a Cape name! Jun 24 01:27:43 A turret or something... Jun 24 01:28:13 lorforlinux: it also feels a bit inappropriate that you're reconfiguring &i2c2, which is already configured and enabled by default Jun 24 01:29:05 set_ you can use any 5v source you have (old charger will work too). Jun 24 01:29:12 Okay. Jun 24 01:29:22 Thank you. Is 1A about enough? Jun 24 01:29:23 I'm also continually mystified by why the default DT uses such silly long names for pinmux nodes (a practice which everyone now seems to copy by example without thinking about why) Jun 24 01:29:41 depends on how much the servos you're connecting want Jun 24 01:29:44 set_: Jun 24 01:29:53 @zmatt: Can you see me again? Jun 24 01:30:07 since, like I've explained, with drawing, the only purpose of that supply is to power the servos Jun 24 01:30:11 it's not used on the cape itself Jun 24 01:30:44 hence, the voltage to be supplied is whatever voltage the servos need, the current required is the total current needed by the servos Jun 24 01:30:57 Okay. I am going to use the BBBW header pins to power the servos via the 5V IN MAX terminal block. Jun 24 01:31:05 vdd or sys? Jun 24 01:31:28 sys Jun 24 01:31:42 So, GenTooMan. YOu are off the hook. Thank you for participating when and now. Jun 24 01:31:53 sys! Okay. Jun 24 01:31:55 zmatt do you have any suggestion on better naming of the pinmux nodes? Jun 24 01:31:57 vdd should be considered an input to the bbb, not an output from it (although it's sometimes abused as such) Jun 24 01:32:16 vdd, an output. Okay. Jun 24 01:32:24 SOryr. input! Jun 24 01:32:33 lorforlinux: their node names only need to be unique within their parent (&am33xx_pinmux), as opposed to their labels which need to be globally unique Jun 24 01:32:43 lorforlinux: so it's really bizarre to use longer names for the node than for the label Jun 24 01:33:17 e.g. I'd do &am33xx_pinmux { some_thing_pins: some-thing { ... }; }; Jun 24 01:33:43 putting "pinmux" or "pins" in the name of a child node of a pinmux controller is completely redundant Jun 24 01:34:30 (and underscores in node names are also highly unusual, more typically dashes are used) Jun 24 01:34:35 Yeah, I guess it makes sense to use &am33xx_pinmux { some_thing_pins: some-thing { ... }; }; Jun 24 01:35:32 lorforlinux: also I'm puzzled by this... it looks like it's neither intended for overlay-utils nor for bb.org-overlays Jun 24 01:36:11 I don't know about dashes, I saw underscores more often. Jun 24 01:37:07 what do you mean by "it's neither intended for overlay-utils nor for bb.org-overlays" ? Jun 24 01:38:09 Hey! Jun 24 01:38:16 It worked and then busted on line 5. Jun 24 01:38:30 lorforlinux is Champion of the Servo! Jun 24 01:38:55 lorforlinux: I cannot tell you about how little I knew jumping into this Cape. Jun 24 01:38:56 lorforlinux: is this being preprocessed by some variant of my perl script? because otherwise it's not valid overlay syntax Jun 24 01:39:45 but my perl script implicitly inserts /dts-v1/; /plugin/; hence it shouldn't be in the source code then Jun 24 01:40:00 ServoCape and lorforlinux: Heave, HO, Heave, HO, Heave, HO! Jun 24 01:40:20 Way to go, mate. Jun 24 01:40:56 set_: you're giving conflicting feedback, you're cheering but you're also saying it busted on line 5 Jun 24 01:41:15 Right. Jun 24 01:41:21 It worked but then busted on line 5. Jun 24 01:41:32 I am just happy that pwm can solve this puzzling Cape. Jun 24 01:41:41 I thought I needed i2c. Jun 24 01:42:00 Drivers! Jun 24 01:42:26 zmatt No, I am not using any of your perl script to prepossess the DT, what's not valid about the overlay? Jun 24 01:44:01 set_ what do you see at line 5? Jun 24 01:45:32 Okay it's giving me the write error but during the first run only. Jun 24 01:48:13 Let me check. Jun 24 01:48:44 line 5: echo: write error: Invalid argument Jun 24 01:48:52 That is the error. Let me check the source. Jun 24 01:49:54 echo 0 > $servo1/enable Jun 24 01:51:00 it worked w/out error the second time. Jun 24 01:51:06 left right. Jun 24 01:51:31 lorforlinux: https://pastebin.com/wcMwbwfb Jun 24 01:52:08 lorforlinux: this is just a simple example, done in both normal overlay syntax (which can be fed directly to dtc) and the dtsi-style syntax used by overlay-utils (which requires preprocessing) Jun 24 01:53:18 Hey y'all? How is GSOC 2020 going? I totally forgot about the Summer season. Jun 24 01:54:37 updated to use &{/chosen} { .. }; instead of / { chosen { .. }; }; Jun 24 01:56:03 lorforlinux: so basically overlay-utils lets you write overlays in the same way you'd write fragments in a custom main dts Jun 24 01:56:58 with some case the exact same file could be used both as a .dtsi to #include in a custom dt as well as be built into an overlay using my tools Jun 24 01:57:58 note that my overlay-utils for historical reasons also uses different headers, but of course the script could just as well be used with mainline header files) Jun 24 02:00:43 you guys are all aht GSoC Jun 24 02:00:46 ? Jun 24 02:00:58 I have absolutely nothing to do with GSoC Jun 24 02:01:35 Not me. I think someone is dealing w/ GSOC if they would speak up. Heh? Anyway, it is a nice program. BBB.io peoples deal w/ it and teach too. Jun 24 02:01:57 Mentorship is a big deal. Jun 24 02:02:20 all I know about GSoC is that it results in (usually clueless) people showing up here saying they want to "contribute" without having any idea to what Jun 24 02:02:36 which is the cue to redirect them to #beagle-gsoc Jun 24 02:02:49 That was my first line w/out that program. Jun 24 02:02:52 Ha. Jun 24 02:03:14 I have yet to make something handy like lorforlinux just made. Jun 24 02:03:25 I am such a slow learner. Do not quit me, Larry. Jun 24 02:03:59 zmatt you are saying initial 2 line /dts-v1/; and /plugin/; of my overlay are invalid? Jun 24 02:04:23 MattB0ne: Type unset PS1 but do not get mad at me. Blame the river bend. Jun 24 02:04:33 Just kidding. Do not do it. Jun 24 02:04:41 lorforlinux: look at the pastebin I just gave Jun 24 02:04:59 lorforlinux: I'm saying your file is a syntactic mish-mash of two incompatible ways of writing overlays Jun 24 02:06:01 unless my perl script is being used for preprocessing Jun 24 02:06:08 is this an experimental version of bb.org-overlays which does that? Jun 24 02:07:11 huh how does this even compile Jun 24 02:08:01 I saw your pastebin and I am unable to find what's wrong with the overlay I wrote. Jun 24 02:08:05 wait what Jun 24 02:08:37 how _does_ this compile Jun 24 02:08:54 Which overlay are you seeing right now? please share the link :') Jun 24 02:09:28 Trippin' homie? Jun 24 02:09:55 SOrry. Jun 24 02:10:14 huh, is dtc able to automatically generate overlay fragments nowadays, and if so when the hell did that happen Jun 24 02:10:22 Ut oh. Jun 24 02:10:32 I suppose you are not talking about this one -> https://raw.githubusercontent.com/lorforlinux/bb.org-overlays/servo/src/arm/BBORG_SERVO-00A2.dts Jun 24 02:10:38 I am Jun 24 02:11:03 I'm deeply surprised by the fact that dtc accepts this as input, and I'm wondering since when Jun 24 02:11:54 As soon as I open LPIC-1, they have already come out w/ an updated version. Jun 24 02:11:56 Blah! Jun 24 02:11:57 I mean, hurray that it does, it is what it should have done right from the start, but it definitely didn't Jun 24 02:12:56 can you point me to the part which seems problematic to you? Jun 24 02:13:28 lorforlinux: lines 19-181 Jun 24 02:13:57 101 Jun 24 02:15:22 nice Jun 24 02:16:26 yeah dtc is able able to perform the necessary transformation (for which overlay-utils uses a perl script) by itself these days Jun 24 02:16:38 it definitely did not do that when overlays were new Jun 24 02:17:25 I think I angered MattB0ne. I am going to apologize when he/she comes back. Jun 24 02:17:47 lorforlinux: I'm puzzled how you don't notice the difference between the two syntaxes even when I show them side by side Jun 24 02:20:56 I see the difference and I have used both of them, what I am unable to see here is what is wrong with the overlay i wrote. Jun 24 02:22:13 can anyone point me to reading/source for how the bbb enumerated as a mass storage device? Jun 24 02:22:26 don't even know if you can still do that Jun 24 02:23:18 lorforlinux: well, now that I know dtc has been fixed to support sane syntax, nothing Jun 24 02:24:05 ayjay_t: there's a script that configures the usb gadget as a composite device, one of which is a mass storage gadget for a small FAT-formatted disk image Jun 24 02:24:30 set_ the servo cape test script has been updated and it will not give you any error now :) Jun 24 02:24:31 oh wait, yeah usb gadget, i've seen that as a systemd process, which seems to fail quite frequently actually Jun 24 02:24:44 zmatt that's probably in /opt/ right? Jun 24 02:24:49 zmatt okay thanks Jun 24 02:24:50 ayjay_t: the relevant service is generic-board-startup.service Jun 24 02:25:26 lorforlinux: this is what dtc is implicitly rewriting it as: https://pastebin.com/raw/SauAtQ7Y Jun 24 02:25:37 and it used to be that that was how you were _required_ to write the overlay Jun 24 02:25:53 which is why I made a perl script that performs this syntax transformation Jun 24 02:26:03 which is what overlay-utils is all about Jun 24 02:26:40 if dtc supported the sane syntax right from the start, the overlays in bb.org-overlays wouldn't look so hideous, and my overlay-utils would never have existed :) Jun 24 02:26:50 yes that's the old way. They updated the syntax now Jun 24 02:27:09 where is it located? Jun 24 02:27:13 Where is the info? Jun 24 02:27:39 thanks for that zmatt Jun 24 02:27:53 I totally agree, overlays are way better with new syntax Jun 24 02:28:05 lorforlinux: ah, there's still one difference: my perl script supports metadata (given as properties at the top-level, outside all fragments) while dtc doesn't Jun 24 02:28:38 not a huge deal since u-boot overlays ignores the metadata anyway Jun 24 02:29:12 set_ just remove the old script and redo the `Testing servo control` part of my blog. Jun 24 02:29:14 (but the old cape-manager required the metadata) Jun 24 02:29:38 Okay. Jun 24 02:29:40 Okay! Jun 24 02:29:57 You made a new bunch of source or something? Jun 24 02:30:11 zmatt I want to enable cape-manager on BBAI do you have anything to share on this? Jun 24 02:30:30 lorforlinux: cape-manager has been deprecated and unused for many years Jun 24 02:30:43 never worked well even on the bbb, prone to kernel panics Jun 24 02:30:58 never accepted by mainline, scheduled for removal Jun 24 02:31:03 bzzt, bzzt! Jun 24 02:31:37 what??? how do we handle the automatic loading of DT cape overlay on BBB then? Jun 24 02:31:44 u-boot handles that Jun 24 02:31:50 not the kernel Jun 24 02:32:13 that was a lorforlinux panic. Ha. Jun 24 02:33:10 How to enable the process on BBAI can you provide some pointers? Jun 24 02:33:30 u-boot overlays and the old bone-cape-manager are mutually exclusive: when u-boot overlays is enabled, it passes a parameter to the kernel that disables cape-manager entirely Jun 24 02:34:12 I don't know much about how u-boot overlays works, sorry... it's a combination for some code in the board initialization file with some scripts in its default environment Jun 24 02:35:07 uboot is not easy stuff. I tried to learn awhile back. Jun 24 02:35:33 Too many processes and orders. Jun 24 02:36:24 zmatt no problem, you cleared some things for good here. I knew that Cape-manager was gone for some time and then it came back 4.something kernel, I thought we are still using that to load the DT overlays for capes. Jun 24 02:36:45 nope, it's all u-boot now Jun 24 02:37:00 cape-manager is dead and buried Jun 24 02:38:13 set_ I removed the disable function call before setting the initial period and duty_cycle assignment. You must reboot your board after updating the script to make sure it's not giving any error now. Jun 24 02:38:31 zmatt okay :b Jun 24 02:38:35 Okay. Please hold. I will do as I am told. Jun 24 02:38:56 I am erasing things and restarting the board first. Then, I will add the new script. Jun 24 02:39:11 you can do that too Jun 24 02:39:17 Right-O! Jun 24 02:39:54 brb Jun 24 02:44:47 Okay. Let me get this correct here. Erase, wget, place, shutdown, and boot! Right? Jun 24 02:45:04 place means put the file where it belongs. Jun 24 02:45:06 SOrry. Jun 24 02:47:22 No! Jun 24 02:47:41 It is perfect and w/ an extra oomph! Jun 24 02:48:26 I should have started this book years ago. It is a plethora of info. and in an easy-to-read format. Yea boy! Jun 24 02:51:47 Nice Jun 24 02:55:15 There, back, and to there! **** ENDING LOGGING AT Wed Jun 24 02:59:57 2020