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.
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 6 years ago.
Improve this question
I'm sorry if this is long. I feel I need to be very thorough as to where I am actually at.
Right so first off I do have experience with JavaScript.
Which is not the same thing, But it sure looks familiar to me.
I want to make music with C.
I got his big book called "The audio programming book".
It was like $60.
It dose have an introduction to C in it. It all makes good sense to me so far.
nothing really new.
So here's my problem...
And its very simple. So simple in-fact that it doesn't seem to be covered in the book.
I don't understand the relationship between my program and the speakers.
my computer's audio device.
I thought to myself "Alright lets start with the very basics. Let's see if we can just make a noise."
And so...
I have something that will make a beep.
#include <stdio.h>
#include <stdlib.h>
int main()
{
printf("Hello world!\n");
printf("\a\n");
return 0;
}
So that's cute.
But that's seemingly all that function is capable of.
And honestly That would be rather confusing if... the thing that is meant for printing text to your screen... was also the thing you use to talk to your speakers....
I've been looking through the book. I've been looking online. I've been looking for hours.
And clearly searching in all the wrong places... because literally all I can find is more of how to make your computer beep...
where is the "send to speaker"??
where do I put in the frequency?
Heaven forbid the part were I tell the thing what device I would like to talk to.
Dose C simply not have any built-in functionality for sending signals to the speakers?
Do I need a Library? Do need C++? What am I missing.
I don't know anything about desktop applications.
All my experiences is with Internet technologies.
Dose C simply not have any built-in functionality for sending signals to the speakers?
Indeed, C does not have any built-in functionality for sending signals to the speakers.
Do I need a Library?
No, but I would highly recommend to use one.
Do need C++?
No. You don't need C++ for doing anything in C. Besides, C++ also has no built-in audio functionality.
where is the "send to speaker"?? where do I put in the frequency? Heaven forbid the part were I tell the thing what device I would like to talk to.
All these and other things related to audio are platform (operating system) specific. In order to interact with a sound card (which is the device that sends signals to the speakers), you must use platform specific API. Some operating systems may have multiple different APIs for audio. You can, as I already recommended, use a (cross-platform) library that abstracts the platform specific API.
You say you want to "make music with C". This seems to imply that you want to be able to feed data into the sound buffer in real-time through something like an ASIO driver, with low-lantency, and that you want to write your own audio synthesis. This is all quite complicated stuff, but you should start by getting some library/API that gives you that kind of access. Sadly, most of them do not tend to be free, but there probably are some free options, if you look around.
Since all of this depends so much on what library/API you use, I sadly cannot say anything more precise.
Another option is to study up and learn how to program VST-instruments (plug-ins for DAWs), which will probabably be even more useful for what it sounds like you're trying to do.
And no, you don't need C++, unless the library/API you want to use only supports C++, for some reason. That doesn't tend to be the case.
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
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!!
I've started learning embedded and its 2 main languages (c and c++). But I'm starting to realize that despite the simple learning requirements, embedded is a whole world in and of itself. And once you deal with real projects, you start to realize that you need to learn more "stuff" specific to the hardware used in the device you're working on. This is an issue that rarely came up with the software-only projects I currently work on.
Is it possible to fragment this field into sub-fields? I'm thinking that those with experience in the field may have noticed that some types of projects are different from other types, which has led them to maybe maybe come up with their own categories. For example, when you run into a project, you may think to yourself that it's "outside your field"? Does that happen to you? and if so, what would you call your sub-field or what other sub-fields have you encountered?
Here are a few sub-specialities I can think of:
Assembly Language Specialist
Yep. You need to know C and C++. But some people also specialize in assembly. These are the experts that are called up to port a RTOS to a new chip, or to squeeze every drop of performance from a highly constrained embedded system (usually to save $$ per unit).
This person probably is not needed that much these days... but.. yet still critical from time to time.
Device Driver Specialist
comfortable living between a real OS or RTOS and a piece of hardware. This person is usually comfortable with lab tools like o-scopes or logic analyzers, thinking in "hex", and understanding the critical nature of timing with HW. This person reads device data sheets for fun at night, and gets excited about creating the perfect porting driver for some new device.
DSP Specialist
Digital Signal Processing seems to be its own sub-specialty of embedded, although perhaps a software engineer may not know the exact algorithm details, and may only be implementing what a system or electrical engineer requires. However, understanding sampling rate theory, FFTs, and some foundational elements from "DSP" is handy and maybe required. And you still generally must be very aware of timing and your target hardware's restrictions ( sampling rate, noise, bits per sample, etc).
Control Theory Specialist
Perhaps the same issue as with DSP: a system or electrical engineer may provide the detailed specs. But, then again, familiarity with various motors, sensors, and other controllers handled by a microcontroller, would be great. Throw in a Bode plot, some Laplace transforms or two and some higher math skills... that couldn't hurt too much!
Networking Specialist
basically the same as the PC world "networking". Many embedded devices are adding networking connectivity features these days. TCP/IP sockets, http, etc good to know and understand how to use in a resource constrained device. Throw in USB and Bluetooth for good measure.
UI Specialist
more and more embedded devices include 2D graphics, and now more include 3D graphics thanks to the influence of iPhones, etc. Even though these are still "fat" systems by other embedded device standards, they are still limited. Just read a bit in the Android Development Guide, and you will realize that you still must consider responsiveness, performance, etc, even in a high end cell phone.
http://developer.android.com/guide/practices/design/performance.html
And then, of course, every industry is a specialization unto itself. Consumer Electronics, Military, Avionics, Robotics, Industrial Machines, Medical Devices, etc...
Have fun and good luck!
Yes, there certainly are several sub-fields. I don't think I can list them all from the top of my head, but the way I see it, there are at least 3 big sub-divisions, and from there, they are further sub-divided. There are micro-controllers, micro-processors and sand-boxed/VMs. For example, using a 16bit micro-controller in a drive-by-wire would be an example of the first, a set-top-box like TiVo would be and example of the second, and iPhones and Androids are the latter.
Micro-controllers are very limited, and usually can't even be programmed in C++. Most of them either has no OS running, or, the most expensive ones, have an RTOS. Set-top-boxes and any ARM/MIPS/SuperH4/Broadcom chips are much more like a PC, in that they have a linux distribution running in them and you can find most of the same facilities as a PC, and if you can't find one, cross-compiling to it is usually simple. The sand-boxed guys, are well, sand-boxed; so it is exactly what it sonds, usually the SDK isolates you from the hardware and you don't really get the 'full embedded experience'.
Sure, for example, there are many operating systems in use in the embedded world. Working with embedded Linux is very different than working with a bare micro controller.
"Learning embedded" sounds impossible to me. I do some work on headless linux computers controlling large machinery - which can be referred to as embedded (but it's not much different to programming any other computer, bar a few hardware interfaces). That's totally different to a phone, and totally different to an air conditioner or home automation system.
Control systems and mobile devices would be two categories of 'embedded' - but I'm sure there are plenty more.
I work on embedded linux on Mobile devices, and its whole lot different from a full flegded Ubuntu image where i write my code and cross compile it for the mobile device.
First of all a embedded system is stripped down to meet the bare requirements of the device, very much unlike the traditional desktop operating system where you can have as many functionalities/libraries etc.
The memory constraints also are a major part of a embedded system. Hence all the programs/applications have to be written inorder to fit into the architecture. This may not be much of a concern on a traditional system.
Basically my point is to emphasize that working on embedded cannot be summed up into a few lines as each have a different purpose.
However programming keeping in view the overall architecture may help you gain confidence if you can fit into a project or not.
PS: I may not be good in categorizing which is what the question expects, however this is my bit on embedded systems.
Lots of good answers already to this question. I think you need to decide what the word embedded software means to you and/or what you want it to mean. Maybe your definition isnt really embedded. My definition means no operating system. And that will probably upset many embedded software engineers, but the experienced ones like ones that have already answered will certainly understand our variations in definition and why. I think they would call me a microcontroller specialist, and that is certainly true, but I spend most of my time on full speed processors with gobs of memory and rom and I/O, networking, etc. I am the guy that brings the hardware up the first time, flushes out board and chip bugs, then hands it off to what most would call the embedded software engineers. I am an electrical engineer by training and software engineer by trade, so I straddle the line.
It is very possible, and not uncommon that you could remain in the C/C++ embedded world, never have to read a datasheet or schematic, all you would do is call api's that someone else has created. There is a large and increasingly larger market for that as what used to be (my definition of) true embedded, or rtos based embedded (which is often api calls and not the full experience) to this linux embedded thing that has exploded. There is nothing wrong with it, it is fairly close to the experience of developing code for a desktop, but you have to try just a little harder for reliable code since it may be flash/rom based and they may not want to have weekly/monthly updates to units in the field. Ideally never update, but that is also becoming more rare.
The rtos/embedded linux api based embedded is and can still be a different experience than what I call application programming. You may still want or need to read a datasheet or schematic, you may still need to know assembler for the target platform.
I like all of the answers thus far to this question, I guess we are struggling to understand what you are really asking or what you are really looking for in life, add to that what we enjoy about our choices and you get this mix of answers.
I see a few groups, there is certainly the good old true embedded microcontroller stuff, but even that is turning into libraries and apis instead of on the metal, look at the arduino community and stellaris and a bunch of others. I spend a lot of my time in board bring up and test, you have to know a fair amount about the whole system hardware, registers, schematic, etc. Have to know enough assembler both to boot the thing out of reset as well as debug things by staring at disassembly dumps and looking for signs of life in the I/O or on memory busses, etc. If lucky you will get to work on chip design as well and get to watch your instructions execute in simulation. The next group is bootloader/operating system. The hardware working well enough at this point, chip boots, memory appears to work, rom is there. This team writes the production boot code and gets the product from power up into the embedded system, rtos, linux, vxworks, bsd, whatever. this is a talent in and of itself, toolchain, root file system, etc. The next group is the masses, the software engineers that write the applications for that operating system, now some will be reading datasheets, schematics, etc, writing device drivers or apis for others to use, and the highest level may be someone that is all application level programming, the api and sdk calls, some of which may be company developed some may be purchased or other.
Bottom line: Absolutly, there are specialties within embedded. Are you going to know everything? NO, maybe 20 years ago, likely 40 years ago, not today the field is too big and wide. What is the best things you can do for yourself in this field? Learn assembler for a few different instruction sets. The popular ones, arm definitely, thumb version of arm, maybe mips or powerpc or others. If you lean toward microcontrollers, learn (arm, thumb,) avr, pic (blah), msp430, maybe 8051. Read some data sheets, microcontrollers can teach you this even if that is not the field you want, tons of sub $50 development/eval boards (sparkfun.com for example) that give data sheets, simple schematics, assembler, C, etc. If you are a software guy, learn to speak hardware guy, software and hardware folks do not speak the same language, if you can avoid picking sides and stay neutral and speak both languages you will help yourself, your career and whomever you work for and with. Despite any personal views you may have about endians or bit or byte numbering, you are likely to have to deal with some screwy things, and speak to customers/coworkers that can only deal with octal (yeah really) or only deal with the msbit of anything being zero. I recommend looking into verilog and maybe vhdl. At least in a readable sense, not necessarily create it from scratch. If you can already program and know C it is very readable. Depending on the job and the coworkers the verilog and the schematic may be your only documentation you use to write your software. If you cant do it they may replace you with someone who can (rather than get the hardware folks to document their stuff).