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

[Red Squirrel]

Say I want to communicate with an atmel or pic based micro project using C++ within a computer what is the easiest way to achieve this?  I'm thinking some form of either USB or RS232 serial.  Since most computers don't have RS232 ports some form of USB emulated serial port is probably the best bet. 

Just wondering what solutions are available, either chips that I can bit bang to and they translate, or tutorials on how to bit bang it directly.  I'm helping someone with an electronics project and he is using a Pic, I've only really worked with arduino as far as interfacing projects with a PC, but I want to learn how to do it without so it will be a learning experience for me too.   Essentially I just want to be able to read sensor values and also alter digital pin values from a computer program that I will write.

I briefly heard about FDTI chips that do just this, is that basically all I need?  What kind of language do I use to talk to it from the micro, is it literally just big banging the ascii values of serial or is there more to it than that?    I'll probably play with it with an atmel chip at home as I have a bunch, but idealy I'll want it to work on a pic too.  I told him to do research for that and let me know what he comes up with but figured I'd check too what is involved, as I'll probably end up helping him code the actual PC portion of the program but still need to get a general idea of how the micro will talk with the PC first.   

[westfw]

I briefly heard about FDTI chips that do just this, is that basically all I need?

Yep.  The Micro sees an async serial port, and can implement that using either bit-banging, or using a hardware UART peripheral (most micros have hardware UARTs these days.)
The PC-side application also sees a COM port, and writes software as if it were an ordinary serial port.  The PC USB stack and the FTDI chip (or equivalent) invisibly do all of the USB magic in between the two "ends" of the serial interface.

[Howardlong]

RS232 is still the easiest way with commonly available interfaces available although not at standard RS232 voltage levels, do it directly at logic levels. I use them extensively for debugging, either for command line entry in Linux based devices or for debug metrics in more bare metal designs.

If you don't already have a logic level (or "TTL") USB to serial converter, get one! Note that some are 3.3V and others are 5V logic levels, so take care to get the right one for your application.

Also note that due to extensive cloning of chips, make sure you get a kosher device, or it might not work. Even some kosher devices based on older Prolific chips won't work on later versions of Windows. FTDI inspired counterfeit clones also have a history of being rendered useless.

How do you know if it's kosher? It's not always easy, but you do stand a better chance by purchasing from well established local suppliers than going direct to China.

[Red Squirrel]

Actually what exactly is a UART, I can't seem to find a definitive answer when I search, I thought it was just a fancy name for the I/O pins on the micro but is it something else?

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? 

http://www.digikey.ca/product-detail/en/ftdi-future-technology-devices-international-ltd/FT230XS-R/768-1135-1-ND/3029155

Are there any good tutorials or libraries on communicating using these chips?  Ex: sending/receiving strings of text. 

Also do I need to isolate the USB from the micro (assuming the micro has it's own power source), or as long as I combine the grounds I'm good?  Trying to keep this simple, but I guess I could use opto isolators.

I have a few of my own projects I want to eventually start on so the idea of adding USB/serial support cheaply so I can connect a laptop and terminal app to get a custom admin interface that I code sounds very awesome.

As for ensuring I get the genuine part, are places like Digikey and Mouser a safe bet or can duds end up on those sites too?    I sometimes order parts off Amazon but typically I try to stick to Digikey as amazon, Ebay etc can be sketchy.  Depends on the part I want really.  Stuff like LEDs or resistors or capacitors I might get "packs" for cheap knowing they're probably garbage but I'm probably going to blow them up anyway.   

[Red Squirrel]

Oh ok so UART is basically just a built in serial interface for RS232?  So kinda like a dedicated i2c and so on.  Yeah I'd probably want to use that if available.

So the chip I posted should do what I want right? Or is there a better one to pick?  Idealy I'd like through hole but not sure if there are any.   Idea is if I add these to my own projects I'd probably just have a USB square plug like for a printer.

[nctnico]

I'd try to avoid the readily made FTDI based UART / USB board due to the high chance you end up with a cloned FTDI device. CP210x based UART/USB converters are a safe bet (and also slightly more stable than the FTDI chip).

[Red Squirrel]

Good to know, think I'll go with that chip then, I like the idea of leaving a permanent USB interface on any project I might make.  I can either have it in there for configuration or debug info or what not.  Or download information... depending what the project is.

Once I am more versed into playing with MCUs I might look into true USB as well but serial is good enough for any needs I can think of and much easier to work with at the computer end too.

[SL4P]

It sounds like you are running away from non-existent shadows.

If you have Arduino experience as mentioned in your OP - then you have already used the 'USB serial' interface.
After uploading the 'sketch', the Arduino interface becomes the default serial port (Serial.) used with the serial monitor, or your previous PC <--> Arduino experiments.

Nothing else to do.
All you're doing for the free-standing PIC solution, is ensuring there is a physical connection and appropriate interface - in the same way as the AVR chip. There are many ways to implement both, all trivial.

[nctnico]

I think what is confusing the OP is that a UART isn't always called a UART but it can also be called a serial interface, asynchronous serial interface or acronyms like SCPI, etc, etc. It takes reading the datasheet and user manual carefully to determine whether a microcontroller actually has an asynchronous serial interface.

[exe]

I bought bluetooth-serial adapter and so far I'm happy with it, though initial setup was a pain.

[Howardlong]

I'd try to avoid the readily made FTDI based UART / USB board due to the high chance you end up with a cloned FTDI device. CP210x based UART/USB converters are a safe bet (and also slightly more stable than the FTDI chip).

It's interesting that because there is a risk of FTDI's own drivers bricking a device, that we're now steering clear of any FTDI serial device because there's no way of knowing it's conterfeit or not until it's sitting on your desk plugged in.

[Karel]

I'd try to avoid the readily made FTDI based UART / USB board due to the high chance you end up with a cloned FTDI device. CP210x based UART/USB converters are a safe bet (and also slightly more stable than the FTDI chip).

The change that you end up with a clone chip is very low. Just don't buy it from some cheap/shady places and you'll be fine.
FTDI has a very good reputation for USB/serial converters and, at least in my experience, they provide the most stable drivers.
Personally, I wouldn't buy anything else than FTDI for USB <-> serial.

At least with Linux, we had some strange issues with Silab based converters that caused the converter responseless and we had
to disconnect and connect the device again. With FTDI based chips, we never had any issues.

[nctnico]

I'd try to avoid the readily made FTDI based UART / USB board due to the high chance you end up with a cloned FTDI device. CP210x based UART/USB converters are a safe bet (and also slightly more stable than the FTDI chip).

The change that you end up with a clone chip is very low. Just don't buy it from some cheap/shady places and you'll be fine.

The latter is the problem. A USB to TTL UART converter board (bare PCB without housing) isn't a high priced product so chances are high they originate somewhere/somehow from China. The last time I ordered some RS485 boards from China they all had fake FTDI chips. One of my customers had a bunch of proprietary USB/serial port boards made in China and those also contained fake FTDI chips. So you are left with two choices: pay $30 to $40 for a board from a local source with (hopefully) a real FTDI chip or pay less than $2 including shipping for a USB-UART board based on a Silabs chip:
www.ebay.com/itm/6Pin-USB-2-0-to-TTL-UART-Module-Serial-Converter-CP2102-STC-Replace-Ft232-Module-/400565980256
Note how it is advertised as a FT232 replacement 

[Red Squirrel]

It sounds like you are running away from non-existent shadows.

If you have Arduino experience as mentioned in your OP - then you have already used the 'USB serial' interface.
After uploading the 'sketch', the Arduino interface becomes the default serial port (Serial.) used with the serial monitor, or your previous PC <--> Arduino experiments.

Nothing else to do.
All you're doing for the free-standing PIC solution, is ensuring there is a physical connection and appropriate interface - in the same way as the AVR chip. There are many ways to implement both, all trivial.

I know I can just use an Arduino and call it a day I've done it before, but I just want to learn how to do it "manually" so to speak, and if I decide to make a project where I want it to have built in USB it's much cheaper than using an Arduino each time.  Though I do kinda cheat and use the Arduino libraries and just burn the Arduino project directly on the Atmel chip.   But it's still a stand alone setup at the end.   

As for the source for the chip I'll stick to Digikey to be safe.   I also imagine the Linux driver is written by Linux community so it probably does not have that issue where it bricks the chips, hopefully.

[SuzyC]

IMHO the easiest, most quick, no HW to buy, simplist and so the cheapest and most reliable way for a PC to communicate with the outside world using languages such as C or VB is to use the parallel port.
(If you are fortunate enough to have an older XP Windows PC around with a motherboard that has a parallel port.)

All it takes is Porttalk22 (attached.) and works with Windows XP very well, and there also exists .dlls that unlock the parallel port in windows, such as inpout32.dll and inpout64.dll  that support windows 7 in 32-bit and 64-bit as well.

Then, bit-banging is just a matter of using simple statements something like Out() or Inp() in your programs.

[retrolefty]

I bought bluetooth-serial adapter and so far I'm happy with it, though initial setup was a pain.

 Adafruit sells a bluetooth serial converter module that has the same pin out as the popular FTDI adapters including emulation for the DTR comm signal (that arduino use to reset and activate a bootloader). It's baudrate transparent and requires no setup from the micro. But of course it costs more but truly a 'universal solution'  for PC<>micro communications applications, especially if you desire or need DC isolation.

https://www.adafruit.com/products/1588

[dannyf]

but I just want to learn how to do it "manually" so to speak,

Your Arudino environment / boards have all you need to do it "manually".

[Karel]

I'd try to avoid the readily made FTDI based UART / USB board due to the high chance you end up with a cloned FTDI device. CP210x based UART/USB converters are a safe bet (and also slightly more stable than the FTDI chip).

The change that you end up with a clone chip is very low. Just don't buy it from some cheap/shady places and you'll be fine.

... The last time I ordered some RS485 boards from China ...

You'll get what you pay for. Just don't buy cheap shit from China.

The op doesn't need rs485.

This cable will work just fine: http://www.newark.com/ftdi/us232r-100/cable-usb-to-rs232-serial-converter/dp/34M8933

[Karel]

IMHO the easiest, most quick, no HW to buy, simplist and so the cheapest and most reliable way for a PC to communicate with the outside world using languages such as C or VB is to use the parallel port.
(If you are fortunate enough to have an older XP Windows PC around with a motherboard that has a parallel port.)

All it takes is Porttalk22 (attached.) and works with Windows XP very well, and there also exists .dlls that unlock the parallel port in windows, such as inpout32.dll and inpout64.dll  that support windows 7 in 32-bit and 64-bit as well.

Then, bit-banging is just a matter of using simple statements something like Out() or Inp() in your programs.

Nope, it isn't. The easiest way is to use the serial port (or a usb to serial converter cable) and this library:

http://www.teuniz.net/RS-232/

No need for an old pc, no need for an (old) windows os, no need to do some silly bit-banging.

[Buriedcode]

Whilst many have covered the hardware needed - I too think a USB-serial bridge is the easiest way to get data between a PC and micro - it isn't all rosey.  The PC-side software for the serial port can be a bit buggy depending on what you're doing, and what API's libraries you use.  In .NET (the nice easy-to-use managed code) environment, the serial port can be buggy.  Its fine for small strings, but for long runs, continuous data or anything approaching 'high speed' it can easily drop bytes.  I ended up having to abandon most of the routines provided and read from the buffer directly with a timer on a different thread.

If you're just sending and receiving control data (occasional packets) its fine.  Not trying to scare you off, but it trips up a lot of people.

[SuzyC]

Karel..
There is nothing simple or easy or inexpensive in cost or time about your suggestion.

There is nothing simple about needing to be experienced in GCC/Linux/Unix programming to just do what the op asked to do.

There is nothing simple about going through the hundreds of options and compile options to just bit-bang to an external port.

The parallel port solution only requires only a few lines of code to make  it work with C, C++ or Visual Basic.

There is no hardware to buy.

Parallel port supports handshaking, has several handshaking pins useful for handshaking protocol.

Parallel ports feature open-collector outputs and can interface directly to 3.3V or 5V logic level systems.

[nctnico]

Karel..
There is nothing simple or easy or inexpensive in cost or time about your suggestion.

There is nothing simple about needing to be experienced in GCC/Linux/Unix programming to just do what the op asked to do.

There is nothing simple about going through the hundreds of options and compile options to just bit-bang to an external port.

The parallel port solution only requires only a few lines of code to make  it work with C, C++ or Visual Basic.

There is no hardware to buy.

Parallel port supports handshaking, has several handshaking pins useful for handshaking protocol.

Parallel ports feature open-collector outputs and can interface directly to 3.3V or 5V logic level systems.

I think you mean by parallel port some kind of I/O interface? Printer ports don't have open collector outputs and modern PCs don't have printer ports for over a decade.

Still a serial port is very standard and a USB-UART interface can be bought for less than $2. There are tons of libraries out there to use a serial port in your own PC software in whatever language you want. If one library doesn't work then hop on to another and don't look back.

[Monkeh]

There is no hardware to buy.

Sorry, uhm, I just looked at every computer I use on a daily basis. I can't find one of these parallel port things anywhere. Do you happen to know what year they were introduced? My machines aren't the newest, so maybe they're a little out of date..

[SuzyC]

There is no doubt that the PC Parallel Port is now "legacy", but this can also mean easy access to a mountain of  free used PC's and this can be an advantage in finding an easy, low-cost(likely no-cost) solution for hardware interfacing an external world circuit or MCU to a PC.

Such a machine can be used for programming, debugging MCU's, machine control, home automation, factory custom automation, to name a few applications.

In a third-world environment, such PC's control solar power, manufacturing assembly lines, etc., with the lowest possible cost and complexity.

The main 8-bit parallel data port is 5V TTL in/out, but the control handshake lines are open-collector.

To interface with 5V MCU's the parallel port provides a super stable, fast bi-directional 8-bit interface with handshake lines.


I should have said:

Parallel ports control ports feature open-collector outputs and can interface directly to 3.3V or 5V logic level systems.

Just using the control port pins allows assigning one of the pins as Clk and another as Data and by using other Control Port pins for handshaking, it is easy enough to just create your own custom fast serial channel interface to/from a target MCU.


If you Wikipedia Parallel Port:

For electronics hobbyists the parallel port is still often the easiest way to connect to an external circuit board. It is faster than the other common legacy port (serial port) and requires no serial-to-parallel converter, and requires far less interface logic and software than a USB target interface. However, Microsoft operating systems later than Windows 95/98 prevent user programs from directly writing to or reading from the LPT without additional software (kernel extensions).[9] Current CNC Milling Machines also often make use of the parallel port to directly control the machine's motors and attachments.

There is no need to fiddle around with bogus FTDI boards and shuffle through the FTDI website to only find that some drivers don't work.  I have provided these already to anyone interested and they have been tested and do work.

[David_AVD]

Recommending the parallel port for data i/o these days is nuts.  How many people have a PC with a parallel port on it?  Windows XP is also rapidly losing share and is no longer supported by most vendors.

Buying a genuine FTDI (or whatever brand you like) USB-TTL adapter is easy and not as expensive as you may think.  FTDI have PC drivers and code examples on their web site.  I'm sure the other vendors do too.

[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.