- Forum
- General C++ Programming
- C++ Embedded Programming
C++ Embedded Programming
My purpose is to learn C++ embedded programming practically. What tools do I need please?
What resource which uses modern C++ do you suggest for starting learning embedded?
Do I need a special tool as well, to deploy the programs on it? Something like a virtual device so that I can see my embedded code running result.
My experience in C++ is fine enough but now I'm very obsessed to learn embedded too. Where and how should I start?
What resource which uses modern C++ do you suggest for starting learning embedded?
Do I need a special tool as well, to deploy the programs on it? Something like a virtual device so that I can see my embedded code running result.
My experience in C++ is fine enough but now I'm very obsessed to learn embedded too. Where and how should I start?
You should start by defining a scope. "Embedded" is far too broad. What device do you want to program?
Please everybody stop replying to this troll.
http://cplusplus.com/forum/general/275678/#msg1189660
http://cplusplus.com/forum/general/275678/#msg1189660
I'm not very sure which is now more popular and will have a shinning future as well. But just to express the terms in my mind, I can say, probably: Industrial, Automotive and Medical scopes. What's your suggestion scope?
closed account (z05DSL3A)
I think when when helios is talking about scope and "Embedded" being far too broad, he is trying to get to what your idea/view of what "Embedded" is.
https://en.wikipedia.org/wiki/Embedded_system
Are you wanting to do embedded systems as a job or just as a hobbyist. Conforming to relevant standards early on is easier than try to unlearn bad habits obtained by tinkering but if tinkering is all your interested in...
Edit:
Are you going to be learning electronicts/mechatronics or are just looking at using COTS hardware?
https://en.wikipedia.org/wiki/Embedded_system
Are you wanting to do embedded systems as a job or just as a hobbyist. Conforming to relevant standards early on is easier than try to unlearn bad habits obtained by tinkering but if tinkering is all your interested in...
Edit:
Are you going to be learning electronicts/mechatronics or are just looking at using COTS hardware?
Last edited on
My idea about embedded is resembling what it is in reality and we see it on a regular basis in life. I've not done it yet but am interested in getting my feet wet. I now need something basic but my favorites as I said are automotive, industry, and so on.
Found a good YouTube series in C but not sure how much I can take advantages of it for C++. In addition it introduced a free but limited version of a simulator for both C and C++ embedded programming. I think Arm Compiler 6 (from 2105) will support modern cpp fully. That virtual device seconds that too, I suppose.
As well as, I found a seemingly great book on microcontroller programming in C++
Looking forward to hearing from you if you have remarks.
Found a good YouTube series in C but not sure how much I can take advantages of it for C++. In addition it introduced a free but limited version of a simulator for both C and C++ embedded programming. I think Arm Compiler 6 (from 2105) will support modern cpp fully. That virtual device seconds that too, I suppose.
As well as, I found a seemingly great book on microcontroller programming in C++
Looking forward to hearing from you if you have remarks.
Let me have a question on Linux. When I see a C++ job vacancy post saying "good knowledge of Linux" as one of the items of the requirement list, does it mean practical experience with a flavor of Linux when using embedded programming on it or can I achieve that profession just by mastering a flavor of Linux without necessarily getting engaged in embedded programming?
statements like that need you to take it in context. If the job is about coding in c++, they probably expect you to know:
-basic shell commands like cp, cd, mv, grep, awk, ... etc
- ability to write at least simple shell scripts
- knowledge of make and g++
- knowledge of one or two of the c++ IDES for unix
- how to use unix remotely eg putty, winscp, type tools from windows
embedded systems may not have a GUI; most do NOT for small devices running unix. They have a bare bones OS installed with just enough stuff to launch the program and interact with the user for setup, debugging, and general system admin tasks. Because of this, you need to be able to use those systems cold with nothing but a command line, doing basic sysadmin tasks if needed (install software, make a folder, copy files, whatever).
you have to understand that embedded machines vary in power from 'as good as your desktop nearly' all the way down to having kilobytes of memory and 10s of megahertz processors. Its everything from an alarm clock to a full on computer, in other words. The smaller (capability) the system, the more that is expected from the coder across the board in dealing with the darn thing.
I would say that basic linux is basic linux. Some things you learn may not be available on these systems, but the standard stuff is close enough across all flavors. Also, learn how to access and read both the electronic built in manuals and the spew from programs when you ask them for help.
embedded work is often more than code. Some systems you have to build to some extent, or at least solder wires, arrange jumpers, read voltages, etc. Its somewhere between computer hardware / computer engineering and computer programming, closer to programming but you will get your hands dirty.
-basic shell commands like cp, cd, mv, grep, awk, ... etc
- ability to write at least simple shell scripts
- knowledge of make and g++
- knowledge of one or two of the c++ IDES for unix
- how to use unix remotely eg putty, winscp, type tools from windows
embedded systems may not have a GUI; most do NOT for small devices running unix. They have a bare bones OS installed with just enough stuff to launch the program and interact with the user for setup, debugging, and general system admin tasks. Because of this, you need to be able to use those systems cold with nothing but a command line, doing basic sysadmin tasks if needed (install software, make a folder, copy files, whatever).
you have to understand that embedded machines vary in power from 'as good as your desktop nearly' all the way down to having kilobytes of memory and 10s of megahertz processors. Its everything from an alarm clock to a full on computer, in other words. The smaller (capability) the system, the more that is expected from the coder across the board in dealing with the darn thing.
I would say that basic linux is basic linux. Some things you learn may not be available on these systems, but the standard stuff is close enough across all flavors. Also, learn how to access and read both the electronic built in manuals and the spew from programs when you ask them for help.
embedded work is often more than code. Some systems you have to build to some extent, or at least solder wires, arrange jumpers, read voltages, etc. Its somewhere between computer hardware / computer engineering and computer programming, closer to programming but you will get your hands dirty.
Last edited on
I know that Unix is glorious and may be the basis for any operating system, but throughout the times I've sought a C++ job, when there's been a talk about operating systems, it almost always has been talking about Linux (and not Unix).
What resource (book, tut, YouTube series) do you recommend to master the (5) items you mentioned at the commencement of your post above, please?
What resource (book, tut, YouTube series) do you recommend to master the (5) items you mentioned at the commencement of your post above, please?
Unix, linux, whatever :) Its all the same to me. The bulk of my time was spent on Irix, which is dead now most likely. Still the same old same old.
Just install a linux on an old pc you have somewhere and play with it. Try to make it do crap, then when you can't, look up online how to do it.
star simple... make a folder, copy files into it, learn how to change the owner/use of a file, list the files in a folder, compile a C++ program, and again with more than one file, and finally with make using libraries. Install some software that requires you to install other stuff to get it working. Connect to it from windows and move files back and forth. Take away the keyboard, mouse, monitor on the box and use only remote into it to modify files, compile programs, do sysadmin things. If you don't have a spare PC, install cygwin and do as much as you can using that instead.
how to do each one of those can be found over and over online.
If you want a book, you can find them, but I have no idea what is best these days. And, again, the bulk of this stuff can all be learned using the 'man' pages, look up how to use those right away. The biggest issue for me really is that there are so MANY command line utilities built into the OS & their names almost never make any sense in terms of remembering what it does, eg awk .. what does that do again, its a type of penguin I think? The names... are horribad.
https://www.guru99.com/linux-commands-cheat-sheet.html //get started
https://www.linuxtrainingacademy.com/linux-commands-cheat-sheet/
a slightly longer list:
https://en.wikipedia.org/wiki/List_of_GNU_Core_Utilities_commands
a larger list once you get your feet wet. Almost all the commands have a link to how to use them here, this is a GOOD link.
https://ss64.com/bash/
Just install a linux on an old pc you have somewhere and play with it. Try to make it do crap, then when you can't, look up online how to do it.
star simple... make a folder, copy files into it, learn how to change the owner/use of a file, list the files in a folder, compile a C++ program, and again with more than one file, and finally with make using libraries. Install some software that requires you to install other stuff to get it working. Connect to it from windows and move files back and forth. Take away the keyboard, mouse, monitor on the box and use only remote into it to modify files, compile programs, do sysadmin things. If you don't have a spare PC, install cygwin and do as much as you can using that instead.
how to do each one of those can be found over and over online.
If you want a book, you can find them, but I have no idea what is best these days. And, again, the bulk of this stuff can all be learned using the 'man' pages, look up how to use those right away. The biggest issue for me really is that there are so MANY command line utilities built into the OS & their names almost never make any sense in terms of remembering what it does, eg awk .. what does that do again, its a type of penguin I think? The names... are horribad.
https://www.guru99.com/linux-commands-cheat-sheet.html //get started
https://www.linuxtrainingacademy.com/linux-commands-cheat-sheet/
a slightly longer list:
https://en.wikipedia.org/wiki/List_of_GNU_Core_Utilities_commands
a larger list once you get your feet wet. Almost all the commands have a link to how to use them here, this is a GOOD link.
https://ss64.com/bash/
Last edited on
@jonnin
awk gets it name from the initials of those created it, Kernighan was one of them.
It is a pattern matching action language /scripting tool.
awk gets it name from the initials of those created it, Kernighan was one of them.
It is a pattern matching action language /scripting tool.
I know what it is, but forgot where it got the awful name. Most of the rest are like examples of how not to name C++ variables. Windows is not any better here, mind you. I can pick on it too... it just has less to remember, which is not exactly anything to be proud of.
Last edited on
> Most of the rest are like examples of how not to name C++ variables.
Unix names were pretty good in the historical context in which they were written. They were created at a time there was no distinction between 'programmers' and 'users'; people who wrote the utilities were also the people who used them. Saving keystrokes those on slow, noisy teletypes was also an important consideration.
Unix names were pretty good in the historical context in which they were written. They were created at a time there was no distinction between 'programmers' and 'users'; people who wrote the utilities were also the people who used them. Saving keystrokes those on slow, noisy teletypes was also an important consideration.
And I get that, and in their shoes would have done the same. Does not make it any less cryptic, though.
Furry, first place I worked one of the guys wanted everything in Hungarian. I flat out refused to do it. He finally came around. I can see how it was useful if you coded in VI or something.
Furry, first place I worked one of the guys wanted everything in Hungarian. I flat out refused to do it. He finally came around. I can see how it was useful if you coded in VI or something.
Last edited on
jonnin, the biggest problem with Hungarian Notation IMO is there are actually two types. Systems Hungarian and Apps Hungarian. (You probably already know this.)
The style of notation proposed by Charles Simonyi is not the notation most people are familiar or use.
https://en.wikipedia.org/wiki/Hungarian_notation#Systems_Hungarian_vs._Apps_Hungarian
Even MS has gotten away from using Hungarian notation, which is not a bad thing.
Variable naming will always be contentious. What makes to one person will be as transparent as mud to another.
MS-DOS system commands can be similarly terse, the same as *nix system commands.
https://leanpub.com/bookstore?category=embedded_systems&language=eng&type=book
The style of notation proposed by Charles Simonyi is not the notation most people are familiar or use.
https://en.wikipedia.org/wiki/Hungarian_notation#Systems_Hungarian_vs._Apps_Hungarian
Even MS has gotten away from using Hungarian notation, which is not a bad thing.
Variable naming will always be contentious. What makes to one person will be as transparent as mud to another.
MS-DOS system commands can be similarly terse, the same as *nix system commands.
| frek wrote: |
|---|
| I'm very obsessed to learn embedded |
https://leanpub.com/bookstore?category=embedded_systems&language=eng&type=book
The reason for some of the "terse" names was that early compilers/linkers were severely limited in the number of characters allowed for variable and function names. For example some early basics only recognized the first two characters as unique variable names, very early Fortran was limited to about 6 characters, even early C was severely limited.
And early Operating systems also had limits on the length of file names (ie: DOS had a limit of 8 characters).
Thankfully today the limitations are much larger, but limits still exist, making meaningful variable and function names possible.
And early Operating systems also had limits on the length of file names (ie: DOS had a limit of 8 characters).
Thankfully today the limitations are much larger, but limits still exist, making meaningful variable and function names possible.
IIRC DOS had 8.3 file names. Base name 8 characters and 3 characters for an extension.
Hurray, FAT!
Hurray, FAT!
Topic archived. No new replies allowed.