Need advices for complex logic design approach

[rtic-rs]

Need advices for complex logic design approach

[perlindgren]

Hi There This is a very good and important question. RTFM Task/Resource Model You can view the system as being event driven, the tasks are the event handlers and interrupts the events. So you can see this as being systems with static call back topology. Your handler for the low level IO may buffer the chars (use for eg. the ring buffer from `heapless`), and trigger (pend) a parsing task (at potentially lower prio), when a return is encountered. The parser task would in turn copy out the received chars, and parse them, and in turn pend some other task. Advantages to threads There are numerous advantages of the event driven approach to a traditional threading model, especially regarding OH, response time, overall schedulability, etc. The Task/Resource model has a strong theoretical foundation allowing real-time analyses. Its deadlock free by construction, and priority inversion is bound. CRO Model In an earlier experiment, we implemented a model of Concurrent Reactive Objects (CRO), offering message passing in between objects (or rather object instances). This is quite close to Ada's protected objects, or using montiors, like the Java synchronize. However the Java model is not safe, as you (or some librarycode somewhere) might have forgotten to synchronize, and you have a race. In our case, it was built into the model. One can also see that as an Actor framework, but in our case we allow for synchonous messages as well (this is not commonplace for Actors, which are decoupled).The CRO model is hard to implement in an elegant way in Rust as of today. The CRO model requires crate wide analysis to derive ceilings and ensure deadlock freedom (you would like to be able to declare CRO objects in different modules and even crates). To this end, we used a build script, parsing "headers" defining the Objects (a bit like the app but just an "interface", for each object. The Objects can be nested into compontents (and bound to other components or object interfaces). The intitial experiment was a proof of concept (required some manual hand waving, and NOT supporting CROs in external crates, there is no suitable metadata in Rust for this as of yet), and has not been published yet. Better support for crate wide analysis in the Rust compiler will hopefully allow us to make it more ergonomic to use. Virtual Tasks and Messages with Timing Seamantics In the meantime, we will release an extension of RTFM allowing virtual tasks with message passing. You can manually encode the CRO model, by seeing "self" as being a common resource (and claim the object state for eachmethod). The model will also provide timing semantics built in, so you can define that the message will be postponed (delayed) before being executed. The user do not need to set up the timer manually, only define the businesslogic. (The timing semantics come with a theoretical underpinning, ensuring timing to be free of accumulated drift.) Similarly a message can have a deadline, and actual hardware priorities will be allocated by the RTFM framework. Deadline semantics is compositional (a huge advantage to handle complexity in real-time systems).Not yet sure the deadline semantics will be implemented in next release, its quite an engineering effort to get everything working at once, so we might release some beta of the new API first, to get some feedback.(There is nothing new here, the CR model has already been researched and implemented in C, Rust RTFM has still a bit of catching up...) FSM generation Relating "automated" genatation of FSMs. This is essentially what generators in Rust do. We plan to support those, but as of now Rustc support is still lacking for making "static" generators. Best regards Per

…

