PC Documation M200 μC Serial Communication Protocol

Abstract

This file describes the communication design via RS232 to the microcontroller driver software that was written for controlling the Documation M200 punch card reader.

This protocol is mainly ASCII based and designed with the target for a lightweight microcontroller implementation (using the C programming language) and a client application, running on a computer. Alternatively, it is supposed to be human readable at a terminal, so an human shall be able to replace the client program on a PC.

Revision

Version 1.0.0

First write down from some scratch paper

Contents

1. Motivation
2. Definitions
3. Hardware wiring and RS232 settings
4. General protocol layout
5. Client request codes
6. Server response code
7. Punch card representations

• APPENDIX A: Binary Punch Card Representation (Douglas Jones)

1. Motivation

In 2009 I've programed a microcontroller control and read out the data from a punch card reader. It was supposed that the microcontroller software translates the data and prints them out to the connected computer.

Since punch cards, having 80 columns with 12 bit each, are a bit weird to handle on modern computer platforms (all talking in 8 bit wide bytes), the question of how to represent such a punch card on a computer arised soon. Furthermore, this Documation M200 punch card reader device isn't complex at all, but there are nevertheless some status and error signals that would be nice to be transfered to the computer, too. After all, it's supposed that humans could use that device with their computers without being freaks. So there must be some running some cient program on the computer that actually accepts the data from the microcontroller. For processing this workflow, there's a need of a standarized protocol.

Well, we're in 2009, today there are many, many protocols outside to use. But there's another point: Users should be able to use the microcontroller without the client program, because I don't want to bind the microcontroller to one special client program.

Since we are using RS232 as transportation layer between computer and microcontroller, we already have some sort of flow control and handshaking, so we need only some data model. Using ASCII is quite the only choice if humans should be able to handle it directly from terminals.

Summing up, we need a protocol with these features:

• ASCII protocol
• Efficient in implementation (small memory footprint on microcontroller)
• Some kind of request code set, some kind of server response set
• Compact transmission of data (since RS232 throughput is quite low)

The proposed protocol in the present document is intended to cover all these issues.

2. Definitions

At first I want to introduce some simple abbreviations:

Reader

refers commonly to the punch card reader Documation M200

Server

μC

This is the Microcontroller (with the software running on it)

Client

Application

Frontend

This is the PC in general or some application running on it, like a terminal or a graphical frontend.

3. Hardware wiring and RS232 settings

This is a rather unimportant chapter concerning how to get a RS232 communication line to the microcontroller.

Discussion about RS232 male and female sockets are too specific at this point, since they only cover our needs. Our microcontroller board is equipped with a RS232 female socket. Since computers are using typically RS232 male sockets, you will need an ordinary RS232 connection cable. The connection is not crossed.

We will use hardware flow control with 8bit bytes and no parity bits. Currently we are using 36400 baud.

4. General protocol layout

This is a typical communication:

100 foo bar bar barz...

5. Client request codes

List of codes:

6. Server response codes

7. Punch card representations

As you can already extract from the response code table, there are three punch card formats:

• 700 range: Debug output. Ideal for actually viewing the card on the screen without any frontend program, but scales very bad because there are about 1600 bytes to transfer for each card, and that takes many time, so card reading cannot be performed in real time any more
• 800 range: Binary output. Ideal for high speed application processing. One card expands to exactly 123 bytes (almost "compressed") data.
• 600 range: Hexadecimal output. Maybe a good tradeoff for high speed "real time" debugging: With consuming about 900 bytes, its almost 2 times faster than debugging output, but still about 8 times slower than binary output

The only real world data format is the binary format, named after the inventor, Douglas Jones. See APPENDIX A for details how to model one card. We are using this fully featured syntax, so one card expands to exactly 123 bytes.

APPENDIX A: Binary Punch Card Representation (Douglas Jones)

This appendix is a copy of Emulated Punch Card Decks by Douglas W. Jones, Part of the Punched Card Collection.

The following file format is proposed for use on such emulators:

One column of a card holds 12 bits; in the file, we lay them out as follows, with ones representing punched holes:

      Top                  Bottom

        _ _ _ _ _ _ _ _ _ _ _ _

       |_|_|_|_|_|_|_|_|_|_|_|_|

      12 11 0 1 2 3 4 5 6 7 8 9

       |     |                 |

       |Zone |     Numeric     |

A design dilemma presents itself: There are two rational ways to map card columns to byte sequences, highbyter (or bigendian) and lowbyter (or littleendian). The choice is arbitrary. Here, we will be bigendian as follows:

               column 1                column 2

       |_ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _|

       |_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|

       |               |               |               |

             byte 1          byte 2          byte 3

This prefix allows extension to H82, where both columns 0 and 81 are represented -- note that some verifiers punched in column 0, and that IBM 026 keypunches could generally punch column 81. Emulators should generally accept H82 files and ignore the extra leading and trailing columns! Similarly H51 can be used to represent the 51 column cards used for some business forms, and H53 can be used to represent these cards with data punched in columns 0 or 52. Mixing multiple card sizes in one deck was never practical, so emulators need not support it, and most emulators need only support H80 (and H82, but ignoring columns 0 and 81).

To support keypunch emulators and card deck display and editing programs, a 3 byte prefix is needed on each card. Emulators that read the holes on a card should ignore this prefix (other than using it to verify that a card-file is indeed being read). The prefix format is as follows:

             byte 1          byte 2         byte 3

       |_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _|

       |1|_|_|_|_|_|_|_|1|_|_|_|_|_|_|_|1|_|_|_|_|_|_|_|

       | | Color | |cut| | |     |form | |    logo     |

                  |       |   |

                corner    | punch

                        interp

      Color:  cream (unbleached)      0000 default!

              white                   0001

              yellow                  0010

              pink                    0011

              pale blue               0100

              pale green              0101

              pale orange             0110

              pale brown              0111 rare

              yellow stripe           1010 very common!

              pink stripe             1011

              pale-blue stripe        1100

              pale-green stripe       1101

              pale-orange stripe      1110

              pale-brown stripe       1111

      Corner: round   0  default

              square  1

 

      Cut:    neither 00 rare

              right   01 common

              left    10 default

              both    11 rarest

 

      Interp: no      0  default

              yes     1

 

      Punch:  none            000 punch didn't print

              026 Commercial  001 older, with "&-#@.¤$*,%"

              026 FORTRAN     010 older, with "+-='.)$*,("

              029             100 default

 

      Forms:  no printing  000

              IBM 5081     001 all numeric rows marked (default)

              IBM 507536   010 only colmns 1, 80 and row 0 marked

              IBM 5280     011 8 fields, 3-3-3-1 subfields

              DSI 327      100 8 fields, 5-5 subfields

              IBM 733727   101 20 fields, 4 chars each

              IBM 888157   110 FORTRAN column layout

                           111

              

 

      Logo:   none                                  0000000 \ default may

              (your institution's logo here)        0000001 / vary!

              IBM 821924 (701 binary)

              IBM 821162 (701 assembly)

              IBM 874266 (7090 assembly)

              Rechenzentrum RWTH Aachen 

              University of Alaska

              University of Arizona Computer Center

              Battelle Laboratories

              Bell Labs (old style)

              Bell Labs (GE 600, new style)