USBee DX

USBee DX Home

Logic Analyzer

Oscilloscope

Mixed Signal OScope

Voltmeter

Signal Generator

Bus Decoders

Data Extractors

Data Logger

Frequency Counter

Remote Controller

PWM Controller

Frequency Generator

I2C Controller

Pulse Counter

Toolbuilder Source

Downloads

FAQ

Buy

Quick Links

Software Download

Getting Started Guide

Users Manual

USBee DX PacketPresenter™

Overview

Included with the USBee DX, the PacketPresenter™ displays the bus traffic that is being transmitted between ICs or system components in a graphical, easy to understand packet format that can be customized to your specific design.

 
With standard logic analyzers, engineers have been accustomed to counting bits, manually decoding protocols, and parsing embedded bus traffic into useable fields.  The PacketPresenter does this for you automatically.  With the PacketPresenter, counting bits on a logic analyzer is a thing of the past.

The PacketPresenter translates standard logic analyzer traces into graphical communication packets that are easy to read and understand.  The PacketPresenter saves you time by automatically extracting the protocol information of interest from raw bus traffic and presenting it in a clear and simple format. You no longer need to count bits or decode waveform traces to find out what your system is saying.

Many existing Protocol Decoders understand only a single protocol.  The PacketPresenter, on the other hand, is customizable to fit your custom and unique embedded bus protocol using a simple and intuitive configurable PacketPresenter Definition file.  And unique to the USBee DX, the PacketPresenter gives you a detailed look into how the packet communications on your embedded bus relates to the actual voltage-versus-time waveforms of the bus signals.

Debugging is performed by viewing and analyzing the PacketPresenter output and relating it back to the logic analyzer waveforms and decoded bus traffic for the various types of busses.  For example, you can see the PacketPresenter display of HDLC communication packets, and correlate that back to the raw byte stream that was decoded from the ASYNC bus, as well as the voltage versus time waveforms of the bus Tx and Rx lines.

The waveforms show the activity on the signal lines:

The Bus Decoders show the data contained on that bus:

Finally, the PacketPresenter parses that data into fields:

The PacketPresenter feature runs alongside the existing bus decoders.  It takes the output of raw binary data from the bus decoder and parses the stream according to a PacketPresenter Definition File for the intent of displaying the communications in easily understood graphical displays. 

Protocols are defined using a text file, called a PacketPresenter Definition File, which specifies the fields within the protocol and how to display that information on the screen.  It is generic enough that you can create your own protocol decoders for your own custom bus types.

Each PacketPresenter Definition File correspond to one single bus type, and the incoming bytes from that bus are inputs for the decoding process.  This steam of data is called an incoming Data Stream and it is handled by a Protocol Processor.  Each Protocol Processor takes a single incoming Data Stream that is broken into Packets, parsed into Fields and either displayed as a field on the screen, ignored, and/or sent to a new Protocol for further processing (as in an N layer protocol). 

Each Protocol Processor defines how to break the stream into Packets, and how to break the Packets into Fields.  These Fields can then be displayed or sent to another Data Stream for further processing.

Below shows a sample PacketPresenter output screen.

USBee DX Home Page
Add a USBee DX to your shopping cart

Each digital waveform on the screen can be defined as a different bus (I2C, SPI, etc.) in the Channel settings dialog box by clicking on the white box to the left of the signal name.  Below shows the Channel Settings dialog box.

To enable the PacketPresenter for this channel, check the “Display the Data Stream using the following PacketPresenter definition file” checkbox.  Then choose the PacketPresenter definition file by clicking the button to the right.  Once you choose the file, you can edit the contents by clicking the “Edit File” button.

Once the PacketPresenter is enabled all bus decodes will be processed through the PacketPresenter as well as the original bus decoder.

USBee DX Home Page
Add a USBee DX to your shopping cart

Once the bus is defined and the PacketPresenter is setup with a PacketPresenter definition file, right clicking and dragging on the waveform will not only decode the raw data from the bus (as specified in the Channel Settings), but will also parse the data based on your PacketPresenter definition file.

If the PacketPresenter is not enabled, only the decoded data is shown as seen below.

Enabling the PacketPresenter shows the PacketPresenter output, with the original decoded data in a minimized window as in the following screenshot.

You can show the raw decoded data at the same time by restoring the minimized window as shown in the following screenshot.

USBee DX Home Page
Add a USBee DX to your shopping cart

You can copy the contents of the PacketPresenter output window to other programs in a number of ways.

First, you can copy the screenshot of the window by selecting the window and pressing Alt-PrtScr on your keyboard.  This copies the image of the window to the Windows clipboard and you can paste that image into any program that accepts images.

You can also use the Edit | Copy menu item.  If the textual decode data window is active, the selected text is copied to the clipboard.  To select text, just click and drag across the text you would like to highlight.  If the PacketPresenter output window is highlighted, all packets starting with the packet at the top of the window are copied to the clipboard.  When pasting the data to other programs, it will paste the data as an RTF file if possible and text otherwise. 

You can also save the PacketPresenter output to either a Text file or an RTF file (Rich Text Format).   The text file output is a textual representation of the packets as seen below.

 Layer: CYPRESSRFIC   DIR     INC      ADDRESS     READDATA 

  Time: 615.2797ms    Read   False   CHANNEL_ADR      0     

  Layer: USBBUS     PID   ADDR   EP    PID            INDATA            HS  

 Time: 616.0198ms   IN     2     0    DATA0   22 2A 00 07 05 81 03 08   ACK 

  Layer: USBBUS     PID   ADDR   EP    PID            INDATA            HS  

 Time: 617.0197ms   IN     2     0    DATA1   00 0A 09 04 01 00 01 03   ACK 

  Layer: USBBUS     PID   ADDR   EP    PID            INDATA            HS  

 Time: 618.0197ms   IN     2     0    DATA0   01 02 00 09 21 11 01 00   ACK 

  Layer: USBBUS     PID   ADDR   EP    PID            INDATA            HS  

 Time: 619.0197ms   IN     2     0    DATA1   01 22 D1 00 07 05 82 03   ACK 

  Layer: USBBUS     PID   ADDR   EP    PID    INDATA   HS  

 Time: 620.0197ms   IN     2     0    DATA0   0A0008   ACK 

Saving data to an RTF file format saves the graphical nature of the packets and can be read by many word processing programs, such as Microsoft Word and WordPad.  Below is a screenshot of data saved to an RFT file and viewed using WordPad.

USBee DX Home Page
Add a USBee DX to your shopping cart

You can change the size of the fonts used by the PacketPresenter by selecting the View | Larger or View | Smaller menu items.  Below are examples of different size fonts.

USBee DX Home Page
Add a USBee DX to your shopping cart

Once displayed, you can search for the next packet that contains certain fields that match your criteria.  Below is the Search Packet dialog box that is shown by using the View | Packet Search menu item.

