next step learning after Arduino ?

[Postal2]

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

Try to think about a red lamp into the loop.

....pulses an IO pin ....

Ok.

[tggzzz]

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

I used various ICE systems in the 80s. They weren't cheap and their capabilities have be supplanted by JTAG plus competent hardware monitoring.

Distressingly little has changed since the 80s, apart from things being smaller/faster/cheaper. We need better.

[artag]

• µ/mu
• yes

I'm inclined to agree with this. It's an incomplete question. There are many other factors to consider when choosing debug method.
However, given that you stated embedded, I would say non-intrusive is far more important. Much embedded code is time-sensitive and stepping or breakpointing through it is impossible. It has to keep running at full speed (and don't expect to be able to do too many printf()s either).

[Psi]

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

Normally the people who don't use a debugger still do do debugging, just not using the hardware debugger. They watch the code execute in other ways. Usually UART messages that dump out variables as required, or set/clear/toggle pins that they capture and watch on a scope/LA. You can have a pretty advanced debugging system running in real-time with your code. The downside is the loss in execution speed.

The reason some people learned to avoid the HW debugger usually stems from being burnt by it too many times.
Some debuggers are terrible buggy pieces of shit that crash often and occasionally lie to you, which is something you really don't want in a debugging system.  Obviously not all debugger are like that and they have gotten so much better in the last 30 years.
But in your formative years learning to code if the debugger enrages you one too many times you tend to swear off it forever.
Everyone has their breaking point

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 often different. Depends on the platform.

Bugs where you're accidently overwriting memory cause this often.
As soon as you use the debugger things move around in memory and the data being overwritten is now something else. So the bug you're focusing on disappears and a new bug is created somewhere else.


And of cause there's the issue with hardware debugging where you don't have enough flash space to compile your code without optimizations enabled, making the debugger pretty annoying to use. Debugging with UART messages does not have this issue.

[artag]

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

Leading on to those lovely bugs that disappear when you turn optimisation off so your debugger can work properly.

[Psi]

Even when you compile with optimizations disabled, executing with the debugger running still messes with things and can lead to different results when you look at the code in question with the debugger vs just letting it run.

[Postal2]

Is the Intel processor an mcu? He has a debug-port. Is it necessary to debug the mentioned Arduino in the same way as an Intel processor? What difficulties can we talk about in a two-line program?

[nctnico]

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

Normally the people who don't use a debugger still do do debugging, just not using the hardware debugger. They watch the code execute in other ways. Usually UART messages that dump out variables as required, or set/clear/toggle pins that they capture and watch on a scope/LA. You can have a pretty advanced debugging system running in real-time with your code. The downside is the loss in execution speed.

The reason some people learned to avoid the HW debugger usually stems from being burnt by it too many times.
Some debuggers are terrible buggy pieces of shit that crash often and occasionally lie to you, which is something you really don't want in a debugging system.  Obviously not all debugger are like that and they have gotten so much better in the last 30 years.

Many, but not all have improved. Getting the debugger going on the ESP32 is typically a waste of time. STM32 can be finicky as well (using the official debugger from ST).

[Postal2]

I'm guessing that if all the code is under control of one person, then a hardware debugger is redundant. And if a person boasts that he uses excessive tools in his simple work, this does not speak in his favor.

[glenenglish]

I dont see what the distinction of 'hardware debugger" is

there is roughly three levels in mebedded world :

1) You have source level jtag  or debug wire etc based debuggers (set breakpoints, hit points , stepping etc, with memory  dumps/mods)
2) a slight enhancement there these days with register and peripheral viewing  and modification included in the above.
3) Then, you have  lets call it 'pin level debugging' - set / toggle IO pins. dump one character into the UART  etc

I do not consider anythign with printf()  in it to be non intrusive, because a) printf is heavy and b) the processor uses effort to get that buffer out, and if the buffer is full, you stall until the uart gets some chars out. That's intrusive.

[Postal2]

.... (set breakpoints, hit points , stepping etc, with memory  dumps/mods) ....

This is necessary in school and in the case of a project developed by many people.
If you are making a "blink" program using a debugger.....

[brucehoult]

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.

Yes. Interactive debugging is mostly for beginners who don't understand the basics of how a CPU and programs work.

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.

This basically NEVER happens to me, for many decades.

It's not because I don't make mistakes. It's because I don't write 1000 lines of code in a frenzy and then try to "debug" it. I write 5 or 10 lines of code, and then test it. If it breaks then I already know, ±5 lines of code, where the problem is.

