Question: I have done some basic object oriented programming with C++ (creating a B-Tree, Hashing Algorithms, Double Linked Lists) and I have done small project in C (like making a scientific calculator etc.)

**How different is hardware programming (specifically for micro controllers) from software/object oriented programming in terms of the mindset and "thinking" that the programmer has to have?**

Is one usually considered harder than the other my most people?

With my background (as described above) would I need a lot of preparation for going into hardware programming or can I dive straight in without too much preparation?

Answer: 
I'm presuming your C++ experience is PC-based. 

An often made error by programmers moving from PC to microcontroller is that they don't realize how **limited resources** can be. On a PC nobody will stop you when you create a table with 100 000 entries, or write a program which compiles to 1MB of machine code.  

There *are* microcontrollers which have a wealth of memory resources, especially in the high end, but it's still a far cry from what you'll be used to. For a hobby project you probably can always go for the maximum, but in a professional project you'll often be forced to work with the **smaller device** because it's **cheaper**.  

On one project I was working with a TI [MSP430F1101](http://focus.ti.com/lit/ds/symlink/msp430f1101.pdf). 1KB of program memory, 128 bytes of configuration Flash, 128 bytes of RAM. The program didn't fit in the 1K, so I had to write a 23 bytes function in the configuration Flash. With these small controllers you **calculate by the byte**. On another occasion the program memory was 4 bytes too small. Boss wouldn't let me use the controller with more memory, but instead I had to optimize an already optimized machine code (it was already written in assembler) to fit the extra 4 bytes in. You get the picture. 

Depending on the platform you're working on you'll have to deal with very **low level I/O**. Some development environments have functions to write to an LCD, but on others you're on your own, and will have to read the LCD's **datasheet** from start to finish to know how to control it.  

You may have to control a relay, that's easier than an LCD, but it will require you to go to the register level of the microcontroller. Again a datasheet or user manual. You'll have to get to know the microcontroller's structure, which you'll find in a block diagram, again in the datasheet. In the microprocessor's days we talked about a **programming model**, which was basically a lineup of the processor's registers. Today's microcontrollers are so complex that a description of all the registers can take the best part of a 100 pages datasheet. IIRC just the description of the clock module for the MSP430 was 25 pages long. 

You'll often have to deal with **real time** event handling. An **interrupt** you have to handle within 10\$\mu\$s, for example, and during that have another interrupt which requires the same timing accuracy. 

Microcontrollers are often **programmed in C**. C++ is rather resources hungry, so that's usually out. (Most C++ implementations for microcontrollers offer a limited subset of C++.) Like I said, depending on the platform you may have an extensive **library of functions** available which could save you quite some developing time. It's worth taking some time to study it, it may save you a lot of time later on if you know what's available.
"hardware programming" can mean a lot of things. Programming a very small chip (think 10F200, 512 instructions, a few bytes of RAM) can be almost like designing an electronic circuit. On the other side programming a big Cortex microcontroller (1 Mb FLASH, 64 kB RAM) can be a lot like PC/GUI programming, using a big GUI toolkit. IMHO a good embedded/real-time programmer needs skills both from the software egineering side and from the circuit design side. For the bigger uC C++ is a good language choice, for the very small ones C might be the only choice. Assemby knowledge can be handy, but I would not recommend doing serious projects entirely in assembly.

I have done serious embedded work with people from both (SWI and EE) sides. I generally prefer the SWI people, provided that they have some experience with multu-threaded programming. 

Your question sounds like you want to dive into embedded programming. By all means do so. For the low-level aspects (interfacing the peripherals in your chip and the hardware around it) you will need to learn some new skills, but it is just a lot of work without many new concepts. For the higher layers of your projects you can draw on your existing knwoledge.