**** BEGIN LOGGING AT Sun Dec 09 03:00:02 2018
Dec 09 10:20:52 <zmatt> interesting, I didn't know that... prior to g++ 5 (which completed c++11 support and made it the default), std::string used copy-on-write, but this is incompatible with c++11 requirements hence using copy-on-write for strings was dropped
Dec 09 10:22:05 <zmatt> it's a shame since I'd imagine COW would often be a useful optimization.  but I can understand it's problematic if any write to the string can cause reallocation and as a result invalidate all iterators into the string
Dec 09 15:40:25 <Guest53470> My BBB is reading 4 channels of sound from 4 ADCs. Having set up the PRUs etc I issue prussdrv_pru_wait_event(PRU_EVTOUT_0). That reads in a chunk (4096) samples on 4 channels. I read that into Linux memory from the variable pru_base. That works fine. Then I want to change pru_base to read another area of PRU memory. I read that in and its all zeroes. How should I aim prussdrv_pru_wait_event() at another database?
Dec 09 15:43:18 <zmatt> events have nothing to do with memory
Dec 09 15:44:47 <zmatt> I don't really understand what you're saying though.  you're saying you're writing data on the pru to some memory but it subsequently reads as zeros by linux?
Dec 09 15:44:55 <zmatt> which memory are you using?
Dec 09 15:56:24 <Guest53470> Trouble is someone else wrote the code and then got very sick and isn't thinking straight so I can't ask what its doing. The basic idea is that you read off a chunks worth in PRU, then quickly read that data in to LINUX memory. The ADCs then read another chunk into different PRU memory
Dec 09 16:01:45 <Guest53470> The upsjot is that I get one chunk of good data followed by a second chunf 0s
Dec 09 16:02:12 <Guest53470> sorry: a second chunk of 0s
Dec 09 16:06:35 <Guest53470> zmatt - I've found a lump of text that might explain - so I'll got and read that Thanks
Dec 09 16:46:12 <zmatt> depends very much on the protocol used
Dec 09 16:46:18 <zmatt> shared memory can be tricky to get right
Dec 09 16:49:08 <zmatt> if pru writes data and then signals the intended consumer of that data (i.e. the cortex-a8) using a fast mechanism like an event, beware that the pru's writes to memory could theoretically still be "in flight" when the cortex-a8 receives the event
Dec 09 16:49:52 <zmatt> though in practice, the irq latency in linux is several order of magnitudes higher than the typical time it takes for pru's writes to safely land at the memory controller
Dec 09 16:50:03 <zmatt> (this is assuming you're using ddr memory, not pru subsystem local memory)
Dec 09 19:12:55 <ayjay_t> its commenting time
Dec 09 19:12:57 <ayjay_t> time to document
**** ENDING LOGGING AT Mon Dec 10 03:00:00 2018