The software development process.

Ok, I've had a chance to digest this (after my previous two responses), and yes, I agree.

To be real clear: it's not the GOTO, it's the spaghetti. Where program flow is unconstrained (the "how did I get here" problem), issues inevitably arise. Some classic ones: - Will this process ever terminate? - What state will the system be in when it does terminate? - What state will the system be in when it reaches a certain line?

Going back to you code chunk despatcher: good point, well made. I agree that the spaghettiness remains in your example. And yet: I use such despatchers all the time without reservation, and I had to take a step back to really see the essential difference. My code, and my program flow, is not spaghetti - the states, their transitions, and their effects are well-defined. The design is not jumping around all over the place.

There's one more subtle thing: your chunk despatcher was in a tight loop, exited when a certain condition existed. The "will this process ever terminate" problem could dominate - if it's a specific sequence with a definite start and end, fine. If the ending condition, and how to get there, is unclear, I get uncomfortable. Also, because of my tendency to use cooperative multitasking, I would tend to put the whole thing in a loop much higher up the hierarchy - e.g. one iteration of the chunk despatcher per round-robin call. While this doesn't guarantee that the state machine will ever reach a terminal state (a separate issue), it does ensure that the rest of the system stays working.

To go (to) back to the original issue: as I've said, GOTO's per se are not evil. It's open constructs that are evil.

