Software Reuse In Embedded code

I don't agree, there. I.e., many libraries are just "lots of mundane code". Nothing earth-shattering or terribly novel. Toughest libraries I've seen are those that try to do FP math

*accurately* (i.e., at the fractional ulp level). There, you're better off *buying* than rolling (those sorts of details make my head hurt) +42

There's a lot that can be done to give *added* structure to stuff that would otherwise *look* like a rats nest. E.g., most UI's are total crap to code in any way *other* than as an FSM.

Not only does this tend to simplify and "robustify" ("You heard it here, first, folks!" :> ) the code, but it makes it a no-brainer to tweak the code at a later date -- just by documenting those data structures (instead of trying to document a ratsnest of spaghetti code)

Exactly. You want to be able to look at something "quickly" (bad choice of word) and see where your *obvious* mistake is without sorting through pages of code wondering which *conditional* is "off by one" (">" should have been ">=", etc.). By imposing structure on it, you force mistakes in the "engine" to be more noticeable -- because they affect *lots* of execution paths instead of just one *rare* path.

I'll give you each "partial blame" on that score. You

*could* have looked around to see what the current *state* of the input queue was -- instead of just assuming "there's a message there" (apologies if I am assuming too much, here, based on what little you've said)

I've learned that programming defensively when it comes to dealing with the actual iron pays off in spades! E.g., just because there was an interrupt doesn't mean there

*should* have been an interrupt! (so, expecting things to *be* indicating an interrupt can bite you)

The best advice when it comes to low level drivers is to use the vendor supplied code as examples of what the code

*might* want to do. To, hopefully, clarify something that is vague in the datasheet.

Like (hardware) app notes, treating them as gospel leads to pain.

That's absolutely true (case in point - when MS took the TCP/IP stack from FreeBSD for use in Windows, they could do so freely and legally and gave nothing back but a small copyright notice in a file that no one noticed).

Another example is FreeRTOS - it is licensed under a modified GPL that anyone can use under certain restrictions (such as giving your customers the source code to any changes you made). Or you can buy a license for the same code with different terms. The FreeRTOS developers and users get the best of both worlds. But if FreeRTOS had been under a BSD license, the authors would have got very little out of it.

What is missing here is that you can negotiate with an author about a separate contract. I would gladly sign a one thousand dollar contract allowing Microsoft to make millions. (Non-exclusive, non-transferable, but no obligation to publish source based on my GPL-ed code.) The BSD author would got nada.

Groetjes Albert

--

--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

I am arguing for a software IP commercial protection scheme of some sort to deal with real software breakthroughs. Originally manufacturers paid royalties to the patent holder as part of the business plan to among other things protect their manufacturing business investment. There is no similar parallel in software.

It might also be interesting to find out how many cases of software patent abuses readers of this news group have first hand experience. I have been around intellectual property for most of my adult life and have had personal experience with a single example 20+ years ago.

Regards,

w..

-- Walter Banks Byte Craft Limited

s

Ok, let me ask the opposite question, since I can't evaluate yours or anyone elses claims, how many resell their software, where the customer reuses it as-is in a wide variety of unrelated products. That surely is an more objective measure of code reuseability.

You said that the head honcho of well-known embedded RTOS supplier had terrible coding guidelines, but they must be selling lots of code to someone repeatedly to be well known so how do you resolve that apparent conflict? Maybe marketing. But the only reasonable answer is his coding guidelines are different, not better or worse then yours. I don't know if he was against table driven code or pro globals but certainly their are situations where higher levels of code abstraction aren't necessarily the best solution and trying to shoe horn those concepts into a product may result is an inferior product that has limited uses (due to performance, say).

I don't see a difference between library and product.

"If you want to encourage innovation..."

If *others* didn't encumber their code with this sort of cruft, *your* job would be easier. You would produce better products, for less investment cost and in less time.

Likewise, others would benefit from you unencumbering your code!

Unfortunately, *you* (speaking metaphorically) don't want to do this with *your* IP -- until others have done it with *theirs*. So, everyone hides their hole cards and everyone pays more to develop products and takes longer to do so and there is less innovation and ...

People are afraid of open source. They don't see what's in it for them. They just see what it might *cost* them. It's a change. People don't like change.

People also tend to have unrealistic expectations! I had a client insist that everything I did for him *only* benefit him. I told him that made perfect sense to me. But, that I would have to *do* everything for him "from scratch", clean-room style -- since I couldn't ethically put work done for previous clients at risk if he opted to go after them for work that "strongly resembled" stuff I was going to do for him (because *he* inherited from them!).

In practical terms, this meant he would have to pay a lot more for his product development. Just for the (selfish?) want of being able to say, "Mine! Mine! ALL Mine!!". Amazing how quickly people rethink their positions when there is a price tag associated with it! ;-)

