|
|
Part: AN435
Category:
Description:
Company:
Datasheet: Download AN435 datasheet File size : 50 kB
Request For quote: Find where to buy AN435
Datasheet text preview:
INTEGRATED CIRCUITS
AN435 I2C byte oriented system driver
Author: Joe Brandolino, Philips Semiconductors FAE Supersedes data of 1993 Jun 01 IC20 data handbook 1994 Oct 25
Philips Semiconductors
Philips Semiconductors
Product specification
I2C byte oriented system driver
Author: Joe Brandolino, Philips Semiconductors FAE, Canada
DESCRIPTION
AN435
IIC_OS2.ASM contains a complete multimaster I2C driver for the byte oriented Philips microcontrollers. To date, the list of byte oriented 80C51 derivative microcontrollers includes: 8XC552 8XC562 8XC652 8XC654 8XCL410 8XCL580 8XCL781 The I2C Bus is a deceptively simple concept. With only two lines involved the data line (SDA) and the clock line (SCL) one would think that writing an I2C driver is a trivial task. In reality, a complete multimaster capable I2C driver would be a complex state machine (the I2C hardware state machine could assume one of 28 possible states). The idea behind IIC_OS2 is to make the state machine workings of the I2C mechanism transparent to the user. When this driver is incorporated into a program, the user communicates with I2C peripherals (and other masters) by executing a command file which contains simple macro directives. For example, to send a byte of data (stored in `the_data') to a PCF8574 I/O expandor (having I2C address `PCF8574_adrs') using this driver, the main program would look like this: ;PROGRAM: ; MOV ; CALL ; JBC ; ; ; ;COMMAND_FILE: ; DB ; DB ; DB ; DB ; DB ;
DPTR,#COMMAND_FILE DO_IIC IIC_failure, PROGRAM . . .
;load address of command file ;call "IIC_OS2" routine ;check for a failure
PCF8574_adrs OR iic_write_mask ;address of slave + R/W bit ioD_ ;define where to get data from 1 ;define number of bytes to send the_data ;define address of data to be sent iic_end_ ;'end of command file' directive
This example describes one option out of many which can be used to send the data byte to a slave. Without a driver like "IIC_OS2", the user would have to interact with the IIC SFR registers, and take into account all hardware state possibilities. The comments in this listing assume that the reader has a basic knowledge of the 80C51 family, and is familiar with IIC basics. This program has been tested as thoroughly as time permitted; however, Philips cannot guarantee that this I2C driver is flawless in all applications. The comment text fields in this file use a consistent method of highlighting the various parameters of the software. All constants (EQUates), registers, bits and other bytes are surrounded by ' ' in the comment text. All routines, labels, procedures and file names are surrounded by " " in the comment text. Generally speaking, all 8051 mnemonics are in UPPERCASE, all variable names and labels are in LOWERCASE or MiXeD case. All EQUates are named such that the last character in the EQUate name is an underscore (e.g., 'iic_end_'). The terms IIC and I2C are used interchangably, and both mean InterIntegrated Circuit. NOTE: To incorporate this program into your main program, place it somewhere in your source file by including the following text: ; ; $include(mod552) ;include the desired processor descriptor file $include(IIC_OS2.asm) ;include this program
Since this program has a 'CSEG AT... definition for the IIC interrupt vector, it is probably best to place it in your program where all the other interrupt vector directives reside so that assembly synchronisation errors do not occur.
November 1992
2
Revision date: 1994 OCT 25
Philips Semiconductors
Product specification
I2C byte oriented system driver
AN435
One must also ensure that the data bytes used by this program do not conflict with those in your main program. Don't forget to initialize the I2C control registers and the interrupt registers, etc. For example: ;INIT: ; ; ; ; ; ; ; ; ; ; ; . . . MOV MOV MOV MOV CLR . . . IEN0,#10100000B ;enable IIC interrupt (and any other) S1CON,#ENS1_NOTSTA_NOTSTO_NOTSI_AA_CR0 S1ADR,#Own_adrs OR general_enable_ ;enable slave/general mode IIC_status,#status_OK_ ;init system status byte IIC_failure ;init status bit
This driver uses DATA space bytes (approx. 16 bytes), plus several buffers which are required only for multimaster scenarios where this micro can be addressed as a slave. One bit addressable byte is used. The user must ensure the following EQUates are set appropriately for his system: Slave address for this microcontroller other bus masters can address this micro as a slave; this driver simply sends `SLVbytes_out_' number of bytes or receives `SLVbytes_in_' number of bytes in the case of being addressed as a slave. The LSBit of the address (`Own_adrs_') is set indicating that general calls will be responded to. ; Own_adrs_ general_enable_ SLVbytes_in_ SLVbytes_out_ IIC_buffer_size_ ;
EQU EQU EQU EQU EQU
02EH 1 8 8 8
;address of micro when addressed as a slave ;general call recognised since LSBit is set ;# bytes to receive when addressed as a slave ;# bytes to transmit when " " " ;# bytes reserved for 'IIC_data_buffer'
Change the following equates to suit your system they define where the start of DATA and BIT ADDRESSABLE DATA for the required bytes in "IIC_OS2". ; IIC_OS2_DATA IIC_OS2_BITADRS_DATA ;
EQU EQU
48 32
;change location to suit your system ;bit addressable!
To interface to this I2C driver, the user need not understand all the details of the program only the following registers must be understood: ; ; ; ; ; ; ; ; ; ; 'IIC_data_buffer' 'Slave_in' buffer (if required) 'Slave_out' buffer (if required) 'aux_adrs' 'indirect_adrs' 'indirect_count' 'IIC_failure' (BIT) 'IIC_status' 'IIC_final_status' used with the 'ioBuffer_' command used only in multimaster systems used only in multimaster systems used with 'use_aux_adrs_' command used with the 'indirect_' command used with the 'indirect_' command set if command file was kaput holds dynamic status of session holds the final status of session
November 1992
3
Philips Semiconductors
Product specification
I2C byte oriented system driver
AN435
Additionally, there is a command file structure (the command file is a list of commands that "IIC_OS2" will execute) which the user must conform to. The list of command file directives includes: ; ; ; ; ; ; ; ; ; ; ; ; ; 'ioD_' 'ioC_' 'ioX_' 'ioBuffer_' 'immediate_' 'call_' 'indirect_' 'use_aux_adrs_' target DATA space for data transfers target CODE space for data transfers target XDATA space for data transfers target 'IIC_data_buffer' for data transfers used to output bytes from command file stream used to call a subroutine between reapeated starts gets I/O address and count from 'indirect_ registers gets slave address from 'aux_adrs'
'iic_end_' last byte of a command file 'iic_write_mask_' OR with slave address to indicate a write operation 'iic_read_mask_' OR with slave address to indicate a read operation
The command file structure is explained in detail below. NOTE: Multimaster systems are very specific to the system design, and therefore, very difficult to make generic. Every multimaster system will have a different protocol for how many (and which) bytes to send/receive when the master is addressed as a Slave Receiver or Slave Transmitter. For this reason, this program implements the multimaster scenario very simply if the micro running this program is addressed as a slave, it will read up to 'SLVbytes_in_' number of data bytes or write 'SLVbytes_out_' number of data bytes (depending on what the calling master requests). The target data buffer in these cases are the 'Slave_in' buffer and the 'Slave_out' buffer. This program also treats the general call scenario as a Slave Receiver mode. If the general call is received, and the `S1ADRS' has been set to accept the general call, up to eight bytes can be received into the `Slave_in' buffer. The IIC specification has defined how the general call should be handled, and the user can write his own code to conform to this specification, or simply use the general call as a means of sending common information to all the masters on the bus which use this driver. Since the bytes sent from the general call master to the other masters which use this driver end up in the `Slave_in' buffer (and the `IIC_status' is set to indicate a general call scenario), the user can write code in his mainline routine to conform to the I2C specification if he wishes. The user can make the size of these slave input/output buffers (by altering the corresponding equates `SLVbytes_in_' and `SLVbytes_out_') as large as required. The calling Master can terminate the slave session at any number of data bytes sent or received by providing a stop or a not acknowledge. IIC_OS2, when integrated into the user's system, will require 16 DATA bytes (mapped anywhere in the internal DATA memory space), and one bitaddressable byte. About 600 bytes of codespace memory are used. The user of this program need not concern himself with the bit or byte level operation of the I2C harware this program takes care of all I2C registers, and checks for all collisions, arbitration lost scenarios, bus errors, etc. A command list consistiing of a limited number of simple macro commands is setup by the user, and this driver uses that list of commands to perform the desired I2C operations. The user loads the DPTR register with the address of the sequence of I2C operations desired. Once this register is loaded, the "DO_IIC" routine is called. "DO_IIC" starts the I2C process by forcing a START condition from which point the interrupt service routine "IIC_VECTOR" will execute the command file and interact with the IIC SFRs. "DO_IIC" acts as a timeout watchdog while the command file is running. Once the command file is completely executed, "DO_IIC" will return to the calling routine with the `IIC_failure' bit and `IIC_final_status' byte set according to the results of the command file execution. The `IIC_failure' bit will be set if an error occurs so the calling program could try again or interrogate the `IIC_final_status' byte to determine exactly what kind of error took place. The I2C operations to be performmed are stored sequentially starting at the address specified by the DPTR (`IIC_Command_File_adrs') and in the memory space designated by 'Data?adrs?space'. I2C operations include: 1. sending or receiving any number of bytes from 1 to 255 into any valid address space 2. repeated start automatically performmed so multiple slaves can be communicated with in one call 3. call subroutines between repeated start conditions directly from the I2C command file list (i.e., transparent to the calling routine).
November 1992
4
Philips Semiconductors
Product specification
I2C byte oriented system driver
AN435
The I2C Command File must be constructed so that it conforms to the I2C driver system format. This format is very simple and can be pictorially viewed as:
COMMAND_FILE: COMMAND BLOCK 1
COMMAND BLOCK 2
COMMAND BLOCK N
`IIC_END_' DIRECTIVE
LAST DIRECTIVE IN COMMAND FILE
Each Command Block consists of the following bytes: (note '+' means logical OR) 1. slave address + direction mask slave address = hex number or `use_aux_adrs_' directive direction mask = `iic_read_mask_' or `iic_write_mask_' 2. memory space directive + directive options + sub-directive options memory space directive = none or `ioD_' or `ioX_' or `ioC_' or `immediate_; (targets CODE) or `ioBuffer_; (targets DATA) directive options = none or `indirect_' (`indirect_' used only with `ioD_', `ioX', or `ioC' memory space directives) sub-directive option = none or `call_' 3. number of data bytes 4. low byte address of data 5. high byte address of data 6. low byte of address of subroutine 7. high byte of address of subroutine for Options 1 to 3 only for Options 1 to 3 only for Options 1 to 3 only (and only if target is CODE or XDATA). only if `call_' sub-directive used only if `call_' sub-directive used
November 1992
5
Others parts begin by an
AN-1 AN-2 AN-3 AN-4 AN-5 AN-6 AN-7 AN-8
|
|
|
