diff --git a/minutes/2019-02-26.irc.log b/minutes/2019-02-26.irc.log new file mode 100644 index 00000000..ef40e5ef --- /dev/null +++ b/minutes/2019-02-26.irc.log @@ -0,0 +1,187 @@ +2019-02-26 20:05:44 ok, let's start this meeting +2019-02-26 20:06:07 i do too but imagine handing an enum to the read functions instead of generics -> always matching ALL variants even when you know what it is you get. well, anyways, let's discuss that later, have a good meeting! +2019-02-26 20:06:07 first, some reminders +2019-02-26 20:06:21 the msrv rfc needs 2 more votes to be approved: https://github.com/rust-embedded/wg/pull/304 +2019-02-26 20:06:31 to be approved this week** +2019-02-26 20:06:58 if there are no concerns within this week it will be automatically be approved next week due to how the reduced majority mechanism works +2019-02-26 20:07:20 so if you have concerns this week's your last chance +2019-02-26 20:07:44 the other bullet is related to core::arch::arm +2019-02-26 20:08:07 a PR recently landed in stdsimd adding the ACLE API to coresimd +2019-02-26 20:08:28 I'm not sure if it's already made its way into core::arch::arm on nightly +2019-02-26 20:09:01 but we need someone to drive the stabilization process of this API +2019-02-26 20:09:19 if you are interested please comment in https://github.com/rust-embedded/wg/issues/63 +2019-02-26 20:09:28 I'll post a summary comment in that thread soon-ish +2019-02-26 20:10:15 also it's not clear if or how much of an RFC we need given the precedent of core::arch::wasm being stabilized without an RFC; I'll ask the libs team in the summary comment +2019-02-26 20:11:10 if there are no volunteers from the WG we may want to ask for help on one of the next newsletters +2019-02-26 20:11:42 * japaric waits a bit to see if someone volunteers :-) +2019-02-26 20:12:31 * therealprof pauses for dramatic moment +2019-02-26 20:12:53 ok then let's move on the agenda items +2019-02-26 20:13:17 first item is @vertexclique RTOS team +2019-02-26 20:13:23 are they around? +2019-02-26 20:13:33 sorry I'm late +2019-02-26 20:13:54 I think they said they wouldn't be… +2019-02-26 20:14:07 hmm +2019-02-26 20:14:21 disasm: do you know if there's some proposal for this rtos team? +2019-02-26 20:14:54 > I am looking forward to work on `RTOS integration` and `Pure Rust RTOS` topics. Want to contribute to the WG in these working groups. My main interest is over task scheduling. +2019-02-26 20:15:22 https://github.com/rust-embedded/wg/pull/320 +2019-02-26 20:15:43 I think the resources team is not about RTOS so proposed to create RTOS team for that +2019-02-26 20:16:19 So the question is simple: do we need an RTOS team? +2019-02-26 20:16:26 The question that comes to mind for me, is this something for the WG? What is the motivation to have it in the WG? +2019-02-26 20:16:35 If so, we can create it with @vertexclique as member +2019-02-26 20:16:54 I think it would be a good thing for the WG to oversee and steer any groups looking to write an RTOS in Rust, or port an RTOS. +2019-02-26 20:17:06 A central point of contact and knowledge. Because these things will overlap to a large extent. +2019-02-26 20:17:13 korken89: dunno. However RTOS is about embedded +2019-02-26 20:17:22 to me this sound a bit like maintaining vendor specific HAL under the EWG; we discussed this before and the decision was not to maintain any of those +2019-02-26 20:17:26 For example RTFM is outside, and IMO it should be outside - it is not a common core part of the embedded ecosystem +2019-02-26 20:17:38 Yes, I agree. +2019-02-26 20:17:51 + here +2019-02-26 20:18:08 But it would be nice if there was a crate for grabbing thread context and de/serialising it. +2019-02-26 20:18:10 Maybe we need a separate section under awesome-embedded-rust +2019-02-26 20:18:25 +1 to disasm +2019-02-26 20:18:46 disasm: Yeah, that could use some refactoring, too. +2019-02-26 20:18:47 and a section under not-yet-awesome-embedded-rust +2019-02-26 20:18:53 :-D +2019-02-26 20:18:57 I see the idea, maybe towards RTOS traits? But not sure how it should gestate. Maybe somewhere where these discussions can be made to better understand what common areas are and can be put into the WG +2019-02-26 20:19:07 Depends on the PoV… +2019-02-26 20:19:22 We need something to start with +2019-02-26 20:19:41 having rtos bindings and pure rtos implementations sound like a pre-requesite for rtos traits, imo +2019-02-26 20:20:01 o/ +2019-02-26 20:20:02 Exactly +2019-02-26 20:20:03 Indeed +2019-02-26 20:20:11 Sounds like something for an RTOS team to discuss separately and report back +2019-02-26 20:20:28 RTOS study group ~ish? +2019-02-26 20:20:36 I could not care any less about a "classical" RTOS, tbh. +2019-02-26 20:20:40 Or rust-rtos org +2019-02-26 20:21:10 vertexclique: any thoughts? +2019-02-26 20:21:41 I agree that this should start as a separate org / community effort +2019-02-26 20:21:45 (https://mozilla.logbot.info/rust-embedded/20190226) +2019-02-26 20:22:52 A separate org or community effort does seem like the appropriate start +2019-02-26 20:23:01 To start collecting the ideas and see where it leads +2019-02-26 20:23:08 + +2019-02-26 20:23:14 the EWG current scope is core / arch-specific things, things tied to the compiler or std, and resources; experimenting with rtoses itself is out of scope; pointing people to those efforts is in scope however +2019-02-26 20:24:09 +1 +2019-02-26 20:24:35 +1 +2019-02-26 20:24:46 We have avr-rust as an example +2019-02-26 20:25:43 Let's move on? +2019-02-26 20:26:12 I think we are in agreement that we should not create an rtos team right now; let's have the community experiment and link to the experiments from our resources +2019-02-26 20:26:33 I'll leave a comment on GH with the conclusion +2019-02-26 20:26:54 Sounds good! +2019-02-26 20:26:58 sounds good +2019-02-26 20:27:01 ok, then let's move on +2019-02-26 20:27:08 next is @mathk *-hal deduplication +2019-02-26 20:27:26 mathk-M is around so let's have them present the topic and drive the discussion +2019-02-26 20:29:07 Yup so this is simply that I have hit some issue one some hal that was soved in other hal. And having a look at the soution shows a lot of common code that could be reused +2019-02-26 20:29:37 this is particulary true for stmXXX-hal +2019-02-26 20:29:59 Maybe try and move hals into the mcu-rs orgs to consolidate? +2019-02-26 20:30:05 So it boild down on how could we avoid such suplcation .. +2019-02-26 20:30:19 duplication* +2019-02-26 20:30:20 Can be tricky to pull of, with a lot of people involved? +2019-02-26 20:30:41 mathk-M: So what is your suggestion here? +2019-02-26 20:31:21 mathk-M: was this the case for hals within the stm32-rs org? or hals outside that org? +2019-02-26 20:31:23 An other stufff I notice is that there is differernt hal that have choose to solve some common problem slightly differently. +2019-02-26 20:31:43 mostly stm32-rs org actually +2019-02-26 20:31:47 We share common code between HAL crates in https://github.com/nrf-rs/nrf52-hal/ +2019-02-26 20:31:57 Ah +2019-02-26 20:32:00 but looking at nordic hal I can see some duplication out there too +2019-02-26 20:32:09 Not sure how well that approach works for STM32. I think Nordic is easier to handle in that regard. +2019-02-26 20:32:30 Nordic has a *slightly* smaller lineup than STM. +2019-02-26 20:32:58 trying to consolidate seems like there will be a lot of pain wrt versioning, since dependencies will change (and doesn't that require a minor ver bump?) +2019-02-26 20:33:06 one suggestion would be to add not only trait but common code to trait in embedded-hal maybe ? +2019-02-26 20:33:18 dependencies on projects already using the existing crates* +2019-02-26 20:33:29 A good reference for seeing how many different hal drivers are needed is ChibiOS, it has made great work there +2019-02-26 20:33:40 For STM32 that is +2019-02-26 20:35:26 I imagine that unformity could be achieved by having a single stm32-hal instead of several stm32X-hals? I expect that chibiOS hal looks like that. +2019-02-26 20:35:50 Yeah +2019-02-26 20:35:52 :-D +2019-02-26 20:36:00 It +2019-02-26 20:36:05 (bunch of ifdefs) +2019-02-26 20:36:13 That would be the total horror. +2019-02-26 20:36:22 It's quite a work of art, if someone wants some inspiration +2019-02-26 20:36:40 For being in C :) +2019-02-26 20:36:53 Maybe the first step would be to identify common code and see if that can be address in an uniform lib. +2019-02-26 20:37:16 a step by step process +2019-02-26 20:37:19 I would say that it's a good first step +2019-02-26 20:37:48 mathk-M: Sure. PRs welcome! +2019-02-26 20:37:49 in any case this sounds like something for the stm32-rs org to think (hard) about how to solve +2019-02-26 20:37:52 I have already identify that Timer /Systick clock could be refactor a bit. +2019-02-26 20:38:07 if there are improvements that need to be done in svd2rust or embedded-hal then the EWG can take action +2019-02-26 20:38:13 I am trying to work on it. +2019-02-26 20:38:19 japaric: +1 +2019-02-26 20:38:28 mathk-M: That's a reasonable idea. It also allows for multiple HAL impls to exist (impl diversity is good!) +2019-02-26 20:38:31 I agree with @japaric here, and give existing solutions a look +2019-02-26 20:39:46 For svd2rust a issue that could prevent refactoring is that for example derive register should be the same structure but IIUC it is not. +2019-02-26 20:40:36 ok then I think we can table this one until there's more input from the $vendor-rs orgs +2019-02-26 20:41:14 as an example there is gpioa::MODER and gpiob::MODER and I don't see why this should be different structure. +2019-02-26 20:42:00 That's because they have different reset values +2019-02-26 20:42:12 so we need to have a macro to do common studd. +2019-02-26 20:42:21 Blech. +2019-02-26 20:42:31 +1 to therealprof :P +2019-02-26 20:42:43 mathk-M: And also you shouldn't be able to write gpiob::MODER bits into gpioa +2019-02-26 20:43:08 mathk-M: in that case svd2rust could check for structural equality but that doesn't necessarily imply that all the registers / bitfields have the same semantics +2019-02-26 20:43:52 we should move onto the next item +2019-02-26 20:43:57 yes but sould we decide the one that could make sens to be merge ? +2019-02-26 20:44:02 ok +2019-02-26 20:44:06 Yeah, this is check and manually optimized in ChibiOS for example - the SVDs do not have the info sadly +2019-02-26 20:44:07 if there's more svd2rust feedback please open an issue +2019-02-26 20:44:29 ok +2019-02-26 20:44:36 next is +2019-02-26 20:44:38 - @Disasm Proper handling of write-only SPI channels +2019-02-26 20:44:53 disasm: please present the topic +2019-02-26 20:44:58 Eah +2019-02-26 20:45:13 (power mode ?) +2019-02-26 20:45:13 We have two PRs with one man trying to solve his problems +2019-02-26 20:45:33 Hmm, we missed it +2019-02-26 20:46:47 disasm: sorry go ahead +2019-02-26 20:47:01 The first problem is write-only mode in SPI. It's easy to use it in sync manner, but we need a proper example for an async. The solution proposed is to add flush() that will clear the FIFO, but it seems strange to me. +2019-02-26 20:47:21 Another way is write & dummy read +2019-02-26 20:47:59 But I don't know how to implement it efficiently. Something like in tokio: write().and_then(|| read()) +2019-02-26 20:48:06 We don't have this and_then() +2019-02-26 20:48:32 So we need to suggest some solution +2019-02-26 20:48:47 a lambda ? +2019-02-26 20:48:59 disasm: you mean a solution for the async case? +2019-02-26 20:49:07 japaric: Yes +2019-02-26 20:49:43 by 'solution' do you mean a default impl in embedded-hal? +2019-02-26 20:49:50 or an implementation pattern? +2019-02-26 20:49:57 Implementation pattern +2019-02-26 20:50:29 Do we have a good async story for any peripheral type in embedded-hal yet? +2019-02-26 20:50:41 not that I'm aware of +2019-02-26 20:50:41 could that pattern emerge once async/await is in rust? (providing we can make it work in no_std env.) +2019-02-26 20:51:05 The problem is, you need an OS to be able to tell you when things are done. +2019-02-26 20:51:23 And another problem. This man wants something like WriteOnlySPI trait to mark that his library needs only writes, but "never" reads. What is the proper way to enforce this? +2019-02-26 20:52:18 Do we do the same for UART RX and TX? +2019-02-26 20:52:34 The idea is to convert your good SPI into WriteOnlySPI if you do not have MOSI wires attached +2019-02-26 20:52:42 >you need an OS to be able to tell you when things are done. +2019-02-26 20:52:42 I've heard conflicting info about whether async implies an OS is required. +2019-02-26 20:52:47 Yes, but not. In SPI you still need to read fake data +2019-02-26 20:53:07 disasm: is this for generic code? if so then it sounds like a marker trait (SpiNeverReads) could solve this +2019-02-26 20:53:19 UART is different. +2019-02-26 20:53:48 japaric: seems like so. Do we need to add such marker to embedded-hal? +2019-02-26 20:54:12 cr1901: (off-topic: Rust's async! needs TLS atm; it doesn't need an OS) +2019-02-26 20:54:13 Sorry for being afk, I'm the one that opened the issues +2019-02-26 20:54:20 UART is not clock like SPI ? TX and RX are independent +2019-02-26 20:54:28 The async case is quite application (and OS) dependent, are there any proposed generic solutions? Or will we need a battery of different solutions depending on the background? +2019-02-26 20:54:31 disasm: What is the problem with fake reading again? +2019-02-26 20:54:41 The issue is that when you never read, hals usually overflow the rx fifo and return an error +2019-02-26 20:54:45 japaric: ack thanks +2019-02-26 20:55:00 therealprof: there is no problem, but we need to mark such SPI somehow +2019-02-26 20:55:02 So you can't just have a marker +2019-02-26 20:55:05 disasm: if it's something that a *driver* (not the impl) wants to rely on (not that I'm aware of such use case) +2019-02-26 20:55:20 then it would make sense to put the marker trait in embedded-hal +2019-02-26 20:55:30 And you also need a way to mark that an spi byte was send, to control cs +2019-02-26 20:55:48 Ok +2019-02-26 20:56:43 flip111? +2019-02-26 20:57:09 david-sawatzke: Huh? You deassert CS after you clocked in the read not after clocking out the write. +2019-02-26 20:57:25 in any case I'm not seeing how optimizing 'write only' mode has to be exposed as a bound +2019-02-26 20:57:35 in STM32 you can mark the peripheral as read disabled, or you can ignore the read overflow flag, it's not propagated to a "general error flag" +2019-02-26 20:58:17 therealprof: Then you need a matching amount of dummy reads +2019-02-26 20:58:30 nraynaud: True, but that's something the HAL impl needs to support. +2019-02-26 20:58:30 japaric: It's not optimizing, it's just a way to express that you should not treat incoming data as valid. Compile-time checked. +2019-02-26 20:59:07 david-sawatzke: Uhm, that's not how SPI works. +2019-02-26 20:59:08 therealprof I did it in my clone, but I can't send a PR because DMA is not there. +2019-02-26 21:00:35 therealprof: Your spi rx fifo could otherwise still contain old data that you'd `read` to check that everything was clocked out +2019-02-26 21:01:57 :bell: unfortunately we have run out of time +2019-02-26 21:02:34 david-sawatzke: TX is independent from RX. You can turn off the RX buffer (and signalling) in most cases as nraynaud suggested in case you're not interested in the clocked in data. +2019-02-26 21:02:35 just a final note: if you have done or seen cool embedded stuff this past week please add it to the next newsletter via PR +2019-02-26 21:02:43 david-sawatzke what device are you using? I think we can handle the situation by the function signature, a read can't happen asynchronously, so something form the software side has to start it. +2019-02-26 21:02:46 https://github.com/rust-embedded/blog/blob/master/content/2019-03-06-newsletter-16.md newsletter link +2019-02-26 21:03:44 thanks everyone for attending and see you next week! \ No newline at end of file diff --git a/minutes/2019-02-26.md b/minutes/2019-02-26.md new file mode 100644 index 00000000..ec5005ce --- /dev/null +++ b/minutes/2019-02-26.md @@ -0,0 +1,34 @@ +# Embedded WG + +- [Coordination repository](https://github.com/rust-embedded/wg) +- [Milestone issues](https://github.com/search?q=org%3Arust-embedded++is%3Aopen+milestone%3A2018&type=Issues) +- Meetings: Tuesdays 8 PM Europe/Berlin time - #rust-embedded @ irc.mozilla.org +# Attendance + +**Write your GH username or IRC handle here!** + +- japaric +- disasm +- hannobraun +- cr1901 +- korken89 +- therealprof + + +# Reminders + +- Please vote on the MSRV policy https://github.com/rust-embedded/wg/pull/304 (current vote count: 8 / 10 (33% threshold since two week has passed since first annoucement)). +- stable core::arch::arm — need someone to drive the stabilization process. https://github.com/rust-embedded/wg/pull/184#issuecomment-467346959 + +# Agenda + +- @vertexclique RTOS team - https://github.com/rust-embedded/wg/issues/318#issuecomment-466368407 + +- @mathk *-hal deduplication - https://github.com/rust-embedded/wg/issues/318#issuecomment-466400273, support for different power modes - https://github.com/rust-embedded/wg/issues/318#issuecomment-466400912 + +- @Disasm Proper handling of write-only SPI channels (https://github.com/rust-embedded/embedded-hal/pull/121), semantics of SPI `read()` function (https://github.com/rust-embedded/embedded-hal/pull/120) + +- @flip111 svd2rust-like tool for external device specification - https://github.com/rust-embedded/wg/issues/22#issuecomment-464929863 + +- Biweekly newsletter — https://github.com/rust-embedded/blog/blob/master/content/2019-03-06-newsletter-16.md +