USB-to-SPI converter

[delmadord]

Greetings, I am curently building a project which revolves around an ATmega168 or ATmega328 (depending on final code size, both in my stock) and handuful of 3V3 devices, all operating on SPI bus.  Since I need an USB connection there, operating as serial port (need to send commands and receive files),my first though was to order an USB-to-UART converter such as standard FT232R, but then I realised that, why to use this device, if I can use some USB-to-SPI converter, I already using SPI there for everything.

Quick look obtained three candidates USB-to-SPI:
1) MAX3420E this looks cool, includes a 4 pin port expander to compensate SPI (can get a sample, but one sample order is on the way, they may turn me down for some time)
2) CP2104 never used this, but I remember reading something that CP < FT in UART versions (probably can get a sample too)
3) FT121 I believe this one from FTDI will do it (not sure about sample)

Did anyone used one of these (or perhaps other one, better maybe) ? Any recommendations on which one to use? It is one-off project, but I would prefer to not order anything more.

My other options are:
1) order ATmega32u2 (since I do not need an I2C and ADC, which AFAIK has only 32u4 version) - looks like a great solution, but will consume more money
2) free V-USB library since I will be doing full documentation of the project anyway, but I am not sure that the V-USB speed will suffice (the files are CSV, with raw data, so it may be OK)
3) HC-05 - I have some of these lying around, I may use one and completely discard USB, but I have far less experience with BT. Seems a lot more complicated for me from my POV.
4) actually order FT232R - will consume money and an UART just for this
5) CP2012 - never used it, could it work? (probably can get a sample)

I am also curious why USB-to-UART is generally used more ( in basic devices, such an Arduino, at least from my observations) than some USB-to-SPI. In my theory,communication should be faster with SPI. It is a price, pin count, both or something else? Thanks for all advices/opinions!

[jeremy]

I have used the similar FTDI USB to I2C chip, it's great!

I imagine the reason these are not so popular is because UART is mostly used on microcontrollers for low speed communication ie debug information. It is simpler for an IC to operate synchronously (I2C, SPI, etc) with the microcontroller at higher data rates without paying *too* much attention to the surrounding circuits.

[delmadord]

I have used the similar FTDI USB to I2C chip, it's great!

Great to know, thanks!

I imagine the reason these are not so popular is because UART is mostly used on microcontrollers for low speed communication ie debug information. It is simpler for an IC to operate synchronously (I2C, SPI, etc) with the microcontroller at higher data rates without paying *too* much attention to the surrounding circuits.

Could you please explain more? I am not quite sure what you want to say at the end,

[Harvs]

I am also curious why USB-to-UART is generally used more ( in basic devices, such an Arduino, at least from my observations) than some USB-to-SPI. In my theory,communication should be faster with SPI.

Yes SPI will usually have a faster throughput (if that matters to you in your application), but it's also slightly more complex in that one device has to be the master and poll the other device for data, or have yet another pin to indicate data is available. For low speed communication where the Rx and Tx are completely separate, you can't get much simpler and easier than UART.

HC05's work fine IMO.  Probably the only non-obvious thing to be aware of is they draw bursts of power.  So if you're using any sensitive analog circuitry make sure that they don't share the same power rail.  Other than that it really comes down to whether you want a USB link or a BT link.

[jeremy]

Well, this is just a hypothesis but...

UART is asynchronous, meaning that the clock is not transmitted or that there is no clock. Alternatively, I2C and SPI are both synchronous because they have dedicated clock lines (SCL and SCK respectively).

When you decode an asynchronous data stream, you usually need to know something about the clock frequency before hand so that you can try to oversample the data (sample lots of times during a 1 or a 0 to ensure correctness) and recover the data without error. Conversely, decoding a synchronous data stream is simple: at the clock edge, sample the data once (you can oversample for noise filtering purposes, but it is not strictly necessary).

On top of this, if two devices have enough error in their master clocks, it can make asynchronous transmissions very error prone. It is not uncommon to see two devices which are trying to communicate via UART at 115200 baud that are actually transmitting at different speeds and thus end up transmitting garbage to each other. And only having one parity bit in the transmission means that you have a 50% chance that a corrupted message will still have a correct parity bit.

As you can probably imagine, this gives synchronous protocols three major benefits:

1) Less stuff needed on the IC to handle the oversampling
2) Communication channel can run at any frequency within the spec, rather than just a specific, prenegotiated one
3) Master clocks for the two devices need not be accurate or synchronised

So I think one would be better off using UART for something that doesn't matter too much (like sending debug messages to your terminal) or slow communication, while saving synchronous transcievers for inter-chip communication. If I received a message in my serial terminal that said "bootiúg kernel from flash.....ok", I would still know what it means. But that one error on an inter-chip bus could be the difference between the board working or not.

[delmadord]

Yes SPI will usually have a faster throughput (if that matters to you in your application), but it's also slightly more complex in that one device has to be the master and poll the other device for data, or have yet another pin to indicate data is available. For low speed communication where the Rx and Tx are completely separate, you can't get much simpler and easier than UART.

Now it gives me sense - master and slave. Thanks Harvs!

Thanks jeremy for your helpful opinion too!

So I think one would be better off using UART for something that doesn't matter too much (like sending debug messages to your terminal) or slow communication, while saving synchronous transcievers for inter-chip communication. If I received a message in my serial terminal that said "bootiúg kernel from flash.....ok", I would still know what it means. But that one error on an inter-chip bus could be the difference between the board working or not.

My application would benefit from having fast precise data. I will probably go with the SPI.

This is leading me to another realisation: If MCU probes an SD card for data, they are already going back over SPI, so this means that MCU do not need to ever touch them and SPI-to-USB can just sniff it and send to the pc to awaiting application, there is no need for extra conversions or other work on the MCU side, right? If yes, could this mean that the power consumtion will be lower than in a situation where MCU will need to convert it to UART and then send to USB?