[book] does it worth to pack tasks into crates?

puzrin commented 6 years ago

Upcoming book contains very good messaging example: https://japaric.github.io/cortex-m-rtfm/user/messages.html. There are some common cases (like block transfers via uart/serial/i2c buses), had to be repeated in many project. It looks attractive to arrange those to crates somehow. Questions are:

Are there any recommendations how to arrange such RTFM extensions?
Should we move in such direction or isn't it better to push such feature into HAL (or some HAL extender)?
- If yes, what should we know about intersecting such libs (with interrupts and processing inside) with RFTM priorities logic?

In other words, as user, i'd like to have "ready solution to read strings from UART" (that's only an example). And use it in RTFM. What is the optimal way to develop such crates? May be worth add some words about into the book.

PS. i'm not sure. Feel free to close anytime.

perlindgren commented 6 years ago

Hi

Well as of now, the app! is a centralized system description. This allows us to do the static analysis and code generation based on system wide information.

To embed interrupt bindings into modules or even crates requires gathering information from different modules/crates.

As of today, that is not possible using procedural macros. It is possible to do as a compiler plugin (like the linters), but those are invoked at a later stage in the rustc compiler and not intended to generate code.

Ongoing work on the Rust compiler might in the future allow what you are after. (We did some initial experiments of using the build script to parse syntax extensions (to gather crate wide info but not cross crate info), but that I believe not to be the best sustainable solution.)

So essentially, for now we are blocked by limitations of the Rust lang/and rustc implementation to a centralized system description. This does not prevent you from modularizing functionality, but interrupt bindings cannot (currently) be defined outside the app!.

Best

Per

Från: Vitaly Puzrin notifications@github.com Skickat: den 8 maj 2018 10:13:32 Till: japaric/cortex-m-rtfm Kopia: Subscribed Ämne: [japaric/cortex-m-rtfm] [book] does it worth to pack tasks into crates? (#76)

Upcoming book contains very good messaging example: https://japaric.github.io/cortex-m-rtfm/user/messages.html. There are some common cases (like block transfers via uart/serial/i2c buses), had to be repeated in many project. It looks attractive to arrange those to crates somehow. Questions are:

Are there any recommendations how to arrange such RTFM extensions?
Should we move in such direction or isn't it better to push such feature into HAL (or some HAL extender)?
- If yes, what should we know about intersecting such libs (with interrupts and processing inside) with RFTM priorities logic?

In other words, as user, i'd like to have "ready solution to read strings from UART" (that's only an example). And use it in RTFM. What is the optimal way to develop such crates? May be worth add some words about into the book.

PS. i'm not sure. Feel free to close anytime.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/japaric/cortex-m-rtfm/issues/76, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AD5naFP36bwUhz9tYCFS7OmQ7pLCCDJ3ks5twVOsgaJpZM4T2NI0.

{"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":"[book] does it worth to pack tasks into crates? (#76)"}],"action":{"name":"View Issue","url":"https://github.com/japaric/cortex-m-rtfm/issues/76"}}}

bergus commented 6 years ago

I wouldn't like RTFM to gather information from all files in the crate (or whole dependency tree). That makes it hard to find all definitions - and conflicts would lead to difficult-to-reproduce problems.

But I did imagine some kind of plugin system where a crate could define a macro that would then be explicitly passed to app!, which would expand (call) the macro and incorporate the resulting declarations. Is that a feasible approach?

perlindgren commented 6 years ago

Hi

Having ort of “local” app macros could perhaps be done in the future. If I got it right there is a proposal regarding a new test framework that allows to “export” and “gather” items. For what I understand its only within a crate (not between crates).

In the experimental “reactive objects” approach we used external files (and a build script) to emulate this behaviour. (Also not cross crate atm.)

Maybe Jorge sits on more info on the progress of the new test framework and how we could best adopt this.

Best, Per

On 24 May 2018, at 20:43, Bergi notifications@github.com<mailto:notifications@github.com> wrote:

