Please avoid trying to shoehorn von Neumann or Harvard architecture concepts on the PIO.
The RP2040 datasheet says "8 PIO state machines". Conceptually, folks should stick to it.
Chip engineers have all kinds of state machines. Moore. Mealy. And so on. It's not a mathematician's worldview of state machines. To stick a von Neumann or Harvard label onto the PIOs would be misleading. It can only be called a processor in a very (very!) loose sense of the word. If we want so much to stick these labels to things, then the state machines controlling CISC processors are processors too. The processor abstraction is wrong.
Follow the RP2040 datasheet. I can't find "Neumann" or "Harvard" in there. Are you teaching readers the correct thing? It's a souped-up state machine and it is too specialised (and too much of a peripheral) to be called a processor. So think peripheral. Think hardware blocks.
Think in terms of running program fragments (like GPUs when they were less complex), not complete programs -- where 'program' is not something written for a processor but something written for a state machine. And state machines have all kinds of dusty corners. If it's not in the datasheet, just don't rely on that behaviour. Undefined stuff are not bugs. Use the state machine according to what is described in the datasheet, that all. Plenty of embedded folks have no problem with that. It's a state machine where one should think of gates and signals and stuff like that. For the PIO, less theoretical CompSci thinking and more chip desginer hardware-level thinking or readers will latch onto all the wrong concepts and thoughts == embedded MCU intro badly taught.
[Edit] Conceptually, a hardware abstraction is better because a lot of things is happening in parallel and all those concurrent things are clocked. Normal for digital logic. Thinking of PIO programs in terms of procedural programming language code is non-ideal. Think clocked synchronous logic.
The RP2040 datasheet says "8 PIO state machines". Conceptually, folks should stick to it.
Chip engineers have all kinds of state machines. Moore. Mealy. And so on. It's not a mathematician's worldview of state machines. To stick a von Neumann or Harvard label onto the PIOs would be misleading. It can only be called a processor in a very (very!) loose sense of the word. If we want so much to stick these labels to things, then the state machines controlling CISC processors are processors too. The processor abstraction is wrong.
Follow the RP2040 datasheet. I can't find "Neumann" or "Harvard" in there. Are you teaching readers the correct thing? It's a souped-up state machine and it is too specialised (and too much of a peripheral) to be called a processor. So think peripheral. Think hardware blocks.
Think in terms of running program fragments (like GPUs when they were less complex), not complete programs -- where 'program' is not something written for a processor but something written for a state machine. And state machines have all kinds of dusty corners. If it's not in the datasheet, just don't rely on that behaviour. Undefined stuff are not bugs. Use the state machine according to what is described in the datasheet, that all. Plenty of embedded folks have no problem with that. It's a state machine where one should think of gates and signals and stuff like that. For the PIO, less theoretical CompSci thinking and more chip desginer hardware-level thinking or readers will latch onto all the wrong concepts and thoughts == embedded MCU intro badly taught.
[Edit] Conceptually, a hardware abstraction is better because a lot of things is happening in parallel and all those concurrent things are clocked. Normal for digital logic. Thinking of PIO programs in terms of procedural programming language code is non-ideal. Think clocked synchronous logic.
Statistics: Posted by katak255 — Mon Jan 27, 2025 4:05 am