What does an embedded beginner need to know?

ttp://

in handy when

Good comments are necessary, but not sufficient. Doxygen is a nice way of presenting comments without the accompanying code. But the hard part of a good project is the design, which precedes most or all of the implementation.

Details, details, details

Embedded is a special kind of programming done by special people who can't wait for morning to continue their profession.

It is the rush that you get looking at the final product and saying there is a little bit of me in there.

It just never goes away.

Several others have dealt with the technical details. I add my vote for design planning should be done before the code is written.

Regards,

-- Walter Banks Byte Craft Limited

Extractor-style "documentation" never impressed me much, and that includes Doxygen. IMHO there needs to be a lot more prose around and not just glossary-type listings. In our case the rules are pretty simple, an inspector from the FDA who is not an embedded system specialist must be able to understand the stuff. If he doesn't then the FDA ain't gonna be happy. And if the FDA ain't happy, nobody's gonna be happy :-)

--
Regards, Joerg

http://www.analogconsultants.com/

"gmail" domain blocked because of excessive spam.
Use another domain or send PM.

It's extremely useful when you have an ISO requirement "code must include documentation" and are too lazy to actually do things like sitting down before you open the compiler, and deciding on paper what the product shall actually do (in detail).

It's also handy as a browseable reference of enums, data structures, etc. and for tracking TODOs.

I agree.

There needs to be three documents first a design document that spells out objectives approach and system functionality with subsections on implementation approaches and design.

A user document that describes what the user sees, expects and does..

Finally the implementation hardware design and source code.

Regards,

-- Walter Banks Byte Craft Limited

Yep and yep. No disagreement at all. First write down -- using full sentences and correct grammar -- what it's supposed to do, what it

*does* do, and why, and how.

With some more reflection, doxy is probably too particularized for an intro course. It is useful a year later, though, when the "The customer wants us to add this new interface." Sort of like ctags on steroids...

--
Rich Webb     Norfolk, VA

Doxygen is good for source-code documentation - it lets you write more elaborate and structured documentation than plain comments, and it's tied tightly to the code in question.

But that's only for source code documentation - it is not appropriate for other documentation.

A project needs a good specification at the start - say what the program is supposed to do. Getting that right is half the work - once you have a good specification, the rest is just implementation coding (and a bit of testing...). If your specification is not good, then your code will be wrong even if it's perfect.

Of course, there's the old saying about specifications - programming from specification is like walking on water - it's easy when its frozen.

Agencies such as FDA or FAA won't likely give a hoot about whether it's ISO compliant enough. They want the docs to be per their standards and expectations or the result of an audit will be a closed door pep talk in the CEO's office ;-)

Yes, for that it's probably quite useful. But not as ECO-ready documentation. At least I would not sign off on it.

--
Regards, Joerg

http://www.analogconsultants.com/

"gmail" domain blocked because of excessive spam.
Use another domain or send PM.

Ideally the documentation relating to implementation should be written concurrently. That's what I do when designing anything, always. There will be all the CAD windows and in parallel a fat and growing MS-Word file set, either on the same PC or a laptop next to it.

I've seen it too often where the final docs are done in hindsight, at the point when people are already stressed because of late-in-the-game issues that came up, or just because they'd rather move on to the next interesting project. So the stuff gets slapped together as fast as possible, to be "done with it". This leads to poor final documentation. The other reason why I do it concurrently is that I could be hit by a truck tomorrow and my clients still need to be able to get on with the project, without having to reverse engineer my designs.

--
Regards, Joerg

http://www.analogconsultants.com/

"gmail" domain blocked because of excessive spam.
Use another domain or send PM.

We all have the same scars different truck. The amazing thing is doing it "right" results in a better product sooner. Being beat up because no code is being typed will extent the project.

Three or four years ago I wrote a code generator for a particularly nasty processor. I spent 3 1/2 months on the design document and a full day writing the code. The total changes to the code since "1" satisfaction doing it right "priceless"

Regards,

-- Walter Banks Byte Craft Limited

Yep, that's how it's supposed to be.

This almost drove the guys crazy at the Institute for Measurement Technology and Aachen University (Germany): Me starting my masters project, a complete CCD camera from scratch. Some folks said it's way to complicated for one guy. Oh, and they also needed a VME data acqusition for it so I told them I'd build one if someone brings a crate of beer. They did, and said that this other project relies on my stuff being ready before the big SPIE conference. "Ok", I said. 3 months down the road, no hardware. 4 months, still nothing but almost a book worth of documentation. And so on. Then the professor had a concerned chat with me. Told him that the plans were just about done and the camera would be ready for use in four weeks. "Plan. Hmm ..." He left, shaking his head. Three weeks later it all worked.

--
Regards, Joerg

http://www.analogconsultants.com/