Steve (still rushing about, and probably not as clear as I'd like)

You explicitly state what you can and can't do with defines, then you have code reviews to weed out the creative weirdos. I would be happy with (and may even write) a coding standard that calls out something like #defines can only express constants or pseudo-functions, and must fit on one line. Then when someone wants to have #defines with three open braces, for loops and case statements, that must be matched by other #defines with three close braces you can shoot them.

Hello Joel,

I've had OO do hardcore crashes when trying to open a Word doc. Not good. If Sun could strike a deal and market it right they could slowly gain a chunk of the pie. But they don't.

There are other reasons why companies often don't use open source SW: Liability. Although realistically the EULAs reduce that to cases of underwater carpet fires there is at least a company with lots of cash behind the product and you can make a case that you relied on them doing "the right engineering thing".

My impression is that while all kinds of meetings with ritzy dinners are held, platitudes are published and all that they are not interested in open design.

BTW, did you get your EE position up there filled?

Hi Joerg,

We're working on it. We've hired one retired fellow in a contract position to design an RF power amplifier -- he's a former tech. college professor with lots of consulting on the side, but very much likes his 5th wheel, and therefore wasn't interested in a full-time/office-bound position. We have an in-person interview with another fellow next week (did his phone interview three weeks back, but not everyone has been in the office lately) that looks like it'll turn out pretty well.

The interviews:hires ratio seems to be lower than 3 or 4:1, which seems to be pretty good in my experience.

---Joel

Hello Joel,

RF amps could be contracted out, doesn't always have to be on site until integration. But when it comes to DSP or other programming being on site has serious advantages. I can understand the love for his 5th wheel. Some day we might start doing that as well. Initially only a tiny one, a Casita or something like that. Right now our two large dogs are keeping us from that.

That is a good ratio. Then again people who are willing to move to your neck of the woods are certainly serious about it and must be down-to-earth people. In my experience most of those folks are good engineers.

A couple of years ago, I was going to enter one of the Circuit Cellar design contests. The MCU looked really interesting, so I worked out a flow char of what I wanted, and then started looking into the code.

First, I looked at some of the sample code. Couldn't make heads or tails of it! I could see that they were basically setting bits here and there, but didn't know what bits they were setting! So, started searching through the files on the various defined variables, and found out that the pile was about 4 layers, with the defines in the actual code mapped to definition in a layer of summaries, which mapped to a layer of ports, which mapped ot what was really a top level elegant definition of every single port and bit in the processor! Now, if they had just used those defines directly, it would have been simplicity itself to understand the code, but I guess they wanted to be able to 'move' a function from say TIMER A to TIMER B just by changing a mid-level define.

Finally, after about 3 weeks, I gave up on the software, and the contest!

Charlie

Hi Rich,

I agree, in probably 90+% of the cases I've seen, a proper function or a "const" variable could take the place of #define.

The primarily time they can't is when you are dealing with a C compiler and not a C++ one. (Although I believe "const" shows up in something like C99 that is widely ignored.)

---Joel

const is in ANSI C / ISO C / C89 so should be supported by pretty much everything.

The 'inline' function specifier is very nice for replacing macros. That is from C99.

Tim

I heard that the Burroughs machines never had an assembler, and that the first Algol compiler was written in Algol. It was hand-compiled by two guys who "executed" it by hand, as the first bootstrap.

John

Ahem. The industry *needed*, *wanted*, and *chose* a monopolist. They might have chosen better, and their choice should have acted better (more altruistically), but that's a hypothetical argument. People need to interchange documents and skills, and the open source movement must necessarily be *always* too late to become the dominant player in such games... for better or worse, mostly worse :-). It's simply less efficient, slower, and the results more problematic, to create standards that a community agrees to implement than it is for a self-interested party in a competitive situation to create a single solution to a given problem.

The only way of evening things out a little would be to legislate that every piece of data created and owned by a user of proprietry software must be in a format that's documented to the level that a third party could produce a program that performs the same functions with that data possible with the proprietry software. Call this the "principle of data transparency". In this respect, hackers actually perform a useful service to the community when they reverse-engineer data storage formats, for whatever nefarious purposes.

Clifford Heath.

My embedded systems never terminate; if they terminated, they's stop functioning, and that's equivalent to "it broke."

My software state machines resemble classic hardware state machines; they do sometimes execute blocks in stately progression, they sometimes execute the same block 219 times in succession, and they do sometimes jump around all over the place. But each block does something, has a maximum allowed execution time, and exits when it's done, usually within a millisecond and often a lot less.

And the dispatcher is usually within a periodic ISR, which does...

save stuff run stuff that's got to be done every time run a block of a state machine unsave stuff rti

and, of course, each state machine block can change which block will be run next pass through. Works like a cookoo clock. I time block executions with a scope and enter them in the source as comments.

John

If I haven't accidentally mixed up the attributions,

"They have been at a great feast of languages, and stolen the scraps."

-- Shakespeare, Love's Labour's Lost.

A 'const' qualifier in C89, C90, C99 does not define a constant. It specifies a read-only variable. Thus you cannot use const in the following sense:

const int x = 4; int a[x];

that requires a "#define x 4" statement.

In article , Steve at fivetrees wrote: [....]

Yes, this was another level of horror I built into the code with no GOTOs.

Often when I write an example of that method, I also shuffle the order of the statements just to make it extra unreadable. This would be a 3rd level of horror, just in case those reading it would otherwise keep lunch down.

I sometimes do multitasking with a context swapping method. I have a routine called something like "OtherTask" that pushes everything, swaps stacks, pops everything and returns. You can bobble back and forth between two tasks that look like linear programs that way.

You can even create your own fixed priority interrupt based multitasker without much work if you only need 2 or three tasks.

In article , John Larkin wrote: [....]

For some meanings of the word terminate quite a few embedded programs terminate. The basically restart from the beginning.

You can also do this: Modified code:

run a block of state machine B

If the two state machine blocks take very small amounts of time to do, this can make for code that is easier to work on if the number of states in the two machines are very different.

Yup. You can also give chain A priority, in the sense that "if an A block is runnable, execute it and exit; if not, run a B block." This is sort of a zen RTOS.

There's also the "rotary dispatcher." State-block list A might have, say, 12 entries that are executed in rotation. But one of those 12 blocks in turn does a rotary call to a second B list of blocks. The second-list blocks then get run at a much lower rate than the A-list ones. The A list may be scanning analogs, driving a VF display, protecting fets, whatever. B list may be checking pushbuttons, reading slow SPI temperature sensors, or managing startup/shutdown modes. I've done this 3 levels deep, 2 levels wide, all diagrammed on a D-size sheet of vellum.

You can also make a list of, say, 64 dispatch pointers...

BlockP BlockQ BlockP BlockR BlockP...

or something like that. The more often a block pointer appears in the list, the more compute time that operation gets. P gets run every other IRQ, but R might run only once every 64.

John

Nonono. I did say "the process", not "the program".

Steve

You can use an enumeration instead, can't you?

enum { x=1024, y=2048, z=129, /* other "constants" here */ };

int a[x]; int b[y]; int c[z];

etc.

A friend of mine used to use a "gotoavoidanceflag" in RTL/2. The purists didn't like that either.