3 ms·

All of this wreaks of complexity crisis to me. That you need to know much and do do so much work - just in order to do the work you want to do. Explain why I’m

All of this wreaks of complexity crisis to me. That you need to know much and do do so much work - just in order to do the work you want to do. Explain why I’m wrong, please.

AlotOfReading 2y ago
The article goes into more detail than it strictly needs to because the purpose is educational. However, a lot of what it's presenting is simplified interfaces and relevant details rather than the true complexity of the whole. Modern hardware is just fundamentally complex, especially if you want to make full use of the particular features of each platform.
fidotron 2y ago
You are wrong. When more general purpose hardware (i.e. CPU cores) are added to chips like this it is to replace the need for single purpose devices. True nightmarish complexity comes from enormous numbers of highly specific single purpose devices which all have their own particular oddities. There was a chip a while back which took this to a crazy extreme but threw out the whole universe in the process https://www.greenarraychips.com/ https://www.greenarraychips.com/
- awjlogan 2y ago
  Not wrong, especially for microcontrollers where micro/nanosecond determinism may be important - software running on general purpose cores is not suitable for that. They can also be orders of magnitude more energy efficient than running a full core just to twiddle some pins. I’ve got a project that uses 4 hardware serial modules, timers, ADC, event system etc all dedicated function. Sure, they have their quirks but once you’ve learnt them you can reuse a lot of the drivers across multiple products, especially for a given vendor. Of course there is some cost, but it’s finding the balance for your product that is important.
  - fidotron 2y ago
    > They can also be orders of magnitude more energy efficient than running a full core just to twiddle some pins. This used to be true, but as fabrication shrinks first you move to quasi FSMs (like the PIO blocks) and eventually mini processors since those are smaller than the dedicated units of the previous generation. When you get the design a bit wrong you end up with the esp32 where the lack of general computation in peripherals radically bumps memory requirements and so the power usage. This trend also occurs in GPUs where functionality eventually gets merged into more uniform blocks to make room for newly conceived specialist units that have become viable.
    - awjlogan 2y ago
      No, still true - you’re never going to beat the determinism, size, and power of a few flops and some logic to drive a common interface directly compared to a full core with architectural state and memory. E.g., just to enter an interrupt is 10-15 odd cycles, a memory access or two to set a pin, and then 10-15 cycles again to restore and exit. Additionally, micros have to be much robust electrically than a cutting edge (or even 14 nm) CPU/GPU and available for extended (decade) timespans so the economics driving the shrink are different. Small, fast cores have eaten the lunch of e.g. large dedicated DSP blocks for sure but those are niche cases where the volume is low so eventually the hardware cost and cost to develop on weird architectures costs more than running a general purpose core.
      - fidotron 2y ago
        > No, still true - you’re never going to beat the determinism, size, and power of a few flops and some logic to drive a common interface directly compared to a full core with architectural state and memory. But you must know what you intend to do when designing the MCU, and history shows (and some of the questioning here also shows) that this isn’t the case. As you point out expected lifespans are long, so what is a designer to do? The ESP32 case is interesting because it comes so close, to the point I believe the RMT peripheral probably partly inspired the PIO, thanks to how widely it has been used for other things and how it breaks. The key weakness of the RMT is it expects the conversion of the data structures to be used to control it to be prepared in memory already, almost certainly by the CPU. This means that to alter the data being sent out requires the main app processor, the DMA and the peripheral to be involved, and we are hammering the memory bus while doing this. A similar thing occurs with almost any non trivial SPI usage where a lot of people end up building “big” (relatively) buffers in memory in advance. Both of those situations are very common and bad. Assuming the tiny cores can have their own program memory they will be no less deterministic than any other sort of peripheral while radically freeing up the central part of the system. One of the main things I have learned over the years is people wildly overstate the cost of computation and understate the cost of moving data around. If you can reduce the data a lot at the cost of a bit more computation that is a big win.
rcxdude 2y ago
Making I/O properly programmable actually reduces complexity overall, because you can put more of the customizability on the other side if the interface, making things much simpler overall. I2C, for example, is a terrible interface in many ways, but one of the biggest is it creates a very complex and low-latency interface between the hardware and the software, and it's often easier to bitbang than use dedicated peripherals, especially the buggier ones. Running it on a small dedicated core means you can deal with it much more sensibly than trying to wrangle a hard peripheral which can't make enough assumptions about your use-case to give a good interface.

