What does an embedded beginner need to know?

No surprise there.

At this point a serious design review should be held where all stakeholders are present. Yes, including the sales and marketing guys.

I have seen the results where design reviews were either not performed or done in a "let's quickly get it over with" fashion. "Now wait, we always assumed its bus could be connected to the xyz gizmo!" ... "Uhm, nobody told us that".

That's useful to point out. Active low is usually an unfamiliar concept to new embedded programmers.

Similarly, a brief introduction to reading a digital schematic will be very helpful. No matter how much the boss thinks that software people never have to look at schematics, these are often the best specifications. Ie, how to tell active low from active high, whether a line is pulled high or low, etc.

But don't let the software people know there is a reserve, or they'll assume they can use it freely.

Oh yeah, big agreement here. What is sad is that many beginners use sample code as exemplar code, and get bad habits early on. I'm of the theory that most of these companies give the job of writing examples to new hires fresh out of school, or even unpaid interns still in school, since I've seen some truly horrid code splashed proudly with the name of the Big Company.

However one shouldn't forget that the developer documentation is just one of many processes that are important for the achievement of the goals of the project. Documentation is not a goal in itself; neither it is a dogma. The infatuation for bureaucracy is very counter productive. The development of the sensible documentation requires talent and consumes a lot of effort; the dull documentation is worse then no documentation as it creates a mess and confusion.

I think it is very important to make the design suitable for debug, production testing and repair. Provide enough of test points, test signals and test modes in the software; so every I/O signal could be verified. Before developing a feature, think how you are going to test it and what hardware would be required to do that. Often those things are overlooked or added at the very last moment. The result is a lot of suffering at the design verification and later in production.

Vladimir Vassilevsky DSP and Mixed Signal Design Consultant

And especially with open drain outputs. Yesterday was a mad day

- I was working a small quick-and-dirty project and wanted it done in one day. You know what that entails - stripboard, DIP packages, PICs (for local availability) and mountains of wiring. All went swimmingly until I tried bringing up a test version of the software of the programmign baord - A Velleman K8048. One of the LEDs just wouldn't work. The software was obviously goign through the correct region of code but that LED still didn't light. I kind of assumed Velleman were competent at designing this kind of thing, but no, they attempted to drive an LED anode high from an open drain output...

A combination of both is a good idea. Here, we like to physically 'Measure the foundations' before 'The Plan' gets too large, and that means a usually small looping piece of code, that pushes the system. Twice recently, we found 'undocumented issues' that meant a major change in design plan in one case, and a slight recode in another.

Raised one with the IC vendor : "Oh yes, that's how we designed it" "Yes, you are right, that behavior detail is not reflected in the data sheet formula" "Really?, others don't have this issue ?"

-jg

Although, not much anymore these days. Most drivers are CMOS and the difference between Rdson of the upper and lower devices is quite small.

Active low has a major downside: If you have a row of LEDs at the front they or their series resistors must be connected to a supply plane. Someone slips with a tool ... bzzzt ... flash ... *PHHHOOMP*

Seen it happen more than once, and those supply planes can pack a punch.

An extreme example of this philosophy can be found in the computer games industry. Publishers always want to see stuff working ASAP. This forces you to start with a hacked-together demo which eventually grows into the final product.

As a programmer, this is infuriating. But any publisher who made a habit of accepting developers' promises at face value would have long since collapsed.

... snip ...

Somehow I suspect the obvious answer (0%) to be wrong. ;-) The message was a useful piece of advice to a beginner.

All interesting ideas to Mike's question ! But, in my experience, the answer is ...NOTHING ! Most of the beginners I've worked with already knew it all ;-)

See ya, Dave

I was actually being sarcastic there. My department has a new mandate to achieve CMMI level 3 compliance and there is an exponential growth in paperwork, most of which is being algorithmically generated by cheat scripts and doxygen, and then later algorithmically checked by macros. Sometimes I think the only actual coding that is happening is the arms race between automatic document generation and automatic traceability matrix checking.

