+1 on having a project interesting to you. This is the motivator to keep on learning, experimenting, coding, and tweaking until it's right.
+1 on getting the datasheet and studying it. That is how I cut my teeth on PIC micros way back. Note however that unless you plan to write in assembly code, then ignore the entire large section about the instruction set. If you aren't sure, then the answer is resoundingly "NO". Chances are you will write in C/C++ etc. Let the compiler worry about the instruction set! You need mainly to know about peripherals, interrupts, and I/O.
If you are sticking with Arduino, do yourself a favor and install a good IDE like Eclipse. You can use it just as an external editor, continuing to use Arduino IDE to build/compile and upload, or you can install an add-on and use it independently of the Arduino IDE. Either way, one main benefit this provides is a powerful editor which will index and cross-reference all the code, including the Arduino sources, libraries you are using, and your own sketch files and other source files. Without that, coding in Arduino can make you feel lost and confused. Ever wonder which code actually calls that "loop()" function over and over (and what else is it doing?), or how millis() or delay() or digitalWrite() is implemented? It's so easy to look at that code once you are inside a proper cross-referencing IDE. Then you will start to understand what is - and isn't - happening on your micro, outside of your sketch. You also absolutely must look at the source for any library that you will use. Partly, this is because most of them are poorly documented. Mostly, it is so that you understand what hardware resources are being used by that library. You can't simultaneously use two libraries which both depend upon Timer2, for example. Some are coded so inefficiently that you might choose not to use them. For example, a very popular infra-red remote control library sets up a timer to sample the input every 50 microseconds. That 20000 interrupts per second, to look for IR signals that might be minutes or hours apart. The MCU spends a significant portion of clock cycles servicing that interrupt for no good reason. If you need high performance elsewhere, such a library might frustrate your efforts.