In the leftmost textboxes, type the Field Label.  Then select the comparator operator (equals, not equals, less than, greater than…) and finally the value that the field is to be compared against.  Finally, if there is more than one field in the search list, choose whether to AND or OR the search terms.  When you click Find, the next packet in the list (starting from the top of the window) will be placed at the top of the window.  You can search forward or backward by selecting the appropriate radio button on the right.

Once displayed, you can filter the output to only show packets that contain certain fields that match your criteria.  Below is the Filter Packet dialog box that is shown by selecting the View | Packet Filter along with the resulting PacketPresenter output.

In the leftmost textboxes, type the Field Label.  Then select the comparator operator (equals, not equals, less than, greater than…) and finally the value that the field is to be compared against.  Finally, if there is more than one field in the search list, choose whether to AND or OR the search terms.  When you click Filter On, only the packets matching the criteria are displayed.  To turn off the filtering, click on the Filter Off button.

USBee DX Home Page
Add a USBee DX to your shopping cart

Using the Window | Tile menu you can choose to show the open windows Horizontally, Vertically or Cascaded as displayed below.

USBee DX Home Page
Add a USBee DX to your shopping cart

When you click on a packet in the PacketPresenter output window, the entire packet is highlighted and the associated raw decoded data is highlighted in the decode window.  The original waveform screen is also shifted to center the start of the packet in the logic analyzer window. 

This feature allows you to correlate what is shown in the PacketPresenter window to the actual waveform on the logic analyzer that created that packet.

USBee DX Home Page
Add a USBee DX to your shopping cart

You can place the cursors using the PacketPresenter window by using the left and right mouse buttons.  Place the mouse over the packet you want to place the cursor on and click the left or right button.  The cursors are placed at the beginning of the packets.  The resulting difference between cursors s shown at the bottom of the screen.

If more than one bus is being shown, you can measure the time between packets on different busses using the cursors as shown in the following screen.  Set the first cursor by left clicking in the first window and place the second by right clicking in the second window.

USBee DX Home Page
Add a USBee DX to your shopping cart

Each PacketPresenter Definition file defines how the incoming data stream is represented in the PacketPresenter screen of the USBee DX MSO application.  These PacketPresenter Definition files are in text format and are easily created using a simple text editor.

Each bus defined in the USBee DX MSO application can have a different PacketPresenter Definition File.

The intent of the PacketPresenter is to produce a series of 2 dimensional arrays of labels and values to be displayed as below by the user interface. 

It is the PacketPresenter Definition File that defines how the data is to be parsed and displayed.

 Comments are started with a semicolon ( ;) and go until the end of the line.

Constants are fixed numbers anywhere in the file.  These constants can be expressed as decimal, hex, or binary using suffixes after the value.  Decimal has no suffix.  Hex uses the suffix “h”.  Binary uses the suffix “b”.

So,

16 = 10h = 10000b
244 = F4h = 11110100b

Gain and offset values used in the Fields section are always in decimal and can contain decimal places.

Each PacketPresenter Definition File has the following syntax that separates the file into sections that correspond to the Channel definition and each of the Protocol Processors.

[Protocol]
. . .
[Protocol]
. . .
[Protocol]
. . .

Each Protocol Section defines what the incoming data stream looks like, how to break the data stream into packets, and how to parse out the fields in each of the packets.  Multiple Protocol Sections can be defined for passing data from one Protocol Section to another.

Each Protocol Section has the following syntax that specifies the packetizing and parsing into fields.

[Protocol]
name = ProtocolName
[Packet]
   packet processing settings
[Fields]
   packet field processing settings
   packet field processing settings
   packet field processing settings
   . . .

The ProtocolName is a label that uniquely identifies this protocol processor.  This name is used in the Field definitions to define which Protocol to route a field of data (for use by multilayer protocols).

The highest level Protocol is the first protocol in the file.  This is the Protocol Processor that is sent the incoming data stream from the bus as defined in the Channel Settings Dialog Box for that waveform.

Some busses are by nature byte oriented, while others are bit oriented.  The following table shows the type of bus.

Each bus type also can have certain bus events that may be significant in the decoding of a protocol.  One such event is an I2C Start Bit.  While the Start bit is not an actual bit in the data stream, it does signify to the I2C slave that a certain transaction is taking place.  These bus events are inserted into the data stream and can be used (or ignored) by the protocol processors.  The list of Bus Events supported is in the following table.

Table 1. Bus Event Types

A Bus Event of 127 (7Fh) is a special event that occurs at the end of a packet of data that is sent from one protocol to another.  This can be used to end the packet sent to the new layer using the [END] section and the type = event in the new protocol level.

Some buses can also have more than one data signal used in the protocol.  One example of this is the SPI bus, where for each byte sent on the MOSI line there is one byte received on the MISO line.  In the protocol definition you can specify which of the signals to expect the next field of data to be sent on.  In the SPI example, you may get a Command and Length field on one signal, followed by the read data back on the other signal.  The decoder would take that into account and show the command, Length and Data as a single transaction.

Multiple signals are differentiated in the PacketPresenter using the X and Y channel specifiers.   These channels are specified by selecting the signals to use for that bus in the Channel Settings dialog box.  The following table shows which signals are the X and Y signals.

Table 2. Channel X and Channel Y Definitions Per Bus Type

The Packet section defines how a packet is bounded and what, if any, preprocessing needs to be done on the packet before the fields can be processed.

[Packet]

[Start]

       . . .  ; How does a packet start?
[End]
       . . .  ; How does a packet end?

[Decode]
       . . .  ; What decoding needs to be

              ; done to get real data?

The Start and End sections define how a packet is bounded.  The available packet bounding Types are defined below:

For [START]

Next: The next byte or bit is assumed the start of a packet
Signal:  An external signal indicates the start of a packet
Value:  A specific value in the data indicates the start of a packet
Event:  A bus specific bus Event or Events indicates the start of a packet

For [END]

Next: The next byte or bit is assumed the end of a packet
Signal:  An external signal indicates the end of a packet
Value:  A specific value in the data indicates the end of a packet
Length:  A specific or calculated length determines the end of a packet
Event:  A bus specific bus Event or Events indicates the end of a packet
Timeout:  A packet ends after a set timeout without data or events

The start or end of a packet is the next byte or bit to arrive. 

[Packet]
[Start] or [End]
type = Next   ; Start/End of a packet is the
                   ; next byte/bit to arrive

The start or end of a packet can be indicated by a separate signal (such as a chip select or a frame signal) using the signal setting.

[Packet]
[Start] or [End]
type = signal              ; Start/End of a packet is based
                                 ; on a signal
signal = signalvalue       ; Signal number 0 - 15
level = 1            ; level the signal needs to be

The start or end of a packet can be indicated by a certain data value contained in the data using the value setting.  Multiple values can be used, where any one match starts or ends a packet. All bits in the Value are included in the resulting packet at the start of the packet.  You must also specify the number of bits that the value covers (defaults to 8 bits if not specified) using the bits keyword.  You can specify a mask value to apply to the start data and values.  When the mask value has a bit that is a 1, that bit in the value and data are compared.