I've gone looking for sources for GPL'd products many times. If the company has gone belly-up or bought out, good luck! So, they benefitted (even if only for the duration of their short-lived existence) from the terms of the license -- yet no one else gets to build on their efforts.

[linksys is pretty good about making sources available. IIRC, there's a page that lists the sources for each such product they've offered. I wonder if the sources will "disappear" 3 years after the products? Or, will the company figure the cost of the page is nothing in the long run]

Depends on the desires of the author. It's *my* belief that unencumbering code encourages reuse far more than the GPL ever will. The more code gets reused, the higher the bar gets raised. I.e., GPL'd code now has to compete with

*truly* "free" code -- "Why should I use your GPL'd code and have to conform to its more restrictive license when this *other* code does all the same -- and more -- and is *free*?"

I'm not addressing license violations. With existing law, there's nothing you can do about that.

OTOH, if everyone could just as easily compete with that violator, it puts pressure on the violator to truly innovate to stay ahead of everyone else that could "freely" use that code.

That's a problem with the current law and practices.

Folks know what risks they face when publishing, producing and/or licensing software. If you don't want to face those risks, then don't play in that profession!

I have little sympathy for a *policeman* complaining that people are *shooting* at him! ;-)

Exactly. And, since there *are* other options, my point of the value of something like the GPL *diminishing* as more alternatives are available becomes more significant. There's very little that's GPL'd that doesn't also have a "free" alternative available. Why would I -- as a businessman -- want to needlessly encumber my work when I don't have to?

Amusingly, the only first-hand experience I have of IP theft is direct copyright infringement. I.e., manufacturer B

*literally* copying the code in manufacturer A's product, making *superficial* changes and then passing it off as his own.

This was commonplace in the gaming field in the 80's. It was *so* common that the (software) mechanisms built into the games to detect and/or thwart this practice were informally referred to as "Jap-zappers" (because most of the counterfeit machines were coming from Japan).

At least some of the "Easter Eggs" in games of this vintage were trade secret, designed to be resistant to tampering and intended to unambiguously identify the original author in future litigation ("Mr. Defendant, could you please explain to the court why *your* game displays the *Plaintiff's* name on the screen when I push this magical series of buttons?")

Not exactly. You're absolutely correct that many contributors would need to OK putting a distribution under new license, and the effort to do that is considerable ... but Torvalds himself maintains exclusive control over licensing of the kernel. He has written extensively about his dislike for GPL v3 and why he felt the kernel could not be subjected to it - much of which has to do with the increasing use of Linux in embedded systems.

George

At a previous employer, a large project was ported from Linux to NetBSD because of similar concerns. Or may be, I should say "it was ported from a GPL license to an MIT license."

-- Roberto Waltman

[ Please reply to the group. Return address is invalid ]

Actually you can blame Mickey Mouse. It was a dispute over Walt Disney's copyrights that led to the current "life + 99 years" law which automatically transfers the holder's rights to his/her estate after death.

George

Ah. Current state of input queue wasn't available to me as such. The code example was very complex. I made the mistake of assuming it worked, since it was published by the silicon supplier - I'll certainly take the blame for *that* error.

(To be real clear, the bug in the "driver" code was down to a Boolean which said "there's a message", when it should have been a counter saying "there are N messages".)

Oooh, bigtime (re defensive coding). I've been known to code defensively against errors that simply can't happen *now* on the basis that things change and maybe this could happen *later*.

Again, absolutely. For relatively manageable drivers, I'll always roll my own (and wind up with far more defensive code than the example). In this case, it was huge, and we didn't have time...

Steve

--
http://www.fivetrees.com

Glad to hear NBSD "getting that business". I like the NBSD folks because they are low key, don't waste a lot of time beating their chests about their product -- but just trudge along improving it.

Exactly. I see Linux as being available on a wider range of things I might want to *play* with, but nothing that would force/encourage me to adopt it (over something "free-r") for a real product.

IMO, these free-r options will eventually put the same pressures on more "encumbered" products that those products put on the "commercial" products.

But, the BSD author wasn't *expecting* (or asking for) anything. So, he doesn't feel "disappointed". Presumably, he made a conscious decision *not* to hide or otherwise "protect" his product -- for whatever reason -- and, seeing it used elsewhere is exactly his goal!

I resolve the conflict by noting that the said head honcho is unlikely to be doing much coding these days ;).

Re different coding guidelines: give me just a *bit* of credit for knowing the difference between e.g. use of a tab character and e.g. use of a goto. (Different style I can live with; dangerous practices I can't.) And yes, his guidelines were dangerous (obviously IMO).

As for the implication that "higher levels of code abstraction" affect performance: I'll grant you that there are a myriad ways in which you can be too clever for your own good, and wind up with something that is abstracted across too many layers and performs poorly. But, for me, that's just another example of poor code. I wouldn't defend that on the basis of coding guidelines or any other criterion.

However, part of the art of coding is knowing the difference. For instance, the goto: I've seen it defended (many times) on the basis of either performance, or error-handling, or any one of many other things. To me, this is all nonsense. I've *never, *ever** come across a case in which a goto can't be eliminated by a proper understanding of code flow, or use of a state machine. (I used to do a lot of legacy code maintenance, so this came up a lot.)

Similarly, I've seen a lot of code that is absolutely *infested* with if/then/elses, where my background in hardware (Karnaugh maps, De Morgan's theorem) has allowed me to simplify it to a few logical cases. I always find it shocking that such basic things (e.g. logic rules) are not known to the coders...

Steve

--
http://www.fivetrees.com

OK. I was assuming you accessed the current message through a FIFO's pointers, etc. (i.e., could do the pointer arithmetic to see how much was "available"). 'Nuff said -- *you* saw the code, not I! :>

As an aside: I have a philosophical issue regarding duplicating data. I.e., I like having one representation of a datum ("state") wherever possible instead of two (or more) which could potentially get out of sync (similar to your problem). It seems to lead to more robust code -- every "consumer" uses the same "copy" of the datum and in the same *way*.

E.g., if you store a "string length" with a string (like "counted strings" in Pascal(?)) but also have another means by which length can be deduced (like ASCIZ strings in C) then you run the risk of one piece of code using the count and another counting them explicitly (strlen()). Fine - until someone forgets to update one or the other (at which time, things fail in irrational ways).

Yup. I looked at a design for a camera circuit some time ago. The components used suggested a different resolution than was

*claimed*. Turned out the design had been lifted from an app note and contained that error!

Ooops!

