This is half the duration for a legal bump, technically, but I have substantive contents to add to this topic. On geekboy's request, I want to quickly document the protocol that the Arduino in an Arduino-based gCn system uses to communicate with the gCn client:
General Notes
:: The client expects a serial speed of 115200 baud.
:: The client will reset when the Arduino initializes itself and sends ":RESETs\n" (\n is a newline character)
:: Other than the 's' echo character discussed in the next section and the ":RESETs\n" message, all Computer -> Arduino frame contents bytes (ie, the two-byte prolog, recipient, sender, size, data, and one-byte footer) are all send as twoASCII characters. For example, a message from calculator [0101010101] to [0202020202] with one content byte of 0xAA would look like this (but without the spaces):
Code:
Computer -> Arduino Protocol
:: No differentiation is made between direct and broadcast frames.
:: Packets from the computer to the Arduino always start with the two decimal bytes 255, 137 (ie, the ASCII-encoded hex string "FF89". Any buffer contents not prefaced with those two bytes are flushed out, and as the Arduino pulls bytes out and discards them, any 's' characters it reads makes it respond with an 's' character.
:: If the packet from the computer to the Arduino is prefaced with the proper 2 bytes, the remainder of the packet is first 5 bytes of recipient address and 5 bytes of sender address. Next is 2 bytes of the data length. This is not formatted the same as canonical CALCnet. The low 7 bits of the first byte are the least significant 7 bits of the size, and the low 7 bits of the second byte are the most significant 7 bits of the size. Therefore, a 129-byte CALCnet frame would have size bytes 0x01, 0x01 (rather than 0x81, 0x00). You must mask off the lower 7 bits of each byte. Why? Because RS232 has a bad habit of stripping of the most significant bit of bytes.
:: After the size comes the actual contents, (size) bytes worth.
:: The packet ends with a decimal 42 (ie, the string "2A"), which means you should stop pulling data out of the serial buffer.
Arduino -> Computer Protocol
:: As with the computer -> Arduino protocol, all address, size, and data bytes are send as ASCII-encoded nibbles.
:: Any literal "f\n" string sent from the Arduino to the computer means a receive error occurred in the middle of the frame. All data received from that frame so far by the computer should be discarded.
:: All frames sent to the computer start with a literal '|' (pipe) character
:: Next 10 bytes are the 5 sender address bytes, encoded as ASCII. This is the opposite of CALCnet frames, where the receiver address is sent first.
:: This is followed by a literal '.' (period).
:: Next 10 bytes are the 5 receiver address bytes, encoded as ASCII.
:: This is followed by a literal ',' (comma).
:: Next are two bytes of size. See above for how 14 bits of address are distributed as 7 bits each in two bytes.
:: This is followed by a literal ':' (colon)
:: Now all the data, each byte encoded as two ASCII characters.
:: Next, a '>', but ONLY if a checksum was received for this frame.
:: Finally, a "\n" newline.
Fun Fact: If you run the gCn Client in verbose (-v) mode, you can see all this going back and forth!
General Notes
:: The client expects a serial speed of 115200 baud.
:: The client will reset when the Arduino initializes itself and sends ":RESETs\n" (\n is a newline character)
:: Other than the 's' echo character discussed in the next section and the ":RESETs\n" message, all Computer -> Arduino frame contents bytes (ie, the two-byte prolog, recipient, sender, size, data, and one-byte footer) are all send as twoASCII characters. For example, a message from calculator [0101010101] to [0202020202] with one content byte of 0xAA would look like this (but without the spaces):
Code:
"FF89 02020202020101010101 0100 2A"Computer -> Arduino Protocol
:: No differentiation is made between direct and broadcast frames.
:: Packets from the computer to the Arduino always start with the two decimal bytes 255, 137 (ie, the ASCII-encoded hex string "FF89". Any buffer contents not prefaced with those two bytes are flushed out, and as the Arduino pulls bytes out and discards them, any 's' characters it reads makes it respond with an 's' character.
:: If the packet from the computer to the Arduino is prefaced with the proper 2 bytes, the remainder of the packet is first 5 bytes of recipient address and 5 bytes of sender address. Next is 2 bytes of the data length. This is not formatted the same as canonical CALCnet. The low 7 bits of the first byte are the least significant 7 bits of the size, and the low 7 bits of the second byte are the most significant 7 bits of the size. Therefore, a 129-byte CALCnet frame would have size bytes 0x01, 0x01 (rather than 0x81, 0x00). You must mask off the lower 7 bits of each byte. Why? Because RS232 has a bad habit of stripping of the most significant bit of bytes.
:: After the size comes the actual contents, (size) bytes worth.
:: The packet ends with a decimal 42 (ie, the string "2A"), which means you should stop pulling data out of the serial buffer.
Arduino -> Computer Protocol
:: As with the computer -> Arduino protocol, all address, size, and data bytes are send as ASCII-encoded nibbles.
:: Any literal "f\n" string sent from the Arduino to the computer means a receive error occurred in the middle of the frame. All data received from that frame so far by the computer should be discarded.
:: All frames sent to the computer start with a literal '|' (pipe) character
:: Next 10 bytes are the 5 sender address bytes, encoded as ASCII. This is the opposite of CALCnet frames, where the receiver address is sent first.
:: This is followed by a literal '.' (period).
:: Next 10 bytes are the 5 receiver address bytes, encoded as ASCII.
:: This is followed by a literal ',' (comma).
:: Next are two bytes of size. See above for how 14 bits of address are distributed as 7 bits each in two bytes.
:: This is followed by a literal ':' (colon)
:: Now all the data, each byte encoded as two ASCII characters.
:: Next, a '>', but ONLY if a checksum was received for this frame.
:: Finally, a "\n" newline.
Fun Fact: If you run the gCn Client in verbose (-v) mode, you can see all this going back and forth!
So we're looking good for ordering PCBs and stencils at the end of the month-ish, I guess? I also need to find me a toaster oven and get practicing on toaster oven reflow. Which means I need to get this DX order ordered so I'll have solder paste and flux.