<re_irc>
< (@altsegcat:matrix.org)> If I want to use a non-nostd crate in an MCU can I just implement the needed syscalls myself?
<re_irc>
< (@adamgreig:matrix.org)> you need to implement "std" yourself, which is generally not as trivial as like implementing "sbrk" and a few friends for libc
tafa has quit [Ping timeout: 252 seconds]
tafama has joined #rust-embedded
<re_irc>
< (@altsegcat:matrix.org)> I found nostd_compat, which seems to solve most of my problems, although it's missing a few API's I need like mutexes and panic wrapping
<re_irc>
< (@altsegcat:matrix.org)> For context I am trying to port rLUA to nostd
starblue has quit [Ping timeout: 260 seconds]
starblue has joined #rust-embedded
fabic has quit [Ping timeout: 260 seconds]
<re_irc>
<thejpster> You could use a macro to generate the 60 lines. But I’d probably just write them out.
fabic has joined #rust-embedded
dc740 has joined #rust-embedded
fabic_ has joined #rust-embedded
fabic has quit [Ping timeout: 255 seconds]
<re_irc>
< (@nihal.pasham:matrix.org)> Over the weekend, I decided to do an impromptu talk on functional correctness (mostly) in the context of embedded software and ended up exploring flux (https://github.com/liquid-rust/flux)
<re_irc>
< (@nihal.pasham:matrix.org)> Over the weekend, I decided to do an impromptu talk on functional correctness (mostly) in the context of embedded software and ended up exploring flux
<re_irc>
some embedded use-cases I can think of for this are - refined memory mapped IO, control-flow with refined bounds checking, refined parsers
<re_irc>
I wonder about other areas where something like this could be applied and does anyone know if there are any embedded projects or library authors (such as hal maintainers) who are thinking of adding functional correctness as an additional guarantee to their projects (maybe to a small part to begin with).
<re_irc>
I believe the formal methods tooling, available for rust is (sort-of) usable, example: prusti and creusot - both are deductive verifiers.
<re_irc>
< (@nihal.pasham:matrix.org)> Over the weekend, I decided to do an impromptu talk on functional correctness (mostly) in the context of embedded software and ended up exploring flux
<re_irc>
stream: https://bit.ly/3jTrASs some embedded use-cases I can think of for this are - refined memory mapped IO, control-flow with refined bounds checking, refined parsers
<re_irc>
I wonder about other areas where something like this could be applied and does anyone know if there are any embedded projects or library authors (such as hal maintainers) who are thinking of adding functional correctness as an additional guarantee to their projects (maybe to a small part to begin with).
<re_irc>
I believe the formal methods tooling, available for rust is (sort-of) usable, example: prusti and creusot - both are deductive verifiers.
<re_irc>
< (@nihal.pasham:matrix.org)> Over the weekend, I decided to do an impromptu talk on functional correctness (mostly) in the context of embedded software and ended up exploring flux (https://github.com/liquid-rust/flux)
<re_irc>
some embedded use-cases I can think of for this are - refined memory mapped IO, control-flow with refined bounds checking, refined parsers
<re_irc>
I wonder about other areas where something like this could be applied and does anyone know if there are any embedded projects or library authors (such as hal maintainers) who are thinking of adding functional correctness as an additional guarantee to their projects (maybe to a small part to begin with).
<re_irc>
<Sean Lyons> +My target is supported by "openocd" thought.
<re_irc>
<Sean Lyons> * though.
<re_irc>
< (@korken89:matrix.org)> Sean Lyons: I'm my experience it's just as simple to add multiple testing bins
<re_irc>
< (@korken89:matrix.org)> If you name them like test_xx you can easily automate the testing with a small script as well
fabic_ has quit [Ping timeout: 252 seconds]
<re_irc>
<IAmnesia> I just started messing a bit with embedded, and I gotta admit, the DX is.. different
<re_irc>
I suppose some of it is just a matter of tweaking my configs a bit. I'm not sure if it's the host/target mismatch that makes RA act like its drunk?
<re_irc>
honestly I could live without LSP at all, if at least I had reasonable iteration cycles. I'm on an old low spec machine atm, and it's almost unbearable.
<re_irc>
Got any tips to help me get comfy? what's your workflow like?
<re_irc>
<IAmnesia> I'm not sure if this problem is specific just to my setup ofc.
<re_irc>
< (@k900:0upti.me)> What do you mean by "act like it's drunk", exactly?
<re_irc>
<Sean Lyons> : I am trying that out now. How do you report results? ITM?
<re_irc>
< (@korken89:matrix.org)> With defmt
<re_irc>
< (@korken89:matrix.org)> Exit with 0 return code to say OK
<re_irc>
< (@korken89:matrix.org)> Else panic to return non zero return code
<re_irc>
< (@korken89:matrix.org)> You can also add logging then to give more info
<re_irc>
<IAmnesia> ya I suppose that's pretty vague.. and poorly described too honestly.
<re_irc>
I just have a lot of cases of missing names and unreliable completions. for some reason it also feels slower, even though it's a tiny project
<re_irc>
I think it might be because RA was built with a different version of the compiler - my target requires using a fork of rust. or it may just be some missing cfg attributes
<re_irc>
<IAmnesia> but RA is completely blind to half of the modules in my deps although they compile just fine
<re_irc>
< (@k900:0upti.me)> Do you have the right target set in "Cargo.toml"?
<re_irc>
< (@k900:0upti.me)> Or are you just doing "cargo build --target whatever"?
<re_irc>
< (@k900:0upti.me)> If it's the latter, you're probably just not seeing stuff that's compiled conditionally for your target
xnor has quit [Ping timeout: 260 seconds]
xnor has joined #rust-embedded
dc740 has quit [Remote host closed the connection]
<re_irc>
< (@josfemova:matrix.org)> Working on some spi nor flash stuff and I'm trying to track the origin of the opcodes. Does anybody here know if there's like a formal std or the common ones are just de facto standards?
<re_irc>
4byte read and the write enable commands are defined in JESD216, but I've been unable to find something formal about others like Page Program, 3byte addr read, etc
<re_irc>
<Peter Hansen> To be fair, it only claims that's the standard applicable to QSPI, not specifically that Page Program etc will be found in it. I haven't tried to check.
<re_irc>
< (@josfemova:matrix.org)> Unfortunately doesn't seem like it
<re_irc>
<Peter Hansen> :(
<re_irc>
< (@josfemova:matrix.org)> Oldest ref I found on the usual 6 commands is the DS for the 25-series eeprom
<re_irc>
< (@josfemova:matrix.org)> Linux and zephyr have an extended list of other opcodes and assume those are standard over all spi nor flash devices, but no comment indicates where they got those from
<re_irc>
<Peter Hansen> Found in an Infineon datasheet: "While Octal/HYPERBUS™ xSPI is standardized at JEDEC (JESD251 profile 1/profile 2 respectively), Quad I/O SPI
<re_irc>
(QSPI) protocol is not. Consequently, some commands have different operands depending of QSPI Flash
<re_irc>
memory vendors."
<re_irc>
<Peter Hansen> so... de facto, I guess. Not surprised if true.
<re_irc>
<Peter Hansen> And if vendors like Nordic are willing to make hardware where these values are basically hardcoded, it seems likely there's some consensus on the known set not changing.
<re_irc>
<Peter Hansen> (from the nRF52840 datasheet)
<re_irc>
< (@dirbaio:matrix.org)> they still allow you to pick which actual command to use among these
<re_irc>
<Peter Hansen> Yes, but they've hardcoded just that set of possibilities.
<re_irc>
< (@firefrommoonlight:matrix.org)> Memory-mapped is something to consider with QSPI
<re_irc>
<Peter Hansen> : You mean XIP, Execute In Place?