[Packet]
[Start] or [End]
type = value  ; Start/End of a packet is based on a data value
mask = bitmask       ; Bitmask to apply to the data stream
value = value1       ; value that the data needs to be to start/End
value = value2       ; value that the data needs to be to start/End
value = value3       ; value that the data needs to be to start/End
bits = 8      ; how many bits in the start/End word

Only valid in the [END] section, the end of a packet can be indicated by a certain length of data.  You use the BitLength or the ByteLength keywords to specify how long the packet is.  The length can either be a fixed length expressed as a constant, or variable length based on the contents of a packet in the data stream.

type = length        ; End of a packet is based  on a length
Bytelength = length  ; How many bytes per packet

or

Bitlength = length   ; How many bits per packet

To use the contents of one of the fields as the packet length, you use the name of the field defined in the Fields section.  You can also do simple arithmetic on the field value to compute the final packet size.

type = length      ; End of a packet is based on a length
Bytelength = fieldname * 2 + 2 
            ; field holding packet size
            ; * (or /) a constant (optional)
            ; + (or -) a constant (optional)

If present, the * or / must come before the + or – offset and is executed first.

For example, if fieldname Field has the contents of 16, then the following is true:

fieldname * 2 + 2 = (16*2)+2 = 34

fieldname + 2 = 16+2 = 18

fieldname / 2 - 2 = (16/2)-2 = 6

fieldname / 2 = 16/2= 8

fieldname + 2 * 2 = invalid (* must come before offset)

fieldname - 2 / 2 = invalid (/ must come before offset)

The length of the packet includes ALL of the data from each of the data channels for that bus.  If the bus contains only one data channel (such as I2C), the length counts all data on that one bus.  If the bus has two data channels, the length refers to all data on both channels combined.

The start or end of a packet can be indicated by the reception of any of the bus specific Events.   For example in I2C you get a Bus Event for each Start Bit and a Bus Event for each Stop Bit.  In USB you get a Bus Event for each Sync word and a Bus Event for each EOP.  Available bus types are defined in Table 1. Bus Event Types.

The event value is a bitmask that includes all events that you want to use.   If any of the events occur, a packet will be started or ended.

type = Event ; Start/End of a packet is signaled by event
event = 1     ; Use Event 1. Available events depend on bus type

or

event = 3     ; Use either Event 1 or Event 2

The end of a packet is determined by a timeout since the last valid data or event on the bus.  The timeout is defined in units of microseconds.

[Packet]
[Start]
type = timeout       ; End is after timeout
timeout = 45  ; microseconds since last data/event received

CHANNELX, CHANNELY or CHANNELXorY specifies what channel is used when an event or data is defined for starting or ending a packet.  Channel X and Channel Y are different based on what the physical bus is and can be found in Table 2. Channel X and Channel Y Definitions Per Bus Type.  If it does not matter which channel the data or event occurs on (it could be either), use the CHANNELXorY keyword.

[Packet]
[Start]
type = value ; Start of a packet is based on a data value
value = 41h   ; value of data that starts the packet
bits = 8
channelX      ; data/event must be received on channel X

  or

channelY      ; data/event must be received on channel Y

  or

channelXorY   ; data/event must be received on either channel X or Y

Each packet can have encoding on the data that needs to be removed in order to see the real data.  This section defines what decoding should be done to the packet.  The entire packet from start to end is sent through the decoders.  If only select parts of the packet needs to be decoded, you must create your own Add-In decoder using the ADDIN keyword.

Available decoding types are:

Multiple decoders can be used and are processed in the order listed. 

Substitutions allow a sequence of bytes (up to 3) to be replaced with a different set (same size or less) of bytes.  They can only be used on bytestreams, not bitstreams.  Substrings define the bytes input and the bytes output.  The Substrings must not contain any spaces.  Examples of this are below:

[1]=[2]       ; Replaces all 1s with 2s

[1][2]=[3]    ; Replaces all 1 immediately  followed by 2 with 3

[1][2]=[3][4] ; Replaces all 1 immediately followed by 2 with 3 immediately followed by 4

[1][2][3]=[4] ; Replaces all 1, 2, 3 with 4

[1]=[2][3][4] ;    INVALID, the number of output bytes must be less than or equal to the input

As an example, the HDLC protocol uses the byte value 7Eh as the start and end flag of the packets and replaces all 7Eh in the data with the bytes 7Dh followed by 5Eh. It also replaces all 7Dh in the data with the bytes 7Dh followed by 5Dh.  To remove this coding you would use the lines:

[7Dh][5Eh]=[7Eh]

[7Dh][5Dh]=[7Dh]

Once the packet is delineated and decoded by the previous sections, it is ready to be displayed by the PacketPresenter.  Since each packet is made up of fields, the Fields section defines how the packet is broken up into its fields and what to do with the field data.

During processing, the Fields Section is processed one Field Line at a time in the order that they are listed in the FIELDS section.  Each Field Line is parsed against the incoming data packets. 

Once a single Field Line is successfully processed and output, the PacketPresenter starts over at the top of the Filed Lines list for the next packet.  This ensures that there is only one output packet for each input packet for a given protocol.

There are 2 types of Field Lines.  A Field Line can be conditional or unconditional.  Unconditional Field Lines are processed for any packet.  Conditional Field Lines are only processed if certain fields match a specific value.

Any Unconditional Field Line (no conditionals) generates an output line on the PacketPresenter screen.   Any Conditional Field Line that evaluates to True generates an output line on the PacketPresenter screen.    Any Conditional Field Line that evaluates to False is skipped and produces no output line on the PacketPresenter screen.  

The Field Lines should be listed with the conditional field lines first followed by an unconditional field line to catch all packets that are not explicitly defined in the conditional field lines.

Unconditional Field lines are parsed and decoded data is output for every packet that is input.  The Fields specify how to interpret the data and how to output the data.

Conditional Field Lines provide a means for defining packets whose contents vary based upon the presence of a value in another field.  An example of this is a packet that contains a Command Byte that determines the format of the rest of the packet.  A Conditional Field Line contains at least one field in the packet that includes the =Value token in the input modifiers section. 

If the data contained in the conditional fields of a packet matches the =Value specified for the field, the packet is parsed and the data is output.  If the condition field =Value does not match the incoming data, then the processor moves on to the next Field Line until it reaches the end of the Fields section.

Each Field Line in the Fields Section has the keyword FIELDS followed by a series of individual Fields.  Individual fields in a packet are separated by commas.  A Field line in the Fields Section defines an entire packet from start to end and has the form:

Fields  Field1,Field2,. . . ,FieldN

You can also insert a string to be printed out at that location in the packet by using the string ($) operator before the string to be printed. Below is an example of a field line with one string added between the fields.

Fields Field1,$String,. . . ,FieldN

Each field will be output with a Label and a Value.  For String fields, the Label is blank and the Value is the String.

Each field in the Field Line is defined using the following syntax and contains no spaces:

FieldName.InputModifiers (= value).OutputModifiers

FieldName is the name of the field.  No spaces, commas, semicolons, brackets, dollar signs, periods, or quotes are allowed in the fieldname.