"gmail" domain blocked because of excessive spam.
Use another domain or send PM.

If you were an unknown quantity to your professor at the time, then he acted very appropriately. After all, at that point your behavior was externally indistinguishable from someone who only knew how to plan and had no clue about the actual implementation work.

As an aside, I'm not all that convinced about the benefits of a strict think-plan-do waterfall model of development. It is fine if you are doing a run-of-the-mill application with tools you are familiar with. But in the face of ambiguity or uncertainty, a more iterative model might be more appropriate.

--
Pertti

It's very refreshing to hear lessons "from the trenches" about our field. Great topic!

Vladimir Vassilevsky escribió:

[...]

Wow. Just like sea lions are not lions?

One of my favorite phrases: Self documenting code isn't.

Ed

In message , Walter Banks writes

In a presentation I do called: Debugging is difficult. So why do it? There are two slides of relevance here.

1 a pie chart of project failures in 61508 projects. Over 60% of the failures are due to [incorrect] specification. 2 A combined project time line of all the successful projects at a major comms company. IT turned out for all the successful projects the first 50-50% of the elapsed time was spend on specifications and design. Only 15% on code and (code) test. There were additional integration and systems test phases.

In both cases they had good systems.

So

1 work out what you want to build (requirements) 2 how it should be built (Specification ) 3 Detailed design (design) 4 build to design. 5 Test according to design specification. 6 Test system according to system spec 7 Test with customer against requirements.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Well, there was quite an extensive schematic at that time, along with explanations about how stuff worked and why certain architectural choices were made.

This was most certainly no run-of-the-mill project. It beat the CCD cameras of those days hands down. The array manufacturer (they also made their own cameras with it) came visit and the CCD division executive offered me a job on the spot. I could have started there the millisecond the university handed me my degree but it was a large company and I wasn't cut out for work in a large corporation. Went to a smaller business instead.

I use this approach all the time and I work at the cutting edge of medical and other markets. In fact, agencies almost mandate this approach. Upon audits one of the first things they request is the design history and if he asks you better be able to place that in front of the officer within minutes.

--
Regards, Joerg

http://www.analogconsultants.com/

"gmail" domain blocked because of excessive spam.
Use another domain or send PM.

Further down in the "regular" specs, there are usually minumum, typical and maximum columns for things like current consumption (and that one for microcontrollers often has half a dozen or more figures, depending on run/wait/stop modes and what on-chip clocks and peripherals are powered up). Ignore the typical column, and use only the worst case number from the other two columns.

One of the first things that comes to mind is "magic memory locations" in memory-mapped I/O or even with separate I/O addressing (where there may STILL be memory mapped I/O) that unlike RAM, what you read from a hardware location may have no connection (it may do an entirely different function from) what you write to that location. I've heard of people getting confused over this, and having a hard time not thinking something like "Oh, that must be a bad memory location in RAM." Going into more detail here, this is even true of bits in a word, some may be read/write, but others may be read-only status bits (that get cleared by hardware just after the read!) and writes to those bits may be don't-care, or specified as "always write zero here." There's hardware addresses on desktop systems that work like that (or even ram locations such as the keyboard key buffer, filled in by a keyboard interrupt routine and read out by a function called from the application), but desktop developers often never see such low-level details. I recall the serial chip in the original Macintosh, I forget the part number, but you had to write TWO consecutive words to it to write to a register, and to read a register you had to write a word, then read the register. That was fun, I hadn't used a chip like that one before, but since then there was a Dallas chip with a one-wire interface.

More stuff hinges on the size of the target systems. I suspect there's a lot of mixed knowledge and assumptions among embedded developers depending on the targets they're used to. 32 bit processors running some Unix thing will likely have all the bells and whistles of the average desktop machine available, and the assumptions of such developers will be similar to "mainstream" desktop developers. Smaller systems running on 8-bit or 16-bit processors may not have things "desktop developers" take for granted, such as scanf, printf, dynamic memory allocation and floating point operations, virtually unlimited program and data memory, and where things such as floating point they ARE available, they may end up taking half or more of the program and RAM space, and run at 1/100th the speed of integer (or fixed-point, something else you may need to explain) operations.

Of course, now you can get a 32 bit processor powered off a rechargable cell and running a conference badge, like this one:

so things aren't dividable between 8/16/32 bit systems as being necessarily different. I suppose you could implement a printf for putting up a message on the LED matrix display, but I'm sure a usable enough function comes with the board.

A better dividing line might be "has OS" vs. "no OS" but I've also seen discussions here of "What constitutes an OS?"

"Embedded" cover a huge and growing number of products. Years ago I saw someone working on an ATM in a supermarket, it was all opened up with a display showing system stuff. I felt a tightness in my chest when I recognized it as some version of Microsoft Windows.