06:04 <zmatt> dunno, first time I've heard about a discord

10:46 <zmatt> (or maybe it's not, but I already forgot again)

12:23 <mattb0ne> so zmatt back to my question. If I am usng two PRUs and I want one program to know about the mapping in the other PRU how would I map variables. Based on what you said about how things init I can only map the local PRU and shared memory...

12:23 <mattb0ne> Though I am confused, since wouldn't i have the same problem if I have two programs mapping to shared memory.

12:24 <mattb0ne> basically one program will always run and the other program will start and stop but want access to state of the other PRU

15:37 <zmatt> yes, previously that hasn't been a problem since the other core was running an assembly program that didn't touch any ram other than its local ram

15:39 <zmatt> not sure what your current intentions are.... your code was previously completely synchronized to load cell measurements, not sure what to make what you've got right now

15:40 <zmatt> other than that it looks like it will spam python with messages at the pru's max rate

15:56 <mattb0ne> right, the loadcell is still the bottleneck which is fine.

15:56 <mattb0ne> So is the compiler smart enough to deal with the fact that I am mapping to shared memory in two separate programs. Like when I load it wont overwrite anything?

16:27 <zmatt> lol no, the compiler is dumb as fuck

16:28 <zmatt> the load cell wasn't merely "the bottleneck", it was the source of timing for your entire control loop

16:29 <zmatt> i.e. any alteration that causes "receive_measurement()" to no longer be at the top of your main loop is a complete change in how the program works

16:30 <zmatt> if you want to use two C programs, the shared memory region should be initialized by at most one of them

16:31 <zmatt> or they could be made responsible for non-overlapping parts of it

16:33 <zmatt> it would be nice if it were possible to just define and initialize the variable in one program and declare it as "extern" in the other and somehow make this work with the linker, but that doesn't seem like it would be particularly easy (but it's something I've had occasional thoughts about myself)

16:35 <zmatt> easiest is to just ensure (though the linker script) that each piece of memory is "owned" by only one of the two programs, allocate stuff in it at fixed offsets, and then access it from the other core by casting the address to a pointer (same as how you accessed the quadrature decoder value when the other pru core was doing that)

16:49 <zmatt> what your use case currently for using both cores?

20:26 <mattb00ne> I am stuck on why this does not incrementing

20:26 <mattb00ne> https://pastebin.com/NTqYgajd

20:26 <mattb00ne> is the c code

20:27 <mattb00ne> https://pastebin.com/PHzSBkXm

20:27 <mattb00ne> the python

20:27 <mattb00ne> when I run I will get that the target and current are different but it appears that pos is not incrementing or the code gets trapped.

20:28 <mattb00ne> but I am not sure why...

20:28 <mattb00ne> wondering if my mapping is no good.