What Kind of Chip Can Be Used to Send Data from I2C Arduino Master to PC in C#?

[Potomac]

Note: please see picture attachment below. I sketched out what I'm talking about. It's very high resolution, so you can zoom in to see the details
-----------------------------------------------------------------------------------------------------


So another beginner question here. I've built an I2C slave board for collecting hardware sensor data. I've also built the prelimary GUI in C# and used simulated data in place of the real hardware sensor data. (See picture below)

Now I want to start using the real data in place of the simulated data. I've been told I will need a chip to act as intermediary interface between the master and the PC.  (This is the orange box in the picture attachment)

I have two questions:

1). Is this something like an FTDI chip? That's the first hit that comes up for "PC interface module." I don't think this is correct. Can someone educate me on this?

https://www.google.com/search?q=ftdi+chi%5B&ie=&oe=#q=pc+interface+module


2). Just to confirm, I should just be using the Arduino IDE to prototype the lower level C code on the Arduinos, and not to transfer data? I am right that the IDE would not be ideal for this sort of thing? It can serial print data of the screen but I don't think that can be passed through easily my GUI/data logger

many thanks in advance

let me know if I left any info out

[ebclr]

http://www.silabs.com/Support%20Documents/TechnicalDocs/CP2112.pdf




http://www.silabs.com/products/interface/Pages/CP2112EK.aspx

[Ian.M]

*MOST* models of Arduino either already have on-board USB <=> serial converters or can directly enumerate as a CDC class device that emulates a serial port to your sketch.   Although it is convenient to use the IDE's terminal for initial debugging, there is nothing to stop you writing PC side .NET code to talk to the serial device the Arduino presents itself as.

Therefore if you are already using Arduinos,  the only tough part is designing a protocol to handle I2C transactions over a serial interface.  The Arduinos with hardware interfaces dont have any handshake lines so a reliable protocol will need to do some sort of software handshaking.

[Potomac]

Thanks for the quick and thorough responses guys

Two more questions:

1). Just so we're on the same page, this chip would go between the IC2 masterand the computer, right? It wouldn't replace the master, right?  (I'm using an Arduino Pro Mini in that role, connected to 8 Pro Mini slaves)


2). There were a lot of recommendations here for off the shelf IC options. Which is the most foolproof for a beginner?  Which would you thing would get the job done fastest? (Taken from recs in this thread)

-Rasberry Pi
-Various FTDI
-Silabs CP2112EK   http://www.silabs.com/products/interface/Pages/CP2112EK.aspx
-Cypress CY8CKIT-042 BLE    http://www.digikey.com/product-detail/en/cypress-semiconductor-corp/CY8CKIT-059/428-3390-ND/5184557

evb recommended that I stay way from using the .NET framework on a chip since it will take a lot of time to set up. I agree I would want to stay away from that

[EBRAddict]

Maybe a USB adapter like this http://www.mouser.com/search/ProductDetail.aspx?R=0virtualkey0virtualkeyUMFT201XB-01

[Potomac]

I should mention that I already use this Sparkfun "FTDI Basic" to program all the Pro Minis and also receive data on the serial monitor from the master.

Can I not use this one to accomplish what I'm trying to do? Sorry for the supremely elementary question. 

https://www.sparkfun.com/products/9716

[testmode]

If I've understood your requirements correctly (I2C slave > I2C master > USB > your app in the PC), you would have to update your design to use a single chip to handle *both* the I2C master and USB interface (this will be your "PC interface module").

3 options that we've used in our systems for similar purposes are:

1) FTDI FT2232H
    - similar to what evb149 has suggested
2) Microchip MCP2221
    - a competing solution to the FT2232H
3) STM32 or <insert your favorite microcontroller here with USB support> with custom code to handle the I2C and USB interface
    - although I wouldn't recommend this route as it will require you to write both the microcontroller code and the driver for the PC...too much effort unless you have very specific requirements or want to be *in control* of the whole communication chain

If I would have to choose one, I would go for the FTDI FT2232H mainly for their good software/driver support. (the Cypress CY8CKIT-xxx solution that evb149 has suggested looks attractive too but I haven't tried it yet)

[rstofer]

I'm confused...  Are you keeping the Arduino or do you want it out of the project?

If you keep the Arduino, you already have a COM port and you should be able to read/write it from C#.  There are a number of samples via Google including some from Microsoft.

If you want to go from your PC app directly to I2C, look at this adapter:
http://www.ftdichip.com/Support/Documents/DataSheets/DLP/usb1232h-ds-v13.pdf

I have never looked at the API so you should do that to see if a) it will talk to your slave and b) you can interface it to C#.  I looked briefly through that datasheet and followed the yellow brick road.  There is sample code for C# (but I didn't look at it) and there is definitely C code for I2C.