Computer games is the essence of modern programming. A big bunch of low paid and interchangeable duffers working long hours on enthusiasm and for the promise of the wonderful future. Extreme labor fluidity. A project is just a huge pile of routine; nothing new or exquisite.

VLV

The figures from the working projects I had indicated planning 50% and testing 30% but then the testing was preceded with static analysis in the coding phase and the testing was automated.

However which ever way you look at it for successful projects you are looking at 30-50% planning, 30-50% testing and about 15% coding.

It might come as a surprise to programmers (if not Software Engineers) that coding is the smallest phase on *successful* projects.

Ouch :-))))

However you do make a VERY good point...

A while ago in this (or comp.lang.c) was a person who declared it was VERY easy to write fully portable C at all times and started pointing out mistakes "novices" made.... He knew what he was talking about and the rest of us were all wrong... It turned out he had written a few PC programs as a hobby and was doing PIC MCU's in his first year at collage. He had not worked on any other MCU but he "knew it all"

The best development method depends entirely on the project type and the customer - as with all things embedded, the answer is "it depends".

For your medical products, you have a clear specification, you can plan your design to that specification, and implement the product to that specification. That's essential for that sort of project, and if there is no clear specification, there will be no project and no product.

But not all embedded systems need the levels of documentation, security, auditability (is there such a word?) and quality control as something like medical equipment - and not all projects have the time and money for such a rigorous process.

The embedded world is huge, and there are vast numbers of customers who have only a vague idea of what they want the system to do - there is no way they can give you a concrete specification. You have to expect to go through a number of iterations, with first "prototypes" on paper, then using general-purpose cards, then prototype versions of a dedicated card, then final versions of the cards. At each stage, you are in dialogue with the customer and are writing and changing as you go along. Clearly you have to have a time and payment model to match - and yes, the customer will sometimes be paying you to do it over, rather than paying you do it right in the first place, because they didn't know what "right" was until first doing it "wrong".

You can, of course, call this whole prototyping and development stage "design and planning" and the final hardware and software the "implementation", if you want to shoe-horn it into an idealised development model. But you have a better chance of success (both for the developer and the customer) if you realise from the start that sometimes development is circular, not linear.

Both models, and everything in between, work for appropriate projects, customers and developers.

Part of the design document process is finding out how the tools and silicon work.

I worked on a project in the mid 80's that had a black board set aside for one liner words of wisdom. One that I remember on that board said,

"If you had time enough to do it over, how come you didn't have time enough to do it right?"

Regards,

-- Walter Banks Byte Craft Limited

d a

=A0I

nt

ngs

ime

of the

or

rst

Right, that's why I posted his numbers, to support your point.

Mike

I guess, if you consider >2:1 "quite small". It's down to SS physics-- the carrier mobility- a 2 or 3:1 difference between n-channel and p-channel devices.

Take for example, a PIC12F508 operating at 3.0V

Voh at 125°C is 1.5V at 4.5mA or so (3 sigma minimum)

Vol at 125°C is < 0.7V at 10mA (again, 3 sigma maximum)

The differences are not as great in HC devices (about 40% in the guaranteed values), probably because they use larger devices for the output p-channel, since it affects the rise time with a large fanout.

Anyway, most designers will automatically connect an LED+resistor load between Vdd and a CMOS output, and if external discrete drivers are required (eg. for muxing an array, the first ones to go discrete are the source drivers).

Though you can get some very nice p-channel discrete MOSFETs these days if you don't mind very low breakdown voltage.

No current limiting? 8-( Bad place to scrimp if it's a product that requires maintenance.

Best regards, Spehro Pefhany

The serious point here is really that the best training leads to

- understanding of exactly how much one does NOT know, and

- learning how to go about getting things done regardless

Hope that is useful Mike ! Best Regards, Dave

Agreed. A little knowledge is only a dangerous thing IF you do not know it is a little knowledge.

Blind enthusiasm gets people killed. though how one teaches students caution id a difficult question.