Input and output modifiers change the way incoming data and output data are formatted.

InputModifiers are a string of characters that represent how many bits are in the field and how the input data is to be handled.  First is the number of bits in the field, or N if the field is a variable length.  Next is any of the following:

M: native bit order from that which came off of the bus (default)

L: inverted bit order from that which came off of the bus

X or Y: which channel the data is on (for multiline busses)

=Value: Indicates that this field MUST be this value for the entire line to be processed (Conditional)

Each modifier is a single character and multiple format modifiers can be combined. 

OutputModifiers are a string of characters that represent how to output the contents of this data. 

Output Modifiers are as follows:

I                      Ignore - no output (entire field is ignored for output)

D                     Decimal output

H                     Hexadecimal output

B                     Binary output

A                     Ascii output

TF                   True (nonzero) or False (zero)

L                      Look up the text string to print out in a matching Lookup line

*Value or /Value: a value to multiply/Divide the output value by

+Value or -Value: a value to offset the output value by

$string: string to print after the data (or in place of the data if the i flag is used).  String must be the last item in a field.  No commas, quotes, semicolons or parenthesis allowed in the string.

Sometimes a specific bus event plays a role in the packet format.  To specify that a specific bus event needs to occur at a specific time in the field sequence, place the single Bus Event value inside brackets in the Field Line.  Multiple events in a single value are not allowed, however consecutive events are allowed.  To indicate the absence of a specific bus event in the protocol, use the ! (Not) operator.

For example, if the bus is I2C, use the following to require that a Start Bit is present between field1 and field2:

Fields  Field1,[1],Field2

If there is a start bit between the 2 fields, then that Field Line will be processed.

And use the following to require that a Start Bit is NOT present between field1 and field2:

Fields  Field1,[!1],Field2

If there is a start bit between the 2 fields, then that Field Line will not be processed.

The Bus Events are defined in Table 1. Bus Event Types.

Often fields contain values that mean something unrelated to the actual number of the data.  Lookup Tables provide a way to output a string of text instead of a data value for a field.   For each field wanting to use a lookup table, use the “L” output modifier in the field format and then define the table in the FIELDS section using the LOOKUP keyword. 

The format of the Lookup table is as follows:

LOOKUP Fieldname

[value1]=$string1

[value2]=$string2

. . .

Fieldname is the name of the field associated with this lookup table.  valuen refers to the actual data value of the field.  stringn is the text string that is output instead of the valuen.

If a lookup entry is not present for the data value (not found in the Lookup Table or the Lookup Table does not exist), then the data value is output.

For example, the following table will assign the text strings for various values of the data for the CommandByte field.  When the field CommandByte,8,L is processed, the strings are output instead of the value

Lookup CommandByte  

       [0]=$Read

       [1]=$Write

       [2]=$Seek

       [3]=$Loc

       [4]=$Size

The Lookup Tables are only associated to the specific Protocol they are contained in.  Therefore you can have a CommandByte lookup table in ProtocolA that is different from a CommandByte lookup table in ProtocolB.  Within a single Protocol, you need to make sure that the Fieldnames are unique for all Lookup Tables so that the PacketPresenter can determine which table to use.

Fields contain data that may or may not be of interest to the user.  Many times the data is information that just needs to be output to the viewer.  Being binary data, each field may need to be translated numerically to mean something.  To output a field of data, you can specify the radix (if it should be shown in Hex, Decimal, binary) as well as a gain and offset to scale the data.  Finally you can add a string to the field to complete the information.  All scaling is performed first using floating point and then the output formatting is applied. 

Below is an example of a field to just output the data.

Fields Volts.16m.d*1.5-37.256$mV

This Field Line contains one field named “Volts”, which is 16 bits long in msbit first order.  The output is to be displayed in decimal format, multiplied by 1.5, offset by - 37.256 and finally appended with “mV” before output to the PacketPresenter screen.

For an input packet as follows:

0000001100001100. . .

The output would be:

which is the input 16 bits in msbfirst order (0x30C) times the gain of 1.5 plus the offset of -37.256 output in decimal format plus the “mV” string. 

Using the Conditional input modifier, many different field arrangements can be defined for the same packet.  Common uses are for parameter fields that exist for different types of commands.  If packets contain commands that determine what the remaining fields are, this syntax defines what those remaining fields are. 

Below is an example of various packet formats based on a single command field.

Fields Command.4m=0.h,Address.8m.h
Fields Command.4m=2.h,Address.8m.h,Data.8m.h
Fields Command.4m=4.h,Param1.8m.h,Param2.8m.h,Param3.8m.h

For an input packet as follows:

0010 00011101 00001000. . .

Followed by a packet:

0100 00011101 00001000 11111110. . .

The output would be:

which are the fields associated with the Command=2 and Command=4 Field Lines.

Fields that can be better expressed as text strings can be outputted as such using a Lookup table. 

Below is an example of a field that uses a lookup table.

[Fields]

Fields StartByte.8.H, CommandByte.8.L, EndByte.8.H
Lookup CommandByte  

              [0]=$Read

              [1]=$Write

              [2]=$Seek

              [3]=$Loc

              [4]=$Size

For an input packet as follows:

00100001 00000001 00001000. . .

The output would be:

which is the text associated with the Command Field 4 bits in msbfirst order (0010b = 2).

Many embedded protocols support multiple layers of protocol, where each protocol layer handles a different set of services or functions.  In these multilayer protocols, a field of data from one protocol layer may be the input data to another layer of protocol.  Routing this field of data to a new Protocol is as easy as naming the Field the same name as the Protocol.  If the Field name matches any protocol, the entire data for that field is passed to that Protocol for processing.

Below is an example that shows a field being sent to a new layer (Layer2) of protocol when the command field is a 1.

[Protocol]
name = Layer1
[Packet]
[Decode]
[Fields]
Fields Command.4=0.h,Address.8.h
Fields Command.4=1.h,Layer2.48.h

[Protocol]
name = Layer2
[Packet]
[Decode]
[Fields]
Fields L2Command.4=0.h,RSSI.8.d
Fields L2Command.4=1.h,QoS.16.d
Fields L2Command.4=2.h,Layer3.44.h

The USBee DX PacketPresenter automatically processes many types of data streams.  However, it cannot decode custom coded data streams.  Using the PacketPresenter Add-In API, the data stream can be decoded to the basic data values for any custom coding.

The USBee DX software package includes a sample DLL project in Microsoft VC6 format (in the installation directory of the USBee DX software) called AddIn that allows you to customize a decoder for your data streams.

The DLL library called usbeeai.dll (USBee Add-In) has the following interface routine that is called by the PacketPresenter if the ADDIN keyword is used in the DECODE section of the PacketPresenter Definition File.

CWAV_EXPORT unsigned int CWAV_API  APIDecode(  

char *Protocol,

char bitIn,

char &bitOut,

char reset );

