Remove dependency on standard library about tinyfsm

[digint]

Thanks for reporting!

I forgot how painful it is to work with crippled compilers (I guess you have some AVR compiler or similar?)...

Here's a fix:

• 9bcf2ac: add tinyfsm::is_state_of<F,S> type trait (abstraction for static asserts
• 2bf67f5: remove extraneous static asserts on transit functions; add asserts on illegal state
• e0f40ac: add TINYFSM_NOSTDLIB compile option (disable static asserts)

This is currently on nostdlib branch: could you please make a quick review and give me a feedback before I merge it?

[niliopoulos]

The nostdlib branch compiles and runs properly with AVR toolchain now.

Thanks!

[digint]

Thanks for testing! can you provide me a link to the AVR toolchain you are using?

[niliopoulos]

Of course,
It is this one:
http://distribute.atmel.no/tools/opensource/Atmel-AVR-GNU-Toolchain/3.4.3/
I inspected the distribution structure a bit and did find experimental features that can enable type_traits but didn't test it. Maybe it is time for us to move to a newer version anyway though.

[digint]

Thanks for the link! I found type_traits in:
http://distribute.atmel.no/tools/opensource/Atmel-AVR-GNU-Toolchain/3.4.3/avr-gcc-4.8.1.tar.gz

# find -name type_traits
[...]
./gcc/libstdc++-v3/include/std/type_traits

It's part of the "type support library", so simply including it should probably work . This is all compile-time stuff and can come in very handy, especially in embedded environments.
Something like this (+probably some dependencies):

gcc -isystem /opt/toolchain/avr/gcc/libstdc++-v3/include/std

See my fancy stuff in: "OpenMPTL - C++ Microprocessor Template Library", especially the stm32f103stk-demo which also uses tinyfsm:

https://github.com/digint/openmptl/tree/master/projects/stm32f103stk-demo/src

@niliopoulos : I'd love to have a little AVR example in TinyFSM. Do you have something you could contribute here? e.g. a basic example with Makefile using the AVR toolchain.

[niliopoulos]

We were looking for OpenMPTL functionality a few months back but we got carried away by higher level stuff. I really like the interface and will try to play with it when we are again at the lower level cycle of development.

Regarding the example, we are currently working on the implementation of an NFA that we expect to publish in the next year and will make sure we give proper credit because without tinyfsm, development, debugging and maintenance would be a nightmare. I am not sure we will publish the code though. What we found interesting is that really the only item that needed to be different from the tinyfsm examples is that the external events are based either on polling or on interrupt callbacks.

[digint]

Regarding the example, we are currently working on the implementation of an NFA that we expect to publish in the next year and will make sure we give proper credit because without tinyfsm, development, debugging and maintenance would be a nightmare.

Well thanks for the credits, tt's always nice to see people finding my stuff useful!

What we found interesting is that really the only item that needed to be different from the tinyfsm examples is that the external events are based either on polling or on interrupt callbacks.

Yes, that's exactly why higher level event dispatching is explicitely not part of tinyfsm. I've used it with interrupts (some low-level SPI), also in conjunction with event queues: basically a scheduler which also generates events by polling. This all was very straight forward, and as long as you don't code braindead things, TinyFSM just works for me.

[digint]

This is now included in TinyFSM-v0.3.2, closing issue.