Issues reading and writing to radio in real time.

[riddlemd]

The serial connection goes all crazy and crashes the device if you try to read and write at the same time (which is already a pain to do and why I submitted pr #65) on ESP32 based devices.

Having said that, I've had some luck with using SemaphoreSlim(1,1) in my code to keeping the WriteToRadio and ReadFromRadio from stepping all over each other.

It would probably make sense to do this at the Connection class level, however; I can't see a situation you'd want to purposely screw up your serial connection.

I can look into doing it, anyone have any input they'd like to share on why we would not want to do this?

[thebentern]

Totally willing to accept some changes here. I've noticed similar issues.
Dogfooding the connection layer into the CLI made for a very linear shot API which I'm running into design remorse with using it in a chatbot project relying on that same layer. In retrospect, a more event / subscription friendly model rather what I've got right now would be ideal, but it's a pretty big rewrite.

[pfjason]

+1 for this. Just trying to do basic stuff from my own code like read incoming messages after sending messages is very hit or miss. Building the CLI project from master and trying to do basic things like list nodes doesn't always work. In the live view I get one remote node, no information about the directly connected node and nothing about the node connected by serial. If I do the same thing against an ip node it works fine. Thought it was maybe my device, but the python cli tool and web ui works just fine for these tasks. I may play with the DeviceConnection or SerialDeviceConnection class to refactor connection messaging into events and outgoing message queuing. I noticed a few Task.Delay calls, which are usually a good indicator that something is up with how you're doing multithreading, so you might be able to get away with just using Semaphores to lock up the direct calls to the serial port.

[pfjason]

After a bunch of screwing around things work relatively consistently with Receive as an event and send as a queue in my branch over here... https://github.com/pfjason/meshtastic-c-sharp/tree/feature/event-connections. I made a mess of the code trying to get it working so there's some cleanup and fixing of stuff I broke (I don't know if populating MyNodeInfo in the DeviceConnectionContext object ever works, but I'm pretty sure it's broken now in my branch), before it's a PR if you're even interested in such a fundamental concept change, otherwise I'll keep it in my fork for my stuff. Serial seems to be duplex so it doesn't choke as long as I keep one thread for receive and firing events, and the sends as a single queue processor thread.

[valentintintin]

@pfjason Your fork is nice and works very well, thanks !

[thebentern]

After a bunch of screwing around things work relatively consistently with Receive as an event and send as a queue in my branch over here... https://github.com/pfjason/meshtastic-c-sharp/tree/feature/event-connections. I made a mess of the code trying to get it working so there's some cleanup and fixing of stuff I broke (I don't know if populating MyNodeInfo in the DeviceConnectionContext object ever works, but I'm pretty sure it's broken now in my branch), before it's a PR if you're even interested in such a fundamental concept change, otherwise I'll keep it in my fork for my stuff. Serial seems to be duplex so it doesn't choke as long as I keep one thread for receive and firing events, and the sends as a single queue processor thread.

Interested in a pull request? I took a look at your changes and they look like a positive direction