Learning embedded coding, which uC?

Hello Lanarcam,

Yes, and that includes documentation during the design process so you can hold proper and regular design reviews.

I require one more: Documentation during the design. If an engineer doesn't want to do that I won't hire him or her. How else can you share ideas and strategies with the other team members, the QA folks and so on?

Language and tools can't prevent all hazards. They cannot know what the consequences of a certain failure are. A failure that may not at all be related to code but, say, to a long power glitch. Or a component failure. In my field the equipment must often still perform a graceful exit, pumps have to properly wind down, pressure needs to be maintained until xyz has been completed and so on. It is what aircraft folks call crash worthiness where a piece of equipment has to be controlled to some extent even after a major mishap or damage and must continue to protect people or property.

Regards, Joerg

I agree documentation can reduce errors, but you made the point in reply to a point about C and concurrency.

Absolutely, and you can be certain their software is *not* written in C which was the OPs point.

Ian

I agree. However, my point was it does not guarantee they will come up with a good design.

Presumably you meant 'without docs' in that last sentence.

Indeed, and it was nothing to do with documentation - it was to do with design quality.

Ian

Hello Ian,

Yes, I did. Sorry.

That's not determined yet. I just cannot imagine engineers not asking that question in a design review. So in a lawsuit a smart attorney would request the design review docs. Even if not I bet the FAA will. And then these docs better be there.

Regards, Joerg

I don't think anyone was arguing that code reviews were sufficient.

Only necessary.

Regards,

-=Dave

I agree. I am not saying documentation is not a good thing. I am simply saying it does not guarantee a good design as your example demonstrates. In fact the documents may well show that the question was not asked. It might show the question was asked but for some reason it was not implemented. Either way the fact that it was documented did not contribute to the quality of the design.

Ian

Not necessarily. Many very subtle bugs are hidden this way. Code reviews in my experience rarely find them.

Er?? Let's be clear. I expect there to exist a document that describes how it is supposed to work *before* software design commences. I also expect the software design to document *how* it achieves this. Again, code reviews alone cannot adequately verify this. If they could then presumably testing would be unnecessary.

Ian

Hello Ian,

We are probably on the same page here. All I am trying to say is that it is next to impossible to create a reliable product unless both HW and SW are documented during the design, not as an afterthought.

In the helicopter case the documents will not bring those lives back. But they will enable the manufacturer to learn from it and improve the design process. If there were no docs they would likely never find out what went wrong in the design process, when or why.

Regards, Joerg

Hello Ian,

Simple code reviews may not but design reviews can. One example: I asked a group of SW engineers what would happen if the image rotation data written to disk were corrupt because someone shut down the unit while it was being written. "Well, they are supposed to do an orderly shut-down first"... "What if the power went and they couldn't?".... "Er, ahem, well, ahm.........".

We ended up doing what aircraft guys do, three consecutive writes and a majority decision. Without a design review this would have gone unnoticed and because the FRS just isn't that detailed.

Regards, Joerg

With you 110% there.

Agreed. As another poster said about code reviews, docs are necessary but not sufficient.

Ian