Author Topic: 8-bit uC - is there even a point?  (Read 57282 times)

0 Members and 1 Guest are viewing this topic.

Offline coppice

  • Super Contributor
  • ***
  • Posts: 8605
  • Country: gb
Re: 8-bit uC - is there even a point?
« Reply #125 on: September 29, 2018, 09:33:39 pm »
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.
 
The following users thanked this post: hans, petert

Offline langwadt

  • Super Contributor
  • ***
  • Posts: 4392
  • Country: dk
Re: 8-bit uC - is there even a point?
« Reply #126 on: September 29, 2018, 09:41:25 pm »
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.

I don't think ARM is terribly complicated, the reference card is a single page, but there is seldom reason to use it, compilers are is most cases good enough or better
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 26755
  • Country: nl
    • NCT Developments
Re: 8-bit uC - is there even a point?
« Reply #127 on: September 29, 2018, 10:26:24 pm »
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.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline Mr. Scram

  • Super Contributor
  • ***
  • Posts: 9810
  • Country: 00
  • Display aficionado
Re: 8-bit uC - is there even a point?
« Reply #128 on: September 29, 2018, 11:05:17 pm »
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. ;)
 

Offline coppice

  • Super Contributor
  • ***
  • Posts: 8605
  • Country: gb
Re: 8-bit uC - is there even a point?
« Reply #129 on: September 29, 2018, 11:06:03 pm »
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.
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 26755
  • Country: nl
    • NCT Developments
Re: 8-bit uC - is there even a point?
« Reply #130 on: September 29, 2018, 11:09:17 pm »
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. ;)
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.
« Last Edit: September 29, 2018, 11:14:29 pm by nctnico »
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 
The following users thanked this post: Siwastaja, petert

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 26755
  • Country: nl
    • NCT Developments
Re: 8-bit uC - is there even a point?
« Reply #131 on: September 29, 2018, 11:11:21 pm »
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.
« Last Edit: September 29, 2018, 11:15:31 pm by nctnico »
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline rx8pilot

  • Super Contributor
  • ***
  • Posts: 3634
  • Country: us
  • If you want more money, be more valuable.
Re: 8-bit uC - is there even a point?
« Reply #132 on: September 29, 2018, 11:13:20 pm »
I have spent the last few hours listening/watching an ARM introduction and tutorial series. It looks just like developing for 8bit. Just faster and much bigger numbers. If you are a sloppy coder.....you may never know with really fast clock speeds. For most applications, who cares I guess.

The cost of the hardware is silly cheap too.
Factory400 - the worlds smallest factory. https://www.youtube.com/c/Factory400
 

Offline coppice

  • Super Contributor
  • ***
  • Posts: 8605
  • Country: gb
Re: 8-bit uC - is there even a point?
« Reply #133 on: September 29, 2018, 11:29:09 pm »
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.
Are you considering the clock, interrupt control, power system, and so on to be peripherals? Those things take considerable effort to set up on most ARM MCUs before any actual application code can run, and do anything useful with the real peripherals. In most 8 bit MCUs you might need a couple of operations to get the clock up to speed.
 

Offline Mr. Scram

  • Super Contributor
  • ***
  • Posts: 9810
  • Country: 00
  • Display aficionado
Re: 8-bit uC - is there even a point?
« Reply #134 on: September 29, 2018, 11:31:23 pm »
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.
I agree with the last bit, but not with the assumptions before it.
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4196
  • Country: us
Re: 8-bit uC - is there even a point?
« Reply #135 on: September 30, 2018, 12:56:55 am »
Quote
[Simple ARM chips exist]
Quote
Such 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.)"

Quote
ARM 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.

 

Offline maginnovision

  • Super Contributor
  • ***
  • Posts: 1963
  • Country: us
Re: 8-bit uC - is there even a point?
« Reply #136 on: September 30, 2018, 02:51:34 am »
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.
 
The following users thanked this post: hans, petert

Online brucehoult

  • Super Contributor
  • ***
  • Posts: 4001
  • Country: nz
Re: 8-bit uC - is there even a point?
« Reply #137 on: September 30, 2018, 04:02:37 am »
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.
 
The following users thanked this post: petert

Offline rx8pilot

  • Super Contributor
  • ***
  • Posts: 3634
  • Country: us
  • If you want more money, be more valuable.
Re: 8-bit uC - is there even a point?
« Reply #138 on: September 30, 2018, 04:06:20 am »

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.

Are there 8bit microcontrollers based on 8080/Z80, 8051, 6800, 6502? I thought they were simply CPU's.
Factory400 - the worlds smallest factory. https://www.youtube.com/c/Factory400
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4196
  • Country: us
