next step learning after Arduino ?

[glenenglish]

I have a friend that has asked me, what is the next step for learning about embedded systems beyond arduino ??

My biggest gripe with Arduino is there there is no in circuit debugger.
So any other platform would need that.

I have played with ESP32, but I've found how it wants to load the whole thing into the large device, that compile / flash run times are just too long. And Ive found, IME, the debugger experience  isnt very good. (maybe I am doing it wrong)

SO what's the next step that has friendly, not too complex tools, but has a real debugger and visibility of CPU registers, peripheral registers, memory  etc?

IE somewhere between  Arduino , and AVR with the awful microchip debugger. actually its not that awful from an experienced POV.
IE a debugger and IDE without millions of options and setup parameters that means if you get one bespoke thing wrong it doesnt work. like Eclipse....
-glen

[Smokey]

Start with a dev board and example programs that do things you are interested in.

I would recommend STM32 Nucleo.  All the debugging stuff is built into the dev boards so you don't need to buy an expensive programmer/debugger.  Wide variety of boards that do various things.  If you want to do motor control, get the motor control one.  Want to do LCD interfacing, get that one.  And they are pretty inexpensive.  This is a "Real Embedded" system. 

Get set up with the manufacturer tools.  STMCubeIDE and the HAL, for all the complaining around here, is a pretty good platform.  Especially for learning all the stuff you mentioned.  You can use it at any level you want: RTOS to bare metal.  Plus it is maintained by a real company and not just a bunch of random dudes on the internet.

One thing to keep in mind when selecting a platform like this.  People tend to "stick to what they know".  So pick something with enough variety that you can comfortably live in that ecosystem and expand into new projects.   STM works for that as well.

[nctnico]

I'd say any microcontroller with an ARM-Cortex core will do combined with Eclipse or VS Code. For example: ST's CubeIDE (Eclipse based) debugging does work with ST's evaluation boards with integrated programmer / debugging. Although I'm not a fan of STM32 devices due to crappy documentation, finicky peripherals and their bloated and horrible HAL which just gets in the way. So far I've found NXP's LPC series ARM Cortex devices much nicer to work with. Really good documentation plus consistent peripherals across the entire line. In about 20 years, I never needed a debugger to write software for those microcontrollers so I can't comment on debugging.

[Psi]

The next step after arduino is, I think, still using arduino but leaning how to use the MCU hardware registers to do stuff instead of using
the Arduino helper functions which hide that stuff from you.  Read the datasheet, understand the registers and use them to do stuff.

Like try the following without using any arduino functions, just registers
- Try setup an IO as output and toggle it without using digitalwrite()
- Try flipping one bit of a IO port without affecting other bits/pins on that port, and understand why the code works to do that.
- Try enable PWM on an pin that has a hardware PWM channel by reading datasheet and setting the hardware registers.
- Try setup your own interrupts for something, enable them yourself, set flags bits etc..

I think it's good to get an understanding of that before moving to an entirely different MCU/IDE.

[Smokey]

The next step after arduino is, I think, still using arduino but leaning how to use the MCU hardware registers to do stuff instead of using
the Arduino helper functions which hide that stuff from you.  Read the datasheet, understand the registers and use them to do stuff.

Like try the following without using any arduino functions, just registers
- Try setup an IO as output and toggle it without using digitalwrite()
- Try flipping one bit of a IO port without affecting other bits/pins on that port
- Try enable PWM on an pin that has a hardware PWM channel by reading datasheet and setting the hardware registers.duty_cycle)
- Try setup your own interrupts for something, enable them yourself, set flags bits etc..

I think it's good to get an understanding of that before moving to an entirely different MCU/IDE.

In general yes.  You can use the Arduino hardware without any of the Arduino software stuff.  The problem with this is that a lot of those boards were never designed to easily use a real debugger.  Plus depending on which Arduinos you are using, the Atmel (yes I know they are microchip now) might not be a great choice for starting a project from scratch. 

