<re_irc>
<adamgreig> man, cortex-m CI is _not_ happy at me
<re_irc>
<adamgreig> "wah wah i can't download rust 1.59 it doesn't exist"
<re_irc>
<adamgreig> "this crate says it needs rust 1.59 but i'm only rust 1.58.1!"
<re_irc>
<adamgreig> 6 emails
<cyrozap>
I finally got a simple Rust program running on an 8051 microcontroller (simulator)! :D
<re_irc>
<adamgreig> wow, they really will never die, hah! what did it take to get it running?
<cyrozap>
Technically, it's running on a RISC-V emulator which is running on the microcontroller, but still, it works!
<re_irc>
<adamgreig> gosh, I see
<re_irc>
<adamgreig> can't tell if that's more or less galaxy brain than getting rust to emit native 8051, amazing
<cyrozap>
So right now it's Rust compiled to RV32I, which is running on my emulator (rv51: https://github.com/cyrozap/rv51) which is running on an 8051 simulator (s51, distributed with SDCC) on x86.
<re_irc>
<GrantM11235> Speaking of galaxy brain 8051, I recall seeing someone who wrote a LLIR-to-C transpiler, which they then fed to SDCC
<re_irc>
<adamgreig> I bet sdcc loved that
<cyrozap>
btw, this code should be able to run on a real 8051--I just wanted to have example code that anyone could run without requiring them to have some specific hardware to do it.
<cyrozap>
It currently requires GNU Binutils because I didn't know if Rust's toolchain has `objcopy` I could use.
<cyrozap>
And it also uses a Makefile because I have very little experience with scripting Rust builds (I'm more familiar with Python and C).
<cyrozap>
@GrantM11235 Interesting, I hadn't considered that approach. But to echo what @adamgreig said, I'm sure SDCC _loved_ the C generated by that--I sometimes have trouble getting hand-written C to be compiled properly by SDCC, so a toolchain that generates C sounds like it would be prone to breakage.
<re_irc>
<adamgreig> if you "rustup component add llvm-tools-preview" it'l grab the rust objcopy, and "cargo install cargo-binutils" gives you "cargo objcopy" which works like build/run e.g. "cargo objcopy --release -- -O binary bla.bin"
<cyrozap>
One idea I thought about (but don't have enough compiler experience to implement) was to write an LLVM backend that targets a virtual 32-bit machine, and then emits 8051 instructions that manipulate that machine. So kind of like a static recompiler (which someone else had mentioned to me, and I had also watched a presentation on), but skipping the disassemble/analyze step.
<cyrozap>
@adamgreig Thanks, I'll try to see if I can get that to work, since it would simplify the toolchain quite a bit (not sure how popular it is for distros to package GCC for RISC-V).
<cyrozap>
Also, unrelated to the 8051 stuff, I was really surprised to see how `rustc -O3` optimized my simple "print" function on RV32I--rather than loop over a string in .rodata like the C program did, it performed _immediate loads_ for each character in the string. And yet, that doubled performance compared to `-O2`, while increasing the binary size only by 100 bytes or so (and every byte counts when your
<cyrozap>
code space is limited to 64kB).
<re_irc>
<adamgreig> huh, that's kinda cute
<re_irc>
<adamgreig> so one load with immediate per character into a register, and then dump the register to the uart or whatever?
<re_irc>
<adamgreig> i guess it beats having to load from memory but i sure wonder what its heuristics are for it, heh
<re_irc>
<adamgreig> you could try -Os and -Oz to see what else it does, though sometimes O3 ends up better anyway
<cyrozap>
Yup--basically just a sequence of `li ...; sb ...` for each character. Also, it was really cool to see how it optimized the putchar function to bypass the "check if a character is a LF and, if so, print a CR first" part, and just directly wrote the CR and then LF.
<cyrozap>
Like, it makes total sense to skip the check when it's known for certain that only the last character is a LF.
<re_irc>
<adamgreig> optimising compilers, huh
<cyrozap>
Yeah, it was weird to experience "wait, shouldn't a loop over the string in the binary be faster" only to try it and be proven _very_ wrong.
<cyrozap>
Oh, wow, so using the compiler explorer I did a little comparison between gcc and clang on that print/putchar loop in C, and yeah, using load-from-immediate is literally less than half the number of instructions executed as the "loop through each char in the string" method (29 vs. 61) while only being 193 bytes larger (244 vs. 51). Now, of course that's C and comparing between `gcc -O3` and `clang
<cyrozap>
-O3` and not `rustc -O2` and `rustc -O3`, but it's the most likely explanation for the discrepancy.
<re_irc>
<farbod peimanzadeh> Hi ,
<re_irc>
I have some Vec inputs that they are the constructor fields. What is your suggetion to implement it?
<re_irc>
let obj1 = Obj::new(
<re_irc>
let config = vec![1,2,3,4];
<re_irc>
let obj = Obj::new(config[0],config[1],config[2],config[3]);
<re_irc>
<farbod peimanzadeh> Some thing like this but with dynamic length
creich_ has joined #rust-embedded
creich has quit [Ping timeout: 250 seconds]
<re_irc>
<ryan-summers> I don't believe such a thing is possible in Rust (I imagine you're taking this syntax from Python or some other dynamic, interpreted language). As far as I understand it, such expansion is not possible for a strongly typed language, since there's no compile-time guarantee that the "vec" has the same number of arguments as the input function. The only way to do this would be to update your "new()" function to accept...
gsalazar has joined #rust-embedded
<re_irc>
... a slice instead of a number of elements
<re_irc>
<ryan-summers> One approach would be to "impl TryFrom<Vec> for Obj {}", so you could _try_ to expand the vec into the object (if it has enough input elements), but you'd still have to expand the vec elements to the Obj::new() function once within the impl as well
gsalazar_ has joined #rust-embedded
gsalazar_ has quit [Remote host closed the connection]
gsalazar_ has joined #rust-embedded
gsalazar_ has quit [Remote host closed the connection]
gsalazar has quit [Ping timeout: 240 seconds]
<re_irc>
<barafael> You could probably do it with a macro but maybe better not. You could just pass a slice.
<re_irc>
<omar_u8> Im trying to wrap my head around the usage (or detail) of the constrain and split methods. Are there any leads on good explanations for those methods? I've found this (https://blog.japaric.io/brave-new-io/) on Jorge Aparico's blog post and it was really good though I'm wondering if there is more. Based on my knowledge in various architechture, it sort of left me with more questions. Also most other explanations...
<re_irc>
... including the documentation Ive seen sort of brush over what the methods do in way that makes me feel that it maybe more intuitve than I'm feeling it might be 😟
<re_irc>
<omar_u8> I'm trying to wrap my head around the usage (or detail) of the constrain and split methods. Are there any leads on good explanations for those methods? I've found this (https://blog.japaric.io/brave-new-io/) on Jorge Aparicio's blog post and it was really good though I'm wondering if there is more. Based on my knowledge of various architectures, it sort of left me with more questions. Also most other explanations...
<re_irc>
... including the documentation I've seen sort of brush over what the methods do in a way that makes me feel that it may be more intuitive than I'm feeling it might be 😟
Guest2 has joined #rust-embedded
<re_irc>
<omar_u8> adamgreig: I figure these Older Architectures with lots of field mileage might still longer for a while as they make a good case for functional safety, don’t they?
<re_irc>
<9names (@9names:matrix.org)> how so?
<re_irc>
<omar_u8> More experience less issues, less chance, chance for failure both on software and hardware end.
<re_irc>
<omar_u8> Especially on the silicon side.
<re_irc>
<omar_u8> More experience less issues, less chance for failure, both on software and hardware end.
starblue1 has quit [Ping timeout: 256 seconds]
starblue1 has joined #rust-embedded
<re_irc>
<ryan-summers> Yeah, but even safety critical stuff has evolving requirements, and a lot of the older processors just don't have the necessary specs to manage
<re_irc>
<ryan-summers> That being said, safety critical does tend to operate on earlier tech, but 8051 is pretty old ;)
<cr1901>
I still want Rust on 8051 just because it would be interesting
<re_irc>
<disasm> cr1901: IIRC there was a RISC-V emulator for 8051, most likely Rust-compatible
<cr1901>
I think that's cyrozap's project
<cr1901>
And yes, that works. It's even in line with "what ppl did back in the 70s/80s sometimes".
<cr1901>
A VM is a valid approach for code density
<cr1901>
I think it would still be cool if there was a way to contort LLVM's assumption of plentiful uniform registers and plentiful stack to generate reasonable code for a global-heavy/broken-stack arch :P
tokomak has joined #rust-embedded
<re_irc>
<omar_u8> ryan-summers: I agree, thing is probably until a few years back I was in the auto industry and recall that 8051 was still being offered by uC manufacturers. I think in industrial contexts it still exists as well. It seems that microchip is still selling them (https://www.microchip.com/en-us/products/microcontrollers-and-microprocessors/8-bit-mcus/8051-mcus). Also in context of functional safety requirements, although...
<re_irc>
... technology might be advanced, the standards like the 26262 revolve more about process, data, and tools.
<re_irc>
<ryan-summers> Safety standards almost always revolve around process and formal verification. In reality, it doesn't actually matter if silicon has bugs in it if you never hit those bugs in your app
<re_irc>
<ryan-summers> Obvious exceptions come into play as you start doing single- and double-fault tolerant designs though
<re_irc>
<ryan-summers> The benefit of silicon defects are that they're deterministic and (usually) easy to document and (hopefully) workaround
<re_irc>
<ryan-summers> Well, now that I'm thinking about it, not always deterministic either
<cr1901>
I wanted to do something similar for 6502 a while ago, but never finished it. It was for the express purpose of creating a small riscv core for FPGA (since 65xx is pretty small)
<cyrozap>
Also, my main target for the emulator has been ASMedia USB host controllers, since they contain a 1T 8051 core (most instructions complete in 1-3 clock cycles, and the most all but one instruction take is 5 cycles--DIV takes 6) running at up to 156.25 MHz, so even under emulation the RISC-V "equivalent in-order clock frequency" of ~1-3 MHz is generally acceptable.
<re_irc>
Does anybody know at what time Rust 1.59 will be released? Or at least at what time updates are normally released?
<re_irc>
<diondokter> Uhg, I'm so distracted today...
<re_irc>
Kinda waiting on to publish a crate to crates.io
<re_irc>
<ryan-summers> I was getting frustrated that my types were becoming insanely large, but if I can give the user sensible defaults, that's a nice compromise
<re_irc>
<adamgreig> and cargo will take "-r" as an alias for "--release", that might take some time to unlearn
Guest2 has joined #rust-embedded
<re_irc>
<diondokter> Oh, my inline asm is technically behind a feature flag, so I was able to release it!
<re_irc>
<diondokter> So "cargo publish" does not check the msrv :P
<re_irc>
<diondokter> "rust-version = "1.59"" has been configured
<re_irc>
<dirbaio> it's for compatibility with time machines I think?
<re_irc>
<adamgreig> you can always "--no-verify" too and just publish whatever, lol
<re_irc>
<diondokter> Now just waiting for the docs to be built and then I can finally announce it :D
<re_irc>
<diondokter> Uh oh, my release has crashed crates.io!
<re_irc>
<newam> Ah, not just me
<re_irc>
<newam> I kept getting 502. Had to use my go-to reference for HTTP errors: https://http.cat/502
<re_irc>
<James Munns> The main website is having problems too :D
<re_irc>
<adamgreig> (there's also the #rust-embedded-space:matrix.org (https://matrix.to/#/#rust-embedded-space:matrix.org) space (and the #rust-space:matrix.org (https://matrix.to/#/#rust-space:matrix.org) space) for finding rust related channels on matrix)
<re_irc>
<diondokter> Nice! But due to the outage 3/4 crates I just published didn't build their docs...
<re_irc>
Any way to retrigger it?
<re_irc>
<diondokter> Or do I have to immediately create a 0.1.1 release? 😅
<re_irc>
<adamgreig> ask nicely on the docs.rs discord
Guest2 has quit [Ping timeout: 256 seconds]
tokomak has quit [Ping timeout: 240 seconds]
<re_irc>
<James Munns> Oh, assume_init is const, I might be able to remove some hax from byte slab
<re_irc>
<James Munns> Ah, zeroed is still not const tho
skunkjoe has joined #rust-embedded
<re_irc>
<Pierre-Yves Aillet> Hi !
<re_irc>
I have a driver requiring an output reset Pin which is not present on the device I use.
<re_irc>
Is there something like a "NoPin" or "NullPin" in embedded-hal ? Or should I try to open a PR on the driver to make the said Pin Optional ?
skunkjoe has quit [Ping timeout: 245 seconds]
<re_irc>
<Pierre-Yves Aillet> * I'm using a driver which requires
<re_irc>
<diondokter> A PR for the driver would be best if the use of the pin is not required for operation.
<re_irc>
And I guess in the meantime, I will stick to what I did before, provide my own DummyPin impl
<re_irc>
<firefrommoonlight> I like your idea of getting the driver changed to be more flexible. If the maintainer doesn't make the change, then you get into the discussion of if you want to fork, copy+paste the code locally etc. (Which each has drawbacks and added complexity)
<re_irc>
<firefrommoonlight> Ideally, the maintainer will make the change or merge a PR
<re_irc>
<firefrommoonlight> I like your idea of getting the driver changed to be more flexible. If the maintainer doesn't make the change, then you get into the discussion of if you want to fork, copy+paste the code locally, keep using the dummy pin etc. (Which each has drawbacks and added complexity)
<re_irc>
<eldruin> diondokter: Nice work! Looks pretty cool! be sure to add it to our newsletter :)
<re_irc>
I think maybe it would make the whole thing more approachable with an use case walkthrough blog post of sorts. Probably most of it could be just pasting together parts of the readmes you already wrote.
<re_irc>
<diondokter> eldruin: True! There's also an example project that sets it all up, but not in the most explanatory way.
<re_irc>
A blog post is planned, but not after I've integrated this with a client project. That way I can also describe my use case and learn a bit more about how my crates feel in their usage