Re: 8-bit uC - is there even a point?
« Reply #139 on: September 30, 2018, 05:35:04 am »
Quote
time constrained program
Were 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 :-(

Quote
Are 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.
 

Offline petert

  • Regular Contributor
  • *
  • Posts: 178
  • Country: de
Re: 8-bit uC - is there even a point?
« Reply #140 on: September 30, 2018, 06:32:21 am »
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.
 

Offline maginnovision

  • Super Contributor
  • ***
  • Posts: 1963
  • Country: us
Re: 8-bit uC - is there even a point?
« Reply #141 on: September 30, 2018, 06:42:06 am »
Quote
time constrained program
Were 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 :-(

Quote
Are 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.

The ARM manuals told me what I needed to know. They were not easy to find or use though. Even before cache and flash issues the interrupt overhead was already too high to bother.
 

Offline Kjelt

  • Super Contributor
  • ***
  • Posts: 6459
  • Country: nl
Re: 8-bit uC - is there even a point?
« Reply #142 on: September 30, 2018, 07:23:41 am »
Quote from: westfw link=topic=141497.msg
I don't know of any 6502-like microcontrollers.
IIRC the ST7 and also STM8 have evolved from the 6502.
They use the same registers but have expanded on some, from stm8 to st7 another expanion
Quote
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.
 

Offline GeorgeOfTheJungle

  • Super Contributor
  • ***
  • !
  • Posts: 2699
  • Country: tr
Re: 8-bit uC - is there even a point?
« Reply #143 on: September 30, 2018, 07:32:41 am »
Even before cache and flash issues the interrupt overhead was already too high to bother.

https://community.arm.com/processors/b/blog/posts/beginner-guide-on-interrupt-latency-and-interrupt-latency-of-the-arm-cortex-m-processors

For comparison, here's a famous 8 bitter:

http://6502.org/tutorials/interrupts.html#a
http://6502.org/tutorials/interrupts.html#1.3

A copy-paste of a table from there (clearly biased):

1802RCA? Most instructions take 16 clocks (6.4μs), some, 24 (9.6μs).  2.5MHz @ 5V.
8080Intel? (still waiting for information)
8088Intel10 bus cycles or 40 clocks(?) (B)+(C) (still waiting for further information)
8086IntelWDC says 182 clocks max total latency. * * * * *  (still waiting for information)
Z8ZilogIRET (E) takes 16 execution cycles.  I don't know how many clock cycles per execution cycle.  8MHz?
Z80Zilog11-19 clocks (B)+(C) depending on mode, or 2.75-4.75μs @ 4MHz.  RETI (E) is 14 clocks, or 3.5μs @ 4MHz.
Z8000ZilogIRET (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.
8048Intel(?) return (E) is 2.7μs @ 11MHz
8051Dallas1.5μs @ 33MHz (52 clocks) latency
8051Intel1.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
80C51XAPhilips2.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.
KS88Samsung3μ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.
78K0NEC4.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.
COP8National70 clocks (7 instruction cycles). RETI (E) is 50 clocks (5 instruction cycles).  (7μs & 5μs @ 10MHz)
μPD78C05NECRETI (E) takes 13 or 15 clocks (2.08 or 2.4μs at 6.25MHz)
μPD70008/ANECsequence (C) takes 13 or 19 clocks.  Return (E) takes 14 clocks.
Instructions take 4-23 clocks each.  6MHz in '87 book.
V20NECRETI (E) takes 39 clocks or 3.9μs @ 10MHz in '87 book.
Instruction set is a superset of that of 8086/8088.
V25NEC?  (still waiting for information)
68000Motorola46 clocks or 2.875μs minimum @ 16MHz (B)+(C)?.  Has a very complex interrupt system.
6800Motorola(C)=13 clocks, including pushing the index register and both accumulators.  RTI (E) takes 10 clocks.  2MHz.
6809Motorola(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.
68HC05Motorola16 clocks typ (8μs @ 2MHz)
68HC08MotorolaInstructions 1-9 cy, or 0.125-1.125μs.  Avg 4-5 cy, or around 0.55μs.
68HC11Motorola(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.
68HC12Motorola2.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.
68HC16Motorola2.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.
PIC16Microchip(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.
TMS370TI15 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).
TMS7000TI(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.
ST6STM78 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.
ST7STM3μ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.
ST9STMExternal 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+STM1.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/300Hitachi8/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-51Silicon 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.
65C02WDCNormal 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!)

« Last Edit: September 30, 2018, 10:03:44 am by GeorgeOfTheJungle »
The further a society drifts from truth, the more it will hate those who speak it.
 

Offline Siwastaja

  • Super Contributor
  • ***
  • Posts: 8110
  • Country: fi
Re: 8-bit uC - is there even a point?
« Reply #144 on: September 30, 2018, 08:45:05 am »
1) Caches are a moot point. They tend to be disabled by default. Just don't enable them. I've never enabled them. Use RAM, especially core-coupled memories for fast instructions and data. Enjoy simple, predictable operation. The caches are there because some people want to use them when developing in a "non-microcontrollerish" style - for example, running a massive UI program from flash - or from an SD card - directly. The caches don't magically mess up your timings when you don't locate timing-critical code and data in cached regions.

2) Getting an STM32 blink an LED requires one (1) register write more than an AVR - 3 instead of 2: a simple enable bit on a well-documented register to turn the relevant GPIO port on. I think the same is true for most ARM microcontrollers. The difference is small: AVR has "power reduction registers" you use to turn peripherals off. STM32 has registers to enable what you need.

3) An ADC on STM32 combined with DMA, while sounding fancy, may be easier to understand for a beginner, since you write about 6-7 lines of this-makes-sense initialization code, and then just read the latest readings directly from the variables - no need to write ISRs to store values and switch analog MUXes.

4) Clock control on an STM32 is not much more complex than on AVR - but instead of calculating some strange separate things called "fuses", which can brick your system preventing reprogramming, you just simply write the config in standard C in your init function. I think this is simpler.

5) With STM32, I don't need a specific programming tool. A standard USB serial cable works.

