Any advice on using Boost++ on eCos?

[Papa Legba]

The title says it all... any advice, pointers to web sites, etc, etc?

Looking to switch away from VxWorks (eCos looks ideal) and at the same time use the Boost++ State machine classes.

Thanks in advance.

[Andrew Lunn-2]

On Tue, Sep 09, 2008 at 02:43:44AM -0700, Papa Legba wrote:
>
> The title says it all... any advice, pointers to web sites, etc, etc?
>
> Looking to switch away from VxWorks (eCos looks ideal) and at the same time
> use the Boost++ State machine classes.

I'm no C++ programmer, so do verify everything i say...

eCos does not support full C++. In particular exceptions are
missing. A couple of people have made some hacks to get this to work,
look in the archive.

If you are prepared to pay some money eCosCentric have a version of
eCos with full C++ support. Getting Boost to work on top of that is
probably much easier way to go.

         Andrew

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[Klaas Gadeyne-4]

On Tue, 9 Sep 2008, Andrew Lunn wrote:

> On Tue, Sep 09, 2008 at 02:43:44AM -0700, Papa Legba wrote:
>>
>> The title says it all... any advice, pointers to web sites, etc, etc?
>>
>> Looking to switch away from VxWorks (eCos looks ideal) and at the same time
>> use the Boost++ State machine classes.
>
> I'm no C++ programmer, so do verify everything i say...
>
> eCos does not support full C++. In particular exceptions are
> missing. A couple of people have made some hacks to get this to work,
> look in the archive.

We started from this page <http://www.zylin.com/libstdc++.html> to get exceptions working in the eCos toolchain.  Apart from some minor issues (which I forgot, please check the zylin ML archives) this worked like a charm.  After that we used Boost++ with eCos (during the port of orocos <http://www.orocos.org/>) without any problems (no modifications to the boost sources were necessary).  However, orocos does not use the Boost state machine classes.

HTH,

Klaas

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[Papa Legba]

Andrew Lunn-2 wrote:

I'm no C++ programmer, so do verify everything i say...

eCos does not support full C++. In particular exceptions are
missing. A couple of people have made some hacks to get this to work,
look in the archive.

If you are prepared to pay some money eCosCentric have a version of
eCos with full C++ support. Getting Boost to work on top of that is
probably much easier way to go.

We can live without exception handling, because we are still having arguments about whether the generated code seriously impacts code size & run-time.

In general, there is a lot of disagreement about whether exceptions are A Good Thing or not *in embedded systems*. Most people don't seem to like them; I personally do, but my team doesn't.

Is anyone else aware of anything else which si not supported? Thanks.

[Frank Pagliughi]

Papa Legba wrote:
> Looking to switch away from VxWorks (eCos looks ideal) and at the same time
> use the Boost++ State machine classes.
>  
Keep in mind that Boost isn't a homogeneous library, but really a
library of libraries, all written by different people with different
goals. Some are layered on other part of the library, but many are
fairly independent, and can often be used by themselves without needing
to port the whole thing.

Some parts of Boost use RTTI, and many parts make heavy use of dynamic
memory, so even if you get it to compile and run, you could have heap
issues, depending on your platform.

And the Boost state chart classes seem to have been written more for
completeness and compatibility with UML designs, and less for
efficiency. In particular, every state is an object and each state
change causes the destruction of the old state and the construction of
the new state. Every state change.

If you're going to make heavy use of the advanced features of the state
chart library, it might be worth the effort, but for simpler state
machines, you can probably find another library that's more appropriate
for use with an RTOS.

Frank

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[Papa Legba]

Frank Pagliughi wrote:

Papa Legba wrote:
> Looking to switch away from VxWorks (eCos looks ideal) and at the same time
> use the Boost++ State machine classes.
>  
Some parts of Boost use RTTI, and many parts make heavy use of dynamic
memory, so even if you get it to compile and run, you could have heap
issues, depending on your platform.

And the Boost state chart classes seem to have been written more for
completeness and compatibility with UML designs, and less for
efficiency. In particular, every state is an object and each state
change causes the destruction of the old state and the construction of
the new state. Every state change.

If you're going to make heavy use of the advanced features of the state
chart library, it might be worth the effort, but for simpler state
machines, you can probably find another library that's more appropriate
for use with an RTOS.

Thank, you, Frank.  Yes, I am a little concerned about heap usage. I don't like the dynamic creation & deletion of states, etc and the whole thing, on closer investigation, seems to be hideously over-complex for my needs.

I think that I will look for something a lot simpler and more static.

Any suggestions, anyone?

[Simon Kallweit]

Papa Legba wrote:

>
> Frank Pagliughi wrote:
>  
>> Papa Legba wrote:
>>    
>>> Looking to switch away from VxWorks (eCos looks ideal) and at the same
>>> time
>>> use the Boost++ State machine classes.
>>>  
>>>      
>> Some parts of Boost use RTTI, and many parts make heavy use of dynamic
>> memory, so even if you get it to compile and run, you could have heap
>> issues, depending on your platform.
>>
>> And the Boost state chart classes seem to have been written more for
>> completeness and compatibility with UML designs, and less for
>> efficiency. In particular, every state is an object and each state
>> change causes the destruction of the old state and the construction of
>> the new state. Every state change.
>>
>> If you're going to make heavy use of the advanced features of the state
>> chart library, it might be worth the effort, but for simpler state
>> machines, you can probably find another library that's more appropriate
>> for use with an RTOS.
>>
>>    
>
> Thank, you, Frank.  Yes, I am a little concerned about heap usage. I don't
> like the dynamic creation & deletion of states, etc and the whole thing, on
> closer investigation, seems to be hideously over-complex for my needs.
>
> I think that I will look for something a lot simpler and more static.
>
> Any suggestions, anyone?
>  

Check out Quantum Leaps QP state machine frameworks. They are pretty
nice for embedded systems, and they come with GPLv2 or a commercial
license. Also have a look at the state map compiler project.

Simon


--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[Andrew Lunn-2]

> Check out Quantum Leaps QP state machine frameworks. They are pretty  
> nice for embedded systems, and they come with GPLv2 or a commercial  
> license. Also have a look at the state map compiler project.

Just watch out for the GPLv2 license. Remember is spreads, so all your
application and eCos becomes GPL. In most systems where eCos is used,
this is not wanted, so you will end up paying for the commercial
license.

         Andrew

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss