I've (for years) naively regarded USB as "just" a faster form of serial port. From a Windows developer point of view we usually interact with USB as a serial port, COM3 and so on as they are usually named.

When working with MCUs too, I connect to USB and that also appears as a COM port.

But that's wrong isn't it? USB is technically much more than that.

I ask because I've been looking at a better/cheaper way to connect an NRF24L01+ to my PC, I use this currently and it works fine:



That appears as a serial port on my PC and one can send simple commands to the device to read and write blocks of bytes.

But is large, a bit clumsy, and the display isn't needed if you are just connecting something to the PC (its helpful for exploring the SPI but if you just want to connect it's overkill) and it costs 30 bucks.

I did some digging the other day and found that the device uses a chip from FTDI and that they have a big presence in this market, they also make breakout boards and here's one from Adafruit:



I think that SPIDriver in facts uses that same FTDI chip: FT232H.

But managing that Adafruit device seems to require various libraries, even when using .Net they seem to rely on an FTDI native DLL to do the low level work, as I searched more all I could find was referenced to this FTDI library and no source code for that either.

Is it a complex thing?

 

A direct USB interface is more complicated than a serial port or SPI or I2C. The main obstacle to direct connection is the identification of devices and the negotiation about what types of devices they are and what types of transactions they support. Getting this to occur successfully the first time is quite challenging and almost impossible without a sophisticate protocol analyzer. On top of this, on a Windows system, the registry can become "corrupted" by unsuccessful USB negotiation attempts preventing further progress until the leftover detritus is removed from the registry.

 

USB is not UART and vice-versa.
Silicon Labs CP2102 and FTDI FT232H are called USB-to-UART bridges.

If you want USB capability, look at STM32 MCU that has USB stacks built-in.

https://wiki.st.com/stm32mcu/wiki/Introduction_to_USB_with_STM32

 

USB is not UART and vice-versa.
Silicon Labs CP2102 and FTDI FT232H are called USB-to-UART bridges.

If you want USB capability, look at STM32 MCU that has USB stacks built-in.

https://wiki.st.com/stm32mcu/wiki/Introduction_to_USB_with_STM32

I'm seeking ways to have code on the PC control a board (like the Adafruit one). The code I have so for controls an NRF24L01+ using that "SPIDriver" gizmo and I'd like to replace that with something smaller/cheaper.

I've just found out that the ideal way to do this is in fact to use their native DLL and use .Net interop, they have some examples and a lot of course but no up to date nuget packages it seems.

I'm very familiar with .Net Interop so I might spend some time exploring this.

Ordinarily one would load have the native DLL sitting in a folder along with the C# DLL. But I think I can do this dynamically and avoid fiddling with files and folders.

 

I've (for years) naively regarded USB as "just" a faster form of serial port. From a Windows developer point of view we usually interact with USB as a serial port, COM3 and so on as they are usually named.

When working with MCUs too, I connect to USB and that also appears as a COM port.

But that's wrong isn't it? USB is technically much more than that.

I ask because I've been looking at a better/cheaper way to connect an NRF24L01+ to my PC, I use this currently and it works fine:

View attachment 349423

That appears as a serial port on my PC and one can send simple commands to the device to read and write blocks of bytes.

But is large, a bit clumsy, and the display isn't needed if you are just connecting something to the PC (its helpful for exploring the SPI but if you just want to connect it's overkill) and it costs 30 bucks.

I did some digging the other day and found that the device uses a chip from FTDI and that they have a big presence in this market, they also make breakout boards and here's one from Adafruit:

View attachment 349424

I think that SPIDriver in facts uses that same FTDI chip: FT232H.

But managing that Adafruit device seems to require various libraries, even when using .Net they seem to rely on an FTDI native DLL to do the low level work, as I searched more all I could find was referenced to this FTDI library and no source code for that either.

Is it a complex thing?

A very complex thing if you've never done it before.
https://acroname.com/blog/understanding-usb-class-codes
https://developerhelp.microchip.com/xwiki/bin/view/applications/usb/how-it-works/device-classes/

Just interfacing a simple HID device requires lots of detail at the low-level.
https://github.com/signal11/hidapi

Wireshark (usbmon) is a great tool to look at what's happening.

 

MCP2210 is cheap USB-SPI bridge, but it needs a 12MHz crystal to operate and enumerates as HID device. Chip is about $2 but module costs about $20

 

OK thanks guys.

I think I've made progress, turns out the .Net IOT stuff has come along in leaps and bounds (been years since I looked at it) and is written from the ground up to work with this kind of hardware.

I just added the basic package to my project as a test and it added fine, so its an integral supported part of .Net.

In theory if I plug one of those Adafruit boards into my PC then I can interact with this board effectively...

 

I just copied some basic MS code from their example page for IoT and USB and ran it. It recognizes the SPIDriver board and returns info about it:



The code dies at line 26 and I presume that's because, although the SPIDriver uses an FT232H chip, the board itself is kind of "hardwired" so only everything operates as a serial device.

Time to order a couple of those Adafruit boards...

Ultimate goal here is to eliminate the SPIDriver board and use that Adafruit boad + the NRF24L01+ board as a device I can just plug into a PC and then use my NRF C# library to contgrol it.

 

MCP2210 is cheap USB-SPI bridge, but it needs a 12MHz crystal to operate and enumerates as HID device. Chip is about $2 but module costs about $20

Cheap and useful as a quick IMU interface.

IMU Z channel control of LED flashing speed demo.

 

Cheap and useful as a quick IMU interface.
View attachment 349431View attachment 349432

IMU Z channel control of LED flashing speed demo.

Man, just how much stuff do you have going on in your workshop, astonishing !

 

Man, just how much stuff do you have going on in your workshop, astonishing !

Life is short. I get paid to build things, so having trinkets for suits to play with it, is a (was a) necessity to keep getting paid.

 

Life is short. I get paid to build things, so having trinkets for suits to play with it, is a (was a) necessity to keep getting paid.

That looks like a pretty high end scope too, the colors are bold, very eye catching display and probably more interesting than watching TV.

 

That looks like a pretty high end scope too, the colors are bold, very eye catching display and probably more interesting than watching TV.

High end, Ha Ha. More like the upper end, of the low end. A lot more interesting than watching TV, but so is getting your teeth cleaned.

 

High end, Ha Ha. More like the upper end, of the low end. A lot more interesting than watching TV, but so is getting your teeth cleaned.

I'm a "hobbyist" your run around, is my Rolls Royce!

As for TV, you likely won't get much better than Twilight Zone, but that was long ago.

 

I'm a "hobbyist" your run around, is my Rolls Royce!

As for TV, you likely won't get much better than Twilight Zone, but that was long ago.

No, really it's low end. The artist can make poor instruments look and sound good. I know the limits of what I build and put the money into the product, not waste it on trophy gear.

Watched first run, some were a lot better that others. I use mythtv to archive what I watch while drinking, TZ is on the list but so is Genie and Bewitched.

 

Complex thing, you ask?

There was a LONG thread (the longest one I ever read in full) running in the Microchip forum, started by a profesor in the Olin College (USA?) who developed code in pure assembler (MPASM). Micro ID, I recall, ended in 50.

He added several "labs" to test it.
I did. It worked well.

There are (were?) two other pieces of code somewhere in the Web at the time, also dedícate to USB handling.

Just in case, if your search throws Olin Lathrop, that is not who you are looking for.

Buena suerte.

 

Just to be very clear, because I am not sure this point is clear to you...

The serial port presented to the computer is an emulated UART, connected as a serial port only at the driver level. It uses the HAL (or other mechanism) to appear to be hardware but it purely virtual.

On the other end, there is hardware that is connected physically to your MCU or other device. These boards which can be had for very low prices are often called USB to TTL UART converters because they aren't RS-232 devices even if serial, they use 3.3V or 5V on the hardware side.

So what you have is: [virtual serial port] ←→ [USB] ←→ [TTL UART] ←→ [connected device]

The chipsets used have varying numbers of GPIO pins on them, and so some can be programmed to do protocols like SPI and I²C. But the bread and butter of these boards is simply to connected hardware with serial I/O to computers with USB.

 

Just to be very clear, because I am not sure this point is clear to you...

The serial port presented to the computer is an emulated UART, connected as a serial port only at the driver level. It uses the HAL (or other mechanism) to appear to be hardware but it purely virtual.

On the other end, there is hardware that is connected physically to your MCU or other device. These boards which can be had for very low prices are often called USB to TTL UART converters because they aren't RS-232 devices even if serial, they use 3.3V or 5V on the hardware side.

So what you have is: [virtual serial port] ←→ [USB] ←→ [TTL UART] ←→ [connected device]

The chipsets used have varying numbers of GPIO pins on them, and so some can be programmed to do protocols like SPI and I²C. But the bread and butter of these boards is simply to connected hardware with serial I/O to computers with USB.

Yes, I'm not knowledgeable about USB at all and everything you say matches what I've read, these are virtualized serial ports. I'm now looking at the .Net IoT libraries, these provide low, granular access to the FTDI chip and rely on a true Windows driver for the chip, also from FTDI.

https://ftdichip.com/drivers/d2xx-drivers/

This is the API that the driver allows us to use in user space code.

https://ftdichip.com/wp-content/uploads/2023/09/D2XX_Programmers_Guide.pdf

This looks interesting and lets me write C# code that can see and manipulate the Adafruit board as a true USB device with all the details, bypassing the restrictive and simplistic virtual com port exposed by the "SPIDriver" gadget.

 

You don't need to know anything about how USB works in order to use it. With the cheap little interface boards, you just let the converter chip sit between the computer and a microcontroller, and it looks like a serial port as far as the software at either end is concerned. A big advance over RS232 ports is that the USB cable carries 5V from the computer, so you don't need an external power supply as long as your device doesn't draw much current.

 

Hi F,
Some PDF's that may help.
E