rust-mos VS nrf-hal

rust the compiler, hell no.

But there is an llvm-mos project to generate 6502 code and that can be used to cross compile rust code.

https://llvm-mos.org/wiki/Welcome

https://llvm-mos.org/wiki/Rust

https://github.com/mrk-its/rust-mos

It was possible thanks to great https://llvm-mos.org/wiki/Welcome project (it adds 6502 target to LLVM). Adding 6502 support to rust was easy part :] https://github.com/mrk-its/rust-mos

This is a super fun project to play around with. I'm currently trying to build a C64 sprite multiplexer in mostly straight C++ using LLVM-MOS and while it's definitely not going to be the most optimized multiplexer out there, I'm finding it most adequate performance-wise.

Whereas it's probably a long way away from being able to use this for democoding due to the mostly cycle-accurate nature of the effects, for creating homebrew games and utilities this is really quite suitable: write high-level logic and sprinkle in some inline assembly here and there for the really performance critical parts.

The code that is being generated is already quite good and (on first glance) looks better than what's coming out of cc65, for instance.

There's also rust-mos which uses LLVM-MOS to compile Rust code. It unfortunately still has some issues (e.g. [1]) but that is looking really promising as well.

Kudos to all involved :)

[1] https://github.com/mrk-its/rust-mos/issues/16

The MEGA 65 doesn't appear to have shipped yet. The best data I could find is the MEGA 65 is based on a "GS4510". The "GS4510" is compatible with a "4502", which in turn is compatible with the 65CE02. The 65CE02 uses a different manufacturing process but the same ISA as the 6502, which is supported by rust-mos and lvm-mos](https://github.com/llvm-mos/llvm-mos).

Using llvm-mos, rust-mos, a lot of time compiling compilers and support from Mariusz (the rust-mos author), I was finally able to program like it was 1982...

This fork is handy for that. It’s fun to play with, but you need to do a decent amount yourself to get it set up.

https://github.com/mrk-its/rust-mos

Thanks to llvm-mos project there is also working rust fork for MOS-6502: https://github.com/mrk-its/rust-mos/tree/mos_target, so you can target 8-bit atari and c64

You should try again. I think that code is verbose because of the borrowing and because you're trying to do a one-liner. I use the nrf-hal library with the nrf52840, and the code reads pretty nicely. Here's an example:

https://github.com/nrf-rs/nrf-hal/blob/master/examples/blink...

Reading nrf-hal source, unfortunately new does re-configure the UARTE, and there is not a new_unchecked. The solution I can think of is to duplicate the write code with nrf52833_hal::pac::UARTE0. The Uarte type does not contain any metadata, it exists purely to guard the init of UARTE.

Really good. Check out the examples in the nrf-hal repo. Also, if you don't mind forking out for some extra components the Knurling sessions by Ferrous Systems are ace.

The embedded HAL crates do this with extensive use of macros, for example: https://github.com/nrf-rs/nrf-hal/blob/aae17943efc24baffe30b...

This solution makes sense given the constraints of Rust, but there's quite a cost in terms of compiler time and cognitive overhead to understand what is going on.

(Aside: I didn't use the HAL in my Rust firmware, that's a higher layer of abstraction; I only used the PAC crates.)