[benSTmax]

Forget about FTDI ... There are much better solutions available ...

As I use a few MCP2221s on a daily basis, I think this chip is the best solution in this case
You have the USB-I2C interface with very good DLL and tools support.

• A windows GUI where you can exercise I2C commands and not only
• a command-line tool useful for command prompt usage
• Android and Java example applications along with their source code!!! - Try to get such a thing from FTDI 
• I2C bus kernel driver for Linux which works fine. I am using it with a regular PC so I can play with I2C slave boards/chips without having to program an MCU. No extra programming hassle. Just load the driver and you can play with the "i2c-tools" right away

And on top of all, you still have an additional USB-UART converter in the same package.

Take a look here:
http://www.microchip.com/wwwproducts/en/MCP2221

and here:
http://blog.flyingpic24.com/2015/09/22/usb-swiss-army-knife/

[Ian.M]

I'm confused...  Are you keeping the Arduino or do you want it out of the project?

If you keep the Arduino, you already have a COM port and you should be able to read/write it from C#.  There are a number of samples via Google including some from Microsoft.

1). Just so we're on the same page, this chip would go between the IC2 master and the computer, right? It wouldn't replace the master, right?  (I'm using an Arduino Pro Mini in that role, connected to 8 Pro Mini slaves)

I think that's fairly clear - he's got an Arduno Master, but as its a Pro Mini, it *DOESN'T* have on-board USB<=>serial.  He's got a FTDI FT232RL breakout board so has all he needs for connectivity for this project.

One *COULD* scrap the Arduino Master and write a PC master using an I2C capable USB UART from FTDI, Microchip or others, but its almost certainly easier simply to add serial command and control capability to the master and get the data logger software talking to it via the existing FT232RL breakout board, without needing any custom drivers or interface software PC side.

[benSTmax]

One *COULD* scrap the Arduino Master and write a PC master using an I2C capable USB UART from FTDI, Microchip or others, but its almost certainly easier simply to add serial command and control capability to the master and get the data logger software talking to it via the existing FT232RL breakout board, without needing any custom drivers or interface software PC side.

If the Arduino I2C master is not needed for other purposes then, I would better scrap it and put straight the MCP2221. I would save a lot of time and have the problem solved.

Looking at all the other solutions mentioned in this thread, there's some firmware or sort of PC development helper functions required to read or write the I2C bus.

I am advocating for the MCP2221 because the DLL has specific functions for I2C read or I2C write and that's all. No cumbersome firmware or protocol development needed.

Why wasting time re-inventing the wheel (by designing custom transport protocols over UART) when there's a solution already?

[Ian.M]

That very much depends on how easy it is to get the data logger software talking to the MCP2221 DLL, and whether or not the master has to be capable of hard realtime processing.  If the datalogger is to be entirely custom, and there is no hard realtime requirement, then yes, it makes sense, but if the datalogger is off-the-shelf software, it probably already supports serial comms, is unlikely to natively support MCP2221 chips and the learning curve for writing plugins for it for new interfaces is probably fairly steep.

There would be cost savings to be made for volume production by eliminating the Arduino master, but only the greenest of novices would design in nine Arduinos if intending volume production, so this is almost certainly a one-off or very low unit count project.

[rstofer]

That very much depends on how easy it is to get the data logger software talking to the MCP2221 DLL, and whether or not the master has to be capable of hard realtime processing.  If the datalogger is to be entirely custom, and there is no hard realtime requirement, then yes, it makes sense, but if the datalogger is off-the-shelf software, it probably already supports serial comms, is unlikely to natively support MCP2221 chips and the learning curve for writing plugins for it for new interfaces is probably fairly steep.

There is no possibility of getting hard real-time sampling with either Windows or Linux.  If that is a requirement, the sampling is best done elsewhere and just sent over a serial stream to the PC.

There would be cost savings to be made for volume production by eliminating the Arduino master, but only the greenest of novices would design in nine Arduinos if intending volume production, so this is almost certainly a one-off or very low unit count project.

I noticed that in the sample graphs, the time is in multiples of seconds with no indication of the sample rate.  More info about the application would probably be helpful.

[Potomac]

To reiterate, yes, I have a Pro Mini Master and 8 Pro Mini slaves. This is NOT meant for production. It's a test board.

The samples will be taken every 15 seconds to or so.



So it seems from the most recent posts that I should either stick with my current FTDI breakout board (that will be able to get the data to the PC app just fine) or get a MCP2221 breakout board   http://blog.flyingpic24.com/2015/09/22/usb-swiss-army-knife/

I am leaning towards what Ian.M says because I won't need any custom drivers

I'm confused...  Are you keeping the Arduino or do you want it out of the project?

If you keep the Arduino, you already have a COM port and you should be able to read/write it from C#.  There are a number of samples via Google including some from Microsoft.

1). Just so we're on the same page, this chip would go between the IC2 master and the computer, right? It wouldn't replace the master, right?  (I'm using an Arduino Pro Mini in that role, connected to 8 Pro Mini slaves)

I think that's fairly clear - he's got an Arduno Master, but as its a Pro Mini, it *DOESN'T* have on-board USB<=>serial.  He's got a FTDI FT232RL breakout board so has all he needs for connectivity for this project.

One *COULD* scrap the Arduino Master and write a PC master using an I2C capable USB UART from FTDI, Microchip or others, but its almost certainly easier simply to add serial command and control capability to the master and get the data logger software talking to it via the existing FT232RL breakout board, without needing any custom drivers or interface software PC side.

[Buriedcode]

Well, if you already have the Arduino for I2C master, and others have already suggested serial-USB adapter (be it FTDI, microchip, cypress etc..) then a third option would be an Arduino Pro micro. 

Its pretty much the same as the pro-mini, but uses an Atmega32u4 instead of the '328 - many of the Arduino libraries work with it, and it has native USB support.  This means you can either just its USB as a virtual com port - very simple for .NET to get bytes from, but you'll still have to open the port and deal with port numbers.  Or... it also has ready-made libraries for custom USB devices, CDC, HID etc.. (think keyboard, mouse, or a generic HID).  If using it as a serial port, it does that right off the bat, you just write your data to 'serial' (the hardware serial UART is serial1).

So this means one small board, directly to your PC, and you can decide if you want to communicate with it directly.  If you just use what code you have, with minor changes to pinout, you'll just have to write your host code for serial.

I'm pretty taken with it, despite shunning the 'Arduino' for many years - you can make a data logger for testing in a few minutes, or a keyboard emulator, again literally in a few minutes, and you don't' have to worry about any reliability issues with FTDI if you just so happen to have a fake FTDI chip.

[macboy]

...
2). Just to confirm, I should just be using the Arduino IDE to prototype the lower level C code on the Arduinos, and not to transfer data? I am right that the IDE would not be ideal for this sort of thing? It can serial print data of the screen but I don't think that can be passed through easily my GUI/data logger

many thanks in advance

let me know if I left any info out

The Arduino board contains a USB-to-serial converter chip. On your computer, this shows up as a COM port (serial port). The Arduino IDE communicates with the Arduino board using this COM port, both for uploading your code and to provide a debug console when your code is running.

You absolutely can and should use this COM port in your custom application. All you need to do is open the COM port in your application and start sending/receiving data (make sure to close the Arduino IDE first, or it will likely already have that COM port open, preventing any other program from opening it). Communicating over a COM port can be very simple. You should think of it as a byte stream. You will need to format your data in a way that makes it easy to parse, or you could implement some kind of request/response protocol, where your app sends a request for a specific piece of data, then only that data is returned. Probably the easiest way to do it is to send the data as ASCII text, rather than binary, since this is also what you do when you print data to the serial console for debugging. So when you send the number 100, it is the three bytes 49, 48, 48, which represent the ASCII characters "1", "0", and "0". The serial.print() function does conversion to ASCII automatically for you. The easiest way to format the data would be to assign some name to each sensor then send name:value pairs. E.g. assume you have three temperature sensors. You could send "temp1:22 temp2:26 temp3:58". Your app would wait for a space then parse the string as a name:value pair, then wait for the next value. There are APIs in C# to convert a string (e.g. "22") into a number, as well as other parsing functionality that you need. All that conversion to ASCII and back isn't especially efficient but it makes the protocol human-readable which can be very handy when there are issues to debug.