This week, I won't be launching a new FAQ question.  Instead, I would like to ask your suggestions of topics that I should start in this forum and that would end up hopefully creating great content for the Embedded Systems community.

So far, we have done:

• Free and Open Source Software for Embedded Systems
• Selecting the Right Microcontroller for your Application
• Embedded Engineers Most Important and Useful Skills
• What is a Bootloader and when do you need one?
• Embedded Software - Good (and Bad) Programming Habits
• Secure Bootloader - When, Why, How...
• Debugging Embedded Systems - Favorite Tools, Strategies, Best Practices...
• When and How to use the Volatile Keyword (Embedded C Programming)
• When (and why) is it a good idea to use an FPGA in your embedded system design?
• Firmware vs Software vs Hardware vs Device Driver, what are the differences?

I am looking for topics suggestions that you believe would be fun to discuss and would end up creating some very useful and/or interesting content for the Embedded Systems community.  

Please contribute one topic per post so that others can 'thumbs-up' the topic if they believe it would be interesting to discuss.  Also, please limit your contribution to a maximum of two topics (two topics suggestion per individual).  

$150 will be divided between the contributors who will have suggested topics.  Your slice of the pie will be proportional to the number of thumbs-ups your suggestion will receive.  

Thanks a lot!

Proposed Topic: Standards and the Small Business Embedded Developer

Small businesses make up 99% of the U.S. economy, and many embedded developers work in small firms. However, many of the standards increasingly used by developers (USB, DisplayPort, Ethernet, etc) rely on standards targeted and priced towards large companies. Whether its an IEEE OUI for MAC addresses for an Ethernet port, a USB Vendor ID, a DisplayPort license from VESA, or whatnot, the upfront and annual costs to use these common peripherals--increasingly found on embedded micros--is often prohibitive for small firms or small volumes. What are the solutions and work-arounds other embedded developers have found? For example, some IC vendors allow the use of their vendor ID and will assign you a Product ID for USB at low or no cost. It's also possible to buy MAC addresses in FLASH from companies like Microchip. What other options exist for staying legal and competitive?

I don't know if it is a subsection of Bob's suggestion: patents- is it worth taking them out. How do you check to see if you are violating a patent? And maybe even licensing a patent.

I love it, exactly the kind of suggestion I was looking for.  Thanks for being the first to suggest a topic!

I am not very knowledgeable in the area (and why I would like to see this be discussed). However, here are some possible questions:

• Open Source (GCC and the like) vs. Paid (IAR or similar)
• What are some pros/cons of using one compiler over another?
• Does anybody have a favorite compiler that they try to integrate into everything

I'm a student and had an opportunity to design an automated vending machine for a start-up. Having only worked on hobby grade projects before, I realized there is a lot more to a product.
A discussion here would be interesting as to how to transform a project into a product, the challenges faced and important things to be considered while doing so.

Proposed topic: Philosophy of documentation

"A product is the sum of its parts, but the documentation does not necessarily reflect the same breakdown."

I wrote a blog on the topic that will fill out what I mean, but here is an extract:

"Packages like Altium integrate many aspects of the design. The schematic, PCB, assembly drawing, mechanical and possibly even firmware are all part of the same design environment. So much so that our draftsman insists that the PCB is the physical manifestation of the schematic and so both should always be in lockstep using the same revision. So if a component value changes, the PCB revision must change! What do you do? And on top of that, what is the number allocated to the schematic, assembly and mechanical drawings that is modified any time the PCB is changed (including possibly trivial stuff like silk-screen updates)? Where in the hierarchy do they lie - are they associated with the catalog number or the PCB number? And where do you file them so that when an engineer updates a drawing, the draftsman works from the changed drawing and not the one automatically stored as part of the PCB package? "

Another proposed topic: Embedded Programming Languages.

At the lowest level, we have instructions and assembly code. However, nobody uses assembly to program anymore, right?? Writing a 32-bit multiplier in assembly is just an educational exercise, right? 

C seems to be the most widespread and accepted language for embedded programming. That is all that I use at work. The big cousin C++ seems to have a mixed history. Although portable and highly reusable, its use seems to instill fear in embedded programmers. 

I know there are some other high-level languages that are used especially in safety-critical applications, such as SPARK and Ada. I have very little familiarity with these.

And I hear that using Python on an embedded MCU is becoming more commonplace. I do love Python, but is this even efficient? What are the trade-offs?  

Are there others that I haven't mentioned?

I would like to see people chime in with their personal experience, preferences, pros/cons. 

• What languages have you used in the past and for what kind of application? Control, safety, residential, etc.
• How does your choice of programming language relate to the size of the project? How about re-usability? 
• Are people generally limited to a language because of the support provided by the vendor or 3rd parties?
• Do different languages make more/less sense when there are few (1-2 people) vs. a team (3+ people) working on the same code base? 
• A little bit off the path - if it was entirely up to you and you were not limited by the choice of compilers, what language would you prefer to use in an embedded system? 

With complexity of projects and the number of developers being involved the need to use a configuration management system becomes more and more apparent. I'd like to get a discussion started on a few "ideal world" questions:

• What features does the ideal CM system provide?
• What should the user interface look like?
• Which use cases should the CM system support?
• Which of the CM systems out in the wild gets closest to the ideal? Git? Clearcase? Perforce? Continuous?
• Surely there are other questions...?

This is not related to the bare metal programming we normally discuss here. However, for a professional software developer the CM system is of utmost importance since we have to deal with it everyday.

Topic: 

What are the steps you have to do for a new Product / Device you are designing?

its similar / related to
trmittal24 Difference between an Embedded Systems Hobby Grade Project and Product

Some possible sub-questions that could fit for this:

• what are the development steps you do?
• how is your process defined?
• how much people work on one project?
• how much time do you calculate for each step?

parts of this eventually already answered in other FAQ-Topics...

Proposed topic "Design for Product certification".

Any product commercial / industrial / automotive / aerospace, will require its own certification (may be self certified, or certified by relevant authority).

In any product design over the years of my experience, what I have found is the businesses allocate few spins for  different stages of product design like proof of concept, prototype, pre-certification, certification, production trial etc. But this will increase the time to market and hence overall profit from the product.

 If the design is done such that product certification requirements taken care the number of pins can be reduced and hence decrease time to market and increase the overall profit.

This discipline needs a thorough understanding of the product certification requirements and induct them in concept and design phase itself and one can reduce the no of spins by clubbing concept + prototype or prototype + pre-certification phase to one and reduce cycle time by 3-6 months. This also requires many disciplines coming together like, EMI / EMC, RF, High speed design, Product safety, Security, Reliability, etc.

More the efforts spent in earlier stages will yield more reliability and less cost less time to market and finally more profit.