5 ms·

On there site, they do not compare it with FreeRTOS, a commonly used alternative. I wonder why.

vardump 8y ago
Yeah, I was wondering same. It also talks about 8-bit support, but only lists AVR... I mean, AVR is compiler target optimized arch, more like a 16/32 bit system with register width chopped to 8 bits, not limited like other 8-bit MCUs. 8051 support wouldn't hurt. Plus side there's support for 16-bit MSP430, important due to its low power consumption. Anyways, it's good to see more OS competition in IoT space. Signed: embedded & driver developer.
pantalaimon 8y ago
FreeRTOS doesn't come with a hardware abstraction, it doesn't include any drivers.
- SlowRobotAhead 8y ago
  Nor should it. As someone in the CE field doing this work everyday, I’m getting kind of sick of abstraction layers. Every device mfg takes a crack at it, every RTOS does, ARM itself does, and many IDEs are as well. I kind of just want my RTOS to do threading, preemption, and resource locking. Middlewares line Amazon’s MQTT are good but I’d really prefer to handle the peripherals myself or use the device mfg’s libs. I am not a believer in write once use everywhere embedded code, it just doesn’t work, because the peripherals are just so different.
  - pantalaimon 8y ago
    > I am not a believer in write once use everywhere embedded code, it just doesn’t work, because the peripherals are just so different. Are they though? You got SPI, I2C, UART Timers and DMA and while their flavor may differ depending on the vendor, they should do about the same no matter what platform you are on. Sometimes you might have to do some exotic stuff when a chip uses non-standard interfaces, but most of the time the behavior should be fairly generic.
    - SlowRobotAhead 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. 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.

Yeah, I was wondering same. It also talks about 8-bit support, but only lists AVR... I mean, AVR is compiler target optimized arch, more like a 16/32 bit system with register width chopped to 8 bits, not limited like other 8-bit MCUs. 8051 support wouldn't hurt. Plus side there's support for 16-bit MSP430, important due to its low power consumption. Anyways, it's good to see more OS competition in IoT space. Signed: embedded & driver developer.

pantalaimon 8y ago

FreeRTOS doesn't come with a hardware abstraction, it doesn't include any drivers.

SlowRobotAhead 8y ago
Nor should it. As someone in the CE field doing this work everyday, I’m getting kind of sick of abstraction layers. Every device mfg takes a crack at it, every RTOS does, ARM itself does, and many IDEs are as well. I kind of just want my RTOS to do threading, preemption, and resource locking. Middlewares line Amazon’s MQTT are good but I’d really prefer to handle the peripherals myself or use the device mfg’s libs. I am not a believer in write once use everywhere embedded code, it just doesn’t work, because the peripherals are just so different.
- pantalaimon 8y ago
  > I am not a believer in write once use everywhere embedded code, it just doesn’t work, because the peripherals are just so different. Are they though? You got SPI, I2C, UART Timers and DMA and while their flavor may differ depending on the vendor, they should do about the same no matter what platform you are on. Sometimes you might have to do some exotic stuff when a chip uses non-standard interfaces, but most of the time the behavior should be fairly generic.
  - SlowRobotAhead 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. 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.