This routine is called for each bit of data in the data stream.  Protocol is the string name of the Protocol being processed and allows you to create an add-in that handles many different kinds of decoding.  The parameter “reset” is set to a 1 for the first bit of a packet and 0 for all bits following.  The next bit from the stream is passed in using the parameter “bitIn” (1 or 0). 

After your code decodes the stream, you can either send back no data (return value of 0), or send a new bits back using the “bitOut” pointer (one bit per char) and a return value of the number of bits returned.

The default Add-In routine simply is a pass through so that the output data stream equals the input data stream.  Start with this library source code to add your custom decoding.

Custom decoders can perform complicated decryption and byte or bit manipulation.  Ignoring the actual algorithm that is executed, these decoders may reduce, enlarge or keep constant the number of bits in the data stream.  The following examples are intended to show how these streams can be shortened, lengthened or modified.  Useful decoders will need to have the appropriate algorithms to compute the true values of the output bits.

This Add-In simply loops back the data (out = in).

CWAV_EXPORT unsigned int CWAV_API APIDecode(char *Protocol, char bitIn, char *bitsOut, char reset )

{

          // This will be the Add-In routine that is called by the PacketPresenter

          // when the ADDIN keyword is used in the DECODE section of the

          // PacketPresenter Definition File.

          // This routine is called for each bit of data in a data packet. 

          // The parameter "reset" is set to a 1 for the first bit of a packet and

          // 0 for all bits following.  The next bit from the stream is passed in

          // using the parameter "bitIn" (1 or 0). After your code decodes the stream,

          // you can either send back no data (return value of 0), or send new bits back

          // using the "bitOut" pointer (one bit per char) and a return value of the number

          // of bits returned. The default Add-In routine is simply is a pass through so

          // that the output data stream equals the input data stream. 

          // Start with this library source code to add your custom decoding.

          *bitsOut = bitIn;   

          return( 1 );                 // Indicates that there is 1 return data bit

}

This Add-In inverts the packet data (out = Not(in)).

CWAV_EXPORT unsigned int CWAV_API APIDecode(char *Protocol, char bitIn, char *bitsOut, char reset )

{

          if (bitIn)

                   *bitsOut = 0;   

          else

                   *bitsOut = 1;   

          return( 1 );                 // Indicates that there is 1 return data bit

}

This Add-In shows how to convert a stream to a larger stream (expanding the bits).  In this case each bit becomes two output bits.

CWAV_EXPORT unsigned int CWAV_API  APIDecode(char *Protocol, char bitIn, char *bitsOut, char reset )

{

          *bitsOut++ = bitIn;   

          *bitsOut++ = bitIn;   

          return( 2 );                 // Indicates that there is 2 return data bits

}

This Add-In shows how to remove bits from a stream (compressing the bits).  In this case each bit pair becomes a single bit, basically throwing away the first bit.

CWAV_EXPORT unsigned int CWAV_API  APIDecode(char *Protocol, char bitIn, char *bitsOut, char reset )

{

          static everyother = 0;

          if (reset)                            // Reset the state of the decoder if reset=TRUE

                   everyother = 0;

          if (everyother)

          {

                   *bitsOut = bitIn;   

                    return( 1 );                 // Indicates that there is 1 return data bit

                   everyother = 0;

          }

          else

                   everyother = 1;

          return( 0 );                 // Indicates that there are no return data bits

}

This Add-In shows how to use the Protocol string to selectively decode different types of packets.

CWAV_EXPORT unsigned int CWAV_API  APIDecode(char *Protocol, char bitIn, char *bitsOut, char reset )

