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 do both, so here's my view.

I think the most important skill by far in embedded is your debugging ability. The required mindset is much different in that so much more can go wrong, and you must be very open to considering all the different ways what you are trying to do can go wrong.

This is the single biggest issue for new embedded developers. PC people tend to have it rougher, as they're used to so much just working for them. They'll tend to waste a lot of time searching for tools to do things for them instead (hint: there aren't many). There's a lot of banging heads into walls over and over, not knowing what else to do. If you feel you're getting stuck, step back and figure out if you can identify what all might be going wrong. Systematically go through narrowing your potential problems list until you figure it out. It follows directly from this process that you should limit the scope of problems by not changing too much at once.

Experienced embedded people tend to take debugging for granted... most of the people who can't do it well don't last long (or work in large companies that simply accept "firmware is hard" as an answer for why a certain feature is years late)

You're working on code that runs on an external system to your development system, with varying degrees of visibility into your target from platform to platform. If under your control, push for development aids to help increase this visibility into your target system. Use debug serial ports, bit banging debug output, the famous blinking light, etc. Certainly at a minimum learn how to use an oscilloscope and use pin I/O with the 'scope to see when certain functions enter/exit, ISRs fire, etc. I've watched people struggle for literally years longer than necessary simply because they never bothered to set up/learn how to use a proper JTAG debugger link.

It's much more important to be very aware of exactly what resources you have relative to a PC. Read the datasheets carefully. Consider the resource 'cost' of anything you are trying to do. Learn resource-oriented debugging tricks like filling stack space with a magic value to track stack usage.

While some degree of debugging skill is required for both PC and embedded software, it's much more important with embedded.
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).