Possibly add a Self ID function?
Opened this issue · 1 comments
Assuming there is still room in the PIC for this. A self ID function would be handy for a host to 1. Identify that there is a TashTalk present on a given serial port and 2. Identify the firmware revision in order to use v2.x's advanced features. Such a system could work as below:
-Host sends 0x04 to TashTalk. This could be something else of course.
-TashTalk sends back:
0x00 0xFB - A possible escape sequence assigned to "Self ID response"
0x54 0x54 - Two bytes that spell "TT" in ASCII.
0x32 0x31 0x33 - Firmware revision as ASCII sequence of numbers. In this case it would be version 2.1.3.
This is definitely something I've considered before... there's currently no command that you can send to TashTalk that will provoke a response of any kind, which is sometimes a pain when debugging, and it'd be nice for it to be able to report its own firmware revision.
By way of background, TashTalk has no queue for bytes being transmitted over its UART. In the LocalTalk receive loop, bytes that come in are sent to the UART directly, and the two-byte escape sequences take advantage of the fact that the PIC's UART can hold a single byte in waiting while it's transmitting another.
The reason I haven't implemented any kind of self-identification command is that a change on the LocalTalk input pin causes the code to drop everything and enter the receive loop, and that would include being in the middle of transmitting an ID string. This creates a potential circumstance where the transmission of an ID string is cut short by the reception of a LocalTalk frame, which would cause the host to interpret the first few bytes of the frame as part of the ID string. This could potentially be mitigated by changing the protocol to prepend an escape sequence to the reception of a frame and telling the host to discard any ID response that is cut short in such a way, but the receive loop is so tightly packed that there isn't space to do so. In addition, in the course of returning from the receive loop, it's just this side of possible that the next character in the ID string would be loaded for transmission, unaware that the receive loop fired off and relayed a frame in the middle of it, potentially causing the host's receive code to prepend invalid bytes to what would otherwise be a valid frame.
Long story short, while TashTalk's UART protocol on the host-to-TashTalk side has room for expansion, the TashTalk-to-host side is in an extremely delicate balance and highly intolerant of additions beyond relaying inbound LocalTalk frames.