| 14 Nov 2019 |
| 17:34:14 |  halfbit | much saner than the typical rtos thread model I feel like, where stack overflows can lead to a lot of head scratching |
| 17:38:53 |  mabez | My thoughts completely, the single stack resource policy is a welcome change. The project I made the Http server for originally was a freertos code base but I managed to convince them to rewrite it in Rust |
| 17:40:34 |  jschievink | here's the Linux port of RTFM, it's super cool: https://github.com/japaric/linux-rtfm |
| 17:44:20 | mabez | @korken89:matrix.org also created a version of rtfm in C++ https://github.com/korken89/crect , if you can't use Rust |
| 17:47:19 | halfbit | Redacted or Malformed Event |
| 17:49:36 | halfbit | I would prefer to use Rust for other reasons over C++ |
| 17:50:52 | halfbit | C++ is great, except when it isn't, which seems to be often |
| 23:24:21 |  japaric | @room cortex-m-rtfm is now out of beta: https://crates.io/crates/cortex-m-rtfm/0.5.0 |
| 23:25:34 | halfbit | Redacted or Malformed Event |
| 23:25:48 | halfbit | * 🎆🎆:fireworks: |
| 23:26:10 | halfbit | Redacted or Malformed Event |
| 23:26:49 |  yatekii | yeah nice! thx |
| 23:26:59 |  adamgreig | o/ nice! |
| 23:27:54 | yatekii | yeah nice! thx |
| 23:28:01 | adamgreig | I'm using rtfm 0.5 in my 400v smps and it's working great |
| 15 Nov 2019 |
| 08:14:42 |  rjo | Thanks! I've been using it for a while in an open hardware 1 MHz multichannel PID controller for quantum physics. |
| 08:15:58 | rjo | Thanks! I've been using it for a while in an open hardware 1 MHz multichannel PID controller for quantum physics. |
| 08:37:49 |  nickray | Congratulations! |
| 08:58:06 | mabez | Looks like I'll be upgrading to 0.5 this morning :) |
| 09:57:21 | mabez | Whats my best bet of getting a small delay with rtfm, in the range of a few millis without blocking a task? |
| 09:57:52 | mabez | Writing to an eeprom, I need to wait for the internal write cycle |
| 10:05:01 |  per.lindgren | if you do a delay there you are not blocking the entire system, only tasks at same or lower priority. another option is to implement your eeprom writer as a state machine and post a message (schedule) with a timing offset (your delay time), then dependent on state cont. with the appropriate action. (@korken89, has implemented a state machine abstraction). A third option is very experimental and that is using generators that allow for yielding, then the generator implements the state machine for you. still you need to post a message for the time of resume. So the dispatcher would be the task you post to, the dispatcher would resume your eeprom thingy. |
| 10:06:08 | per.lindgren | if you do a delay there you are not blocking the entire system, only tasks at same or lower priority. another option is to implement your eeprom writer as a state machine and post a message (schedule) with a timing offset (your delay time), then dependent on state cont. with the appropriate action. (@korken89, has implemented a state machine abstraction). A third option is very experimental and that is using generators that allow for yielding, then the generator implements the state machine for you. still you need to post a message for the time of resume. So the dispatcher would be the task you post to, the dispatcher would resume your eeprom thingy. |
| 10:07:14 | per.lindgren | if you do a delay there you are not blocking the entire system, only tasks at same or lower priority. another option is to implement your eeprom writer as a state machine and post a message (schedule) with a timing offset (your delay time), then dependent on state cont. with the appropriate action. (@korken89, has implemented a state machine abstraction). A third option is very experimental and that is using generators that allow for yielding, then the generator implements the state machine for you. still you need to post a message for the time of resume. So the dispatcher would be the task you post to, the dispatcher would resume your eeprom thingy. |
| 10:09:34 |  korken89 | In reply to @mabez:matrix.org
Whats my best bet of getting a small delay with rtfm, in the range of a few millis without blocking a task? Or have a "background work queue" that runs at idle priority |
| 10:10:38 | korken89 | In reply to @mabez:matrix.org
Whats my best bet of getting a small delay with rtfm, in the range of a few millis without blocking a task? Or have a "background work queue" that runs at idle priority |
| 10:11:17 | korken89 | And simply post work orders to it |
| 10:19:06 | mabez | Looks like matrix is still having some issues, seeing 3x of everyones messages. Thanks, I like the first idea, mixed with korkens idle prio idea so I'll give that a try. |
| 10:21:29 | mabez | I've implemented the second method a few times for other things like retrying mounting a filesystem, but its a bit of a faff to setup do you think it would be possible in the future rtfm could support a delay 'primitive'? Preferably without generators as I don't think they're on track to stabilize anytime soon |
| 10:39:18 | per.lindgren | the key advantage to performance and robustness of RTFM is the run-to-end semantics, there is no concept of task switching natively in RTFM. We would need to use something like genetars in order to "mimic" that behavior. Just calling into the cortex_m delay from a low prio task (like idle), does not block scheduling (as long as you don't hold any resource during the delay). Notice, in RTFM a resource is not really locked its claimed, raising the global system ceiling. If the resource ceiling of R is say 3, that means that ALL tasks with a prio of 3 or less is blocked (not just the ones that that access R).
At a first glance this might look like bad news (reducing schedulability), but in facts its very good news. We implement the Stack Resource Policy, and that gives us bounded priority inversion. In comparison using a traditional threaded RTOS, blocking might be transitive, and thus priority inversion is unbounded (meaning its very hard to foresee the time you will be blocked). Moreover, that time may well be infinite (that is the case of a deadlock, but thats just a special case of the unbounded blocking nature of threads based Mutexes). |
