Any good place to learn about POST and how to design and code one? I am a C++ programmer and quite baffeled with the term.
Thanks
You might want to take a look at the code for coreboot, a free software (open source) BIOS project that runs on many different kinds of hardware.
You can checkout the OpenBIOS project.
They have information on numberous opensource bios/firmware implementations.
Being open source you can grab the code from svn or read it online for all of them.
BIOS? That's not too common in the embedded world, the one place where people still write POSTs. Typically, they happen before the OS itself starts, or alternatively, as the OS starts.
The goal is to figure out whether the device can run, run in degraded mode, or should signal malfunction. A typical sequence is test CPU and XIP flash, then memory, fixed hardware, and then optional hardware. You define a series of tests. A test has a start function and a check function. The start functions kicks off the test; the check polls to see if a result is already available. Tests have dependencies, and the test controller starts those tests for which the dependencies have passed (CPU and RAM being the special cases, if they're broken it's not feasible to have a nice test controller).
As you can infer from the CPU and RAM tests, you don't have the luxury of C++. You can't even assume you can use all of C. During the first part of the POST, you might not even have a stack (!)
Open source EFI BIOS, with documentation and specs (good way to learn):
https://www.tianocore.org/
Background In June of 2004 Intel
announced that it would release the
"Foundation Code" of its next
generation firmware technology - a
successor to the PC BIOS - under an
open source license later in the year.
The Foundation Code, developed by
Intel as part of a project code named
Tiano, is Intel's "preferred
implementation" of the Extensible
Firmware Interface (EFI)
Specification. The code to be released
includes the core of the Foundation
Code as well as a driver development
kit. To follow through with its
intentions to release the code as open
source, Intel partnered with
Collabnet, an industry leader in
providing tools and services to
support an open source initiative, to
create a community for this effort.
The result of this partnership is this
Open Source Website.
Since there are more projects that are
EFI-based working in parallel with the
Foundation Code, it was decided to
release the EFI Shell Application and
the EFI Self Certification Test (SCT)
project to the open source community.
POST (Power On Self Test) is part of the Bios, and writing a POST, but not other parts of the BIOS, seems like an odd task indeed.
The documentation section of the processor manufacturer's web site would be a good start for BIOS programming. I remember writing an 80186 BIOS and POST a long time ago, and I worked exclusively with the Intel specs.
And btw, you will be doing this in Assembler, not C++.
Related
Is there a Windows standard way to do things such as "start fan", "decrease speed" or the like, from C/C++?
I have a suspicion it might be ACPI, but I am a frail mortal and cannot read that kind of documentation.
Edit: e.g. Windows 7 lets you select in your power plan options such as "passive cooling" (only when things get hot?) vs. "active cooling" (keep the CPU proactively cool?). It seems the OS does have a way to control the fan generically.
I am at the moment working on a project that, among other things, controls the computer fans. Basically, the fans are controlled by the superIO chip of your computer. We access the chip directly using port-mapped IO, and from there we can get to the logical fan device. Using port-mapped IO requires the code to run in kernel mode, but windows does not supply any drivers for generic port IO (with good reason, since it is a very powerful tool), so we wrote our own driver, and used that.
If you want to go down this route, you basically need knowledge in two areas: driver development and how to access and interpret superIO chip information. When we started the project, we didn't know anything in either of these areas, so it has been learning by browsing, reading and finally doing. To gain the knowledge, we have been especially helped by looking at these links:
The WDK, which is the Windows Driver Kit. You need this to compile any driver you write for windows, With it comes a whole lot of source code for example drivers, including a driver for general port-mapped IO, called portio.
WinIO has source code for a driver in C, a dll in C that programmatically installs and loads that driver, and some C# code for a GUI, that loads the dll and reads/writes to the ports. The driver is very similar to the one in portio.
lm-sensors is a linux project, that, among other things, detects your superIO chip. /prog/detect/sensors-detect is the perl program, that does the detecting, and we have spent some time going through the code to see how to interface with a superIO chip.
When we were going through the lm-sensors code, it was very nice to have tools like RapidDriver and RW-everything, since they allowed us to simulate a run of sensors-detect. The latter is the more powerful, and is very helpful in visualising the IO space, while the former provides easier access to some operations which map better to the ones in sensors-detect (read/write byte to port)
Finally, you need to find the datasheet of your superIO chip. From the examples, that I have seen, the environment controllers of each chip provide similar functionality (r/w fan speed, read temperature, read chip voltage), but vary in what registers you have to write to in order to get to this functionality. This place has had all the datasheets, we have needed so far.
If you want something real quick to just lower fans to a level where you know things won't overheat, there's the speedfan program to do so. Figuring out how to configure it in the early versions to automatically lower fans to 50% on computer startup was so painful that my first approach was to simply byte-patch it to start the only superio managed fan I had at lower speed. The newer versions are still bit tough but it's doable - there's a graphical slider system that looks like audio equalizer except that the x axis is temp and y is fan speed. You drag them down one by one. After you figure out how to get manual control for the fan you want, this is next step.
There's a project to monitor hardware (like fans) with C#:
http://code.google.com/p/open-hardware-monitor/
I haven't extensively looked at it, but the source code and use of WinRing0.sys atleast gives the impression that if you know what fan controller you have and have the datasheet, it should be modifiable to also set values instead of just getting them. I don't know what tool is suited (beside kernel debugger) to look at what Speedfan does, if you preferred to snoop around and imitate speedfan instead of looking at the datasheets and trying things out.
Yes, It would be ACPI, and to my knowledge windows doesn't give much/any control over that from user space. So you'd have to start mucking with drivers, which is nigh impossible on windows.
That said, google reveals there are a few open source windows libraries for this for specific hardware... so depending on your hardware you might be able to find something.
ACPI may or may not allow you to adjust the fan settings. Some BIOS implementations may not allow that control though -- they may force control depending on the BIOS/CMOS settings. One might be hard-pressed for a good use case where the BIOS control (even customized) is insufficient. I have come across situations where the BIOS control indeed was insufficient, but not for all possible motherboard platforms.
WIndows Management Instrumentation library (WMI) does provide a Win32_Fan Class and even a SetSpeed method. Alas, the docs say this is not implemented, so I guess it's not very helpful. But you may be able to control things by setting the power state.
I am a graduate student and I am trying to propose a project for a advanced testing course.
Since I am a embedded guy, I do want to test something challenging related to embedded systems.
uC/OS-II is an very nice open source light-weighted OS for embedded systems. So I want to propose the testing for it for my course project.
But I don't know the feasibility of testing uC/OS. Is it doable?
I am using Blackfin and SHARC (are from Analog Devices) now and they are compatible with uC/OS (said on the uC/OS website).
In terms of testing tools, I think CUnit might work. Also we have a unit testing tool call EmbeddedUnit, which runs on VDSP (development environment for Analog Devices processors).
I have no experience with uC/OS, but my understanding is we should compile it and then include the .obj files and the header files into the project then we can use and test the functions in uC/OS.
Am I right?
Is it doable? Yes it is. We had a project that needed to be portable to many different environments uCos-II, Linux and VxWorks. In order to do that we wrote as simple abstraction layer that gave us a common API on all platforms to the OS features we chose to have enabled. We then wrote a Unit Test to test the abstraction layer, and had a unit test case for each OS feature we wanted to test (Msg Queues, Semaphores, Event Flags etc). We used that to verify our abstraction layer was functional and working on all 3 host environments.
uCos-II is delivered as very clean c-code that can easily be used in any number of tools such as code coverage etc.
Good luck.
Some googling has led me to believe that C++ is the best language for real-time 2D graphics programming, but since the Android is Java-based, is that still the best option? Or us the fact that I have to use NDK going to slow it down or something? My program also has a lot of scientific computing and I know C++ is best/fastest for that...
I've never done anything with the Android before so I'm really helpless right now. If I'm just going about it the wrong way, please give me other suggestions... Some other vocab I came across is OpenGL (which I have experience with, but that's more for 3D, right?) and Canvas (don't quite get this)? If I could get access to GPU-like capabilities that would be great.
Android applications are written Java, yes - however the Android NDK allows you to write performance-critical sections of your program in C or C++. From the Android NDK website,
The Android NDK is a companion tool to
the Android SDK that lets you build
performance-critical portions of your
apps in native code. It provides
headers and libraries that allow you
to build activities, handle user
input, use hardware sensors, access
application resources, and more, when
programming in C or C++.
That said, using the NDK appropriately will most likely not slow your program down.
OpenGL works for 3D and 2D graphics - if you're only interested in 2D you will want to look at using an Orthographic Projection - see glOrtho for more information. The Android Canvas, on the other hand, is the Java method for drawing raster graphics to the screen. It will let you render 2D graphics, but at a slower rate (and with frequent interruptions from the Android Garbage Collector).
Keep in mind that if you want to use C++, as of writing, there is no STL implementation available. There are, however unofficial ports that provide most of the functionality. STLPort is one that I have tried with some success. The biggest reason to move code to C/C++ is because of interruptions from the Android Java Garbage Collector - if you're not overly careful with your code, it will interrupt your program frequently to clean up objects you've left lying around. In practice this can limit game or simulation framerates drastically.
All that said, I would strongly recommend you look into one of the few open source android game engines that are cropping up. The best one I've tried is libGDX. It takes care of all the messy NDK details and lets you code your game / simulation purely in Java. It automatically runs the performance-heavy parts of the game engine in native code to get the fastest possible performance with the ease of coding in Java. Best of all, you can write your application code once and have it automatically run on Windows, Linux, OSX and Android - which makes testing your applications much, much easier than using the Android Emulator.
If you really want to look into the NDK yourself, or need to have really fine control on what OpenGL is doing, I would recommend you download the Android SDK and NDK, get eclipse set up, and then start with the NDK samples. There is an OpenGL demo there that shows you how to get everything set up. Another good starting point would be the SpinningCube google project.
EDIT: I'm not really sure if what you mean by 'GPU-like capabilities', but With libGDX, you can compile vertex and fragment shaders under OpenGL ES 2.0 - you could use this to run embarrassingly parallel code using the device's GPU.
You're making the assumption that the Android system will be too slow to do what you want, without any data to back that up. Write some tests in Java, and test out the performance first. You don't want to make assumptions about performance without any basis.
Premature optimization is the root of
all evil. - Knuth
How to do it: C-programmers guide to Java and JNI in Android
Good question, I put myself like 1½ years ago, found it very annoying. I feel a lot for you!
And because of this I like to give a hands on answer.
But look it is easy if you follow this guideline step by step (you will have much less struggle). I did it.
Learning this, you can in no time learn easily write Java Netbeans GUI with JNI apps (for any other OS) also, you are in the Java GUI JNI development world?
The basis is “knowing C/C++ very well, not knowing Java or Android programming at all, coming from for instance the Win32 SDK culture and making the first Android app”.
Android GUI is Java – you have to yield
Thing is that the GUI of Android is Java. Java like your app and the app is more or less in practice a piece of the GUI/OS environment completely integrated calling Java GUI SDK code all the time. The debugger even goes into the Java GUI SDK source code (feels like going off road, real odd for a Win32 SDK programmer).
In short, no way writing any Android apps, but in Java.
But it is pretty easy in anyway, you got the JNI
There are three very good shortcuts:
The Android sample library (is very rich), especially the Hello JNI sample is really important
The fact Java is in syntax very much alike C/C++ (but very different in its soul, read below, you need to understand)
You got the JNI C-code opportunity in doing the heavy work (and you major share of the code)
You have to write a small Java Android GUI user interface for your app (by thieving form samples) and the major part JNI, where you write your C/C++-code doing all the work.
Start with the Hello JNI sample program
Install Java and Android Studio and that it is all you need in tools (available in Win10, OSX or Ubuntu, they are the same).
Start Android Studio and its generic picture is a menu, select the lowest, Import an Android code sample.
The main sample program for a traditional C/C++ programmer is Hello JNI. Select it and say next to everything.
The Android Studio editor will open with the sample code (chews somewhat first see status line low).
Up to the right you (might need to push the Android tab to) see the content of your project Hello JNI, app. It consists of:
Manifests (app declaration, today of minor importance because most is now in Gradle script declarations (below))
Java tab for the Java files
Cpp-tab for your C-code files
Resources (texts, menus and icons)
Gradle compiling scripts
C-make-files
The Android studio might ask you for installation plugin upgrades, say yes to everything until it is done (see status line below).
Then run the Hello JNI sample code, to make certain your installation is OK
Pushing the green arrow in a cogwheel (mid top).
You get a dialogue box. Here you can try the sample on:
A physical Android device (via a cable from your PC, might need a Samsung win driver from their support)
A HAXM Android unit emulator (is reel good)
But you need to switch off the Hyper-V feature (used for XP emulation) in Win10 to make it run. Android studio might do it automatically for you asking, else control panel/Programs and functions/Windows functions.
Select Create new Virtual device. You might need to do some installation plugin upgrades more, say yes to everything.
When the Hello JNI app is working in the device, you have an OK installation.
C-code, check hello-jni.c
Look in the cpp-folder Up right) and you will find a C-file with a function.
Here and in any other C-file you can fill it with regular C-code.
Everything but the ANSI C locale features are supported (must get locale data from Java and transport them to the C-environment).
You need to edit the CMakeLists.txt file to add any additional C/C++-files (it is the makefile, look up to the right under the Gradle scripts).
Memory heaps, Java with JNI and C are different
You must be aware that everting in the data jstrings delivered by the JNI interface is located in the Java memory heap. This is also the case after the data has been in delivered C-format by JNI.
You will have fuzz if you don’t copy string data (and arrays) from the Java heap to the C-heap. Make a basic function like this to copy the data and release the JNI data:
char *GetStringfromJniString(JNIEnv *env, jstring jniString)
{
const char *TempString = (*env)->GetStringUTFChars(env, jniString, 0);
char *String = calloc(strlen(TempString) + 1, sizeof(char));
strcpy(String, TempString);
(*env)->ReleaseStringUTFChars(env, jniString, TempString);
return String;
}
When you send data to Java jstrings you need to contain it to the JNI transport by using the
return (*env)->NewStringUTF(env, pCstring);
Long funny names of the JNI-functions
The function name is Java_com_example_hellojni_HelloJni stringFromJNI(…).
There “Java” is always there
com_example_hellojni means it communicate with your app in the Java com.example.hellojni Java package (read about it in the tutorial)
The HelloJni is the name of the Java file the JNI function is declared
And stringFromJNI(…) is the actual function name (functions in Java are called Methods).
If naming is OK the declaration of the C JNI-functions in the Java file is black text, if not red text. (Give it a chance, it stores and checks the code continuously in the Java environment, might take a few seconds to verify it is right (becoming black).
You must declare the C JNI-functions in java
In the Java file here HelloJni.java the JNI-functions must declared as Java Methods (functions in Java).
public native String stringFromJNI(…);
Where return values and function/method switches are the same as in C.
After that you can use the JNI-functions as Java methods as they are declared in the Java declaration. Note that char * is String in java.
Constants must be declared on both sides
#define CONSTANT_A = 24
Is in Java
static final int CONSTANT_A = 24;
And you can use them in Java and in C as usually.
if(!variable) does not work in Java
You need to do
if(variable==0)
Test other samples
The sample library is full of fully nice functioning Java samples. Try them one by one until you find a user interface of your like. It is actually nice to test samples.
There are a lot of sample in Github but a lot of them need fixes of Gradle scripts or comes from Eclipse (the past Android dev environment) and is harder to try (often need fixes). Other Github sample are just fragments and a lot of work making them working. Of course nothing for a Java Android star but we are not there yet. But Github a very good even larger source of samples.
Copy the Java stuff into your Hello-JNI
Found anything nice, copy it!
Theft always pays as JS Bach used to do!
It is quite easy to just copy stuff from one sample to another. When copying in the Android studio, Android studio adds automatically the includes (asking first) and just accept. Sometimes it does it asking you to enter Alt-Enter, do it.
Editing several projects at the same time
The File/Open recent - Own windows-command, make you having two projects up at the same time, easier to copy stuff in between.
Making your own application
After some testing you create your own app.
Go to the generic Android studio picture (file/close project), select Start a new Android Studio project. Put your Package tree data (think that over, read about it in the tutorial) and create it. Then copy the stuff you tested to your own app.
Learn Java, the Android developer tutorial is real good
Now you have made your environment working and spotted some good user interfaces, learn Java!
The Android Studio tutorial is real good. Try it, and soon after a few lessons you will be able to play with Java code and very soon you are a Java programmer.
Getting stuck, google and you find most answers in Stackoverflow, just search.
You are never the first with a problem and Stackoverflow is real good. Read all the answers and think, you find what fits you best.
The Java environment and Android OS is very different from Windows
You need a feeling for the culture and environment. Like a Swede coming to Norway, the same food taste slightly different, even if it looks the same.
The major difference is that in Java nothing crash as good as in pure C in a C environment. Finding bugs can be hell because of non-consistent crashing. The program continue to run and crash later, but you find the bugs.
There are Java log files for debugging, but it takes quite an effort to penetrate it. Like learning the assembly code in a Windows debugger.
A good idea is to really debug the C-code in a pure C-environment first and handle the Java stuff in Android Studio.
I can amend C-code in Android Studio but writing a large chunk of C-code is really looking for troubles debugging it. Like asking a Norwegian make a Swedish dinner, impossible to get it right, looks the same but taste different. Nothing is wrong but different culture.
The soft crashing style of Java includes even security soft crash features like the try/catchy/finally stuff. (You have to google and read about it yourself. It is unbelievable for a hard core C-programmer, but it is real.)
There are no h-files and #if-compiler switches in Java
Instead of h-files and common declarations of functions/variables as in C in java you have to refer to them with a filename followed by a dot and the method name, using them from another file.
If declared private variables and methods can only be accessed from the same file, with public can be used with file reference. Static is something very different in Java.
There are no compiler #if-switches so you need to use regular variables/constants (for constants put final before in the declaration).
There are no pointers in Java, but there are strings
There are no pointers in Java but a String (and array) variable is in fact a char pointer
But you can’t handle pointers as in C with * and &, but in JNI you certainly can. The memory management is completely different, nothing is fixed in Java.
You don’t need to free data, Java wipes it all for you
Java cleans unused data automatically.
You don’t free data just delete (=0;) the string-“pointers” or just leave the method (Java function) and it cleans it.
So if you have a string pointer and just replace it with something else the old stuff is automatically wiped.
The Java environment lives its own life, but the Android studio debugger includes a monitor of the data used.
Size limitations of Java apps and JNI code
Good to know is that there are some restrictions in how large a Java app can be (but as usual nothing is written in stone in Java) but the JNI heap can be as large as the HW can take.
But you are not alone in a phone, an incoming call might come and you don’t want to mess that up? If you clean well it is a larger chance your app is intact returning to it and not killed.
Android apps don’t die by exit
If you exit an app, the app is still running even though the GUI is gone (like in Macintosh). Thing is that you have to be aware of that, read about it if you make serious apps.
Android kills apps
But on the other hand you can never trust that an app is not wiped by the OS and you have to rebuild. If the OS need memory it just starts to kill apps. But the JNI part usually survive and you can store data there for a recovery.
There is only one JNI instance (WinSDK term) but there might be many Java instances
And them all connect to the same JNI at the same time. Only one app instance can be active (shown) but the others might make background tasks. In JNI you need to keep track of them.
Normally there is only one Android instance of every app. But if you start the app by a work files from for instance like an email client, you in fact have another instance of the app (with its own memory and everything (but the JNI that is in only one common instance)).
Starting an appended file there will be two or more Android instances. Each related to each email instance, by the intents procedures (learn about intents in Android tutorial).
A smart thing is keeping track of the instances by number them when the app is created if savedInstanceState == null.
Copy data to the emulated unit
You might need to upload some data to test your app. In a regular phone you just attach the USB-cable and enter the Phone storage from Windows explorer. With the emulated units you must use the adb-terminal script functionality (can be used in bat-files in Windows and a copy bat file looks like this:
PATH=%PATH%;C:\Users\You\AppData\Local\Android\sdk\platform-tools
adb push C:\Users\You\Documents\v.txt /storage/emulated/0/Android/data/com.yours.app/files/v.txt
Very limited privileges to read and write files
Thing is however that you are only allowed to open your own files stored by your app in the emulated SD card. Else nothing comes reading them.
Use standard ANSI C file functions rather than Java
Best in a C-heavy app is to use standard C- file functions, as a C-programmer you are used to them and their behavior.
The C-file functions works fine and is easier to get binary code or transparent text files with ctrl-characters etc (Is not allowed in Java Strings but in java bit arrays). Take some effort learning Java file handling if you try that.
JNI performance is no issue
The C-code is much faster than the Java code so a lot of developers not from the C-culture must make JNI-functions and pure C-code to perform in heavy apps, needing performance. In short JNI performance is no issue.
However I have the impression that the Android GUI is faster than the WinSDK GUI in many cases. Working with ListViews and sometimes very long lists, Android is far better optimised. It looks like WinSDK is loading every line of the list, but Android only the lines visual, and in long lists it makes a huge difference.
I am impressed by performance in Android even with tiny ARM processors. Apps do perform very well. Intel Android units are real good in performance. I wouldn't hesitate trying to make a heavy duty app in Android, as long as I use JNI. Does not come short compared to Windows.
But notice, that running HAXM in an Intel PC the Intel emulated units runs much faster than the ARM than in real HW-units, because it runs intel code straight and not over an emulator layer as with ARM emulated units.
I am amazed that the Android x86 is not marketed heavier as a competitor to Windows on netbooks, for the common man, doing some documents, some calculations, email and Google? I believe the Crome OS is too alien for most people and most people have Android phones, feeling home. As a SW vendor I would like to see Android netbooks marketed much more and I would put more effort in SW development. Same thing with the Android TV without menus is closing the market for just the old Smart-TV approach. Something I can't understand having a boxed Win10 on the back of my TV since years, using a lot of programs there. The lack of Android graphics driver for the Raspberry-pie is also hard to understand, one with a regular Android would be smashing attached to the TV. In Sweden where I live, people under 40 don't watch aired TV, they stream, public service play, YouTube and Cable TV operators packages over internet. Having regular Android in the TV would generate usage of a lot of other apps. I see a market opportunity for SW vendors is closed. This when MS is making suicide with leased SW (normal people don't pay) mixing the culture of large accounts with the common man, a huge marketing window is opened. And the Android app performance is real good and nothing to worry about. It is not performance but marketing policies that limits the app market.
Quick you become a Java and Android master
You will be surprised how easy Java is for a C-programmer, doing it the right way (like following this guideline).
It might be slightly harder for a C++-programmer because the Classes in java and C++ culture looks to vary, might be easier to learn Java classes from scratch? But if you see C++-code in Win32 and OSX environment they look usually from different planets, so they might use to it.
The major disadvantage is that you wouldn’t get a diploma for your CV as doing a programmers course?
I've had a desire to learn at least a tiny bit about programming hardware for quite some time now and thought I'd ask here to get some starting points. I am a reasonably accomplished programmer with Delphi and Objective-c experience but have never even listened to a device port / interupt (I dont even know the terminology) let alone programmed a piece of hardware.
To start with what I would like to be able to do is,
Buy a simple bit of kit with 2,3 or 10 buttons
Plug the device into my pc via USB
Listen to the device and write some code to do something once the button is pressed.
I reckon this is a good place to start, anyone got pointers on hardware to buy or how I could start this?
I like the Arduino, easy to use, open source and a great community!
Good to get started with, and uses a subset of C/C++.
Also, has alot of addon hardware available, like GPS, Bluetooth, Wifi etc
My experiences with Arduino have been nothing but good, from the point you get it out of it's box (and install the free compiler on either Windows / Mac / Linux), to building your first 'sketch' (a project or application for the Arduino).
Making an application is easy, you have a Setup Method, which is called on startup, and then a loop method which is looped while the Arduino is running.
Then all you have to do is hook either inputs or outputs up to the pins on the Arduino board, tell the code what they are and hopefully you'll get the desired output.
One other really good thing about the Arduino (and others I'm sure) is that you now have a use for those old broken printers, or 2x CD-Rom's that no one wants, and every other little bit of out dated technology. It's amazing what you can find in a server room!
Now, I have only worked on small projects, like plugging in an LCD, and reading the room temp and various projects like that. But based on what I have done, I am happy with the Ardunio, it gives a good base to embedded programming and if it's not enough, you can always go bigger!
My 2 cents!
There's also the hot-off-the press netduino which uses the .NET Micro Framework and Microsoft Visual C# Express. I don't know that's it's better than the Arduino but it's another option.
Why don't you start with AVR programming for microprocessors. Yeh it might be a bit too low level. but I know many people that have started with it for hardware programming. you could find a compiler here. http://winavr.sourceforge.net/ and a good tutorial here: http://www.ladyada.net/learn/avr/
The previous poster mentioned the Arduino, but you should also consider a Teensy. It's basically the same thing, but price is a little better. You also have the option of using it in "Arduino" mode, or raw AVR mode. I don't know if Arduinos give you both options.
There is a comparison page where you can see the Teensy has some better hardware. The built-in USB gives it much better performance.
I would definitely suggest trying out various microcontrollers. Arduino Controllers are nice and have a number of tutorials.
However, its not your only option. In school, I worked with Microchip PICs, which are also quite nice for the hobbyist scene. The nice thing about the PIC was that our microcontrollers textbook supported it, so we got to see the application as we were learning the theory.
If I understand your question right, you are not interested in embedded programming. You want to buy something that works from the begining and control it from Windows.
When it comes to buttons, there is not much to do in Windows. These are HID controls and Windows handles all the interfacing for you. Nothing too exciting there.
In that case you can grab any Joystick and use the DirectInput (a part of the DirectX tech.) to interact with it. With force feedback you can do some cool stuff.
A more fun project would be to buy a Wii control and write some fun applicartions.
Look at this site to get some ideas of what I mean:
http://johnnylee.net/projects/wii/
Since Windows has no support for a Wii contrller, you really get to do some work here :)
I see that you like Delphi, so you can take a look at AvrCo Multitasking Pascal for AVR. You can try it at http://www.e-lab.de. MEGA8/88 version is free. There are tons of drivers, simulator, JTAG online debugger and programmer with visualization of all standard devices (for a startup, you can make a simple LPT programmer with just a few resistors). It can also make programs for all Arduino devices out there, since AVR is in their hearth. Atmel's STK500 is a good beginner board, with leds, switches, and few other peripherals. If you prefer open source, then WinAVR with GCC could be your path.
As already mentioned, Arduino is a good choice. The community is large and helpful. The nice thing is that you can transition right to a "real" language by using the GCC port for AVR micros, if you want. On my latest project I did this - prototype most of it with Arduino, then re-write it in C.
Starting with buttons and LEDs is a great idea. Build some confidence in working with basic hardware first, before modding the Wii!
Some links:
Windows GCC cross compiler (1 step install) for AVR: WinAVR
A Arduino clone kit
Adafruit is another good source of starter hardware and tech advice
The embedded StackOverflow
Any program you already write interacts with hardware, there's the monitor, keyboard, mouse, speaker etc. Getting a simple setup where your program can deal with buttons on a USB device will not teach you that much about working with hardware. It's partly a question of how low you want to go in the software stack and how much you want to learn about what happens at the point where the software ends.
Get yourself a copy of "The Art of
Electronics". It's a relatively easy read and covers everything between Ohm's law and the microprocessor and will give you a good idea of what the complete system does.
Read it.
Check out Digikey. You can buy anything hardware related from resistors, capacitors, IC's, low cost boards easily online and for reasonable prices.
Other replies mentioned Microchip PIC and Atmel AVR which are small and simple microcontrollers. Both companies have a wealth of application notes, check out their web site, read through some app notes. You can get low cost evaluation boards for the above or something like the Arduino mentioned in other replies. Consider designing and building your own board to force yourself to learn the basics. Find a friend who is an EE or serious hobbyist who wouldn't mind helping you with some tips.
If you want to learn more about PC hardware you can take a look at some simple device drivers (e.g. printer or serial port) under Windows (download the WinDDK), Linux or even DOS. Programming under something like DOS on a PC allows for relatively easy interaction with the PC hardware, you can use a printer port to read push buttons etc.
Links (I'm a new user so I can't link directly):
www.amazon.com/Art-Electronics-Paul-Horowitz/dp/0521370957
www.digikey.com/
www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2879
www.atmel.com/products/avr/
My new project is targeting an embedded ARM processor. I have a build system that uses a cross-compiler running on an Ubuntu linux box. I like to use unit testing as much as possible, but I'm a little bit confused about how to proceed with this setup.
I can't see how to run unit tests on the ARM device itself (somebody correct me if I'm wrong). I think that my best option is to compile the code on the build machine using its own native compiler for the unit tests. Is this approach fundamentally flawed? Is unit testing on a different platform a waste of time?
I'm planning to use CppUnit on the build machine using the native compiler for the unit tests. Then I'll cross compile the code for the ARM processor and do integration and system testing on the target device itself. How would you structure the source code and the test code to keep this from turning into a tangled mess?
With embedded device it depends on what interfaces (hardware) you have.
For example the motion control cards I deal with uses a command line interface. The IDE they ship uses it as it primary method of interacting with the cards. It works the same way regardless if I am using PCI, IDE, Serial, or Ethernet.
The DLL they ship for programming give access to the command line interface. So I can send a string, and read back the response. So what I do for my unit tests is have a physical card hooked (or in) my development machine. I send it commands after uploading the software, read the response and if they are correct it passes the test.
I also have extra hardware, a black box if you will, that simulates a machine that motion control card is normally hooked up too. It helps with the automated sets but there is a manual phase as I have to set switches to simulate different setups on the machine.
I have achieved a greater degree of automation by taking a digital I/O card and using it outputs to feed into the inputs of the motion control card and the same in reverse.
I found that for most hardware you have to have some type of simulator hardware.
The exception being the rare package that comes with a software simulator.
I know this isn't probably ideal as not every developer can have one of these on their desk. My hardware simulator so I can give it to whoever it working on the motion control software at the time. If it can't be portable then having a dedicated testing or hardware development computer would be in order.
Finally it boils down on the specifics of your hardware and what support the manufacturer gives in terms of software and simulators. To help you more you will need to post more specifics.
In ten-plus years in the embedded industry, I've seen it done quite a few ways. At my current company:
one of our products has enough horsepower (and space) to run tests on the target board. It's somewhat slow, and we can't stick all the python on the box we'd like, but it works well.
one of our products doesn't have the space, so we compile all the libs we can in x86 (anything that isn't hardware-dependent) and run unit tests on desktops. It's not perfect, but far better than nothing.
one of our components is a super-lightweight power-miser on exotic hardware, so virtually no unit tests are possible. Core algorithms (DES, etc.) are tested on x86 as above, but much of the code simply has to be tested as a whole, in situ. This entails lot of code reviews.