Adruino world shields you from essentially anything embedded (peripheral config/interfacing, memory, timing, interrupts...) so "knowing Adruinos" doesn't really translate to "knowing AVRs". 

[Psi]

Learning to use a debugger is definitely something you need to learn at some point.
But I'm not sure it really matters when you learn it.
And it only takes an hour to figure out the basics assuming you have it setup and installed correctly and it's working.

You can divide programmers into two groups.
Those who use the debugger many times a day and those who might use it once every few months when they can't figure something out and it becomes the last resort.

It's the absolute worst when you have a bug that doesn't occur when you enable the debugger.

[MasterT]

You can use serial monitor to read/write registers on atmega328. No debugger required.
I switched to stm32 nucleo boards awhile ago, but continue to enjoy arduino IDE and do low level debugging over serial, registers, set / reset bits, change clock etc. 

Code: [Select]

/*
  TO DO
*/


         String       in_String         =     "";       
         boolean      end_input         =  false; 
         uint16_t      adres_reg         =      0;         
         uint8_t      debug_osm         =      0;

void setup()
{
  Serial.begin(115200);
  in_String.reserve(200);

  Serial.print(F("\n\tSketch: Reg_base_UNO"));

  Serial.print(F("\n\tSetup done."));
}

void loop()
{
  int32_t  tempr = 0;
  char *   pEnd;


 
// d, a, r, w - (a)ddress variable length.

/* 
  q, *w,  e, *r,  t,  y,  u,  i,  o,  p,
 *a,  s, *d,  f,  g,  h,  j,  k,  l,
  z,  x,  c,  v,  b,  n,  m,   
*/
 
  if(debug_osm) {
    }

  serialEvent();

  if( end_input) {
    char cmd = in_String[0];
    in_String[0] = '+';
   
    if( cmd == 'd' ) {
      debug_osm = 1 - debug_osm;
      if(debug_osm) Serial.print(F("\nDebug aktiv."));
      else          Serial.print(F("\nDebug de-aktiv."));
      }
       
    if( cmd == 'a' ) {
      adres_reg = strtol( in_String.c_str(), &pEnd, 16);
      Serial.print(F("\n\tReg: "));
      Serial.print(adres_reg, HEX);
      Serial.print(F("\tvalue: "));
      tempr =   (*(uint8_t*)adres_reg);
      Serial.print(tempr, BIN);
      }
    if( cmd == 'r' ) {
      Serial.print(F("\n\tReg: "));
      Serial.print(adres_reg, HEX);
      Serial.print(F("\tvalue: "));
      tempr =   (*(uint8_t*)adres_reg);
      Serial.print(tempr, BIN);
      }
    if( cmd == 'w' ) {
      Serial.print(F("\n\tReg: "));
      Serial.print(adres_reg, HEX);
      Serial.print(F("\tvalue: "));
      tempr =   (*(uint8_t*)adres_reg);
      Serial.print(tempr, BIN);
      tempr = strtol( in_String.c_str(), &pEnd, 2);     
      (*(uint8_t*)adres_reg) = tempr;
      Serial.print(F("\tnew  value: "));
      tempr =   (*(uint8_t*)adres_reg);
      Serial.print( tempr, BIN);     
      }
               
    in_String = "";
    end_input= false;
  }

}

void serialEvent() {
  while (Serial.available()) {
    char inChar = (char)Serial.read();
    in_String += inChar;
    if (inChar == '\n') {
      end_input= true;
    }
  }
}

