avr-hal VS llvm-project

/* * For examples (and inspiration), head to * * https://github.com/Rahix/avr-hal/tree/main/examples * * NOTE: Not all examples were ported to all boards! There is a good chance though, that code * for a different board can be adapted for yours. The Arduino Uno currently has the most * examples available. */ #![no_std] #![no_main] use dht_sensor::*; use panic_halt as _; #[arduino_hal::entry] fn main() -> ! { let dp = arduino_hal::Peripherals::take().unwrap(); let pins = arduino_hal::pins!(dp); let mut serial = arduino_hal::default_serial!(dp, pins, 57200); let mut pin3 = pins.d3.into_opendrain_high(); let mut delay = arduino_hal::Delay::new(); ufmt::uwriteln!(serial, "{}", "waiting for sensor...").unwrap(); arduino_hal::delay_ms(2000); loop { match dht11::Reading::read(&mut delay, &mut pin3) { Ok(dht11::Reading { temperature, relative_humidity, }) => ufmt::uwriteln!(serial, "{}°, {}% RH", temperature, relative_humidity).unwrap(), Err(_e) => ufmt::uwriteln!(serial, "Error {}", "Unable to read").unwrap(), } arduino_hal::delay_ms(2000); } }

I found the generics a lot less of a problem when I realized I could parametrize on things like embedded_hal::serial::Write instead of UsartOps https://github.com/Rahix/avr-hal/pull/264/commits/17ed15321cb8fcf8aedb1f8133be1f189eb06a6f

I've come across avr-rust, avr-hal and both seem to have arduino stuff, wondering which is the most beginner friendly? (I have a bit of experience with the regular arduino IDE but want to switch over to doing all the stuff in rust for a challenge)

fyi, a minor follow-up at https://github.com/Rahix/avr-hal/issues/388

I have contributed a little to this. avr-hal I have done a couple little hobby projects with it as well, but I can't say it's the best thing out there.

All you need is in the documentation: https://rahix.github.io/avr-hal/arduino_hal/index.html even though reading the documentation without knowing what you're looking for can be quite difficult, so looking at some examples might be more helpful.

Rust language shares all advantages of efficient C++ code. With the rust community growing year after year, more and more people try using rust to program their Arduino boards. Consequently, the Arduino Rust ecosystem have significantly developed in the last couple of years. The Hardware Abstraction Layer for AVR microcontrollers avr-hal, Rudino library and ravedude CLI utility to make Rust development for AVR microcontrollers easier are just a few examples of the solid foundation developed so far.

Today I was toying with the arduino again, making an attached LED matrix print awesome messages better than it previously had. I wanted to use millis() found in the examples in the unsurpassed avr-hal crate, to orchestrate the duration it should show (part of) a character before moving on. But that is all besides the point. I made a few mistakes that coincidentally compiled and as such made me believe I was doing things right. (Perhaps I should note here that I am visually impaired so it is a bit easier for me to glance over smaller differences.)

There's a blink example in the repo for the avr-hal crate.

I'm trying to make an Arduino display text on an LCD using I2C (HD44780). So far, I've used arduino-hal from the avr-hal crate (github.com/Rahix/avr-hal) to program the Arduino, and I wonder if anyone happens to know of a library/crate which is compatible with it? So far I've only found ag-lcd which doesn't seem to work with I2C.

As far as I know, libstdc++'s representation has two advantages:

First, it simplifies the implementation of `s.data()`, because you hold a pointer that invariably points to the first character of the data. The pointer-less version needs to do a branch there. Compare libstdc++ [1] to libc++ [2].

[1]: https://github.com/gcc-mirror/gcc/blob/065dddc/libstdc++-v3/...

[2]: https://github.com/llvm/llvm-project/blob/1a96179/libcxx/inc...

Basically libstdc++ is paying an extra 8 bytes of storage, and losing trivial relocatability, in exchange for one fewer branch every time you access the string's characters. I imagine that the performance impact of that extra branch is tiny, and massively confounded in practice by unrelated factors that are clearly on libc++'s side (e.g. libc++'s SSO buffer is 7 bytes bigger, despite libc++'s string object itself being smaller). But it's there.

The second advantage is that libstdc++ already did it that way, and to change it would be an ABI break; so now they're stuck with it. I mean, obviously that's not an "advantage" in the intuitive sense; but it's functionally equivalent to an advantage, in that it's a very strong technical answer to the question "Why doesn't libstdc++ just switch to doing it libc++'s way?"

This Ruby implementation is based on mruby and LLVM and it’s commercial software but cheap.

'Computer Architeture: A Quantitative Apporach" and/or more specific design types (mips, arm, etc) can be found under the Morgan Kaufmann Series in Computer Architeture and Design.

"Getting Started with LLVM Core Libraries: Get to Grips With Llvm Essentials and Use the Core Libraries to Build Advanced Tools "

"The Architecture of Open Source Applications (Volume 1) : LLVM" https://aosabook.org/en/v1/llvm.html

"Tourist Guide to LLVM source code" : https://blog.regehr.org/archives/1453

llvm home page : https://llvm.org/

llvm tutorial : https://llvm.org/docs/tutorial/

llvm reference : https://llvm.org/docs/LangRef.html

learn by examples : C source code to 'llvm' bitcode : https://stackoverflow.com/questions/9148890/how-to-make-clan...

See

https://github.com/llvm/llvm-project/issues/88344

https://fortran-lang.discourse.group/t/flang-new-how-to-forc...

You can never mistake type_declaration with an identifier, otherwise the program will not work. Aside from that constraint, you are free to name them whatever you like, there is no one standard, and each parser has it own naming conventions, unless you are planning to use something like LLVM. If you are interested, you can see examples of naming in different language parsers in the AST Explorer.

> There is one way to make the LLVM JIT compiler more usable, but I fear it’s going to take years to be implemented: being able to cache and reuse compiled queries.

Actually, it's implemented in LLVM for years :) https://github.com/llvm/llvm-project/commit/a98546ebcd2a692e...

> It's true, this was a CVE in Rust and not a CVE in C++, but only because C++ doesn't regard the issue as a problem at all. The problem definitely exists in C++, but it's not acknowledged as a problem, let alone fixed.

Can you find a link that substantiates your claim? You're throwing out some heavy accusations here that don't seem to match reality at all.

Case in point, this was fixed in both major C++ libraries:

https://github.com/gcc-mirror/gcc/commit/ebf6175464768983a2d...

https://github.com/llvm/llvm-project/commit/4f67a909902d8ab9...

So what C++ community refused to regard this as an issue and refused to fix it? Where is your supporting evidence for your claims?

For everyone else looking for the magic in this almost 7k lines monster, look at line 6610 [1].

[1] https://github.com/llvm/llvm-project/blob/8ec28af8eaff5acd0d...