[robotjosh]

These problems that embedded rust is trying to solve are not a big deal. In C you try to minimize what happens in any interrupt, usually just set a flag, save a result, and return. You generally use atomic instructions on gpio. To set or clear a bit mask is atomic so there is not much reason to read-modify-write gpio in an interrupt or anywhere. I think these solutions would create more work than they save.

[vvanders]

Keep reading, they also cover dealing with exclusive access to subsystems. I could totally see this being applied to DMA and other long-running peripherals to great success.

I'll also disagree that this is a small problem. We had one of these that was so hard to track down that it involved 100+ devices running in a stress loop over 24 hours with cameras looking for the regression. Ended up being a timing sequence that could have been caught by a system like this.

The repro was incredibly infrequent but when you've got millions of units even 0.01% chance of something happening is too often.

[__david__]

I think the project is neat, but I've also written stuff to do all of that for embedded C projects. Where you'd allocate pins on the board for the peripherals you wanted to enable and it would complain if you double allocated.

That it's auto-generated is the neat part, but then again, you could auto-generate C code that was just as robust (though admittedly, a lot of that robustness would be pushed to run-time checks with C code).

[idubrov]

I don't see anything controversial here.

First, you can always use unsafe and access low level registers ignoring all the synchronization. You are still getting typed access to the bits (well, contingent on SVD file quality), which is an improvement over hand-writing bit manipulation code (or using wrong constant for shift/mask in STM32 HAL, for example).

Second, look at the port splitting example. If you split port into pins, when you can independently move these pins into different execution contexts and you won't need any synchronization as well. Write to a pin would be a single write to BSRR register -- no read-modify-write. So you are getting safety and about the same generated code as for hand-written code (well, except that if you want to do multiple pins at once).

What if you want to reconfigure port? This is, actually, what was particularly annoying for me with the old version of svd2rust I/O. Even though I know that my two subsystems operate on completely different pins, I still had to pass CRL/CRH around, to avoid potential race when reconfiguring pins.

This new version has the same property, though, -- according to the article.

However, the solution is pretty straightforward. By using ARM bit-banging feature, you can have the same "split" atomic-share-nothing-style API for the port reconfiguration, too. Similarly, you would split, for example, GPIOA into 8 pins and each pin would allow you to both input/output data and change port direction.

So, bottom line, I think you can get best of both worlds most of the time: safety and performance of the hand-written code. And in corner cases, you can still ignore all the safety and access registers without any overhead.

I don't really understand what is this approach lacking for career firmware engineer.

(disclaimer: I haven't ported my firmware yet, so I could be wrong in my assumptions how this new I/O works).

[Ericson2314]

Yeah the current way of developing these things is slow AF so I'm not buying it. I've done Haskell->Verilog, its an amazing development speed up, and people give the same "but that's not the hard part" complaints.

The fact is, no one's development process is that parallel, so critical-path-style arguments don't work. Turning even just a few easy parts free does reduce dev costs, and in these case we're clean-sweeping like all the low hanging fruit.

[xfer]

Any projects with public code you have that i can look into, assuming you are talking about clash? I would appreciate it.

[Ericson2314]

My stuff is unfortunately all closed source for school and then work, but check out https://github.com/thoughtpolice/clash-playground

[stmw]

As all problems, these bugs are avoidable, but having a high speed language that helps you avoid them seems like a good thing. Having had to fix this kind of stuff before, it sure felt like a "big deal" at the time. :-)

[robert_foss]

I can't say that I agree. I would rather thread through some boilplate, rather than have a hard to debug issue on a platform that I have low visibility into.

[robotjosh]

It sounds like this would work for beginners or certain people who know rust and not C. A new firmware language could never be widely adopted if it is not made for the career firmware engineer to use.

[weberc2]

I think you give firmware engineers too little credit.