// Address Book:
/*
  page 536:
 
  0x0B (0x2B) PORTD PORTD7 PORTD6 PORTD5 PORTD4 PORTD3 PORTD2 PORTD1 PORTD0 95
  0x0A (0x2A) DDRD DDD7 DDD6 DDD5 DDD4 DDD3 DDD2 DDD1 DDD0 95
  0x09 (0x29) PIND PIND7 PIND6 PIND5 PIND4 PIND3 PIND2 PIND1 PIND0 95
  0x08 (0x28) PORTC – PORTC6 PORTC5 PORTC4 PORTC3 PORTC2 PORTC1 PORTC0 94
  0x07 (0x27) DDRC – DDC6 DDC5 DDC4 DDC3 DDC2 DDC1 DDC0 94
  0x06 (0x26) PINC – PINC6 PINC5 PINC4 PINC3 PINC2 PINC1 PINC0 94
  0x05 (0x25) PORTB PORTB7 PORTB6 PORTB5 PORTB4 PORTB3 PORTB2 PORTB1 PORTB0 94
  0x04 (0x24) DDRB DDB7 DDB6 DDB5 DDB4 DDB3 DDB2 DDB1 DDB0 94
  0x03 (0x23) PINB PINB7 PINB6 PINB5 PINB4 PINB3 PINB2 PINB1 PINB0 94


// PORTS********************
#define PINB _SFR_IO8(0x03)
#define DDRB _SFR_IO8(0x04)
#define PORTB _SFR_IO8(0x05)

#define PINC _SFR_IO8(0x06)
#define DDRC _SFR_IO8(0x07)
#define PORTC _SFR_IO8(0x08)

#define PIND _SFR_IO8(0x09)
#define DDRD _SFR_IO8(0x0A)
#define PORTD _SFR_IO8(0x0B)

// COMPARATOR***************
#define ACSR _SFR_IO8(0x30)
#define ACIS0 0
#define ACIS1 1
#define ACIC 2
#define ACIE 3
#define ACI 4
#define ACO 5
#define ACBG 6
#define ACD 7

// ADC**********************
#define ADC     _SFR_MEM16(0x78)
#define ADCW    _SFR_MEM16(0x78)
#define ADCL _SFR_MEM8(0x78)
#define ADCH _SFR_MEM8(0x79)

#define ADCSRA _SFR_MEM8(0x7A)
#define ADPS0 0
#define ADPS1 1
#define ADPS2 2
#define ADIE 3
#define ADIF 4
#define ADATE 5
#define ADSC 6
#define ADEN 7

#define ADCSRB _SFR_MEM8(0x7B)
#define ADTS0 0
#define ADTS1 1
#define ADTS2 2
#define ACME 6

#define ADMUX _SFR_MEM8(0x7C)
#define MUX0 0
#define MUX1 1
#define MUX2 2
#define MUX3 3
#define ADLAR 5
#define REFS0 6
#define REFS1 7

#define DIDR0 _SFR_MEM8(0x7E)
#define DIDR1 _SFR_MEM8(0x7F)


// TIMERS*******************
#define TIFR0 _SFR_IO8(0x15)
#define TOV0 0
#define OCF0A 1
#define OCF0B 2

#define TIFR1 _SFR_IO8(0x16)
#define TOV1 0
#define OCF1A 1
#define OCF1B 2
#define ICF1 5

#define TIFR2 _SFR_IO8(0x17)
#define TOV2 0
#define OCF2A 1
#define OCF2B 2

#define GTCCR _SFR_IO8(0x23)
#define PSRSYNC 0
#define PSRASY 1
#define TSM 7

#define TCCR0A _SFR_IO8(0x24)
#define WGM00 0
#define WGM01 1
#define COM0B0 4
#define COM0B1 5
#define COM0A0 6
#define COM0A1 7

#define TCCR0B _SFR_IO8(0x25)
#define CS00 0
#define CS01 1
#define CS02 2
#define WGM02 3
#define FOC0B 6
#define FOC0A 7

#define TCNT0 _SFR_IO8(0x26)
#define OCR0A _SFR_IO8(0x27)
#define OCR0B _SFR_IO8(0x28)

#define TIMSK0 _SFR_MEM8(0x6E)
#define TOIE0 0
#define OCIE0A 1
#define OCIE0B 2

#define TIMSK1 _SFR_MEM8(0x6F)
#define TOIE1 0
#define OCIE1A 1
#define OCIE1B 2
#define ICIE1 5

#define TIMSK2 _SFR_MEM8(0x70)
#define TOIE2 0
#define OCIE2A 1
#define OCIE2B 2

#define TCCR1A _SFR_MEM8(0x80)
#define WGM10 0
#define WGM11 1
#define COM1B0 4
#define COM1B1 5
#define COM1A0 6
#define COM1A1 7

#define TCCR1B _SFR_MEM8(0x81)
#define CS10 0
#define CS11 1
#define CS12 2
#define WGM12 3
#define WGM13 4
#define ICES1 6
#define ICNC1 7

#define TCCR1C _SFR_MEM8(0x82)
#define FOC1B 6
#define FOC1A 7

#define TCNT1 _SFR_MEM16(0x84)
#define TCNT1L _SFR_MEM8(0x84)
#define TCNT1H _SFR_MEM8(0x85)
#define ICR1 _SFR_MEM16(0x86)
#define ICR1L _SFR_MEM8(0x86)
#define ICR1H _SFR_MEM8(0x87)
#define OCR1A _SFR_MEM16(0x88)
#define OCR1AL _SFR_MEM8(0x88)
#define OCR1AH _SFR_MEM8(0x89)
#define OCR1B _SFR_MEM16(0x8A)
#define OCR1BL _SFR_MEM8(0x8A)
#define OCR1BH _SFR_MEM8(0x8B)
#define TCCR2A _SFR_MEM8(0xB0)
#define WGM20 0
#define WGM21 1
#define COM2B0 4
#define COM2B1 5
#define COM2A0 6
#define COM2A1 7

#define TCCR2B _SFR_MEM8(0xB1)
#define CS20 0
#define CS21 1
#define CS22 2
#define WGM22 3
#define FOC2B 6
#define FOC2A 7

#define TCNT2 _SFR_MEM8(0xB2)
#define OCR2A _SFR_MEM8(0xB3)
#define OCR2B _SFR_MEM8(0xB4)
#define ASSR _SFR_MEM8(0xB6)
#define TCR2BUB 0
#define TCR2AUB 1
#define OCR2BUB 2
#define OCR2AUB 3
#define TCN2UB 4
#define AS2 5
#define EXCLK 6


#define TIMER2_COMPA_vect_num 7
#define TIMER2_COMPA_vect _VECTOR(7)   

#define TIMER2_COMPB_vect_num 8
#define TIMER2_COMPB_vect _VECTOR(8)   

#define TIMER2_OVF_vect_num   9
#define TIMER2_OVF_vect   _VECTOR(9)   

#define TIMER1_CAPT_vect_num  10
#define TIMER1_CAPT_vect  _VECTOR(10) 

#define TIMER1_COMPA_vect_num 11
#define TIMER1_COMPA_vect _VECTOR(11) 

#define TIMER1_COMPB_vect_num 12
#define TIMER1_COMPB_vect _VECTOR(12) 

#define TIMER1_OVF_vect_num   13
#define TIMER1_OVF_vect   _VECTOR(13) 

#define TIMER0_COMPA_vect_num 14
#define TIMER0_COMPA_vect _VECTOR(14) 

#define TIMER0_COMPB_vect_num 15
#define TIMER0_COMPB_vect _VECTOR(15) 

#define TIMER0_OVF_vect_num  16
#define TIMER0_OVF_vect   _VECTOR(16) 

#define ADC_vect_num      21
#define ADC_vect          _VECTOR(21) 

#define ANALOG_COMP_vect_num  23
#define ANALOG_COMP_vect  _VECTOR(23) 
*/

