CC65-Advanced-Optimizations
nrf-hal
CC65-Advanced-Optimizations | nrf-hal | |
---|---|---|
2 | 5 | |
115 | 472 | |
- | 1.9% | |
0.6 | 8.4 | |
about 1 year ago | 10 days ago | |
C | Rust | |
MIT License | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
CC65-Advanced-Optimizations
-
Assembly programming on the Commodore 64
I'd like to suggest trying C, using cc65. Assembly knowledge is useful, but working in C is much easier and fast enough most of the time. Here's a nice guide on how to write C code that runs fast on a C64: https://github.com/ilmenit/CC65-Advanced-Optimizations
-
Rust on the MOS 6502: Beyond Fibonacci
The cool thing about LLVM-MOS specifically it that by using the zero page as virtual registers you sort-of get the same output with 'regular' code as opposed to this 'global variables' style of programming.
I recall a tutorial for 'cc65 optimizations'[0] which basically destroys a well-structured C program in order to do all of these optimizations (like making everything global) and it was absolutely terrible, code-wise. Well, the end result was probably fine, but it's just a shame these 'optimizations' were needed.
[0] I think it was this one: https://github.com/ilmenit/CC65-Advanced-Optimizations
nrf-hal
-
Rust newcomers are 70x less likely to create vulnerabilities than C++ newcomers [pdf]
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...
-
Any good examples of using embedded Rust with an existing embedded C codebase?
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.
- Rust on the MOS 6502: Beyond Fibonacci
-
First steps with Embedded Rust: Selecting a board
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.
-
I rewrote my Rust keyboard firmware in Zig: consistency, mastery, and fun
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.)
What are some alternatives?
llvm-mos-ferris-demo
embassy - Modern embedded framework, using Rust and async.