-
So, I am looking for a way to access SPI or I2C slave devices from the PC using "serial port" explicitly with virtual COM port drivers. But I have to do so without using any programmable devices (neither micros nor FPGA/CPLD are allowed).
This basically forces me to use some sort of USB to UART bridge, for which Virtual Com Port drivers are readily available (like from FTDI, SiLabs or Microchip) which I would then need to translate to SPI or to I2C.
I have only found a single device capable to do this, namely the SC18IM704 from NXP. But apart from that.... nothing.
Are there any other devices like that that you know of?
I can find quite a large number of SPI/I2C to UART bridges, which are slaves on the SPI/I2C interface, but only the above mentioned one which can be master. Also, there's quite a number of software based solution which I could employ, on various microcontrollers or FPGAs, only if firmware would not be excluded from this endeavor.
I am also aware of the existence of various direct USB-to-SPI or USB-to-I2C converters, but unfortunatelly these do not operate with Virtual Com Port Drivers.
Is this such a narrow niche...?
Regards,
Cristian -
why do you insist on using virtual COM port drivers?
-
Yes, because most people wanting to do this don't have a "no programmable devices" limitation.
Is this such a narrow niche...?
Some of the FTDI devices have a serial engine that can be configured to do SPI.
-
Yes, because most people wanting to do this don't have a "no programmable devices" limitation.
Is this such a narrow niche...?
Some of the FTDI devices have a serial engine that can be configured to do SPI.
and if you don't need speed they can all do it with bit banging, but that's using the ftdi direct driver, not virtual com port
-
Quote
why do you insist on using virtual COM port drivers?
This requirement/limitation comes from the intended users of the end device: they already have vast code base with Virtual Com Port and are unwilling to change to other methods. Unfortunately, I cannot influence that.QuoteSome of the FTDI devices have a serial engine that can be configured to do SPI.
I am familiar with those, but unfortunatelly they cannot operate in that mode using the VCP drivers; we would need to use the D2XX dll based method of controlling them and that is not accepted by the stakeholders.Quotebut that's using the ftdi direct driver, not virtual com port
Precisely. And that is not acceptable.
Regards,
Cristian
-
Quote
why do you insist on using virtual COM port drivers?
This requirement/limitation comes from the intended users of the end device: they already have vast code base with Virtual Com Port and are unwilling to change to other methods. Unfortunately, I cannot influence that.QuoteSome of the FTDI devices have a serial engine that can be configured to do SPI.
I am familiar with those, but unfortunatelly they cannot operate in that mode using the VCP drivers; we would need to use the D2XX dll based method of controlling them and that is not accepted by the stakeholders.Quotebut that's using the ftdi direct driver, not virtual com port
Precisely. And that is not acceptable.
Regards,
Cristian
why is a programmable device out of the question? I'm sure quite few USB to uart devices are actually MCUs
if you really want to get creative, make a program that pretends to be a comport on one side and does the DXX magic on the other side
-
Quote
make a program that pretends to be a comport on one side and does the DXX magic on the other side
This was actually discussed as a potential option, but ruled out eventually. The existence of this additional layer is veto-ed by the end users, due to maintenance, reliability etc. No, they want to use a proven and established COM port driver, from a reputable provider. And I can understand and accept that. As a fall-back solution, the SC18IM704 from NXP does what we want, but it is so...single source like. And I mean not even a "principle" function equivalent device exists out there (even with different footprint or somewhat different operation). None.
One other idea is to place the SN74LV8153, which has a weird but UART compatible interface. And go through all the trouble to bit-bang SPI data through it. But even this one looks like a "single of its kind" type of thing.
Regards,
Cristian -
Quote
make a program that pretends to be a comport on one side and does the DXX magic on the other side
This was actually discussed as a potential option, but ruled out eventually. The existence of this additional layer is veto-ed by the end users, due to maintenance, reliability etc. No, they want to use a proven and established COM port driver, from a reputable provider. And I can understand and accept that. As a fall-back solution, the SC18IM704 from NXP does what we want, but it is so...single source like. And I mean not even a "principle" function equivalent device exists out there (even with different footprint or somewhat different operation). None.
One other idea is to place the SN74LV8153, which has a weird but UART compatible interface. And go through all the trouble to bit-bang SPI data through it. But even this one looks like a "single of its kind" type of thing.
Regards,
Cristian
sounds like they don't want a solution
-
Quote
sounds like they don't want a solution
It is legitimate to consider that we are on a look-out for a non-optimal system level solution, I agree that. But it is a constraint I cannot change and I have to work with that: no software, no programmable devices. Solutions do exist (as I have previously mentioned the NXP SC18IM704 or the TI SN74LV8153). It's just that I am somewhat uncomfortable with the narrowness of the purely non-programmable hardware options and I started this thread to maybe get more options pointed to me.
Regards,
Cristian -
Quote
sounds like they don't want a solution
It is legitimate to consider that we are on a look-out for a non-optimal system level solution, I agree that. But it is a constraint I cannot change and I have to work with that: no software, no programmable devices. Solutions do exist (as I have previously mentioned the NXP SC18IM704 or the TI SN74LV8153). It's just that I am somewhat uncomfortable with the narrowness of the purely non-programmable hardware options and I started this thread to maybe get more options pointed to me.
Regards,
Cristian
I mean, if a software solution is out, a programmable device is out, the narrowness of the purely non-programmable hardware it out, single source is out, then there isn't really anything left
-
Quote
the narrowness of the purely non-programmable hardware it out, single source is out,
These two are not really blocking criteria. I was just hoping to get here some suggestions that would widen a bit the options.
Regards,
Cristian -
MCP2221
https://www.microchip.com/en-us/product/mcp2221
I2C = https://www.digikey.com/en/products/detail/microchip-technology/MCP2221A-I-ML/6009295
SPI = https://www.microchip.com/en-us/product/MCP2210
The UART doesn't go directly to the I2C, but it's a simple driver for USB->I2C. No circuit board side programming required. I use these for test fixtures all the time. -
MCP2221
https://www.microchip.com/en-us/product/mcp2221
I2C = https://www.digikey.com/en/products/detail/microchip-technology/MCP2221A-I-ML/6009295
SPI = https://www.microchip.com/en-us/product/MCP2210
The UART doesn't go directly to the I2C, but it's a simple driver for USB->I2C. No circuit board side programming required. I use these for test fixtures all the time.
but when used for SPI/I2C they don't work like virtual com ports
-
Yes, I am acquainted with the Microchip parts, but they are using the HID class when operated as converters to I2C. This would violate the fundamental requirement I have here, that of using Virtual Com Port from a computer perspective.
-
Yes, I am acquainted with the Microchip parts, but they are using the HID class when operated as converters to I2C. This would violate the fundamental requirement I have here, that of using Virtual Com Port from a computer perspective.
Have a PC side program that has a command terminal interface that emulates a COM port that then uses the HID to talk to the I2C. -
For SPI, search pypi.org for SpiAdapter and SpiDriver.
For I2C, search pypi.org for I2cAdapter and i2cDriver.
They have python packages available and they use serial COM protocol that doesn't require special OS drivers.
-
For SPI, search pypi.org for SpiAdapter and SpiDriver.
For I2C, search pypi.org for I2cAdapter and i2cDriver.
They have python packages available and they use serial COM protocol that doesn't require special OS drivers.
I2cAdapter uses programmable hardware (Raspberry Pico) that already been ruled out, i2cDriver uses software that's already been ruled out
-
So, I am looking for a way to access SPI or I2C slave devices from the PC using "serial port" explicitly with virtual COM port drivers. But I have to do so without using any programmable devices (neither micros nor FPGA/CPLD are allowed).
This basically forces me to use some sort of USB to UART bridge, for which Virtual Com Port drivers are readily available (like from FTDI, SiLabs or Microchip) which I would then need to translate to SPI or to I2C.
I have only found a single device capable to do this, namely the SC18IM704 from NXP. But apart from that.... nothing.
Are there any other devices like that that you know of?
...
Is this such a narrow niche...?
That paints you into the corner of a pre-programmed part using an ASCII command set to expand the UART so it can manage the extra state engine of i2c.
You should feel lucky you have found anything 'ready to go'
The NXP SC18IM704 part has a quite recent data sheet, looks quite good, and you can buy modules using it, so why not use that ?
Looks to be based on the LPC802M001JDH16 family. It needs a 3.3V supply, but claims 5V tolerant pins.
How many do you need ?
There were parts for UART => i2c that were programmed PICs that you could buy already programmed (mostly DIP?), but a quick search cannot find them.
Addit: No, wait... found it.
Similar commands to NXP, but a superset, with more features. Four separate I2C busses, SPI, Dallas 1 Wire Needs 14.7456MHz crystal, so has precise BAUD rates.
https://www.i2cchip.com/shop.html
DIP and a SMD (SO18W) version comes in tubes of 50, ready to go. SSOP20 available on order.
-
Well, yes, currently the NXP SC18IM704 is the tentative way to go.Quote
Addit: No, wait... found it.
Similar commands to NXP, but a superset, with more features. Four separate I2C busses, SPI, Dallas 1 Wire Needs 14.7456MHz crystal, so has precise BAUD rates.
https://www.i2cchip.com/shop.html
But the link you provided seems intriguing... How do you know it is a pre-programmed PIC behind their BL233 ic name? They do not seem to explicitly mention it.
Regards,
Cristian -
But the link you provided seems intriguing... How do you know it is a pre-programmed PIC behind their BL233 ic name? They do not seem to explicitly mention it.
The 18 pin package is a massive clue, just like the NXP part is a MCU programmed, the volume of these parts is too low to make anything fully custom.
If you are using modest volume of these in the medium term, I'd suggest trialing both.
If you are a little more adventurous, I think this may be the upstream code for the NXP part.
https://os.mbed.com/users/k4zuki/code/uart_i2c_conv/file/9d12c615c8ea/main.cpp/
https://github.com/K4zuki/tinyI2C/tree/master
Suppliers like Digikey can program parts, for a fee, so that may be almost 'no programming', you can treat the hex file you send Digikey as a large order number
-
They don't offer this service outside the USA, apparently because you might be sending them export-controlled encryption code to program into your tiny micro. Seriously.
Suppliers like Digikey can program parts, for a fee, so that may be almost 'no programming', you can treat the hex file you send Digikey as a large order number -
Hi everyone. UART to I2C master devices:
NXP SC18IM700 was tested 10 years ago, and found a regulary nice, but poor performing device:
Settings cannot be saved on EEPROM
Undocumented message transaction performance
Weird GPIO messages processing
Under stress, the device can crash
For all these reasons, we turned to BL233
I've dealing with BL233 (https://i2cchip.com) B and C versions for 10 years. Althrough it's a device with impresive capabilities and afordable price (SO-18 version available!), the company is unresponsive since four mounths ago (please, if someone get in touch, let me know).
After this issue, we turned our eyes (again) to NXP SC18IM704, a modern replacement for SC18IM700.
Nowadays evaluating SC18IM704 (firmware 1.0.2) : the SC18IM700 was far more reliable. Please, take a look at NXP support forums about this device before expend hours (you'll see a pair of post from my own), to figure out. We're expecting a new firmware, released by NXP as requested samples.
Zilog has also this kind of device, but website is offline.
Horter has a I2C modem https://www.horter-shop.de/de/102-i2c-pc-adapter a pricey device
Last but not least, you ca relay on a TI MCU with firmware, provided by TI https://www.ti.com/lit/pdf/spradd0
This is a very good howto about this kind of devices: https://www.ti.com/lit/an/slaa908/slaa908.pdf?ts=1591284148014
Hoping been userful. I'll keep on searching...
-
Question: What quantities are you guys talking about... I mean seriously, if it's decent volume I'll buy a chip programmer/re-reeler right now and sell you pre-programmed micros with whatever functionality you want.
-
Question: What quantities are you guys talking about... I mean seriously, if it's decent volume I'll buy a chip programmer/re-reeler right now and sell you pre-programmed micros with whatever functionality you want.
No need - use a Microchip device and they'll program and re-reel it for a few cents -
Question: What quantities are you guys talking about... I mean seriously, if it's decent volume I'll buy a chip programmer/re-reeler right now and sell you pre-programmed micros with whatever functionality you want.
No need - use a Microchip device and they'll program and re-reel it for a few cents
shhhhh!!! you are ruining my new business!