All of this wreaks of complexity crisis to me. That you need to know much and do do so much work - just in order to do the work you want to do. Explain why I’m wrong, please.

AlotOfReading 2y ago

The article goes into more detail than it strictly needs to because the purpose is educational. However, a lot of what it's presenting is simplified interfaces and relevant details rather than the true complexity of the whole. Modern hardware is just fundamentally complex, especially if you want to make full use of the particular features of each platform.

fidotron 2y ago

You are wrong. When more general purpose hardware (i.e. CPU cores) are added to chips like this it is to replace the need for single purpose devices. True nightmarish complexity comes from enormous numbers of highly specific single purpose devices which all have their own particular oddities. There was a chip a while back which took this to a crazy extreme but threw out the whole universe in the process https://www.greenarraychips.com/ https://www.greenarraychips.com/

awjlogan 2y ago
Not wrong, especially for microcontrollers where micro/nanosecond determinism may be important - software running on general purpose cores is not suitable for that. They can also be orders of magnitude more energy efficient than running a full core just to twiddle some pins. I’ve got a project that uses 4 hardware serial modules, timers, ADC, event system etc all dedicated function. Sure, they have their quirks but once you’ve learnt them you can reuse a lot of the drivers across multiple products, especially for a given vendor. Of course there is some cost, but it’s finding the balance for your product that is important.
- fidotron 2y ago
  > They can also be orders of magnitude more energy efficient than running a full core just to twiddle some pins. This used to be true, but as fabrication shrinks first you move to quasi FSMs (like the PIO blocks) and eventually mini processors since those are smaller than the dedicated units of the previous generation. When you get the design a bit wrong you end up with the esp32 where the lack of general computation in peripherals radically bumps memory requirements and so the power usage. This trend also occurs in GPUs where functionality eventually gets merged into more uniform blocks to make room for newly conceived specialist units that have become viable.
  - awjlogan 2y ago
    No, still true - you’re never going to beat the determinism, size, and power of a few flops and some logic to drive a common interface directly compared to a full core with architectural state and memory. E.g., just to enter an interrupt is 10-15 odd cycles, a memory access or two to set a pin, and then 10-15 cycles again to restore and exit. Additionally, micros have to be much robust electrically than a cutting edge (or even 14 nm) CPU/GPU and available for extended (decade) timespans so the economics driving the shrink are different. Small, fast cores have eaten the lunch of e.g. large dedicated DSP blocks for sure but those are niche cases where the volume is low so eventually the hardware cost and cost to develop on weird architectures costs more than running a general purpose core.
    - fidotron 2y ago
      > No, still true - you’re never going to beat the determinism, size, and power of a few flops and some logic to drive a common interface directly compared to a full core with architectural state and memory. But you must know what you intend to do when designing the MCU, and history shows (and some of the questioning here also shows) that this isn’t the case. As you point out expected lifespans are long, so what is a designer to do? The ESP32 case is interesting because it comes so close, to the point I believe the RMT peripheral probably partly inspired the PIO, thanks to how widely it has been used for other things and how it breaks. The key weakness of the RMT is it expects the conversion of the data structures to be used to control it to be prepared in memory already, almost certainly by the CPU. This means that to alter the data being sent out requires the main app processor, the DMA and the peripheral to be involved, and we are hammering the memory bus while doing this. A similar thing occurs with almost any non trivial SPI usage where a lot of people end up building “big” (relatively) buffers in memory in advance. Both of those situations are very common and bad. Assuming the tiny cores can have their own program memory they will be no less deterministic than any other sort of peripheral while radically freeing up the central part of the system. One of the main things I have learned over the years is people wildly overstate the cost of computation and understate the cost of moving data around. If you can reduce the data a lot at the cost of a bit more computation that is a big win.

rcxdude 2y ago

Making I/O properly programmable actually reduces complexity overall, because you can put more of the customizability on the other side if the interface, making things much simpler overall. I2C, for example, is a terrible interface in many ways, but one of the biggest is it creates a very complex and low-latency interface between the hardware and the software, and it's often easier to bitbang than use dedicated peripherals, especially the buggier ones. Running it on a small dedicated core means you can deal with it much more sensibly than trying to wrangle a hard peripheral which can't make enough assumptions about your use-case to give a good interface.