6 ms·

And most importantly, it doesn't have an OS that provides next to no benefit for many of those tasks, and suffers from inconsistent timing. Something like ESP3

And most importantly, it doesn't have an OS that provides next to no benefit for many of those tasks, and suffers from inconsistent timing. Something like ESP32 is much more reliable at controlling hardware. It will never miss on a triggered limit switch in time because memory ran out for some reason and it started swapping.

blacksmith_tb 4y ago
Ah, that kind of timing. I have made several kinds of clocks with RPis, one that ran fine for years driving a little servo to strike an hourly chime like a grandfather clock, which was all very easy thanks to having an OS with NTP and cron. But I mostly agree with the article, I have a Gigabyte Brix fanless NUC-alike as my real home server, and a couple of Pis doing little things (and switched to 'overlay file system' so running only from memory and not writing to those frail SD cards).
- bschwindHN 4y ago
  > very easy thanks to having an OS with NTP and cron. An ESP32 can still have both of those things in some capacity. https://randomnerdtutorials.com/esp32-ntp-client-date-time-arduino-ide/ https://randomnerdtutorials.com/esp32-ntp-client-date-time-a... https://github.com/DavidMora/esp_cron https://github.com/DavidMora/esp_cron
  - cinntaile 4y ago
    The point the GP made was that timing issues weren't a real problem on the rpi thanks to the tools mentioned.
    - monocasa 4y ago
      That's not the kind of timing the original point was talking about AFAICT. Real time response is the issue with regular Linux, not vaguely accurate wall time.
    - dale_glass 4y ago
      There are different kinds of timing issues. There's knowing the time, which you can do with something like NTP. That the RPI can manage just fine. And there's acting with precise timing, eg, if you need to control a mechanism and reliably react on a deadline of a few ms. A RPI doesn't perform well there, which is why 3D printers use microcontrollers instead.
      - ahepp 4y ago
        A few ms? In my experience that seems well within the capabilities of Linux. I guess last time I measured wasn't on a Raspberry Pi. I'm kinda tempted to take a shot at profiling this and writing up a blog post since it seems like a useful topic, although it will probably be a few months until I can get around to it.
        josefx 4y ago
        Being within the capabilities of something and guaranteeing that it will never exceed that are two different things. At least in the past real time guarantees for Linux came as part of an optional patch set for the kernel since guaranteeing that an algorithm would complete within a set time frame or that things like priority inversion issues would be handled correctly came with a performance cost.
        petsfed 4y ago
        I think milliseconds overestimates by a few orders of magnitude, but non-real-time OSs really suffer for the intermediate IO stuff you expect in an embedded project (e.g. SPI, I2C, etc) A long time ago, I was playing with Project Nerves on an Orange Pi running some flavor of debian. I was doing some I2C transaction (at 400 kHz, each bit is single-digit microseconds), and I ultimately had to have a re-attempt loop because the transaction would fail so often. I found a failure cutoff of 5 attempts was sufficient to keep going. I don't recall the failure rate, but basically, whenever a transaction failed, I'd have to reattempt 2-3 times before it eventually succeeded. Meanwhile, on a bog-standard Arduino with an ATMega328P, I send the I2C traffic once, and unless the circuit is physically damaged, the transaction will succeed.
        4y ago
    - deleted 4y ago
      [deleted]
    - ahepp 4y ago
      I think we are talking about things like interrupt latency, not NTP synchronization. MCU interrupt latency can be extremely deterministic. I ran some measurements for work and found Linux to be adequate for many uses, but it is a valid concern. There are some Linux kernel patches like PREEMPT_RT that attempt to bound Linux latencies, but generally MCUs are a lot better suited if latency is critical. In part because they just have less software running on them to interfere with timing.

blacksmith_tb 4y ago

Ah, that kind of timing. I have made several kinds of clocks with RPis, one that ran fine for years driving a little servo to strike an hourly chime like a grandfather clock, which was all very easy thanks to having an OS with NTP and cron. But I mostly agree with the article, I have a Gigabyte Brix fanless NUC-alike as my real home server, and a couple of Pis doing little things (and switched to 'overlay file system' so running only from memory and not writing to those frail SD cards).

bschwindHN 4y ago
> very easy thanks to having an OS with NTP and cron. An ESP32 can still have both of those things in some capacity. https://randomnerdtutorials.com/esp32-ntp-client-date-time-arduino-ide/ https://randomnerdtutorials.com/esp32-ntp-client-date-time-a... https://github.com/DavidMora/esp_cron https://github.com/DavidMora/esp_cron
- cinntaile 4y ago
  The point the GP made was that timing issues weren't a real problem on the rpi thanks to the tools mentioned.
  - monocasa 4y ago
    That's not the kind of timing the original point was talking about AFAICT. Real time response is the issue with regular Linux, not vaguely accurate wall time.
  - dale_glass 4y ago
    There are different kinds of timing issues. There's knowing the time, which you can do with something like NTP. That the RPI can manage just fine. And there's acting with precise timing, eg, if you need to control a mechanism and reliably react on a deadline of a few ms. A RPI doesn't perform well there, which is why 3D printers use microcontrollers instead.
    - ahepp 4y ago
      A few ms? In my experience that seems well within the capabilities of Linux. I guess last time I measured wasn't on a Raspberry Pi. I'm kinda tempted to take a shot at profiling this and writing up a blog post since it seems like a useful topic, although it will probably be a few months until I can get around to it.
      - josefx 4y ago
        Being within the capabilities of something and guaranteeing that it will never exceed that are two different things. At least in the past real time guarantees for Linux came as part of an optional patch set for the kernel since guaranteeing that an algorithm would complete within a set time frame or that things like priority inversion issues would be handled correctly came with a performance cost.
      - petsfed 4y ago
        I think milliseconds overestimates by a few orders of magnitude, but non-real-time OSs really suffer for the intermediate IO stuff you expect in an embedded project (e.g. SPI, I2C, etc) A long time ago, I was playing with Project Nerves on an Orange Pi running some flavor of debian. I was doing some I2C transaction (at 400 kHz, each bit is single-digit microseconds), and I ultimately had to have a re-attempt loop because the transaction would fail so often. I found a failure cutoff of 5 attempts was sufficient to keep going. I don't recall the failure rate, but basically, whenever a transaction failed, I'd have to reattempt 2-3 times before it eventually succeeded. Meanwhile, on a bog-standard Arduino with an ATMega328P, I send the I2C traffic once, and unless the circuit is physically damaged, the transaction will succeed.
      - 4y ago
  - deleted 4y ago
    [deleted]
  - ahepp 4y ago
    I think we are talking about things like interrupt latency, not NTP synchronization. MCU interrupt latency can be extremely deterministic. I ran some measurements for work and found Linux to be adequate for many uses, but it is a valid concern. There are some Linux kernel patches like PREEMPT_RT that attempt to bound Linux latencies, but generally MCUs are a lot better suited if latency is critical. In part because they just have less software running on them to interfere with timing.