// the loop function runs over and over again forevervoid loop() { digitalWrite(LED_BUILTIN, HIGH); // turn the LED on (HIGH is the voltage level) Serial.println("ON "); delay(1000); // wait for a second digitalWrite(LED_BUILTIN, LOW); // turn the LED off by making the voltage LOW Serial.println("OFF "); delay(1000); // wait for a second}

Using board 'd1_mini' from platform in folder: C:\Users\...\...\esp8266\hardware\esp8266\2.4.1Using core 'esp8266' from platform in folder: C:\Users\...\...\esp8266\hardware\esp8266\2.4.1

Is there some compile switch or library I have installed incorrectly? Is there an incompatible library that needs updating? I've compiled with the selected board of "WeMos D1 R2 and Mini" - see attached image

As the USB serial is an emulation of a serial interface over USB the baud rate is completely irrelevant. The device (Wemos) is informed about the settings the PC sets for the "serial interface" but it may simply ignore it.As the software for this emulation is uploaded to the Wemos with every sketch, a buggy core installation may cause such misbehavior. I'd try to de-install the ESP core and re-install it afterwards.

a buggy core installation may cause such misbehavior. I'd try to de-install the ESP core and re-install it afterwards.

Thanks for the suggestion.

I had considered this possibility which is why I tried compiling and installing the sketch on a separate machine that had an older version of the core installed. But just to be sure, I did re-install as you suggested, by removing the ESP board in board manager, and deleting the cached compiled cores. Unfortunately it did not resolve the problem.

the baud rate is completely irrelevant. The device (Wemos) is informed about the settings the PC sets for the "serial interface" but it may simply ignore it.

Not sure I understand why you make this comment that the baud rate is completely irrelevant - I must be mis-interpreting your comment, because it is well known that the baud rate used by the device must match the baud rate used by the serial monitor, otherwise the monitor displays garbage. (I don't think any debate on the difference between baud rate and bits per second is relevant here - either way, the data transmission rates must be identical on both device and monitor)

For the avoidance of doubt and confusion the boot message of the device may be sent at a different baud rate to the rate set in the Serial.begin(), and it is well documented the boot message may be displayed as gibberish, whilst the Serial.print commands will display correctly.

The serial monitor (be it in the Arduino IDE, Putty, or any other software) does not 'inform' the device (WeMos/Arudino etc) of the speed it is using - the device is 'informed' via the sketch through the Serial.begin() statement, so the baud rate specified in Serial.begin is a critical parameter that must match the speed used by the serial monitor.

However, I agree that the device may be ignoring this statement, which is the subject of this thread.

Given that it appears the ESP core is not corrupt on my IDE machine, having been reinstalled, what else is going on to cause the problem.

Not sure I understand why you make this comment that the baud rate is completely irrelevant - I must be mis-interpreting your comment, because it is well known that the baud rate used by the device must match the baud rate used by the serial monitor, otherwise the monitor displays garbage. (I don't think any debate on the difference between baud rate and bits per second is relevant here - either way, the data transmission rates must be identical on both device and monitor)

This is true as long as a real UART style communication is involved (p.e. UNO). But if the communication is only using USB technology (UART emulation) as p.e. the Arduino Leonardo is using the configured baud rate on both sides is irrelevant and can be ignored. I don't know the low level stuff in the ESP world but I guess the serial emulation is also done in software and there it simply would make more effort and would be error prone to falsify data if the configured baud rates don't match.

Quote

For the avoidance of doubt and confusion the boot message of the device may be sent at a different baud rate to the rate set in the Serial.begin(), and it is well documented the boot message may be displayed as gibberish, whilst the Serial.print commands will display correctly.

If this is true, the ESP won't know anything about USB but rely on an external chip for the USB connection. As I wrote, I'm no expert in the ESP world, I thought the ESP has the USB hardware on chip.If this is not the case and there is an external chip handling the USB connection, it might be a problem with the driver of that chip.I just had a look at the source code of the ESP8266 hardware serial and it seems that it simply drives a hardware UART, so the USB connection is made externally.

Some searches showed that the Wemos boards use a CH340 chip which is very badly documented and most drivers don't implement all features. Try to use a common baud rate (p.e. 57600 or 115200) as 76800 might be simply ignored by the CH340 chip.

Some searches showed that the Wemos boards use a CH340 chip which is very badly documented and most drivers don't implement all features.

Indeed, the schematics of the WeMos D1 R2 and D1 mini show the CH340 chip.

I found out that the Serial.begin(speed) needed to be scaled by ~0.969 - ie, if the monitor used 115200, the I use Serial.begin(111615). Without digging into the ESP core (perhaps this is a topic for the ESP8266 forum - I only found that forum after my post here), it may be that the clock frequency is off, and hence the timings are all out. That could be an interesting project to test (maybe comparing CPU time using millis(), and comparing to real time - maybe using getEpochTime()). Or maybe it's just a dud CH340.

For those interested in how I found this out, I used Serial.println("U*U*U*U*U*") in WeMos. 'U*' is an alternating bit pattern. I wrote a simple serial monitor in C#, that kept changing the baud rate until I saw the correct characters being received (ie a "U*" sequence of characters). Changing the baud rate manually in Putty was too slow and getting me nowhere fast.

I'd be interested to hear if others have experienced similar timing problems with their various boards.

I found out that the Serial.begin(speed) needed to be scaled by ~0.969 - ie, if the monitor used 115200, the I use Serial.begin(111615).

A serious hardware serial interface should adapt in the range of +/- 5% of a wrong baud rate so the speed must be completely wrong somewhere. I don't know if the ESP or the CH340 is the bad guy in this game but the combination in the wemos seems to be definitely broken for higher baud rates.

I had the CH340 chip in a USB2Serial adapter and had lots of problems with it. After about two days of anger i threw it away and bought a part a bit more expensive but working.

Actually, the problem also occurs at even the lowest of baud rates (300), it seems like a more fundamental timing / clock speed problem, rather than one for higher baud rates. The only thing different about the higher baud rates is the higher sensitivity to using the correct scaling factor, which isn't surprising.

The strange thing is that there doesn't seem to be any problems uploading the sketches at various speeds. I am guessing the software/firmware is self adapting to the speed used to upload.