I am working on a project which has a Raspberry Pi 3 Compute Module integrated into a hardware design where the PCB provides access to both Serial Ports on the compute module:
One serial port with TX/RX on GPIO 14/15 (pins 51/53 of module)
One serial port with CTS/RTS/TX/RX on GPIO 31/31/32/33 (pins 34/36/46/48 of the module)
As far as I understand there is one full 16650 compatible UART available in the BCM2835 called the "PL011", and one mini-UART which is normally used to communicate with the internal BlueTooth chip.
When booting Raspbian Jesse, I see the /dev/ttyAMA0 device which seems to communicate on GPIO pins 14/15, and according to what I have read this communication runs through the PL011 full UART chip. I have tried to create a /boot/config.txt file which has the following device tree overlays:
dtoverlay=uart1,txd1_pin=32,rxd1_pin=33
enable_uart=1
This does not seem to provide me with a /dev/ttyAMA1 device. This seems consistent with the description in the /boot/overlays/README file which states:
Name: Uart1
Info: Enable uart1 in place of uart0
I did find a limited driver for the mini-UART which is fixed at 115200 baud, which seems like a driver to use the mini-UART instead of the full UART.
What I'd like to do is: without redesigning the hardware, configure the "PL011" full UART to use the CTS/RTS/TX/RX port, and the mini-UART to use the TX/RX port, so that I can use both serial ports in my application.
Related
The dev boards for the ESP32 family of MCU use CP210x (or similar) "FTDI" chips to communicate with the MCU when flashing. CP210x presents a COM port to the host computer which runs esptool.py, a script which implements the Esressif communication protocol. Rather then use a CP210x, I would like to utilize a SAMD21 in its place.
I have managed to receive logs from my ESP32, to a serial monitor on my computer, via the SAMD21, over USB. The SAMD21 connects to the ESP32 via UART, with the standard ESP configuration of 115200 8N1. I can manually enter bootloader mode by holding the correct pins low at boot, and I get the log back confirming the correct bootloader mode.
When I run esptool.py, however, the connection fails, and I get a timeout. Likewise the esptool "monitor" fails to acknowledge the same logs which my terminal emulator easily detects.
What is the communication protocol between the host computer running esptool.py, the CP210x FTDI chip, and the ESP32, and how can I emulate the CP210x with a SAMD21? The definition of "FTDI", "TTL" and "RS232" are all a bit fuzzy, as far as I can determine with research online, so if anyone has experience in this arena, I would be very curious to hear your advice.
The code I have on my SAMD21 is just:
#include <Arduino.h>
void setup()
{
Serial.begin(115200);
Serial1.begin(115200);
}
void loop()
{
if(Serial.available())
{
Serial1.write(Serial.read());
}
if(Serial1.available())
{
Serial.write(Serial1.read());
}
}
Where Serial1 is the UART and Serial is the USB Serial connection.
esptool.py expects a serial port (known as COM port on Windows) to communicate with the ESP32. It doesn't care if the computer has an old-style serial port, is using a USB-to-serial bridge with a proprietary protocol (FTDI, CP210x and the like) or is using the standardized UBS protocol for serial communication (USB CDC ACM). This is left to the operating system and the installed drivers.
However, esptool.py modifies the baud rate and uses the RTS and DTR signals to reset the ESP32. It is also rather susceptible to timing issues with regards to the reset. If you set the ESP32 in boot mode manually, you should be able to get away without these.
However, the most likely cause is that the Arduino CDC implementation does not implement flow control. If esptool.py sends more data than fit into the internal buffer, it is likely discarded, instead of sending a NAK back so the host computer can retry later.
I don't fully understand the SAMD21 Arduino core to verify it. If so, I don't see how you can make it work with an Arduino program. You would need to resort to some other framework for programming the SAMD21.
Update
After more tests, it turns out the USB CDC implementation of the SAMD21 Arduino core correctly implements flow control. So no data will be lost.
In fact, I was able to successfully upload code to an ESP32 module. The setup was:
Arduino code built with PlatformIO. Instead of Serial, I've used SerialUSB as I'm unsure how to control the project settings available in the regular Arduino IDE.
For the ESP32, I've used a ESP32-WROOM-32 module on a minimal board (reset and boot button, 2 pull-up resistors).
I've connected the board via GND, 3.3V, TX, RX directly to the SAMD21 dev board.
I've verified that I can see the ESP32 log output in normal run mode and the "waiting for download" prompt in bootloader mode (after pressing BOOT and RESET).
Arduino has multiple boards where the esp32 is on-board as WiFi adapter. To flash the esp32, there is a tool sketch called SerialNINAPassthrough in examples of the WiFi library, which should be uploaded into the main MCU of the board (SAMD21 on two of the official boards).
The SerialNINAPassthrough sketch handles the DTR and RTS signals sent by the esptool to reset the board into the flashing mode.
I have Raspberry Pi 3 plate with connected USB to UART (COM) converter.
The power led on the USB stick is ON.
I can not find the converter in Windows Device Portal.
In both: connected and disconnected states I see just two UART related records in Device Manager:
(ID:ACPI\BCM2835\0, Class:System, Manufacturer:Microsoft, StatusCode:25165834)
>BCM283x Mini UART Serial Device
(ID:ACPI\BCM2836\0, Class:Ports, Manufacturer:Microsoft, StatusCode:25182218)
>ARM PL011 UART Device Driver
(ID:ACPI\BCM2837\4, Class:System, Manufacturer:Microsoft, StatusCode:25165834)
Also I use git diff between saved device lists and there is no difference between the case I connect USB stick and disconnect it.
Where can I see the device in the list?
UPDATE
Here I print all found devices:
First you need make sure your USB to UART (COM) converter is supported on Windows IoT Core. Please check the hardware compatibility list. The CP2102 USB 2.0 to TTL Module Serial Converter is supported.
I use CP2102 USB to UART Bridge Converter and it also works. Use the SerialUART sample can list two device: one is on-board PL011 UART Device and the other is mine.
From device portal:
I'm trying to implement UART over a USB interface on the STM324x9I-EVAL development board. The purpose is to send commands to a servo controller (or other hardware, for that matter) serially. I've successfully implemented the USB_Device_CDC example on the development board but am unsure exactly how this works without a PC with drivers on the other end. As far as other hardware is concerned, will the USB port now simply look like a serial port? Or is there still a need for a driver or some sort of interface on the other end?
I do want to point out that I'm aware of the following post:
Emulating UART over USB
but I don't believe my question is fully answered within the context of that answer.
A USB connection is not a peer-to-peer connection like a UART. It requires a host and a device in a master/slave relationship. The device cannot initiate data transfer; it must be continuously polled by the by the host.
A CDC/ACM class device presents a virtual COM port on a PC host, but that does not allow the device to communicate with a UART interface. It looks like a serial port at the software level, but does not implement a UART physical layer. There is an awful lot going on under the hood to make it look like a PC serial port, but none of it resembles UART communications at the physical level.
There are devices that act as UART/USB bridges (from FTDI and Prolific for example), and you could (somewhat expensively) build your own from a microcontroller that has a USB device controller and a UART, but the bridge is a USB device and must still connect to a USB host; these are normally used to connect a PC to a microcontroller that lacks a USB controller or where the software/CPU overhead of using a USB controller is too great.
In theory you could connect a microcontroller that has a USB host controller to one that has a USB device controller, but you need host and device software stacks on each respectively, and once you have the USB connection, implementing CDC/ACM is a somewhat inefficient use of the available bandwidth. The purpose of the CDC/ACM class is primarily to allow "legacy" software to work on a PC.
If you need to connect to a "real" serial port, you should use a real UART - which are far more ubiquitous than USB controllers on microcontrollers in any case.
You should learn a little bit about USB device classes. CDC is a USB device class, and ACM is a subclass that I assume you are using. The device you made could be called a "CDC ACM device" because it uses the CDC class and the ACM subclass.
These classes and subclasses are defined by the USB Implementers Forum in documents that you can find here:
http://www.usb.org/developers/docs/devclass_docs/
These documents specify things like what USB descriptors a CDC ACM device should have in order to describe itself to the host, and what kinds of interfaces and endpoints it should have, and how serial data will be represented in terms of USB transactions and transfers.
Note that CDC ACM only specifies some USB commands for transferring data between the host and the device. It does not specify what the device will actually do with that data. You can use CDC ACM to implement a USB-to-serial adapter, or you can just use it as a general purpose communication interface for whatever data you want to send.
Yes, you do need a driver on the PC side. The driver needs to be designed to run on your specific operating system. It needs to create some kind of virtual serial port device in your operating system that other software (which only knows about serial ports) can find and connect to. It needs to translate serial port operations performed by other software on the serial port (e.g. writing some bytes to the serial port) into low-level USB commands according to the CDC ACM specifications (e.g. sending some bytes out to the device on a particular endpoint in the form of USB packets). It needs to somehow know which USB devices it should operate on, since not every USB device is a CDC ACM device.
For Windows, you will probably use the usbser.sys driver which comes with Windows. For versions of Windows older than Windows 10, you will need to write an INF file to associate your device to usbser.sys and sign it. For Windows 10 and later, there is a new INF file called usbser.inf already included with Windows which will automatically match any valid CDC ACM device. This means you don't have to write or distribute a driver for CDC ACM devices if you only intend to support using the device on Windows 10 or later. The partnership between Microsoft and Arduino which began in 2015 gives me hope that Microsoft will continue supporting and improving usbser.sys in the future. In fact, they claim that in Windows 10 "the driver has been rewritten by using the Kernel-Mode Driver Framework that improves the overall stability of the driver", so that is good news.
For Linux, there is the cdc_acm kernel module, which has been a standard part of the kernel for a long time and should work automatically with any CDC ACM device you plug in.
For Mac OS X, there is the AppleUSBCDCACM driver, which should work automatically with any CDC ACM device you plug in.
Note that for any of these drivers to recognize your device and work with it, your device has to have certain values in its USB descriptors, and the requirements can vary depending on what exact driver version you are talking about.
Will the USB port now simply look like a serial port?
No, that's the wrong way to think about it. The USB port will still look like a USB port, but the various USB drivers provided by your operating system will recognize that a CDC ACM device is plugged into that port and create a new entry in your operating system's list of serial ports. Then if you run some software that only knows about serial ports, it can connect to that port.
In fact, if you make a composite device, you can have a single USB device plugged into a single USB port that actually has two or more virtual serial ports.
I want to connect a USB peripherals to a FPGA. Basically FPGA should act like an USB host. Is there a FPGA board support a USB hub so that one could connect multiple(upto 4) USB peripherals at a time.
I have a Digilent Nexys3 fpga which is based on Spartan 6. It supports only one USB device (keyboard or mouse). It doesn't support a hub. I have found Cypress host controllers, but I am not sure how to use it in a FPGA.
You need to have a USB host controller inside your FPGA, such IP is not freely available, one alternative is to use a Zynq based (for Xilinx) or Cyclone V based (for Altera) board. Those have integrated USB controllers connected to their dual ARM core.
You can find more info about those at:
Altera Cyclone V
Xilinx Zynq
You maybe able to use an external host controller but then you have to connect it to your FPGA and that is usually requires a lot of IOs and those modules are more expensive than buying a Zed board ($395) or Cyclone V board ($450).
The Arduino Nano (and other models) has a USB Connector on the pcb.
Can a Arduino Application (Code inside the loop() Function) communicate to a PC/Mac over the built in USB Channel?
The board at the link you posted uses an FTDI USB to UART chip; the ATMega168 itself has no USB controller. The UART side of the FTDI chip is attached to the ATMega168's RXD/TXD UART pins. So from the point of view of the Arduino code, you are just communicating with a UART driven serial port.
From the PC end, the FTDI chip uses the USBSER.SYS driver to emulate a legacy UART serial port (A Virtual COM Port or VCP). You will be able to see this and which COM port it has been assigned to in Device Manager.
So in essence all you need to know is how to do serial port programming on both the PC and the Arduino and you are good to go.
This is how I have done it. You also need to write a program to your computer - for POSIX-compilant OSes, this one could help you out.