!yafYEipFNsXDdwiHMT:matrix.org

Real Time For the Masses

43 Members
Welcome to the Rust Embedded Real Time For the Masses (RTFM) chat room! | Documentation: https://rtfm.rs/ | Discuss, coordinate, help: https://github.com/rtfm-rs | Code of conduct: https://www.rust-lang.org/conduct.html4 Servers

Load older messages


Timestamp Message
14 Nov 2019
17:34:14@halfbit:matrix.orghalfbitmuch 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:matrix.orgmabezMy 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:matrix.orgjschievinkhere's the Linux port of RTFM, it's super cool: https://github.com/japaric/linux-rtfm
17:44:20@mabez:matrix.orgmabez @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:matrix.orghalfbitRedacted or Malformed Event
17:49:36@halfbit:matrix.orghalfbitI would prefer to use Rust for other reasons over C++
17:50:52@halfbit:matrix.orghalfbitC++ is great, except when it isn't, which seems to be often
23:24:21@japaric:matrix.orgjaparic@room cortex-m-rtfm is now out of beta: https://crates.io/crates/cortex-m-rtfm/0.5.0
23:25:34@halfbit:matrix.orghalfbitRedacted or Malformed Event
23:25:48@halfbit:matrix.orghalfbit * 🎆🎆:fireworks:
23:26:10@halfbit:matrix.orghalfbitRedacted or Malformed Event
23:26:49@yatekii:matrix.orgyatekiiyeah nice! thx
23:26:59@adamgreig:matrix.orgadamgreigo/ nice!
23:27:54@yatekii:matrix.orgyatekiiyeah nice! thx
23:28:01@adamgreig:matrix.orgadamgreig I'm using rtfm 0.5 in my 400v smps and it's working great
15 Nov 2019
08:14:42@jordens:matrix.orgrjoThanks! I've been using it for a while in an open hardware 1 MHz multichannel PID controller for quantum physics.
08:15:58@jordens:matrix.orgrjoThanks! I've been using it for a while in an open hardware 1 MHz multichannel PID controller for quantum physics.
08:37:49@nickray:matrix.orgnickrayCongratulations!
08:58:06@mabez:matrix.orgmabez Looks like I'll be upgrading to 0.5 this morning :)
09:57:21@mabez:matrix.orgmabezWhats 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:matrix.orgmabezWriting to an eeprom, I need to wait for the internal write cycle
10:05:01@per.lindgren:matrix.orgper.lindgrenif 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:matrix.orgper.lindgrenif 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:matrix.orgper.lindgrenif 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:matrix.orgkorken89
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:matrix.orgkorken89
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:matrix.orgkorken89And simply post work orders to it
10:19:06@mabez:matrix.orgmabezLooks 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:matrix.orgmabezI'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:matrix.orgper.lindgrenthe 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).

There are no newer messages yet.


Back to Room List