00:59 <nick12310> what does the mapping of foo and bar to memory do, in elf-test.py, does it  mean those variables now correspond to the values at those memory locations?

01:12 <zmatt> nick12310: essentially yes... they're ctypes.c_uint32 objects representing 32-bit unsigned integers at those locations in pru memory

01:12 <zmatt> so accessing foo.value will access pru memory

01:13 <zmatt> ctypes also can be used to define structures and arrays, and those can likewise be mapped using map()

01:13 <nick12310> Ok cool. I think my simple test is working.

01:14 <nick12310> So can I make a ctype string to print out troubleshooting messages from pru?

01:17 <zmatt> there are certainly ways to do that, although it requires a bit of care since strings are variable-length

01:18 <nick12310> Hm, yea. I guess a better way would be just to return a code corresponding to the message?

01:19 <zmatt> nick12310: look at fw-c/stream.cc and stream-c.py

01:21 <zmatt> note: allocating variables in shared memory like this: https://github.com/mvduin/py-uio/blob/master/pru-examples/fw-c/stream.cc#L24-L25 requires a linker script that places far data in shared memory, which the linker script in that directory (am335x.cmd) does, but I don't remember if that's standard/typical of linker scripts provided by TI

01:22 <zmatt> in this example I'm not actually reporting a message but the file name and line number where I'm halting, but obviously you could easily use the same mechanism to pass a message

01:32 <zmatt> (of course you're not _required_ to have clpru allocate stuff in shared memory for you, you can also keep doing it the manual way like you've been doing so far, but it's nice to have the linker verify your variables actually fit in shared memory and don't overlap)

06:05 <nick12310> I'm trying to test the inputs of my pru. I made a while loop for the case when one pin was tied on for it to loop endlessly, but for some reason this never stops my pru execution. I checked to make sure, and the value I'm checking is changing with the inputs, but just wondering is there another reason why this would happen?

07:45 <vitthal> Hi,

07:46 <vitthal> i am working on kgdb  debugger tools on beagle bone

07:47 <vitthal> when i am enter bellow command its open kdb prompt our side is not happening

07:47 <vitthal> echo g > /proc/sysrq-triger

07:47 <vitthal> please help any issue

21:46 <nick12310> Hi zmatt, I updated my py-uio for the fill(), read(), and write() methods, and now the examples fail to run. This is what I get now, https://pastebin.com/G2CG85Cz

21:50 <zmatt> huh wtf

21:52 <zmatt> how the fuck did that happen

21:53 <zmatt> a bunch of random crap managed to get included into the commit

21:56 <zmatt> fixed

22:02 <nick12310> yep, all fixed lol. Thanks!

22:03 <zmatt> thanks for alerting me