I'm not familiar with it but I can see advantages if you regularly deal with various MCU and board/computer designs, or at least want that flexibility. We've been extremely tight on code space, so not sure if it would work for us, unless we go with the 32 KB MCU's like the 1-series 3216. We (well I mean gchart ) have Anduril support basically working for this MCU. I think right now, the 1-series 1616 and 3216 are our best options with 3 pin flashing, small footprint, calibrated temp sensor, and advanced features.
If I could write firmware for ATTiny's in C#, that would be outrageous! Not sure if this platform supports that though - it looks like C/C++ but gives a wink to C#. I've been spoiled rotten working in C# over the last few years.
Funny enough, I write C# based applications in the .NET framework (mostly web apps) as well! There’s a lot of developer ergonomics I miss when I’m outside of that space.
As to Platform IO, at least in my experience, you’re still sticking to the same C / C code, but you get some additional conveniences such as pulling code libraries in from their package repository or referencing a Github url. And having the command palette abstract all of the cmd line stuff for flashing and monitoring your boards. And of course, VS Code is a fantastic editor to work with. I pretty much exclusively work in it for the front-end Javascript editing.
The Rust language now has AVR support baked in. Rust isn’t quite C# but it has lots of developer experience things that are missing in C, supposedly without any performance trade offs.
This is a different case. Rust binaries are statically linked which makes them comparatively very large.
But in the embedded space everything is statically linked, so no difference here.
On the other hand is LLVM as good as gcc in optimizing for size? I played with that years ago on a different target and it was not. But this experience may not be relevant now.
Also, how does the higher level nature of rust lend itself to space optimizations? It works well for performance which is a good sign. But it is not a certainty.
BTW, modern MCUs tend to have much more flash. So dropping compatibility with older lights (as well as many modern ones that still use older MCUs) would make things much easier. I don’t expect our greatest firmware developers to go this way any time soon but I wouldn’t surprised to see someone else experimenting with Rust either.
Please help me make things clear with branches. I’m really not familiar with launchpad. What is the difference between lp:flashlight-firmware and lp:~toykeeper/flashlight-firmware/fsm. Second one seems newer, so I assume I should use this branch to get latest Andruil?
It is. I highly doubt that you can compile and flash Anduril or Narsil with the Arduino IDE. You’ll need comman line avr-gcc and avrdude for compiling and flashing. There are several tutorials how to do it.
Does Narsil work with three channels? Does the pinout match?
Damit this stuff is way too complicated for me. I can’t even get the name right. It was andruil.c from toykeepers launchpad. I just tried with command prompt / avrdude and i get a file directory error. I appreciate your willingness to help SammysHP but this is already irritating the c^@p out of me
I finally got it to flash. It turns out the directory was the issue. I moved the hex file and it worked fine Now that i got it to work (once at least ) i need to learn how to modify the hex file
Thank you SammysHP. To change the pin you need to modify the file, right? I was hoping for a complete hex file. Maybe I will need to figure out how to create a hex file myself. Last time I tried it just showed me a bunch of errors.