Do I need a RTOS?

I was clearly too brief ;).

Somewhat less briefly: there needs to be a clear distinction between the hardware resources owned by the top level, and those owned by interrupts. Reasonably often a single port has pins that are serviced by interrupts, and others that are not. In such cases one has to be sure that an interrupt doesn't come along and change the state of the port (or its DDR) while the top level is doing something with it, hence my reference to read-modify-writes being atomic. Again, reasonably often one needs to maintain a copy of the state of the entire port in software - the same cautions apply.

As a general rule, unless the hardware support is time-critical (as is the case with serial comms or SPI), it's better to set a flag in software under interrupt control and allow the top level to maintain the hardware. YMMV.

Steve

--

formatting link

Reply to
Steve at fivetrees
Loading thread data ...

Oooh, what an interesting statement.

Me, I love state machines. I'd much rather have a hierarchy of state machines than an RTOS. Hell, for even a non-timing-critical sequential system within an alien non-RT OS, I'd still use a state machine. The reason is perhaps less to do with latency than elegance: I find a task described entirely sequentially (with sleep()s etc) tends to have a lot of duplication of error handling - a thread from earlier this year here, where a couple of the people whose opinions I would otherwise respect took time to defend the dreaded goto on this basis, illustrated my point rather well ;). (And no, try/catch doesn't cut it either. Slightly better than the goto, but still a nappy layer.)

YMMV, and I'd be interested to hear it.

Steve

--

formatting link

Reply to
Steve at fivetrees

Bravo, I say, bravo . Good show, old chap.

Seriously - apart from my comment about state machines as a better mousetrap - you nailed it, dude. Absolutely my point of view too. Thanks for saving me all that typing :).

Steve

--

formatting link

Reply to
Steve at fivetrees

Fascinating. That state machine must have really sucked.

I've had the opposite experience, but possibly that's because the state machines were designed by me, and I'm quite good/experienced/old ;). My main aim in such cases is to make things so clear they can't possibly be either wrong or misunderstood. It's actually not all that hard.

However, re code downloaded from the net, I have to agree there - the majority of 3rd-party state-machine implementations I've seen really do suck. That doesn't mean the basic concept is flawed, though. It just means people think sequentially, and have trouble thinking synchronously. Unless of course you're a hardware designer, in which case such things come naturally ;).

There is some truth in this, but not 5:1. Given Moore's Law, I'm happy to sacrifice some efficiency for robustness and clarity. But probably not 5:1. More like 1.5:1.

I call this argument the sock argument - is the sock inside-in or inside-out? You can have time-based or task-based paradigms - some are good, some are bad. But thinking entirely sequentially, with no eye to cooperation, tends to result in sucky code either way.

Steve

--

formatting link

Reply to
Steve at fivetrees

I'd rather bear with the preemptive multitasking overhead then do a cascade of the state machines.

In a state machine, the responsiveness is determined by the state with the longest execution time. Suppose you have a math task which takes a long time to calculate (~1 second). Okay, this task can be broken in a sequence of the small states and the tons of the state variables, which is going to be messy and difficult to maintain. Nevertheless you can't split a library function such as sin() or log() into a sequence of states. Neither you can split a function like fread(), so if there is a file system related delay, then everything is stalled.

Vladimir Vassilevsky

DSP and Mixed Signal Design Consultant

formatting link

Reply to
Vladimir Vassilevsky

Ok, noted. (Although "cascade" for me seems scarily chaotic compared to "hierarchy" ;).)

All good points, well made.

I'd counter only with:

- Yes, I've occasionally had to split a lengthy (time-wise, not action-wise) process into substates. Not too often, but yes, at such times pre-emption seems attractive ;).

- You absolutely have a point re e.g. fread() - assuming you're using a classic function call provided by an OS, in which case all bets are off. If you're writing your own under a cooperative multitasker, you'd probably split it into states anyway ;).

Thanks for response - fascinating discussion.

Steve

--

formatting link

Reply to
Steve at fivetrees

Thanks, Steve. But of course, over time here I've learned that you and I think far too much alike!! I'm still wondering if we disagree on anything. I can only imagine what it would be like working on a project, together. (A real joy, I'm sure.)

Yes, I happen to appreciate state machines, too. I wrote here, "I can provide specific cases that would argue well that a state machine is clearer, maintainable, and far less prone to programming mistakes." And that is not just words, but fact. There are times when I'll head towards a state machine well before I will examine any other option because of how consistently well they work and the ease in writing them to cope with myriad complex logical possibilities with robust, bullet-proof perfection. Some places, they are nearly indispensable.

Jon

Reply to
Jon Kirwan

Consider me suitably flattered ;).

Once again, well said.

Steve

--

formatting link

Reply to
Steve at fivetrees

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.