Embedded programming usually solo?

In article , Mark Abbott writes

Any number between 1 and 200 on a project. Similar number for HW people. some embedded engineers can do both HW and SW so some projects are only

Many projects are for 1 SW person. However these tend to be the 8 bit systems where there is usually no OS.

You will also need to learn some new tools and test/debug techniques. depending on the target, an ICE, a JTAG debugger, simulators and possibly a logic analyser (this is usually the first tool a HW person goes for).

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\ /\/\/ snipped-for-privacy@phaedsys.org

Oscilloscope first.

Mike Harding

On 3 Jan 2004 14:40:12 -0800, snipped-for-privacy@acm.org (Mark Abbott) wrote in comp.arch.embedded:

Once upon a time, when I was young (was I ever young?), almost all embedded projects used 8 bit microcontrollers (and before there were microcontrollers, 8 bit microprocessors) with a few K bytes of ROM or EPROM for code storage and a few dozen or few hundred bytes of RAM.

In those days it was very common for the embedded program to be written (most likely entirely in assembly language) by a single person, as often as not the EE who designed the board, drew the schematics, and laid out the artwork.

Nowadays embedded projects range from those like the above to those using 32 and 64 bit processors (and DSPs) with megabytes of memory space and processor speeds up to the GHz range. There are embedded operating systems for these beasts that themselves occupy a megabyte or more of memory.

Projects like the latter type often have quite a few programmers working on them.

There is no such thing as a "typical" embedded project any more, and the range is far, far wider than desk top applications.

In my experience, about half of the embedded projects I've seen have been solo s/w projects. The rest involved 2-5 people.

Sure. But if you've never done embedded SW before, you don't want to try to solo right off the bat -- unless you alredy know how to use an oscilloscope, logic analyzer, and know how to debug hardware. Could you tell when two address lines are shorted together (either by looking at a memory dump or an oscilloscope trace)? If not, you'll need to work with somebody who does. One of tasks of an embedded SW engineer is to troubleshoot prototype circuit borads.

Quite possible. I have been involved in a number of successful projects where there was just one person responsible for creating the software. I chose those words carefully because in all these cases there has been someone else responsible for creating the electronics design anopther responsible for creating the mechanical design. The important thing is that the *whole team* is responsible for the correct function and performance of the product. In other words, no one man projects.

Ian

Hi Mark,

On small embedded devices (ie: 8 bitters with 4 KB of assembly code), it's often a one-guy's project.

But embedded design are usually more and more complex, with 32 bits MCU, realtime OS, network connectivity, GUI coded with C++, ... In my humble experience, it's often a job for a small team (2-6) in this case.

Note: It seems to be difficult to create a real developpment team with people who are used to work on solo project :

- bad communication ("I used to do it that way, everyone should know it !")

- bad documentation ("I AM the documentation")

- bad programming (bad prototyping and globals everywhere).

IMHO, Team-works is the way to go if you really want to learn a lot of things talking with other SW and/or HW guys.

Regards Emmanuel.

Mark Abbott wrote:

Tech-Tools makes a good setup. The way to learn is to have an assembler/programmer with source-level tracing. Write some code, then step thru it to see what it is doing.

I learned several micro's this way, and, long ago, C programming using the Borland integrated environment.

I can usually work with as little as a multi-meter, Forth and a simple logic probe. The scope is only required when things get a little more complicated. Usually by the time others have phoned the instrument hire company for the rental quote on a logic analyser (too expensive to own one to just sit on the shelf gathering dust) I have resolved the problem.

So his meter didn't have an "AC/DC" switch on it?

Scopes are great. I love using them. I don't always have that luxury and must sometimes get by with lesser tools.

Kelly

Errr... the AC voltage ranges on multi-meters will only read up to a few hundred hertz.

Mike Harding

Seconded in spades.

Ian

True.

The problem is that not all good technical people are good human people... The problem exists even though its only reason is over-valuation of own work.

