Question to MGTOWs Working in Embedded systems..

[ryuk_shinigamiParticipant 95]

My fellow MGTOWs working in Embedded systems,

How often do you use python?
And for what kind of tasks do you python?
I see on stack overflow, that C is the preferred language for embedded,

http://stackoverflow.com/questions/812717/is-there-any-reason-to-use-c-instead-of-c-for-embedded-development

And I see employers asking for C/C++ as proficiency..
Do I need to know C as well?
And If that is not the case, C++ is fine, then,how well, as in what topics in C++ do I need to know for getting into Embedded?

Will knowing how to code data structures(stacks,queues,trees) do me any good in embedded systems?

Apart from the above mentioned stuff, do I need to know, other stuff also?

Thanks in Advance..!!

Some people call it fate. I call it, "Chaos Theory" - Sam Fisher

[Anonymous 3]

C is very useful to know at least the basics. For example I am into NI Labview, but a few times I had to write my own DLL (in C) that I called from the main program.

But I have to tell you, programming and coding are two slightly different things. Programming includes to design the architecture and structure and subroutines and classes and object oriented programming stuff, and documentation as well. If you ignore these, you will have trouble understanding your own code after a few years, not to mention others.

So develop good practices.

[sidecarParticipant 35837]

I occasionally use python if I need to gin up a quick user interface on a host machine that will drive the embedded device, though usually I use java for that. Python is also good for quick and dirty mock ups when you’re submitting a project proposal.

On the embedded device itself, at a bare minimum starting point it’s forth during the hardware debug phase and c with the occasional assembler snippet where absolutely necessary. And nothing else.

Embedded systems are all about doing the necessary with the minimal as reliably as possible. The more layers you put between your code and the hardware the more expensive everything becomes and the more places you create for something to break.

For more complex projects you generally find yourself developing to whatever RTOS (like VxWorks) or just plain OS (like a small footprint linux) you decide to use, and that will determine what language you use based on what development environments are available for that OS. And that will usually include c, because c is ubiquitous.

So I guess what I’m saying is you’ll need to know c. And then you’ll go from there depending on what’s available. But it’s a lot easier to develop with c and go upwards when permitted by the project than start with, say python, and find yourself forced down to c. A c developer who gets the occasional chance to code something in python is a much happier man than a python developer who finds he has no choice but to do some little task in c (or assembler).

In any event, whatever language you end up using, make damn sure to compartmentalize your code properly, keep track of your revisions, and document the f~~~ out of everything even if you’re only documenting it for yourself. I have a number of examples where less than ten lines of code have more than ten paragraphs of documentation. A bit more typing now will save you a lot of time in the future wondering just what the f~~~ you were thinking.

[AttonParticipant]

Never used python I find it gay I use C++ and Lua.

A MGTOW is a man who is not a woman's bitch!

[RyshParticipant 134]

Hi ryuk,

I think I can say something here because I know the domain quite well. So let me break it down a bit – embedded systems cover a lot of things.

– “big” embedded systems.
Cortex-A or x86 systems in small form factor cannot be used “bare metal”, at least not if you want the project to finish in any reasonable time frame. You will have a full-fledged GNU/Linux running. If you have such hardware, use Python. Both C and C++ have much longer development cycles, which would bump up both project cost and time to market.

– “medium” embedded systems.
Cortex-M comes to mind. Forget GNU/Linux here, the memory footprint is too large. Even if you have external RAM, you would have to load the GNU/Linux from SD-card into the external RAM and run it from there. It would be quite slow because external RAM has only about 10% of the speed of the on-chip SRAM.

Either you’d go with a small real time operating system, that is if you need multitasking. Get familiar with stuff like dead locks, race conditions, task synchronisation and the like. It’s really fun here.

Otherwise, you could as well go bare metal. Python is out of question. What you need is the ability to go through the microcontroller’s datasheets and understand how to program tons of registers (config, IO and things). Putting interrupts in the right place and such. This is the domain where I am really good at, and I consider this as fun, too.

Python is useless here. C or C++ are the choice, mixed with a limited amount of assembler. Assembler will be used for the startup code, for some exception handlers and really time critical sections.

C++ is a mixed bag here. I do hate object orientated programming (except for graphic user interfaces), and thus also C++. I hate the compiler obfuscating stuff; I want to more or less see through the source text right to the resulting machine language.

But to be objective, C++ is usable. However, you have to restrict yourself basically to C plus classes. Something like C+ (sic). You could do that in C, too, with structs containing data and function pointers. I have done this, and it works well, but you loose public/private.

You cannot use anything involving dynamic memory allocation because this is a total no-go for these systems. Easy enough with C, just avoid e.g. malloc and printf. Harder with C++ since you have to know what’s going on behind the scenes. The abstraction here is what I hate most about C++. But still, if you are good at C++, know the inner workings and avoid the costly things, it will be fine.