________________________________ Från: Vitaly Puzrin <[email protected]> Skickat: den 29 april 2018 23:31:49 Till: japaric/cortex-m-rtfm Kopia: Subscribed Ämne: [japaric/cortex-m-rtfm] Need advices for complex logic design approach (#75) As far as i understand, in existing RTFM approach "tasks" are low-level units (driven by hardware interrupts). That may "conflict" with "normal" architecture design process (from top to bottom), when tasks are business-logic oriented units (because interrupt-driven approach is "from bottom to top"). Everything is great for simple case, when "user actions" and interrupts are equal: * User push button -> interrupt happens (event) -> task executed What about more complex cases? Let's consider several samples: 1. Device waits for input string with command (\n-limited) on UART * Interrupt happens on each char. But separate char means nothing useful, only accumulated string should emit event (run logical task) 2. User push button, but we need filter jitter to drop noise (or jitter filter for EC11<https://www.alps.com/prod/info/E/HTML/Encoder/Incremental/EC11/EC11_list.html> quatratic encoder) * We have to setup additional timer interrupts, and do some black magic inside. Consumer should receive a simple result somehow (and be isolated from jitter filtering logic) Of cause, we can make each RTFM task more and more complex, adding FSM inside and so on. But that still keep us on "from bottom to top" design - difficult and inconvenient for complex things. Are there some pattern to solve such collision (move from "bottom to top" to "top to bottom" design)? May be virtual tasks/evens or something else... — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<https://github.com/japaric/cortex-m-rtfm/issues/75>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AD5naKkNgIpkavvtl-h4H0-m0RtDvT2kks5ttjFFgaJpZM4Tr93e>. {"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/japaric/cortex-m-rtfm","title":"japaric/cortex-m-rtfm","subtitle":"GitHub repository","main_image_url":"https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png","avatar_image_url":"https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name":"Open in GitHub","url":"https://github.com/japaric/cortex-m-rtfm"}},"updates":{"snippets":[{"icon":"DESCRIPTION","message":"Need advices for complex logic design approach (#75)"}],"action":{"name":"View Issue","url":"https://github.com/japaric/cortex-m-rtfm/issues/75"}}}

[puzrin]

I think, it worth consider one more case - regulating data pressure. Let's imagine, that we have GUI, which:

• Reacts to input buttons
• Do some animation by timer
• Sends OLED updates via SPI bus

But screen updates can happens faster, than SPI bus can send. What is the most optimal strategy for RTFM to regulate data flow pressure? Is this issue related to RTFM at all?

• The most obvious approach is using double framebuffer (debounce output). One frame to draw image, second frame - to snapshot image been sent via SPI. Disadvantage - memory requirements.
• Opposite would be to debounce input (stack keypresses and timer ticks). Possible, but not clear how to implement.

[perlindgren]

Hi Before summer hopefully. It should be fairly easy to port existing applications. The low level API to peripherals won't change. Best Per

…

________________________________ Från: Vitaly Puzrin <[email protected]> Skickat: den 30 april 2018 03:23:22 Till: japaric/cortex-m-rtfm Kopia: Per Lindgren; Comment Ämne: Re: [japaric/cortex-m-rtfm] Need advices for complex logic design approach (#75) Thanks for reply. Virtual Tasks and Messages (even without timing semantics) would be interesting to glue exiting RTFM interrupt handlers with business-logic domain in human-friendly way. Are there any timelines for such extension release? — You are receiving this because you commented. Reply to this email directly, view it on GitHub<https://github.com/japaric/cortex-m-rtfm/issues/75#issuecomment-385298084>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AD5naKMufSIHYiwOr-l_X5vcUceSMm7Uks5ttmeKgaJpZM4Tr93e>. {"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/japaric/cortex-m-rtfm","title":"japaric/cortex-m-rtfm","subtitle":"GitHub repository","main_image_url":"https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png","avatar_image_url":"https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name":"Open in GitHub","url":"https://github.com/japaric/cortex-m-rtfm"}},"updates":{"snippets":[{"icon":"PERSON","message":"@puzrin in #75: Thanks for reply. Virtual Tasks and Messages (even without timing semantics) would be interesting to glue exiting RTFM interrupt handlers with business-logic domain in human-friendly way.\r\n\r\nAre there any timelines for such extension release?"}],"action":{"name":"View Issue","url":"https://github.com/japaric/cortex-m-rtfm/issues/75#issuecomment-385298084"}}}

[puzrin]

Thanks for reply. Virtual Tasks and Messages (even without timing semantics) would be interesting to glue exiting RTFM interrupt handlers with business-logic domain in human-friendly way.

Are there any timelines for such extension release?

[puzrin]

@Chocol4te no, i'm interested to understand low level libraries and design approaches. Not out-of-box framework solutions. Answers in this thread were very useful.

[korken89]

If this need more conversation, please reopen this issue. Closing