TOMADO de la pagina http://muforth.nimblemachines.com/Blog
Estoy de acuerdo con lo dice el autor.
Attractions of the S08
They are quite cheap - cheaper than comparable PIC or AVR parts - and you get a lot of bang for your buck. For instance, the S08QG parts in DIPs have a UART, SPI, and I2C, all standard, a good selection of timers, 8 channel 10 bit ADC, and some nice add-on features, such as clever compare logic in the ADC that causes an interrupt only when a value crosses a threshold. The USB parts have 12 bit ADC, 2 UARTS, and 2 SPI ports.
Also, it's quite easy to get free samples, directly from Freescale, and also to buy directly from them, for very competitive prices, even down to quantity one.
Unlike Atmel's Flash, which is only good to 10k cycles (if you're lucky) and has a short retention lifetime (10 years?), Freescale's Flash, like much of Microchip's, is good to 100k cycles and has a retention of more like 100 years. This might not sound like a big deal, esp for hobbyists, but philosophically I find it unappealing to use something so obsolescent as Atmel's chips.
Von Neumann architecture
A feature that is here in the "pro" column but also has a dark underside. Since RAM and Flash exist in the same memory map, it's possible to execute code out of RAM - and in fact it is necessary to do so when executing code to program the Flash. Code in RAM make several things possible:
* self-modifying code
* "specialised code", generated on the fly on the target
* nice interactive development - ie, the ability to define and execute new bits of code while "online" with the target
Built-in debug architecture
This is an attractive feature, esp if you're going to use Freescale's development software, which can take full advantage of it.
Basically, every S08 part - even the lowliest 8 pin part - has not only a background debug mode (BDM) single-pin interface (which can be used to Flash empty parts, to reprogram parts, and to debug running code!) but also a tiny built-in in-circuit emulater (ICE). There are two code breakpoints and one data watchpoint available in hardware, with sophisticated chaining available between two of them. There is also an 8 entry trace buffer, allowing the capture of address and data bus values.
Considering how "low-end" some of these parts are, this is quite a stunning feature.
It's more "gut feeling" than real empirics, but the quality and flexibility of the on-chip peripherals seems very high, compared to AVR and PIC. Maybe when I re-develop all my code for AVR I'll have harder data on this one. ;-)
Upward migration path
Freescale have introduced several new S08 families with the so-called Flexis architecture. The new USB parts - the S08JM family - are Flexis parts.
Flexis families have both S08 members, and 32-bit ColdFire members, which are pin-compatible and only a bit more expensive than their 8-bit cousins, making it easy (assuming your code is not in assembler!) to upgrade to a fast 32-bit core. The peripherals are exactly the same 8-bit peripherals in the S08 parts, so all that code - again, assuming it's in a high-level language - will port over trivially.
Or so the story goes. It's a nice idea, and if you're not interested in ever using the 8-bit version, it's a way to get quite cheap 32-bit parts.
And since ColdFire is essentially 68k, it's a good target for Forth and C (and everything else) and also nice for nostalgia buffs.
Distractions of the S08
Ok, so how about downsides to the HCS08? There are several, and a few are big ones.
* lack of community
* lack of open source support
* lack of cheap, universal, and easy-to-use development hardware
* lack of off-the-shelf "target" hardware (eg, like Arduinos and clones)
* lack of registers! making Forth a bit tricky
* von Neumann architecture slows execution considerably
* most S08 parts are 3v only (1.8v to 3.6v), though there are a few 5v families (intended mostly for automotive customers)
I think the hardest for me right now is the lack of development hardware. I have some chips, but I have to do some work to be able to try them out. I'm currently busy writing code, but soon I'll want to try it on some real hardware!