<nick12310>
zmatt in your py-uio module, how is the write() and read() function meant to work? I am trying to write to memory with core.write(100, 0x10000) for example, but when I do a core.core.read(c_uint32, 0x10000), I always get 0
<nick12310>
core.read(c_uint32, 0x10000)*
<zmatt>
hmm I should probably add an explicit check to write() that raises a TypeError if you try to stick an int into it
<zmatt>
since write() converts the data to a bytes object, and bytes(100) is just 100 zero-bytes
<nick12310>
what is meant to be written into it?
<zmatt>
bytes or anything convertible to bytes, e.g. a ctypes object... in this case you probably meant to do core.write(c_uint32(100), 0x10000)
<zmatt>
if you intended to write a 32-bit unsigned integer to that location
<nick12310>
ah, yes ok.
<zmatt>
I'll be honest I rarely use read()/write(), map() is more appropriate for shared variables
<nick12310>
how do you write on the mapped variable in that case?
<zmatt>
same as you'd use ctypes objects in any other context... for integer types such as c_uint32 the object has a value attribute that you can get/set to read/write the memory
<zmatt>
(except it doesn't write it, it just reads the value written by the C program)
<nick12310>
If I make a new variable separate, it does work.
<zmatt>
?
<nick12310>
I think maybe it's because I initially write to the address with my pru, are you not allowed to write to the same addresses between the two?
<zmatt>
you're allowed to do whatever you want, but obviously if you're going to write to a variable from both pru and python you're going to have to think about how exactly that's going to work out in a sensible way
<zmatt>
it pretty much just behaves like two threads sharing memory
<zmatt>
I can't really comment on what you did wrong without knowing exactly what you were doing
<nick12310>
Yea, I think I'm just mixing up the writing between the two, will attempt to fix
nick12310 has quit [Quit: Client closed]
buzzmarshall has quit [Quit: Konversation terminated!]