Seeking more input on hobbyist demo/educational stuff

That's true - and I'd also say that the 6808 chips are a poor choice to learn about these days.

It is not uncommon in professional work for factors such as peripherals, price, power consumption, etc., to outweigh the cpu core when choosing the right microcontroller for the job. But when you have a free choice of core, then you should pick one that has good tools at an appropriate price (for this situation, free or very cheap is appropriate), and that is easy to work with.

There are good reasons why accumulator-based register-poor architectures are considered old-fashioned, and modern cpu designs are risc architectures (unless they need to be backwards compatible, of course). So if you don't have overriding reasons for picking a register-poor core, then don't use them.

mine.

The number of CPU registers that are appropriate for embedded systems is not as simple as more is better. We have looked at a lot of embedded application code and the number of registers that could be effectively used in real applications is a small number. It is unfortunate that most of the open source tools have never focused on application optimization.

The 6808 / RS08 ISA swapped more CPU registers for lots of page

0 operations removing data flow pressure on the processor registers. The win for embedded systems comes in two forms reduced interrupt overheads saving and restoring processor registers and many operations that never need a processor register.

I don't see risc as the architecture of choice in new CPU designs for embedded systems. The basic problem is code density and application execution speed. The fundamental problems are best shown in the ARM thumb ISA eventually extending it to the Cortex M3. (Cortex M0/M3/M4 may well become the next 8051) What I am seeing in new ISA's are instruction sets that are trading execution speed for code that can only be realistically created with code generation tools.

w..

mine.

There is a trade-off - I don't mean that more registers is always better. The sweet-spot for small devices is probably no more than 16 registers, perhaps just 8. But passing all data through a single accumulator becomes a bottleneck in many applications, and a CISC-style core with complicated addressing modes and instructions leads to a slower implementation (because you have more layers of logic for decoding and execution).

I don't see a problem with cores requiring code generation tools to get the best out of the core (within a practical development time) - as long as the cores are designed to suit code generation tools. (The Itanium was made with a human-unfriendly architecture on the assumption that compilers would handle parallel instruction scheduling, without stopping to think /how/ compilers would do that job.)

Me and my employer would have to disagree with that statement. We have all three classes in use here, and will for a while yet. 16-bit CPUs compete with 32-bitters for projects 1 MiB ROM range, and they have what it takes to win a good portion of those.

But then, this is automotive stuff, where CPU cores as such are typically considered a side issue. You basically buy peripherals, memory and overall robustness (wide temperature range, robust I/O pin circuitry at 5 Volt, ... and no BGA, thank you very much), and accept whatever CPU core happens to be sitting in the middle of all that, as long as it's a halfway decent architecture with sufficient tool support.

I agree, though, that it's probably no longer worth the bother to go into depth on all three size classes in a course on micros aimed at hobbyists. Not because there's no 16-bit market any more, but because there's not that much special about 16-bitters. Once you've studied 8 and 32 bit CPUs for a while, understanding the peculiarities of 16-bit ones should be an exercise on interpolation which can be left to the reader.

Automotive industries often use a variety of cores that are less well-known amongst the "masses" of small-time and hobby developers. I have no idea which ones /you/ use, but in that industry microcontrollers from Fujitsu or Renesas are often more common than ARM or AVR cores. And yes, some of these are 16-bit and are fully suitable choices for these designs. But they don't really fit the market that the OP is looking for here. Personally, I am enjoying working with a large PPC device at the moment - but I would definitely not recommend it as a choice of a 32-bit microcontroller for teaching hobby users!

So let me amend my statement to "the 16-bit market is mostly dead" - nothing in the embedded world really dies entirely, they just get pushed into smaller and smaller niche markets.

how

I have experience doing professional applications for commercial instrumentation using both AVR and PIC. I have no question which of the two I'd recommend, assuming technical merits related to the application being the same.

