**** BEGIN LOGGING AT Wed Apr 20 02:59:56 2022 Apr 20 03:02:51 I found some new lib. from a Phd. fellow. Self-proclaimed or not, he has it down pat w/ the BBB for specific kernels and images. Apr 20 03:03:14 It was a relief to find other people are still willing to share around their builds, i.e. no matter how difficult things are for some people. Apr 20 03:09:14 whats the difference between dram and iram Apr 20 03:09:20 for the PRU Apr 20 03:30:35 mattb0ne: First one to find out, wins? Apr 20 03:31:18 It is not a game. I am being serious!! Apr 20 03:31:42 I will search while you search. The first one that finds the answer must post it. Apr 20 03:32:11 Are you game Apr 20 03:32:15 ? Apr 20 03:32:40 28 minutes and counting! Apr 20 03:36:25 i am game Apr 20 03:36:32 I need to find the logs to get old pastebins Apr 20 03:36:40 this was before the migration to libra chat Apr 20 03:37:06 No, in the big book! Apr 20 03:37:43 TRM. We can learn how exactly to chat about what the machine understands. Apr 20 03:38:19 the am335x understands a lot but our chat w/ one another is lacking in this dept. Apr 20 03:38:32 Are we discussing the am335x still and the PRUs onboard? Apr 20 03:41:19 5000 large on pages to review. It is almost mind numbing but it shall be fun, fun, fun! Apr 20 03:41:49 I am saying that b/c it is boring to review the TRM alone. Apr 20 03:42:13 W/out conversing about it, it just disolves itself into nothingness. Apr 20 03:43:35 I mean...the beagleboard.org people just put out fresh images. Why not? Apr 20 03:46:34 I am not saying you have to have my email address, home address, or to reciprocate in that manner. Chat and TRM about the am335x or am5729 is all. Period. Apr 20 03:52:05 Well, no issue. I will just keep reviewing it until my boards die or I slaughter them off by accident. Crude garbage is what I think you think I am typing, i.e. hence this last post about the TRM and my langauge skills. English and not Python3 or C/C++ is what I am discussing...oof. Apr 20 03:55:49 no issue! Apr 20 03:59:03 Well, there goes that...I never get it. Apr 20 03:59:23 Everyone always yells, "You got it!" Nope, I sure do not. Apr 20 03:59:41 10:00! Apr 20 09:37:34 HI! Sorry for leaving yesterday with spidev2.1 problem. I will try to investigate the problem and report on success. Apr 20 10:31:37 Good evening, I hope you can help. I've updated my Beaglebone blue with the lates debian 5.10.106-ti-r41, but it seems the devices are not properly configured. When I run a driver test with robotcontrol, I get: Apr 20 10:31:40 ~/librobotcontrol/examples/bin$ sudo ./rc_test_drivers Apr 20 10:31:41 Kernel: 5.10.106-ti-r41 Apr 20 10:31:41 BeagleBoard.org Debian Bullseye IoT Image 2022-04-01 Apr 20 10:31:42 Debian: 11.3 Apr 20 10:31:42 PASSED: gpio 0 Apr 20 10:31:43 PASSED: gpio 1 Apr 20 10:31:43 PASSED: gpio 2 Apr 20 10:31:44 PASSED: gpio 3 Apr 20 10:31:44 ERROR: ti-pwm driver not loaded for hrpwm0 Apr 20 10:31:45 ERROR: ti-pwm driver not loaded for hrpwm1 Apr 20 10:31:45 ERROR: ti-pwm driver not loaded for hrpwm2 Apr 20 10:31:46 ERROR: ti-eqep driver not loaded for eqep0 Apr 20 10:31:46 ERROR: ti-eqep driver not loaded for eqep1 Apr 20 10:31:47 ERROR: ti-eqep driver not loaded for eqep2 Apr 20 10:31:47 PASSED: pru-rproc Apr 20 10:31:48 ERROR: uart1 driver not loaded Apr 20 10:31:48 ERROR: uart2 driver not loaded Apr 20 10:31:49 ERROR: uart4 driver not loaded Apr 20 12:11:51 I'm guessing there are some overlays missing there .. at the very least for the serial ports Apr 20 12:17:16 zmatt: I am confused on how to access PRU1 private memmory on the github you have pruss.dram1 (offset 0x02000 in pruss, up to 8KB) but I have been using #define position_var ((uint32_t const volatile *)0x00002000) to reference PRU0 private memory Apr 20 12:19:07 if I want to plop a big array in private memeory for PRU I am tempted to put (offset 0x00000000) but that sounds like it would be PRU0 private area Apr 20 12:25:33 Yes, spidev1.1 works! on mini image as spidev2.1 on usual 4GBimg Apr 20 12:41:44 Awaken! Apr 20 12:41:54 It is not 10:00 yet! Apr 20 12:43:04 tenchiro: The PWM and UART needs a refinement on the newer kernels. I tried it too. Apr 20 12:43:30 I am surprised the PRU-RPROC driver is working now. That is good news! Apr 20 12:44:40 When compiling the source, probably b/c of changes in 8 to 10 gcc, there are errors that need tending. Apr 20 12:48:14 Thank you for the responses. I greatly appreciate it. Is this something I can correct or something I'd need to wait. Thank you. Apr 20 12:49:36 I say jump on in! Compiling the source is the first step to "doing it w/ class." Apr 20 12:50:14 Do you know C/C++ well? Apr 20 12:50:53 I think the source is written in C/C++. It will be helpful when trying to handle errors and debugging. Apr 20 13:23:46 C and C++ are not a problem. Though I'd be concerned my knowledge of the os architecture is not sufficient for building entirely from the ground up. My goal was to get the PX4 going. But I've got some cross dependency conflicts with my build environment, the cross compilers and the older os version on the beaglebone blue. All I really need is a Apr 20 13:23:47 version that supports one dot version of clib. 2.29 vs 2.28. 5.10 has 2.31 which is sufficient but for this device issue. Maybe I can go backwards one or two releases when the gclib is > 28 but the devices were still working? Apr 20 13:29:02 Oh no. Apr 20 13:29:36 I am not saying from start to finish but there are entries you can output to file for seeing what exactly happens in the build of librobotcontrol. Apr 20 13:29:56 That is one step towards something. Apr 20 13:52:16 tenchiro: try installing the latest 4.19-ti kernel, see if that resolves the problem Apr 20 13:53:07 tenchiro: also, ignore set_ Apr 20 13:53:19 :P Apr 20 13:55:07 tenchiro: I can't easily check right now if those drivers are for some reason not being enabled on the 5.x kernel or if it's just a compatibility-issue with librobotcontrol, but in either case downgrading the kernel to the one used in the stable images should probably fix it Apr 20 13:55:44 (my guess would be it's a compatibility issue) Apr 20 14:09:54 No, not me! Apr 20 14:10:09 * set_ attentionize me. Apr 20 14:11:08 Hey...are you guys going to be ready? Apr 20 14:11:34 you know...for GSoC trials and tribulations! Send all output to file! Apr 20 14:17:05 For instance: set_ is the Main Man, Number One of all > truth.txt Apr 20 14:17:16 Okay. Done. Apr 20 19:06:21 zmatt! Apr 20 19:06:49 did you see my question Apr 20 19:35:56 This took +10 seconds at boot after enabling r-o file system: Apr 20 19:36:11 rootfs: recovering journal Apr 20 19:36:26 rootfs: clean, 28634/889024 files, 345262/3779579 blocks Apr 20 19:37:43 Can I turn off recovering journal? or cleaning files? Apr 20 20:43:54 Hi. I am looking to write a variable which is a double to a file. Then I am looking to read this variable from the file upon next power cycle on. Any help would be appreciated. Apr 20 20:51:28 hmmm Apr 20 20:51:37 you could add something to run on boot Apr 20 20:51:52 not sure the exact steps but seems google solvable Apr 20 20:58:28 i would wait for the zmatt Apr 20 21:39:50 Siegurd: sure, if you do that then it'll instead do a full filesystem check and/or fail to boot due to filesystem corruption Apr 20 21:41:05 Siegurd: what do you mean by "after enabling r-o file system" ? Apr 20 21:42:02 if the filesystem is truly readonly then it has no reason to do a journal recovery (which only happens after power failure while the filesystem was mounted read-write" Apr 20 21:42:05 ) Apr 20 21:57:16 why oh why wont C let me declare an array Apr 20 22:00:27 does the PRU not support arrays Apr 20 22:38:39 most likely you're doing it wrong Apr 20 22:40:00 mattb0ne: also, on the PRU cores, 0x0000 - 0x1fff always refers to the core's own private ram and 0x2000-0x3fff to the other core's private ram Apr 20 22:40:56 so on core1, 0x2000 will be dram0 rather than dram1 Apr 20 22:55:00 arggg Apr 20 22:55:03 let me paste bin Apr 20 22:56:06 https://pastebin.com/esef8cKL Apr 20 22:56:21 I striped a lot out because I was getting so many errors Apr 20 22:56:44 for the life of me I am not sure why my Signal struct is throwing an error Apr 20 22:58:55 i tried a couple things no dice brb Apr 20 23:47:16 is this C or C++ ? because those initializers inside a struct are only permitted in C++ Apr 20 23:48:51 also, why did you copy-paste parts of my sys_gpio.h header into your source file? just leave the header be as it is and #include it Apr 20 23:51:04 also, you're not actually reading the position var inside your loop, just a logically cached copy of it Apr 20 23:51:48 and there's plenty more questionable here, but I'm not sure I have the energy to explain right now Apr 20 23:53:09 there's also a bunch of points I already made last time you seem to have ignored, e.g. you shouldn't use unsigned integers for the error, or A Apr 20 23:57:17 and you probably can't use the control_signal directly as PWM value without scaling (using a right-shift), since doing so would leave you with pretty much no resolution in your coefficients Apr 21 00:00:20 e.g. right-shifting it by 16 would give you 16 fractional bits for your coefficients Apr 21 00:02:51 lol Apr 21 00:02:58 well starting at the top Apr 21 00:03:16 this is C and I am just trying to create an array of ints for my input signal Apr 21 00:04:20 I had a lot incorporated but the thing threw out alot of errors so I was starting from working code since it was on a different computer I wasnt actively referencing it Apr 21 00:04:25 so I made a lot of mistakes again Apr 21 00:04:44 how do I make a struct with an array in it for the PRU Apr 21 00:04:51 that is my most pressing question Apr 21 00:05:32 how you put an array into a struct is not an architecture-dependent question, it's purely a C question Apr 21 00:05:55 and you got it almost right, the problem is the initializers you added Apr 21 00:06:08 like I said, you can't do that in C Apr 21 00:06:49 why are you putting this into a struct anyway? Apr 21 00:07:08 also, why are there two arrays? don't you just need a single array of data values? Apr 21 00:08:01 I am a bit worried about tracking with time so I was going to include that as well so I can check Apr 21 00:08:11 though I guess I would just need dt Apr 21 00:08:16 if you want to write it from python, just declare it as a global variable in pru shared memory, just like 'ddr' and 'shmem' Apr 21 00:08:21 uhh, what do you mean? Apr 21 00:08:31 just make each element one time-step Apr 21 00:08:37 obviously Apr 21 00:08:38 right Apr 21 00:08:50 long day Apr 21 00:09:09 so your saying just put it in memory from python and do not declare it in the C program? Apr 21 00:09:33 I just literally told you to declare it in the C program Apr 21 00:09:44 sorry long day missed that Apr 21 00:09:49 same as ddr (line 92) and shmem (line 93) Apr 21 00:09:57 or you could put it into the SharedVars struct Apr 21 00:10:10 now I do want to put it in PRU1 private memory Apr 21 00:10:12 but maybe declaring it separately is nicer Apr 21 00:10:16 why? Apr 21 00:10:59 I would advise against that, leave pru1 private memory for the compiler's own stuff Apr 21 00:11:07 ok Apr 21 00:11:39 is there a website that explains that right shifting stuff Apr 21 00:11:48 that sailed over way over my head Apr 21 00:12:08 dunno, any tutorial on programming that covers integer arithmetic? Apr 21 00:12:37 right shifting is basically just dividing by a power of two Apr 21 00:12:47 (and rounding down) Apr 21 00:13:05 likewise, left-shifting is multiplying by a power of two Apr 21 00:15:05 mattb0ne: https://pastebin.com/krKh9Tav Apr 21 00:18:12 by right-shifting at the very end, all your constants need to be multiplied by that same power of two, which means you now have the ability to specify them with some actual precision Apr 21 00:18:49 i get it Apr 21 00:18:52 you can't stick 0.25 into an integer, but you *can* stick 0.25*65536 into an integer Apr 21 00:19:02 right Apr 21 00:19:16 why is it better to use compile time constants Apr 21 00:19:22 efficiency Apr 21 00:19:32 although it might not matter too much I guess Apr 21 00:20:37 just avoid division, that gets emulated in software (pru has no native way to divide numbers) Apr 21 00:21:04 but you don't need division anyway, or dt for that matter: if you look closely, all it does it scale your Ki and Kd coefficients Apr 21 00:21:20 and you need to tune those anyway Apr 21 00:23:11 yeah if I am assuming dt will be constant i can get away with it Apr 21 00:23:21 i am just wondering how true that would be Apr 21 00:23:45 also, like I said, put a range limit on your control_signal ... i.e., set it to zero if it gets negative, and likewise clip it to a suitable maximum value (i.e. max_pwm_value << 16, if you're using control_signal >> 16 as pwm value) Apr 21 00:23:48 it would be easier if I could fit 1000 points in there Apr 21 00:24:15 right I am going to do that I just needed get something to compile before adding that Apr 21 00:24:52 if you use 16-bit integers for your data points, 1000 points is 2KB Apr 21 00:24:55 pru shared memory is 12 KB Apr 21 00:25:24 (on the am335x) Apr 21 00:25:50 and yes, dt should definitely be a constant Apr 21 00:26:03 there's no good reason for it not to be Apr 21 00:27:17 btw, you do realize __delay_cycles( 10000 ); Apr 21 00:27:34 is only 50 microseconds? Apr 21 00:28:54 yeah I haven't gotten there yet but that was on the list to fix Apr 21 00:29:15 as you can see I did not get very far with this Apr 21 00:29:34 also, don't put stuff like receive_measurement() in send_message() Apr 21 00:29:39 If I make my A_0 compile time constants would I also need the Kp and stuff to be that as well Apr 21 00:29:55 how should I do it Apr 21 00:31:27 I'd pass the relevant into to send_message() ... but receive_measurement is too important to bury inside send_message() since your whole loop is synchronized to that... which you seem to have forgotten yourself as well, considering you put a pointless __delay_cycles() in your loop Apr 21 00:32:06 likewise you should sample *position_var only once per loop, and you need it in multiple places Apr 21 00:32:37 didn't you eventually also need the measured force (i.e. the result of receive_measurement()) for something in your control algorithm? Apr 21 00:33:28 sort of abandoned for now. I change force vs time into position vs time thinking it would be easier to PID control Apr 21 00:33:40 i got a non-linearity due to the magnets Apr 21 00:37:26 regardless of how or what your control algorithm will look like, I'd suggest an outline like https://pastebin.com/FuJzCuX9 Apr 21 00:38:06 for debugging you may also want to include the output value of your control loop in the message sent to python Apr 21 00:45:15 if the output loops like a random number generator, you may need to tweak your coefficient s;-) Apr 21 00:45:22 *looks like Apr 21 00:51:14 cool Apr 21 00:51:19 I need you to look at this line Apr 21 00:51:27 getting unknown token error Apr 21 00:51:33 one second let me paste bin Apr 21 00:55:37 https://pastebin.com/v9QuFjqJ Apr 21 00:55:52 line 201 Apr 21 00:56:02 getting unrecognized token error Apr 21 00:56:07 not sure why Apr 21 00:58:42 fixed error being unint btw Apr 21 00:58:47 forgot to do that Apr 21 00:59:12 but I still not sure why the compiler hates a simple minus sign it seems Apr 21 01:00:43 if I comment out "- position" it compiles Apr 21 01:04:11 nevermind splitting into two lines worked but weird it cannot hande (a+b)-c in one line Apr 21 01:05:21 your macros are the problem Apr 21 01:06:44 probably Apr 21 01:07:13 I'm not sure actually, your macros are definitely *a* problem Apr 21 01:08:22 as written, it makes line 202 expand to: control_signal = control_signal + 1 + 1 + 1 * error[0] + -1 -2*1 * error[1] + 1 * error[2]; Apr 21 01:08:30 which I'm fairly confident is not what you wanted Apr 21 01:10:14 ah I see the problem with line 201... − is some unicode char, not an ascii - **** ENDING LOGGING AT Thu Apr 21 02:59:57 2022