I tried to get a Serial-USB-Converter working on my ChipworkX-System. I tried my FTDI-Converter without any problems (thats a real Serial-USB-Converter).
Afterwards I tried to use a device (optical interface to a Smart Meter and a RS485 converter with the same chip) to get it working with my board - but it does not work. The devices have a “Silicon Labs CP210x USB to UART Bridge”-Chip inside. The PC knows it as this type and offers a COM-Port. I tried sending/receiving with PC without any Problems (300 Baud, 7 databits, 1 Stopbit, Even Parity, No Handshake).
After connecting the SiLabs-Device to the ChipworkX and tried sending with the same method as the FTDI-Chip, but an other device (the device is added the same way as in the sample at GHI Librabry Documentation). But this does not work! I can see, that the optical device is sending some data (infrared is sent), but I do not get data at the other device.
What could that be? Is there a problem with the baudrate (300) using SiLabs? Does it not work with the choosen settings? I don’t know what to try next to get it working…
I assume you’re using this converter as a USB Host connected device. Did you check the library API notes? There’s a specific example that talks about Silabs devices - it is not always presented as a serial endpoint, so there’s an example of forcing it to connect.
I know, I “force” it to be a SiLabs device after Checking VID and PID! Thats no problem. It also sends something out (I see infrared LED flashing in webcam), but I don’t know what!
Is there a possibility to test that? I have got not the equipement. Our is it a possibility that somebody looks at the code if there is anything wrong with sending at 300 Baud? I’ve tried various things, but do not get the SiLabs device running. I need to send at 300 Baud, because the Smart Meter does not react on other Speeds.
You could perhaps jumper TTL UART signals into the other side of the UART, avoiding the USB Host functionality. I don’t know whether UART at 300baud is more robust or more tested than the software side of things, but at least the requirement for it to be working is put back to the chip maker, not the netmf layer.
Hmm I’m sorry, I do not understand what you mean. I have to use the USB-device, because its a out-of-the-box-optical and out-of-the-box rs485 interface with a USB-connector. So using the COM-Port of ChipworkX is not possible.
Or is my english just too bad and I don’t understand?
The Silabs chip sits in the USB device. On one side of that chip is the USB connection. On the other side of that chip is a TTL UART connection. You could break open the device, and solder jumper wires directly onto the TTL UART side of the chip, essentially bypassing it. Those wires then connect to a UART of your ChipworX.
I’m sure it’s possible. It’s not necessarily nice, but it is possible.
USB connection <–> Silabs USB-to-UART chip <–> split to RS485 and optical connector (whatever they are)
All you would be doing is bypassing the USB connection and the Silabs chip, you are still using everything else.
Again, whether this then allows you to use a “more tested” code or not I can’t answer, but it does bypass the USB Host code and go back to using a UART on the processor (which is typically more tested because the vendor wouldn’t offer it as an option if they didn’t test it)
Personal thought here: the best way you can test this is to get a pair of Silabs USB-to-RS232 devices that use the same chip and connect one to your PC and one to your CwX, and set them up to use 300 baud. There aren’t many devices these days that talk at 300 baud. Is it possible that the default baud rate can be increased?
Actually, can you elaborate on the other pieces of the USB cable, specifically the UART-to-optical and UART-to-RS485 portion of it? Perhaps you could design your own?
And while we’re at it, can you show us a sample code of how you set up the connection? I have a couple of CP2102 devices coming in the post so when they arrive I may have a way to reproduce this (no CwX but plenty of other Fezzez)
ok, I quickly looked at your code and it looks to me at first glance as virtually identical to the sample in the SDK doco. So that’s helpful to know, but I can be no more benefit to you sorry
What is interesting is that the same code works for FTDI; What is the reason you can’t use that cable? Does it only do one portion of your system?
Its the requirement to read Smart Meter with RS232 (for this the FTDI is used), with RS485 (Silabs…) and optical (Silabs…). And the devices for RS485 and optical are implemented with this silabs-ICs (unfortunately). I have to use this devices. So I will look at the traffic with a DSO tomorrow in the Lab (or today, here it is 2 AM :))
I hope I’ll get some infos out of looking at it with the DSO.
The support for silab can be limited. There is actually no documentation on how it works on low level. GHI did some reverse engineering to make it work. The main support and testing was done on 115200 with no changes on parity or bit count. Should you need support for silabs chips you have 2 options, using raw USB to write your own drivers or we can add a specific support for you at a fee. Please contact GHI directly if interested.
I’ll write a wrapper for it, but it would be great if you mention it in the GHI Electronics NETMF Library
USBH_SerialUSB Class Documentation. I will post a solution here if it works…