Blog

Standards need to be set and followed within the organization. I group standards into industry standards and internal standards.

Designing and producing an embedded product is a team effort. But sometimes hardware and firmwares engineers don't talk to each other.

How many of us are guilty of writing firmware and then getting it to work without thorough testing? Or do we plan ahead?

By having the device driver return the settings that it used in the hardware, the test harness could verify proper operation.

Dangers of read-modify-write operations on registers create exposure to collision and corruptions by firmware.

CPU commands can be used to assist firmware read-modify-write operations, but such solutions are not without their own dangers.

Having multiple device drivers accessing the same register for read-modify-write operations can be dangerous.

On many occasions there was someone attending our meetings who was not part of our team but was a representative of some other team.

When someone starts pulling hard for a “one and only true” way, I look very carefully at their arguments.

Some have said that 5 to 20% of their code is product specific. The larger the code base, the more they split product code into files.