Nearby Brad had a bit of a rant, which prompted me to wonder...

It would be interesting to hear from people who do this kind of thing for a living:

• How do you choose which family of microcontroller to use?
• How important is the quality of the toolchain?
• Does the availability of a C compiler make any difference?

(I refrain from putting "OT" in the subject here, because the answers to these questions must be important to WDC, who make not only microprocessors but also microcontrollers and dev boards, and must know that they are competing with offerings based on ARM, or PIC, or MSP430, or Coldfire, or Z80, or others. So, how people make their decision must be of interest.)

Most of my work with small control and data acquisition systems (including custom RTUs for SCADA) was done on the Z80. That particular project ended up being used for around a hundred endpoints. It was all coded in assembler.

I've coded some in C, but not enough that it has ever began to feel "natural" to me.

Any language can be confusing if the writer takes a lot of short-cuts and doesn't leave a lot of comments. Not trying to brag, but I would be surprised if someone familiar with Z80 assembly couldn't take my code and figure out what I was don't from the comments. I will sacrifice compactness and saving a few cycles for something that is straight forward. The only exception to that is some very early work I did with the 1802 where RAM and ROM were scarce.

I have used PICs the last few years for some one-off projects. Typically those are also coded in assembler.

I tend to look for reference designs or similar projects when choosing a chip to start from. I have never been involved in anything where production scale mattered, so spending an extra $5 to $25 a device is no big deal if it cuts development time. I love the 6502, but tend to use the Z80 for things where I buy pre-manufactured boards and the PIC for hand-built boards.

