Related
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.
What languages features are known for being useful for fast prototyping of projects before starting the actual code?
I suggest to look into model-driven engineering. Several tools provide you with quick one-click prototyping out of high level (graphical) models.
For instance, WebRatio lets you design Business processes or User interface models and generates a running web application for you. It is based on BPMN and WebML graphical notations.
[Disclaimer: I'm with Politecnico di Milano and WebRatio, and among the inventors of WebML]
Would the built-in libraries of LabWindows CVI meet the needs of a quantitative developer?
My experience with LabWindows CVI is that its built-in libraries are more geared to instrumentation (GPIB, analog and digital I/O, motion control, and so forth) and
data display (GUI widgets like meters, sliders, switches, LEDs, simple graphs), rather
than extensive libraries of numeric, statistical, or analytic routines. The development environment that comes with Labwindows CVI is pretty decent -- they have a drag-and-drop GUI building interface that makes it easy to position controls within windows and wire them up to your C code, if that matters to you.
But for your analytic needs, you might be better served with a product like Matlab or IDL, especially if your work is heavy on the plotting/visualization end of things.
If you want to stick with C, the GNU Scientific Library has a pretty extensive
set of statistical and analytic routines.
There are better environments and languages for analytics than Labwindows/CVI. I am not saying it is not possible though. NI has extensive support if you stay within their ecosystem. You can use LabView, Labwindos/CVI to program the data gathering part and then visualize/do post calculation it with e.g. NI DIAdem (basically a Excel on steroids).
You have integrated libraries for:
Signal Generation, Array Operations, Complex Operations, Signal Processing, Measuremtn, Statistic, Curve Fitting, Interpolation, Vector & matrix Algebra
A pretty decent list.
But still Labwindows/CVI is more targeted for a test environments where e.g temperature controller, measurement equipment needs to be controlled.
Languages like R, Matlab (as pointed out by Jim), Maple, Mathematica, or even the .net environment may be more helpful to your needs. If you are an inexperienced programmer or not fond of text based languages, check out LabView. Support & community is even bigger than it is for Labwindows/CVI.
I think LabWindows CVI has very nice built-in libraries, but a lot of annoying things, for example popups are not well designed, or multithreading is some kind of wired, and so on. Therefore you have to do a lot handmade, and search your way arround.
I switched over to use Visual Studio with C# and add the national references. National has a very good .net support. I could access my National Hardware almost as easy as from CVI, and can write my code in C# and profit from a well designed and very powerfull language. I think its a very nice Option.
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.
On the surface LabView and Microsoft Robotics Studio appear to me to have a very similar programming paradigm and environment.
Is it fair to compare these two products, or are they in different leagues?
I am hoping someone who has used both products will help compare and contrast them so that I can understand when it is appropriate to use one or the other.
Disclaimer. I have not worked with Microsoft Robotics Studio. I only looked at the fact sheet and some of the documentation. However I have a great deal of knowledge of LabVIEW. So this answer might be (and probably is) biased.
History wise LabVIEW has been around for 20 years and has the following features which MSRS doesn't have (from the first glance).
Platform independent (LV compiles on Windows, Linux, Mac and various embedded platforms), however hardware support varies
A compiler, directly into machine code
LabVIEW is a programming language not targetted at robotics but originated in Test and Measurement
Extensive DAQ and data analysis support
The VPL (MSRS) looks very clumsy compared to LabVIEW code, it looks like MS doesn't really makes the switch to visual programming (or is not allowed by patents from third parties).
Price wise, MSRS is much friendlier with a free 'hobbyist' version, while a LabVIEW base begins around $1300.
Additional MSRS does not run on the robot, it only controls the robot via the robot API (bluetooth or wired), while LabVIEW (and more specific NXT-G) run on the processer inside the robot stand-alone.
What might be important is the LabVIEW is the main software product of NI while MSRS is one of many products of MS, so support and development should have a higher priority.
Ton
I have programmed extensively with MSRDS and to a lesser extent with LabVIEW and here is my opinion. Earlier, most of our software used to developed using LabVIEW but the last few years we have been moving a major part of it to C# because it is much easier to do objected oriented programming using a language like C#. I personally feel MSRDS and in particular the Concurrency Coordination Runtime (CCR) is so underrated partly because of the not so detailed documentation. Although the MSDN forums are excellent, we are required to search through them to find out some of the things that I feel should have been part of the documentation. Another excellent source of information to refer is the book "Professional Microsoft Robotics Developer Studio" by Kyle Johns and Trevor Taylor.
Coming back to the comparison, I feel both LabVIEW and MSRDS (although I am not sure about LabVIEW Robotics) follow different programming methodologies. Although it has been targeted to Robotics, MSRDS is used to harness asynchronous behavior in any application. CCR has some excellent coordination primitives (such as Joins and Interleaves) and it makes asynchronous programming a lot easier. DSS is used to develop service oriented applications that are distributed across multiple nodes residing in the same machine or across different machines. We developed a framework for developing Laboratory Automation Systems using MSRDS. The framework is used to develop distributed component based software that is both thread-safe and responsive.
It is also worth mentioning that Task Parallel Library Data Flows in .NET 4.5 is based on the CCR concepts and also the concepts from .NET RX. I suggest you consider looking at them as well.
Thanks,
Venkat
I think Ton hit it on the nose, but there a couple key points I disagree on.
Independent of price LabView is a far superior system for automation and embedded programming. However, there is the catch that without a license LabView will break the bank a few times over. Depending on your targeted platform, you could easily spend several thousand dollars for a development environment.
Both systems do have a compiler. For a while LabView was restricted to only a few embedded environments, but with the addition of an ARM compiler there are now a huge number of supported hardware systems. LabView is compiled in real time as you program, MSDS is compiled on request (as far as I know).
LabView is absolutely targeted to robotics. NI has put forth a lot of tools for robotic applications and many of the ideas taken from automation can be dropped right into a robotics setting. As an interesting note, the FIRST Robotics Competition exclusively uses NI hardware (the cRIO) and LabView is a popular programming option.
RDS's visual programming and LabView's visual programing aren't really comparable. They don't operate by the same paradigms.
RDS does create machine code and the code can run on a robot without intervention.
If you are looking to buy a complete robotics system for development with LabView check out this page: http://www.ni.com/robotics/how_to_buy.htm
Just as a bit of background, I am a certified LabView developer and have used RDS with the lego NXT system as an instructor.