Serial USB Speed ?

Does anyone know what speed Serial USB is capable of running at ?

I’m wondering if it would be possible to Flash a ESP8266 via a STM32 using the serial USB.

i.e create a transparent bridge.

The reason I’m interested in doing this, rather than just using a dumb USB to Serial converter, is that I’ve seen a concept to use a ATTiny85 to toggle the reset and upload lines on the ESP8266 when it sees the upload traffic on the serial lines going to the ESP8266 from a USB to Serial converter.

So it may be possible, assuming the Serial USB is fast enough, to do the same thing with a STM32, but have the STM32 act as both the USB to Serial as well as controlling the reset and upload lines.

I’d need to review the ATTiny code to see what it looks for in terms of the upload, as I’m not sure how long is needed between getting the upload data and resetting the ESP etc, and whether this is practical at all.

Edit

Just to partially answer my own question

I used the MegaMultiSerial example to make a USB to Serial to Serial1 bridge, and attempt to upload to the ESP8266 at 115200, but although it seems to go through the motions. The sketch in the ESP8266 didnt get updated.

I also tried 57600 and that was the same.

So it would need further investigation to figure out what’s going on.

But unfortunately just using a simple serial bridge doesn’t work for some reason.

It should be do-able …
When you’ve tried simple serial bridge, I presume it was bidirectional, because esptool is doing a lot of handshaking.
Did you figured out why it didn’t work ?

Martin

Yes. The bridge was bidirectional.

The ESP upload tool appeared to be working like it normally does, and the bridge was also passing back the debug from my web server test sketch.

But if i made changes to the ESP’s sketch, they didn’t end up in the code on the ESP.

I will have to try again, another day, and save the verbose output from uploads via the stm32 and one via the normal usb to serial. Then compare them side by side to see if I can spot any difference in the messages.

Matrin,

I finally got around to doing this, and it looks like the Serial USB drops loads of chars when the ESP8266 is sending back bursts of text.

I also can’t get it to upload to the ESP8266 via the STM32 at 115200

I’ve tried a few times and it seems to go though the motions, but I find that the uploader this is used by the ESP8266 doesn’t seem that good at reporting problems.

Even with a USB to serial adapter, it sometimes seems to fail to upload, but i don’t seem to get any notification that its not succeeded

I’m not sure if this is an issue with the way the USB Serial works in the libmaple core or something inherent in the virtual serial driver.

I’m tempted to dig out an Arduino Pro Micro that I have kicking around somewhere as they use the ATMega32U4 which has USB on the chip, so that it has a free hardware serial port.
So I should be able to run the same program on that one.

Alternatively, I can just glue a pro mini to the back of one of my existing USB to serial adaptors and use the ATTiny code

https://github.com/esp8266/Arduino/issues/480

Actually I have bucket loads of GD32’s, so I’ll use one of those, but not for its serial USB but just for its hardware serial

Well, again now I think about it. Perhaps a 120Mhz GD32 may be able to transfer at 115200 to its USB Serial. Its probably worth a try !

Alternatively, I can just glue a pro mini to the back of one of my existing USB to serial adapters and use the ATTiny code

Pictures! Pictures!

I have a bucket load of PSoC 4100 devices … I have found that the break-off serial-USB board makes a nice adapter if one can live without the handshake signals, only Tx and Rx appear to be available but Cypress has not released the source-code they run on the PSoC 5.

Ray

RogerClark wrote:it looks like the Serial USB drops loads of chars when the ESP8266 is sending back bursts of text.

Martin

Ive not tried it on my linux machine, but I will when I get chance.

Its unclear why uploads are failing, but after attempting to upload via a Maple mini, the code failed to run, and I seemed to get some sort of stack dump being spat out via serial, and then the ESP8266 would reboot (over and over).

Using the Maple mini, It seemed to drop big parts of the stack dump text, which I could clearly see when I use a USB to serial adaptor.

I probably need to write a simple program to send 512 chars of text, out via serial, at 115200 and see what arrives at the pc via the Maple mini

then try smaller packets if that fails

There was a post on hackaday today about using the ESP8266 as a bridge to upload to an arduino or ARM. The article points to jeelabs github site https://github.com/jeelabs/esp-link It looks as if there are options for setting the baud rate from 57600 through 460800.

Thanks @fredbox

I actually came across that the other day, when looking for something completely different.

I’m now thinking of a different approach, probably using a STM32F103C8 as a Black Magic Probe so that I can flash the ESP using OpenOCD, however I’m not sure the guys on the esp8266.com forum have got OpenOCD working with the ESP yet

For Flashing the ESP, since the MCU has it own bootloader, there is no need for OpenOCD.
For Debug, although I didn’t try it out yet, there is the new GDBStub :

https://github.com/esp8266/Arduino/tree … es/GDBStub

Hi Martin

Thanks for the link.

I think I also need to look at OTA updates, as currently I’m finding that the time to upload via serial at 115200, is quite a hit on development time, especially as not every upload seems to succeed.

I’m currently trying to debug some serial comms between the ESP and another device so I’m thinking of thinking of using a Maple mini as a dev platform, just to get that code running, and I can put it back on the ESP when its working.

