buzzmarshall has quit [Quit: Konversation terminated!]
GenTooMan has quit [Quit: Leaving]
akaWolf has quit [Ping timeout: 246 seconds]
akaWolf has joined #beagle
mattb0ne has quit [Ping timeout: 240 seconds]
mattb0ne has joined #beagle
mattb0ne has quit [Ping timeout: 240 seconds]
vagrantc has quit [Quit: leaving]
wonko-the-sane has quit [Quit: leaving]
<zmatt>
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
<zmatt>
(to minimize the amount of work done per message, since otherwise python can't keep up)
GenTooMan has joined #beagle
ikarso has joined #beagle
<zmatt>
mattb0ne, if you read irclog later: see if you can toggle gpio0.31 from pru using these lines: https://pastebin.com/s2Y9vgqQ
rob_w has joined #beagle
<set_>
Python is s l o w.
foxhole has quit [Ping timeout: 250 seconds]
javaJake_ has joined #beagle
javaJake has quit [Ping timeout: 250 seconds]
javaJake_ is now known as javaJake
florian has joined #beagle
wonko-the-sane has joined #beagle
michaelo has joined #beagle
mattb0ne has joined #beagle
mattb0ne has quit [Ping timeout: 256 seconds]
starblue has quit [Ping timeout: 256 seconds]
starblue has joined #beagle
mattb0ne has joined #beagle
<mattb0ne>
back for another day of troubleshooting
<mattb0ne>
seems like the transfer limit on passing messages to the python is 10-12 msec
<mattb0ne>
i so the load cell is not limiting i think
<mattb0ne>
the loadcell can out put 600 times a second
<mattb0ne>
but I can only send at ~100 times a second
<mattb0ne>
if the thing is truly moving at 5ns an instruction I would think I would get better performance
<mattb0ne>
All I have my code doing is reading a value from shared memory and collecting the time stamp
<mattb0ne>
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
<mattb0ne>
is there a way to check where the PRU code is slow easily
Shadyman has quit [Remote host closed the connection]
<zmatt>
mattb0ne: you're printing a log line per _batch_ of messages processed in python
<zmatt>
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
<zmatt>
you're likewise only writing one line to csv per batch of messages, instead of one line per message
<mattb0ne>
oh ok
<zmatt>
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
<mattb0ne>
lol
<mattb0ne>
a file is not UI
<mattb0ne>
kidding
<mattb0ne>
do you think a file write is faster than output to the screen
<mattb0ne>
i am wondering if I would have the same problem
<mattb0ne>
in anyevent until I can change the motor direction on the PRU side the speed is sort of lost
<zmatt>
doing any part of the real-time processing in python would make using PRU entirely pointless
<zmatt>
PRU can control GPIO just fine, if it's not working then it simply needs to be debugged
<zmatt>
like I said earlier, see if you can toggle gpio0.31 from pru using these lines: https://pastebin.com/s2Y9vgqQ
<mattb0ne>
ok
<mattb0ne>
did you take a peak at my overlay
<mattb0ne>
was that ok
<zmatt>
don't remember, just use show-pins to confirm the pin is muxed as gpio and configured as output
<zmatt>
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
<mattb0ne>
ok I am going to make a simple program that sets a motor speed and runs those commands
<zmatt>
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
<zmatt>
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
<zmatt>
you'll also want your coefficients to be int32_t rather than int16_t
<zmatt>
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
<mattb0ne>
crap
<mattb0ne>
for some reason i had it in my mind that uint8 would do 32, something something
<mattb0ne>
the raw signal was to get around the fact that the PRU does not have float support
<mattb0ne>
now you said I can bit shift
<zmatt>
???
<mattb0ne>
the int thing is just my dumbness
<mattb0ne>
the raw counts comment
<mattb0ne>
like I cannot put 112.25 in the PRU
<zmatt>
I was talkihng about the weird "fault condition" check, which is using the "position", not relative to reference_count or anything
<mattb0ne>
well my signal was not goign to accumulate counts if working correctly
<mattb0ne>
so if it hit either number something went wrong
<zmatt>
right, it won't accumulate counts... but it starts at reference_count
<mattb0ne>
ahhhh
<mattb0ne>
yes
<zmatt>
also 42949000 seems like a weird arbitrary number
<zmatt>
like, it's missing two zeros if it's supposed to be close to 2**32
<zmatt>
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])
<zmatt>
using an assert() for that may be justified
<mattb0ne>
yeah it was arbitrary
<mattb0ne>
nature calls afk
mattb0ne has quit [Ping timeout: 240 seconds]
mattb0ne has joined #beagle
argonautx has joined #beagle
SJFriedl has joined #beagle
Guest34 has joined #beagle
Guest34 has quit [Client Quit]
Guest67 has joined #beagle
Guest67 has quit [Client Quit]
mattb0ne has quit [Ping timeout: 240 seconds]
wonko-the-sane has quit [Remote host closed the connection]
wonko-the-sane has joined #beagle
mattb0ne has joined #beagle
rob_w has quit [Remote host closed the connection]
mattb0ne has quit [Ping timeout: 276 seconds]
argonautx has quit [Quit: Leaving]
lucascastro has quit [Ping timeout: 272 seconds]
mattb0ne has joined #beagle
lucascastro has joined #beagle
lucascastro has quit [Ping timeout: 248 seconds]
florian has quit [Quit: Ex-Chat]
mattb0ne has quit [Ping timeout: 276 seconds]
ikarso has quit [Quit: Connection closed for inactivity]
lucascastro has joined #beagle
xet7 has quit [Remote host closed the connection]
zjason has quit [Read error: Connection reset by peer]
zjason has joined #beagle
mattb0ne has joined #beagle
lucascastro has quit [Ping timeout: 240 seconds]
<mattb0ne>
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
lucascastro has joined #beagle
<zmatt>
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
<mattb0ne>
so maybe something else is wrong
<zmatt>
and yes your coefficients would get larger by a factor of 65536, but why does that matter?
<mattb0ne>
i am just wondering why they are soo big
<mattb0ne>
like I am trying to get the motor to move and I at kp = 1000000
<zmatt>
because they now have 16 fractional bits, even though you don't write them as fractional
<mattb0ne>
just seems odd but I also have no context for this stuff
<zmatt>
also, Kp doesn't allow for the control value to grow as needed to get a response
<zmatt>
Ki does
<zmatt>
iirc
<mattb0ne>
right but you suppose to start with kp and zero out everything else
<mattb0ne>
I am will eventually auto tune it
<mattb0ne>
in matlab but I need to get in the ball park
<mattb0ne>
I am wondering if I am doing something wrong
<zmatt>
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
<mattb0ne>
if I strip out the shifting I can get the motor to move but I lose tha resolution as you say
<mattb0ne>
I will keep messing with it
<zmatt>
1000000 is effectively 15.2587890625 if you take the shifting into account
<mattb0ne>
which blows my mind I am still wrestling with that but I just got to stew on it
<mattb0ne>
and jsut to be clear I am not shifting my coefficents so I have kp = 1000000 not kp = 1000000 <16
<zmatt>
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
<zmatt>
yes correct
<zmatt>
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
<mattb0ne>
ok
<zmatt>
though I guess you could do something like (int)( 15.25 * 0x10000 )
<zmatt>
the floating-point compputation would in that case be evaluated entirely at compile-time which is fine
<zmatt>
while allowing you to write coefficients of "normal" magnitude, with a fractional part if needed/desired
<zmatt>
obviously you're free to not use shifting at all, but that would severely limit the precision available for tuning
<mattb0ne>
yeah I need the precision
<zmatt>
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
<zmatt>
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
mattb0ne has quit [Ping timeout: 246 seconds]
mattb0ne has joined #beagle
<mattb0ne>
so I could do 1.5 << 16;
<mattb0ne>
for a coefficent
Shadyman has joined #beagle
<zmatt>
yes no sorta, you have to write it (int)( 1.5 * 0x10000 )
<zmatt>
multiplying by 0x10000 is the same thing as left-shifting by 16, except multiplication also works for floats while left-shifting does not
<mattb0ne>
ok I think I am going to do that
<zmatt>
and of course the final cast to (int) to ensure we don't actually get floating-point arithmetic at runtime
<mattb0ne>
would I need to change anything else down stream if that is how I define the coefficents?
<zmatt>
this is assuming your have a final right-shift by 16, which you already have
<zmatt>
on the control value
<mattb0ne>
right
vagrantc has joined #beagle
<mattb0ne>
so my control signal doesnt budget off zero
<mattb0ne>
do I shift the error or something
<mattb0ne>
something is up I have increased kP to the point that I get a truncation warning on a unint32
<mattb0ne>
i can paste my code
<mattb0ne>
one second
<zmatt>
that would require an _enormous_ value of Kp
<zmatt>
one that would cause the PID calculation to spit out complete garbage
<zmatt>
I'm assuming you mean int32_t, not uint32_t
<mattb0ne>
sorry signed int
<zmatt>
yeah, int
<mattb0ne>
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
<zmatt>
mhh, I just realized a problem with the way this PID is expressed
<zmatt>
ok yeah, and it's a big problem
<zmatt>
I think
<zmatt>
let me think for a bit
<zmatt>
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
<zmatt>
or it might anyway
<zmatt>
I guess if you have a non-zero I term that should at least rectify the situation
<zmatt>
what range are you expecting on the input signal?
<zmatt>
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)
<jkridner>
zmatt: have you done a uio instance on TDA4VM?
<jkridner>
for PRUs.
<mattb0ne>
input will always will be less than 1440
<zmatt>
jkridner: given that I don't have a TDA4VM, ehh no? though I'm pretty sure it should Just Work
<mattb0ne>
it seems to be working now
<jkridner>
k.
<jkridner>
I just need to track down the device-tree bindings.
<mattb0ne>
thouhg I will try that other formulation in the paste bin
<mattb0ne>
i think I have showcased my ineptitude enough today
<mattb0ne>
lol
<jkridner>
got a good link for them on am5729? I don't think it ever made it to our standard dt, but I'll look.
<zmatt>
overlays for both pruss instances, for kernels 4.14/4.19 and 5.4/5.10
<zmatt>
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
<zmatt>
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
<zmatt>
i.e. the required properties are: reg compatible ti,pintc-offset interrupts
<zmatt>
pretty simple
<jkridner>
looks like they were broken down into ti,icssg-intc
<zmatt>
yeah, which makes sense, but not in combination with uio-pruss
<jkridner>
ah.
<zmatt>
(the pruss-instance property I add on am57xx is just to identify the different pruss instances to userspace, for use by udev rules)
<jkridner>
I'm trying to use remoteproc, but enable mmap of the shared memory.
<jkridner>
so, not full-on uio.
<zmatt>
ah that's a different story
mattb0ne has quit [Ping timeout: 272 seconds]
<zmatt>
this is full-on uio
<jkridner>
yeah, I don't want the whole thing mapped with uio, just the shared memories.
<zmatt>
for shared memory regions, add child devices to the pruss (on 5.x) or pruss_soc_bus (on 4.x) node
<zmatt>
using compatible = "uio"; and a reg property covering the range you want to be mappable
<jkridner>
there is an iccsgX_mem entry as a subentry to ti,j721e-icssg without its own compatible line.
<zmatt>
and a symlink property to have udev create a nice symlink, e.g. symlink = "uio/pruss1-shmem"; to create /dev/uio/pruss1-shmem
<zmatt>
yeah, that's used by remoteproc no doubt
<jkridner>
for loading?
<jkridner>
can I have both?
<jkridner>
or will it go boom?
<zmatt>
you can have both, the extra uio device won't care about remoteproc or vice versa
<zmatt>
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
<jkridner>
child off of icssg (ti,j721e-icssg)?
<jkridner>
multiple devices?
<zmatt>
it looks like it's a bus so that *should* be fine
<zmatt>
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)