3 ms·

I think anything truly real time would be interrupt driven and use C/assembly. This would act as the glue between that critical code. I don't feel like we've hi

I think anything truly real time would be interrupt driven and use C/assembly. This would act as the glue between that critical code. I don't feel like we've hit peak embedded development yet. I love the idea of rapid embedded development that deploys scripts over a network or RS232, but most scripting languages aren't great for this. I would like to see a statically typed actor system with no GC or optional per actor GC that is pre-allocated and can only cause a single actor to fail in a predictable way.

bluGill 5y ago
How real time do you need to be? some real time is you need to react within milliseconds or bad things happen, humans will notice if there is 10ms lag in real time audio. Some real time is you need to react within seconds. A machine might need several tens of seconds to get up to speed, so controlling the motor only needs to update a once a second or so for the speed to remain within tolerance. And everything in between. Depending on where you are on the need for control different technologies can work for you.
- detinho 5y ago
  I'm probably wrong, but isn't real time not about how fast you can react but if you can react on a defined time constraint? Or is there a time threshold you can't consider real time any more like 1 day? Edit: just like you said, 10ms, 1s, etc.
  - fullstop 5y ago
    Maximum tick time for RTOS are usually measured in tenths of seconds. The range is typically from microseconds to about 100ms. edit: updated to reflect that I meant "upper bound" edit2: completely reworded to be more clear.
    - monocasa 5y ago
      Time constraints on an RTOS are what you need them to be for the domain. On the RTOS I was the lead for, some constraints were measured in 100s of ns. Edit to address the edit: our upper bound in that case was single digit microseconds.
      - fullstop 5y ago
        My point was that once you pass the 100ms mark most would not consider it "real-time".
        monocasa 5y ago
        Ah it reads backwards, that you're asserting no one actually deals with constraints tighter than 100 ms.
        fullstop 5y ago
        We're coming from different directions. My upper bound was "after this point it won't be rtos", but I've reworded it entirely to be more clear.
        monocasa 5y ago
        Upper bound is a specific term in real time also unfortunately. Might I suggest wording such as "upper bound constraints exceeding 100ms aren't typically addressed with real time methods".
        detinho 5y ago
        For what I see from the discution it seems to be more a practical decision to not use real time resources and techniques for much higher times. So 1 day for example would be a waste of development time to try to use real time, you could use alerts and background jobs to fix issues. But when you reach shorter and shorter timeframes and bad things can happen a real time approach starts to make more sense. Now, some parent comment mentioned RTOS. Maybe for a real time OS there would be a practical hard upper bound. But for real time systems in general this upper bound would be totally domain specific.
  - bluGill 5y ago
    The time depends on your problem. The real time is more about bad things happen if you don't respond on time. If you click on a webpage and your browser times out loading it is a real time failure, but the failure isn't bad enough that anyone thinks of browsers as real time because the failure isn't really harmful.
  - tdeck 5y ago
    You're correct, the definition requires that operations be bounded, not necessarily "fast".
cinntaile 5y ago
There are languages invented for this purpose, such as Ada. I'd look at that instead of C when you're doing real time systems. Although there are many different kinds of real time systems so it depends on the goal. Soft real time systems aren't as time critical as hard real time systems so the way you program and reason about them is a bit different.

bluGill 5y ago

How real time do you need to be? some real time is you need to react within milliseconds or bad things happen, humans will notice if there is 10ms lag in real time audio. Some real time is you need to react within seconds. A machine might need several tens of seconds to get up to speed, so controlling the motor only needs to update a once a second or so for the speed to remain within tolerance. And everything in between. Depending on where you are on the need for control different technologies can work for you.

detinho 5y ago
I'm probably wrong, but isn't real time not about how fast you can react but if you can react on a defined time constraint? Or is there a time threshold you can't consider real time any more like 1 day? Edit: just like you said, 10ms, 1s, etc.
- fullstop 5y ago
  Maximum tick time for RTOS are usually measured in tenths of seconds. The range is typically from microseconds to about 100ms. edit: updated to reflect that I meant "upper bound" edit2: completely reworded to be more clear.
  - monocasa 5y ago
    Time constraints on an RTOS are what you need them to be for the domain. On the RTOS I was the lead for, some constraints were measured in 100s of ns. Edit to address the edit: our upper bound in that case was single digit microseconds.
    - fullstop 5y ago
      My point was that once you pass the 100ms mark most would not consider it "real-time".
      - monocasa 5y ago
        Ah it reads backwards, that you're asserting no one actually deals with constraints tighter than 100 ms.
        fullstop 5y ago
        We're coming from different directions. My upper bound was "after this point it won't be rtos", but I've reworded it entirely to be more clear.
        monocasa 5y ago
        Upper bound is a specific term in real time also unfortunately. Might I suggest wording such as "upper bound constraints exceeding 100ms aren't typically addressed with real time methods".
        detinho 5y ago
        For what I see from the discution it seems to be more a practical decision to not use real time resources and techniques for much higher times. So 1 day for example would be a waste of development time to try to use real time, you could use alerts and background jobs to fix issues. But when you reach shorter and shorter timeframes and bad things can happen a real time approach starts to make more sense. Now, some parent comment mentioned RTOS. Maybe for a real time OS there would be a practical hard upper bound. But for real time systems in general this upper bound would be totally domain specific.
- bluGill 5y ago
  The time depends on your problem. The real time is more about bad things happen if you don't respond on time. If you click on a webpage and your browser times out loading it is a real time failure, but the failure isn't bad enough that anyone thinks of browsers as real time because the failure isn't really harmful.
- tdeck 5y ago
  You're correct, the definition requires that operations be bounded, not necessarily "fast".

cinntaile 5y ago

There are languages invented for this purpose, such as Ada. I'd look at that instead of C when you're doing real time systems. Although there are many different kinds of real time systems so it depends on the goal. Soft real time systems aren't as time critical as hard real time systems so the way you program and reason about them is a bit different.