Don't get mwe wrong. I am not saying that a solo project could not be a successful project. I have seen very high-quality solo work, and I have seen very low-quality team work. But the main point is that being a good solo programmer requires way more than being a good programmer in a team.

Right. What is the percentage of small projects which have a proper documentation -- with the thought process documented, as well -- of all projects. Very small.

This contact list idea is very good, but depends very much on the environment. And it is not so easy to create the network if you are a beginner.

So, I am not saying that team work would be better per se. It may be worse and is usally less efficient. But for a beginner, being a member of a team (even a loosely connected one) might help a lot.

- Ville

It's been my experience that the quality of documentation is more heavily related to the philosophy of the company itself, and not the size of the team. Companies which tend to follow a more rigorous set of guidelines tend to have better documentation. These are the companies which might still have a QC guy with a little round rubber stamp. He could/would prevent products from shipping if documentation was lacking.

Many (most) modern companies are so consumed with bottom-lines, that they just want to get products "out the door." Documentation can be a tedious and time consuming process, especially when the most talented engineers (with the best knowledge of the product) are generally not used as technical writers. They move on to other projects, so they can get more new products "out the door." IMHO, that is why documentation suffers.

Regards, Tom

I don't think so. I think the effort required to participate productively in a team is in fact more difficult, because it uses skills - communication, negotiation, other interpersonal skills - that the solo programmer may rarely need to use, and almost never as deeply.

I've been very lucky throughout my working life, because I've either been solo, or a team lead, or I've been working with people so highly skilled and/or with whom I have such a good relationship that arguments never become acrimonious.

If I had to pick the one thing I like most about being in a team, it is the psychological safety net that tells me if I make some egregious mistake, it will be picked up by someone else before it escapes into the real world. The contrast to this is what makes solo work fun; it's the feeling of being an intrepid explorer, and I think very closely related to the impulse that makes small boys so greatly enjoy crawling through a dense forest :)

I agree with you on that point to a certain extent. However, when the issue of getting paid to produce something is brought into the argument it should be clear that you need to learn to encourage the other guy to build a case for his viewpoint as you build a case for yours. After presenting yoursupporting cases in turn it should become clear which way to go (even if it was a third way suggested out of answering the identified problems. If there really is totally opposing views you may need an arbirtrator.

Yes, probably an order of magnitude more self discipline.

In the whole universe of programming perhaps. In high integrity systems development, probably a significant roportion because it is demanded.

True. However, netorking is a skill that needs to be developed and I cannot imagine that college or university environments would not present plenty of opportunities for it. Some of my networking contacts go back over twenty years ago and I am still in touch with them.

Agreed.

Interesting comment. However surely a solo programmer needs these same skills when dealing with whoever is paying him to do the work. IMHO *all* engineers need to posses good communication, negaotiation and interpersonal skills.

Ian

Emmm... yes... maybe... :) Engineers are not noted for their communications and people skills.

Joke: How can you you tell when you're talking to a extrovert engineer?

When he replies he looks at your shoes rather than his own.

Mike Harding

Whilst it is certainly true that *some* engineers are not noted for the comms/people skills, it is by no means universal. I worked for twenty years in large technology consultancies and there it was a definite prerequisite that engineers as a minimum showed the ability to acquire these skills. They received as much training in this area and other non technical skills like project mamagement as they did in technical topics.

My personal view is this made them better engineers because they were able to:

a). Persuade non technical people (clients and possibly management) to their viewpoint

b). Present their ideas in a clear manner

c) Understand the point of view of others and take it into account.

I am sure they enjoyed their work more as a result.

Ian

It is extremely difficult to describe anyone else's thought processes. When I look at a schematic diagram or a piece of program created by someone else (or me years earlier), there are always strange things I do not understand. Why was that done that way when a much simpler way exists? Quite often there is a good answer, because of this and that. This small piece of information may turn out to be very important in case there are problems later on.

So, the documentation has to be written by the same people who have gone through the thought process. Preferably during or immediately after the thinking.

- Ville