carrigan

Hi all! I'm a software/hardware engineer at Yard Stick and am happy to talk more about what we've been working on if anyone has any questions.

I agree that we need to cut back our current emissions. Even if we stopped emitting all greenhouses gasses tomorrow, the global temperature would continue to rise for decades before stabilizing, so there is still plenty of need to capture what we've already let out.

I'm fairly bearish on direct capture solving much though. It requires so much capital and energy just to replicate the carbon capture that we can already do just by growing plants. I hope that companies like Charm will also get significant funding to pursue using plants for the capture part.

I don't believe that hardware constraints have anything to do with code quality. Running your code on a microcontroller will require your algorithms to run in a smaller RAM footprint and potentially come with timing requirements, but do not dictate that you write quality code to do so. You can solve those problems with thousands of lines of uncommented assembly efficiently, but that does not mean it is quality code.

I have worked for a significant time in my career as both an embedded engineer as well as a backend engineer, and in general I find that the backend code is way easier to read, maintain, and extend. Embedded code is seldom properly tested and most of it is written in C where people can abuse a library's contracts or the preprocessor. It is not uncommon to find functions that are over a thousand lines in the embedded world. Compare this to Rails where there are a ton of standards, short and succinct functions, and good support for testing.

I guess it depends on your definition of "quality code". If you mean code that is dependable and will do one thing well on one platform for the rest of time, then embedded code could be considered high quality. I would debate that these items have more to do with the binary than the code though. If you mean code that conveys how a program works well to other programmers, is under test, and follows some standard structure, I would pick modern app development as typically being much higher quality.

Thank you very much! I'd love to hear about what you come up with for recipe management.

Thank you for the kind words! I will echo slig and say that I have been really happy with the Rigol DS1054Z so far. I love that you can build a really capable electronics lab at home in 2018 for less than $500.

This is exactly what I was looking for; I had only checked the String and &str documentation and didn't think to look for a macro. Thanks :)

I go through this cycle every 6 months or so where I will get excited about Rust and try it out for embedded development again. Typically in the first day, I get frustrated with some major limitation and put it back on the shelf. This last time, I wanted to make a simple timer that displayed the time since a button was last pressed on a 16x2 character LCD screen.

In addition to the HAL annoyances that turbinerneiter talked about, I wound up giving up this time because I could find no way to manipulate strings in a static buffer. In C I could just allocate two 17 byte strings statically and then `sprintf` to them, but there seems to be no equivalent in Rust.

I'd be curious to know what limitations others have run into when trying this and if I was just doing it wrong.