<re_irc>
<benatar111> hello, i started the discovery book and following the install procsees i get "error: no such subcommand: `embed"
<re_irc>
<benatar111> i think i download the right GNU Arm Embedded Toolchain intaller
<re_irc>
<benatar111> after download a cl open and i follow the book instruction with "arm-none-eabi-gcc -v" and got this "gcc version 10.3.1 20210824 (release) (GNU Arm Embedded Toolchain 10.3-2021.10)" the book there is diffrent ver -> "gcc version 5.4.1 20160919 (release) (..)"
<re_irc>
<benatar111> in embed.toml i pick microbit v-2 "chip = "nrf52833_xxAA" "
<re_irc>
<benatar111> sorry i have to go to work i wanted to try and do all the setup in the morning so when i get back from work i dont have to do this, figure i ask here to see if its a common problem. i see its isn't so i will solve it when i get back from work and if i cant i will write a more appropriate detailed message
<Lumpio->
I'm pretty sure the page I linked to should solve your problem
<re_irc>
<benatar111> check it thank you
<re_irc>
<benatar111> have good day people
<re_irc>
<benatar111> fuck you right i gloss over this section in hurray and started with windows install
<Lumpio->
On second thought maybe there's a language barrier
<Lumpio->
They were nice otherwise
<re_irc>
<Jan Bronicki> lool
explore has quit [Quit: Connection closed for inactivity]
_whitelogger has joined #rust-embedded
<re_irc>
<luojia65> * #612. #612 changes whole _R and _W structure names to name of enumeration which is yet to be discussed, but we can change case to constant case first
<re_irc>
<luojia65> The name of enum can be read from enumeratedValues, which current code did not cover
<re_irc>
<James Munns> Lumpio-: I assume it was supposed to be "fuck, you're right", rather than "fuck you", but agree it's probably better not to be so explicit :)
<re_irc>
<James Munns> * you right",
<Lumpio->
probably yes
<re_irc>
<Campbell He> I just found the "svd-parser" currently ignores "noNamespaceSchemaLocation" due to the wrong code. My simple analysis and a possible solution is here: https://github.com/rust-embedded/svd/issues/204
<re_irc>
Might need someone who is familiar with xml to check whether I am right.
<re_irc>
<silvergasp> Hey, has anyone here put any thought into what an embedded friendly operating system abstraction layer (OSAL) would look like for rust? This next bit is gonna sounds like criticism. I have a lot of respect for projects like embassy, tock, rtic and use them on a regular basis. However one of the things I find rather frustrating is how viral these dependencies become. E.g. rtic has the app macro, embassy has its...
<re_irc>
... task/main macros. Once you buy into one way of doing things it becomes almost a complete rewrite if you want to switch over. I guess I'd be keen to work on something like NASA'S core flight system OSAL, but more rust centric.
<re_irc>
<dirbaio> agreed this is an unsolved problem! It's a hard one though becuase there's no way to abstract over async/blocking
<re_irc>
<dirbaio> so at the very least you'd need two abstraction layers, one for "classic" RTOSs with stackful tasks/threads, and one for async executors
<re_irc>
<dirbaio> note that you _can_ write very portable code already if you stick to the embedded-hal(-async) traits though
<re_irc>
<dirbaio> only thing you can't do is task spawning
<re_irc>
<dirbaio> for example with async, you'd have just "async fn"s in the public API and ask the user to spawn them, and use the EHA traits for all hardware interaction
<re_irc>
<dirbaio> that'll work on any async executor
<re_irc>
<silvergasp> dirbaio: Yeah I think this is true to an extent. But what I found was that writing code that was very quickly approaching a cooperative rtos anyway.
<re_irc>
<dirbaio> (and also note most of Embassy runs on any executor, not just embassy's. For example it's already working with RTIC's upcoming async support (https://github.com/Dirbaio/embassy-rtic-test))
<re_irc>
<silvergasp> dirbaio: I think I need to do a bit more reading as I only vaguely understand what you are saying here.
<re_irc>
<silvergasp> dirbaio: Awesome, I'll have a bit more of a look into it
<re_irc>
<silvergasp> In any case it must be doable. 'Standard' rust is abstracted well enough over 'Standard' OSs. So at some point there was a cross-platform shared interface that was decided upon. I imagine that deciding on that interface was not trivial and took some time with a lot of people involved.
<re_irc>
So I imagine that deciding on an interface that is general enough to allow portable app code but not so generic that it's impossible to make a useful/performant RTOS/async executor.
<re_irc>
<silvergasp> * executor, would be difficult.
<re_irc>
<dirbaio> I don't think abstracting over "classic RTOS with stackful task", "RTIC" and "async" with a single interface is doable
<re_irc>
<dirbaio> * blocking RTOS with stackful tasks",
<re_irc>
<dirbaio> * RTOS (blocking, with stackful tasks)",
<re_irc>
<dirbaio> they're 3 very very different models on how to do concurrency
<re_irc>
<adamgreig> you could just port std to the RTOS I guess, isn't that what esp32 has?
<re_irc>
<dirbaio> yep, that too, "std" is already a great interface for "classic RTOS" :)
<re_irc>
<adamgreig> arm has cmsis-rtos as an abstraction layer, which I believe someone has also already wrapped for rust
<re_irc>
<adamgreig> so in theory if an rtos provides a cmsis-rtos layer you could consume that in rust as-is
<re_irc>
<adamgreig> I assume someone has written something to adapt OSAL and CMSIS-RTOS too
<re_irc>
<adamgreig> almost as many RTOS abstraction layers as RTOSs :P
<re_irc>
<dirbaio> yeah... in the C land there's also the (varying quality) libc, libpthreads, bsd socket API ports
<re_irc>
<adamgreig> embassy and rtic aren't really RTOSs or OSs, so I don't know that it would make sense to try and wrap them as such, right
<re_irc>
<adamgreig> but the esp32 idf stuff demonstrates that you could definitely just port std, which is probably the nicest thing to do for rust?
<re_irc>
<dirbaio> it has some downsides (like forcing requiring alloc)
<re_irc>
<adamgreig> it's been done for nintendo DS too recently iirc
<re_irc>
<dirbaio> but being able to use std code just like that is awesome
<re_irc>
<dirbaio> (was surprised there, the original DS has no OS)
<re_irc>
<adamgreig> indeed, I misremembered, I saw it in an old TWIR i think
<re_irc>
<silvergasp> Hmm, so I think the line between what is an RTOS and what isn't is rather blurry. For example, in my eyes rtic behaves close enough to a "stackfull rtos". But it uses some clever tricks to reduce the scheduler down to using the hardware IP. I'm not by any means an expert on rtic so I could be waay off base here. In my head at least it's an RTOS with a hardware accelerated scheduler ๐คท.
<re_irc>
<silvergasp> I agree that the async api is fundamentally different though
<re_irc>
<dirbaio> IMO the "RTOS or not" line is: it's a RTOS if a task can get "descheduled" when blocked/sleeping
<re_irc>
<dirbaio> which implies a stack per task
<re_irc>
<dirbaio> for exmaple, RTIC won't deschedule a task that's blocked on an UART RX, it'll stay spinning preventing other tasks at same/lower prio from running
<re_irc>
<dirbaio> therefore RTIC is not a RTOS
<re_irc>
<Lachlan> So, RTOS means stackfull tasks?
<re_irc>
<dirbaio> I'd say yes?
<re_irc>
<dirbaio> actually async kinda meets my definition above ๐
<re_irc>
<dirbaio> like, from the PoV of the programmer maybe async is (feels like) an RTOS?
<re_irc>
but from the PoV of what actually runs on hardware it's not (it's state machines)
<re_irc>
<dirbaio> async is also kinda "stackful", except the "stack" is the task's Future
<re_irc>
<Lachlan> I wouldnโt call async _stack_full
<re_irc>
<silvergasp> I'm happy with the definition for the purpose of the conversation. I don't have a hard and fast definition myself. I've heard many other definitions. In any case there are RTOSs that behave in a similar manner (e.g. RTEMS). I still think that rtic could for the most part share an abstraction with a traditional RTOS.
<re_irc>
<dirbaio> "stateful tasks" maybe
<re_irc>
<dirbaio> ๐คท
<re_irc>
<dirbaio> whether the "state" is a stack or a future
<re_irc>
<dirbaio> hahaha
<re_irc>
<Lachlan> The interesting point here I think is that rtic doesnโt provide any interface to the hardware, whereas RTOSs typically provide abstractions over hardware
<re_irc>
<Lachlan> Theyโd have to, since it has to integrate into their task system
<re_irc>
<dirbaio> either way RTIC is not an RTOS because tasks don't keep any state (they never get descheduled, if you want to "yield" to let other tasks run you have to explicitly manually save all your state to resources, then return)
<re_irc>
<dirbaio> +clearly
<re_irc>
<dirbaio> hmmm I always thought C RTOSs provide hardware APIs to workaround lack of traits?
<re_irc>
<dirbaio> +one of the main reasons
<re_irc>
<Lachlan> Bit of both, Iโd say
<re_irc>
<silvergasp> Though there are RTOSs that don't support yield
<re_irc>
<Lachlan> The whole async thing lets the hardware interface be separate from the task system by providing a standard interface between them
<re_irc>
<dirbaio> so the way to write code portable across different hardware is to reimplement all hardware under the same API ๐คฃ
<re_irc>
<dirbaio> +C
<re_irc>
<dirbaio> yeah its true rtos hardware drivers need to use the rtos primitives
<re_irc>
<dirbaio> they could use an abstraction layer like cmsis-rtos
<re_irc>
<dirbaio> but RTOSs still reinvent the drivers to get a consistent API
<re_irc>
<thalesfragoso> dirbaio: Not really, since the you aren't descheduling a task, the task itself returns
<re_irc>
<dirbaio> from the PoV of the programmer it really "looks like" the task gets deschedued at the ".await"
<re_irc>
<dirbaio> it's a weird "in between"
<re_irc>
<thalesfragoso> dirbaio: The programmer still has to worry about blocking code and others no-cooperative behavior, so I think it's a clear distition
<re_irc>
<dirbaio> you can still do preemption with async
<re_irc>
<dirbaio> and you can configure RTOSs to not do preemption (cooperative only, at least within the same prio)
<re_irc>
<dirbaio> it's not so black and white :D
<re_irc>
<thalesfragoso> There is no scheduler deciding what runs and when
<re_irc>
<thalesfragoso> The programmer still has to worry about blocking code and others non-cooperative behavior, so I think it's a clear distition
<re_irc>
<silvergasp> I wonder how hard it would be to create a really granular set of traits. E.g. task, prioritised task, yield etc. So you would be able fairly quickly port between schedulers that implement the API that you use.
<re_irc>
<dirbaio> the executor is arguably a really simple "scheduler"
<re_irc>
<dirbaio> I do agree with you, I'd say embassy (or async in general) is not an RTOS but provides similar ergonomics to RTOSs
<re_irc>
<dirbaio> the good of RTOSs, without the bad (bloat, complexity)
<re_irc>
<dirbaio> because most heavy lifting is done by the compiler, not by the kernel/scheduler at runtime :D
<re_irc>
<thalesfragoso> dirbaio: But that exists outside of async
<re_irc>
<James Munns> I'll drop my totally unhelpful $0.02
<re_irc>
<James Munns> "is it an rtos" is an X/Y problem question
<re_irc>
<James Munns> like, what do you want? Do you want to juggle multiple concurrent tasks? Do you want to respond to SOME SPECIFIC stimulus within N uS?
<re_irc>
<James Munns> like, regardless of what you want, you probably _could_ do that with RTIC, or Embassy, or a main loop
<re_irc>
<James Munns> but Rust's SW ecosystem doesn't map 1:1 with C/C++'s.
<re_irc>
<James Munns> It's easier to state what you're trying to do, and what your requirements are, rather than saying "I want an RTOS".
<re_irc>
<James Munns> and with that, I'll run away and enjoy my Sunday :D
<re_irc>
<dirbaio> yeah there's similar ideas floating around the rust async WG
<re_irc>
<dirbaio> most are some variant of "fn spawn(impl Future)"
<re_irc>
<dirbaio> which neither embassy not rtic can implement because they statically allocate tasks (this is why they use macros) ๐
<re_irc>
<silvergasp> My rust macro foo is pretty limited, so I don't know what would be possible here. With embassy and the async API would it not be possible to create a "macro interface", that embassy or others implement. I know tokio has a similar set of macros.
<re_irc>
<dirbaio> that'd be a macro, not a trait
<re_irc>
<dirbaio> and there are no "macro traits" ๐
<re_irc>
<Lachlan> Itโd be cool if there were though
<re_irc>
<dirbaio> macros are cursed enough
<re_irc>
<Lachlan> Definitely not possible tho lol
<re_irc>
<Lachlan> The only way forward is through
<re_irc>
<James Munns> the alloc-enabled alloc can "spawn"
<re_irc>
<James Munns> static/no-std allocators can "spawn allocated"
<re_irc>
<James Munns> which means, "caller is responsible for making sure the task lives long enough"
<re_irc>
<James Munns> which means embassy could support that kind of API
<re_irc>
<dirbaio> ah, user has to pass in the allocated mem
<re_irc>
<James Munns> mnemos uses a non-liballoc allocator, so the async-allocator can allocate first, then pass in an allocated task
<re_irc>
<James Munns> yeah
<re_irc>
<dirbaio> you could still make an "opinionated" wrapper that does the allocation itself with whatever allocator
<re_irc>
<James Munns> dirbaio: yeah, mnemos does that
<re_irc>
<James Munns> it just doesn't exist in maitake
<re_irc>
<dirbaio> James Munns: embassy doesn't refcount wakers, so the task storage really has to live for "'static", you can't deallocate it even if the task has finished
<re_irc>
<dirbaio> +because there might still be wakers pointing to it
<re_irc>
<Lachlan> I feel like the only way that generic interface could work for all usages is if it allowed enforcing additional traits on the task somehow
<re_irc>
<James Munns> ยฏ\_(ใ)_/ยฏ
<re_irc>
<Lachlan> But then again, as the C++ standard library teaches us, a solution for all problems is no solution at all
<re_irc>
<dirbaio> "ABI break!!!"
<re_irc>
<silvergasp> I'd be happy if it didn't work for *all* use cases. I think that 80-90% of all use cases would probable be the sweet spot. As long as there is an escape hatch through the abstraction. Conceptually if I can base 90% of my code based on a common abstraction then I'd only have to rewrite 10% of my code rather than the current scenario where that situation is inverted. I think the same can be said about the embedded-hal...
<re_irc>
... crate. It does the job for 90% of use cases but every now and then you might need async multi-channel-ADC streaming over DMA, which it doesn't necessarily make sense to include in a common interface.
<re_irc>
<dirbaio> RTIC is way more than 10% of the use cases though ๐
<re_irc>
<Lachlan> Wait, what about some sort of โspawn_staticโ abstraction in core?
<re_irc>
<silvergasp> Oh should clarify. I agree that RTIC is capable of covering more than 10% of use cases. I mean if there was a common "scheduling interface" that covered 90% of use cases, and then you had to write an additional 10% of your code to be RTIC specific, that would be ideal. As it would mean that porting to/from RTIC would be significantly easier.
<re_irc>
<Lachlan> That requires the future to be statically allocated somehow
<re_irc>
<thalesfragoso> James Munns: It could be to write a runtime agnostic driver that asks for RTOS features, e.g. pretty much all of proprietary wifi drivers today
<re_irc>
<thalesfragoso> But I don't think embassy or RTIC would be enough
<re_irc>
<dirbaio> (see: the esp-wifi reinventing a mini-rtos in rust just to be able to run the wifi blob ๐)
<re_irc>
<dirbaio> +project
<re_irc>
<silvergasp> Ill just add this. RTIC is great don't get me wrong. My biggest problem that I have with it is that cross architecture support is pretty minimal. Normally I'd just choose an ARM microcontroller and call it a day as that's what I'm most familiar with. For RTIC that fits in perfectly. But with the chip shortages it means I have to be a bit more flexible with the Architectures that I use. RTIC isn't supported on every...
<re_irc>
... platform/arch. So I've either got to port RTIC to a new arch or just choose a different scheduling system. Embassy seems to work well here but there are still some challenges. So it's not that I don't want to use RTIC or embassy it's more than I want the flexibility to quickly switch between schedulers/RTOS depending on how my needs change.
<re_irc>
<Lachlan> It works on all cortex_m MCUs I believe
<re_irc>
<silvergasp> Yeah, I've got a bunch of riscv mcu's. I saw there was some risc v support when rtic was rtfm. But it seems to have been dropped.
<re_irc>
<Lachlan> Oh, gotcha
<re_irc>
<Lachlan> Riscv support would be v neat
<re_irc>
<silvergasp> In any case a generic scheduling interface is something I'm actively exploring. As I think I'll get some use out of it.
<re_irc>
<dirbaio> riscv irqs are a mess, there's like 10 different interrupt controllers out there
<re_irc>
<dirbaio> many not vectored, or without priority levels even
<re_irc>
<dirbaio> which defeats the point of rtic...
<re_irc>
<silvergasp> Haha yeah who knows I might end up back on ARM soon. The approach I'm taking at the moment is to buy all the parts I need to build something. Then designing the pcbs. Got sick of designing things and then having the parts go out of stock.
<re_irc>
<dirbaio> then while designing you discover the part you picked won't quite work as you thought it would...
<re_irc>
<dirbaio> and then you're sitting on 10k pcs of useless chips :D
<re_irc>
<silvergasp> Yup, haha. Though I'm mostly building low volume scientific instruments so it's less of a problem ๐ but I do have a stockpile or some rather useless parts
<re_irc>
<silvergasp> Still beats the hell out of final revision: 15, without ever making a prototype.
<re_irc>
<chemicstry> where I work we have reusable chips, which get resoldered on newer revision boards ๐ it's almost at a point where rentable chips kinda makes sense ๐
<re_irc>
<chemicstry> * make
<re_irc>
<silvergasp> Haha yeah at one point I was buying st nucleos and desoldering the micros, so I didn't have to redesign something ๐ .
<re_irc>
<silvergasp> In any case risc-v micros seem to stay in stock longer than arm. With maybe the exception of the rpi picos. Which might be the direction I go next.
<re_irc>
<dirbaio> rpi pico is arm
<re_irc>
<dirbaio> ah sorry, I misread ๐
<re_irc>
<chemicstry> Probably because riscv is relatively new. Less tooling and libs, the giants (automotive) are not buying them by billions yet
<re_irc>
<dirbaio> yes, the rp2040 stays in stock even if it's arm
<re_irc>
<dirbaio> ...probably because no one is using it in commercial products. Just like riscv! :D
<re_irc>
<silvergasp> Yeah I've found the riscv part of things to be pretty great. For the most part it's not that different to development on ARM. The ISA is well thought out which makes writing assembly a lot easier. The only thing that leaves a lot to be desired is the peripheral IP on most riscv micros. I think that'll change with time. But it was a massive let down coming from primarily using stm32s with an excessive number of...
<re_irc>
... remappable peripherals. I haven't run into many problems with the interrupt IP, but I haven't really been pushing the envelope in the same way a project like RTIC would.
<re_irc>
I'm aware that I'm skewing the conversation a little off topic... sorry
<re_irc>
<dirbaio> noo, it's interesting ๐
<re_irc>
<Lachlan> I wonder if st will ever switch to riscv
<re_irc>
<Lachlan> I could keep all the same peripherals
<re_irc>
<Lachlan> * They
<re_irc>
<dirbaio> there's clones that use riscv but keep st peripherals, the "gd32v" chips for example
<re_irc>
<Lachlan> Clones? From ST?
<re_irc>
<silvergasp> dirbaio: Well in that case then. The interrupt system in risc-v is actually fantastic. though I can understand why it would be a pain from the perspective of a RTIC maintainer. It's super extensible, so if you are working with riscv+fpga you end up with a super expressive interrupt system. So you can have 100 individual interrupts that aren't bundled as they would be on ARM. So you can easily build something that...
<re_irc>
... does exactly what you need. It's essentially "you only pay for what you use" for interrupts.
<re_irc>
<silvergasp> Lachlan: Gigadevice makes an ST clone, which has the same register layout as ST, so they are like a drop in replacement for stm32f0s
<re_irc>
<dirbaio> yup, totally! the disadvantage is on the software side you now need many drivers, so you can no longer handle irqs in "arch support" crates like "cortex-m-rt"
<re_irc>
<dirbaio> the fun thing about "gd32v" is it's the same register layout as ST, but it's riscv
<re_irc>
<dirbaio> they even copy the part numbers... "GD32VF103C8T6" ๐
<re_irc>
<silvergasp> Yeah they origionally had just ARM clones. And then they pulled out the Cortex-M0 IP and dropped in a risc-v CPU. So they do both.
<re_irc>
<silvergasp> I've got a few of the risc-v versions
<re_irc>
<silvergasp> dirbaio: I wonder if it'd be doable to generate a spec for the interrupt IP, that could be used for code generators similar to svd2rust.
<re_irc>
<chemicstry> I know that their first clones (ie. the famous GD32VF103C8T6) are not completely compatible and require firmware changes, but maybe it got better with newer ones
<re_irc>
<chemicstry> * (i.e.
<re_irc>
<chemicstry> * GD32F103C8T6)
<re_irc>
<silvergasp> Yeah honestly I wasn't that stoked with the ARM clones. I got duped a couple years ago buying what I thought where ST micros but they where repackaged fakes. I could only tell, because there where some edge cases where things weren't working, and the ADC's where basically exponential instead of linear :)
<re_irc>
<thalesfragoso> dirbaio: And they mix peripherals too, e.g. the USB from that chip is actually a copy of the F4 instead of the F1
<re_irc>
<dirbaio> oh, wtf
<re_irc>
<thalesfragoso> They even copy que flash wait states from the F1, even though the chip doesn't really need it, haha
<re_irc>
<silvergasp> Yeah they weren't great. You'd even get parts floating around on ebay, that had the full stm32f0 part numbers embossed into them. But then had all the weird register maps. I'm not sure if it was gigadevices making the counterfeits or some other shady company, but they left a sour taste...
<re_irc>
<silvergasp> A lot of the blue-pill boards you see on aliexpress/ebay are all gd32s with stm32 part numbers embossed on the package
GenTooMan has quit [Ping timeout: 244 seconds]
<re_irc>
<silvergasp> The risc-v versions aren't too bad though, as they aren't trying to be something that they are not