It's about exposure to syscalls, C, assembly, lower level debugging and just making sure people aren't afraid to touch that layer. Same goes with other foundational knowledge like packets and networking protocols
What I think the author is getting at with '8-bit' is that presenting children with a complete machine that is simple enough to understand from top to bottom gives a foundation that they can build on when they encounter more complex systems later on.
They are a much better target for teaching children about hardware.
One of the main benefits of teaching on 8 bit micros is they function like basic HW Harvard state machines, meaning their code execution is easily predictable and explainable form the diagrams on paper/whitrebaord, to the disassembly in the debugger in practice, as every CPU instruction takes exactly one clock cycle, there's no memory caching, no PLL and various multipliers and dividers for the 50 on-chip clock domains and IRQ tables, but they have on single clock from an external oscillator from which the CPU, RAM and FLASH memory, and all peripherals run on only that clock meaning it's easier to draw clock/signal diagrams to show "on this rising edge the CPU fetches the instruction, on the next clock edge, the ADC triggers the sampling, etc"
Secondly, 8 bit micros come in DIP packages easier to breadboard and are 5V tolerant meaning you can just hook them up to USB, and most of the times they have high current pins with Schottky diodes meaning you can have them rectify AC voltage or direct drive LEDs without transistors.
Thirdly, IMHO, 8bit ASM disassembly, like the Atmega AVR, is much easier to follow and understand in the debugger for beginners than the 32 bit ARM due to lower instruction count and simpler less powerful instructions that are always 8 bit, and less features that can confuse you like configurable IRQ tables or powerful instructions that cand do two operations at once per clock cycle for extra performance or optimized instructions that are 16 bit instead of 32 bit to save code space like the ARM Thumb.
8bit micros like the old Arduinos are far ore capable for learning and hobbyist tinkering than people give them credit for. People just needlessly fixate against them because "32 bit is bigger than 8 bit".
My $0.02.
That’s like comparing a sand castle to a hospital complex. You might want some intermediate steps in between.
Nevertheless, given a choice, I would never use those again for this purpose.
None of the traditional 8-bit CPUs (i.e. introduced before 1980) had many instructions that took exactly one clock cycle. Most of their instructions required multiple clock cycles with a number different for each instruction. Nevertheless, on many 8-bit CPUs you could guess approximately the number of clock cycles for many instructions based on the number of memory cycles needed for executing the instruction (including the cycles required for fetching the instruction code).
On the contrary, modern 32-bit microcontrollers have a majority of instructions that are executed in one clock cycle. Regarding the cache memory, the slower models with a clock frequency below 100 MHz, e.g. from 24 to 72 MHz may have no cache, and even if they have a cache, not enabling it would not make much difference.
From all that you have said I agree only with the fact that a 32-bit MCU will have usually a complex clock tree with various PLLs that must be programmed for maximum performance.
Nevertheless, besides the fact that programming the PLLs is usually needed only in a single place, at startup, it is also optional for many applications. All 32-bit MCUs that I have seen start after reboot in a safe mode using an internal RC oscillator. The speed is low, but it works. You need to program the PLLs only if you want to reach the maximum speed by using an external quartz oscillator or resonator. The 32-bit MCUs may have a large number of complex internal peripherals but at least in the beginning it is possible to ignore their existence. Only the few peripherals that are used must be enabled and configured and the MCU vendors provide example programs that can be used before learning how to modify them.
8-bit disassembly does not have a lower instruction count but it always has a much higher instruction count for doing the same task, because each 8-bit instruction does less work.
The easiest to program in assembly language are the 64-bit CPUs, because the range of 64-bit numbers is big enough to use them in most applications without worries. Already with 32-bit numbers you must be careful to avoid overflows, while with 16-bit or 8-bit numbers you must be prepared to handle overflow at each operation. So on CPUs with narrower hardware instructions and registers, you must almost always write or use a library implementing operations with wider numbers, which makes the programs more complex than for 32-bit CPUs, because only seldom you can do an addition or multiplication etc. by just using one hardware instruction.
For the 32-bit ARM CPUs all the software tools that one may need are free. For most 8-bit CPUs the tools are either proprietary or of lower quality than for the 32-bit CPUs.
There are 32-bit ARM CPUs that are soldered together with support circuits on a very small PCB with DIP pins (e.g. various models of STM32 Nucleo-32 boards), which can be inserted in DIP sockets or in solderless breadboards, so DIP is not an advantage exclusive to obsolete 8-bit CPUs.
There are many such 32-bit microcontrollers that have high-current pins that can drive directly LEDs and most cheap development boards may include buffers to provide 5-V tolerant I/O pins on the headers mounted on the board.
While for the cheapest 32-bit development boards the user interface must be done on some PC to which the development board is connected via USB, or the board may be used through a console on a serial interface or through a remote shell over Ethernet (for the boards including an Ethernet RJ-45 connector), there are more expensive boards, e.g. around $50, to which it is possible to connect a display panel directly.
It is true that I have never used an Arduino, because every time when I looked at any model it appeared overpriced and without any advantage whatsoever over a Cortex-M board, so I could not understand why would someone waste time with it.
On the other hand, the costs of learning to program a development board with Cortex-M are close to zero and the experience is much more valuable.
Arduino IDE is definitely not low quality.
>It is true that I have never used an Arduino, because every time when I looked at any model it appeared overpriced and without any advantage whatsoever over a Cortex-M board, so I could not understand why would someone waste time with it.
- Because you don't need 32 bits to turn on a LED and read an ADC.
- Because in 2008-2014 there were not many cheap Cortex M boards, and hobbyist ARM tooling was low quality or expensive (Keil, IAR, etc) and didn't come out of the box with pre-made sample projects that could get you up and running on stuff like UART, ADC, SPI, etc.
- Because Arduino coade was easily portable meaning sharing projects that drove particular displays or other external peripherals or widgets would just be copy-paste plug and play instead of having to tailor the C code you got from someone else to your particular ARM microcontroller, and configure the peripherals, clocks and keep fucking with it to get it to work like ti worked for the other person, etc.
Project portability and cross compatibility was the big selling point of the Arduino ecosystem. You didn't need to know any programming or C to get some humidity or ultrasonic senor from Adafruit to work on an Arduino, because most likely someone already published the code or library for it.
While 8-bit processors take multiple cycles per instruction, the number of cycles is usually fixed. On superscalar pipeline processors it is very difficult for the programmer to predict the performance without profiling.
Looking back at what I studied in my EE degree in the early 90s, my first introduction to assembly language and hardware was with the 6809. Then I moved on to the 68000. I am probably biased but I think starting with 8-bit then moving to a simple 32-bit architecture is a good introduction to computer hardware.
Also, I can see there is a case for using a simple modern design such as Cortex-M as a base but - as the peer comment also says - it’s really not the case that a Cortex M7 is conceptually simpler than a 8-bit design.
For most operations that can be done in one machine instruction on a 32-bit CPU like Cortex-M7 (which also includes support for floating-point numbers), you need to write a complex sequence of instructions for 8-bit CPUs like Z80, 6502 and the like, where you do not have even a multiplication instruction, much less more complex operations.
To be able to write performant programs on ancient 8-bit CPUs requires much more knowledge and experience than on modern 32-bit CPUs, because you need to implement in software many algorithms for things that are done in hardware on the modern CPUs.
Wait we’re teaching kids to write performant assembly language?
8-bit basically means ASCII when you deal with text (doesn't it ?) - how do you teach middle-schoolers that don't use a latin-based alphabet in their native tongue ??
When you encode something more complex then ascii you use 1-4 consecutive bytes, the encoding in the byte tells you if you need to look at the next.