This can actually be *really* hard to do! I faced the same problem recently when trying to code a test suite for a memory management suite. The code could detect things that simply "*couldn't* happen". Period. (i.e., you'd need to blame alpha particles for these sorts of errors) The problem I faced was trying to *fabricate* test cases that I could throw against the code to verify that the code was well-behaved in those situations!

Some environments provide tools to help you stress your code (e.g., starving the free memory pool, etc.). Jaluna included some things to help you harden your drivers.

I think this goes to the issue of the thread's title. "Author X" prepares a particular code fragment/suite that fits *his* (actual and/or envisioned) needs. "Consumer Y" assumes (hopes?) said code will address *his* needs as well. But, somewhere in between, an assumption falls apart...

And, of course, "Consumer Y" is left holding the proverbial bag!

A good description of the causes of the Ariane 501 disaster. In a nutshell.

Or, digging the pieces of his expensive rocket and satellites out of a tropical swamp to try to understand why it didn't work.

--
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

(sigh) I have to defend the value of the (rare) goto. (Recalling largely from memory and expressing as pseudo-C) my variable precision decimal math package does it's "from_string" conversion something like:

do { if (compare(ptr, "nan") == TRUE) { ptr += strlen("nan") if (*ptr != '\0') return ERROR /* nothing else accompanies */ /* have a NaN, act accordingly */ break }

/* !"NaN" */ if (*ptr == '-') { sign = -1 ptr++ } else if (*ptr == '+') { sign = +1 ptr++ }

/* so far: ? */ if (compare(ptr, "infinity")) { /* have: ?, act accordingly */ if (*ptr != '\0') return ERROR /* nothing else accompanies */ break }

/* so far: ? but not Infinity. *Must* be mumeric */ while (*ptr == '0') { /* note leading zeroes */ ptr++ }

/* so far: ?0* next must be part of number */ while (isdigit(*ptr)) { /* accumulate digits left of DP */ ptr++ }

/* so far: ?0*([1-9][0-9]*)? next must be DP or exp */ if (*ptr == '.') { /* note position of DP */ ptr++ while (isdigit(*ptr)) { /* accumulate digits right of DP */ ptr++ } }

/* so far: ?0*([1-9][0-9]*)?(.[0-9]*) next must be exp */ if ((*ptr == 'e') || (*ptr == 'E')) { ptr++ while (isdigit(ptr)) { /* accumulate exponent */ ptr++ } }

if (*ptr != '\0') { return ERROR

} while (ONCE); /* hack -- skips a break */

win: /* have a valid string and all the parameters needed to convert * it to internal representation */

[apologies if I've made some horrendous screwup -- I'm rushing to finish before my custard cools...]

The actual code is much longer (in terms of amount of paper used, not much more in terms of *complexity* -- but there are lots of pointers to track so you can figure out how many significant digits were present int he input, where the DP was located, etc.

The point here is that there are several places where "goto win" would have cleaned up the code. The do-while hack runs the risk of not being familiar to novices (and, also gives trouble if you want to "break break" -- requiring a flag and some kludge logic). And, the do-while cheats me out of three characters per line (because it introduces another indent level)

[actually, I think I wrote this inside out -- breaking for errors instead of "wins". dunno. Same argument applies]

I find I have to leave notes for folks explaining odd choices of conditionals. E.g., if (! ((*ptr != 'e') && (*ptr != 'E')) ) { though that would be a bad choice, here.

I think use of finite automata, logic reduction, *state* reduction ("implication tables") tend to be more hardware taught skills than software. I.e., I was exposed to all of them in my *hardware* classes, not in software. If you think about it, why are so many programmers puzzled by races and hazzards? ("Hmmm... how'd *that* happen?") The apparent aversion to pointers? etc.

I think hardware mindsets also come up with different (not necessarily *better*) ways of partitioning things.

I use goto whenever it results in clearer and more readable code. Using "goto error" in a function that ends like this:

error: cleanup_stuff(); return retval; }

is easy to understand. The 'error' label makes it clear what the purpose is, even without reading any further, and it helps to keep the mainline code free of error handling. It may be possible to rewrite the code to avoid the 'goto', but if that doesn't result in any tangible benefits, why bother ?

The extra indentation shouldn't be a problem, though. If you need more than 3-4 levels of indentation, you should probably restructure the code and/or use some extra functions anyway.

I never worry about simplifying the logic, unless it helps readability.

It's true that Linus Torvalds prefers the GPLv2 to GPLv3 for Linux (I fully agree with him here), and one of the many reasons is that the GPLv3 would make it more difficult to use Linux in embedded systems.

Your other claim that "Torvalds himself maintains exclusive control over licensing of the kernel" is quite simply incorrect. With Linux, every contributor retains the copyrights to their contribution (unlike some other projects, like gcc or Open Office), and thus the individuals retain the right to control the licence used. The licence for a file in the Linux source code cannot be changed without the consent of all the copyright owners for all the parts of that file - and I'd be surprised if there are more than a handful of files in Linux that have only one contributor. Torvalds is probably still the single largest individual contributor, at least in the deep kernel itself, but he has far from any exclusive rights there. It's probably been a decade since he made the top ten code contributors list for any Linux releases.