Originally Posted by
freexray
Just some comments from my experience with AVR.
Any AVR that supports a 20MHz clock (most modern ones) will support a 1.25MBaud uart. However at that rate you would have 160 clock cycles between uart transfers, so it may be very tight if you plan to program in c.
EDIT: that is to say the AVR will need to run at 20(or 10 with high speed UART enabled)MHz.
If you have SPI working, you could use an FTDI ft2232 to directly connect to a pc (and let FTDI deal with driver support, with drivers being supported on just about everything imaginable atm).
The ft2232/ ft232r /ft230x should also handle UART at 1.25MBaud (you will need to check, they go 300Baud to 3+MBaud).
Alternatively the "u" coded AVR have USB phy built in (eg atmega32U4) however you will need to write your own drivers (or use the open source drivers like LUFA or ATMEL's libs)
Not knowing your background this may be a bad suggestion, and would be overkill in the extreme, but have you considered an FPGA? All logic could be implemented on the FPGA, serialisation ect. only thing not possible would be analogue stages (and even then you have DSP....). Downside would be the cost.
Many thanks for your input. I misread the datasheet; yes, it looks like the UART will run at 1.25 MHz with the 20 MHz clock. It's nice having others check up on me to catch my mistakes!
I was thinking about using the UART to read the demodulated signal from the transponder, but then realized that the format isn't compatible-- the transponder doesn't send start and stop bits. This might not be a big deal; even a garbled result from the transponder would still be useful as long as the result is unique to that transponder. But at the moment I think I should keep all of the information intact, just in case.
Also, it is unclear to me whether or not the UART in the ATmega devices re-synchronizes to the incoming data on each bit or each start bit, or simply times everything from the first detected start bit. The transponders send a pulse train having 98 total bit "slots", and their bit rate isn't very accurate, so errors can occur if the UART doesn't re-synchronize at least a few times during reception of the transponder data. My SPI design re-synchronizes on each received phase inversion (which I have been calling a logic 1).
The FPGA would be the logical route to take for production runs. It would also be nice to have for prototyping, but I don't have the programming tools laying around here. I do have a bunch of 74HC logic laying around, so that's what I'm using. Do you have any suggestions for a very inexpensive FPGA family and the associated tools?
There is another benefit using standard 74HC logic: If we make this design open-source, then the decoder could be constructed by others with minimal effort and expense.