20210913
This commit is contained in:
lampmerchant
parent
e7cbd5e519
commit
8547f16ef8
|
|
@ -0,0 +1,63 @@
|
|||
TashTalk UART Protocol
|
||||
======================
|
||||
|
||||
Host to TashTalk
|
||||
----------------
|
||||
|
||||
### Flow Control
|
||||
|
||||
The firmware accepts bytes over its UART receiver at all times, including while actively transmitting or receiving LocalTalk frames. When its 128-byte buffer is half-full, it deasserts the CTS (Clear To Send) line to request that the host suspend transmission of data. When the buffer falls below half-full, it reasserts CTS to request that the host resume transmission of data. The host must stop transmission soon after the CTS line is deasserted to prevent overflow of the queue. Because the firmware does not keep an entire frame to transmit in memory at once, the host must also promptly resume transmission once the CTS line is reasserted to prevent underflow of the queue. Overflow or underflow of the queue will result in undefined behavior.
|
||||
|
||||
### Commands
|
||||
|
||||
#### 0x00 - No Operation
|
||||
|
||||
This command byte does nothing. As such, the host can send it as many times as it likes to no ill effect. A sequence of 1024 0x00 bytes will be certain to return the chip's UART receiver to the state where it awaits a command byte.
|
||||
|
||||
#### 0x01 - Transmit Frame
|
||||
|
||||
This command byte prepares the firmware to accept a frame to transmit over LocalTalk. It is simply followed by the frame to be transmitted, byte for byte with no escape sequences.
|
||||
|
||||
* The host must calculate and provide the two-byte CRC sequence for the payload frame.
|
||||
* The end of the frame is not explicitly marked and will be inferred from the frame data.
|
||||
* Control frames, where the high bit of the third (LLAP type) byte is set, consist of five bytes.
|
||||
* Data frames, where the high bit of the third (LLAP type) byte is clear, are variable length.
|
||||
* The length of a data frame is defined in its fifth byte and the two least significant bits of its fourth byte.
|
||||
* This number includes the length field, but not the three LLAP header bytes or the two CRC bytes.
|
||||
* LocalTalk specifies that this number may not exceed 600, but the firmware does not enforce this limit.
|
||||
* Data frames will be preceded by an RTS frame (generated by the firmware) and non-broadcast data frames will be transmitted in response to a CTS frame, following the algorithm as detailed in *Inside AppleTalk*.
|
||||
* The firmware will await the next command byte after the transmission completes or after 32 failed attempts at transmission.
|
||||
|
||||
#### 0x02 - Set Node IDs
|
||||
|
||||
This command byte determines on which node IDs' behalf the firmware will respond to ENQ and RTS frames. It is followed by a 256-bit (32-byte) bit field, with each bit corresponding to one of the 256 possible node IDs on the LocalTalk network.
|
||||
|
||||
The first byte following the 0x02 command byte determines whether the firmware will respond on behalf of node IDs 0 through 7, with a 1 in the least significant bit causing the firmware to respond on behalf of node ID 0, and a 1 in the most significant bit causing it to respond on behalf of node ID 7. Likewise, the next byte determines whether the firmware will respond on behalf of node IDs 8 through 15, with the least significant bit corresponding to 8 and the most significant bit corresponding to 15, and so on up to the 32nd byte following the 0x02 command byte.
|
||||
|
||||
Note that 0x00 and 0xFF are not valid for use as node IDs on a LocalTalk network; the bits corresponding to these node IDs should never be set. The former may not cause any problems, but the latter will prevent any broadcast data frames from being transmitted.
|
||||
|
||||
|
||||
TashTalk to Host
|
||||
----------------
|
||||
|
||||
The firmware retransmits over its UART all frames going over the LocalTalk bus, regardless of source, type, or destination, excepting those that it transmits itself. It will also transmit frames that it responds to itself; it is important to bear this in mind so that, for example, duplicate responses to ENQ frames are not transmitted.
|
||||
|
||||
### Escape Sequences
|
||||
|
||||
In order to accomplish in-band signalling, the firmware uses an 0x00 byte as the first half of an escape sequence. The character following the 0x00 byte determines its meaning.
|
||||
|
||||
#### 0x00 0xFF - Literal 0x00
|
||||
|
||||
This sequence signifies a literal 0x00 byte in the frame being received.
|
||||
|
||||
#### 0x00 0xFD - Frame Done
|
||||
|
||||
This sequence signifies the end of a frame where no exceptional conditions occurred.
|
||||
|
||||
#### 0x00 0xFE - Framing Error
|
||||
|
||||
This sequence signifies a framing error - a condition in which six consecutive '1' bits are received but cannot be interpreted as a flag byte.
|
||||
|
||||
#### 0x00 0xFA - Frame Aborted
|
||||
|
||||
This sequence signifies an aborted frame - a condition where a host had been transmitting a frame but unexpectedly stopped without a concluding flag byte.
|
||||
|
|
@ -0,0 +1,67 @@
|
|||
TashTalk Prototype Details
|
||||
==========================
|
||||
|
||||
Raspberry Pi
|
||||
------------
|
||||
|
||||
A Raspberry Pi 3 Model B was used. Note that these instructions are specific to this model and may differ for other models.
|
||||
|
||||
### UART Setup
|
||||
|
||||
#### raspi-config
|
||||
|
||||
Under `Interface Options` > `Serial Port`, answer "No" to "Would you like a login shell to be accessible over serial?" and then "Yes" to "Would you like the serial port hardware to be enabled?".
|
||||
|
||||
#### /boot/config.txt
|
||||
|
||||
Add the following lines:
|
||||
|
||||
* `dtoverlay=miniuart-bt`
|
||||
* Ordinarily, the Bluetooth device uses the PL011 UART (/dev/ttyAMA0); this line forces it to use the mini-UART instead. We want the PL011 UART available because it's the only one that supports hardware flow control.
|
||||
* `gpio=16-17=a3`
|
||||
* This line switches GPIO16 and GPIO17 to be CTS and RTS for hardware flow control.
|
||||
|
||||
### Connections
|
||||
|
||||
| PIC12F1840 Pin | RPi 3 Pin |
|
||||
| -------------------- | ------------- |
|
||||
| 01 Supply | 01 3v3 Power |
|
||||
| 02 RA5/LocalTalk Out | |
|
||||
| 03 RA4/Driver Enable | |
|
||||
| 04 RA3/LocalTalk In | |
|
||||
| 05 RA2/UART CTS | 36 GPIO16/CTS |
|
||||
| 06 RA1/UART RX | 08 GPIO14/TXD |
|
||||
| 07 RA0/UART TX | 10 GPIO15/RXD |
|
||||
| 08 Ground | 06 Ground |
|
||||
|
||||
|
||||
Driver/Receiver
|
||||
---------------
|
||||
|
||||
While the LocalTalk bus is half-duplex, LocalTalk and PhoneNet dongles use a hybrid transformer to accommodate the SCC's separate TxD and RxD lines. Because a PhoneNet dongle was used for the prototype, a pair of SN65HVD08 were used, one as a receiver and one as a driver.
|
||||
|
||||
Other RS-422/485 drivers may be suitable, but it is important to experimentally verify that their receivers output a logic '1' when the bus is not being driven.
|
||||
|
||||
### Connections
|
||||
|
||||
| Receiver SN65HVD08 Pin | PIC12F1840 Pin | LocalTalk/PhoneNet |
|
||||
| ---------------------- | -------------------- | ------------------ |
|
||||
| 01 R | 04 RA3/LocalTalk In | |
|
||||
| 02 !RE | 08 Ground | |
|
||||
| 03 DE | 08 Ground | |
|
||||
| 04 D | | |
|
||||
| 05 GND | 08 Ground | SGnd |
|
||||
| 06 A | | RxD+ |
|
||||
| 07 B | | RxD- |
|
||||
| 08 Vcc | 01 Supply | |
|
||||
|
||||
| Transmitter SN65HVD08 Pin | PIC12F1840 Pin | LocalTalk/PhoneNet |
|
||||
| ------------------------- | -------------------- | ------------------ |
|
||||
| 01 R | | |
|
||||
| 02 !RE | 03 RA4/Driver Enable | |
|
||||
| 03 DE | 03 RA4/Driver Enable | |
|
||||
| 04 D | 02 RA5/LocalTalk Out | |
|
||||
| 05 GND | 08 Ground | SGnd |
|
||||
| 06 A | | TxD+ |
|
||||
| 07 B | | TxD- |
|
||||
| 08 Vcc | 01 Supply | |
|
||||
Loading…
Reference in New Issue