Funny thing about the UART not being able to do manchester coding— since he's defining the protocol, it totally could! He'd just have to define each data byte as two wire bytes, and then translate on each end.
On the whole though, it seems weird to eschew software USB but then go ahead with software serial. I would definitely have just done this as FTDI -> SPI. Or thrown away the AVR, and gone with a some dirty-cheap 32-bit ARM chip that has the needed peripherals built right in. Maybe an STM32F04, which is $3.64 at quantity 1:
I decided against software USB because the receiver is already spending much of its time trying to meet the real-time limits from the radio decoding, and the USB would be its own big undertaking.
As I stressed in the preceding post (http://spin.atomicobject.com/2014/05/16/radio-system-from-sc...), I'm intentionally doing these things the hard way, so I can learn how more of these things work at a deeper level than "use built-in functionality, configure to run at this baud rate, done". Otherwise, yeah, I'd use a 32-bit ARM chip and a better SMD transceiver. :)
On the whole though, it seems weird to eschew software USB but then go ahead with software serial. I would definitely have just done this as FTDI -> SPI. Or thrown away the AVR, and gone with a some dirty-cheap 32-bit ARM chip that has the needed peripherals built right in. Maybe an STM32F04, which is $3.64 at quantity 1:
http://www.digikey.ca/product-detail/en/STM32F042K6T6/497-14...
That's a 32-pin LQFP package, which is straightforward to hand-solder for an intermediate.