I need to interface BBB with a PIC microcontroller using UART. I have had partial success- I could read the data received by BBB using minicom as well as this command: (stty 115200 cs8 -ixon; cat) < /dev/ttyO0 > UART_data.log
I assume these two methods use polling.
My app expects around 80kB data from PIC and need to write it into some file. Since polling would mean that BBB would’ve to loop and not be able to execute anything else, I guess I should go for interrupt driven UART. But I’m totally clueless on how to go about it. Can someone please help me?
Notice that when you specify the amount of data to be read (nbytes) the read "blocks" until that amount of data arrives. But while blocked waiting, you will also notice that the CPU is almost all free for other threads and processes.
So simply start a new thread or process and use the OS to read the data. The OS will handle it gracefully, with low CPU overhead. Even if you loop, reading small chunks (like 1 or 8 bytes, for instance), just for checking the live stream in real time, still the CPU usage would be negligible at 115200.
I need to interface BBB with a PIC microcontroller using UART. I have
had
partial success- I could read the data received by BBB using minicom as
well as this command: (stty 115200 cs8 -ixon; cat) < /dev/ttyO0 >
UART_data.log
I assume these two methods use polling.
My app expects around 80kB data from PIC and need to write it into some
file. Since polling would mean that BBB would've to loop and not be
able to
execute anything else, I guess I should go for interrupt driven UART.
But
I'm totally clueless on how to go about it. Can someone please help me?
I assume these two methods end up doing a libc "read", which transfers to
the OS the task of reading the data. IFAIK, it does use interrupts.
Notice that when you specify the amount of data to be read (nbytes) the
read "blocks" until that amount of data arrives. But while blocked
waiting, you will also notice that the CPU is almost all free for other
threads and processes.
So simply start a new thread or process and use the OS to read the data.
The OS will handle it gracefully, with low CPU overhead. Even if you
loop, reading small chunks (like 1 or 8 bytes, for instance), just for
checking the live stream in real time, still the CPU usage would be
negligible at 115200.
Or you can use Node.js which uses non blocking I/O. No need to deal with
the problems associated with threads. If you want to present that data on
a dynamic webpage, you could do that in just a few lines of code.