Project14 | You Decide the Next Monthly Project Competition!

I am enjoying the interchange of ideas here. I do have a small issue with using excrement as a unit of measure when talking about some devices, though. I think what needs to be understood is, many times the complaint isn't with the hardware (DDS), but usually with the implementation software (embedded). I have implemented a four cylinder engine controller on an Arduino-Nano. However, I ran into significant limitations and timing problems when I used the installed (Arduino) package.  The hardware (328p and USB) was what I was interested in using, so I compiled and loaded my own interrupt handlers and communication software, blowing away what was in there from the factory. I thought at some point, I would go back to if I could work around the problems I had with the installed loader, but haven't gotten to it yet.

The point I am trying to make is my issue with many electrical engineers in general, their training in the area of software development is sorely lacking. What I find is the words "never" and "always" get used when explaining conditions encountered with certain hardware platforms, when in fact, a person with a strong background in software can see a less common route to the solution. This also highlights an issue I have during part selection in initial development. The rating system used by an electrical engineer is based on available registers, clock speed, and assembly level instruction set. What I point out is, "when was the last time you programmed a project all in assembler?". The compiler, for whatever language you are using should be the determining factor. Does it take advantage of all the resources and instructions, and how good is it at optimization. Sadly, during development of hardware platforms, the question of how good the compiler is, is not considered.

More software,

Jack

I am enjoying the interchange of ideas here. I do have a small issue with using excrement as a unit of measure when talking about some devices, though. I think what needs to be understood is, many times the complaint isn't with the hardware (DDS), but usually with the implementation software (embedded). I have implemented a four cylinder engine controller on an Arduino-Nano. However, I ran into significant limitations and timing problems when I used the installed (Arduino) package.  The hardware (328p and USB) was what I was interested in using, so I compiled and loaded my own interrupt handlers and communication software, blowing away what was in there from the factory. I thought at some point, I would go back to if I could work around the problems I had with the installed loader, but haven't gotten to it yet.

The point I am trying to make is my issue with many electrical engineers in general, their training in the area of software development is sorely lacking. What I find is the words "never" and "always" get used when explaining conditions encountered with certain hardware platforms, when in fact, a person with a strong background in software can see a less common route to the solution. This also highlights an issue I have during part selection in initial development. The rating system used by an electrical engineer is based on available registers, clock speed, and assembly level instruction set. What I point out is, "when was the last time you programmed a project all in assembler?". The compiler, for whatever language you are using should be the determining factor. Does it take advantage of all the resources and instructions, and how good is it at optimization. Sadly, during development of hardware platforms, the question of how good the compiler is, is not considered.

More software,

Jack

Thank you for your support, and sorry for getting off topic.

I would like to see a project that is focused on software as well.  Bells and whistles are hardware, as well as shiny objects, but my point from before, their focus can be a distraction at times. How about applications that are built for portability. They can be tested by having them run stand alone on Arduino, BBC, and Raspberry. Possibly switching up languages as well, porting the portable C program to Python/Tcl.