KREYREN has quit [Remote host closed the connection]
KREYREN has joined #beagle
ikarso has quit [Quit: Connection closed for inactivity]
<set_>
KREYREN: Hello.
<set_>
Try, um, those people...
<set_>
Dang it.
<set_>
Please hold.
<set_>
CentroidCNC with the beaglebone green.
<set_>
KREYREN: They have a nice "new one" that I found recently too. It is a beaglebone green with a larger formatted board and CNC support. It is nifty. One is called Acorn and the other is called something else but has more XYZ ABC and so on...
samnob has quit [Quit: I'm not smart enuf to edit bouncer.conf]
frostsnow has quit [Ping timeout: 260 seconds]
vagrantc has quit [Quit: leaving]
aussetg has quit [Remote host closed the connection]
aussetg has joined #beagle
Shadyman has joined #beagle
hnv has quit [Quit: Client closed]
buzzmarshall has quit [Quit: Konversation terminated!]
darkapex has joined #beagle
Steve_ has joined #beagle
SJFriedl has quit [Ping timeout: 268 seconds]
CrazyEddy has quit [Ping timeout: 252 seconds]
CrazyEddy has joined #beagle
KREYREN has quit [Remote host closed the connection]
KREYREN has joined #beagle
ft has quit [Quit: leaving]
frostsnow has joined #beagle
mvaittin has joined #beagle
rob_w has joined #beagle
shoragan has quit [Quit: quit]
Mor has joined #beagle
set_ has quit [Ping timeout: 260 seconds]
Mor has quit [Remote host closed the connection]
set_ has joined #beagle
russ has quit [Ping timeout: 256 seconds]
florian has joined #beagle
russ has joined #beagle
shoragan has joined #beagle
KREYREN has quit [Remote host closed the connection]
<mattb00ne>
so I set a value in python PRU will respond by moving the stepper.
<mattb00ne>
What is not happening is that PRU cannot seem to talk to PRU0 or Python
<mattb00ne>
my PRU1 code is a toy code and is just assigning a value but no one else can see it.
<mattb00ne>
The memory mapping is good
<mattb00ne>
It seems to me the py-uio will not permit communication between the PRUs
hnv has joined #beagle
mattb000ne has quit [Ping timeout: 268 seconds]
mattb00ne has quit [Ping timeout: 268 seconds]
<zmatt>
everything can communicate with everything
<zmatt>
I would definitely like to make it easier though, e.g. use the ELF symbol table or DWARF debug info to simply access variables of the PRU code by name
<mattb000ne>
the one change I tried on a whim is to map the shared variables twice
<mattb000ne>
something I have not done in my actual program
<zmatt>
this is already kinda problematic since both programs are initializing the shared variable
<mattb000ne>
right
<zmatt>
but it will work yeah
<mattb000ne>
is that a crappy work around is to map it twice
<zmatt>
(also, both programs incrementing shared_counter is obviously a race condition)
<mattb000ne>
i tried to stagger with the delays
<mattb000ne>
but yeah I know it is bad
<mattb000ne>
I just wanted to have python, pru0 and pru1 share variablees
<mattb000ne>
having problems with that
<mattb0ne>
let me see if it breaks if I do not do the double map
<mattb0ne>
hmmm
<mattb0ne>
still works
<mattb0ne>
so something else is wrong
<mattb0ne>
grrrrrrrr
<mattb0ne>
but that makes sense
<mattb0ne>
one mapping should be sufficent
<zmatt>
I have no idea what you're talking about
<zmatt>
the main problem with what you're doing here is that the current linker map tells the compiler it owns the shared memory region (0x10000-0x12fff) and can allocate variables there
<zmatt>
doing that with both cores is dangerous
<mattb0ne>
so what is the proper way to have the PRUs communicate
mattb00ne has quit [Ping timeout: 256 seconds]
<mattb0ne>
They both need to know the addresses in shared memory
<zmatt>
e.g. if your program gets bigger the compiler could run out of space in the core's private ram (0x0000 - 0x1fff) can allocate stuff in the shared memory region since it still have plenty of space... and if both programs think they can do that you'll have a spectacular mess
<mattb0ne>
hmmm
mattb000ne has quit [Ping timeout: 264 seconds]
<mattb0ne>
I got a big array of 2000 uint16s
<mattb0ne>
in shared
<mattb0ne>
that I guess I am asking to be allocated twice
<zmatt>
the best way would be if py-uio had the ability to link the two programs in such a way that you can simply refer to the other program's variables by name and you don't even need to worry about what address
<zmatt>
but that's not gonna happen on very short notice
<mattb0ne>
ok
<mattb0ne>
for a stop gap
<mattb0ne>
I can shrink what is in shared memory space maybe?
<zmatt>
so, there's two aspects here: how allocation is decided, and how you actually access it
<mattb0ne>
at a minimum I need to have PRU check for 1 value from the other PRU
<mattb0ne>
or I could live with just that capability
<zmatt>
both pru cores and python can access all memory in pruss
<mattb0ne>
could I sort of hard code it
<zmatt>
lemme think a moment how to best approach this for you
<mattb0ne>
where the PRU will blindly read this spot in memory
<mattb0ne>
ok thanks
<zmatt>
like, yes you can do that. you can choose which parts of pru memory can be used by the compiler to allocate variables, and by simply omitting part of memory you can ensure the compiler will not put stuff there and therefore you're free to use that memory directly in whatever way you want
ikarso has joined #beagle
<mattb0ne>
sounds hard I would manually have a map
<zmatt>
e.g. if we change the linker map so that the compiler doesn't know about the shared memory region then you can simply decide that UserControlVars lives at 0x10100 and access it using (struct UserControlVars volatile *)0x10100
<mattb0ne>
but that requires a change in the linker
<mattb0ne>
or it can do that stock
<zmatt>
a trivial change in the linker _script_ that's in your source tree
<zmatt>
called am335x.cmd or something probably
<zmatt>
it needs to be changed regardless, right now you're telling the compiler for both programs that it's free to allocate stuff in shared mem
<zmatt>
that's definitely not okay
<mattb0ne>
ok
<mattb0ne>
so should I go that route or wait and see if you have a better approach
<zmatt>
each piece of memory needs to be *either* owned by the compiler for the pru0 program *or* owned by the compiler for the pru0 program *or* used for manual allocation
<zmatt>
of course even if a piece of memory is compiler-owned you can still put variables in there at a known address using the location-attribute like you're doing right now
<zmatt>
the benefit of that instead of completely manually allocating is that at least you'll get an error if you accidently overlap variables
<mattb0ne>
ok
<mattb0ne>
i found my am335x.cmd file
<zmatt>
in the MEMORY{} section you should have two regions declared
<zmatt>
eh
<zmatt>
I mean, two data regions in PAGE 1
<mattb0ne>
yes
<mattb0ne>
Local and shared
<zmatt>
the only way you can safely use the same linker script for both cores is it neither owns the shared memory
<mattb0ne>
so delete the shared line?
<zmatt>
alternatively you can use two separate linker scripts, and then one of them can own shared memory (or you can split the shared memory between them)
<mattb0ne>
I like the first option
<mattb0ne>
no one ones shared
<mattb0ne>
owns*
<zmatt>
if neither of them owns shared then this would mean you're choosing to manually allocate stuff in shared and it'll be your responsibility to ensure variables don't overlap
<zmatt>
(and to ensure they actually fit in shared memory)
<mattb0ne>
ok nevermind that
<mattb0ne>
too hard
<zmatt>
lol
<mattb0ne>
I guess lets split it
<zmatt>
it's probably easier to just let one core own all of it
<mattb0ne>
ok
<mattb0ne>
so leave the shared line in tact on one version of the linker script and delete it in the other version?
<zmatt>
so copy the linker script and I suggest naming them after your main source file but .cmd instead of .cc
<zmatt>
then it's easy to make a makefile rule that automatically uses the right linker script
<zmatt>
in the program that owns SHARED you can just define variables in there
<mattb0ne>
for the program that will not own shared
<mattb0ne>
I am getting a link error - cannot find file "md"
<zmatt>
the other program can access them by casting the address to a pointer, but making a #define for that makes it nicer and means you can access the variable the same way in both cases
<mattb0ne>
cool
<zmatt>
?? that sounds like you made a typo somewhere
<mattb0ne>
in the edit to the am335x.cmd file
<zmatt>
wait hold on
<mattb0ne>
the line to be edited did not have a -k in it