-
Notifications
You must be signed in to change notification settings - Fork 276
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SoftwareSerial::availableForWrite()' marked override, but does not override #200
Comments
For matching EspSoftwareSerial to ESP8266 Core for Arduino, this is a repetitive question ad nauseum. RTFM. |
This question also popped up on the PlatformIO forums -- I've written a post here that shows how to use the library properly; That is, for most users, do not install this library via the library manager, so that the library version used that's contained within the released Arduino-ESP8266 library. It also shows how to use the latest version of the library with the latest Arduino core and compiler, if one really wants. So you can also direkt people asking it in the context to PlatformIO to this post without having to explaining too much again. |
Well, it's, like, open source, so you're free to do pack ports, just don't confuse everyone else with issues and pull requests that are totally besides the point. Please read the fine manual, don't mix and match ESP8266 Core for Arduino at your own free will, bad things can happen and you will not get any support from the developers for this, just irony ;-) |
I have replaced esp8266 v2.7.4 included SoftwareSerial library v6.8.5 with latest available here (v6.11.4), but a change caused this compilation error:
I compiled this within the Arduino 1.8.13 IDE on Windows10.
background:
I replaced this component in the hope to get better bit timing. I use it to talk to ModBus RTU slave at 9600 half-duplex, that ignores my messages possibly due to framing errors. That slave does accept same messages when send though hardware Uart (using Pro Micro). Scope shows that character timing is off by more than a half bit after 8 bytes and appears to be dependent on bit values; example code Ascii chars bittiming looks fine. I already eliminated I2C code and Wifi code influence.
Could there be an interrupt priority issue?
Are there known issues with 8-bit data with bit7=1?
Any other hints?
The text was updated successfully, but these errors were encountered: