microcontroller programming -- how to begin

You mean tried and true, well proven don't you. Just because something has been around for a while doesn't lower its value.

A free macro assembler is very far from "of limited value".

"actively developed" is a very strange turn of phrase. Do you mean that they are still working on it (ie: trying to remove the bugs)

In article , Pooh Bear wrote: [....]

In a lot of cases they aren't. It is really hard automatically do variable lives when there are interrups involved, or if you have jump tables.

I already know the 8051, I've got good tools for it and I have a huge library of existing routines for it. I can go from quite low cost up to darn fast all with the same code.

Ken Smith schrieb:

I mean abandoned.

A free macro assembler is no big deal, you can get one for any microcontroller family in the world. It's different when it comes to C compilers. For 8051 there is only SDCC, but it's not as good as the free compilers you can get for AVR, MSP430, Z8 or ARM. I have yet to see a free IDE for source level simulation/debugging of SDCC code.

What kind of free software is available for 8051 that isn't for AVR?

I should have written "actively maintained".

Being sceptical of open source because of bad experiences with OpenOffice is about as smart as being sceptical of eating because of a bad prawn.

The msp430 gcc port is solid stuff. I've used in on a number of projects - it's my clear favourite small micro. The debugger (gdb) works fine (although you may want a graphics front-end if you don't like just using the command line debugger), and works with the parallel port debuggers ($10 from Olimex) and USB debuggers (a fair bit more expensive, but again cheapest from Olimex). The key developers are regulars on the mailing list, which is helpful and friendly.

It's both - "actively maintained" ensures that any bugs that are found get fixed, even in older versions (although not too far back, unless you have a particularly good reason). "Actively developed", in that new features are added regularly. In particular, the library is frequently improved, support for new devices is added as they come out, development follows the mainline gcc so that front-end improvements benefit avrgcc as well as more common gcc ports, and support for other languages (c++ and even ada) is gradually improving.

"N" is 32 on the AVR, and 1 on the PIC. Not much difference there, really.

In the same way, the PIC is really quite close to an Intel '486, and a Sinclair C5 is just like a Ferrari, bar a few minor details.

Like Windows, the x86 architecture, or C, the main reason the 8051 is popular is because it is popular, not because it is good in itself. That might be an appropriate reason for choosing it, of course.

Hello Nico,

That's encouraging. However, in medical electronics everything has to have a fully back-traceable design history, including the tools.

The MCS48 and TMS1000, 3870 etc. were very popular at one time too, but they did not survive. There's a reason for that.

Best regards, Spehro Pefhany

Hello David,

Oh, there were quite a few bad prawns so far, of different origin.

As I answered to Nico, we usually need fully traceable design history for our products and also for our tools. That pretty much means there has to be a centralized doc system, one that FDA inspectors would bless in case of an audit. A case in point was an impedance analyzer. The TenTec VNA would have been perfect to the job. But, because of the above requirement we could not use it and had to buy Agilent.

Hello Ken,

That is the other reason why many of my designs went 8051. It was much easier to find local people to write the code because more are familiar with it. For low-power apps that meant pulling a lot of tricks out of the hat though.

Well, "open source" is no guarantee of quality - but neither is "closed source". The software world is all buyer beware, even if the dollar price is zero.

I would have thought that open source tools would suit that better - you have the entire source available. In the case of well-run major projects like gcc, they've got old versions available stretching back for many years. The msp430 port is not in the main gcc tree, however, but their patches are all available as source.

Of course, I've not had the pleasure of having to follow FDA rules, so I may be completely wrong.

damn

There can be many, many reasons for something being popular or not - my point is merely that technical pros or cons are not necessarily (or even often) the deciding factor.

Hello David,

Source code with some comments in there doesn't qualify, usually. At least not in front of an FDA inspector I guess. Everything must be fully ECO'd, blessed by QA/QC, logged, catalogued, retrievable within x minutes from FDA officer's request and so on.

It's no cake walk but generally their rules make good sense. By now I use them even on non-FDA regulated projects. That has saved the bacon for at least one client. They had a field problem and could not find the right records. I had pulled it all up before finishing that rather panicky phone call and began to pack and book a flight right after. Around six in the morning, oh man.

Hear hear !

If an assembler / compiler works why does it need 'developing' ?

Graham

PL/M appears to manage just fine !

Graham

What is there to maintain if it works ?

Graham

Hello David,

Absolutely. Like the FPGA series that Intel had many moons ago. At that time it was the only series that had any reasonable power consumption. Basically CMOS behavior, going almost towards zilch as the clock frequency approached zero.

I almost designed a major (meaning a decade+ of production) product around it. Luckily I went discrete again. Whew. Intel just dropped them like hot potatoes. No idea why.