Re: Messaging Frameworks in Embedded C/C++ / Serialization
John Carter wrote:
So the situation is this...
We have multiple multi-threaded embedded systems that must
communicate via message passing both with internal threads
(using eCos mailbox's) and with the other devices over serial
(RS-485) links.
Currently we are using a klutzy pack struct's, copy structs
homebrew that does way too many mallocs and copies and struct
packs and each new message means allocating new message ID's
and touching upto 4 or 5 files.
And for remote messaging we use almost the same, but even
messier method.
I believe I can make it possible to...
a) Make a message send look exactly like a C++ method call.
b) Make a message handler look exactly like a C++ method. (ie. Threads
become ActiveObjects for C++)
c) Make a remote message send/receive look exactly like a local one.
This may take a wee bit of magic on my part, but I know I can do it.
Additional constraints....
1) The remote messaging must be endian neutral (ie. Mix of big
and little endian devices present.)
2) The protocol / messaging spec needs to be open. ie. PC
based Reference implementation, Documented and shipped to 3rd
parties to implement own devices.
3) It must be ram/rom/cpu light weight enough to fit in highly
resource constrained embedded systems. ie. If I understand
things correctly, that means not CORBA. (Please correct me if
I'm wrong.)
You probably cannot use full Corba, but a subset might work.
Still, it sounds like your in a more industrial context, where
ASN.1 rules.
In any case, I'd definitly start by using some sort of higher
level specification language to define the interfaces. Corba is
very C++'ish in some ways (albeit a somewhat dated C++), and
defines interfaces and functions. ASN.1 defines the data
structures which will be translated. As you apparently realize,
the higher level of abstraction in Corba does have its costs.
Both Corba and ASN.1 are fairly complex, because they are
designed to meet a wide variety of situations. If you have
resource constraints, I would definitly consider subsetting
them, even if it means implementing a large part of the
framework in house. (Much of the complexity in both is involved
with addressing---if you know exactly where each object is in
advance, you can simplify enormously.)
Question: This feels like reinventing the wheel. Any well
known round wheels out there that does this?
Question 2: Any parts of this puzzle available eg. The endian
neutral (de)?serialization/marshalling
Corba handles serialization internally, so you don't have to be
concerned with it. ASN.1 supports several types of encoding;
there are also external tools chains supporting it, although
they probably aren't as advanced nor as wide spread as those
supporting Corba.
I'm currently digging around in the ONC RPC/XDR spec wondering
if I can't reuse chunks of it.
Somehow I feel intelligent use of C++ must make it all a lot
cleaner...(eg. Endianess handling cries out to be handled via
traits/policies.)
Endianess takes care of itself if you do things right; it's
simply not a problem. Things like differenting floating point
formats are, as are different integer formats, if you have to
support machines which don't have a 32 bit 2's complement
integral type.
Beyond that, you can doubtlessly do a lot with metaprogramming,
but why make life hard for yourself. This sort of problem just
cries out for an external, code generating tool.
--
James Kanze GABI Software
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]