What is easiest way for a micro to talk to a computer?

[westfw]

Parallel ports disappeared from PCs somewhat before serial ports did.  And while you can get a USB/Serial converter or chip, the replacements for the parallel ports all seem to be "parallel PRINTER converters" that are intimately tied to printer drivers, and don't have the programable simplicity of the original parallel port...

are places like Digikey and Mouser a safe bet or can duds end up on those sites too?

They are safe places to buy chips.  But they also sell modules produced by other vendors, and those MIGHT be subject to less care, and could have counterfeit chips.  OTOH, I would trust Digikey and Mouser to take back such modules if they end up not working due to counterfeit chips (and pressing back on the manufacturer.) (unlike the random eBay seller.)

http://www.digikey.ca/product-detail/en/ftdi-future-technology-devices-international-ltd/FT230XS-R/768-1135-1-ND/3029155
Would this chip do what I need, or is there a better/more popular one?  Guessing these are common enough that Linux and Windows would probably have drivers built in and it just shows up as a virtual serial port?

Yes, it would do what you need, and windows has built-in drivers these days.  The FTDI chips are/were very popular, tempered by the company's recent questionable behavior toward counterfeits (disabled in particularly unfriendly ways by the drivers.  Search FTDIGATE if you care.)

Based on your level of expertise, you might be better off with a pre-built module.    I've seen the following recommended: http://www.digikey.com/product-search/en?keywords=MIKROE-483
(OTOH, this would be one of those "other vendor" products with a higher likelyhood of counterfeit chips.  I haven't seen any complaints about this particular vendor yet, though.)
This would solve the "fine pitch SMT" problem, but it's a $10 module instead of $3 worth of components (or a $2 eBay module.)

Idealy I'd like through hole but not sure if there are any.

The Microchip MCP2221 is available in DIP.  I haven't heard anything good or bad about it, though...





Idealy I'd like through hole but not sure if there are any.

http://www.digikey.com/product-search/en?keywords=MIKROE-483

[Buriedcode]

Yeah, forget about the parallel port.  It's all well and good if your PC already has one, and you're designing something specifically for that PC, but to develop something new using a parallel port is mad.  $10 for a parallel port PCI.. that will have to be put in any PC your project uses, plus the legacy back end... plus the big, thick cable that goes with it... and the large 25-pin connector.. ugh.

As you mentioned FTDI the FT232RL has been the staple of many 'microcontroller' projects for years, but there are viable alternatives that work just as well.  Microchips MCP2200 has already been mentioned  and the CP2102-based modules can be had for a few $$ on ebay or amazon. Avoid 'prolific' chipsets (PL2303hx) because their drivers started to get funky and unreliable about 8 years ago.

Both the above are surface mount devices, but as mentioned, simple modules that just have a USB-mini B anda  few pins (Tx, Rx, _5V, GND etc..) are fairly cheap and totally worth it for convenience of development.

For through-hole devices, and if you wanted to get your hands dirty with micros, whilst it may seem a huge task, using a USB-capable micro isn't that difficult.  Both microchip and atmel have example software that you can flash into one of their devices  - application notes will mention particular devices, but the PIC16F1455 (microchip) and ATmega16U2 (Atmel) spring to mind.  Ultimately, you can just flash these micro's with an example project from either of the vendors IDE software and have a working stand-alone USB-UART bridge.  You can then use other micro's with their UART's to communicate with the PC. 

Or of course, you can  modify those example projects, so instead of the micro's UART getting, and transmitting data on the USB, you can deal with the data directly.  This is what I did for several projects - use microchips USB-serial bridge example code, but add in a few lines of code to read from the ADC, or control PWM.   As far as the PC is concerned, its still a 'serial port', because the USB device enumerates itself as such, so the PC side of things is easy... you send some bytes from a buffer in your PC code, and its sent to the buffer in your micro, and visa versa.  What you do with those bytes is up to you.

10 years ago, it was a bit of an effort to get native USB support into a project (for hobbyists) so the FT232RL became very popular.  These days, with the PIC16F1455 being about $2 and other small micro's with USB capability, its cheaper, more fun, and better experience to use these - plus you avoid the 'heated' debate over FTDI's dubious practice of dealing with fake devices.

[Buriedcode]

The Microchip MCP2221 is available in DIP.  I haven't heard anything good or bad about it, though...

http://www.digikey.com/product-search/en?keywords=MIKROE-483

Oops, seems they do do a DIP USB bridge.  And if it does I2C as well, I might even buy a few as I do hate I2C on micro's.

[suicidaleggroll]

Don't try to use a parallel port for this...I actually had to look at the date of this thread when I saw that suggestion to make sure it wasn't a necro-post from <2005.  Parallel ports are not "legacy", they are obsolete, and have been for a long time.  USB -> UART is going to be the simplest, easiest, and most portable option today and for a while to come.  Don't avoid FTDI just because there are fakes of one of their models (not even the model you're looking at) out in the wild that don't work properly with their Windows driver.  Just don't buy cheap shit from China and your chances of getting a fake of any part drops to near-zero.