//**//




[glenenglish]

....yeah but serial line debugging in arduino is not  non-intrusive, there are side effects.

Thanks all the for the comments. Keep them rolling.

Good ideas of controlling AVR peripherals directly as an intermediate step.  There seems to be a big gulf between Arduino  and STM cube etc. 
I cant imagine not using a debugger. That is something from the 1980s.....I see people employed as pros in companies stuck on bugs  and they just guess what is going on and seem resistant to using a debugger, what a time waste....

It's the absolute worst when you have a bug that doesn't occur when you enable the debugger

THose sort of things are usually startup side effects. Starting in the debugger is ooften different. Depends on the platform.

[brucehoult]

....yeah but serial line debugging in arduino is not  non-intrusive, there are side effects.

Thanks all the for the comments. Keep them rolling.

You could step from the ATMega328 to something that supports both the Arduino library (and IDE) and also proper debugging. For example Arm or RISC-V.

My sentimental favourite at the moment is the CH32V003. It works on either 3.3V or 5V, is 32 bit, has a similar amount of resources to an ATMega328 (both have 2k RAM, the '003 has 16k of flash vs 32k on the AVR, but also generally more compact code using fewer instructions, especially if using 16 or 32 bit variables. It also runs at 48 MHz instead of 16-20 MHz, and executes 4 bytes of code per two cycles (two 2-byte instructions or one 4-byte instruction) at that speed. Or one instruction per cycle at 24 MHz. It's also not that much more complex than the AVR at the register level and is well documented -- and had a pretty big community around it too. The chips cost $0.10 to $0.16 depending on the pin count (8, 16, 20) if you buy 50 of them (i.e. $5 - $8 total). The official dev board comes with a USB programmer / serial / debug and 5 bare 20 pin chips for $7.23.

https://www.aliexpress.us/item/3256804709476544.html

You can find 3rd party boards as low as ... well, I see now one for $0.58, five boards for $2.90:

https://www.aliexpress.us/item/3256807122251439.html

Olimex are advertising a board for €1.00 to ship soon, with an Apple I "Wozmon" style monitor program in flash, and a bit-banged VGA output and PS/2 keyboard support, all from an 8 pin chip!

https://www.olimex.com/Products/Retro-Computers/RVPC/open-source-hardware

Of course you can re-flash with your own code, modify theirs etc.

People are doing all kinds of fun projects with the CH32V003 e.g.





And of course they have bigger cousins with more RAM and flash, more pins, native USB and other interfaces etc.

[glenenglish]

Hi Bruce

Something that is a bit more interesting  than a dev board with a header is a good idea.  Like the pics you posted.

That's what I will recommend my friend do, his son is proficient with usual Arduino things shields etc, so this is a reasonable next step, and it's a step into knowing any embedded system,  IE the skills u get will be good for all micros onwards.

cheers

You are right about AVR producing lots of code (compared to a 32 bit micro)  with 32 bit values, just like when you shift right by three etc.

[ralphrmartin]

A different take on your friend's question is, rather than learning to use a debugger or about registers etc, get to grips with an RTOS, e.g. FreeRTOS, and how to use it for multitasking.
That does not necessarily need to go beyond Arduino, but it is beyond the usual basic Arduino stuff.
There's a decent book out there called "FreeRTOS for ESP32-Arduino" which should help.

[artag]

I think ralphmartin makes a really good point.

Don't go tying yourself to an IDE - they're mostly awful in one way or another and tend to force their particular way of working on you. Arduino is very limited but also lightweight. Some people like VSCode, I personally hate it and I think it has severe disadvantages for professional (ie something that has to be maintained by someone else) use. But understanding a bigger concept like an RTOS is growing your ability, not just learning a new tool.

Another possibility is digging deeper by writing or rewriting device drivers. The Arduino ones are generally a bit limited and slow - they're trying to make things appear the same, for easy learning. The STM Cube have a similar aim - they want to make it easy for users to migrate across ST products but have little interest in portability beyond that and seem to give no thought to performance. This is not a good model for the budding embedded engineer. They're after low effort to maintain by using common code as far as possible. I would say comparing the arduino drivers for very different hardware such as AVR and ESP32 might be interesting (though I haven't investigated their ESP321 code).

 

[glenenglish]

good take on the concept of learning RTOS, multitasking. lots of new disclipines to learn there. I mean there is a full bottle of stuff to learn with multitasking and multi threading.

I hate VS code. I find it maddening. it's pretty  and seems to do alot but seems to be alot of secret background stuff going on in scripting, which I get  is the advantage of it, but I dont like it.

Alright, I think I have enough to go on, The still seems to be a big gap between Arduino and say STM cube.
I'll also thing about how I would teach this, as I do a bit of informal teaching, that might lead me to a coherent path.

One thing that I like when there is enough RAM available, is reconfiguring the linker script to run the code from RAM. This substantially reduces the usual   flash program/restart cycles.
Another thing to look at is QEMU, on a high level platform. But eventually, you need the student  to come to grips with real hardware and have him/her realise the importance of embedded hardware working like it should,  like for example, the student's project , in the extreme case, firing the ejection seat, or jettesoning the service module.   That's putting your c0ck on the bl0ck.  There are parallels to this in other industries- in airplane maintenance, or building aircraft electronics I get to feel a bit of this with stuff I do.

[PlainName]

I cant imagine not using a debugger. That is something from the 1980s.....I see people employed as pros in companies stuck on bugs  and they just guess what is going on and seem resistant to using a debugger, what a time waste....

Actually, not using a debugger is a critical ability. You need to be able to solve problems to really get anywhere, and although a debugger makes some parts of that process easy it is not the solution. Often, something weird happens and you have no idea where the problem might be, so how is the debugger going to help? You can't single-step the entire code, and if you do single-step the chances are the issue may not occur. You're not going to have interrupt interactions timing properly, and anything that relies on timing (perhaps bit-bashing a port) will be stuffed.

No, what you need to do is figure out what the problem is before you set about dealing with it. When the weird thing happens you think about it, what could possibly be related. As other things occur you add them to your mental list of clues, much like you might fill in pieces of a jigsaw. Eventually you'll have enough clues to determine that it's probably so-and-so that's causing the problem, and at that point - where you want to test that hypothesis - you 'do' the debugging, which might be to use an LED, console output or, indeed, the debugger.

The debugger is might be seen as the Arduino of problem solving.

Don't get me wrong - I like a good debugger as much as the next developer, but it's not the end of the world if it's not there. There are many reasons to discard a particular chip as unsuitable for a job, but lack of a debugger is quite a way down the list.

[glenenglish]

agreed on not using a debugger is a required skill. That is  really good point .
I would consider that skill to be after proficiency of source level debugging.

There's really two situations

1) code not functioning because you wrote it wrong- Source level debugger is a huge  time saver. That's what I see missing from Arduino.

2) cannot use a debugger  because any stop/start of the platform would change the timing with hardware or other processes that your program is interacting with.  That's where it is essential to learn  various tools and methods to solve those ones.
These situations are usually tricky and require experience to troubleshoot.
 
