**** BEGIN LOGGING AT Mon Apr 25 02:59:56 2022 Apr 25 03:00:37 I know it is late but! Where are you guys? Where are you guys in building on 5.17.x and .dts education? Apr 25 03:00:59 I know you guys/gals are helping as mentors this year w/ GSoC, i.e. so I am in no rush. Apr 25 03:01:04 I was just wondering. Apr 25 03:41:08 mattb0ne: what does your python-side code looks like? Apr 25 03:41:57 because my guess would be the issue is there, not on the pru side Apr 25 04:17:06 i can paste bin Apr 25 04:20:56 https://pastebin.com/C8BYC1m4 Apr 25 04:22:37 C code https://pastebin.com/jGBJZGmU Apr 25 05:43:28 based on what are you saying the message numbers "jump" ? baesd on the log lines you're pending? but you're only printing one log message per batch of messages processed in python Apr 25 05:44:09 (to minimize the amount of work done per message, since otherwise python can't keep up) Apr 25 07:05:18 mattb0ne, if you read irclog later: see if you can toggle gpio0.31 from pru using these lines: https://pastebin.com/s2Y9vgqQ Apr 25 08:04:52 Python is s l o w. Apr 25 11:06:47 back for another day of troubleshooting Apr 25 11:29:16 seems like the transfer limit on passing messages to the python is 10-12 msec Apr 25 11:29:28 i so the load cell is not limiting i think Apr 25 11:30:45 the loadcell can out put 600 times a second Apr 25 11:30:56 but I can only send at ~100 times a second Apr 25 11:31:23 if the thing is truly moving at 5ns an instruction I would think I would get better performance Apr 25 11:31:46 All I have my code doing is reading a value from shared memory and collecting the time stamp Apr 25 11:32:31 reading the load cell does not change the performance so the bottleneck is elsewere. I am pretty sure it is the pru because the time stamp is set on the PRU side Apr 25 11:33:00 is there a way to check where the PRU code is slow easily Apr 25 11:42:50 mattb0ne: maybe make a habit of checking https://libera.irclog.whitequark.org/beagle/ to see what replies you missed Apr 25 11:44:22 mattb0ne: you're printing a log line per _batch_ of messages processed in python Apr 25 11:44:51 and also, you have a 10ms sleep between processing batches of messages, which means you're going to see at most 100 log lines per second Apr 25 11:46:15 you're likewise only writing one line to csv per batch of messages, instead of one line per message Apr 25 11:46:42 oh ok Apr 25 11:46:56 it probably should have been a good hint that the section of code labeled "update user interface" is not the right place to write data to file Apr 25 11:47:16 lol Apr 25 11:47:23 a file is not UI Apr 25 11:47:25 kidding Apr 25 11:47:39 do you think a file write is faster than output to the screen Apr 25 11:47:45 i am wondering if I would have the same problem Apr 25 11:48:43 in anyevent until I can change the motor direction on the PRU side the speed is sort of lost Apr 25 11:49:15 doing any part of the real-time processing in python would make using PRU entirely pointless Apr 25 11:49:42 PRU can control GPIO just fine, if it's not working then it simply needs to be debugged Apr 25 11:49:56 like I said earlier, see if you can toggle gpio0.31 from pru using these lines: https://pastebin.com/s2Y9vgqQ Apr 25 11:54:15 ok Apr 25 11:54:20 did you take a peak at my overlay Apr 25 11:54:22 was that ok Apr 25 11:54:49 don't remember, just use show-pins to confirm the pin is muxed as gpio and configured as output Apr 25 11:56:34 hm, I just checked the compiler output for gpio_set_one_low( &GPIO0, 31 ); and gpio_set_one_high( &GPIO0, 31 ); and it seems to produce the correct output (equivalent to https://pastebin.com/s2Y9vgqQ ) so I really don't see any reason for it to not work Apr 25 11:57:03 ok I am going to make a simple program that sets a motor speed and runs those commands Apr 25 11:58:11 https://pastebin.com/tuEQ9keR my overlay Apr 25 12:02:37 gpio 0.31 is P9.13 ... I don't see any pinmux declared for it? Apr 25 12:02:43 never mind, I'm blind Apr 25 12:03:44 then I guess it looks fine... maybe rename gpio_pins (both occurrences) to motor_gpio_pins to match your node name Apr 25 12:04:42 using those lines worked Apr 25 12:04:44 and I'm presonally add a comment to each pin (lines 95-100) to mention which gpio (name and number) it is Apr 25 12:04:51 *personally Apr 25 12:05:16 but gpio_set_one_high( &GPIO0, 31 ); and gpio_set_one_low( &GPIO0, 31 ); doesn't? as far as I can tell they produce the same code output Apr 25 12:05:27 let me double check Apr 25 12:06:09 side note is there a way to have a problem gracefully exit after ctrl-c Apr 25 12:06:36 like a try catch wont fix a ctrl-c exit from python Apr 25 12:06:48 when I break the code the motor will keep spinning Apr 25 12:06:59 I want to put in a wind down Apr 25 12:07:01 or somethign Apr 25 12:07:30 then add code to your PRU program to gracefully turn off the motor when it hits an abort Apr 25 12:08:06 or add a try-catch in python that stops the PRU and then manually turns off the motor or whatever Apr 25 12:08:25 but I'd put more trust in PRU to do it Apr 25 12:08:52 ok Apr 25 12:08:57 (though if you're letting PRU do it you obviously shouldn't kill the PRU core on exiting) Apr 25 12:09:34 having said that, it looks like you're already doing some cleanup in python now Apr 25 12:09:41 so it would be easier to add your motor cleanup to that Apr 25 12:12:30 ok Apr 25 12:12:42 does ctrl-C go to the finally in a try catch Apr 25 12:12:46 yes Apr 25 12:23:20 ok the helper functions work Apr 25 12:23:56 the issue was with the decoder wrapping sometimes so rather than being at 0 it is at 2^32 or something slightly less Apr 25 12:24:16 that doesn't matter Apr 25 12:24:47 also should I be shifting my coefficents as well Apr 25 12:24:54 right now I only do the signal Apr 25 12:25:28 that's the whole reason for doing the shifting, to get a large range to work with for your coefficients Apr 25 12:25:46 oh right for some reason you're still doing some kind of weird test on the raw encoder position Apr 25 12:26:07 the purpose of which is a complete mystery to me Apr 25 12:26:17 working with the raw encoder Apr 25 12:26:27 https://pastebin.com/jGBJZGmU lin 230 Apr 25 12:27:22 like, surely that should at the very least be done on the position relative to reference_count ? unless I completely misunderstand the point of this code Apr 25 12:28:33 also, I just noticed you declared your counter as uint8_t yet you're trying to use it for range 0..999 ... newsflash, that range doesn't fit in an uint8_t :P Apr 25 12:29:44 you'll also want your coefficients to be int32_t rather than int16_t Apr 25 12:30:47 also, you need to take the absolute value of the control signal to set EPWM1A ... I had that in my original code fragment but you seemed to have removed that in editing it Apr 25 12:31:24 crap Apr 25 12:32:01 for some reason i had it in my mind that uint8 would do 32, something something Apr 25 12:33:07 the raw signal was to get around the fact that the PRU does not have float support Apr 25 12:33:14 now you said I can bit shift Apr 25 12:33:25 ??? Apr 25 12:33:39 the int thing is just my dumbness Apr 25 12:33:44 the raw counts comment Apr 25 12:33:57 like I cannot put 112.25 in the PRU Apr 25 12:34:02 I was talkihng about the weird "fault condition" check, which is using the "position", not relative to reference_count or anything Apr 25 12:34:34 well my signal was not goign to accumulate counts if working correctly Apr 25 12:34:51 so if it hit either number something went wrong Apr 25 12:35:19 right, it won't accumulate counts... but it starts at reference_count Apr 25 12:35:33 ahhhh Apr 25 12:35:34 yes Apr 25 12:37:04 also 42949000 seems like a weird arbitrary number Apr 25 12:38:18 like, it's missing two zeros if it's supposed to be close to 2**32 Apr 25 12:39:58 if you want to limit the growth on the error value (to catch when the algorithm is seriously failing to converge), just put a test on abs(error[0]) Apr 25 12:40:35 using an assert() for that may be justified Apr 25 12:54:05 yeah it was arbitrary Apr 25 12:59:23 nature calls afk Apr 25 21:17:46 zmatt: any reasoning on the bit shift by 16? I ask because I wind up needing to make my Kp and everything very large to have a signal large enough to be non zero when i shift back Apr 25 21:21:57 mattb0ne: it's just the most obvious shift value for the range needed here, convenient for the compiler, and 16 fractional bits is hopefully more than plenty for your coefficients Apr 25 21:22:45 so maybe something else is wrong Apr 25 21:22:47 and yes your coefficients would get larger by a factor of 65536, but why does that matter? Apr 25 21:23:00 i am just wondering why they are soo big Apr 25 21:23:19 like I am trying to get the motor to move and I at kp = 1000000 Apr 25 21:23:22 because they now have 16 fractional bits, even though you don't write them as fractional Apr 25 21:23:42 just seems odd but I also have no context for this stuff Apr 25 21:23:56 also, Kp doesn't allow for the control value to grow as needed to get a response Apr 25 21:23:58 Ki does Apr 25 21:24:08 iirc Apr 25 21:24:23 right but you suppose to start with kp and zero out everything else Apr 25 21:24:30 I am will eventually auto tune it Apr 25 21:24:38 in matlab but I need to get in the ball park Apr 25 21:24:54 I am wondering if I am doing something wrong Apr 25 21:25:24 well the problem is also that your motor probably won't move unless your output has a certain value... so yeah if you're using Kp only then it may need to be fairly substantial Apr 25 21:25:29 if I strip out the shifting I can get the motor to move but I lose tha resolution as you say Apr 25 21:25:44 I will keep messing with it Apr 25 21:25:46 1000000 is effectively 15.2587890625 if you take the shifting into account Apr 25 21:26:21 which blows my mind I am still wrestling with that but I just got to stew on it Apr 25 21:27:02 and jsut to be clear I am not shifting my coefficents so I have kp = 1000000 not kp = 1000000 <16 Apr 25 21:27:02 you scale down the final output value by 65536, therefore to get equivalent results you need coefficients scaled up by the same factor of 65536 Apr 25 21:27:14 yes correct Apr 25 21:27:48 putting a literal left-shift on your coefficients would make it impossible to use the extra precision you have and make the whole shifting pointless Apr 25 21:27:58 ok Apr 25 21:30:01 though I guess you could do something like (int)( 15.25 * 0x10000 ) Apr 25 21:30:56 the floating-point compputation would in that case be evaluated entirely at compile-time which is fine Apr 25 21:31:54 while allowing you to write coefficients of "normal" magnitude, with a fractional part if needed/desired Apr 25 21:34:34 obviously you're free to not use shifting at all, but that would severely limit the precision available for tuning Apr 25 21:40:26 yeah I need the precision Apr 25 21:43:48 mattb0ne: all the shifting is doing is multiplying the coefficients by some constant scale-factor and then dividing the final result by that same scale factor... that scale factor being a power of two, specifically 0x10000, because dividing by this (using a right-shift) is extremely cheap, while division in general is not Apr 25 21:44:33 and this gives you the extra precision, since now your coefficients don't need to be integer, they only need to be integer after scaling Apr 25 22:43:44 so I could do 1.5 << 16; Apr 25 22:43:54 for a coefficent Apr 25 22:44:21 yes no sorta, you have to write it (int)( 1.5 * 0x10000 ) Apr 25 22:44:51 multiplying by 0x10000 is the same thing as left-shifting by 16, except multiplication also works for floats while left-shifting does not Apr 25 22:45:05 ok I think I am going to do that Apr 25 22:45:21 and of course the final cast to (int) to ensure we don't actually get floating-point arithmetic at runtime Apr 25 22:45:33 would I need to change anything else down stream if that is how I define the coefficents? Apr 25 22:46:04 this is assuming your have a final right-shift by 16, which you already have Apr 25 22:46:11 on the control value Apr 25 22:48:28 right Apr 25 22:57:36 so my control signal doesnt budget off zero Apr 25 22:57:45 do I shift the error or something Apr 25 22:58:04 something is up I have increased kP to the point that I get a truncation warning on a unint32 Apr 25 22:58:10 i can paste my code Apr 25 22:58:12 one second Apr 25 22:58:23 that would require an _enormous_ value of Kp Apr 25 22:58:36 one that would cause the PID calculation to spit out complete garbage Apr 25 22:59:07 I'm assuming you mean int32_t, not uint32_t Apr 25 23:00:23 sorry signed int Apr 25 23:00:35 yeah, int Apr 25 23:03:01 I got to be making a bone head move somewhere if I strip out the shifting i get hte motor to move it is just I cannot adjust anything really because I have no precision Apr 25 23:03:02 https://pastebin.com/aJpcz6QD Apr 25 23:03:40 the problem is you're declaring your A[] array as int16_t Apr 25 23:05:21 got it Apr 25 23:13:23 must be wrapping or something if I lower the shifting to 4 and my scale factor to 0x00100 i get movement Apr 25 23:13:40 but I would only get 0.25 resolution Apr 25 23:14:28 no, 1/16 .... but there shouldn't be any wrapping going on here unless your coefficients are wildly too large Apr 25 23:15:25 uhh, also, scale factor 0x100 corresponds to a shift of 8 Apr 25 23:15:30 not 4 Apr 25 23:16:50 i.e. you set a much larger value (16 times as large as previously) Apr 25 23:16:57 and that's why you're getting a response Apr 25 23:20:38 also, why are you resetting your reference_count again? Apr 25 23:20:46 that will break your PID loop Apr 25 23:20:59 by causing drift Apr 25 23:22:47 Which side does GND go to on the BBB for the serial debug cable? Near the USB Port or the Ethernet Port? Apr 25 23:23:10 near the ethernet port, the side marked with a white dot on the pcb Apr 25 23:23:19 Thank you sir. Apr 25 23:23:26 what did you do to your bbb to need a serial debug cable? Apr 25 23:26:06 Built an image. Apr 25 23:26:11 I am booting into it. Apr 25 23:26:30 But for now, until I add the required dep, I am stuck w/ the UART0. Apr 25 23:26:41 you know what, forget I asked Apr 25 23:27:01 Otay! You have are having a nice day. I can tell. Apr 25 23:27:19 Full of candy and licorice? Apr 25 23:28:13 well my error is based on postion count vs my input signal which repeats Apr 25 23:28:53 mattb0ne: error is the difference between desired position (input signal) and actual position Apr 25 23:29:15 so I have a reference Apr 25 23:29:16 in this case, actual position is being measured relative to reference_count Apr 25 23:29:23 and I add my input signal to it Apr 25 23:29:28 and that is my target Apr 25 23:29:31 if you keep changing the reference, your position can drift unbounded Apr 25 23:30:20 yeah your right I guess what I am finding is the motor keeps spining so my error just takes off Apr 25 23:30:28 but resetting is not doing anything to fix the issue Apr 25 23:30:38 no, it will make it worse Apr 25 23:30:56 if the motor is running away then there's a problem with the control loop or coefficients Apr 25 23:30:59 or motor direction Apr 25 23:31:03 right Apr 25 23:32:01 like I said previously, I'd suggest giving your signal a length of 1 for now.... i.e. have the algorithm try to keep a fixed position Apr 25 23:32:18 and if it can do that successfully, try slowly changing that value from python Apr 25 23:32:35 ok I will try that Apr 25 23:33:24 and probably put an assert or something on abs(error[0]) ..., if it gets too big your control algorithm has failed Apr 25 23:34:40 now i took some abs function from the internet Apr 25 23:34:54 but shouldnt there be a abs function in the std header Apr 25 23:35:18 make sure the motor direction is such that if control_signal is positive, your motor spins in the direction that increases position Apr 25 23:35:25 yes, Apr 25 23:35:48 also that abs function looks like garbage Apr 25 23:35:56 not in the least because its argument is declared as int16_t Apr 25 23:36:11 so you're turning your control value into garbage Apr 25 23:36:44 also, it looks hideously expensive compared to the much simpler and faster return value < 0 ? -value : value; Apr 25 23:37:22 but also, you don't need to define it yourself anyway, it's in #include Apr 25 23:43:09 also, you're subtracting your reference_count twice now Apr 25 23:53:57 ok Apr 25 23:54:09 let me fix that Apr 25 23:54:25 I think my first attemp at using the abs it said it was undefined Apr 25 23:54:42 because your file doesn't #include Apr 25 23:56:13 how am i subtracting reference_count twice Apr 25 23:56:56 you've defined uint32_t current_position = *position_var - reference_count; Apr 25 23:57:11 (a better name for that variable would be relative_position, also it should be signed rather than unsigned) Apr 25 23:57:58 and then your error[0] definition is input_signal + reference_count - current_position Apr 25 23:58:12 which is equivalent to input_signal - (current_position - reference_count) Apr 25 23:59:05 which is input_signal - (position * 2 * reference_count) if position is the raw sampled position value (i.e. *position_var) Apr 26 00:02:05 whats a cleaner way to label this I felt adding reference count to the input signal makes sense Apr 26 00:02:30 i guess I would get rid of the reference adjustment on the position variable Apr 26 00:05:07 https://pastebin.com/rRvN6GCB Apr 26 00:06:34 mhh, I just realized a problem with the way this PID is expressed Apr 26 00:07:29 ok yeah, and it's a big problem Apr 26 00:07:59 I think Apr 26 00:08:03 let me think for a bit Apr 26 00:08:53 they're handling the P and D terms by differentiating and then integrating again... but I think that will interact poorly with the range-limiting Apr 26 00:09:17 or it might anyway Apr 26 00:09:38 I guess if you have a non-zero I term that should at least rectify the situation Apr 26 00:10:36 what range are you expecting on the input signal? Apr 26 00:10:52 (out of curiosity) Apr 26 00:16:23 this alternative may be better behaved: https://pastebin.com/K65wBKPE Apr 26 00:17:40 in that case you may want to monitor error_accum to ensure it doesn't grow excessively large.... though it will only do that if your PID loop is broken (e.g. due to wrong motor direction or very poorly chosen coefficients) Apr 26 00:19:30 zmatt: have you done a uio instance on TDA4VM? Apr 26 00:19:33 for PRUs. Apr 26 00:20:17 input will always will be less than 1440 Apr 26 00:20:19 jkridner: given that I don't have a TDA4VM, ehh no? though I'm pretty sure it should Just Work Apr 26 00:20:21 it seems to be working now Apr 26 00:20:31 k. Apr 26 00:20:45 I just need to track down the device-tree bindings. Apr 26 00:20:47 thouhg I will try that other formulation in the paste bin Apr 26 00:21:01 i think I have showcased my ineptitude enough today Apr 26 00:21:08 lol Apr 26 00:21:09 got a good link for them on am5729? I don't think it ever made it to our standard dt, but I'll look. Apr 26 00:21:12 thanks zmatt Apr 26 00:21:39 jkridner: https://github.com/mvduin/overlay-utils/tree/master/am57xx Apr 26 00:22:16 what are all those interrupts? Apr 26 00:22:17 overlays for both pruss instances, for kernels 4.14/4.19 and 5.4/5.10 Apr 26 00:23:03 jkridner: those are the interrupts from pruss to arm... on kernel 5.x I need to redeclare those since they moved the original declaration to a child node Apr 26 00:24:30 jkridner: they're literaly just copy-pasted from https://github.com/beagleboard/BeagleBoard-DeviceTrees/blob/v5.10.x-ti/src/arm/am57-pruss.dtsi#L85-L92 Apr 26 00:24:48 k. Apr 26 00:25:43 they're not in the 4.x version of the overlay because it had them declared on the &pruss1/&pruss2 node itself in the base dts: https://github.com/beagleboard/BeagleBoard-DeviceTrees/blob/v4.19.x-ti-overlays/src/arm/dra7.dtsi#L1266-L1273 Apr 26 00:27:31 a proper from-scratch declaration of the node (without reusing/patching the node declared for remoteproc) would have those interrupts, the reg-property, and the properties I declare in the overlay Apr 26 00:28:22 i.e. the required properties are: reg compatible ti,pintc-offset interrupts Apr 26 00:28:25 pretty simple Apr 26 00:28:29 looks like they were broken down into ti,icssg-intc Apr 26 00:28:47 yeah, which makes sense, but not in combination with uio-pruss Apr 26 00:29:32 ah. Apr 26 00:29:50 (the pruss-instance property I add on am57xx is just to identify the different pruss instances to userspace, for use by udev rules) Apr 26 00:29:51 I'm trying to use remoteproc, but enable mmap of the shared memory. Apr 26 00:29:58 so, not full-on uio. Apr 26 00:30:27 ah that's a different story Apr 26 00:30:33 this is full-on uio Apr 26 00:31:14 yeah, I don't want the whole thing mapped with uio, just the shared memories. Apr 26 00:31:19 for shared memory regions, add child devices to the pruss (on 5.x) or pruss_soc_bus (on 4.x) node Apr 26 00:32:36 using compatible = "uio"; and a reg property covering the range you want to be mappable Apr 26 00:33:35 there is an iccsgX_mem entry as a subentry to ti,j721e-icssg without its own compatible line. Apr 26 00:33:39 and a symlink property to have udev create a nice symlink, e.g. symlink = "uio/pruss1-shmem"; to create /dev/uio/pruss1-shmem Apr 26 00:33:52 yeah, that's used by remoteproc no doubt Apr 26 00:34:27 for loading? Apr 26 00:34:34 can I have both? Apr 26 00:34:41 or will it go boom? Apr 26 00:34:59 you can have both, the extra uio device won't care about remoteproc or vice versa Apr 26 00:35:44 you can in principle also have multiple named reg-ranges per uio device, though that's a bit annoying for userspace so I'd suggest to instead create multiple devices in that case Apr 26 00:37:04 child off of icssg (ti,j721e-icssg)? Apr 26 00:37:21 multiple devices? Apr 26 00:37:52 it looks like it's a bus so that *should* be fine Apr 26 00:38:42 if it's actually fussy about sub-devices that it may be necessary to interject a parent bus around the pruss device (i.e. resurrect the pruss_soc_bus present in 4.x) Apr 26 00:39:05 &icssg0 { compatible = "uio"; symlink = "uio/icssg0-shmem"; }; ? Apr 26 00:39:15 oh, plus the reg entries. Apr 26 00:40:02 oh... I need to actually make the device! Apr 26 00:40:07 not change the one that is there! Apr 26 00:40:10 yeah Apr 26 00:42:04 e.g. &icssg0 { uio@10000 { reg = <0x10000, 0x10000>; compatible = "uio"; symlink = "uio/icssg0/dram2"; }; }; Apr 26 00:42:07 or something Apr 26 00:43:29 actually I'd lean towards calling it uio/pruss0/dram2 since "ICSSG" is really just a fancy version number for pruss :P Apr 26 00:46:50 dram is always so confusing for me.... I have a hard time absorbing "data" vs. "dynamic". Apr 26 00:47:05 hehe, yeah Apr 26 00:47:14 in this case it's dram vs iram Apr 26 00:47:27 yeah Apr 26 00:49:12 jkridner: also, to do this on tda4vm you'll want to ask rcn-ee to apply https://github.com/RobertCNelson/linux-stable-rcn-ee/commit/16cad6a224f9d6906397f073b493c545075448cf to the ti-arm64 kernel, otherwise compatible="uio" will require a modprobe config file ( https://github.com/mvduin/py-uio/blob/master/etc/modprobe.d/uio.conf ) to work Apr 26 00:49:50 k Apr 26 00:50:17 (that patch is already in other kernels) Apr 26 00:51:56 wow, crazy https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/uio/uio_pdrv_genirq.c#n279 has no entries at all. Apr 26 00:52:35 yes, by default it _requires_ using its module param to fill in the first (and only) match Apr 26 00:52:49 which is... very convenient *cough* Apr 26 00:59:38 hmmmm..... not sure where I've got a syntax error in my DT. Apr 26 00:59:58 ah, missing semi Apr 26 01:00:08 the usual suspect Apr 26 01:00:32 fortunately dtc always provides helpful diagnostics, like TOKEN ERROR or something ;D Apr 26 01:00:36 rebooting Apr 26 01:01:53 gack. I must be missing the right symlink udev rule---or the driver didn't load. Apr 26 01:02:07 hmmm... nothing 'uio' in dmesg Apr 26 01:02:41 has the driver even been built? CONFIG_UIO_PDRV_GENIRQ Apr 26 01:03:46 CONFIG_UIO=m CONFIG_UIO_PDRV_GENIRQ is not set Apr 26 01:04:17 well there ya go **** ENDING LOGGING AT Tue Apr 26 02:59:56 2022