The employer issue here is that C++ sucks. You can get proficient C programmers. You can also get proficient C++ programmers. What you will struggle at is getting proficient C++ programmers who are still good when robbed of half of their language, and who know what parts are to be avoided. While they do exist, they are more expensive than regular proficient C programmers. Plus than you need only an average C programmer, but a C++ expert.

You still have to be able to read hardware schematics, understand basic hardware issues (e.g. debouncing inputs) and be familiar with basic usage of oscilloscopes. Holds also for the next section with the “small” systems.

Oh, and don’t count on shiny debuggers. I have been working on projects where the only debug feature was a free IO pin that you could toggle, either for attaching an LED or an oscilloscope. It can really be that low-level.

In any way, you have to get familiar with the instruction set of the target platform as to avoid C constructs that would translate into performance bumps. Like, avoid 8 bit things on ARM, but strive for them on small AVRs.

I think that reading these datasheets is exciting, and I always discover useful stuff. But well, I also consider reading compiler release notes or hardware errata notes as interesting.

I am not sure whether I may already post links, so take a Google search for the keywords ’embedded C interview 0x10 questions’. The first hit is your candidate. I was able to answer most of the questions correctly without preparation, just experience. You really need to know things like interrupts and volatile.

– “small” embedded systems.
You have something like 256 bytes (!!) of RAM. Forget about C and C++, you are in for assembler. If the project is to be produced in high numbers of units, it can make sense to save every cent of hardware cost. I have been doing such projects, too. It is not that hard because these little things have a limited instruction set and do not feature confusing instruction pipelines.

Hope that helps a bit? It may sound like “oh no, that’s tons of stuff?!”, but if you have a technical mind, you will get into that. What’s more, you will even enjoy it.

[ryuk_shinigamiParticipant 95]

@rysh, @sidecar, @atton, @Darth Peter, thanks a lot for your advice, fellas..!!
@rysh, I will be leaving my current telecom testing work, soon enough and get into embedded testing(They use pyserial, a python package for testing serial ports and other automation stuff, involving python) and from there work my way up, to be a developer.

Get familiar with stuff like dead locks, race conditions, task synchronisation and the like. It’s really fun here.

That, I agree with. I got a PDF of Operating systems by william Stallings and all that stuff and more(concurrency, process scheduling,multi threading to name a few topics) are covered in it. It is fascinating, no doubt.

One more ques, How well do I need to know algorithms for programming in embedded systems?
If I will be working on application side, then basic algorithms(sorting, searching) will be needed, I guess..

But how much of algorithms knowledge will be needed on system programming side?

Thanks A lot again..!!

Some people call it fate. I call it, "Chaos Theory" - Sam Fisher

[RyshParticipant 134]

ryuk_shinigami wrote:

I will be leaving my current telecom testing work, soon enough and get into embedded testing

Oh yeah, also interesting. Testing is often totally underestimated. You need kind of a destructive mindset, always asking “what can I do to the system to make it fail”. Developers want to prove their system works, testers want to prove it doesn’t.

Sometimes, developers look down on testers. It helps to establish the paradigm “your tester is your first customer”. That gives you all the power you need because while being critisised by a tester is bad, being dissed by customers is worse. I’ve been in testing, too, and I had heated discussions with the developers and designers, but reminding them that I tried to use their things like their customers would do gave me the power to change their minds. Never let yourself be reduced to the “testing slave”.

Of course, I filed as many problem reports as possible to give the employer a rationale to pay me.

That, I agree with. I got a PDF of Operating systems by william Stallings and all that stuff and more(concurrency, process scheduling,multi threading to name a few topics) are covered in it. It is fascinating, no doubt.

If you can, also get some qualification courses. The way to present it to your employer is that you could figure out things yourself, but your productivity will raise much faster with proper qualification training. Plus that the certifications of these trainings are a nice point if you apply elsewhere.

One more ques, How well do I need to know algorithms for programming in embedded systems?

Depends on your application. Basically, the most important knowledge is not how to implement e.g. a quicksort. You can check it out on the web anyway. The important thing is that you know when to select what algorithm.

E.g. quicksort sucks because it is recursive, which is a no-go in many embedded applications. MISRA and stuff, limited stack and such. Bubble sort sucks always. Heapsort is good if you need a reasonably fast, reliable algorithm with quite constant execution time. Shellsort is good if your execution time is fine to vary, but you need raw performance. Selection sort is good if you need only e.g. the two top elements of a long data list.

But how much of algorithms knowledge will be needed on system programming side?

Quite limited. The really important things are somewhat different. In the waterfall development model, the cost to fix an error multiplies by ten in every stage. So you need to find errors as early as possible, and they can well be already in the spec. The question here is, what does the customer really need? As opposed to what he demands.

Normal operation is quite straight-forward. But you can’t reboot an embedded system because it usually has no user interface. It must run in autonomous mode for months, or years. Your poor little device has to deal with all the evilness of the world without any support. Broken remote connections, cabling damage, intermittent power.

[Author]

Posts