RE: Stream Device With Parameters

[Gorka Ronda <g.ronda@jema.es>]

>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)")

Thanks Dirk, that is exactly what I want to do. But how to give value to $(P):$(R):C4:ADDR record without passing that values to my device's buffer?

Now, I'm putting a value in $(P):$(R):C4:ADDR with the command:

dbpf wbc6600:Test:C4:ADDR 0x0457

Or with $(P):$(R):C4:HI and $(P):$(R):C4:LO records, with the commands:

dbpf wbc6600:Test:C4:HI 0x04
dbpf wbc6600:Test:C4:LO 0x57

And then I process my C4 sending the 0xc0 0x04 0xFB $1 $2 0x00 0x00 0x00 0x00 "%<xor>" bytes, with:

dbtr wbc6600:Test:C4

The problem is that my device receives first the 0x04 and 0x57 and then the C4 bytes (0xc0 0x04...), when I would like only to receive the C4 bytes. How can I specify the value of $(P):$(R):C4:ADDR without sending it to my device? I have to use another command instead of dbpf? I have read something about not processing the record with PP and NPP parameters, it can be an option? Another option that I've been looking to, is the use of links with FLNK, DOL,... fields, it can be the solution? If some of these is the solution, how I would define the record and protocol?

Thanks in advance,

Gorka


-----Mensaje original-----
De: Dirk Zimoch [mailto:dirk.zimoch@psi.ch] 
Enviado el: martes, 21 de septiembre de 2010 9:24
Para: Gorka Ronda
CC: tech-talk@aps.anl.gov
Asunto: Re: Stream Device With Parameters

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: tech-talk@aps.anl.gov
> 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 [dirk.zimoch@psi.ch]
> Enviado el: jueves, 16 de septiembre de 2010 15:31
> Para: Gorka Ronda
> CC: tech-talk@aps.anl.gov
> 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
> 
>