I would recommend them OVER the AVR -- not because the ISA you seem so focused upon, but because of the support I've consistently received as a developer. No questions asked, just rapid delivery of answers and ridiculously good support for their professional development tools and old parts. (Way, way beyond even my hoped for expectations.) Time and again. Not once. Not twice. But dozens of situations that might otherwise have been more difficult with another source and most certainly WAS made much more difficult by Atmel, in a couple of new projects where my ealier positive experiences and their parts suggested I should use them again. (These were pushed up to European corporate, not just my local FAE, by the way.)

mine.

As always, of course. That's neither good nor bad, just is.

No, that was another claim. But in reading over all of it, it really just seemed to be a conclusion that the market is dead. I still think that's the underlying point you made.

Another claim. But it sadly conflates many boundary conditions all into the same soup. The reality is MUCH more nuanced than that.

Thanks for the input, David. You know I mean it seriously. I agree with a few things you say above (particularly ones that are exactly what I said earlier -- hehe.) But I'm not looking for the focus you suggest, nor if I did would my experiences be interpreted the same as you've interpreted your own experiences about what is going on. Either or both of us can be wrong -- my bet is both -- but research starts out with developing a comprehensive view. Right now, that's my goal in this thread. Not debating or deciding the end points. I do take your experiences very seriously, though. I take Walters with very great weight. And I've been helped a great deal, more than I'd actually hoped for this go-around by many others here too. It has all given me much more to consider and helped me realize more of what scope I have to look at before starting to winnow things back down.

Jon

Automotive CPU choice is hardly a side issue. The fundamental requirement is the silicon needs to operate reliably for a decade or more in a very bad environment, both physical and electrical.

There are issues that few other embedded processors ever face like processor power up in -50 degree environments with packaging that can stand temperature and humidity shifts.

Most automotive processors used are designed to meet this kind of extreme requirements. There are few processors designed for consumer electronics used in automotive applications.

w..

I believe SDCC is quite a lot better for 8051, and more popular there.

Chris

support.

You make me wonder about the lead frame, slack in the bonding wires, the package leads, and the package and all the expansion issues related there. Just for the temperature part. Existing packaging is pretty resistant to chemicals, but I imagine even that could be improved upon if there was a need and money to do it.

I do imagine that resistance to moisture is also required, but I hardly imagined that humidity changes impact the packaging design more than it already does. My area goes from its usual 90% humidity state during most of the year to perhaps 18-20% during parts of the year. Everything has to stand that much.

Now that all this comes up, I live in a rain forest -- literally we get 65-80 inches a year spread out evenly throughout the year (until the last decade or so with global warming -- another issue which gives me two more months of gardening time and where the total precipitation hasn't changed but more of it comes in winter and less in summer.) Moss and lichens iterally grow on the dust on and around bumbers of cars. It grows on the rubber insulation, especially, destroying it in time. I wonder if it grows on the IC leads. I'll have to go look. ;P

Jon

That's fair enough. Our experiences often seem to differ somewhat - both in what we have used, what we have read about or heard about, and what experiences we have had with support, manufacturers, distributors, etc. (For example, I have heard many people say that they find distributors to be useless middlemen, and they prefer to contact manufacturers directly for parts or support. My experience has been the opposite, with distributors providing a great deal of help and support. Maybe that's just the way it works here in Norway.)

As I said, use my experiences and opinions if they are useful to you. It is /you/ that is doing this project, /you/ who know your target audience, and /you/ who have to support them! And while I believe I do a good job as a development engineer and programmer, I think I would make a very lousy teacher - so your judgement on what is suitable for educational purposes outranks mine rather significantly.

mvh.,

David

Atmel is IN Norway, isn't it? I'd expect you'd find better support from random folks walking down the streets there, than I would here 180 degrees on the other side of the world!! My Atmel FAE is a very wonderful, very well informed man. Nothing I've said should say anything different than that. However, there are situations that the local FAE and local distributers (I was going through both, before going directly to Atmel's group in France regarding the AT91) cannot handle. More, It turns out that many of my issues had to be "funneled" through "channels" and given the opposite side of the world that meant two day turn arounds in communications, most of the time. Even then, actual experience regarding the issues was miserable. The difference between what I'd expect from Microchip in, say, no more than a week... took 9 months with Atmel. And even then, resolved long too late to be of any use.

It just didn't work out. And then Atmel pulled memory parts and certain key cpus from small orders (my customers we between 1000 and 5000 per year in orders, which Atmel didn't imagine was worth supporting) in order to fill only their largest customer needs. I knew where the parts went, though. Microchip, so far as my experience goes, may make everyone bear some of the brunt, but it never ever cuts its smaller customers off at the knees. You can feel them working hard for you, even when you are small. It shows. Every day.