As for the toolchain, that is one of my pet peeves. If I can't get something installed and do a basic "hello world" in 15 minutes, I usually move to the next thing. For the Z80 and PIC, part of the attraction is the variety of tools available to use. If one doesn't fit my style of coding and working, I find another that does. (I've been working with Cyclone FPGAs lately--one or two gig download to get started??? At least the tools work well once you get going.)

For me, C adds no value. For small control projects, I don't want to mess with things like linkers and libraries. A lot of time, the code goes into ROM or is burned into the controller, so I'm good with explicitly defining and managing the address space. Is the code not as "reusable"? Probably, but I've had projects where getting things running in a week was important while I've never had one where they said that having code that could be reused is paramount.

I will point out one more thing that is becoming more common--code audits. For things that go into critical infrastructure, you may well have to go through a code audit to ensure your device is secure. At that point "I don't know assembler." becomes problematic if assembler is an intermediate step in generating object code. With assembler, if the code looks clean, you just have to verify the actual object code matches what should have been generated. With C, typically the assembly code is auditable as well as the assembled results. The problem is that the assembly code is usually pretty hard to wade through. For consumer devices or non-critical applications that probably isn't that big of a concern.

Years ago I did build a system around the 6512 with Forth a long time ago. I'm not any good with Forth either, but built those were used as control and data acquisition systems for chemistry experiments and the chemist involved developed the bulk of the code.

Thanks,
Jim

Very interesting, thanks Jim. I like the Hello World toolchain usability test!

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

I'm an expert on neither, and just briefly glanced at the instructions sets as presented by Wikipedia.

The MSP430 has 16 16 bit registers, of which 4 are reserved (PC, Stack, Status, and a "Constants" register). In contrast to the Atmel which (for the 8-bit) appears to have 3 "pointer" registers, and 32 byte registers (which map to the zero page).

So, it's easy to see how a bunch of free 16 bit registers, on a 16 bit machine, makes writing a Forth extra easy.

That said, it seems the MSP430 has "lots of ROM (Flash)" and "a little RAM". So you may be able to only host a limited Forth on it (in terms of the interactive environment one might be used to). Hardly impossible, of course, you can easily have a static vocabulary and one based on the little bit of RAM thats available. You could do a lot with just 1K of RAM and a robust ROM base program for debugging and experimentation on board, then adding the changes to a new ROM image and reuploading.

I'm no expert either but I can say the MSP430 is a really neat chip. It first got me into electronics, so I have a real soft spot for it. Most people seem to use C for it but some other guys on the forum when I was active a few years ago were doing assembler too. The DIP version chips all had less than 1k RAM last I checked. You can get a lot more RAM with their F series which is SMD only if you want a beefy Forth. On the other hand, I have had really good luck with 128k SPI RAM chips and the MSP430. It has a memory mapped SPI peripheral so you can just store a byte at that address and wait a couple cycles for the chip to write it automatically (I think it works up to half of clock speed, so 8MHz max for the DIP version.) That might cut down on your Forth speed but you would have an enormous amount of RAM to play with. I used that set up to make a scientific calculator with MSP430s. I made a program that would replace any references to variables I wanted stored on the external chip to function calls that used the SPI peripheral. This let me write code as if I had direct access to the 128k chip but involved some C voodoo not everyone may be fans of

I think the PIC24 microcontrollers are a good platform for Forth experimentation. Something like the PIC24EP512GP202 offers 48K of banked RAM, 512K of flash ROM, a 16-bit core easily programmable in C or assembler, 16 16-bit registers (only one reserved for the stack pointer) and 70MIPS of performance. All in an easy to use 28pin SPDIP package.

http://www.microchip.com/wwwproducts/en/PIC24EP512GP202

_________________
Andrew Jacobs
6502 & PIC Stuff - http://www.obelisk.me.uk/
Cross-Platform 6502/65C02/65816 Macro Assembler - http://www.obelisk.me.uk/dev65/
Open Source Projects - https://github.com/andrew-jacobs

I was active in PIC a long time ago. In fact, it was the first micro-controller I ever used and I managed to produce B/W video with them.

I've since moved on to Propeller and the AVR/Arduino-based mcu's.

But, that mcu looks nice at 70 MIPS. I wonder how well it would work for glue logic on a 65C02 based computer? I wonder how fast the 65C02 could run with that PIC acting as the memory decoder? Hmmmm...

_________________
Cat; the other white meat.

[url]flashforth.com/[/url]

Purchasing tells you what you can use. Unfortunately I'm not really joking. But given our choice, most of the engineers I work with have a few things they consider important. These are probably the most common, but the order varies by individual:
Peripherals and their suitability for the task
Code efficiency in time and space
Tool chain
Support from the manufacturer / application engineers.

I firmly believe the only reason the 8 bit PICs have done so well is the peripherals and the support. The architecture is just horrible, especially if you use C. If you are using a new chip and the FAE (field application engineers) can't or won't help you when you need it, you aren't likely to go back to that company again. With a lot of recent mergers (Freescale and NXP, soon adding Quallcomm and Microchip and Atmel) we have been bitten hard. Support was the first place they cut costs. The FAEs with the most knowledge and experience were let go and it shows.

Of course, to the bean counters, price is the ONLY thing that matters. The engineers are expected to work magic and run a million line app on a 1K flash, 8 pin micro.


It's pretty important, but in my experience it isn't much considered until it's too late. If you choose a chip and toolchain that is new to you, it is too late to do anything about it until you get a chance to change architectures later. Which usually means a couple of projects down the road. Where I work, we have now "standardized" on ARM Cortex parts and IAR toolchain. Luckily, the toolchain is good and covers just about anything with an ARM processor. But at around $5000 US per seat, you would expect it to be good.


Absolutely. In most cases it simply doesn't make sense to write assembly any more. The exception is VERY small applications, like <1K binary. C is semi portable (not as much in embedded work as large systems) and the compiler can almost always write better code than almost any human. A quote I read once was "the compiler doesn't get tired or bored." If you compare the output of a really good compiler to what you wrote, it's hardly recognizable. Modern compilers, the real money ones as well as open source (GCC), are simply amazing.

As much as I like, and like to play with, these old 8 bitters, they simply can't hold a candle to chips designed in modern times. Their architecture dates from a time when transistors were scarce and it's very difficult to have a compiler generate good code for them. The 6502 is probably one of the hardest of the popular ones, beaten only by the 8 bit PICs.

That's my 1/2 cent worth. I'm sure many people will disagree with much of it and I will be interested to see what they have to say.

Will