Pet peeves? I have many. Here are a few:
Technical documentation. Much of it is poorly written and does not convey a complete and accurate description of the part. This is especially true for complex parts like microcontrollers, and the "remedy" often suggested is to look at the example code or use the vendor libraries. This is nonsense--the documentation itself should be complete and accurate without recourse to other materials like source code. A related peeve is that often these manuals are written by someone for whom English is not their first language. The result is a mess of typos and confusing phrasing. Sometimes these issues even obscure the meaning of the text, or make it incorrect. Many of these companies have offices in the US and should have a native English speaker go over the documents and correct the mistakes. ST is a big offender here--some of their technical documentation reads like it was written by an eight-year-old.
Chip errata. Some vendors don't mind releasing parts with dozens and dozens of nasty errata. A good example was the Microchip PIC32MZ EC. The errata sheet for this part was almost eighty pages long and even fundamental things like the crystal oscillators didn't work. Took Microchip a year to fix some (but not all) of these bugs and release the EF parts. Some vendors never fix certain errata--stepping after stepping of the part gets released with the same errata there year after year.
Vendor websites. Some of these make you jump through hoops to download datasheets and other documentation, sometimes to the point of requiring you to wait for an email from them containing a download link. Others (like Broadcom) won't provide documentation at all, or require NDAs. Oftentimes these sites are so poorly organized as to make it very difficult to find information on their products.
Development Boards. Some vendors like to put too many external peripherals on their boards (accelerometers, SDRAM, LCD displays, microphones, audio codecs, etc) to the point where it's difficult to find a combination of free pins to implement something you need. Some of these vendors don't even bother to break out all of an MCU's port pins on accessible connectors, or, in many cases, only have "Arduino compatible" connectors on the board. Many MCUs have a separate power domain intended to be powered by a battery in case of a power failure, but most vendors don't bother making the Vbat pin accessible to users. ST has the right idea with their STM32 Nucleo boards. These typically only have a few LEDs and a button, but every port pin is broken out to a connector. Another peeve related to dev boards: vendors never seem to provide enough ground and Vcc connection points on their boards.
IDEs. Many of these are based on Eclipse, which in and of itself is okay, but vendors can't resist adding every plug-in and add-on under the sun, and the effect of this crud is to slow everything down to a crawl. Another IDE peeve is the "wizards" often provided to create new projects. There never seems to be an option to create a bare-bones project with nothing except the start-up code--the only options create projects that pull in lots of unwanted crap that needs to be deleted. Do vendors think professional embedded developers always start a new project as a "blinky" app? Hint: we don't.
Some general peeves:
DVDs and Blu-rays that have previews that can't be skipped or fast-forwarded through. People who create these should be boiled in oil.
Drivers who don't indicate when turning or changing lanes. Drivers who use their windshield washers in moving traffic (this usually happens right after I get my car washed). Drivers who throw burning cigarettes out the window.
People who don't use its/it's and your/you're properly in a sentence.
Home
Help
Search
Login
Register