Uploading to the Maple mini via DFU seems to be substantially faster than to the ESP via serial, but of course the IDE has to upload a much bigger binary to the ESP.

Im also thinking of looking at Visual Micro for ESP8266, but I think it may be Windows only.

I am having a similar issue. I am trying to build a little usb dongle that is sort of like the Bus Pirate, but much smaller and written in Arduino on the STM32 hardware. From what I can gather, the baud rate you set on the computer seems to be irrelevant when using the Maple CDC serial. It appears to send full speed usb, or at least way faster, than the baudrate set, to the STM32. This is not a problem when sending small amounts of data, because the buffer can handle it. However, when making a serial bridge by reading USB serial and writing to hardware serial, the data comes in at full speed, and only goes out at a set baud rate that is no where close to USB speed. This makes the buffer overflow. When using it to program the ESP8266, for example, bytes are constantly dropped due to this overflow and the large amount of data being sent with nothing telling it to stop.

I am planning on either modifying the maple USB CDC Serial code, or making another library to handle this differently (maybe a class named SerialUSB like the original name). I have not gotten to look at the USB CDC code enough, but it clearly needs some improvements for this behavior. It even says so in the notes in the code. I am thinking the current code sends a CTS signal at all times, so the USB port always sends data at full speed. One way to improve this would be to monitor the buffer, and turn off the CTS signal when the buffer is full.

This is something I need really bad for my project and it all relies on this. It is probably an easy fix and would only take a few lines of code, I just haven’t had enough time to look through all the USB CDC code yet.

I also want to add many functions that return the baud rate from the computer, and can set the flow control pins externally.

I also want to build in the function outlined here. http://leaflabs.com/docs/lang/api/serialusb.html at the bottom of the page. There is a big delay when you do USB serial writes and there is no com port open on the other side. I use the following function in all of my STM32 code.

// check to see if usb can receive serial data
bool usb(){
if(Serial.getDTR() && Serial.getRTS()) {
return true;
} else {
return false;
}
}

if(usb()) Serial.print("Connected");


@primateio

Interesting…

I had noticed that it doesn’t matter what baud rate you sent in a terminal attached to the Maple mini, the data always comes out the same.

Some of the USB files seem to date back to 2008 !!!! (which is much earlier than when Leaflabs originally wrote libmaple)

It looks like there is newer code (from STM) which we may be able to use to update the current usb_core.c, usb_init usb_mem and usb_regs

Possibly from

https://github.com/OculusVR/RiftDK1/tre … tm_usb/src

Or a more official channel.

However I doubt it would fix the problem, if the usb client is supposed to notify the host, when its buffers are full.

There was a thread about it on the original leaflabs forum

http://forums.leaflabs.com/topic.php?id=13641

which may give some clue on how to fix this

I’ve been using libopencm3 as USB serial driver, and it works really well so far in the serial USB boot loader I’m experimenting with – see this thread: http://www.stm32duino.com/viewtopic.php … 0&start=40

The libopencm3 code is used in many projects, including some very heavy transfers and high speeds: https://github.com/libopencm3/libopencm3

Paul with Teensy ran a bunch of benchmarks on boards with usb, including the maple. It is clear that the maple needs some improvements from his results.

https://www.pjrc.com/teensy/benchmark_u … ceive.html

He has the code for the test, I plan on using it to try to get the usb speed closer to teensy 3.0 levels.

primateio wrote:Paul with Teensy ran a bunch of benchmarks on boards with usb, including the maple. It is clear that the maple needs some improvements from his results.

https://www.pjrc.com/teensy/benchmark_u … ceive.html

primateio wrote:I also want to build in the function outlined here. http://leaflabs.com/docs/lang/api/serialusb.html at the bottom of the page. There is a big delay when you do USB serial writes and there is no com port open on the other side. I use the following function in all of my STM32 code.

// check to see if usb can receive serial data
bool usb(){
if(Serial.getDTR() && Serial.getRTS()) {
return true;
} else {
return false;
}
}

if(usb()) Serial.print("Connected");


I don’t think there is any flow control.

Whats funny is how the Due seems to be even slower than the Maple

I have made some progress on a improved USB-Serial library. There are not breaking changes, so we should be able to add it to the core when I get done, if you guys want After pouring over the usb code, I do not think it is a buffer overflow issue that is dropping bits. I believe it is a parity/data bits/stop bits issue. I tried to find out what serial settings are used to program the ESP8266, but no luck. Does anyone have any ideas?

What I have working:
Capture baud set on host and change Hardware serial baud accordingly.
Capture usb DTR and RTS state and have physical pin react accordingly.
Capture parity, data bits, and stop bits set by host.

What I don’t have working:
Setting parity, data bits, and stop bits on hardware serial. I noticed that Roger put a note about the inability to set these settings in the HardwareSerial.cpp code.

void HardwareSerial::begin(uint32 baud)
{
begin(baud,SERIAL_8N1);
}
/*
* Roger Clark.
* Note. The config parameter is not currently used. This is a work in progress.
* Code needs to be written to set the config of the hardware serial control register in question.
*
*/

void HardwareSerial::begin(uint32 baud, uint8_t config)
{ ......