Sorgelig wrote:ericgus wrote:One thing I have noticed is when disconnecting from a BBS .. the UART doesnt seem to want to drop the connection, I have to go into F12 and "reset uart connection" .. Maybe it needs a bit of tweaking?
UART works as a bridge between FPGA and HPS. It's completely unaware what's going on with Linux connectivity. So, wathcing ethernet connection or WiFi connection is not the task of UART connection.
And from permanent connectivity there is no difference between temporary disconnection or permanent - they are all temporary. For example on my PC i see sometimes ethernet becomes unavailable for short time - probably something with communication problem on cable. So ethernet disappear and then appear again.
Anyway, with this connection emulation there is no such thing as "carrier lost".
I am comparing the functionality against a wifi modem which works in a similar manner via telnet over the internet.. I presume the Midilink/TCP stack works in a similar manner.. the issue is very likely a problem in the tcpser Modem emulation in the midilink/tcp stack and not the underlying networking .. in this case "carrier lost" is akin to the telnet session between the two "internet modems" terminating the session (gracefully -- not due to any underlying networking issues).... whats specifically happening is, when logging off from a BBS, the MidiLink/TCP stack no longer is responding to "AT" commands at the terminal without having to "reset the uart" which effectively restarts the midilink software stack returning the AT command prompt. Once you reset it, you are then free to contact another BBS with the terminal software... without resetting it, the dialer no longer works due to the lack of the "AT" command response.