There are simple ARM µCs too, and ARM assembly is easy peasy, a much better design and much easier to understand than the arbitrary ISA messes of the obsolete 8 bitters.ARM assembly isn't easy peasy. It being complicated is why industry veterans like Jack Ganssle don't bother with it. I assume we value his opinion above ours. ARM chips are a lot more complicated than 8 bit chips. There's no way around it.
There are simple ARM µCs too, and ARM assembly is easy peasy, a much better design and much easier to understand than the arbitrary ISA messes of the obsolete 8 bitters.ARM assembly isn't easy peasy. It being complicated is why industry veterans like Jack Ganssle don't bother with it. I assume we value his opinion above ours. ARM chips are a lot more complicated than 8 bit chips. There's no way around it.
There are simple ARM µCs too, and ARM assembly is easy peasy, a much better design and much easier to understand than the arbitrary ISA messes of the obsolete 8 bitters.ARM assembly isn't easy peasy. It being complicated is why industry veterans like Jack Ganssle don't bother with it. I assume we value his opinion above ours. ARM chips are a lot more complicated than 8 bit chips. There's no way around it.Few people bother with any assembly language in MCUs. They use C. ARM chips are generally a lot more complicated than 8 bit chips, but its nothing to do with the instruction set. Its the complexity of getting them configured to the point where they can run any useful code which makes them more complicated to get started with.
Jack Ganssle is just an old fart. Remember: Those who can, do; those who can't, teach. From my own experience ARM assembly is as easy or difficult like assembly for the Z80, ADSP2180, x86, 8051, MIPS, ARM, 68000 and a few others I have probably already forgotten about.
There are simple ARM µCs too, and ARM assembly is easy peasy, a much better design and much easier to understand than the arbitrary ISA messes of the obsolete 8 bitters.ARM assembly isn't easy peasy. It being complicated is why industry veterans like Jack Ganssle don't bother with it. I assume we value his opinion above ours. ARM chips are a lot more complicated than 8 bit chips. There's no way around it.Few people bother with any assembly language in MCUs. They use C. ARM chips are generally a lot more complicated than 8 bit chips, but its nothing to do with the instruction set. Its the complexity of getting them configured to the point where they can run any useful code which makes them more complicated to get started with.Again: that depends entirely on what kind of microcontroller you are using. There are 8 bit microcontrollers which are hard to configure as well. Don't confuse the CPU core for peripheral complexity.
Jack Ganssle is just an old fart. Remember: Those who can, do; those who can't, teach. From my own experience ARM assembly is as easy or difficult like assembly for the Z80, ADSP2180, x86, 8051, MIPS, ARM, 68000 and a few others I have probably already forgotten about.I'll trust the old fart over the random forum guy. Besides, not teaching doesn't automatically mean being in the "can" group.
There are simple ARM µCs too, and ARM assembly is easy peasy, a much better design and much easier to understand than the arbitrary ISA messes of the obsolete 8 bitters.ARM assembly isn't easy peasy. It being complicated is why industry veterans like Jack Ganssle don't bother with it. I assume we value his opinion above ours. ARM chips are a lot more complicated than 8 bit chips. There's no way around it.Few people bother with any assembly language in MCUs. They use C. ARM chips are generally a lot more complicated than 8 bit chips, but its nothing to do with the instruction set. Its the complexity of getting them configured to the point where they can run any useful code which makes them more complicated to get started with.Again: that depends entirely on what kind of microcontroller you are using. There are 8 bit microcontrollers which are hard to configure as well. Don't confuse the CPU core for peripheral complexity.I neither mentioned nor intended to refer to peripheral complexity.
There are simple ARM µCs too, and ARM assembly is easy peasy, a much better design and much easier to understand than the arbitrary ISA messes of the obsolete 8 bitters.ARM assembly isn't easy peasy. It being complicated is why industry veterans like Jack Ganssle don't bother with it. I assume we value his opinion above ours. ARM chips are a lot more complicated than 8 bit chips. There's no way around it.Few people bother with any assembly language in MCUs. They use C. ARM chips are generally a lot more complicated than 8 bit chips, but its nothing to do with the instruction set. Its the complexity of getting them configured to the point where they can run any useful code which makes them more complicated to get started with.Again: that depends entirely on what kind of microcontroller you are using. There are 8 bit microcontrollers which are hard to configure as well. Don't confuse the CPU core for peripheral complexity.I neither mentioned nor intended to refer to peripheral complexity.Actually you did because every microcontroller has the CPU start executing code from the default start address after power up. ARM microcontrollers are no exception to that rule.
I hate it when other people say something is hard because they failed or are not inclined to make the effort to learn. It doesn't say anything about something being hard or easy to do for someone else. Idolising a person is the worst thing to do. Always go from your own strength and let nobody tell you are unable to do this or that. History is littered with people who succeeded where many others failed.
[Simple ARM chips exist]QuoteSuch as? I mean, it's not really awful, but I don't think I've run across an ARM yet that isn't: "oh, you want to run at the rated maximum clock speed? That means you'll have to start by configuring our complicated clock system! (Don't worry; you can use the 1kbyte library function instead.)"QuoteARM assembly isn't easy peasy. It being complicated is why industry veterans like Jack Ganssle don't bother with it.ARM assembly language is ... unpleasant, designed to be output by a compiler rather than written by a human.That's especially true of the Cortex-M0 used on the low-end ARM MCUs. "Supports the ARM instruction set. No, not that instruction. Not that register. And not that mode of THAT instruction, and ... the range of operands for THIS instruction is a bit limited on CM0." Sigh.Even on a well-behaved ARM, it's still three instructions, a literal pool constant, and two registers trashed to write a value to a peripheral register.
8bit is a great place to learn the basics. They provide a solid baseline skill set that translates to all sorts of more complex architectures.
There are simple ARM µCs too, and ARM assembly is easy peasy, a much better design and much easier to understand than the arbitrary ISA messes of the obsolete 8 bitters.
Many of the 8 bitters do have horrid ISAs. 8080/Z80, 8051, 6800, 6502, PIC. A few however are actually pretty pleasant: 6809 and AVR, for example.
I do love ARM, and it's simpler than x86, but its gained a lot of cruft over the years and is much more complex than MIPS or RISC-V. Both RISC-V (with 16 and 32 bit instructions) and the latest nanoMIPS encoding (with 16, 32 and 48 bit instructions) come in very code size competitive with Thumb2, while still being much simpler.
time constrained program
Are there 8bit microcontrollers based on 8080/Z80, 8051, 6800, 6502? I thought they were simply CPU's.
Jack Ganssle is just an old fart.
Quotetime constrained programWere the ARM manuals sufficient? When it comes to timing, it seems to all fall apart when you get to the not-full-speed flash memory, which usually has some sort of "accelerator" or cache in front of it, which is usually a vendor feature that is not very well documented :-(QuoteAre there 8bit microcontrollers based on 8080/Z80, 8051, 6800, 6502? I thought they were simply CPU's.Z80 - yes. There's a whole line Zilog microcontrollers (on-chip RAM and code memory, plus peripherals), plus some of the Renesas chips are pretty much Z80-like (with bells, whistles, an kludges.)
The 8051 was always a microcontroller. There are now oodles of variants with up to a full address space (or more) of program flash, although RAM is usually a bit on the weak side. Any number of special purpose chips (MP3 player chip, USB Flash Controller Chip, etc) turn out to be 8051 cores with some special purpose hardware attached.
I don't know if there are any 6800 microcontrollers, but the 6805 line (which is quite similar architecturally) spurred several microcontroller families, including S08 and S12 families that are still labeled as current, rather than "legacy."
I don't know of any 6502-like microcontrollers.
I don't know of any 6502-like microcontrollers.
It has the same six registers (A, X, Y, SP, PC, CC) as the ST7, but the index registers X and Y have been expanded to 16 bits, and the program counter has been expanded to 24 bits.
Even before cache and flash issues the interrupt overhead was already too high to bother.
1802 | RCA | ? Most instructions take 16 clocks (6.4μs), some, 24 (9.6μs). 2.5MHz @ 5V. |
8080 | Intel | ? (still waiting for information) |
8088 | Intel | 10 bus cycles or 40 clocks(?) (B)+(C) (still waiting for further information) |
8086 | Intel | WDC says 182 clocks max total latency. * * * * * (still waiting for information) |
Z8 | Zilog | IRET (E) takes 16 execution cycles. I don't know how many clock cycles per execution cycle. 8MHz? |
Z80 | Zilog | 11-19 clocks (B)+(C) depending on mode, or 2.75-4.75μs @ 4MHz. RETI (E) is 14 clocks, or 3.5μs @ 4MHz. |
Z8000 | Zilog | IRET (E) takes 13 cycles in non-segmented mode, and 16 in segmented mode. I don't know if that's instruction cycles or clock cycles. |
8048 | Intel | (?) return (E) is 2.7μs @ 11MHz |
8051 | Dallas | 1.5μs @ 33MHz (52 clocks) latency |
8051 | Intel | 1.8μs (C) min @ 20MHz. 5.4μs (A)+(C) max total latency @ 20MHz. (3-9μs @ 12MHz.) Interrupt sequence (C) and return (E) take 4.6μs @ 20MHz ST |
80C51XA | Philips | 2.25μs for interrupt+return (C)+(E) @ 20MHz. ST Instructions 2-24 cy, or 0.1-1.2μs. Avg 5-6 cy, or around 0.27μs. |
KS88 | Samsung | 3μs for interrupt+return (C)+(E) @ 8MHz ST Instructions 6-28 cy, or 0.75-2.5μs. Avg 11 cy, or 1.38μs. |
78K0 | NEC | 4.3μs for interrupt+return (C)+(E) @ 10MHz ST Instructions 4-50 cy, or 0.4-5.0μs. Avg 15 cy, or 1.5μs. |
COP8 | National | 70 clocks (7 instruction cycles). RETI (E) is 50 clocks (5 instruction cycles). (7μs & 5μs @ 10MHz) |
μPD78C05 | NEC | RETI (E) takes 13 or 15 clocks (2.08 or 2.4μs at 6.25MHz) |
μPD70008/A | NEC | sequence (C) takes 13 or 19 clocks. Return (E) takes 14 clocks. Instructions take 4-23 clocks each. 6MHz in '87 book. |
V20 | NEC | RETI (E) takes 39 clocks or 3.9μs @ 10MHz in '87 book. Instruction set is a superset of that of 8086/8088. |
V25 | NEC | ? (still waiting for information) |
68000 | Motorola | 46 clocks or 2.875μs minimum @ 16MHz (B)+(C)?. Has a very complex interrupt system. |
6800 | Motorola | (C)=13 clocks, including pushing the index register and both accumulators. RTI (E) takes 10 clocks. 2MHz. |
6809 | Motorola | (C)=19 clocks. Stacks all registers. RTI (E) 15 clocks. 2MHz (8MHz/4). FIRQ-RTI take 10 & 6 clocks, & work more like 6502 IRQ-RTI. |
68HC05 | Motorola | 16 clocks typ (8μs @ 2MHz) |
68HC08 | Motorola | Instructions 1-9 cy, or 0.125-1.125μs. Avg 4-5 cy, or around 0.55μs. |
68HC11 | Motorola | (C)=14 clocks. RTI (E)=12 clocks. Total for interrupt+return=8.75μs @ 4MHz (16MHz/4). ST Instructions 2-41 cy, or 0.5-10.25μs. Avg 6-7 cy, or around 1.6μs. |
68HC12 | Motorola | 2.63μs for interrupt+return (C)+(E) @ 8MHz. ST Instructions 1-13 cy, or 0.125-1.625μs. Avg 3-4 cy, or 0.45μs. |
68HC16 | Motorola | 2.25μs for interrupt+return (C)+(E) @ 16MHz. ST Instructions 2-38 cy, or 0.125-2.375μs. Avg 6-7 cy, or around 0.4μs. |
PIC16 | Microchip | (C)=8 clocks (2 instruction cycles), and RETFIE (E) is also 8 clocks; but this doesn't even include saving and restoring the status register. That's an extra, rather mickey-mouse operation. 20MHz Most instructions 4 cy, or 0.2μs. |
TMS370 | TI | 15 cycles (3μs) min (C), 78 (15.6μs) max (A)+(C), and a cycle is 4 clocks (200ns min)! 20MHz. RTI (E) is 12 cy (48 clocks or 2.4μs). |
TMS7000 | TI | (C)=19 cycles min (17 if from idle status) 5MHz, 400ns min cycle time (IOW, interrupt sequence is 7.6μs min, 6.8 from idle.) RETI (E) is 9 cycles, or 3.6μs @ 5MHz. |
ST6 | STM | 78 clocks min, or 9.75μs @ 8MHz to fetch interrupt vector. More to reach first ISR instruction. RETI is 26 clocks, or 3.25μs. |
ST7 | STM | 3μs for interrupt+return @ 8MHz. ST Instructions 2-12 cy, or 0.25-1.5μs. Avg 4-5 cy, or around 0.55μs. |
ST9 | STM | External IRQ best case: 1.08μs @ 24MHz. NMI best case: 0.92μs. internal interrupts best case: 1.04μs. 2.25μs @ 24MHz for interrupt and return ST Instructions 6-38 instruction cy, or 0.5-3.67μs. Avg 17 cy, or around 1.4μs. |
ST9+ | STM | 1.84μs @ 25MHz for interrupt and return, ST Instructions 2-26 instruction cy, or 0.16-1.04μs. Avg 11 cy, or around 0.9μs |
H8/300 | Hitachi | 8/16-bit: 2.1μs @ 10MHz for interrupt and return ST Instructions 2-24 cy, or 0.2-3.4μs. Avg 5-6 cy, or around 0.55μs. |
M16C M30218 | Mitsubishi Renesas | 18 cy min (C), or 1.125μs @ 16MHz w/ 16-bit data bus. 50 cy max (A)+(C). REIT is 6 cy, or 0.375μs. Dual register sets like the Z80. Max instruction length 30 cy. |
CIP-51 | Silicon Labs Cygnal | μC p/n C8051F2xx) total latency 5-18 cy or 0.2-0.72μs @ 25MHz. RETI takes 5 cy, or 0.2μs. This is the only one I have data on here that gives the 6502 below any competition. |
65C02 | WDC | Normal latency (C) 7 clocks (0.35μs) min, 14 clocks (0.7μs) max (A)+(C). RTI 6 cy (0.3μs). 20MHz. Instructions 2-7 cy, or 0.1-0.35μs. Avg 4 cy, or 0.2μs. Special case: IRQ from WAIt instrucion with interrupt-disable bit I set: no more than 1 cy (0.05μs!) |
Jack Ganssle is just an old fart.I find it that this kind of personal attack is unnecessary, especially with that type of wording, even if I may agree about the advantage of modern µCs. It's just an unpleasant kind of interaction, and quickly derails.
I will say my personal experience is that the ARM MCU's I've used finding a lot of the details of the core, which matter for a time constrained program, was not easy and not in the datasheets. The datasheets were mostly about peripherals, which is normal for an ARM MCU as far as I can tell. I was forced(or I could just not know I guess) to look up the data in the ARM manuals. That isn't pleasant for me and feels like searching through a large garbage bin for a lost check. The 8-bit MCUs I've used had that data in the datasheet. If you don't care that's fine but that was my experience. I still use 8 bit and 32 bit MCUs, ARM and not, but it's definitely not as easy to find some data that you might need.
Sometimes you need to make a bold statement to get a point across to wake people up. Look at Jack's bio. He clearly is a systems designer and not a programmer.
Sometimes you need to make a bold statement to get a point across to wake people up. Look at Jack's bio. He clearly is a systems designer and not a programmer.It would probably be naive to think his experience and preference only applies to him personally being behind a keyboard or writing code. This would also have been the moment to concede it may not have been the best way of expressing yourself, rather than doubling down on it.
ARM architecture is easy to understand, what comes to the interrupt vector table, how the interrupts work, and how to use them. Also register pushing on interrupt entry. I find all this simpler than on AVR, although AVR is quite simple as well. Having prioritized interrupts that can pre-empt others, IMO, makes everything easier. You can write longer ISRs with lower priorities, and make timing critical ISRs pre-empt them; you have more tools in your box to work different ways case-by-case. Using two lines of code to set the interrupt priority and enable it is not complex.