6) I opened ARM reference manual first time after about 3 years of professional work on ARM MCUs. I have spent about 0.00001% of my time on ARM reference manual, after that. I think I have opened it twice.

7) I sometimes look at the instruction set, and sometimes need to write custom assembly. AVR instruction set is OK, but ARM is very good, simple, and easy to understand.

8 ) 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.

9) I think one of the best points in AVR or PIC is that the existing community mostly develops code in a style what I call "sane". Simple, efficient way. While you can do the same on ARM, it's not trivial because the community is so fragmented, and "everybody" seems to be using bloated ways - dozens of different code autogeneration tools, dozens of different libraries that are complex to use and fail at doing real hardware abstaction - which is understandable, since totally generic (written by others) hardware abstraction is not easy on microcontrollers.

People who have developed for AVR or PIC, often say they miss that "old" style when going ARM. What we need to tell them is: you can go on with exactly that, there's nothing wrong - ARM cores and the peripherals in a typical modern ARM MCU are not that much more complicated than on AVR! It's just that the 1000-line bloated inits autogenerated or copypasted make them look very complex. But if you choose it, you have the freedom to go on in the classical MCU style, and I strongly recommend it to anyone. The problem is, while I'm not alone, our viewpoint won't get enough exposure.

10) Previous point tldr: With AVR, every beginner has a clear and simple route to follow. On ARM MCUs, everybody's teaching different way, it's hard to know what to do, and it often looks difficult and complex - many code examples are long just to blink an LED.

11) Once more: the biggest issue I see on learning ARM MCUs is lack of simple, easy to understand, lightweight examples, and tutorials to do sane, sustainable development.

12) Finally, sometimes a cheap small 8-bitter offers exactly what you need. Use it. Especially, if you are experienced on using the PIC, and don't need the fancy-pancy stuff on current generation ARM controllers, use the 8-bitter to save time. Not everyone needs to learn every new skill. Concentrate on what you find important yourself. Be an expert on something, it hasn't to be ARM.
« Last Edit: September 30, 2018, 08:50:43 am by Siwastaja »
 
The following users thanked this post: nfmax

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 26755
  • Country: nl
    • NCT Developments
Re: 8-bit uC - is there even a point?
« Reply #145 on: September 30, 2018, 10:17:29 am »
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.
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.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 26755
  • Country: nl
    • NCT Developments
Re: 8-bit uC - is there even a point?
« Reply #146 on: September 30, 2018, 10:24:16 am »
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.
This depends on the manufacturer. NXP has an extensive section on the processor core (including instruction set) in the user manual.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline Mr. Scram

  • Super Contributor
  • ***
  • Posts: 9810
  • Country: 00
  • Display aficionado
Re: 8-bit uC - is there even a point?
« Reply #147 on: September 30, 2018, 10:40:21 am »
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.
 
The following users thanked this post: maginnovision

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 26755
  • Country: nl
    • NCT Developments
Re: 8-bit uC - is there even a point?
« Reply #148 on: September 30, 2018, 11:18:03 am »
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.
You are still idolising. If someone tells me something is extremely hard to do I already close one ear. I'm not going to get useful information from that person other than he/she can't and doesn't know people who can. I keep one ear open for clues on how not to tackle a problem but that is sketchy because maybe the approach was good but the execution was wrong.
« Last Edit: September 30, 2018, 11:30:31 am by nctnico »
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 
The following users thanked this post: Siwastaja

Offline legacy

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: 8-bit uC - is there even a point?
« Reply #149 on: September 30, 2018, 12:28:13 pm »
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.

In avionics we have constraints and ISRs pre-empt is extremely bad for us, hence strictly prohibited.
I don't want to give you a "no-go", simply a hint: I would put extra careful in abusing of this feature.

 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf