When to use high level languages to prototype hardware development


Many times when I talk about hardware development I push the awesomeness of having the ability to use high-level languages. Languages like C#, Python or Java can really do a great deal for your prototyping speed. Yet a few days ago in Kiev I said the exact opposite, I said that sometimes you should not use them and that, in all honesty, might seem a bit confusing. Should you or should you not use high-level languages to prototype hardware? The answer to that questions is : Maybe – after all this is software development and there are no silver bullets. High-level languages tend to depend on if the hardware platform can support them or not. Meaning that choosing between a high-level language will force you to more choices. Choices such as if you can use cheap microprocessors or need a more complex platform.

When to use high-level languages

I choose to use ready made systems as often as I can because, quite frankly, they save a heck of a lot of time between idea and seeing if something will work. So anytime when I am playing around and are experimenting more with the hardware. Anything when I don’t know if what I am doing are going to work or not, I choose to use high-level programming languages and ready made platforms. Think about it! If I want to show functions to a focus group and then act on the feedback, rapid prototyping means everything! That means that speed and cost will both be beneficial from the use of a readymade system that utilizes high-level programming languages for rapid prototyping.

When not to use high-level languages

I choose to use the cheaper microprocessors that you often need to program in C, ASM or similar when the task is set. When we have a product that are going into production in thousands of copies or more. In these events, when we don’t need to prototype time is not as important as a low production cost per unit. But developers should also consider things like time to market and how hard it will be to update/fix bugs in a solution that does not support true OOP etc. Using products that is a prototyping tool and can be resused is a good middle ground here. Products like the Arduino that allows the hardware designer to implement it’s functions into the hardware.

As you can understand quite often you will use both these before a product is sitting on a shelf ready to be purchased by eager consumers. It is rare to have a problem that is so obvious in it solution, marketability and function that we don’t need to prototype it, but it do happen. And when that happens it is important to think about your options. Should you go with a cheap simple microprocessor that might need to be programmed (not always the case anymore) in a low-level language and have custom circuit boards made or use a rapid prototype platform that works with a high level language for your next project.