N. Coesel schrieb:
At 20:47 14-11-07 +0000, you wrote:
On 2007-11-14, N. Coesel <[email protected]> wrote:
I would like to issue a bit of warning here and ruin the party
a little :-) I've looked at protothreads myself and decided
not to use them. My main reason is that it will make the code
very hard to maintain because protothreads hide the way
various 'processes' are working together.
I don't see how. Can you provide an example?
Look at the protothreads examples and the defines that make up
protothreads.
I have. It's co-operative tasking with stack-unwinding on
context switches.
The whole idea is pretty nifty. But I think it is beyond the
grasp of a lof of programmers and therefore prone to errors
which are hard to debug.
It may be beyond the grasp of somebody who's never done
anything but Visual Basic macros for a spreadsheet, but
cooperative tasking and stack unwinding are pretty basic
concepts that I'd expect any competent software engineer to
understand.
And that is exactly where the problem is. Competence. Writing embedded
software usually involves an electrical engineer at some point. Electrical
engineers are often required to be a 'Jack of all trades, master at few'
more than anyone else so you'll need your code to be maintainable by people
that are not absolute experts on software as well.
heh. competence is relative ;-)
when the educated "software engineer" tries to write fancy code, ends
using up so much RAM that it compiles but gets stack overflows at
run-time and a developer not understanding why his own beautiful code
isn't working ;-)
lots of programmers never worked on real-time systems where a breakpoint
can kill hardware or at least invalidate any information they are
looking at.
and have you watched a pure software engineer using an oscilloscope? ;-)
chris