The list of (2) is many !  In the simplist terms- interaction with timers, controlling something external that does not stop when you stop the source code execution

------------------------------------------------------
Remember the old days before jtag etc. We used to toggle pins to see where we were  in the program, hooked up to  a 2 channel scope  or logic probe, or if you were lucky, a 8 or 16 channel logic analyser.  Then when we got hardware uarts, we could send a single character to a uart to inform where we were without side effects. Then when there was a bit more memory (maybe 128 bytes..) a push button could interrupt and halt / terminate  and send to a uart a small trace dump out of memory to uart or a bit-bashed  uart to a teleprinter in 5 bit baudot....

[glenenglish]

WHICH brings me to a question... 
on an embedded platform -

Which do you teach first :

source level debugging OR non-intrusive hardware based debugging   ?

[PlainName]

What do you mean by non-intrusive hardware-based debugging?

[Postal2]

He means the standard method, when a trap (infinite loop) is used at a fixed address, and then an oscilloscope on external memory can be seen which address. This is a well-known common method.

[PlainName]

That's hardly non-intrusive. In fact, hard to think of anything more so!

[tggzzz]

WHICH brings me to a question... 
on an embedded platform -

Which do you teach first :

source level debugging OR non-intrusive hardware based debugging   ?

There are two useful answers:

