Yeah I was more busy than I expected
Yes in many applications the performance might not be too important. In general I'd say the current state will add 50-100ms to communication. Haven't tested it with mqtt_as yet because in the current state there is one major problem: With non-blocking sockets you read every 20ms which currently is each a call to the host taking 50ms so that's not good
![Very Happy :D](./images/smilies/icon_e_biggrin.gif)
But I already know how to solve that and it'll be fine. I'll test it then.
I'm more concerned about sending, maybe you have an idea. Mqtt_as e.g. has 4 write instructions per publish, sometimes just a single byte. Currently every instruction would be sent to the host resulting in a simple publish needing like 200ms only for the communication between client and host.
I don't know how to buffer those writes unless I use an interrupt driven timer to send them every 5ms if data is waiting. But this has 2 downsiedes: 1) I return True but don't know if that data will actually be sent, which is ok with non-blocking sockets but not with blocking socket. 2) That would also mean that I add a background task to micropython that uses up to 20-50ms. That would crazily noticeable in every application. By using more interrupts (or uasyncio
![Very Happy :D](./images/smilies/icon_e_biggrin.gif)
) I could drive that time down to maybe 10-20ms but that is still noticeable. It might be acceptable but it's not transparent to the application because it will occur e.g. 5ms after you write to the socket.
You're right about crc. Current implementation takes at most 1ms. All that profiling adds some overhead so maybe 500us. Could make it faster but doesn't seem to be the slowest part of my code. But could definitely be faster and less complex, detecing errors on uart should be rather easy.
Generally this might not be a very fast solution but I guess if you need a fast wlan solution you will probably pick a board with integrated wlan?
pythoncoder wrote: ↑Thu Feb 11, 2021 2:15 pm
I have ported my MQTT-only solution to the Pico.
Guess you've been rather busy yourself
![Very Happy :D](./images/smilies/icon_e_biggrin.gif)
Thought you had retired that project. But it's good to see it alive and working!
Seeing your latency of about 250ms (according to your docs) makes me feel a little bit better but is expected with a software bitbanging communication.
pythoncoder wrote: ↑Thu Feb 11, 2021 2:15 pm
So that is an option for those wanting MQTT only. One advantage is that the resilience of the ESP8266 solution is already proven.
True. For needing mqtt only this might be a nice solution. My library will depend on the host application to be resilient so should work just fine with mqtt_as but we'll see. It has to prove itself first
![Smile :)](./images/smilies/icon_e_smile.gif)