USB-TO-GPIO datasheet(20/50 Pages) TI1

20 / 50 page

www.ti.com

4.2

Rules for Implementing Compliant Custom Firmware

4.3

Compliant Versioning

Rules for Implementing Compliant Custom Firmware

In order for custom firmware to be compatible with this versioning scheme, it must comply with the

following rules:

1. The custom firmware must support pairs of commands listed in Table 4-1 (see Chapter 3 for the

default implementation).

Table 4-1. List of Pairs of Commands Needed for Firmware Versioning

CODES (hex)

DESCRIPTION

INFORMATION

0x00 and 0x80

Firmware Version (Get Version)

Required to communicate its unique identity to the GUI software

Required for the GUI software to reprogram the firmware on the

0x18 and 0x98

EEPROM Pro

embedded EEPROM

Required for the GUI software to validate the firmware image on the

0x19 and 0x99

EEPROM Read

EEPROM

2. The custom firmware must have a unique, compliant version number that describes its functionality.

Note:

Together, these two rules describe an interface that all GUI software can expect to be

implemented. If GUI software cannot call the Firmware Version command, it cannot

identify the firmware and should not attempt to use it as the outcome is unpredictable. If

GUI software needs to reprogram the USB interface adapter, it expects command 0x18 to

be an EEPROM programming. Conforming to this standard ensures that the firmware

does not break the validation and reprogramming cycle.

The versioning scheme uses three bytes to make up a unique identifier that the device can return (as the

data part) in response to the Firmware Version command (see Chapter 3 for more details).

The first byte is the Family Code and it describes who is responsible for the firmware. These codes are

given out in blocks to various groups with TI. For instance, the Digital Power Group owns codes 01–16 (or

0x01–0x10 in hex). Some Family Codes are reserved. Family codes 240–255 (or 0xF0–0xFF in hex) have

been set aside for custom implementations by end users or anyone wanting to make a compliant version

of custom firmware for their own private use.

This Family Code also denotes the permutations of protocols supported, such as Family Code 1 supports

I2C, PMBus, and SMBus, while Family Code 2 might support I2C and Protocol X.

The second byte is the Major Version and it describes a revision to the permutations of protocols. If the

protocols supported need new functionality or have changes to the way that they are called (signature

changed) then this byte denotes the change.

The third byte is the Minor Version and it describes a revision to the permutations of protocols. If the

firmware code has changed to fix a bug in the functions but no new public functions have been added and

no changes have been made to the function signatures, this byte should be changed to denote the new

version.

Table 4-2 summarizes the significance of the three-byte code.

Table 4-2. Three Bytes for Firmware Versioning

BYTE ORDER

MOST SIGNIFICANT BYTE

MIDDLE BYTE

LEAST SIGNIFICANT BYTE

Byte Meaning

Family Code

Major Version

Minor Version

01 = Major revision

01 = Owned by Digital Power

01 = Minor revision of the permutation of

Example Value

of the permutation of

PMBus, SMBus, I2C supported

protocols

Firmware Versioning Scheme

SLLU093 – August 2006

Submit Documentation Feedback

USB-TO-GPIO датащи(PDF) 20 Page - Texas Instruments

USB-TO-GPIO датащи(HTML) 20 Page - Texas Instruments

Html Pages

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50

датащи скачать

ссылки URL