I don't think so.
I have a Computer Science background and automatic code generation has allways been a big topic there. But it never made it to reality.
Why? Because with the time the processing power grows and with that the technology allways tends to more powerfull frameworks instead of code generation. Frameworks enable you to develop complex software very fast - as it is true with code generation, but give you more flexibility.
I think the same is true or the embedded market as well. Many processors run Linux and there you have a lot of powerfull frameworks at hand to do UI stuff, networking or even so complex stuff like IO and thread scheduling.
I hear this argument quite often from computer science graduates when discussing assembler vs C++ for embedded apps - technology is getting so cheap and powerful that powerful high level languages can be used with embedded operating systems ....
Personally I think this is the wrong way to look at it. Most embedded applications don't need hundreds of millions of operations per second, and even a $5 chip running an embedded OS is massively overpriced. Why throw a system running thousands of lines of code at a problem that has very few inputs or outputs? A 40 cent microcontroller in a washing machine could have it's two or three hundred bytes of code generated automatically from a good flow chart.
Where there are a relatively small number of inputs and outputs (most control systems), automatic code generation is a big help to the companies who's main expertise is the thing being controlled, not the processor doing the controlling. Where expensive PLC modules used in industry for many years used to have a terminal or PC interface and allowed equipment engineers to program machines using logic equations and diagrams, now smaller, cheaper microcontrollers can be employed closer to the work being done - and they need code, which for most systems is going to be cheaper if it's generated by an easy to use automatic tool than hiring a programmer who then needs to learn all about the product being controlled.
Not all embedded applications need internet connectivity, multitasking, multimedia, 16 bit colour, XML parsers or a penguin. Mostly they count pies, turn lights on and off or keep the office at a comfortable temperature - all very mundane and scripted. Ideal for low power drag and drop programming.
I hear this argument quite often from computer science graduates when discussing assembler vs C++ for embedded apps - technology is getting so cheap and powerful that powerful high level languages can be used with embedded operating systems ....
Personally I think this is the wrong way to look at it. Most embedded applications don't need hundreds of millions of operations per second, and even a $5 chip running an embedded OS is massively overpriced. Why throw a system running thousands of lines of code at a problem that has very few inputs or outputs? A 40 cent microcontroller in a washing machine could have it's two or three hundred bytes of code generated automatically from a good flow chart.
Where there are a relatively small number of inputs and outputs (most control systems), automatic code generation is a big help to the companies who's main expertise is the thing being controlled, not the processor doing the controlling. Where expensive PLC modules used in industry for many years used to have a terminal or PC interface and allowed equipment engineers to program machines using logic equations and diagrams, now smaller, cheaper microcontrollers can be employed closer to the work being done - and they need code, which for most systems is going to be cheaper if it's generated by an easy to use automatic tool than hiring a programmer who then needs to learn all about the product being controlled.
Not all embedded applications need internet connectivity, multitasking, multimedia, 16 bit colour, XML parsers or a penguin. Mostly they count pies, turn lights on and off or keep the office at a comfortable temperature - all very mundane and scripted. Ideal for low power drag and drop programming.