<re_irc>
<Lachlan> Here is the raw value of the SR register: "00000000000001010000000000000000"
<re_irc>
<Lachlan> Keep in mind this doesn't error when "opt-level = 1" isn't set
<re_irc>
<James Munns> that sounds like a timing thing
<re_irc>
<James Munns> like, it's probably (much) slower on a lower opt level
<re_irc>
<James Munns> are you trying to do something before the erase is complete or something?
<re_irc>
<James Munns> if it _isn't_ a timing thing, "works on lower opt levels" is usually undefined behavior
<re_irc>
<Lachlan> I'm not doing anything weird
<re_irc>
<Lachlan> I erase the bank and then do stuff afterwards
<re_irc>
<dirbaio> the ECC chunk is 8 bytes
<re_irc>
<Lachlan> And, from what I can tell, the first write doesn't fail
<re_irc>
<dirbaio> you have to write in 8 byte chunks
<re_irc>
<dirbaio> check addr is multiple of 8
<re_irc>
check data len is multiple of 8, pad it if not
<re_irc>
<Lachlan> Data is always 512 bytes
<re_irc>
<Lachlan> It fails after a couple of writes, not always the same one
<re_irc>
<James Munns> that makes me wonder if the HAL isn't checking "done" correctly, and it works when you are slower
<re_irc>
<Lachlan> That sounds plausable
<re_irc>
<dirbaio> ah no ECC chunks are 256 bits, so 32 bytes 😂
<re_irc>
<dirbaio> I think it was L4 that was 8 bytes (?)
<re_irc>
<James Munns> do you need to _wait_ for the EOP bit to be set?
<re_irc>
<James Munns> right now it only clears it if set, and I guess there could be a window where you're not busy but the eop isn't set?
<re_irc>
<James Munns> I'm guessing wildly
<re_irc>
<James Munns> > EOP1 flag is set when a programming operation to bank 1 completes. An interrupt is
<re_irc>
> generated if the EOPIE1 is set to 1. It is not necessary to reset EOP1 before starting a new operation. EOP1 bit is cleared by writing 1 to CLR_EOP1 bit in FLASH_CCR1 register.
ni has quit [Ping timeout: 258 seconds]
ni has joined #rust-embedded
<re_irc>
<Lachlan> I added "while regs.sr.read().eop().bit_is_clear() {}" and all the writes complete successfully
<re_irc>
<James Munns> :D
<re_irc>
<James Munns> yaaaaay shots in the dark
<re_irc>
<Lachlan> Good thought
<re_irc>
<James Munns> "STM32H7: Oh, I'm not _busy_, but I'm still programming!"
<re_irc>
<James Munns> ಠ_ಠ
<re_irc>
<Lachlan> Interestingly, this works:
<re_irc>
while regs.sr.read().eop().bit_is_clear() {}
<re_irc>
<James Munns> Tho the default value is "0b11", which isn't even mentioned on that table? (the highest value is "0b10"?
<re_irc>
<dirbaio> 🤷
cr1901_ has joined #rust-embedded
<re_irc>
<James Munns> okay, sleep, is 5am
<re_irc>
<James Munns> dirbaio go to bed too :D
<re_irc>
<dirbaio> 😭
<re_irc>
<Liam Rosenfeld> Hi, I'm currently trying to write a kernel for a raspberry pi 3b and am running into an issue that I am struggling to solve. Calling "write_fmt" (but not "write_str") causes the kernel to crash. This only occurs when run on real hardware (it works fine in qemu with the raspi3b machine preset—making it harder to debug). The only thing I can find on that issue online is needing to enable the "strict-align"...
<re_irc>
... feature but from what I can tell, it is already enabled for the "aarch64-unknown-none target".
<re_irc>
Any guidance on this would be much appreciated. My current guess is that it's a stack pointer issue because from my testing, qemu does not care about the stack pointer being initialized correctly. However, I'm not sure what about "write_fmt" is causing the issue, so I'm not sure how to fix it.
cr1901 has quit [Ping timeout: 252 seconds]
cr1901_ is now known as cr1901
<re_irc>
<Lachlan> I was definitely doing a lot of stuff between writes, so I dunno
<re_irc>
<Lachlan> Oh, that's in the loop
<re_irc>
<Lachlan> Yeah, maybe that extra few cycles was necessary
<re_irc>
<chemicstry> I second using a debugger, helped me a lot when developing bare-metal on rpi4. Oh and you can use these cheap ftdi usb-uart adapters as JTAG with openocd
Amadiro__ has joined #rust-embedded
Amadiro_ has quit [Ping timeout: 272 seconds]
gsalazar has quit [Ping timeout: 240 seconds]
<re_irc>
<henrikssn> Does anyone know a terminal/CLI which plays well with rust embedded over UART or RTT?
<re_irc>
<henrikssn> I was almost starting to write something and then thought to myself: I can't be the first one with this problem...
bjc has quit [Remote host closed the connection]
aspe has joined #rust-embedded
<XMPPwocky>
are you looking for a readline-like library, or something like picocom?
<re_irc>
<Chris [pwnOrbitals]> henrikssn: What doesn't play well in your use cases ? Never had a problem tbh
<re_irc>
<ryan-summers> Pyserial
<re_irc>
<ryan-summers> * Pyserial's miniterm works well for me
<re_irc>
<henrikssn> I want a term like thing running on the MCU which allows me to set variables and query state
<re_irc>
<Chris [pwnOrbitals]> Ah like a GDB session ?
<re_irc>
<ryan-summers> Why not just use GDB at that rate?
<re_irc>
<chemicstry> I also have a similar use case, but haven't tried this lib yet. Seems to be a bit old
<re_irc>
<allexoll> has someone found a way to deal with large PACs that rust-analyzer takes a long time to check on HAL save?
aspe has quit [Quit: aspe]
bjc has joined #rust-embedded
<re_irc>
<ryan-summers> Crates being old is never a reason to avoid them imo
<re_irc>
<ryan-summers> There's a lot of crates that have been around for a while that are still perfectly usable
<re_irc>
<Clark Kozak> Is there any Rust and RPI 4 getting started guide? I have some wires, an LED, and resistor, and a breadboard and I want to make a light blink
<re_irc>
<dirbaio> these are for running under linux though, not bare-metal
<re_irc>
<Clark Kozak> Oh that's interesting. Are RPI's not the microcontroller of choice for Rust embedded devs?
<re_irc>
<dirbaio> raspberry pi's aren't really microcontrollers, they're more like small computers designed to run linux
<re_irc>
<dirbaio> and then there's raspberry pi pico, which is a "real" microcontroller, doesn't run linux
<re_irc>
<Clark Kozak> ah gotcha
<re_irc>
<Clark Kozak> so then I don't need to have linux installed on a RPI 4B?
<re_irc>
<dirbaio> the easy way to use a rpi4 is with linux
<re_irc>
<dirbaio> you write a program that runs under linux, that uses gpio or whatever
<re_irc>
<K900> You can technically run bare metal on a Pi, but it's rather annoying and most of the "bare metal" stuff won't actually be bare metal because you still have to go through Broadcom's proprietary firmware
<re_irc>
<K900> There's some reverse engineered open source firmware for older models, but nothing for a Pi4 I think
<re_irc>
<K900> * the
<re_irc>
<ryan-summers> I've done real bare metal on the Pi 2, but yeah, it's not actually open sourced hardware
<re_irc>
<ryan-summers> So only portions of the silicon are publicly documented
<re_irc>
<ryan-summers> And generally it's all just leaked datasheets
<re_irc>
<K900> Some NixOS folks actually had it booting on completely open firmware on a Pi3
<re_irc>
<K900> But like half the peripherals didn't work
<re_irc>
<K900> But it booted!
<re_irc>
<ryan-summers> I think even I still needed the initial setup.bin blob somewhere on the SD card
<re_irc>
<ryan-summers> Or boot.bin or something
<re_irc>
<ryan-summers> But yeah, even then getting USB and ethernet and such is a chore
<re_irc>
<K900> Yeah you probably did
<re_irc>
<K900> If you didn't, you would have remembered
<re_irc>
<K900> It is _very janky_
<re_irc>
<ryan-summers> Yeah, very likely :P Was like 7 years ago at this point
<re_irc>
<ryan-summers> Also, I hate that I just said that. I'm not that old :(
<re_irc>
<K900> Well, for starters, the early stage firmware runs on the GPU
<re_irc>
<K900> So you need to build a patched GCC 5.something
<re_irc>
<ryan-summers> Yup, definitely didn't do that
<re_irc>
<K900> That can target the completely bespoke VLIW-ass ISA the GPU uses internally
<re_irc>
<K900> And then compile the early firmware with that
<re_irc>
<Clark Kozak> huh thata's something else
<re_irc>
<Clark Kozak> the more you know 🌈
<re_irc>
<Clark Kozak> huh that's something else
<re_irc>
<James Munns> So apparently the circuit/micropython folks got bare metal working on the Pi4
<re_irc>
<James Munns> it's likely still using blobs
<re_irc>
<James Munns> but it might be an interesting read if you're going down that route
<re_irc>
<Clark Kozak> Sounds like an interesting read! I don't know if I do want to go down that road for actually play on the RPI. I want to make a LED blink so it looks like going through linux is the way to do it
<re_irc>
<James Munns> Unless you want to learn OS things, going with linux is probably a great first choice :)
<re_irc>
<James Munns> still lots of hardware stuff to learn, without trying to do EVERYTHING by yourself at once :)
<re_irc>
<K900> James Munns: Yeah that's using downstream firmware
<re_irc>
<Clark Kozak> yeah exactly. One layer of abstration at a time
<re_irc>
<K900> And a good chunk of the Linux machinery, weirdly
aspe has joined #rust-embedded
<re_irc>
<Clark Kozak> so then, how do I flash a program on the RPI? Would I need NOOBS in as a SD....?
<re_irc>
<K900> You don't "flash" anything
<re_irc>
<K900> You just copy it over and run it
aspe has quit [Client Quit]
<re_irc>
<K900> Like a normal Linux system
<re_irc>
<K900> Because it is
<re_irc>
<K900> You don't even need to write a program, technically, you can just control the GPIOs by writing to sysfs
<re_irc>
<Clark Kozak> 😂 omfg cooool.
<re_irc>
<Clark Kozak> So then I would install Rust on the machine itself?
<re_irc>
<K900> That is a thing you can definitely do
<re_irc>
<Clark Kozak> or the compiled file
<re_irc>
<K900> Or you can cross-compile and copy over SSH or whatever
<re_irc>
<Clark Kozak> sick
<re_irc>
<Clark Kozak> and then...just run it?
<re_irc>
<K900> Yes
<re_irc>
<ryan-summers> As an aside, I'm very much not a fan of circuitpython/micropython for robust systems :^)
<re_irc>
<K900> Like literally it's a normal Linux computer
<re_irc>
<K900> You can completely treat it like one
<re_irc>
<ryan-summers> Yeah it has a desktop and everything
<re_irc>
<ryan-summers> The raspberry pi is a quad core 1GHz processor.
<re_irc>
<ryan-summers> Oh, 1.5GHz now
<re_irc>
<K900> It runs on horrifying cursed garbage but the user experience is mostly normal Linux
<re_irc>
<Clark Kozak> well; it would if I had another monitor 😂 i have this 7" lcd to use. I'll swing by the store and pick up a monitor
<re_irc>
<K900> (and it's not like other computers run on non-cursed non-garbage)
<re_irc>
<K900> Clark Kozak: You can just SSH into it
<re_irc>
<K900> It should have SSH enabled by default IIRC
<re_irc>
<ryan-summers> All silicon is cursed. Its how we get the magic into it
<re_irc>
<K900> Raspbian that is
<re_irc>
<Clark Kozak> K900: oh that's an idea
<re_irc>
<Clark Kozak> would it have to be on the same network?
<re_irc>
<K900> If you can run an Ethernet cable to it from something that does DHCP
<re_irc>
<K900> It should just work
<re_irc>
<Clark Kozak> oh fuck yeah
<re_irc>
<K900> (assuming Raspbian again)
<re_irc>
<ryan-summers> Yeah I have a raspberry PI that runs in my office as my MQTT + telemetry server
<re_irc>
<Clark Kozak> yeah i got NOOBS
<re_irc>
<Clark Kozak> let's see..
<re_irc>
<Clark Kozak> well
<re_irc>
<Clark Kozak> i may have to reflaash cuz i didn't set up SSH in the rpi-imager
<re_irc>
<K900> Mine runs NixOS and the entire Grafana stack
<re_irc>
<ryan-summers> Influxdb cloud is nice to just not worry about that stuff :P
<re_irc>
<ryan-summers> But I'
<re_irc>
<ryan-summers> * I'm just using it for dev prototypes
<re_irc>
<K900> Yeah I've got a few sensors going into it
<re_irc>
<K900> So cloud is _more_ effort, not less
<re_irc>
<Clark Kozak> personal cloud ^_^
<re_irc>
<Clark Kozak> errryone gets a nimbus
<re_irc>
<K900> Oh nice
<re_irc>
<K900> I went to check on it and noticed one of my promtails died
<re_irc>
<K900> Should probably set up alerts for my alerts
<re_irc>
<lulf> fyi there is public and free mqtt/coap/http connectivity at https://sandbox.drogue.cloud/ - I'm obviously biased here, but I'm using it for several personal hobby projects
<re_irc>
<lulf> +too
<re_irc>
<lulf> +(and open source)
<re_irc>
<ryan-summers> Given that my devices are controllable via MQTT, I definitely don't want to connect them to a public cloud until we get TLS set up :P
<re_irc>
<ryan-summers> Don't want a random stranger setting my office on fire
<re_irc>
<lulf> Yeah (I should mention it does only support MQTT and HTTP over TLS)
<re_irc>
<lulf> * Yeah, I should mention it does only support MQTT and HTTP over TLS
<re_irc>
<lulf> CoAP does not yet support TLS
<re_irc>
<lulf> * DTLS
<re_irc>
<lulf> +endpoint
<re_irc>
<ryan-summers> I actually wanted to take a look at the drogue-tls stuff and maybe make it generic for smoltcp stacks
<re_irc>
<ryan-summers> Tbd if I will have time in the near term, but there's interest for some of Quartiq's hardware
<re_irc>
<ryan-summers> Would be nice to have lab equipment controlled via cloud brokers for sure
<re_irc>
<ryan-summers> Ooh lovely. I always wondered how tightly coupled it was to drogue
<re_irc>
<ryan-summers> My assessment was "not very"
<re_irc>
<ryan-summers> Really happy to see that exists though, hopefully can help out in the future :)
<re_irc>
<lulf> Yeah, this was the reason for renaming, it's not intended to be drogue specific
<re_irc>
<Clark Kozak> K900: _i'm in_ (he said in a hacker voice)
<re_irc>
<Lachlan> How can I go about resetting the clock configuration completely before jumping over to the app?
<re_irc>
<Lachlan> Is it the "CEC" peripheral?
<re_irc>
<James Munns> Depends on the hardware. Not sure if the H7 has like an RCC::reset_all() flag.
<re_irc>
<Lachlan> Nope, nvm lol
aspe has joined #rust-embedded
<re_irc>
<adamgreig> yea, just gotta write all the rcc registers to their reset values, which are stored in the PACs at least
<re_irc>
<adamgreig> room meeting time again! agenda is https://hackmd.io/P-XSJ2lLTP6unuBAQ3e7nA, please add anything you'd like to announce or discuss and we'll kick off in 5min
<re_irc>
<Lachlan> Will resume after meeting is over
<re_irc>
<James Munns> (the panic-recurses thing hasn't been triaged yet, might be good to mention in the meeting for awareness)
<re_irc>
<adamgreig> you're not making life easy with this "reflash firmware and start running without resetting", heh
<re_irc>
<James Munns> adamgreig: "serialize and pass current config to app from BL", or "just do all the clock config in bootloader", or "make sure app doesn't assume default states" are all alternative approaches to this, btw.
<re_irc>
<Lachlan> James Munns: Yeah, I'm considering doing that, at least for the clock which seems more difficult to reset.
<re_irc>
<adamgreig> yea, I'd probably have the app write whatever config it needs from scratch regardless of current rcc state, and then the bootloader can do whatever
<re_irc>
<adamgreig> rcc has reset bits for every peripheral... except rcc :P
<re_irc>
<adamgreig> ok, let's start! a fairly quiet week on the whole, anyone have any announcements?
<re_irc>
<eldruin> I just read that drogue-tls got renamed embedded-tls. any update there?
<re_irc>
<lulf> The embedded-tls 0.6.0 was released, mostly just renaming and a few bugfixes from newam
<re_irc>
<eldruin> sounds good :)
<re_irc>
<adamgreig> cool!
<re_irc>
<James Munns> Not sure if you've tweeted about it lately, but that's probably worth a post/tweet just saying "not just for drogue anymore!" :D
<re_irc>
<eldruin> yeah maybe some post about the project vision
<re_irc>
<lulf> James Munns: Most of drogue is not "just for drogue" but get your point. Would be good to write some more about it :)
* re_irc
lulf should stop naming creates drogue-this-and-that
<re_irc>
<James Munns> I'm just excited to retweet things all the time :)
<re_irc>
<adamgreig> essentially people may have believed that a double panic would abort but instead it recurses, blowing the stack
<re_irc>
<adamgreig> I guess right now we'll wait and see if this is considered a bug in rust vs a requirement to update some docs
<re_irc>
<adamgreig> but if you have a nontrivial panic handler you might want to check if it can panic
<re_irc>
<adamgreig> is that about it, James Munns?
<re_irc>
<James Munns> yup!
<re_irc>
<James Munns> (and props to diondokter to being the one that found it, I just wrote it up)
<re_irc>
<newam> I appreciate these bugs being highlighted here before I find them out myself 😅
<re_irc>
<adamgreig> stack overflow? in MY rust???
<re_irc>
<adamgreig> ok, well we'll keep updated on how that progresses anyway!
<re_irc>
<adamgreig> quick update on cortex-m, 0.7.5 is pretty much ready to go but just needs a quick test that the inline asm does actually work on stable, I meant to get to it last week but didn't... if anyone wants to give that a go please go ahead, otherwise I'll try and test it and then we can merge that and get it released
<re_irc>
<adamgreig> (0.7.5 allows you to enable the inline-asm function on stable rust)
<re_irc>
First panic is a softer panic, where i try to send things out of Ethernet/serial but using panicable functions. The second time it panics, i just skip all of that and do a harsher routine which will manually abort
<re_irc>
<Lakier15> adamgreig: I actually personally make use of the fact that I can recurse.
<re_irc>
<adamgreig> how do you tell if it's the second time?
<re_irc>
<adamgreig> and carried over from last week, there was some discussion of the discovery book's indirect dependency on defmt 0.2 via rubble via microbit, I don't know if anyone's had thoughts since?
<re_irc>
<Lakier15> With an atomic that gets set the first time it panics, at the entry of the panic routine
<re_irc>
<adamgreig> aah, nice
<re_irc>
<adamgreig> so what you're saying is we can't make double panics abort because actually people are using this feature 😆 https://xkcd.com/1172/
<re_irc>
<dirbaio> rubble is now archived as unmaintained, since 7 days ago
<re_irc>
<Lakier15> Pretty much 🤣🤣🤣
<re_irc>
<adamgreig> dirbaio: ah, ok, so probably best drop if microbit drop it from their deps and then defmt 0.2 will vanish from discovery book
<re_irc>
<adamgreig> is that therealprof ?
<re_irc>
<James Munns> Lakier15: FWIW, this is basically what "std" does in "unwind" mode
<re_irc>
<dirbaio> what's the issue? "microbit" doesn't depend on "rubble" does it?
<re_irc>
<dirbaio> there's just one example that does
<re_irc>
<James Munns> (e.g. it tries to unwind until a second panic, then aborts)
<re_irc>
<adamgreig> I thought the example's dependency was somehow coming in to the discovery book? someone was having an issue where it brought in defmt 0.2
<re_irc>
<adamgreig> James Munns: ah, makes sense, so maybe the answer is docs that say if you write a panic handler that might panic, consider making it reentrant using an atomic?
<re_irc>
<adamgreig> but looking now, I don't see it exactly...
<re_irc>
<therealprof> adamgreig: Sorry, wasn't paying attention. I'll guess we'll do that then.
<re_irc>
<James Munns> Yeah, that would be part of the "docs update", either for e-r-book or somewhere else.
<re_irc>
<James Munns> Potentially (maybe) we could get the corelib to do that for us, and "UDF" on re-entrant calls
<re_irc>
<James Munns> but honestly that's probably not the best answer anyway.
<re_irc>
<adamgreig> dirbaio: ah, the problem is the microbit crate depends on defmt 0.2 because otherwise its example that uses rubble wouldn't buid
<re_irc>
<James Munns> (the only "prior art" for this is that the unstable "panic immediately abort" feature generates a UDF for every panic)
<re_irc>
<therealprof> adamgreig: Yeah, it's a weird depedency loophole. I didn't quite catch why it's actually there but...
<re_irc>
<dirbaio> oh whoops
<re_irc>
<dirbaio> yeah you can't mix defmt 0.2 and 0.3 in the same binary
<re_irc>
<therealprof> Somehow the examples being their own crates in the same workspace bunches the dependencies together.
<re_irc>
<adamgreig> I think it's not that it bunches them together (maybe?) so much as that the example won't build if microbit uses defmt 0.3 and the example uses rubble that uses defmt 0.2
<re_irc>
<dirbaio> so either update rubble to defmt 0.3, or drop the rubble example...
<re_irc>
<adamgreig> weird, I guess it must be that actually, nothing else in microbit except examples ues 0.2?
<re_irc>
<Liam Rosenfeld> TimSmall: I don't currently but I will try to set that up. Thank you for the resource.
<re_irc>
<adamgreig> I don't really see how the dependency in the example is making its way out then, weird 🤷
<re_irc>
<eldruin> does anybody know the backstory about rubble being archived? just no time available or did they deem it a dead end? otherwise it might make sense to transfer it to the r-e-c. I always thought it was a cool project but never got to play with it
<re_irc>
<therealprof> adamgreig: That's exactly the problem. Otherwise this example could use defmt 0.2 and the rest defmt 0.3 but they have to be all the same version despite all examples never being part of a the same binary.
<re_irc>
<adamgreig> but why does that even matter to the microbit crate which doesn't use any of the examples?
<re_irc>
<therealprof> -a
<re_irc>
<dirbaio> if microbit pulls defmt 0.3, and rubble pulls defmt 0.2, it will fail to build even without the cargo workspace
<re_irc>
<therealprof> adamgreig: That's the part I don't understand. The example dependencies are somehow becoming microbit dependencies.
<re_irc>
<adamgreig> yea, but microbit doesn't use defmt at all, only the examples?
<re_irc>
<therealprof> That's the change I just PRed to bump defmt to 0.3.
<re_irc>
<therealprof> Nothing in the main lib.
<re_irc>
<therealprof> (or libs)
<re_irc>
<adamgreig> yea, weird
<re_irc>
<adamgreig> oh well
<re_irc>
<adamgreig> thanks! I guess that resolves the discovery book issue
<re_irc>
<adamgreig> final thing on the agenda is someone added talking about adding an org-level readme to the github org, which sounds like a nice idea
<re_irc>
<therealprof> I'll have to do the release first, will do in a bit.
<re_irc>
<eldruin> sounds good, maybe we can get most of it from the wg readme
<re_irc>
<adamgreig> we'd need a new .github repo and add the readme in there I believe, shall I set that repo up and then we can discuss on PR the readme contents?
<re_irc>
<mabez> I added it, it's been a pretty nice addition to the esp-rs org, and I think it'll especially help the r-e org because most new people won't know to look at the WG repo :)
<re_irc>
<therealprof> Ah, so it squeezes the README inbetween the header and repos.
<re_irc>
<therealprof> Nice.
<re_irc>
<adamgreig> would anyone like to have a go at a first version of a readme?
<re_irc>
<eldruin> hmm I can make a first draft
<re_irc>
<adamgreig> 👍️ thanks! happy to review and help with wording etc
<re_irc>
<adamgreig> good suggestion mabez!
<re_irc>
<adamgreig> ok, that's all from the agenda, did anyone else have anything to talk about?
<re_irc>
<Lachlan> the bootloader works!
<re_irc>
<adamgreig> cool, let's finish the meeting here then, thanks all!
<re_irc>
<James Munns> Thanks adamgreig !
<re_irc>
<Clark Kozak> therealprof: which repo is this from?
<re_irc>
<adamgreig> looks like cortex-m 0.7.5 works, inline-asm on stable here we go
<re_irc>
<therealprof> Clark Kozak: microbit
<re_irc>
<henrik_alser> eldruin: Would it be possible to have a new alpha of embedded-hal-async released?
<re_irc>
<eldruin> yes, definitely
<re_irc>
<eldruin> will do later
<re_irc>
<eldruin> * do,
<re_irc>
<henrik_alser> You’re awesome! No rush!
<re_irc>
<Tom> what does a "safe" rust look like compared to normal rust?
<re_irc>
<Tom> like what all is required in that, is that just a big check to TUV or something to have them rubber stamp things?
<re_irc>
<Tom> what does a "safety certified" rust look like compared to normal rust?
<re_irc>
<adamgreig> Defining what exactly that means is half the job! Really depends what industry you're in and what your actual requirements are
<re_irc>
<adamgreig> Have you seen https://ferrous-systems.com/ferrocene/ ? They're working on an ISO26262 qualified rustc, which has a somewhat specific set of things to demonstrate
<re_irc>
<adamgreig> Plenty of other standards though
<re_irc>
<Tom> I did see ferrocene, and was asking directly because of that!
<re_irc>
<Tom> I guess I'm most used to hearing about TuV and whatever its safety certification are, but to me it always seemed like a bit of a joke, freertos is "safe" somehow
<re_irc>
<Tom> like what about safertos vs freertos makes it "safe" other than a check was handed to someone and they stamped it so
<re_irc>
<adamgreig> There's typically some specific set of requirements to be met, often around process and documentation as much as like "we checked it doesn't have bugs"
aspe has quit [Quit: aspe]
<re_irc>
<Tom> I suppose that makes some sense, so perhaps less about potential misteps given API usage or formal validation of correctness
<re_irc>
<Tom> -perhaps
aspe has joined #rust-embedded
<re_irc>
<adamgreig> This presumably sounds very vague :p it might involve someone auditing the code base, but equally important is verifying that processes are in place to guide how development is done, how bugs are handled, that sort of thing
<re_irc>
<James Munns> safertos is only a subset of freertos, has a different scheduler iirc, and has done all the paperwork and validation associated with qualification
<re_irc>
<adamgreig> It's very rare to formally validate correctness but some levels of safety critical requirements will need that
<re_irc>
<adamgreig> There's usually an increasing number of demands depending on just how critical the thing is
<re_irc>
<James Munns> "formal" in safety critical typically means "done formally", rather than "formal verification", if that makes sense
<re_irc>
<James Munns> where "formal" means "done in accordance with some established process"
<re_irc>
<adamgreig> Like, maybe you insist on at least 80% test coverage (by lines of code) for your web app, and maybe someone else wants 100% coverage of all possible branches through the code, and someone else wants you to check the source and the compiled machine code are equivalent too
<re_irc>
<James Munns> EXCEEDINGLY few things even in safety critical are "formally verified"
<re_irc>
<adamgreig> Yea, you do anything you can to avoid needing that :p
<re_irc>
<James Munns> (like, usually only the very highest requirement items are done, and even then, typically only partially, as in some part of the scheduler or control algorithm or something)
<re_irc>
<adamgreig> Usually there's some cheaper or easier route, like a hardware monitor that will shut down the software entirely instead
<re_irc>
<Tom> This to me, does make me feel like safety certified does much of anything to actually make things safer
<re_irc>
<Tom> * doesn't
<re_irc>
<James Munns> ¯\_(ツ)_/¯
<re_irc>
<adamgreig> It stops people taking a lot of shortcuts in development that historically have led to safety problems
<re_irc>
<Tom> that makes sense if nothing else
<re_irc>
<adamgreig> Like, regulations on how many hours a truck driver can drive a day don't physically stop drivers doing longer, but they do make it harder for companies to insist drivers do illegal overtime, so on balance fewer crashes
<re_irc>
<James Munns> It also follows established processes, so it's easier for OTHER people to catch problems, or requires process steps that make "a missing or not-followed plan" much easier to see.
<re_irc>
<adamgreig> Standards that say you need a documented process for managing software development can't make you write good code (if only we knew how to do that...) but they do help encourage what we think are best practices for important areas
<re_irc>
<Tom> So its a formal process of development, less about a technical test validation by a lab. It's less like UL testing things to ensure it meets the safety requirements (which is what I always thought about when I thought safety)
<re_irc>
<Tom> e.g. no lab test pushing things to a breaking point to get certified
<re_irc>
<adamgreig> There's elements of both, depending on what level of criticality it is
<re_irc>
<James Munns> that's a good way to think about it, and yeah, generally yes
<re_irc>
<adamgreig> There are definitely some standards that will require "iv&v" ie independent validation and verification, where some other company does literally test and audit your code/software/device
<re_irc>
<adamgreig> Much like UL tests
<re_irc>
<Tom> is that the role of TuV in the EU?
<re_irc>
<James Munns> you typically produce a lot of paperwork (review times/dates, contents, test results, traceability), that in some industries (like avionics) get checked before you can ship, or in others (like automotive outside germany), hold on to a record of your submissions, and typically check them when problems occur
<re_irc>
<Tom> I'm super naive when it comes to software safety stuff, obviously!
<re_irc>
<adamgreig> And yea at some level you get to formally verify your algorithms and also use certified compilers and demonstrate the object code matches the source that you formally verified and have completed mcdc test coverage bla bla
<re_irc>
<adamgreig> But that's all sort of... levels of requirement depending on how important the piece of software is
<re_irc>
<adamgreig> And if wouldn't make sense to do that for everything
<re_irc>
<Tom> interesting, so in the case of ferrocene then, is the goal to show that Rust is developed in a formal enough way to be safety certified?
<re_irc>
<Tom> that would seem to be a tough task as the process is hard to control?
<re_irc>
<Tom> like its not enough seemingly to show the large test suite
<re_irc>
<Tom> and that the behavior is as expected
<re_irc>
<adamgreig> I think on the whole the view is that the rust development process is pretty good! It has a well defined process that's rigourously enforced by tooling, loads of tests and tooling and monitoring, loads of well written explanations for decisions made
<re_irc>
<adamgreig> Totally depends what level of certification to what particular standard you want though I guess (I don't really know anything about ferrocene!)
<re_irc>
<Tom> I don't really need it myself, but it seems like it'd be a selling point to using Rust in more places which is cool!
aspe has quit [Quit: aspe]
<re_irc>
<adamgreig> yea! I think it will help encourage some of those more conservative industries to try it out, by all accounts it's already making lots of in-roads in R&D teams
<re_irc>
<adamgreig> it will be nice to help take away excuses to not use it :P
<re_irc>
<Tom> I take it most places simply use Arm at the moment then
<re_irc>
<adamgreig> there's a huge variety of embedded platforms in industrial/safety stuff, I don't know that arm is especially popular
<re_irc>
<adamgreig> a lot of arm platforms are so complex that it's very hard to reason about them
<re_irc>
<adamgreig> most places probably are using 8051s still :P or more specialist things nobody's heard of, or like a PIC that someone spent a bunch of money on a certified compiler for in the 90s, or...
<re_irc>
<Tom> adamgreig: yeah that makes sense, simpler the better even
<re_irc>
<adamgreig> and then management says you need a high res touch screen and bluetooth and you can say goodbye to the PIC12F that reliably ran your safety critical system for a decade and now you need to make it work on a new arm chip :P
<re_irc>
<Tom> I still love avrs for that reason, though I've accepted for awhile arm is the future (maybe riscv as well)
<re_irc>
<Tom> yeh
<re_irc>
<Tom> exactly
<re_irc>
<Tom> "we need to make this thing look modern"
<re_irc>
<Tom> bluetooth is what drove me to using an RTOS and Arm
<re_irc>
<therealprof> "microbit" 0.13.0 is published... I thought I'd double check what the discovery book is using and noticed it's using the github repository directly... Not really sure that's ideal.