• µ/mu
• yes

[nctnico]

WHICH brings me to a question... 
on an embedded platform -

Which do you teach first :

source level debugging OR non-intrusive hardware based debugging   ?

First thing to teach is to write code step-by-step (incremental going through short coding & testing cycles). Make code testable. Having a serial port CLI is extremely handy for this because you can query the state of modules, print debug output and control low-level hardware. This is not only handy during development but also when a device is installed in the field. A field service engineer only needs a serial port and a terminal emulator to diagnose & service the product.

However, algorithms which do not need to deal with hardware are not to be debugged on a microcontroller but tested on a PC where debugging is infinitely easier and algorithms can be unit / stress tested in a short amount of time.

[tggzzz]

agreed on not using a debugger is a required skill. That is  really good point .
I would consider that skill to be after proficiency of source level debugging.

There's really two situations

1) code not functioning because you wrote it wrong- Source level debugger is a huge  time saver. That's what I see missing from Arduino.

2) cannot use a debugger  because any stop/start of the platform would change the timing with hardware or other processes that your program is interacting with.  That's where it is essential to learn  various tools and methods to solve those ones.
These situations are usually tricky and require experience to troubleshoot.
 
The list of (2) is many !  In the simplist terms- interaction with timers, controlling something external that does not stop when you stop the source code execution

