Hey everyone,
I am working on a project where an STM32F0 microcontroller generates 220 bytes of data from an sensor array every millisecond.
Now I want to have this data on my beaglebone black so I can write it to files and send it away with FTP.
But I only have an time gap of 200-300 usec where I can send data to the beaglebone.
I can buffer some bytes on the STM32 but is had limited memory size (like 3-4 ms).
Can anybody give me an solution?
I looked into SPI but the beaglebone is only working in master mode, so i wanted to trigger it with an interrupt but it is only responding in 1-3 milliseconds.
I also looked for an SD card buffer between the two but I think it is to slow with this amount of data.
Does anybody know a way of creating an sort of FIFO buffer between the beaglebone and the STM of some other way of fast data handling.
Thanks in advance,
Gr Teus
Switch to a real-time kernel (PREEMPT_RT or Xenomai) and you can get
interrupt latencies in the 50-100 uS range, which ought to be fast
enough to use SPI.
Alternatively, you could modify the PRU code from the BeagleLogic
project to recognize a data/strobe handshake from the STM32 which
would get the data into the BBB where you can use the reset of the
BeagleLogic framework to buffer it in DRAM on it's way to wherever
else it's headed (network, uSD card, etc).
Alternatively, you could modify the PRU code from the BeagleLogic
project to recognize a data/strobe handshake from the STM32 which
would get the data into the BBB where you can use the reset of the
BeagleLogic framework to buffer it in DRAM on it’s way to wherever
else it’s headed (network, uSD card, etc).
I wonder if using both PRU’s directly, instead of using the STM32 would be faster ? That is to say, one PRU captures the data(does it need post processing too ? ), then broadsides that data to scratchpad buffer, where the other PRU takes over and shuffles off to DDR.
However, Charles maybe you know the answer to this question. I’ve been slowly reading about the uio_pruss driver in code etc. And it seems that the pru shared library code gives C access to the 12KB shared ram directly ? Wouldn’t it just be faster to mmap() that shared memory which is high speed access for the PRUs ? I mean mmap() is mmap() from C( Linux ) so I’m thinking that could help the PRUs keep up in many situations. Passed that though, I know for a fact, that mmap() through /dev/mem/ is at minimum capable of ~3M / second data with a ti-rt, or bone-rt kernel. From my experiments using the ADC module.
I don’t know though . . . maybe too much of a learning curve initially for Gr Teus ?