> On Tue, 22 Apr 2008, Martin wrote:
>
>
>> Are there any good books or resources that you would recommend about
>> designing software on the PIC? I don't mean "this is how you make an LED
>> blink" or "this is how you drive a stepper motor" but more like a
>> system-level design where you might have a timer-interrupt drive a state
>> machine that would accomplish 10 different tasks that you have to do?
>> (just an example, I don't know if that's how you'd actually do it)
>>
>> Also I've had a quick look at the likes of FreeRTOS - but I'm using
>> assembly. I feel like the only benefit of using C would be that my code
>> is more organized and perhaps quicker to develop (but then there'd be
>> low level bugs I can't see easily)
>>
>> Does anyone use an RTOS with assembly in their PIC 18F project? Would it
>> be very difficult to write some time-sharing code for a PIC?
>>
>
> If you build your system as a pure state machine (lots or states and
> events and NO hanging around in a state waiting for something to happen)
> then multitasking can become VERY simplified. You could even run multiple
> state machines on the same CPU and have each one looking after a different
> task (they could send each other events or communicate in other simple
> ways).
>
> C is not very good for multi-tasking because C does not know about
> multi-tasking, instead you need to use a library which introduces
> overheads and the seperate tasks can interfere with each other and there
> is no way for the compiler to know or generate task safe code.
>
> Converting a straight forward C or ASM program into a state machine can
> easily become tedious and error prone since the better you break down the
> program into a state machine the more states and events you produce. The
> more states and events you have the harder it is to keep track of
> everything (maintain and debug it).
>
> So what you need a tool that is to state machines as a C compiler is to
> machine code. You need a tool that takes a high level description of a
> state machine (which is easy to maintain and debug) and from it generates
> executable machine code. From choise you would use a tool that uses state
> diagrams to describe the state machine and allows you to debug your code
> using the same state diagrams - kind of like source level debugging in C
> or BASIC but on the diagram. I have a tool like this and it is called
> ZMech. There are other tools around. Some require that you specify the
> state machine in a high level text based language. Others that allow you
> to use diagrams. Some will only generate complex C++. Others that will
> generate C. But I haven't come across any (other than ZMech) that will
> allow you to produce machine executable code and interactively debug it
> directly against the state diagrams.
>
> Going back to the alternate multi-tasking approach, there is the XCSB
> compiler which produces highly efficient machine code executables. The
> language has multi-tasking built into it and the compiler generates task
> safe function calls without resorting to the runtime overhead of a dynamic
> stack and multi-tasking library.
>
> The LITE edition of XCSB if free for hobbyist / student use
> (non-commercial) and you can get it from:
>
>
http://www.xcprod.com/titan/XCSB
>
> The following might give you some ideas that you can either implement
> yourself (maybe with paper and pencil) or things to look out for in an
> automated dev tool:
>
>
http://www.xcprod.com/titan/ZMECH-DOC/generate/state-machine/block-indx.html
>
> Regards
> Sergio Masci
>