{

     static everyother = 0;

     if (!strcmp( Protocol, “COMPRESS”)

     {

          if (reset)              // Reset the state of the decoder if reset=TRUE

              everyother = 0;

          if (everyother)

          {

              *bitsOut = bitIn;   

               return( 1 );       // Indicates that there is 1 return data bit

              everyother = 0;

          }

          else

              everyother = 1;

          return( 0 );       // Indicates that there are no return data bits

     }

     else if (!strcmp( Protocol, “EXPAND”)

     {

          *bitsOut++ = bitIn;   

          *bitsOut++ = bitIn;   

          return( 2 );       // Indicates that there is 2 return data bits

     }

     // No matching decoder label found so just loopback the data

     *bitsOut = bitIn;

     return(1);        

}

Creating your PacketPresenter Definition File can be made simpler using the Debug mode.  To turn on Debug mode, use the DebugOn keyword in a [DEBUG] section of the Definition File.

[Protocol]

       name = I2CEEPROM

[DEBUG]

       DebugOn       ; Turns On Debug Mode. 

; Comment it out to turn it off.

[Packet]

When debug mode is on, each packet is output twice in its raw form, showing the data values as well as the events from the bus.  The first debug line is the initial bus data.  The second line is the bus data after any decoding is completed.  Following the debug lines are the PacketPresenter output packets from this same data.

Below is a screen shot that shows the PacketPresenter that has Debug turned on.

USBee DX Home Page
Add a USBee DX to your shopping cart

The PacketPresenter system has the following limits regarding file size, packets, fields, lookup tables etc.

100K bytes per PacketPresenter Definition File

64K Data Records per Packet (min 64K bits, max 64K bytes)

7 Protocols

1024 Field Lines per Protocol

128 Fields per Field Line

64 Lookup Tables per Protocol

256 Lookup entries per Lookup Table

256 Decoder Substitutions per Protocol

3 Bytes per Substitution input or output

4 PacketPresenter Windows

2.1B bytes per PacketPresenter Output File

USBee DX Home Page
Add a USBee DX to your shopping cart

; Async Protocol Definition File

; This file defines the transfers to/from a custom device

; over an ASYNC bus

;

[Protocol]

   name = ASYNCBus

   bytewise

[DEBUG]

   ;DebugOn      ; Uncomment this to turn on Debug Packets

[Packet]

   [Start]

       type = value

       value = 40h   ; Start command

       mask = F0h ; Mask out the channel number

   [End]

       type = timeout

       timeout = 3000   ; 3ms timeout ends the packet

   [Decode]

   [Fields]

       Fields

          Start.4.h,

          Channel.4=1.h,

          Command.8.h,

          X.16.d/20.48-25$g,

          Y.16.d/20.48-25$g,

          Z.16.d/20.48-25$g,

          Rest.N.h  ; Rest of the packet

       Fields

          Rest.N.h  ; Rest of the packet

USBee DX Home Page
Add a USBee DX to your shopping cart

; I2C EEPROM Protocol Definition File

; This file defines the transfers to/from an I2C EEPROM

; with 8 bit address

;

[Protocol]

     name = I2CEEPROM

     bytewise

[DEBUG]

     ;DebugOn      ; Uncomment this to turn on Debug Packets

[Packet]

     [Start]

          type = event

          event = 1 ; Start Bit

     [End]

          type = event

          event = 0Ah   ; Stop Bit Or NACK

     [Decode]

     [Fields]

          ; Device Not Present

          Fields

              $Device Not Present,              ; Printout this label if match

              SlaveAddress.7m.h,RW.1.i,         ; Control Byte

              Address.8m.h,                     ; 1 byte address

              [8]                               ; followed by a NACK condition

          ; Set Address

          Fields

              $SetAddressCmd,                   ; Printout this label if match

              SlaveAddress.7m.h,RW.1=0.i,       ; Control Byte

              Address.8m.h,                     ; 1 byte address

               [2]                               ; followed by a STOP condition

          ; Write Command

          Fields

              $WriteCommand,                    ; Printout this label if match

              SlaveAddress.7m.h,RW.1=0.i,       ; Control Byte

              Address.8m.h,                     ; 1 byte address

              [!1],                             ; NO START condition

              WriteData.Nm.h                    ; Written Data (Variable N)

          ; Current Address Read

          Fields

              $CurrentRead,                     ; Printout this label if match

              SlaveAddress.7m.h,RW.1=1.i,       ; Control Byte

              ReadData.Nm.h                     ; Read Data (Variable number N)

          ; Random Read

          Fields

              $RandomRead,                      ; Printout this label if match

              SlaveAddress.7m.h,RW.1=0.i,       ; Control Byte

              Address.8m.h,                     ; 1 byte address

              [1],                              ; START Condition

              SlaveAddress.7m.i,RW.1=1.i,       ; Control Byte

              ReadData.Nm.h,                    ; Read Data (Variable number N)

USBee DX Home Page
Add a USBee DX to your shopping cart

; Cypress RF IC Protocol Definition File

; This file defines the transfers to/from a CY6936 RF IC

; using the SPI bus

[Protocol]

     name = CypressRFIC

     bytewise

[DEBUG]

     ;DebugOn

[Packet]

     [Start]

          type = event

          event = 1 ; SS goes active

     [End]

          type = event

          event = 2 ; SS goes inactive

     [Decode]

     [Fields]

          ; RX_IRQ_STATUS_ADR Read and Write Command

          Fields    Dir.1y=0.L, Inc.1y.tf, Address.6y=07h.L, Dummy.8x.i, RXOW.1x.h, SOPDET.1x.h, RXB16.1x.h, RXB8.1x.h, RXB1.1x.h, RXBERR.1x.h, RXC.1x.h, RXE.1x.h

        Fields    Dir.1y=1.L, Inc.1y.tf, Address.6y=07h.L, RXOW.1y.h, SOPDET.1y.h, RXB16.1y.h, RXB8.1y.h, RXB1.1y.h, RXBERR.1y.h, RXC.1y.h, RXE.1y.h

          ; TX_IRQ_STATUS_ADR Read and Write Command

          Fields    Dir.1y=0.L, Inc.1y.tf, Address.6y=04h.L, Dummy.8x.i, OS.1x.h, LV.1x.h, TXB15.1x.h, TXB8.1x.h, TXB1.1x.h, TXBERR.1x.h, TXC.1x.h, TXE.1x.h

          Fields    Dir.1y=1.L, Inc.1y.tf, Address.6y=04h.L, OS.1y.h, LV.1y.h, TXB15.1y.h, TXB8.1y.h, TXB1.1y.h, TXBERR.1y.h, TXC.1y.h, TXE.1y.h 

          ; RX_BUFFER_ADR Read and Write Command

          Fields    Dir.1y=0.L,   Inc.1y.tf,    Address.6y=21h.L,       Dummy.8x.i,                                          RxData.Nx.h            

          Fields    Dir.1y=1.L,   Inc.1y.tf,    Address.6y=21h.L,       RxData.Ny.h            

          ; TX_BUFFER_ADR Read and Write Command

          Fields    Dir.1y=0.L,   Inc.1y.tf,    Address.6y=20h.L,       Dummy.8x.i,                                          TxData.Nx.h            

          Fields    Dir.1y=1.L,   Inc.1y.tf,    Address.6y=20h.L,       TxData.Ny.h            

          Fields    Dir.1y=0.L,   Inc.1y.tf,    Address.6y.L,     Dummy.8x.i,                                                ReadData.Nx.h          

          Fields    Dir.1y=1.L,   Inc.1y.tf,    Address.6y.L,     WriteData.Nmy.h              

          Lookup Dir

             [0]=$Read

             [1]=$Write

          Lookup Address

             [00h]=$CHANNEL_ADR

             [01h]=$TX_LENGTH_ADR

             [02h]=$TX_CTRL_ADR

             [03h]=$TX_CFG_ADR

             [04h]=$TX_IRQ_STATUS_ADR

             [05h]=$RX_CTRL_ADR

             [06h]=$RX_CFG_ADR

             [07h]=$RX_IRQ_STATUS_ADR

             [08h]=$RX_STATUS_ADR

             [09h]=$RX_COUNT_ADR

             [0ah]=$RX_LENGTH_ADR

             [0bh]=$PWR_CTRL_ADR

             [0ch]=$XTAL_CTRL_ADR

             [0dh]=$IO_CFG_ADR

             [0eh]=$GPIO_CTRL_ADR

             [0fh]=$XACT_CFG_ADR

             [10h]=$FRAMING_CFG_ADR

             [11h]=$DATA32_THOLD_ADR

             [12h]=$DATA64_THOLD_ADR

             [13h]=$RSSI_ADR

             [14h]=$EOP_CTRL_ADR

             [15h]=$CRC_SEED_LSB_ADR

             [16h]=$CRC_SEED_MSB_ADR

             [17h]=$TX_CRC_LSB_ADR

             [18h]=$TX_CRC_MSB_ADR

             [19h]=$RX_CRC_LSB_ADR

             [1ah]=$RX_CRC_MSB_ADR

             [1bh]=$TX_OFFSET_LSB_ADR

             [1ch]=$TX_OFFSET_MSB_ADR

             [1dh]=$MODE_OVERRIDE_ADR

             [1eh]=$RX_OVERRIDE_ADR

             [1fh]=$TX_OVERRIDE_ADR

             [26h]=$XTAL_CFG_ADR

             [27h]=$CLK_OVERRIDE_ADR

             [28h]=$CLK_EN_ADR

             [29h]=$RX_ABORT_ADR

             [32h]=$AUTO_CAL_TIME_ADR

             [35h]=$AUTO_CAL_OFFSET_ADR

             [39h]=$ANALOG_CTRL_ADR

             [20h]=$TX_BUFFER_ADR

             [21h]=$RX_BUFFER_ADR

             [22h]=$SOP_CODE_ADR

             [23h]=$DATA_CODE_ADR

             [24h]=$PREAMBLE_ADR

             [25h]=$MFG_ID_ADR

[Protocol]

     name = RxData

     bytewise

[DEBUG]

     ;DebugOn

[Packet]

     [Start]

          type = next

     [End]

          type = event

          event = 127   ; All Data passed in

     [Decode]

     [Fields]

          ; RX_IRQ_STATUS_ADR Read and Write Command

          Fields    ReceiveData.N.h

USBee DX Home Page
Add a USBee DX to your shopping cart

; CAN Protocol Definition File

; This file defines the transfers to/from a custom CAN device

; over a the CAN bus

;

[Protocol]

          name = CANBus

          bitwise

[DEBUG]

          ;DebugOn           ; Uncomment this to turn on Debug Packets

[Packet]

          [Start]

                   type = event

                   event = 1 ; Start of CAN packet

          [End]

                   type = event

                   event = 2 ; End of CAN packet

          [Decode]

          [Fields]

                   ; Extended Frame Format

                   Fields    SOF.1.i, IDA.11.h, SRR.1.h, IDE.1=1.h, IDB.18.h, RTR.1.h,

                             Rsrv.2.i, Length.4.h, Data.N.h, CRC.15.h, CRCDel.1.h,

                             ACK.1.h, ACKDel.1.h, EOF.7.h

                   ; Base frame format

                   Fields    SOF.1.i, ID.11.h, RTR.1.h, IDE.1=0.h, Rsrv.1.i, Length.4.h,

                             Data.N.h, CRC.15.h, CRCDel.1.h, ACK.1.h, ACKDel.1.h,

                             EOF.7.h

USBee DX Home Page
Add a USBee DX to your shopping cart

; One Wire Protocol Definition File

; This file defines the transfers to/from some 1-Wire devices

; using the 1-Wire bus

;

[Protocol]

          name = OneWireBus

          bytewise

[DEBUG]

          ;DebugOn           ; Uncomment this to turn on Debug Packets

[Packet]

          [Start]

                   type = event

                   event = 2 ; Presence Pulse

          [End]

                   type = event

                   event = 1 ; Reset Pulse

          [Decode]

          [Fields]

                   ; These fields are used by Maxim/Dallas Digital Thermometers

                   Fields    ROMCommand.8=F0h.$Search Rom, Data.N.h

                   Fields    ROMCommand.8=33h.$Read Rom, Family.8.h, SerialNumber.48.h,

                             CRC.8.h

                   Fields    ROMCommand.8=55h.$Match Rom, Family.8.h, SerialNumber.48.h, CRC.8.h

                   Fields    ROMCommand.8=CCh.$Skip ROM, Function.8=44h.$ConvertTemp

                   Fields    ROMCommand.8=CCh.$Skip ROM, Function.8=BEh.$Read Scratchpad,                               Temp.16.d, TH.8.h, TL.8l.h, Rsvd.16.i, Remain.8.h, CpC.8.h, CRC.8.h

                   ; These fields are used by Dallas Serial Number iButtons

                   Fields    ROMCommand.8=33h.$Read Rom, Family.8.h, SerialNumber.48.h, CRC.8.h

                   Fields    ROMCommand.8=0Fh.$Read Rom, Family.8.h, SerialNumber.48.h, CRC.8.h

                   ; These packets are used by 1-Wire EEPROMS

                   Fields    ROMCommand.8=33h.$Read Rom, Family.8.h, SerialNumber.48.h, CRC.8.h

                   Fields    ROMCommand.8.h, MemoryCommand.8=0Fh.$Write Scratchpad,

                                          Address.16.h, Data.N.h

                   Fields    ROMCommand.8.h, MemoryCommand.8=AAh.$Read Scratchpad,

                                           Address.16.h, ES.8.h, Data.N.h

                   Fields    ROMCommand.8.h, MemoryCommand.8=55h.$Copy Scratchpad,

                                           AuthCode.24.h

                   Fields    ROMCommand.8.h, MemoryCommand.8=F0h.$Read Memory,

                                                         Address.16.h, Data.N.h

USBee DX Home Page
Add a USBee DX to your shopping cart

; Sample Parallel Protocol Definition File

; This file defines the transfers to/from an unique device

;

[Protocol]

   name = ADevice

   bytewise

[DEBUG]

   ;DebugOn

[Packet]

   [Start]

       type = signal

       signal = 14

       level = 0

   [End]

       type = length    

       Bytelength = 21

   [Decode]

   [Fields]

       Fields

          StartByte.8m.d*2+4$mV,        

          CommandByte.8l.L,         

         FLength.8m.h,      

          SlaveAddress.7m.h,RW.1.L, 

          Long.32m.h,

         8Bytes.64m.h,       

          NextLayer.Nm.h      

[Protocol]

   name = NextLayer

   bytewise

[Packet]

   [Start]

       type = next  

   [End]

       type = Event  ;End of a packet is signaled by a event   

       event = 127   ; Means the end of the data (only for higher layers)

   [Decode]

   [Fields]

       Fields

          Rest.N.h      ; Just print out all the bytes

USBee DX Home Page
Add a USBee DX to your shopping cart

; Serial Protocol Definition File

; This file defines the transfers from a serial device

;

[Protocol]

   name = SerialBus

   bitwise

[DEBUG]

   ;DebugOn      ; Uncomment this to turn on Debug Packets

[Packet]

   [Start]

       type = value  ; Look for a value in the data to start the packet

       value = 6211h ; NOTE: This value is assumed MSbit first in

                     ; the data stream!

       bits = 16

       mask = FFFFh

   [End]

       type = length

       bitlength = 64   ; End of command after 64 bits

   [Decode]

   [Fields]

       ; Send out the bits of the packet

       Fields Start.16.h, Nine.9.h, Seven.7.h, Rest.N.b

USBee DX Home Page
Add a USBee DX to your shopping cart

; USB Bus Protocol Definition File

; This file defines the transfers to/from a custom USB device

;

[Protocol]

          name = USBBus

          bitwise

[DEBUG]

          ;DebugOn           ; Uncomment this to turn on Debug Packets

[Packet]

          [Start]

                   type = event

                   event = 1 ; Setup/In or Out found

          [End]

                   type = event

                   event = 6 ; ACK, NAK or Stall found or no handshake found

          [Decode]

          [Fields]

                   ; Any Packet - No Response

                   Fields    Sync.8.i, PID.8.L, Addr.7l.d, EP.4l.d, CRC5.5.i, ; Token

                             [4]                          ; No Handshake

                   ; Setup – Nakd                        ; Token

                   Fields    Sync.8.i, PID.8=10110100b.L, Addr.7l.d, EP.4l.d, CRC5.5.i,

                             Sync.8.i, HS.8=01011010b.L   ; Handshake

                   ; IN - Nakd

                   Fields    Sync.8.i, PID.8=10010110b.L, Addr.7L.d, EP.4L.d, CRC5.5.i,

                             Sync.8.i, HS.8=01011010b.L        ; Handshake

                   ; OUT - Nakd

                   Fields    Sync.8.i, PID.8=10000111b.L, Addr.7L.d, EP.4L.d, CRC5.5.i,

                             Sync.8.i, HS.8=01011010b.L   ; Handshake

                   ; Setup

                   Fields    Sync.8.i, PID.8=10110100b.L, Addr.7l.d, EP.4l.d, CRC5.5.i, Sync.8.i, PID.8.L, Rtype.8.i,

bRequest.8L=1.$Clear Feature, bValue.16L.h, bIndex.16L.H, bLength.16L.H, CRC16.16.i, Sync.8.i, HS.8.L                                

                   Fields    Sync.8.i, PID.8=10110100b.L, Addr.7l.d, EP.4l.d, CRC5.5.i, Sync.8.i, PID.8.L, Rtype.8.i,

bRequest.8L=0.$Get Status, bValue.16L.h, bIndex.16L.H, bLength.16L.H, CRC16.16.i, Sync.8.i, HS.8.L

                   Fields    Sync.8.i, PID.8=10110100b.L, Addr.7l.d, EP.4l.d, CRC5.5.i, Sync.8.i, PID.8.L, Rtype.8.i,

bRequest.8L=8.$Get Configuration, bValue.16L.h, bIndex.16L.H, bLength.16L.H, CRC16.16.i, Sync.8.i, HS.8.L

                   Fields    Sync.8.i, PID.8=10110100b.L, Addr.7l.d, EP.4l.d, CRC5.5.i, Sync.8.i, PID.8.L, Rtype.8.i,

bRequest.8L=6.$Get Descriptor, bValueL.8L.I, Type.8L.L, bIndex.16L.H, bLength.16L.H, CRC16.16.i, Sync.8.i, HS.8.L

                   Fields    Sync.8.i, PID.8=10110100b.L, Addr.7l.d, EP.4l.d, CRC5.5.i, Sync.8.i, PID.8.L, Rtype.8.i,

bRequest.8L=16.$Get Interface, bValue.16L.h, bIndex.16L.H, bLength.16L.H, CRC16.16.i, Sync.8.i, HS.8.L

                   Fields    Sync.8.i, PID.8=10110100b.L, Addr.7l.d, EP.4l.d, CRC5.5.i, Sync.8.i, PID.8.L, Rtype.8.i,

bRequest.8L=5.$Set Address, Address.16L.h, bLength.16L.i, bLength.16L.i, CRC16.16.i, Sync.8.i, HS.8.L

                   Fields    Sync.8.i, PID.8=10110100b.L, Addr.7l.d, EP.4l.d, CRC5.5.i, Sync.8.i, PID.8.L, Rtype.8.i,

bRequest.8L=9.$Set Configuration, Config.16L.h, bLength.16L.i, bLength.16L.i, CRC16.16.i, Sync.8.i, HS.8.L

                   Fields    Sync.8.i, PID.8=10110100b.L, Addr.7l.d, EP.4l.d, CRC5.5.i, Sync.8.i, PID.8.L, Rtype.8.i,

bRequest.8L=7.$Set Descriptor, bValue.16L.h, bIndex.16L.H, bLength.16L.H, CRC16.16.i, Sync.8.i, HS.8.L

                   Fields    Sync.8.i, PID.8=10110100b.L, Addr.7l.d, EP.4l.d, CRC5.5.i, Sync.8.i, PID.8.L, Rtype.8.i,

bRequest.8L=3.$Set Feature, bValue.16L.h, bIndex.16L.H, bLength.16L.H, CRC16.16.i, Sync.8.i, HS.8.L

                   Fields    Sync.8.i, PID.8=10110100b.L, Addr.7l.d, EP.4l.d, CRC5.5.i, Sync.8.i, PID.8.L, Rtype.8.i,

bRequest.8L=10.$Get Interface, bValue.16L.h, bIndex.16L.H, bLength.16L.H,  CRC16.16.i, Sync.8.i, HS.8.L

                   Fields    Sync.8.i, PID.8=10110100b.L, Addr.7l.d, EP.4l.d, CRC5.5.i, Sync.8.i, PID.8.L, Rtype.8.i,

bRequest.8L=11.$Set Interface, AltSetting.16L.h, Interface.16L.H, bLength.16L.H, CRC16.16.i, Sync.8.i, HS.8.L

                   Fields    Sync.8.i, PID.8=10110100b.L, Addr.7l.d, EP.4l.d, CRC5.5.i, Sync.8.i, PID.8.L, Rtype.8.i,

bRequest.8L=12.$Sync Frame, bValue.16L.h, bIndex.16L.H, bLength.16L.H, CRC16.16.i, Sync.8.i, HS.8.L

                   ; IN

                   Fields    Sync.8.i, PID.8=10010110b.L, Addr.7L.d, EP.4L.d, CRC5.5.i,

                             Sync.8.i, PID.8.L, InData.NL.h, CRC16.16.i,   ; Data

                             Sync.8.i, HS.8.L   ; Handshake

                   ; OUT

                   Fields    Sync.8.i, PID.8=10000111b.L, Addr.7L.d, EP.4L.d, CRC5.5.i,

                             Sync.8.i, PID.8.L, OutData.NL.h, CRC16.16.i,   ; Data

                             Sync.8.i, HS.8.L   ; Handshake

                   ; Catch all

                   Fields Data.NL.h

                   Lookup    Type

                             [1]=$Device

                             [2]=$Config

                             [3]=$String

                   Lookup    PID

                             [11000011b]=$DATA0

                             [11010010b]=$DATA1

                             [01001011b]=$ACK

                             [01011010b]=$NAK

                             [01111000b]=$STALL

                             [10110100b]=$SETUP

                             [10000111b]=$OUT

                             [10010110b]=$IN

                             [10100101b]=$SOF

                   Lookup    HS

                             [01001011b]=$ACK

                             [01011010b]=$NAK

                             [01111000b]=$STALL

; PS2 Protocol Definition File

; This file defines the transfers from a PS2 device

;

[Protocol]

   name = PS2Bus

   bytewise

[DEBUG]

   ;DebugOn      ; Uncomment this to turn on Debug Packets

[Packet]

   [Start]

       type = next      ; Every byte is the start of the next packet

       CHANNELXORY      ; Either Device to Host or Host To Device

   [End]

       type = TIMEOUT

       TIMEOUT = 5000   ; End of command after 5msec

   [Decode]

   [Fields]

       ; Setting LEDs after command

       Fields [1], $Device To Host, $Key Down, Scancode.8x.h, [2],

$Host To Device, HostCommand.8y=EDh.$Set LEDs, Ack.8x.i, Parameter.5y.i, Caps.1y.tf, Num.1y.tf, Scroll.1y.tf, Ack.8x.i

       Fields [1], $Device To Host, $Key Down, Scancode.8x.h, [2],

              $Host To Device, HostCommand.8y.h, Ack.8x.i,

                                 Parameter.8y.h, Ack.8x.i

       ; Device to Host

       Fields [1], $Device To Host, $Key Up, Release.8x=F0h.h,

              Scancode.Nx.h

       ; All other scancodes

       Fields [1], $Device To Host, $Key Down, Scancode.Nx.H

       ; Host to Device

       Fields [2], $Host To Device, Command.Ny.h

USBee DX Home Page
Add a USBee DX to your shopping cart

  Copyright (c) 2010 CWAV, Inc.  All Rights Reserved.  Specifications subject to change without notice.
CWAV, Inc.  28481 Rancho California Road #201  Temecula, CA  92590
Tel: (951) 694-6808  Fax: (240) 220-8868
www.usbee.com        support@usbee.com