As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I want to make a list of things that need to learn that is valuable for my career. What skills do you think are vital for an embedded developer, now and the distant future?
I have become quite proficient with C and ARM assembler through working with embedded Linux kernel and I'm about to dive into Linux drivers. However I can't help to think that I'm maybe narrowing my skill set to much. I want to keep working with embedded systems in the future but you never know the job market (paranoid that I'm going to be outsourced to China and India).
I feel that I'm currently quite weak with C++ and Java, I would also like to learn the Android kernel in the future. I also don't know any scripting languages.
Can anyone who has worked with embedded systems for a while, give some input on what skills/languages they think is vital for an embedded developer? Should I continue to only hone my C skills or should I learn new things.
Here's my list:
C essentials
OOP/ C++ - classes, encapsulation, polymorphism, overloading/ overriding, templates
Algorithms - search, sort, b-trees
Design Patterns - factory, observer, singleton etc.
Real Time Operating Systems - primitives (semaphore, mutex), scheduling techniques, user/ kernel space
Linux fundamentals, driver writing, shell
microprocessor fundamentals - interrupt processing, registers, assembly code, etc.
microcontroller fundamentals - ADC, DAC, Timers, PWM, DMA, watchdog, etc.
Memory - NOR, NAND, SRAM, DRAM, wear levelling
Basic protocols - I2C, SPI, UART, LIN
Advanced protocols - SATA, PCIE, USB, CAN, MOST
Concurrent/ parallel programming - MPI for SMP etc.
UML - class diagram, component diagram, state diagram, sequence diagram
Perl or Python for scripting, for e.g. to modify simple text files.
Java and Android
Basic electronics - schematics reading, using oscilloscope, multimeter, soldering iron
Specialized techniques for embedded programming e.g. debouncing of switches, resistive ladder switches, rotary encoders, etc.
software engineering - SDLC, CMMI, agile methods e.g. SCRUM, version control (ClearCase, git, svn), bug tracking (JIRA?), static code checking, Lint, unit testing, continuous integration
build environments - makefile, cmake
Basic FPGA/ ASIC design, basic DSP
As mentioned by Lundin, this question is open to many different answers. You have from small battery-powered memory-constrained bare metal embedded devices to more complex systems running Linux.
First of all, it's very important to be a flexible developer. You need to be able to adapt to changes as quickly as possible. You may need to do a concept-proof prototype in just a couple of weeks in a language you've never used before, or to start working in a legacy project to fix a bug very quickly.
It's very important to know about software architecture concepts, RTOS, event-driven systems (embedded systems are reactive by nature) and modeling too (UML). Maybe test-driven development (TDD). These are language-agnostic, and will help you to develop good firmware from the ground-up.
Regarding to languages, I think that C is used in both small and big systems, so having a good background in C is a must. Here I'm not talking about c programming at a novice-level. I'm talking about knowing what the processor and the compiler do behind the scenes. According to what you mentioned, you probably have these skills. This is very helpful in the case of small systems, where every byte of RAM and ROM counts.
Knowing something about MISRA-C rules will help you to develop safer C code.
Probably you will need some scripting programming to perform automated testing, data processing, code-generating tools, etc. I use Python for all of this, and also some linux shell scripting.
Being able to design PC-based applications is useful for creating test fixtures to test the embedded devices in the production line, or maybe because the embedded device just needs a pc software to work, like a pocket USB-based oscilloscope. In this case, I use Qt, since it's cross-platform, but you can use Visual Studio with C# if you only want to work in Windows.
In the case of embedded systems, it's better if you have a solid hardware background. Also, you need to be able to use an oscilloscope, a logic analyzer, a signal generator, etc. Sometimes you will need to fix hardware problems with software. :)
Here is a small list of books I find very useful:
Practical UML Statecharts in C/C++.
UML Distilled.
Making Embedded Systems.
Computers as components.
Embedded Software Primer.
Better Embedded Systems Software.
I hope it helps.
Fernando
Whatever the domain you want to select not only C programming you should know but you should also be good familiar with hardware.
It doesn't matter which domain your are working on (linux, vlsi, arm....). But matter how efficient your code is running on the hardware.
If you really would like to work in embedded world, you will find your way.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I'm a firmware developper and I usually develop firmware in C or Assembly. However, I came across a project completely implemented in C++ in our embedded library. Now I know object oriented languages can be used on a hardware level, but I would like to know why they aren't that popular when developing embedded systems.
The real reason: because of conceptual complexity. C and assembly provide an a simple mental model to track what is going on in the system. Object oriented programs require a more complex model that makes it harder to reason about what is going on.
Embedded systems tend to be environments that call for very tight control about what is going on in the system versus the more open ended server and PC environment. This requires both simple and transparent programming constructs. Both C and assembly provide a high level of visibility on what is really going on in the system at the lowest hardware level.
Object oriented languages in general and C++ in particular, abstract away many of the details of what is going on in the system when code is executed, thus making it much harder to reason about the inner working of the system.
Here is an example to explain what I mean. Consider the following code snippet:
i++;
Seeing this in a C program gives us a mostly accurate idea about what this does and an order of magnitude about how many CPU cycles are used, how many registers are involved and so on.
Now what does the same line will do in a C++ program? well, it depends. Depends on what type i is and how has the ++ operator been overloaded. See what I mean?
None of these comes to say that C++ or object oriented is bad. It is not. It does require a much more complex mental model if one is interested about the minute details about what is really going in the system, as many embedded developers feel they need.
From technical point of view, embedded systems have limited resources. Object oriented languages tend to create much bigger binaries than pure procedural ones, thus many would choose something that's as light as possible. For instance, I work for a smartcard company and my team is the one handling extremely low cost cards, with RAM ranging only from 1.5 - 1.75 KB and EEPROM from 96 - 136 KB. For this kind of embedded environment, most object oriented languages (especially the heavy ones such as Java) won't fit. We don't even use ANY standard C library, everything is written from scratch for size. C++ might fit, with proper coding technique and use of compiler options that doesn't generate rtti, minimize vmt, use only stack based objects, etc. but it's just my guess.
"OO languages" is too broad. There are lots of object-oriented languages with radically different characteristics. "It can be done in C++" doesn't imply "it can be done in any OO language". Good luck for writing a Python program for a less powerful AVR MCU for example. The device has 2kB of RAM and 32kB of Flash memory, the Python interpreter itself doesn't even fit into them.
C++ is a language with high-level and low-level parts at the same time. It's object-oriented, but at the end, your nice OO code will be compiled down to raw machine code, just as if you wrote it in C or assembly directly. Some other object-oriented languages, which are considered "higher-level" (or high-level-only, rather), can't do the same thing. It's all about the implementation of a particular language, really.
One addition to what all others said:
We don't write much C++ embedded code because the customer demands it. In my field code may need to get a certification and certification guidelines only exist for C, not C++.
Therefore the project has to be implemented in C even if C++ would lead to a better product.
Because many developers "think" that C++ is not suitable for embedded environment at all because of code size and performance! and this is not true in most cases !
I strongly recommend to read those slides which is talking about C++ usage for embedded and talking about C++ myths like:
The "Bloat" Myth !
The "Poor Performance" Myth !
Many compiler vendors for embedded targets provide C++ compilers like Keil , IAR , CodeRed also processor manufactures provide their toolchain with C++ compilers e.g. Texas Instruments, Freescale,...
Generally the developer need to consider c++ while starting a new project and determine to use it or not based on project needs and what OOP/C++ could provide to get the job done on time on cost!
I want to know in which applications/programming domain are most suitable for Smalltalk. Could anyone please provide me some useful links that could answer my query?
Through googling I learned that some companies use it for:
logistics and foreign trade application
desktop, server and script development
data processing and logistics, scripts and presentations
but I cant find documents/research papers that can tell me which programming domain Smalltalk-80 (or Smalltalk) is best suited.
Some of the programming domains are:
- Artificial intelligence reasoning
- General purpose applications
- Financial time series analysis
- Natural language processing
- Relational database querying
- Application scripting
- Internet
- Symbolic mathematics
- Numerical mathematics
- Statistical applications
- Text processing
- Matrix algorithms
I hope you guys can help me. I am doing this for my case study. Thanks in advance.
It's a general purpose programming language. To paraphrase Kent Pitman on the question of what Common Lisp is useful for:
...Please don't assume [Smalltalk] is only
useful for Animation and Graphics, AI,
Bioinformatics, B2B and E-Commerce,
Data Mining, EDA/Semiconductor
applications, Expert Systems, Finance,
Intelligent Agents, Knowledge
Management, Mechanical CAD, Modeling
and Simulation, Natural Language,
Optimization, Research, Risk Analysis,
Scheduling, Telecom, and Web Authoring
just because these are the only things
they happened to list.
It's particularly suited for applications that cannot have downtime - it's quite normal to patch a running server in deep ways (say, by changing the shape of your class) without taking the server down - or systems that are very complex or have rapidly changing requirements.
Smalltalk has quite substantial growth recently in web based applications, thanks to innovations and fresh approaches in Aida/Web, Iliad and Seaside Smalltalk web frameworks.
In general Smalltalk is used for most complex information systems, let me mention just two:
Finance: Kapital, a risk management in JP Morgan
Manufacturing: ControlWorks, for chip manufacturing in AMD
My goal has been to do a brain dump into software. And I have found Smalltalk to be very well suited for that. Smalltalk makes it easy to put my ideas down in code. And it provides feedback to my thinking. The ability to debug infinitely deep at any point in the execution just enhances my understand of the problem to be solved. Then it allows me to carry out my solution most naturally.
Aik-Siong Koh
I'm afraid you will get as many answers as users of Smalltalk. For some it's a "way of life" for others it's a learning process and in the end they "strand" at granddaddy of the OO languages. Some are using their smalltalk as a kind of shell to "IT-problems".
For me the answer is for application development. Now this is definitive a wide field. As you figured out it is used quite "much" in the software for economic stuff. And that is where I'm using it. I've decided to use it for my Web-Development projects which are related to "business".
The domains you named are all suitable for Smalltalk. Smalltalk shows its strengths in development for systems that are engineering-time limited, instead of hardware-limited.
The Seaside web framework allows us to create complex web applications in a fraction of the time needed in other technologies. The Gemstone object-oriented database allows us to nearly ignore persistence issues.
Smalltalk is generally a very expressive, readable, and understandable language. Whenever a large codebase is to be maintained or code needs to be understandable to non-professionals, Smalltalk shines.
»Smalltalk is a vision of the computer as a medium of self expression. … A humanistic vision of the computer as something everyone could use and benefit from. If you are going to have a medium for self expression, programability is key because unless you can actually make the system behave as you want you are a slave to what’s on the machine. So it’s really vital, and so language comes to the for because it’s through language that you express yourself to the machine.« – Elliot Miranda
You can check this link: http://www.clubsmalltalk.org/web/index.php?option=com_content&view=article&id=183&Itemid=117 this is a compilation of uses of smalltalk in latam.
perhaps another way of answering the question would be by stating what it might not be suitable for. One domain would be where you have "real" real time constraints i.e. you would need to control the garbage collector from kicking off. If I recall IBM's (OTI) Smalltalk embedded had a mechanism for turning off the gc, but IBM dropped that a while ago. The other domain I have not seen much of is cell phone apps. As far as I know none of the viable Smalltalk's can run on Android but that may change. One hears of folks in Squeak/Pharo working on that. I would love to see ST running well on Android. I think that the Android tablet market will be a hot one.
I should conclude by saying that in all the years I have been coding in ST i.e. since 94, I have seen Smalltalk in just about everything else.
I cant find documents/research papers that can tell me which programming domain Smalltalk-80 (or Smalltalk) is best suited.
This is because Smalltalk is not a domain-specific language, but a general purpose language.
Things it has been used for in the past:
- as the operating system system language for personal computers
- writing rich multimedia and near real-time applications, such as sound synthesisers
- very large corporate and government data processing systems, such as the UK's Home Office Large Matter Enquiry System, or many of JPMorgan Chase's financial trading systems
- web applications, such as DabbleDB
- creating complicated development tools, such as IBM's VisualAge IDE
- experimenting and prototyping applications in early-stage development
Generally speaking Smalltalk shines where the systems are complex, development speed is a key factor, and maintainability is going to be a key factor.
I use Smalltalk to create applications to control, manage and distribute multi-platform JavaScript webapps.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I have a great idea for a 3D network game, and I've concluded that it is possible to write it in Java as an applet which will live under the web browser, just like a full software in C++. And it will look and feel the same.
The main advantage of Java on C++ is that with Java you can play without downloading any software. I have already thought about the download of the graphics, sound, etc but I found a solution for it. RuneScape just proves that it is possible.
So my first question is, should my game live on a web browser or on the operating system? I think that in a web browser it is much more portable, although you need install Java and stuff. But the fact is, that most MMO games are currently not in the web. If you suggest in a software so please suggest a language either - C++ or something more productive like Python or C#?
So after choosing a language, I need a graphics solution. Should I write directly with OpenGL/DirectX or use a game engine? What game engine should I use? Ogre? jMonkeyEngine?
What's your opinion?
Thank you!
P.S: Please don't use answers like "Use what you know".
Despite your last point, use whatever you can, and what will provide the biggest user base possible.
Applets are old, and no longer used as extensively as they used to. Flash or Silverlight are the "standard" for web games now. It may be worth checking out JavaFX based your interest in using Java, it's supposedly a replacement for what applets should have been. I've not actually used JavaFX, nor do I hear much about it, take that as you wish. The biggest benefit of deploying to the web is as you've said, the user base is larger and people are more likely to give your game a play. The downside is that you end up using the likes of Flash or equivalent for the development process.
If you go down the route of building a standalone application, you can use whatever you want. C++, Java, C#, Python and so on are all viable options. You can make games in most languages. C++ is the industry standard but ignore this fact. You can make amazing looking and performing games in any language if you are a hobbyist developer. What I'm trying to say is that unless you are building the next big hit, using C++ can be avoided. In contrast to web applications, your users will require a framework/API that you use. For example, they'll need OpenGL/DirectX/XNA and so forth. As for XNA vs DirectX vs OpenGL? It matters not, your language choice will most likely dictate your choice of graphics API/Framework. So I'll leave this point up to yourself for research.
As for should you use an engine? It depends.
Are you making a game which is complex enough to warrant an engine?
Do you wish to just focus on the game, rather than the engine?
Do you feel comfortable learning an existing engine?
Do you feel comfortable producing the required components (collision etc..) on your own?
Other factors come into this, but it may be worth just focusing on the game at hand. You can easily write a simple enough engine for what you require. By doing this, you'll avoid licensing and deployment issues.
One option to consider is the Unity 3D game engine - in addition to being a fairly powerful development tool, it has several cross-platform deployment options. You can build both a stand-alone executable (for Windows and Mac, not yet Linux), and a web-browser version, which answers your first question about deploying on the web versus OS. You can do both.
It also uses both Javascript and C# (and Boo, a variant of Python) for scripting languages. These are based on Mono, the Open-Source version of .NET, so it's not just a gaming platform, but has access to all of .NET's abilities (well, those implemented in Mono anyway).
See the Licensing page for a long list of Unity's features (the Basic version is free). And check out the list of Unity-based games, of which the first is Tiger Woods PGA Tour Online, by Electronic Arts.
A game that just runs as an applet will not be percieved as a real game to most hardcore gamers.
If you want a game that is played only by noobs, the java might be an option, otherwise drop it and stick to a language that allows to actually produce executables.
Talking about the library, there are not so many you can't try them all and chose the one you like the most, so... do just that.
I'm a software developer. I've been programming in high level languages for a few years.
I would like to know, how to take my first step into programming hardware. Not something crazy complicated, but maybe some ordinary CE device? Assuming I don't need to put the PCB together with varies components, but just to program the tiny cpu?
How low-level do I have to go? ASM? C? manipulating registers? or are the dev kit quite high level now? Is Java even in the picture? OO coding in hardware, is that even a dream or a reality? Need a reality check.
I also tend to learn better with books or sites that are written in a tutorial format. Something that guides the way for me from something simple to something more complex. Any recommendations? Maybe something that will introduce me to the popular hardware (microprocessor/micro-controller) available today?
Much appreciated, thank you everyone.
The actual programming isn't a big deal. The frustrating, annoying part is getting your development environment setup and getting the tools working. Once you've done that, you're half done.
I'd suggest buying a development kit ('dev kit') that has USB built in and works with your chosen OS. Get that working, and you're halfway done.
If you're missing the knowledge, it's also important to know the basics of how a processor works. You'll be programming at a much lower level than any other programming, so the fundamentals are a bit more important.
If you know C then it's only a matter of learnig the tool chain steps to download the code.
Easy place to start (cheap hardware/software) http://www.arduino.cc/en/Guide/HomePage
I have been coding in C both as a hobby and professionally for about 16 years now, but always for userland code (i.e., programs, not kernel or drivers). Most of my jobs involved high level languages (I have done a lot of Perl and Ruby programming, with the occasional Java, Python and shell scripting in between). I did develop a lot for MS-DOS (which was probably as close to bare-metal programming as you would get on a x86 machine), but my last job involved 5 years of Perl and Ruby on Rails web development.
That being said, I am now a senior engineer for embedded Linux development, developing drivers (including an emulator for a legacy simple microprocessor inside a kernel module) for uClinux on the Blackfin platform. There are times when my inexperience with hardware related issues (i.e., floating signal levels due to lack of a pull-up/pull-down on a pin) did get in the way, but it has been mostly a highly enjoyable and thrilling experience. As stated by others, understanding your tools is essential -- for uClinux, that meant the GNU Toolchain, which fortunately I was already familiar with due to my background on FOSS technologies.
The Blackfin is hardly an entry-level microprocessor (in particular, it does not have a MMU, which has some relevant effects on Linux development), but as already stated, you can buy a Beagleboard for around US$200 with all required accessories and start messing around with it in just a few days. If you want something simpler, there are many Arduino options out there, though if you have some real development experience under your belt I believe you will find their development environment a little limiting (I know I did).
After you get comfortable with your tools you might want to spend some money on an in-circuit emulator (or ICE). These are usually highly platform specific (both in terms of target architecture and development environment), but are highly recommended for anything beyond the usual blink-LEDs-after-button-press examples I am sure you will quickly outgrow.
In few months you will find yourself building custom images for hackable customer devices using Buildroot and having a lot of fun. All I can say is, go for it, it's highly addictive and not particularly expensive to do nowadays.
Also something to look into is the Microsoft Robotics Studio. They support quite a lot of hardware boards (including CE), and with it is is fairly easy to get a small robot up and running. And what's more cool a project to learn embedded programming?
It all integrates nicely in Visual Studio (express) and their devkit also comes with a free express edition.
Get a beagleboard. Cheap, lots of users (community support will be key), many OS options. http://beagleboard.org/
Well, if you want to know what you're doing, you need to understand the assembly language of the processor and the processor's architecture.
You will need to learn C to be competent in microcontrollers. There is no way around that.
There are some VM-level languages on embedded systems. I see the Java out-of-memory exception from time to time on my cell phone(which also helps to give me a strong opinion on VM-level embedded languages).
The ARM has some support for hardware-level Java bytecodes.
Your best bet is to pick up something like the PIC or the Atmel chips and begin hacking with them.
If you want to do it with your existing hardware, get a hypervisor for your PC and begin writing a basic kernel.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm looking at doing embedded coding for a device that's approximately 20MHz, has 6mb ram, with an ARM32 processor. Can anyone suggest the best / most appropriate language for programming an embedded system? I'm considering:
Lua
TinyPy
C
Java ME
C#
someone has suggested JavaScript
Any suggestions? Thanks
Edit - looks like C and Lua are the winners. Cheers all!
Edit - Real Time is not an issue, its more the limited ram/cpu dictating things.
If you're bringing the device up from scratch or interfacing directly with non-standard peripherals, C is really the only way to go.
If you've already got an embedded OS or can port one without difficulty, you might have more flexibility in adding one of the more script-y languages. C# is out of the question unless you're on WinCE, and then you'll be restricted to .NET Micro.
Beyond that, "best" has little meaning without describing what your device is going to be used for. Some languages have better support for certain tasks than others.
C is probably your best bet for such limited cpu resources.
I've used Lua on an ARM OMAP processor. Lua's tight integration with C allows going to the metal whenever you need, and its small size makes it suitable for a wide range of platforms. I developed the UI for my firmware in Lua on my mac and then brought it over to the embedded platform with no changes.
While the OMAP processor was beefy enough to run other languages like Java or Python, I didn't know what hardware I was targeting when I started the code. Lua was a safe bet.
I'd be tempted to go with straight C, but then I've been writing C for nearly 30 years. Lua and TinyPy seem too new, experimental, to me; embedded devices need to be very robust.
Java ME has good points. I don't know about C# in an embedded world.
It's important to specify what you expect this device to do. Is it some sort of control application? Does it have to implement algorithms? What about floating-point support? GUIs? Is performance critical? Are you planning on using an OS?
Answering these questions is a crucial prerequisite to picking a programming language.
That said, embedded systems have to be reliable, so I'd go for some tested solution. C is probably the most solid and best-supported option for ARM chips, but YMMV depending on your specific needs.
C is certainly the most used language in embedded systems.
It also seems to be the most talked about language in general http://www.langpop.com/
Edit: hmm. I just noticed that the 'embedded' you seem to be describing is not about adding an automation language to an application, but squeezing an application into an embedded platform. As others suggest, unless you really need it, skip embeddable languages and program your application in C. There is nearly no runtime overhead for that, except for what you actually use.
In no particular order, Lua, JavaScript and TCL are all quite well suited to embedding. Lua has been the easiest for me to embed. Javascript might be the fastest. All three have good handling for untrusted code, but TCL's is most robust, for example, untrusted code can run untrusted code (if it's trusted to do that much).
Unless you have an RTOS available that supports a variety of alternate languages, C or C++ (depending on your compiler chain) is the way to go.
Your decision is most likely to be determined by the tools avaiable for this processor.
C is by far the most supported language for embedded processors, so you can't go far wrong with that, and it will be good experience if you have to write software for other chips in the future.
C++ is becoming more popular for embedded systems. Beyond that, it depends on your priorities (time to market, resource usage, speed), and the quality of the tools you use.
C the best