On 30/06/17 23:05, Chris Albertson wrote:
That is not "ugly" is the common why things are done in real-time
systems.
You try as hard as you can to push everything you can into user space.
What you describe is actually "best practice".
Look even at the normal Linux kernel. Typically an interrupt handler might
read data off the interface then flip a bit and that's it. Processing the
data happens in a user space task. Very common design pattern used over
and over.
I'm not talking about file I/O while running in real time. The task is
started from user space so at startup you have access to user space.
That is how command line config values are passed to the real-time task.
I was hoping there would be some way to make use of that to load config
values from a file instead of the command line.
By ugly I was talking about setting up shared memory communications
simply to pass config values once at startup. It is also untidy from the
user's viewpoint. They need to load two modules even though one is going
to simply read from a file, squirt those values to the HAL module then exit.
I'm doing other work right now in a different area (not MK) and I'm using a
full on actual RTOS (Not Linux based) and a common structure I use is the
"work queue" I'll do minimum processing in the real time task then place a
task on the queue. Then background non-real time tasks pull work requests
off the queue. This is the "Computer Science 101" text book design that
was like used back in the 1950's
Of course you keep the real-time task as lean as possible. I'm fully
aware of that and have also done plenty of RTOS stuff. I've even written
my own cooperative + preemptive real-time multi-tasking OS for one
project where space and cpu were so constrained no off-the-shelf RTOS
would work. That one raised a few eyebrows when I wrote it in C++. A lot
of people think C++ is more bloated and slower than C but it all comes
down to how you use it.
Les
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Emc-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-users
