Breaking News
News & Analysis

Struggle continues to plug embedded programming gap

5/3/2012 03:33 PM EDT
95 comments
NO RATINGS
Page 1 / 2 Next >
More Related Links
View Comments: Newest First | Oldest First | Threaded View
Page 1 / 9   >   >>
henil43
User Rank
Rookie
re: Struggle continues to plug embedded programming gap
henil43   6/23/2013 10:25:00 AM
NO RATINGS
hey,I am a CS major from india...and i am planning to do my post graduation in embedded system software engineering..i found in my cs curriculum that they focuses on low level concepts like digital design,processors,ALP in just earlier semesters..and switch the focuses on higher level programming like java,vb,c# and php in higher semesters..so most of the students make major projects like websites,web application or mobile applications as their major projects due to current trends in market..and obsolete all the basic studies of earlier semesters..And they cannot perform upto the mark in embedded industries..

SQS Manager
User Rank
Rookie
re: Struggle continues to plug embedded programming gap
SQS Manager   3/12/2013 4:38:24 PM
NO RATINGS
Hello Anthony, I would like to know if you would be interested in hiring a candidate from us on a contract basis. He has expertise in the area of Embedded Programming, C, C++. Let me know at manager@sqssolutions.com. I can forward his resume once you reply. The candidate is currently in India, working on a project for Hitachi Automotive, Japan. He is Involved in Model Based Development, Embedded Testing, Software Design, Tool Based Application, Test Automation, Verification and Validation. Let us know. Thanks. Raja Ismail Manager. Software Quality Solutions LLC manager@sqssolutions.com

george.leopold
User Rank
Rookie
re: Struggle continues to plug embedded programming gap
george.leopold   6/8/2012 2:00:16 PM
NO RATINGS
Some useful observations from reader Anthony Mendoza, who notes that if you are an embedded C/C++ programmer, his company has a job for you: "The problem of plugging the embedded programming gap is very much one of perceptions. Two years ago, a prominent IT magazine had a list of the top 10 obsolete technologies. Number 3 was the C programming language. I quickly sent the writer an email telling him that C wasn't anywhere near obsolete. I just as quickly got back an email from the writer saying that my thinking was just wishful thinking and that in these days NO ONE programmed in C. Unfortunately, this kind of thinking is very common in the industry away from centers of embedded expertise and, until it changes, we will continue to have problems filling our embedded positions. (We have over 30 open requisitions for embedded C/C++ software engineers at my company alone)." Anthony Mendoza Tucson, Arizona

Phil K
User Rank
Rookie
re: Struggle continues to plug embedded programming gap
Phil K   6/6/2012 8:18:41 PM
NO RATINGS
Carnegie Mellon is still teaching embedded skills at a pretty deep level. I teach a 3rd year undergraduate course using an HC12 automotive controller that emphasizes assembly language, C, I/O, concurrency, and other deeply embedded topics. One lab exercise has students optimize C source code by looking at what assembly language is being spit out by the compiler. (They also write some assembly on their own to get a taste.) I feed what I learn in doing industry design reviews back into course content. http://www.ece.cmu.edu/~ece348/ has the topics list.

webmasterpdx
User Rank
Rookie
re: Struggle continues to plug embedded programming gap
webmasterpdx   6/4/2012 3:03:10 AM
NO RATINGS
I think the problem lies in that most of the jobs out there are not related to embedded systems. I love embedded systems with a passion, and will strive with anything to stay in that field, but as an older developer, it's getting harder to find openings. I am also lucky in that I have a strong hardware background. There are many who do not. The problem with the jobs though is that the most frequently exported jobs in the US in the technical fields are the embedded design jobs. Both the hardware and firmware design positions are sent to india, so the field is drying up in the US. The government needs to deal with this and keep the jobs here. Then there won't be a trend for students to not WANT to be embedded developers.

Mohammed.Saju
User Rank
Rookie
re: Struggle continues to plug embedded programming gap
Mohammed.Saju   5/24/2012 3:55:03 AM
NO RATINGS
In view of the troubled programmers in embedded domain, I have personally started a blog to help budding programmers. It is mainly intended for Just passed out graduates, but basics. Due to my official workload I was not able to continue.All please have a look, and send in your comments. http://www.myembeddedodyssey.com/ Plan to put more in the coming months.

