Experimental Physics and
Industrial Control System

Dirk Zimoch <[email protected]> · Tue, 21 Sep 2010 09:24:28 +0200

Hello Gorka,
So the LO and HI are parts of one 16 bit value, not two different
values. That was not clear to me from your previous mails.
I would suggest a protocol like this:
c4 { # address hi,lo in parameters 1,2
  MaxInput = 4;
  out 0xc0 0x04 0xFB $1 $2 0x00 0x00 0x00 0x00 "%<xor>";
  in  "%2r%*2r"; # read 16 bits, discard inverse
}
If signed/unsigned matters, then %02r stands for an unsigned value and
%2r stands for a signed value.
c5 { # address hi,lo in parameters 1,2
  MaxInput = 4;
  out 0xc0 0x04 0xFA $1 $2 0x00 0x00 0x00 0x00 "%<xor>";
  in  "%4r"; # read 32 bits
}
If the 32 bit value is a float, use %4R instead of %4r.
I use MaxInput here because the protocol has a fixed input length
instead of terminators.
These protocols use a fixed address for each record.
In the INP link specify
INP("@devwbc6600.proto c4($(HI),$(LO)) $(PORT) $(A)")
and pass HI and LO as macro substitutions to the template.
If you want to be able to change the address at run-time, you may want
to store the address in an other record, let's say a longout and pass
the name of that record to the protocol:
c4 { # name of address record in parameter 1
  MaxInput = 4;
  out 0xc0 0x04 0xFB "%(\$1.VAL).2r" 0x00 0x00 0x00 0x00 "%<xor>";
  in  "%2r%*2r"; # read 16 bits, discard inverse
}
INP("@devwbc6600.proto c4($(P):$(R):C4:ADDR") $(PORT) $(A)")
Dirk

Gorka Ronda wrote:

I send the information appended to previous mail but without text format, for future revisions:

1. INTRODUCTION
The commands are part of the protocol for RS232 communication between the device and a PC. The protocol is based on data frames. Each command the device receives will be a data frame. This data frame contains always the same number of bytes. The peripheral for the serial communication of DSP (SCI) has a 16-byte FIFO buffer. It is capable of receiving up to 16 bytes without the DSP has to perform any operation. Once the 16 bytes received an interrupt is generated, and within this interruption we analyze the 16 bytes of the received frame.In the protocol, the length of the frame is of 10 bytes. 

2. DESCRIPTION OF THE FRAMES OF COMMUNICATION
The definition of the 10 bytes of the frames of communication is:
Byte 0 Byte 1 Byte 2 Byte 3 Byte 4 Byte 5 Byte 6 Byte 7 Byte 8 Byte 9
Comm. Index ~Index Parameter 1 Parameter 2 Parameter 3 CRC

Byte 0: Command indicator. There should always be 0xC0.
Byte 1: Command index (there are 17 commands).
Byte 2: Complement to 1 of command index.
Byte 3: Upper part of the parameter 1.
Byte 4: Lower part of the parameter 1.
Byte 5: Upper part of the parameter 2.
Byte 6: Lower part of the parameter 2.
Byte 7: Upper part of the parameter 3.
Byte 8: Lower part of the parameter 3.
Byte 9: CRC of the bytes 0 to 8.

3. COMANDS THAT I WANT TO CALL FROM EPICS, 4 AND 5
Command 4. Request for 16-bit variable
Byte 0	Byte 1	Byte 2	Byte 3	Byte 4	Byte 5	Byte 6	Byte 7	Byte 8	Byte 9
0xC0	0x04	0xFB	        Add HI	Add LO	     x	            x	            x	             x	          CRC
Returns the value of a variable of 16 bits stored in the memory address indicated by add HILO. This command does not distinguish types of variables signed, unsigned... Who makes the call to this command must know which type of variable will s/he read and act upon the data received.
The device must answer:
Byte 0	Byte 1	Byte 2	Byte 3
Val. HI	Val. LO	Val. ~HI	Val. ~LO

Command 5. Request for 32-bit variable.
Byte 0	Byte 1	Byte 2	Byte 3	Byte 4	Byte 5	Byte 6	Byte 7	Byte 8	Byte 9
0xC0	0x05	0xFA	         Add Hi	Add LO	    x	            x	            x	            x	          CRC
Returns the value of a variable of 32 bits stored in the memory address indicated by add HILO. This command does not distinguish types of variables float, signed, unsigned ... Who makes the call to this command must know what type of variable will s/he read and act upon the data received.
The device must answer:

Byte 0	         Byte 1	    Byte 2	        Byte 3
Bits 24-31	     Bits 16-23	  Bits 15-8  	Bits 0-7

________________________________________
De: Gorka Ronda
Enviado el: jueves, 16 de septiembre de 2010 18:37
Para: Dirk Zimoch
CC: [email protected]
Asunto: RE: Stream Device With Parameters
Thanks Dirk,
As you requested, I append to this mail part of the device documentation to know what C4 and C5 (Command 4 and 5) do.
Don't hesitate to ask for more information if you need it.
Gorka
 ________________________________________
De: Dirk Zimoch [[email protected]]
Enviado el: jueves, 16 de septiembre de 2010 15:31
Para: Gorka Ronda
CC: [email protected]
Asunto: Re: Stream Device With Parameters
Typos in my previous mail:
Hi Gorka,
I probably did not understand completely what you wanted. You want to be
able to use *different* lo and hi values each time the record processed?
If that is the case you have to store the values in some record. For
example in an "ao" record. (There you can even scale it from "user
units" in VAL to integers in RVAL. See "ao" documentation.)
So let's now assume the two values are in stored in $(P):$(R):C4:LO.RVAL
and $(P):$(R):C4:HI.RVAL. Then you can use redirection to access these
values. You have to give the record names (or the common prefix) to the
protocol as a parameter like this:
field(INP, "@devwbc6600.proto c4($(P):$(R):C4) $(PORT) $(A)")
and use the name in $1 for two redirections to fetch LO and HI:
out 0xc0 0x04 0xfb "%(\$1:LO.RVAL)r%(\$1:HI.RVAL)r" 0x00 0x00 0x00 0x00
"%<xor>";
The %r converter just outputs the least significant byte of the
mentioned record field.
It would really help to know what the "C4" command actually does. Can
you give me a link to the device documentation?
Dirk

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System