Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
Hi i'm wanting to program microcontrollers but i don't really know how to do it and what i need to do it. I have no idea where to look in the slightest for the information i need. I've been coding with python for around 11 months now and i know how to use the language well. I've used c++ in the past and i know quite a large amount of that language too.
When programming microcontrollers can the microcontroller be programmed with any coding language or do microcontrollers only allow certain languages to be used with it?
I have endless amount of questions but i'm not going to ask them all, if someone could please point me in the right direction i would be very grateful. Thanks.
The problem is with the word "programmed". Microprocessors (you mean CPUs, right?) typically execute machine codes which are specific to their hardware platform. Machine codes are just bytes read from the memory and interpreted in a special way. This is the lowest possible level at which processors may be programmed (and some day the were programmed that way).
Now since programming processors this way is very inconvenient, the so-called "assembly languages" have been invented. Basically, they just define symbolic representations for machine codes and sets of rules of their interpretation. Then a special program, called translator, takes a set of text files containing the definition of a program written in an assembly language and produces something which contains machine codes and might be executed by the target processor. (The definition of this "something" is hard, and let's not digress.)
Now there's another level higher up — languages like C (and, to a lesser extent, C++) which try to abstract away the details of a particular hardware platform and allow to concentrate on algorithms and data formats rather than dealing with a particular processor. Obviously, this moves the knowledge of a particular H/W platform to the compiler — a program which takes the text of your program written in a high-level language and produces something runnable by a target processor.
Now there's another level higher up which includes languages which almost completely abstract you away from any particularities of a H/W platform. JavaScript which runs in your browser when you're reading Stack Overflow is a good example — the programs in it are still executed by the processor of the device running your browser but there are many complicated layers of code between those JS scripts and the processor.
By now you should see that there's no definitive answer to your question. If you would like to dabble with low-level code for the CPU on your bedroom PC then google for "x86 assembler", "intel assembler" etc. This is a good start. If you want to program some other processor, the search query to use would be similar. If, instead, you want to program some specialized processor like AVR then start with that product manuals as they usually come with specialized tools.
if you are interested in getting handy with basic practical like you said "like to do something basic to start like making an LED flash etc."
choose basic micro controller, say from 8051 family we will take 89c51(NXP/Atmel depend on availability). Go through the user manual first, it will give you brief idea(overall architecture) about it.
regarding programming you will find basic code for LED flash in manual only(likely).
if you are using NXP micro-controller then Flashmagic software is freely available on internet you can download it.
In you IDE(like keil) do not forget to create ".hex " file after you are done with your coding.
now open Flashmagic and load your .hex file in it and burn your micro controller for particular code you wrote.
Good Luck!!
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I recently asked the question if I could limit bandwidth via a C# WinForms applications much like NetLimiter and NetBalancer. I was told that there's two ways to do this. Either via proper QoS or writing something along the lines of an "NDIS Network Filter Driver". Using QoS isn't the way I want to take. So I've looked up some of the stuff required to write drivers and found some interesting points. Points such as a good understanding of C/C++, because the executed code being very prone to BSODs since it could be run in something called "Kernel mode". I also found a GitHub "dump" which looks interesting and tempts me to investigate and look around in.
As you can see I'm no where near advanced enough to delve into this on a professional level. Ignoring that, what would be a good start to start my adventures into writing drivers to monitor - and further down the line manipulate the network to introduce throttling.
Any help, guides or information that might be of help is always appreciated.
PS: I am unsure as to whether this is (as afore mentioned in a comment to my previous question) too broad a question to be answered on Stack Overflow. If so, where would I go to ask this?
Indeed, this would be too broad. Driver writing is a complicated thing which requires a good understanding of how a computer and the OS works. Also, C# (and .NET itself) indeed isn't available in Kernel Mode, so C/C++ is the preferred way. Although theoretically any unmanaged language (like Pascal) could do, I haven't heard of anyone writing drivers in them. Microsoft's own developer resources are also written with C/C++ in mind.
Which brings us to the question of why you want to do it.
If you need it for work and there's a deadline - forget it. Get someone else who already knows this stuff. Or there might be a library out there that fills the need. Any of these options will be cheaper than your time spent learning all this stuff.
If it's for your own curiosity however - go for it! I'd advise by starting to learn C first. Not C++, that's more complicated and for drivers it will be easier with C anyway. But you can pick up C++ later too, it's good stuff. C++ is mostly compatible with C, so you can start with C and then continue with C++.
In parallel, get a good book about OS design. Not because you want to design an OS, but to understand the basic concepts that it is built upon. You should get a good understanding of things such as Kernel Mode/User Mode, virtual memory, interrupts, process scheduling, etc.
Learning a bit of assembly might be useful too (albeit not required).
Finally, when you feel like you've got a good grasp of the above, head over to MSDN and start reading about driver development. There will be long articles and example programs to get you started. Tweak them and play around in a virtual machine until you get what you need.
And also... read this.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
How low and high level programing languges are related with each other? As an example, assembler language and C++ work at different levels but, what kind of logic exist between those levels? Let´s suposse that I write a Hello World! program in C++, I compile and run it. What thing do I need to care about in order to make more efficient my code on the assembler level??
You go to the hardware store and you can find beams and boards and nails and screws and bricks and mortar and all kinds of basic building materials. Combinations of those materials can build a dog house, a people house, an office building, a sidewalk, a road, a mailbox, etc.
C/C++ is the house, the mailbox, the storage shed. The bricks and boards and nails are the machine language. The word brick and nail are the assembly language that describe and have a one to one relationship with a single instances of the material.
When you take a line of high level code
a = b + c;
you cannot run that in that form, not really even interpreted, because the interpreter itself is a program made up of smaller pieces. A compiler be it a human doing it by hand or a program evolved from other programs, is used to interpret that line of high level code, allocate registers or memory for each of the variables and pick from the available instructions in the instruction set and order of those instructions to create a program that the processor can understand, that performs the same functional task. give this problem to 100 people and you may get anywhere from 1 to 100 different solutions, there is always more than one way to have a functional equivalent to a high level program in the instruction set that the processor understands.
Assembly language is ideally just a human readable and writable form of the instruction set for that processor, so that we dont have to stare at bits and bytes of machine code. an assembler is a much simpler program that converts the assembly language mnemonics into machine code, ideally one asm instruction to one machine instruction, but the assembler may add other features to make the task of hand programming (or even compiler generated asm) easier on the human.
the "logic" between these levels is other programs called compilers, assemblers and linkers that "convert" the high level program into a functional equivalent at the low level. The processor can only actually execute the low level. The high level source code is just a blob of data no different than a book, web page, audio file, video, etc to the processor, it cannot understand it without a program in its native language that can parse that data.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
My background is like this: embedded/C, then C++, then higher level OO languages (Java, Scala, Ruby, Groovy, etc.), and now I am doing a small project involving MSP430 microcontroller. Meanwhile, inspired by that, I am contemplating a number of potential pet embedded system projects (meshes and/or RTLS look appealing). So my question is focused primarily on MSP430 for now, though, as an aside, I'd love to have a broader picture, too, involving other microcontrollers.
I was a bit surprised finding out that, after so many years, I might need to go back to C, with its macros, naming conventions, and all. My brain used to be wired for C, but that was many, many years ago.
So what alternatives are available?
C++ feels much more agreeable to me, and, fortunately, seems doable: http://stonepile.fi/object-oriented-approach-to-embedded-programming-with-c/
So if I am to program C++, I just need to inline a lot, avoid virtual functions when possible, and I should be good, right? (at least, memory-wise; they did not benchmark for performance at the above link).
However, if it's so easy, why do people program C? I must be missing something.
The above link also seems to provide a wrapper library for pico]OS. Has anyone used picoOS on MSP430, how reliable is it, and how much resources does it take?
What are the pros and cons of Energia for a simple MS430 project? I tried it, it seems very intuitive and self-documenting, but does it result in as neat a code under the hood? For instance, does Energia initialize unused GPIO to the off state to save energy? Does it initialize unused interrupts? What is the overhead in terms of memory and speed? Etc.
Edit: As a long-time Eclipse person, I'd love to use CCS. I saw that Energia sketches can be imported to CCS. Does it mean that CCS have full support for Energia and can be used as an Energia IDE?
Has anyone used Java Grinder http://hackaday.com/2014/02/10/java-grinder-spits-out-dspic-and-msp430-assembly-code/ ? It seems appealing, but because it spits out an Assembly and not C/C++ code, it's a bit scary to commit to it: what if I am locked into it and it's not ready for the prime time? If it generated C code, I could have easily dropped it if it did not work.
I mentioned Java and my question was deleted, as it's self-evident that other than grinder-like syntactic sugar (not that I mind syntactic sugar!), Java can't run on MSP430. I guess I'll ask another question re WHERE Java can run. This has already grown too long.
What other languages/environments are out there, that fill the niche between low- and hig-level languages?
you seem to have several questions here so I shall go through in the order you numbered them.
Most micros will indeed run C++ (assuming the manufacturer or an open source project provides a compiler back-end), however you have to be wary of a number of drawbacks. C++ Is less deterministic, as in, it provides a significantly higher level of abstraction, which one likely does not want an a resource constrained embedded system, and by and large it is not needed either as embedded systems are rarely powerful enough to usefully run the enormously complex algorithms that warrant a high level language like C++. It is also likely to cause a wide range of hard to track bugs, given the difficulty of debugging code from an embedded system having bugs which are simple and easy to trace are very much nicer. However very importantly, the C++ standard libraries are enormous, they will use excessive ram and very likely waste much of your limited memory space. Thus, even if you do use C++, you wont be able to use any of the techniques that make it powerful.
Simply, I have not used it, however like any RTOS, it is useful if you want a slightly higher level interface, however for a micro the tiny size of the MSP430 it seems overkill, I cannot imagine you doing anything on there that warrants an ROTS, if you need multitasking it would be better to provide simple cooperative tasking yourself.
Unfortunately I have not used that platform either, however given it is based on wiring, my guess it that it does not provide high levels of hardware specific optimization, if you want that I recommend using it for the bulk of your code but make calls into lower level libraries when needed. Beyond that however, it does provide a lovely, self documenting interface, I strongly encourage you to try it. It will also make your code many times easier port if you switch to another micro later (many systems from many companies provide wiring bindings).
You really answer this yourself here, it could be very powerful but is still very immature, I would avoid it purely because of this lock-in until it becomes more mature, then it is worth re-assessing.
Java works nicely on more powerful ARM chips, that is the only place I have seen it in wide use, and implemented fairly efficiently in a micro (ARM provides hardware assistance specifically for Java). Other than this Java is a poor fit for the micro world, at one point it appeared it might go somewhere but this was largely unrealized, for now C likes are the way to go for smaller micros.
Unfortunately there is not really a huge amount of choice other than C. My best recommendation is using higher level libs like wiring. That gives you slightly nicer interfaces without killing efficiency, otherwise there is little point in using a tiny micro if you need high levels of abstraction.
In summary, C does a fairly good job here, I do not think there has been any motivation or effort to make a good replacement. And frankly I largely feel this way too, C never became a bad language, it is still well suited for small systems for the same reasons as it was before. It provides power, efficiency and predictability.
I hope this helps somewhat, if you have any queries please comment me and I will see what I can do to help.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
So I was fiddling around with the Raspberry Pi, and it just kinda came to me that "Where do all these drivers come from". Like specifically for the SNES controllers im using on them....how on earth did someone figure out how to write that.
I know C decently, and C++...ok. But this has always been something I kinda thought about. It's cool because it's low level enough to understand possibly whats going on hardware wise....but also great to learn about the OS.
Where do I start with something like this? Im guessing doing this for windows would be WAYYYY different.
Thanks
It seems to me that there are really two questions here that don't really have a lot to do with each other.
The first is "what does Linux require of device drivers?" That's almost always going to be answered by reading the documentation. Although the device driver documentation may (arguably) be a little less thorough, complete, easy to read, etc., than docs for writing normal programs, it's still pretty decent. Probably the biggest difference from normal code is debugging, which is most often done via simply printing things out with printk.
The other question is something like: "How do you figure out what protocol is (or "protocols are") used by specific hardware like the SNES controller. When you're developing for something like a normal hard drive or keyboard, you can pretty much just follow the documentation. You may (often do, at least in my experience) find that you need to compensate for some bugs in the hardware, but beyond that it's (again) fairly normal programming. The biggest challenge in quite a few of these cases is simply deciding how you want to present the particular device in question to the rest of the system. For something like a hard drive that's generally pretty easy, but for something like a human interface device, it can be a little more challenging (e.g., do you want to present it as itself, or do you want to emulate some existing type of device like a keyboard or mouse?)
For hardware that's not really documented, things can get a little more difficult. The really general purpose tool for looking at logic signals is a logic analyzer. If you have something that uses a well-known hardware interface (e.g., PS/2 keyboard/mouse, USB, SATA) you can find more specialized tools (and/or add-ons for a logic analyzer) that make life quite a bit easier. Something like an NES or SNES controller almost certainly uses a proprietary interface, so for these you probably end up using a logic analyzer. Fortunately, they're also likely to be a pretty narrow, slow interface, so the logic analyzer doesn't need to be terribly fast or support a huge number of channels.
With the logic analyzer you can see all the individual signals, but for a proprietary interface, it's pretty much up to you to figure out which signals do what. In a typical case, you'll have at least a few that are fairly obvious: power, ground, quite possibly a clock, and so on. In quite a few cases, you quickly find that even if it's not publicly documented, it may follow some well-known protocol like I2C, SPI, etc.
Linux Device Drivers is the book you want.
While you wait for the book to arrive, I can tell you that knowing how the hardware works and how the Linux kernel works is only half the battle. You also need to know the hardware level interface for your specific device. Hopefully you can find documentation for this, but that can be difficult.
See this related question for an example of how someone came up with a driver for Linux by watching the commands that came out of the Windows driver:
How are low level device drivers written for Linux?
For Windows, the process is not actually terribly different. All the concepts are still the same, since it is the same hardware. The differences are in the details, of course.
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 am looking to start from scratch to learn to program embedded systems. After some time looking around I found myself a bit confused.
I can program both C and C++ but I just don't know where to start with embedded programming, should I buy some kind of device to practice on, use a microprocessor emulator (if so, which one?) - stuff like that, any advice or resource on where to start is very welcome.
In my opinion, skip Arduino. I've always seen it as kind of a dumbed down system for non-programmers. Go for something that lets you apply your C knowledge to getting as low level as possible, at first. You want to understand how interrupt vectors work, how your limited RAM limits your stack, how to debug.
Check out Freescale's 8-bit and 16-bit Microcontrollers, especially the HCS08 or HCS12. There are some $100-200 and some sub-$100 development systems with built in debug interface (Background Debug Mode). These are also higher performance and memory than Arduino. The CodeWarrior software is free (code size limitations, but in most cases the limitation number is greater than the amount of flash on these devices), and fully functional. I don't know if you can set code debug breakpoints with Arduino, but you can with these. There is another benefit to CodeWarrior -- while you do at first want to delve into datasheets to understand how memory-mapped registers for the various modules operate (eg, how a flag should be cleared, how to set a mode, whatever), CodeWarrior comes with Processor Expert which will generate functions for you for specific HCSxx family derivatives and their specific modules. Since most of these products reuse the logic between derivatives, with some minor differences, it makes sense to reuse code. Processor Expert has come a long way since its beginning 10 or so years ago. In the long run it is a huge savings to development time, as these functions take care of writing the very low level actions (eg, configure a PWM timer output pin for a xx/yy duty cycle with one C function call).
Then you can use some of the OS's that will run on these, or you can move up to ARM or ePPC. I know of at least one HCS12 demo board that comes with Linux and a webserver, which you could always wipe out for your first development, and then put it back when you're ready. Freescale is also very good with providing tutorials, application notes, and documentation, except that their site is sometimes hard to navigate. I suppose that's just a symptom of a large ecosystem. Good luck!
There are several embedded platforms out there that are popular with hobbyists and very easy to use. The Arduino is probably the most popular. Boards are cheap ($20-30) and easy to use, and there's plenty of good software. The main web site for the Arduino platform is http://arduino.cc. You'll find plenty of links there to other resources that'll help you get started.
You may want to check out SparkFun, which is primarily a hobbyist-level supplier of electronics parts (including Arduino and other useful boards) and tools. They've got a lot of great content on their web site to help you get started with both the hardware and software.
why dont you start with something like that:
http://www.bytecraft.com/downloads/firststeps.pdf
this should cover a lot of the ground you are looking for.
or a lot can be found here: http://www.eetimes.com/electrical-engineers/education-training
have fun with your first steps =)
One could divide embedded systems into two classes:
Those that run a full OS. If there is a documented way to get the OS and boot it up, then these aren't really handled any different than desktops, except you will need to build or download a cross-compiler. For things like phones, of course, elaborate development environments with debuggers are provided by the environment's sponsor.
Those that run a program on what's called "bare metal". These will have little more than your program and the language runtime loaded. (Some of these are really simple and run either a simple interpreter or assembly language. These have the advantage of not needed complex programming just to set up the integrated peripherals.)
You may not need an emulator or other hardware debugging setup, in fact, you may not even need hardware to get started. If possible, try to do initial development in a virtual machine.
As always, you get what you pay for. In a commercial project lots of environment is available but these are presumably not used much for robot projects and the like.
There are lots of platforms that come with reasonable amounts of support. The latest rage (due to its remarkable US$35 price point) is the Raspberry Pi, however, it is not immediately available at this time.
You have tons of options! I guess you'll start with an emulator (it doesn't matter what type of embedded OS you'll use, probably you won't use a x86 CPU). If you'll work with a X86 CPU you don't need any emulator but you may need a Virtual Machine.
You tagged your question with "arm" so I guess you want to use an ARM processor (then you'll need an emulator). Start to look here, you'll find tutorials and resources to begin with embedded programming.
I would suggest trying out some of TI's EZ430 series of development tools. Some of the tools can be purchased for as little as $20 and have basic functionality, as well as ways to expand them out. You can easily buy two eZ430-F2013 and have them talk to each other or to another computer.
TI comes with Code Composer Studio for their MSP430s which is free and full featured (it's based on Eclipse) so the programming environment is very user friendly. TI also provides a large number of code samples which cover most of the system's functionality.
With the MSP430, you will be programming on "bare metal" code as its said, so you're not just going to be programming C, you're going to be toggling outputs and bit-banging. But it looks like you're interested in learning it down at this level, so this is a great place to start.
On the other hand, if you want an embedded OS (such as Linux) check out the gumstix website.
Because your question provides little information as to application type, performance requirements, and budget etc., no answer will be particularity well focussed.
However given that I would suggest that you pick an ARM architecture device, simply for the reason that this covers devices from a few dollars with performance in the 10's of MIPS, and small on-chip memories to application processors on boards costing a few hundred dollars capable of running Linux, WinCE or Android for example.
Like it or not ARM is ubiquitous in the embedded systems world; everything else is niche in terms of design-in and market share. A Cortex-M3 based device on a simple development/evaluation board is a good place to start. You will be frustrated however if you do not factor in the cost of tools and debug hardware.