I wouldn't like RTFM to gather information from all files in the crate (or whole dependency tree). That makes it hard to find all definitions - and conflicts would lead to difficult-to-reproduce problems.

But I did imagine some kind of plugin system where a crate could define a macro that would then be explicitly passed to app!, which would expand (call) the macro and incorporate the resulting declarations. Is that a feasible approach?

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/japaric/cortex-m-rtfm/issues/76#issuecomment-391818708, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AD5naB6vahIteO8iX5Nz9ZMruilkZoOMks5t1v8wgaJpZM4T2NI0.

{"@context":"http://schema.org","@type":"EmailMessage","potentialAction":{"@type":"ViewAction","target":"https://github.com/japaric/cortex-m-rtfm/issues/76#issuecomment-391818708","url":"https://github.com/japaric/cortex-m-rtfm/issues/76#issuecomment-391818708","name":"View Issue"},"description":"View this Issue on GitHub","publisher":{"@type":"Organization","name":"GitHub","url":"https://github.com"}} {"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://assets-cdn.github.com/images/email/message_cards/header.png","avatar_image_url":"https://assets-cdn.github.com/images/email/message_cards/avatar.png","action":{"name":"Open in GitHub","url":"https://github.com/japaric/cortex-m-rtfm"}},"updates":{"snippets":[{"icon":"PERSON","message":"@bergus in #76: I wouldn't like RTFM to gather information from all files in the crate (or whole dependency tree). That makes it hard to find all definitions - and conflicts would lead to difficult-to-reproduce problems.\r\n\r\nBut I did imagine some kind of plugin system where a crate could define a macro that would then be explicitly passed to app!, which would expand (call) the macro and incorporate the resulting declarations. Is that a feasible approach?"}],"action":{"name":"View Issue","url":"https://github.com/japaric/cortex-m-rtfm/issues/76#issuecomment-391818708"}}} { "@type": "MessageCard", "@context": "http://schema.org/extensions", "hideOriginalBody": "false", "originator": "37567f93-e2a7-4e2a-ad37-a9160fc62647", "title": "Re: [japaric/cortex-m-rtfm] [book] does it worth to pack tasks into crates? (#76)", "sections": [ { "text": "", "activityTitle": "Bergi", "activityImage": "https://assets-cdn.github.com/images/email/message_cards/avatar.png", "activitySubtitle": "@bergus", "facts": [ ] } ], "potentialAction": [ { "name": "Add a comment", "@type": "ActionCard", "inputs": [ { "isMultiLine": true, "@type": "TextInput", "id": "IssueComment", "isRequired": false } ], "actions": [ { "name": "Comment", "@type": "HttpPOST", "target": "https://api.github.com", "body": "{\n\"commandName\": \"IssueComment\",\n\"repositoryFullName\": \"japaric/cortex-m-rtfm\",\n\"issueId\": 76,\n\"IssueComment\": \"{{IssueComment.value}}\"\n}" } ] }, { "name": "Close issue", "@type": "HttpPOST", "target": "https://api.github.com", "body": "{\n\"commandName\": \"IssueClose\",\n\"repositoryFullName\": \"japaric/cortex-m-rtfm\",\n\"issueId\": 76\n}" }, { "targets": [ { "os": "default", "uri": "https://github.com/japaric/cortex-m-rtfm/issues/76#issuecomment-391818708" } ], "@type": "OpenUri", "name": "View on GitHub" }, { "name": "Unsubscribe", "@type": "HttpPOST", "target": "https://api.github.com", "body": "{\n\"commandName\": \"MuteNotification\",\n\"threadId\": 332976692\n}" } ], "themeColor": "26292E" }

et1975 commented 6 years ago

I'm totally new to RTFM, but I'd think that plugin system would be a step backwards in terms of compile-time verifiability. A bit of explicit assembly at the top in exchange for increased guarantees seems preferable.

korken89 commented 4 years ago

If this conversation is not done, please reopen. Closing [issue cleanup]

rtic-rs / rtic

[book] does it worth to pack tasks into crates? #76