-
Notifications
You must be signed in to change notification settings - Fork 3.1k
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
Initial version of software UART C module #2673
Conversation
This code is very useful. I used it in my module for communicate with sensor GY-MCU680 (https://github.com/shimosaurus/mcu680). It works well on 9600 baud. |
@pjsg would you be willing to review this? |
b0103cf
to
be75383
Compare
@galjonsfigur I would like to do a build to test this module, it doesn't seem to be merged into dev yet. Suggestions please. |
@galjonsfigur can you rebase this on the latest upstream |
@NicolSpies @marcelstoer I rebased this PR and now it should be ready to test. I previously tested it mainly by using an Arduino to transmit and receive data, but now when I was rebasing it I tested it using only ESP8366 itself transmitting the data. And because this version tries to sample full data frame in one interrupt, it's not possible to use software transmit and receive that transmission at the same time. This might be a subject to change. Now I have acquired digital oscilloscope and I can try to change interrupt code to sample only single bits in data frame instead of whole frame - that way it should work even better. This PR is low-priority so I don't know yet when this upgrade to the module would be ready - now it's in working state, but it could be better for sure. |
@galjonsfigur , Unfortunately I can only test the unit from a Lua application perspective against the existing UART module. This might be a bit premature to test before it has been reviewed. I hope there will be interest to take this further as it is very handy. |
@marcelstoer, I am using the last pre-SDK 3.0 commit in the dev tree due to TLS issues mentioned in the list. Would it be possible to use the indicated pre-SDK 3.0 commit, include only the softuart.c module, add it to user_modules.h and build. The build on @galjonsfigur's git is already on SDK 3.0. |
@marcelstoer, I have tried without success to find if this software UART module have made it into dev. Can you recall if it did ? |
You are asking this on an open PR for |
Excellent answer for a stupid question, thanks 😊 |
@marcelstoer , much appreciated |
Thanks for merging this code. I think that it can still be improved so if there are people who find it useful and use it I would be thankful for any feedback or bug reports. |
See my review comment. Note to @nwf, @HHHartmann and @marcelstoer we've got existing module clean-up to do on this, but we should at least try to avoid this type of malloc use except when absolutely necessary. |
dev
branch rather than formaster
.docs/*
.Justification
There are many GPS or GSM modules that are using UART to communicate with microcontroller. But ESP8266 despite it's power and built-in WiFi radio has only one full and one transmit-only UART. There is no other way to communicate with those modules than using additional ICs like UART-to-I2C bridges or similar stuff.
This is an initial version of Software UART module. Inspired by #2120 with fixed issues and some improvements. It's not ideal for any reliable applications, but should work for simple and small amount of data communication. In typical microcontrollers like AVRs, PICs, 8051s and many others the approach is quite simple: set the interrupt for stop bit, in ISR wait for stop bit to end, set hardware timer to proper bit time and setup another ISR for this timer. In second ISR data is sampled and saved somewhere. But in ESP8266 there is no free hardware timer that could be suitable for this job - it has to be very precise and I don't have an oscilloscope to test if multiplexed HW timer (#2497) is precise enough to read the data at high baudrate. So this module uses different approach - whole data frame is read and saved in one gpio ISR - this can lead to crash at very low baud rates like 300 (I haven't tested it though), but I tested 9600 and 115200 and it worked fine. There is a third approach that uses gpio interrupt and the ISR is run at every edge, but I saw only one example of this (https://github.com/SlashDevin/NeoSWSerial) and trying to implement this without logic analyzer or digital oscilloscope would be too hard for me.
I'm not a C or ESP8266 expert so any comments and/or testing would be appreciated.