If I'm working on a tricky algorithm then I develop it on a real computer, where I can run billions of test cases quickly, or generate tens of GB of debug printf output and then write little Perl scripts to look for problems. Or, in the worst case, use a source debugger, but a printf or assert between every single line of code is better than single-stepping or even setting breakpoints in a debugger. See "Perl", above. Sanity checks written in the code run at the speed of code. Conditional breakpoints in a debugger run a million times slower. OK, maybe a thousand.

Single-stepping didn't make sense on a CPU running 400k instruction per second in the 1970s, it sure as heck doesn't make sense on a modern microcontroller running 20 or 30 million instructions per second, let alone on a PC running 10 BILLION instructions per second, per core.

The only exception is if you're so fresh you don't yet understand CPU instructions, registers, PC, stack, loops, function calls etc.

If I'm working on something that can only be done on the real hardware -- setting up GPIO, or input and output from a UART, or some SPI or i2c communication -- then I write and test ONLY THAT.

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

In the mid 2000s I was writing effectively embedded software on pre iOS/Android phones running the BREW operating system. There was no memory protection, no debugging. Not even a serial console. What you could do was draw something on the screen, maybe up in a corner to not interfere too much with using the app, or log printfs to a file in the onboard flash (which was never very large). And even with logging, when the program crashed you lost the last flash sector of printfs unless you closed the file and re-opened for append every time which is very very slow because you're writing a complete flash sector every time.

Fun times.

But we got the product (AlcheMo Java to native Arm AoT compiler) out and it was extremely solid.

[Postal2]

I can only say one thing - not a single problem found recently, including those described by me here, can be detected by debugging tools.

[glenenglish]

what like a single event upset  changing a condition code bit in the ALU ?

[glenenglish]

well, I think single steppng, register inspection, etc   is enormously useful. Yes sure, develop the algorithm on a high level device first if you want.

[Psi]

I dont see what the distinction of 'hardware debugger" is

If you are using debugging silicon inside the chip then it's a hardware debugger.
If not, then it's a software debugger

[PlainName]

well, I think single steppng, register inspection, etc  is enormously useful

Yes, it can be. I think the point is that it's not the end of the world if it doesn't exist - there are other techniques that usefully substitute, albeit they may be more tedious to use, and learning those ultimately leads to a more useful toolbox. Also, on-chip source level debugging isn't the solution for every problem.

However, you don't bake a cake without breaking eggs, as they say, and it helps to walk before you run. There is a school of thought that you should be au fait with the hard stuff - times tables, say - before being rewarded with the cool tools - a calculator. But it depends on what the aim of the game is, and you aren't here to learn how to debug but to get down and dirty with the processor.

I would second the idea of getting an STM32 dev board, which is ready to go and has the on-chip debugging embedded and just gagging for a USB cable. You don't have to use the Cube IDE or libraries, but doing so is kind of halfway between the Arduino stuff and nothing at all. The hardest decision would likely be what to do with it - some target to work towards is useful.

[nctnico]

well, I think single steppng, register inspection, etc   is enormously useful.

It is not. The reason is that you'll also need to know what each bit and/or instruction means. There is no use in looking at a bundle of data and franticly going through documentation which describes each bit and/or instruction. Errors are easely made. A much better way is to simply print the data as text where the meaning of bits is translated into a human readable form. People don't program in assembly nowadays and scripted languages are also being used increasingly.

[tggzzz]

I do not consider anythign with printf()  in it to be non intrusive, because a) printf is heavy and b) the processor uses effort to get that buffer out, and if the buffer is full, you stall until the uart gets some chars out. That's intrusive.

Not necessarily: it depends on the hardware and software architecture.

I have used printf/scanf over USB to allow a PC to control an instrument. The instrument was operating in hard realtime, using software to count edges in two 62.5Mb/s serial bitstreams, plus front-panel i/o. Counting the edges took 99% of a processor's cycles; edges were never missed - proven by design and demonstrated by testing.

[brucehoult]

People don't program in assembly nowadays

I am, at this very moment (or I was 2 minutes ago), programming in assembly language, and am in fact writing an interpreter for a different assembly language (ok, machine code) that I'm making up as I go along, with the intention of being the most compact and hopefully fastest executing (non JIT) bytecode with the smallest interpreter ever made. Some combination of those -- but hopefully all. Well, we shall see how that works out :-)

Targeting RV32EC with 2k RAM and with a REPL. Inspired by Transputer, SWEET16, and others.

I claim that I am "people", though perhaps a weird one.

[pardo-bsso]

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.

How would that work?
(I'm assuming the program won't survive a powercycle)

[tggzzz]

I am, at this very moment (or I was 2 minutes ago), programming in assembly language, and am in fact writing an interpreter for a different assembly language (ok, machine code) that I'm making up as I go along, with the intention of being the most compact and hopefully fastest executing (non JIT) bytecode with the smallest interpreter ever made. Some combination of those -- but hopefully all. Well, we shall see how that works out :-)

Targeting RV32EC with 2k RAM and with a REPL. Inspired by Transputer, SWEET16, and others.

I claim that I am "people", though perhaps a weird one.

Weirdness, on its own, is neither good nor bad

XMOS have a RISC-V processor now. Use a mailinator email address (ugh!) to download the whitepaper from https://www.xmos.com/using-risc-v-to-define-socs-in-software/

XMOS xcore ® processors are highly flexible like an FPGA and can target complex and highly varied designs. Unlike an FPGA, this is all expressed in software.
...
For its latest generation of xcore, XMOS has adopted compatibility with the RISC-V architecture. The centrepiece of all XMOS processors is that the system is programmed using a collection of hardware threads. Individual parts of the system are programmed using one or more threads each, and all threads are composited together into a single system that implements the full embedded system. With the adoption of RISC-V, these threads become RISC-V HARTs; which stands for “HARdware Threads”. Each HART can be seen as its own individual execution engine that is running in parallel with all the other HARTs.
..
The core instruction set is RV32IM: a 32-bit RISC-V with 31 registers per HART, and the M extension for multiplies and divisions.
...
The architecture underneath the threads guarantees that each HART issues an instruction every thread-cycle. Threads follow each other through a shared pipeline, so with eight active threads, an instruction will be issued every eight clock cycle. When clocked at 600 MHz, that guarantees an issue rate of 75 MHz for each HART. Because of this guarantee, each HART can be programmed independently, tested independently, and have its real-time properties characterised and “signed-off” independently. Based on this foundation, software can be composited together simply by running different real-time functions on different HARTs.

That gives you 16 Transputers I presume, but can't be bothered to check, you can run xC on them - which would give you Occam No reason you couldn't implement your interpreter in that processor, and invoke the appropriate comms mechanisms

Sounds fun!

[glenenglish]

How would that work? (I'm assuming the program won't survive a powercycle)

There does not need to be a power cycle. The debugger loads the program into SRAM and executes from there. Flash memory isnt used in that case  (some processors cannot execute from RAM, that's true also, and some have limitations on where the interrupt vectors can go so you might need to nail down some things) .
Most STM32 can do this .  at 1 MHz JTAG clock you can load up 100kbytes of code  in about 1 second and its ready by the time you blink, rather than an incremental/segment partial flash erase and reprogram which takes a few seconds.

[glenenglish]

well, I think single steppng, register inspection, etc   is enormously useful.

It is not. The reason is that you'll also need to know what each bit and/or instruction means. There is no use in looking at a bundle of data and franticly going through documentation which describes each bit and/or instruction. Errors are easely made. A much better way is to simply print the data as text where the meaning of bits is translated into a human readable form. People don't program in assembly nowadays and scripted languages are also being used increasingly.

Not if you use a modern debugger that permits single stepping of source code, or single stepping of the disassembly, wih modification of registers and CC while the CPU is halted......  there's no need to remember the bits and opcodes anymore, unless you want to, like Bruce, which is fine.

I think various ops here have different definitions on what 'embedded' is for them. That's what I am seeing with this excellent discussion.

[nctnico]

well, I think single steppng, register inspection, etc   is enormously useful.

It is not. The reason is that you'll also need to know what each bit and/or instruction means. There is no use in looking at a bundle of data and franticly going through documentation which describes each bit and/or instruction. Errors are easely made. A much better way is to simply print the data as text where the meaning of bits is translated into a human readable form. People don't program in assembly nowadays and scripted languages are also being used increasingly.

Not if you use a modern debugger that permits single stepping of source code, or single stepping of the disassembly, wih modification of registers and CC while the CPU is halted......  there's no need to remember the bits and opcodes anymore, unless you want to, like Bruce, which is fine.

I'm not writing about opcodes but assembler instructions and what bits mean in peripheral registers. Another problem is that you can only step through C / C++ code which isn't optimised OR has been optimised to allow debugging (gcc flags -O0 or -Og). Stepping through optimised code is hit & miss (with mostly miss) as there is no longer a 1 to 1 relation between the machine code and source code.