[Red Squirrel]

I'll be sticking to USB virtual serial, the idea is I want to be able to apply this knowledge to most/all of my projects so I can always have a USB diagnostic/telemetry port.

At some point I want to learn how to do true USB but that's another topic for another day.  Most things I can get away with serial and that's easiest.  Can even get fancy and make a text based interface to talk to it.

I'll probably order a couple of those chips from Digikey.   

[dgtl]

* Parallel port is dead. The simple bitbang won't work with usb-parallel converters and this limits your device to machines with native port, that have not been mainstream for 5+ years.
* If the computer has native RS232 serial port, this is bulletproof solution. Even some new pc mainboards have serial ports (some have only the headers on board but the bracket has to be obtained extra). If higher reliability is needed, you can handle the problems on data layer and you do not have to worry about the ports coming and going away dynamically and the issues of some USB controllers and high-speed signal integrity issues. For standalone automation tasks etc, I would prefer native rs232 over any usb connection. But not for consumer-oriented things.
* USB-serial is a reasonable compromise. Reliability may sometimes be an issue, because it is very difficult to handle all kind of problems how the usb can get broken. Too many USB problems need un-plugging and re-plugging the cable and this may be issue when you have a lot of devices and they are far away. The uart layer between the usb-serial and uc is an unneeded conversion step and performance bottleneck. Also, the device shows up as "usb-serial converter" and some customers do not like it (there are ways around, though). Another issue with serial ports is the autodetection of the device connected to the port; the "select com port number" thing is stupid in the age of usb plug and play.
* Modern uc's have internal USB port. You can get better performance and more control on the data transfer when using uc USB device port as USB serial. This can in some cases be cheaper than uc + external converter. Beware that this needs the usb stack on the uc side and some vendors' stacks are terribly broken. Also, you need drivers on PC side. Microsoft has generic usb-serial class driver (usbser.sys), but until win10 it was not loaded as class driver and you had to provide inf file to bind it with your device. Linux and mac works with built-in drivers. The inf file needs to be signed or you'll get warnings for win7 and you can't load it on win8. Also, unless you can use the vendors' vid/pid (for some vendors, there are options), then you'll need your own and this is costly. So, the amount of work on this solution depends a lot of the uc vendor, it may be totally easy or real hell. On the plus side, throughput is higher and the device is identified automatically (still requires a lookup in win registry to determine com number for a given usb vid/pid).
* Some other usb protocol? Sometimes, you need usb hid, mass storage or other class protocol. If your device must emulate keyboard (ie barcode scanners), then it would not be wise to make it a serial port device and then build an application to pump data from serial to keyboard buffer.
* Custom solution without serial layer inbetween. You can use just the usb layer itself and make your own protocol on top of that. This can provide much higher throughput and/or lower latency (ie for usb 2.0 high speed with ulpi phy, i've reached >200Mbit/s between STM32F205 and PC). You can use whatever the usb provides (control transfer (packets!); bulk stream transfer; isochronous transfer etc). Downside is that the device needs driver on PC side. There has been libusb driver around for years as a generic driver to forward usb layer to userspace application. Finally, microsoft has also made their own generic driver, WinUSB, and this can be driverless (automatically loaded) on win8 and up (win7 needs inf, but does not have to be signed). You still need USB VID registration and this costs a lot. Anyway, this needs a lot of knowledge and work, so definitely not for beginners.
* Other options? Ethernet? Wifi? Bluetooth?

[dgtl]

I'll be sticking to USB virtual serial, the idea is I want to be able to apply this knowledge to most/all of my projects so I can always have a USB diagnostic/telemetry port.

Ah, diagnostic port. Usually, I'm adding an extra pin header connected to uc uart. For debugging and diagnostics, I'm using the FTDI cables ( http://www.ftdichip.com/Products/Cables/USBTTLSerial.htm ). The converter chip is not soldered on board, but is in the cable. This makes the boards cheaper, there is no need to solder on board the things that are usually not used. When debugging is needed, a debug cable is plugged in. Having the chip at usb connector end is more convenient, there is no dongle hanging on or near the board. Of course, any cheaper usb-serial converter board can be used.
Beware that the usb-serial converter TX wire is default-high and if the converter is powered from usb (like the ones with cables are), the tx can provide parasitic power via uc gpio pin to the whole system.

[MSO]

I’ve just started down the same path (USB to MCU) using Microchip products. I bought Microchip’s PICDEM Lab II Development Kit (DM163046) for US$100.00 and their PICKIT-3 (PG164130) for US$48.00. 

http://www.digikey.com/product-search/en?keywords=DM163046
http://www.digikey.com/product-search/en?keywords=pg164130&WT.srch=1

The PICDEM Lab II has two MCP2221 USB bridges on board; one is hardwired to the various MCU sockets and one is ‘free standing’ with a row of pins so you can connect it to whatever device you may have plugged into the breadboard.

The MCP2221 supports USB->Serial (RS-232 type) and USB->I2C with some extra GPIO pins. They also supply an interface to their drivers on the PC, it comes as a DLL for managed (.NET) or C/C++ development. They also include a static library that you can link with your C/C++ program instead of using their DLL.

I also downloaded Microchip’s MPLABX IDE and XC8 C compiler for free. There are some limitations on the free version and it doesn’t do full optimization. I figured that by the time I ran into the limitations, I’d be far enough along to know whether or not I’d want to go further.

I’ve selected the PICF1454 MCU as my target device. It has a Master Synchronous Serial Port that supports either SPI or I2C; an Enhanced Universal Synchronous Asynchronous Receiver Transmitter that supports RS-232 type communications and last, but not least, a USB bus that supports low and full speed transfers with no need for a USB bridge.

So far, I’ve used only the I2C to the MCP2221 USB bridge to talk with my PC. I intend to write PC software that will use the MCP2221 library at first, then move on to direct USB on PC to USB on MCU communications.

It’s just a hobby for me now that I’m retired, but it’s still fun to learn new stuff.

[Red Squirrel]

The MCP2221 looks interesting, I might actually go with that.   I feel a bit dirty buying FTDI. 

Found it here:
http://www.digikey.ca/product-detail/en/microchip-technology/MCP2221-I%2FP/MCP2221-I%2FP-ND/4902585

I like that it's in dip as well.  It also does i2c and uart which is a bonus, as I want to play with i2c at some point anyway.

Think I'll get a couple to play with.   

Edit: Reading the datasheet it seems this is a USB Human Interface Device and not virtual serial port, or does it do serial port too? 

[Buriedcode]

Edit: Reading the datasheet it seems this is a USB Human Interface Device and not virtual serial port, or does it do serial port too? 

It does both as its a composite device.  The USB device will appear both as a virtual comm port for the UART, and as a HID for the I2c (and for configuration).  To me it looks like a PIC16F1455 with permanent firmware, and only ever-so-slightly more expensive (ie: probably worth it).  Apparently there's a flashing app from microchip that allows you to change boot-up config (the FTDI had a similar bit of software for their devices).

I'm fairly certain its a plug'n'play job with the serial port/uart.  As it claims to use native VCP drivers - which would set the baud, stopbits, parity etc.. just like any other USB-serial bridge.

[Red Squirrel]

Yeah reading on it further I realized that's what it is, i2c for the HID and UART for the serial.  I like it, as I do eventually want to play around with i2c and HID so I can use the same chip.   

Only thing with being fairly newb at electronics I find it's always hard to google for code examples, is there a good place or methodology on finding out how to code for these type of things in general?  I know C++ half decently, but just the thing of knowing the function/variable names etc... on how to do things.  Though I'll probably cheat and use Atmel MCU and Arduino libraries so I imagine I'll find lot of Arduino code.   But I do want to learn the non Arduino way eventually as it's probably good knowledge to have.

Or is it actually as simple as bit banging on the UART pins in the rs232 language? 

[MSO]

Red Squirrel,

"Or is it actually as simple as bit banging on the UART pins in the rs232 language?"

I've not used the serial port side of the MCP2221, but the data sent from the PC to the MCP2221 is seen by the MCU exactly as if it were talking to an another I2C master.  Just follow the I2C protocol and you're in business.

When the MCP2221 is plugged into the PC, you can go to the control panel->device manager->properties->Port Settings and modify the settings just as if it were a serial port. So all the MCU has to do is set up its UART with matching settings and then read/write the data from the UART's RX?TX registers. There is no real bit banging so to speak, other than managing the UART itself.

[MSO]

* Modern uc's have internal USB port. You can get better performance and more control on the data transfer when using uc USB device port as USB serial. This can in some cases be cheaper than uc + external converter. Beware that this needs the usb stack on the uc side and some vendors' stacks are terribly broken. Also, you need drivers on PC side. Microsoft has generic usb-serial class driver (usbser.sys), but until win10 it was not loaded as class driver and you had to provide inf file to bind it with your device. Linux and mac works with built-in drivers. The inf file needs to be signed or you'll get warnings for win7 and you can't load it on win8. Also, unless you can use the vendors' vid/pid (for some vendors, there are options), then you'll need your own and this is costly. So, the amount of work on this solution depends a lot of the uc vendor, it may be totally easy or real hell. On the plus side, throughput is higher and the device is identified automatically (still requires a lookup in win registry to determine com number for a given usb vid/pid).

dgtl,

I only quoted part of your post to save bandwidth, but wanted to thank you for taking the time to write the whole post. I found it very enlightening.

[Psi]

When you get the hardware sorted you will need to find/write some sort of serial communication system on the mcu and in the win/mac/lin app.

It can be as simple or as complex as you like but i recommend designing it for two-way comms, even if you think you only need 1way.

If you have no blocking functions in your main code that will make things easier, ie, no hard delays like delay(1000)

A good approach is to use the UART data ready interrupt and UART transmit complete interrupt.
Pick a start of frame marker and end of frame marker, eg, "STR"  "END"
Define 4 pointers to 4 arrays (they will need to be volatile)
Pointers - TXWrite  TXRead   RXWrite  RXRead
Arrays - TXArrayA TXArrayB  RXArrayA RXArrayB
(eg, naming convention  "TX array buffer for READING" = TXread)

This allows you to double buffer both the TX and RX directions. The interrupts work on two buffers and your normal code in main() works on the other two buffers. You can swap them around easily since they are just pointers. Which you do when you want to transfer data between "interrupt land" and "main land"

eg,
When you want to send a message your send() function stores the data into the TXWrite buffer and then swaps the pointers around (A and B). Then  enables the transmit complete interrupt and sends the first byte. The interrupt fires when this has been sent and it keeps sending out bytes one at a time from the TXRead buffer until complete. Then the interrupt disables itself.

When data arrives the data ready interrupt fires and starts populating the RXWrite buffer. As bytes come in it checks them for matching your start of frame marker (eg, "STR"). If you detect an invalid char then clear and start again since that indicates a bad packet or its out of sync.
When you reach the end of your packet you can compare any checksums you might have to make sure the packet is not corrupt and if all looks good swap the RXWrite RXRead buffers around. Its then ready to read the next packet into RXWrite right away even though RXRead hasn't been processed yet

In your main loop you are continuously checking for anything in RXRead buffer that is not zero. If you find something you process the packet (do whatever you want) and then clear it to zero.

[Red Squirrel]

I ended up ordering the MCP2221, can't wait to play with this chip.   

[link47]

Go with serial, and get an adapter for USB. Most microcontrollers have drivers pre-written for RS-232 and it is easy to get up and running.

Also, don't skimp on the RS-232 <-> USB adapter. Many give noise issues later in the life of the product.

We have had good luck with these. Get it, you will use it again and again.

http://www.mouser.com/ProductDetail/FTDI/USB-RS232-WE-1800-BT_00/?qs=KXh8wMBzxN%252b6nQ698XZ6xA%3D%3D

[Karel]

Go with serial, and get an adapter for USB. Most microcontrollers have drivers pre-written for RS-232 and it is easy to get up and running.

Also, don't skimp on the RS-232 <-> USB adapter. Many give noise issues later in the life of the product.

We have had good luck with these. Get it, you will use it again and again.

Assuming most uControllers run on 3.3V these days, and most people would like to skip the level-transverter, I advise this cable:

www.mouser.com/search/ProductDetail.aspx?R=0virtualkey0virtualkeyTTL-232R-RPI

It doesn't have the connections for the hardware flow control but usually you don't need that, specially when it's just for debugging.

[suicidaleggroll]

Go with serial, and get an adapter for USB. Most microcontrollers have drivers pre-written for RS-232 and it is easy to get up and running.

Also, don't skimp on the RS-232 <-> USB adapter. Many give noise issues later in the life of the product.

We have had good luck with these. Get it, you will use it again and again.

http://www.mouser.com/ProductDetail/FTDI/USB-RS232-WE-1800-BT_00/?qs=KXh8wMBzxN%252b6nQ698XZ6xA%3D%3D

No microcontrollers have RS232-level signaling, they use the same protocol but at TTL voltage levels.  The product linked by Karel will work for 3.3v devices, but I prefer the VIP version of the cable where you simply supply your I/O voltage, whatever it is (between 1.8-5v), on the red wire.  Works for any MCU running at any [normal] voltage level.
http://www.mouser.com/ProductDetail/FTDI/TTL-232RG-VIP-WE/?qs=%2fha2pyFadujx5k75gqjHkoYcPogD7SIlE6dZpulE3h4Uft8ZSATqhw%3d%3d

[free_electron]

Telepathically.

no wires needed and no mucking with RF voodoo...

[Rick Law]

It could be helpful if you do it a step at a time.  Divide the problem into hardware side and software side.

Google some codes for Arduino bit-banging for/with bluetooth (or easier would be an FTDI/CH340 USB-serial converter instead of bluetooth)  The CH340/FTDI based USB-Serial is rather easy to use.  The bit-bang code would work with either bluetooth or USB-Serial.

Once you get that working, you can replace the codes you found on the web with your own code.  Then you can replace the bluetooth/FTDI converter with a home made serial TTL->RS232 converter with a MAX232 chip or similar connecting to the same pins as with the bluetooth.  You can then connect to a real serial port with the max232 chip, or roll-your-own CH340/FTDI type solution, or really do a bluetooth HC5 or HC6 (simpler, slave only).

Good luck.