3 ms·

Yes, I think they are. Nordic 832’s SPI has an 8bit for remaining count in its hardware register meaning a transfer has a max of 255chars. Atmel’s SPI is all ev

Yes, I think they are. Nordic 832’s SPI has an 8bit for remaining count in its hardware register meaning a transfer has a max of 255chars. Atmel’s SPI is all event based. STM32 F3 SPI has an entirely different setup procedure than those two and that has a difference I can’t remeber the F0 and F7 are different. Just at a base level how you work with peripherals is going to be different. Some are better with events, some better as ISRs, some better with polling. There is no middleware that’s just going to abstract those and get a great implementation of each. They were just designed so differently.

pantalaimon 8y ago
> Yes, I think they are. Nordic 832’s SPI has an 8bit for remaining count in its hardware register meaning a transfer has a max of 255chars. Atmel’s SPI is all event based. STM32 F3 SPI has an entirely different setup procedure than those two and that has a difference I can’t remeber the F0 and F7 are different. How does this prevent you from hiding all those implementation details behind an API like spi_transfer(spi_t dev, const void* buffer_tx, void* buffer_rx, size_t size)? RIOT manages to get by with that - granted, most implementations there rely on polling, it's not a conceptual problem. https://github.com/RIOT-OS/RIOT/blob/master/cpu/stm32_common/periph/spi.c https://github.com/RIOT-OS/RIOT/blob/master/cpu/stm32_common... https://github.com/RIOT-OS/RIOT/blob/master/cpu/atmega_common/periph/spi.c https://github.com/RIOT-OS/RIOT/blob/master/cpu/atmega_commo... https://github.com/RIOT-OS/RIOT/blob/master/cpu/nrf5x_common/periph/spi.c https://github.com/RIOT-OS/RIOT/blob/master/cpu/nrf5x_common...
- jschwartzi 8y ago
  It's not that we don't see how you could create an abstraction that works, it's that we're questioning the value of doing so. In your example, if I want a DMA-based transfer it's fine to just hide it and block the thread waiting for the DMA interrupt. But if the hardware designer expects me to poll, now I have to find a way to put the thread to sleep and schedule it. And there are performance and timing implications for either scheme that your abstraction hides from me. At some point I'm going to stumble on those implications and get screwed badly enough by your abstraction that I need to rip it out or work around it to solve a problem. This has happened to me too many times before. On systems that are small enough to be considered "embedded" I would much rather the OS gets the hell out of my way and lets me pick a sensible abstraction myself. I don't see much value in having an abstraction layer in these systems unless it's for a hobby project. In an established project you would never recompile your code for a completely different hardware platform "just to see how it performs." You'd stick with the hardware you know, and you'd already have de-risked the performance questions early enough in the project that you wouldn't have written a bunch of application code yet. It's not a problem that needs to be solved in a professional environment.
  - SlowRobotAhead 8y ago
    Nailed it. There is just no way an abstraction is going to pick the best process for my needs. And yea, while it might be a nice idea to switch chips... I’d have to go through sourcing to figure out if they make a chip in the package i would need at a price I’m willing to pay at a lead time I’m willing to wait, a week or two reading data sheets and reference manuals, updating the board hardware, changing the BOM, getting with purchasing to update the next PO, changing the assembly programming and stencils... plus documentation, plus fragmenting our hardware variations, etc. The abstraction to switch chips, might be nice for prototyping, but yea, it’s not really useful for production, so I think I would rather my OS developers focus on other things.

pantalaimon 8y ago

> Yes, I think they are. Nordic 832’s SPI has an 8bit for remaining count in its hardware register meaning a transfer has a max of 255chars. Atmel’s SPI is all event based. STM32 F3 SPI has an entirely different setup procedure than those two and that has a difference I can’t remeber the F0 and F7 are different. How does this prevent you from hiding all those implementation details behind an API like spi_transfer(spi_t dev, const void* buffer_tx, void* buffer_rx, size_t size)? RIOT manages to get by with that - granted, most implementations there rely on polling, it's not a conceptual problem. https://github.com/RIOT-OS/RIOT/blob/master/cpu/stm32_common/periph/spi.c https://github.com/RIOT-OS/RIOT/blob/master/cpu/stm32_common... https://github.com/RIOT-OS/RIOT/blob/master/cpu/atmega_common/periph/spi.c https://github.com/RIOT-OS/RIOT/blob/master/cpu/atmega_commo... https://github.com/RIOT-OS/RIOT/blob/master/cpu/nrf5x_common/periph/spi.c https://github.com/RIOT-OS/RIOT/blob/master/cpu/nrf5x_common...

jschwartzi 8y ago
It's not that we don't see how you could create an abstraction that works, it's that we're questioning the value of doing so. In your example, if I want a DMA-based transfer it's fine to just hide it and block the thread waiting for the DMA interrupt. But if the hardware designer expects me to poll, now I have to find a way to put the thread to sleep and schedule it. And there are performance and timing implications for either scheme that your abstraction hides from me. At some point I'm going to stumble on those implications and get screwed badly enough by your abstraction that I need to rip it out or work around it to solve a problem. This has happened to me too many times before. On systems that are small enough to be considered "embedded" I would much rather the OS gets the hell out of my way and lets me pick a sensible abstraction myself. I don't see much value in having an abstraction layer in these systems unless it's for a hobby project. In an established project you would never recompile your code for a completely different hardware platform "just to see how it performs." You'd stick with the hardware you know, and you'd already have de-risked the performance questions early enough in the project that you wouldn't have written a bunch of application code yet. It's not a problem that needs to be solved in a professional environment.
- SlowRobotAhead 8y ago
  Nailed it. There is just no way an abstraction is going to pick the best process for my needs. And yea, while it might be a nice idea to switch chips... I’d have to go through sourcing to figure out if they make a chip in the package i would need at a price I’m willing to pay at a lead time I’m willing to wait, a week or two reading data sheets and reference manuals, updating the board hardware, changing the BOM, getting with purchasing to update the next PO, changing the assembly programming and stencils... plus documentation, plus fragmenting our hardware variations, etc. The abstraction to switch chips, might be nice for prototyping, but yea, it’s not really useful for production, so I think I would rather my OS developers focus on other things.