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: 
You need to think about several things:

* You will use C as the language
* You can still create a feeling of object orientation using function pointers so that you can override functions etc. I have used this method in the past and current projects and works very well. So OO is partially there but not in C++ sense.

There are other limitations that will come in to play such as limited speed and memory. So as a general guideline, I avoid:

* Using heap, if there is a way to solve the problem without Malloc, I do that. For example, I preallocate buffers and just use them.
* I intentionally reduce the stack size in compiler settings to face with stack size issues early on, optimize that carefully.
* I assume every single line of code will be interrupted by an event, so I avoid non reentrant code
* I assume even interrupts are nested so I write that code accordingly
* I avoid using OS unless it is necessary. 70% of the embedded projects doesn't really need an OS. If I must use an OS, I only use something with source code available. (Freertos etc)
* if I am using an OS, I almost always abstract things so that I can change OS in a matter of hours.
* For drivers etc. I will only use the libraries provided by the vendor, I never ever directly fiddle the bits, unless I have no other choice. This makes the code readable and improves debugging.
* I look at the loops and other stuff, especially in ISR, to make sure they are fast enough.
* I always keep a few GPIOs handy to measure stuff, context switching, ISR run time etc.

List goes on, I am probably below average in terms of software programming, I am sure there are better practices.
Regarding microcontroller vs OOP programming, they are not something opposites. It is true that all vendor libraries are in plain C, but all platforms support C++ OOP too. Developers can build and do build C++ high level libraries and device firmware on top of that. The good example is Arduino libraries, official and user built - mostly C++ classes. Maybe not all OOP advantages can be fully utilized in embedded environment, but well known C++ vs C advantages are valid here too.

Regarding the mindset and thinking, as noted in other answers, microcontrollers are very resource constrained platforms (specially in RAM, less in speed) - stuff like dynamic memory allocation, C++ exceptions are usually ruled out. Given the right hardware is chosen, it is easy to adopt to these limitations and use other techniques (also widely used in other platforms).

In my view, the harder challenge might be one more extra dimension found in embedded programming - timing. This is because usually embedded software deal a lot with real-time events, strictly timed protocols to drive peripheral hardware and general task itself (these is some parallels in other "high level" platforms too, like multi-threaded applications).

Be prepared to read a lot of datasheets when dealing with new hardware - I guess it could be related to "mindset" question part :) Surely some EE and hardware knowledge would be needed.

Also I would like to note that these days embedded software development doesn't require assembly language. In fact Java (BTW it is OOP by default) is already here and getting stronger (at least for some class of embedded devices, for example IoT devices, it could have very bright future).