OK - so, I’ve done some further work… (Interspersed by work (the day job) and some holidays.) The system seems to be working pretty well, here are the details and some comments:
The Delay function was replaced with the Delay_Microsecond function. Achieved via calling the Delay_Microsecond function within the Delay function, of course multiplying the delay time by 1000.
(The TimingDelay variable was also removed as part of this, as it’s no longer necessary to track the delay, as ‘clocked’ via the systick interrupt handler.)
A port of the QP framework - specifically QP/C++ Version 4.5.04, and that provided in one of the examples for the ARM CORTEX M3 (dpp-stm3210c-eval) - was used. STM3210C specific code was removed as it’s irrelevant, particularly given that the STM3210C is an evaluation board with an LCD, etc., etc.
A basic “supervisor” type active object was implemented to manage everything. The systick timing wasn’t changed, so it’s still every 1 ms. This means that the QP framework is tick’ed every 1 ms. Then there is a 1 ms user (QP) timer which checks on the network status.
The wlan specific code was moved from the main routine into the supervisor active object such that network connection is handled and then maintained.
I’m yet to move the button press handling from the Timing_Decrement routine. Based on what I’m thinking handling these this is best located in the supervisor active object.
- The spark core (or rather: particle core) performs the network connection fine and connects to the cloud.
- Currently I can’t put the particle core into listening mode - I’m sure there’s some minor issue here which I’ve missed. Although I can easily write new firmware (DFU mode) and then it connects to the wlan / cloud fine.
How to leverage the QP framework? (read: why QP?)
So a good question… Here’s my thinking:
Relating to state machines, but maybe not the prime focus: A lot of programming problems exist because of lack of knowledge of what will happen in the future (the classic example is: “How many bytes to allocate in a buffer?”). A state machine clearly indicates what to do when.
(And the particle core is powerful enough to require some form of realistic OS, nothing too complicated, but something that makes everything easy and possible.)
The QP framework makes developing embedded code easy(!). (I’ve developed a GPS Disciplined Oscialltor on an Arduino, with an LCD and button UI, not to mention the GPS message handlers. Everything just works.)
Active objects are a mechanism to provide for all of this. A good design pattern.
The framework offers both co-operative and pre-emptive scheduling options built-in.
The QP framework is freely available (GPL v2 licencing).
Of course preference for programming style is just that. But I’m a believer of state machines for embedded development, with the QP framework being readily available, quite well documented and it makes things easy.
Anyway, I’ll keep you posted of my adventures…