Protocols: Communications Control Blocks (CCB)

Since this was written we have introduced Hash commands. The Open_Serial hash command make this much simpler to do, so 99% of the time you won;t need what follows

Most protocols have a number of attributes that can be controlled, and need to be set up. This may be fairly obvious things like the Baud rate (strictly speaking not part of a protocol, but a very important setup parameter) or subtler, protocol-specific things.

It takes up to 21 bytes of information (possibly more in the future) to fully specify the settings for a protocol. These bytes get stored by you, the programmer, as a table in NVEM page 0 (if that means nothing to you, don't worry, we will give you examples later). The table is called a Communications Control Block (CCB), and is created as you edit your program ("Set at Design Time").

This discussion is generalized; it does not pertain to any specific protocol.

Once the CCB is set up in NVEM0, it is invoked during program run by executing a ComSetCCB instruction. The ComSetCCB instruction contains an argument that points to the CCB.

In summary, to switch to a protocol other than the default SPLatLink, you need to:-

1. At design time create a Communications Control Block (CCB) that selects the required protocol and sets its parameters.
2. When your program runs, have it execute a ComSetCCB instruction that points to the CCB.

In a program, this would look something like the following. Don't try yet to fathom the details of the CCB; that will be explained under each individual protocol. Also, be aware the the CCB structure may vary between protocols, according to their individual needs.

;Example of protocol switching

;The following instruction would be in the body of the program,
;most likely in a program initialization sequence:

        ComSetCCB       ModBus_CCB      ;Point processor at CCB for ModBus
        ...

;The following is in the NVEM0 segment, which must be located
;after all executable program lines (i.e. at the end of the program)

        NVEM0           ;Demarcation between program space and NVEM page 0 space

ModBus_CCB:     	   ;Communications Control Block for ModBus master
        NV0Byte         2       ;Protocol = ModBus RTU Master
        NV0Byte         0       ;Device address (N/A)
        NV0Byte         0       ;Character profile (8,N,1) *Must match slaves!*
        NV0Byte         7       ;Baudrate = 38400 *Must match slaves!*
        NV0Byte         255     ;Not used
        NV0Byte         255     ;Not used
        NV0Byte         255     ;Not used
        NV0Byte         255     ;Not used
        NV0Byte         255     ;Not used
        NV0Byte         5       ;Message gap x 10mS
        NV0Byte         15      ;Query timeout x 10mS
        NV0Byte         3       ;Query attempts before failure
        NV0Byte         255     ;Not used
        NV0Byte         255     ;Not used
        NV0Byte         255     ;Not used
        NV0Byte         255     ;Not used
        NV0Byte         255     ;Not used
        NV0Byte         255     ;Not used
        NV0Byte         255     ;Not used
        NV0Byte         255     ;Not used

We mentioned earlier that in the first 10 seconds after a reset, the controller is locked in SPLatLink protocol (as used by SPLat/PC) by a startup timer. The instruction ComTestStartTimer will test if that startup timer is running, and return a True result in X if it is. You can then branch your program using a GoIfT or GoIfF.

If you ignore the startup timer and just do a ComSetCCB, the whole processor will stall (block) until the timer expires. You might write a splash screen (startup message) to the LCD before starting the delay. You could also do anything that is required to "make safe" your machine, and also initialize any values that will be transmitted over the protocol once it starts running.