------------------------------------------------------
Remember the old days before jtag etc. We used to toggle pins to see where we were  in the program, hooked up to  a 2 channel scope  or logic probe, or if you were lucky, a 8 or 16 channel logic analyser.  Then when we got hardware uarts, we could send a single character to a uart to inform where we were without side effects. Then when there was a bit more memory (maybe 128 bytes..) a push button could interrupt and halt / terminate  and send to a uart a small trace dump out of memory to uart or a bit-bashed  uart to a teleprinter in 5 bit baudot....

Remember ICE? Used up until at least the 68020 era

[tggzzz]

...
code not functioning because you wrote it wrong- Source level debugger is a huge  time saver.
...

Fails on C/C++ code with higher levels of optimisation, where the instruction sequences can't be unambiguously mapped to source code statements.

[glenenglish]

He means the standard method, when a trap (infinite loop) is used at a fixed address, and then an oscilloscope on external memory can be seen which address. This is a well-known common method.

ahh no, not quite.
I meant where the code toggles or pulses an IO pin as it enters or leaves or goes past a line of code. Non intrusive. When you get to FPGAs this becomes essential...like it was in the 70s and 80s. because even with Xilinx Chipscope, adding logic to the design can change timing.

As for true ICE, I could never afford those as a hobbyist / school age kid.  They were not cheap, as I remember.

thanks for the responses. Gives me some ideas, perspectives that are not my own are useful to me.

[tggzzz]

A different take on your friend's question is, rather than learning to use a debugger or about registers etc, get to grips with an RTOS, e.g. FreeRTOS, and how to use it for multitasking.

And then progress to software architectures that don't have/need an RTOS.

Then realise that in future highly parallel systems the RTOS can be beneficially implemented in hardware. After all, if you have many cores, you don't need to multiplex multiple processes[1] onto a single core.

But with a single or multicore processor, you still need communication between processes.

[1] No, not the operating system concept of a process; that's unnecessarily far from the specification/hardware concept of a process