Your experience has helped me a number of times, David. And I very much appreciated it. I'm sure not for the last time, either.

Different worldviews and experiences, perhaps. But what is shared in common I'm sure far exceeds any such differences.

Jon

Atmel's AVR group is in Norway - but the main company is in the USA (and their 8051 group is in France).

I can't say I have had a huge response the couple of times I've used their forums - but then it was for complaints about their development tools and I didn't really have much hope of a positive response!

I don't know what the situation is like for Microchip, but Atmel AVR's have a very strong support community independent of Atmel (and sometimes directly at odds with Atmel) through the avrfreaks website and communities round the open source development tools and libraries. I think that for many people, avrfreaks is a more useful source of help and information than the suppliers.

I must admit I have only ever heard good things about Microchip's support, especially for smaller customers and smaller orders - and I can see how that is very important to you.

Jon,

To add to the issue of automotive processor reliability visualize a car whose owner lives in Bismarck ND (Close to where I grew up) and decides they have had enough of arctic winter and decides a winter would be better spent in Phoenix. Couldn't resist a little skiing in Denver on the way down and once there settled in and finally realized that 4th of July celebrations are best observed at home so he drove over to see his friend Jon for a little microprocessor advice and stopped back in Denver to collect the skis he left behind then home.

This road trip more or less covers the requirements list for embedded automotive CPU's. As you implied the system issues are also an issue, lead and board layout. Humidity includes condensing moisture and absolutely dry.

Some of the CPUs are designed with internal error correcting on all memory accesses including processor registers to combat electrical noise.

w..

pin

accept

as

support.

Any use ECC for each and every cpu register and latch? I'd also tend to want larger feature sizes, than smaller, just as a guess.

Jon

Suffice it to say that I did mention "overall robustness" for a reason. The one point I did indeed forget to mention is guaranteed long-term availability.

The point that I was trying to make here is that CPU architecture aspects like 16-bit vs. 32-bit, much less something like PIC vs. 8051, AVR vs. MSP430 or ARM vs. MIPS would be among the least of your worries in the selection process.

Those would mainly be restricted to use in non-essential systems inside the passenger compartment, e.g. the radio/DVD/navigation units. Those things have turned into very nearly complete personal computers, up to and including a HDD and touch LCD --- and 30+ seconds boot-up time. Some people can get from their garage to the highway before their radio displays anything useful.

Well, let's just say if you need MIL Spec, your customer will probably just tell you where to get the parts ;-)

Automotive ECUs in areas like the the engine compartment can suffer some pretty amazing kinds of humidity problems. E.g. you make a really nice better-than-IP65 enclosure for your main engine controller, only to have water pushed in _through_ the cables (as in: between copper and insulation, partly by capillary effects) into the plugs and sockets, all the way onto the PCB.

Yep. It's not entirely unheard-of to have a controller manufacturer come in and, in a friendly but matter-of-fact style, ask if existing contracts notwithstanding you could possibly be persuaded to consider a re-spin of your long-running project, since that would mean they could finally clean out and refurbish that oldest, biggest-feature-size fab of theirs --- what with you being the only customer for those chips.

Err, you are probably thinking of their Matra-Harris 8051 buy out, a long time ago now, and I believe Atmel have sold all their French assets.

Their 8051 business, and especially the LP51 series, is done from US HQ in San Jose. I still see the 8051 as a good intro, especially given it has many education-mature Simulators.

-jg

(and

long time ago now, and I believe Atmel have sold all their French assets.

in San Jose.

education-mature Simulators.

And a nice BASIC from Intel that I have. Used to be the docs were free from Intel; no longer even available so far as I'm aware. But it's a decent tool, just the same. It's in the back of my mind as one of many pathways to consider.

Jon