Question about real-time programming on Pandaboard
Leo
I had trouble using fprintf() function in real-time linux.
When I use fpirntf() function in 10[ms] loop, the delay occurs sometimes.
I think fprinf() function is not proper for real-time programming.
After substituing fprintf() with sprintf() & fwrite(), the 10[ms] loop looks fine.
But I am still not confident about that way.
Is this the best way to save data to file?
I attached the C code file.
- Ji-Hyuk Yang
Dave Hylands
On Sun, Apr 15, 2012 at 3:12 AM, Leo <zero...@gmail.com> wrote:
> I had trouble using fprintf() function in real-time linux.
>
> When I use fpirntf() function in 10[ms] loop, the delay occurs sometimes.
>
> I think fprinf() function is not proper for real-time programming.
>
> After substituing fprintf() with sprintf() & fwrite(), the 10[ms] loop looks
> fine.
>
> But I am still not confident about that way.
>
> Is this the best way to save data to file?
I'm not sure why sprintf/fwrite should be any faster.
You don't want to be doing file I/O from inside a loop that's running
every 10 msec.
You want to write your data into some type of memory buffer and have
an I/O thread which writes the data.
In order to get good I/O performace you'll also need to be careful
about how you write the data. Using fopen/fwrite/fprintf type calls,
they use a 4K or 8K internal buffer which will generally give you poor
performance. You'll want to increase your buffer size to 64K or 128K.
Also, some devices, like MMC are notoriously slow doing writes, so the
type of card makes a huge difference.
Look at the function setvbuf for setting up the buffer associated with a FILE *.
--
Dave Hylands
Shuswap, BC, Canada
http://www.davehylands.com
Bob Smith
> Is this the best way to save data to file?
Well, probably not.
The problem is that disk IO can be _REALLY_ slow.
In fact, the whole idea of real-time extensions is
mostly to get around disk IO problems. Putting
disk IO in a real time process probably just won't
work.
Use a real time process to deal just with the
hardware that requires it. Have another process
do the disk write and have the two processes talk
to each other through sockets or shared memory.
Whether sockets or shared memory, make sure there
is enough buffer space between the two so that
the real time process never blocks waiting for
a free buffer.
hope this help
Bob Smith