descriptor request. Reached second transaction which is set address.
Need to add support for set address to move forward.
Added some fancy macros for handling the uber annoying EP0R register
Would like to make some even fancier macros that work for all EPnR
registers taking the number as an arguement for the macro.
Might be good to start cleaning up the code a bit before getting too much
further. Really feel like things are getting messy... Maybe don't need so
many copy pastes from the reference manual..?

Couldn't figure out why the second IN packet wasn't getting sent.
The host requests 16KBytes worth of data when it makes it's first get
device descriptor request. HOWEVER, it sends a STATUS packet immediately
after receiving the first IN stage. The stm32 ref manual recommends
STALLing all xfrs in the opposite direction of current transfer. But that
breaks things preventing the host from telling the device to stop talking.
So still need to add that fix but everything looks good for the first data
stage when using logic analyzer.
Current build added support for devices which require external xtals for
USB via define statements. Also setting flash/sram size to 32KB/6KB to
support smaller devices. Adding include files for other devices, guess
030 is pretty worthless considering it doesn't have USB...
Added "make program" support to make file. ST-LINK_CLI.exe must be in
path variable, only works on windows for now..

Currently USB ISR just sets the yellow LED on discovery board.
Not getting a CTRM interrupt to the first setup packet isn't transferring
correctly.
I am getting error, suspend, reset, eof, & esof interrupts though.
Also PC is detecting that something is connected but fails device
descriptor request.
There is a problem with usb buffer pointers though based on response I
got: http://a3f.at/articles/register-syntax-sugar#comment-3418319877
So going to try that fix and see what happens.

Issue was due to messed up SRAM define in linker script. IDK what
datasheet I was reading.. But I had the location and size completely
wrong. That caused any access of SRAM to cause a hardfault of course.
First happening when popping anything to the stack. Which also explains
why I couldn't look at the stack to figure out the last called instruciton
to point to where the issue was...
copied stm32f0xx_*.h files over from STM32F0xx_StdPeriph_Driver/inc dir