DaveWyland
User Rank
Rookie
re: Struggle continues to plug embedded programming gap
DaveWyland   5/21/2012 6:47:03 PM
NO RATINGS
A good, balanced viewpoint. However, some updates might be useful. If your task is controlling hardware where time is important (e.g. most I/O devices), you are driven down to the hardware level of registers and gates plus timing. And typically deeper than the level of the program itself. Joel's Law of Leaky Abstractions says that you need to understand the next level down from the abstraction to be able to debug it when the abstraction "leaks" - i.e., stops working under some condition. Assembly language has one important advantage in this situation: it gives you direct estimation and control of timing. Each instruction takes X number of clocks. Another thing that is quietly happening: Moore's law died - or at least has gone into the ICU. We had 3.5 GHz Pentium 4's in 2004, up from 100 MHz 486's a few years earlier. There has never been a 4.0 GHz Pentium. "Is it not true that Moore's Law [i.e., transistor shrinkage] is still working? No, but it's accurate." At 90 nm and beyond, the chips continue to get smaller, but they get slower and hotter. The grand ride fro 1970 to 2004 is over. If you want performance post 2004, you have to go parallel. FPGA based hardware design can do this; multiple cores cannot. The old dream from the 1980's of a compiler that can take any big C program and break it up into multiple simultaneous streams running on multiple cores remains a dream. So if you are controlling hardware or need more performance, you are going to slide into the world of real time hardware and language abstractions that can support it. Post 2004, the speed of a computer running C or other conventional language is limited to ~2 GHz. This means that software cannot continue to expand in space and time exponentially in time as it has done in time past and maintain acceptable performance. Time is creeping into the discussion, and this will change things, IMO.

DaveWyland
User Rank
Rookie
re: Struggle continues to plug embedded programming gap
DaveWyland   5/21/2012 6:23:06 PM
NO RATINGS
On the contrary, I think Labview is a good idea for Robotics versus C or other languages. Robotics is ultimately about motion trajectories in time, whether platform or arm. Conventional programming languages like Fortran/C/C++/Java/Python/... have NO abstraction for time. Single threaded sequencing is the best they can do. Robot trajectories involve two or motors operating simultaneously to crate trajectories. Examples are two wheel motors and 6+ motors on an arm. Time is the metric method of synchronizing these various motors to create the desired trajectories. Labview and Matlab/Simulink are graphic computer languages that have the abstraction of time built-in. Time flows from left to right in the frame, and multiple simultaneous paths are shown from top to bottom in the frame. Ironically, this is an echo of schematic diagrams that worked the same way. There are two archetypes of embedded systems: embedded applications and control. Embedded applications are simply conventional programs - like web browsers - that run on an embedded device instead of a PC. The smart phone is the current example. Embedded control is about controlling hardware, whether microwave ovens, automobile engine control or robotics. Embedded control is typically real time, meaning that response time is important. Hard real time means Really Important, in that if you are late, things may break and people may get hurt. Real time, and particularly hard real time means that the design of the software is intimately involved with timing, often with several things going on at once that must be coordinated. So time is a fundamental abstraction that is used, even if the tools do not support it well. No, I own no stock in Labview or Matlab/Simulink. But I have been involved in real time control (and lately robotics) for a very long time indeed. Having started out in analog hardware and computer design was a big help here.

ivanwong888999
User Rank
Rookie
re: Struggle continues to plug embedded programming gap
ivanwong888999   5/14/2012 9:02:51 AM
NO RATINGS
Well, in my uni all engineering students are required to be exposed to C programming in their first semester. I'm in mechatronics, so in later semesters, I'm exposed to Assembly languages, as well as C for embedded systems. So, I do know full well how limited are the hardware for embedded systems are..

BentThomsen
User Rank
Rookie
re: Struggle continues to plug embedded programming gap
BentThomsen   5/11/2012 8:58:38 AM
NO RATINGS
In 2003 I posed myself the question why has the embedded systems industry not adopted Java? Well nine years of research later I now have a better understanding of the problem. First of all Java, in its traditional sense, is not appropriate for real-time systems development and many embedded systems are real-time systems. Java lacks a notion of a deadline, real-time clocks and has insufficient semantics for garbage collection and threads. Initiatives including the Real-Time Specification for Java, and hard real-time Java profiles such the Ravenscar Java, Predictable Java and the international standardization effort, Safety-Critical Java, have now plugged this gap. Especially the latter profiles further tighten the semantics of Java for making real-time systems written in Java amenable to static analyses such as WCET analysis. These profiles include constructs for making memory allocation (and de-allocation) more predictable, and talking to hardware through the notion of hardware objects. Next step is to provide implementations suitable for embedded systems. Clearly Java can be ahead of time compiled like C/C++, e.g. by gcj, but usually Java is implemented via a JVM. JVMs are usually big and very memory hungry needing MBs if not GBs of memory. However, in recent years JVMs, such as JamaicaVM, FijiVM, KESO VM and HVM have emerged, especially the latter two can be run on systems where memory is counted in kb. But making a JVM time predictable and analyzable is challenging. It can be done in hardware e.g. the Ajile 100 or JOP processors – the latter being analyzable by the WCA and SARTS tools. For many embedded systems a dedicated Java processor is not acceptable. But making a SW JVM predictable and analyzable is more challenging, but now doable, e.g. the HVM is complemented with the TetaJ tool. Next question is how to make the embedded industry pick up these technologies

Page 1 / 9   >   >>
Flash Poll
Radio
LATEST ARCHIVED BROADCAST
Join our online Radio Show on Friday 11th July starting at 2:00pm Eastern, when EETimes editor of all things fun and interesting, Max Maxfield, and embedded systems expert, Jack Ganssle, will debate as to just what is, and is not, and embedded system.
Like Us on Facebook

Datasheets.com Parts Search

185 million searchable parts
(please enter a part number or hit search to begin)
EE Times on Twitter
EE Times Twitter Feed
Top Comments of the Week