Learn C, and get a cheap microcontroller development board, like an MSP430 or ARM Cortex, and at least write and load a few C programs.
I have a computer science degree and a software development background, mostly C++ programming for games and now iOS games and apps, but my last job was a semi-pro EE gig that started with doing a bunch of firmware programming for an ARM Cortex M3 system, and then ended up with me learning how to do some basic circuit design and board layout and designing a couple of simple boards. So I basically had to confront the problem of using the best programming language for bridging the hardware/software design as someone who was responsible for both ends of it.
C is absolutely the language you need to know. It's easy for people who program in C++ and never actually have to restrict themselves to C's feature set to say "it's the same thing" but it's not. Especially the way C++ has evolved and gathered features, and the way mainstream C++ programmers use those features, it is really a much different thing to work on a reasonably large C application as opposed to a C++ application. Your firmware SDK will be a bunch of C libraries, anything else that will fit on an MCU will be a C library, any OS that makes sense on an MCU will be written in C, etc. etc.
That said, since many of the MCU toolchains out there end up using GCC as their compiler, you will almost certainly have a C++ compiler available if you're using a decent MCU family. But you have to be very careful about the features you use, especially things from the standard library, as it is very easy to end up with a binary that is way too big to fit on your device. I think there is a good case to be made for using C++ on embedded devices, C++ has quite a few nice features that have litter or no size or speed penalty, you just have to know what you're doing and write code that is way further on the C-style end of the spectrum than the STL end of the spectrum in terms of clever feature use.
Don't pay too much attention to people who say you can use Lua or Python on an MCU with the right embedded interpreter blah, blah. That is true, I've done it and it's fun, but at the moment it's more for toy projects and stuff that shows up on Hack a Day. I think we'll see more of that sort of thing as Moore's Law is relentlessly applied to even the smallest processors, this is something that happened with games where there used to be a lot of assembly, then they held out with C and C++ longer than everyone else, and now everything is so fast, and developer productivity is so important that a lot of development is done with embedded higher-level languages or in a high level language outright. Even so, it'll be a few years before you see companies hiring firmware programmers with Python and Lua backgrounds.
Don't spend too much time on assembly either. It's not bad to be familiar with the concepts, but it is unlikely you'll find yourself doing much, if any assembly programming. There's like this conventional wisdom with games and embedded that it's "good to know" assembly, often repeated by people who don't actually work in those fields. But in reality it is very unlikely you will write any assembly at all, ever, and if you do it'll probably just be a few lines for optimization or something with the hardware you just don't have an API for (but you will after you write one that wraps a few lines of assembly). I've worked on several games and that board/firmware design project and the total number of lines of assembly I've written for commercial projects is probably in the low teens. It's not productive, it's not portable and it's not readable so it's only ever used as the last possible option.