Re: [Boost-users] [Statechart] Porting to Embedded Linux and C (not C++)

From: Andreas Huber (ahd6974-spamgroupstrap_at_[hidden])
Date: 2007-01-10 18:37:29

Hi Eli

> For the embedded software project I am working on, we are seeking a
> library to run Statecharts.
>
> The run-time environment is :
>
> *         ARM cpu
>
> *         Linux 2.6
>
> *         C (not C++)
>
> *         Embedded / real-time application
>
>
>
> I read about the Boost.Statechart tool, and have some questions,
> mostly concerning the run-time part of the tool.
>
> 1. Is there anyone out there using the tool on similar
> environments?

I don't know for sure but I guess not, since I've never heard from any 
uses of the library from C.

> a. If you do
>
>                                                                i.
> Can you comment on the effort required to port the tool to a Linux
> (preferably 2.6) environment?
>
>                                                              ii.
> Can you supply some measures concerning real-time restrictions caused
> by using the tool (added latencies, memory usage, determinism, ...)
>
> b. Can one of the developers comment on the above (assuming
> there are no user comments)?

I don't have any measurements appart from the ones in the documentation 
...

http://www.boost-consulting.com/boost/libs/statechart/doc/performance.html

... if that leaves any questions, please ask.

> 1. One of my greatest concern is the fact we are working in C. This
> introduces several problems
>
> a. Mixing C and C++. This is my smallest concern, since the
> compilers should have solved this long ago.
> b. Connecting the C++ produced by the tool to our C code.

Whether C code can easily interface with Boost.Statechart C++ code 
largely depends on what you want to do. I don't know much about the 
mixing of C with C++ code but it seems that you couldn't directly access 
any of the C++ classes/objects from C code. You'd need to write C++ 
accessor functions that only have C compatible types in their signatures 
for pretty much anything you want the library to do. If there are only a 
few such interaction points then the necessary effort would seem small.

> c. We do not have personnel proficient in C++. This means
> that the above problems, together with any deeper understanding of the
> internals of the tool will be problematic. This will hurt mostly
> during debug and integration.

I guess so, although one C++ crack in your team would probably go a long 
way.

> 2. Is there a visual tool to draw statecharts that generates
> Boost.Statechart code?

Not currently, although I had contact a few days ago with someone who 
wants to write such a tool. If you want I can mail you his address.
During Google Summer of Code there has been an attempt at the exact 
opposite (a tool that analyzes Boost.Statechart code and produces 
statechart diagrams) but it seems it would need more work to be useful 
in a real-world project.

> 3. I did not find the tool on boost.org. Does this mean it has not
> been formally released?

Exactly, it was accepted almost a year ago, but sadly there hasn't been 
a Boost release in the mean time.

HTH & Regards,

-- 
Andreas Huber
When replying by private email, please remove the words spam and trap
from the address shown in the header.