I2C and the Atom PRO

Lynxmotion Electronics & Software
1

I got some Microchip MCP23017 I/O Expander chips, which interface via i2c. I’ve been trying to get an Atom PRO to communicate with this chip, but have not had any success so far. From what I have read of the MCP23017’s datasheet, it looks like I am doing things properly.

However, it seems like the Atom PRO is just locking up when it executes the i2cout command. Nothing happens after it gets to that i2cout command, and I have a serout and turn on an LED right after that. Neither of those things happen.

Is there something I am missing about the i2cout command? Is there some other setup I need to do for serial communications to work, including i2c? I didn’t see any mention of extra setup in the Atom PRO manual.

Here is the code:

[code]’
’ I2C Test Program for Microchip MCP23017 I/O Expander
’
’
greenLED con p8
yellowLED con p7
redLED con p6

’ I2C Configuration
SCL con p12
SDA con p13

’ Microchip MCP27013 I/O Expander Configuration
ctrlwr con %01000000 ’ Control Byte (Write)
ctrlrd con %01000001 ’ Control Byte (Read)

iocona con 0x05 ’ Port A I/O Configuration Address
ioconseta con %11100011 ’ Port A ICON register setting

iodira con 0x00 ’ Port A Direction Bit Control Address
iobitsa con %00000000 ’ Port A Direction Bit Settings (0 = output, 1 = input)

ioconb con 0x15 ’ Port B
ioconsetb con %11100011 ’ Port B

iodirb con 0x10 ’ Port B Direction Bit Control Address
iobitsb con %00000000 ’ Port B Direction Bit Settings (0 = output, 1 = input)

high redLED
high yellowLED
high greenLED
pause 1000

low redLED
low yellowLED
low greenLED

Main:
gosub WriteI2C [iocona, ioconseta]
gosub WriteI2C [ioconb, ioconsetb]
gosub WriteI2c [iodira, iobitsa]
gosub WriteI2c [iodirb, iobitsb]
goto Main

address var byte
outdat var byte
WriteI2C [address, outdat]
high yellowLED
pause 1000
low yellowLED

i2cout SDA,SCL, Failed, ctrlwr, address, [outdat]

serout S_OUT, NE2400, "Wrote byte ", BIN outdat, ", at address ", BIN address, 13]
high greenLED
pause 1000
low greenLED
goto WriteDone

Failed:
serout S_OUT, NE2400, “Output to I/O Expander failed!”, 13]
high redLED
pause 1000
low redLED
goto Main

WriteDone:
return

end[/code]

I know the WriteI2C subroutine is getting executed because the yellow LED comes on and goes off. I never see the green LED blink or the serout command execute. I also don’t see any branch to the Failed section of code.

8-Dale

2

I have had some luck with the SRF08 range finder with I2c code.
It has been awhile since I looked at some of this, but I had the following:

;
; SRF helper functions		
SDA      Con P4     ' Define Data pin
SCL      Con P5     ' Define Clk pin
SRF08a   Con 0xE0   ' 1st Sonar I2C Address
SRFCmdReg   Con 0      ' Sonar Command register
SRFLightReg Con 1      ' Sonar Light sensor register
SRFRangeReg Con 2      ' Sonar 1st Range register

srfLightVal    Var Byte   ' Light sensor
srfAdr var Byte
srfRange    Var Word   ' 16 bit variable for Range
SRFPing[srfAdr]
    I2COut SDA, SCL, SRFPFail, srfAdr, SRFCmdReg, [80]	; do a ping in inches...
    srfRange = 0
SRFP2
#if 0
	pause 1
	i2cin SDA, SCL, SRFCmdReg,[srfLightVal]
	if srfLightVal = 0xff then
		srfRange = srfRange + 1
		if srfRange > 150 then
			goto SRFPFail
		endif
		goto SRFP2
	endif
#else
	pause 67
#endif		
	    
    ; lets try to wait until the Ping completes
    i2cin SDA, SCL, srfAdr, SRFRangeReg, [srfRange.HighByte, srfRange.LowByte]
	return srfRange
SRFPFail
	return 0xffff	

SRFLight[srfAdr]  
    i2cin SDA, SCL, srfAdr, SRFLightReg, [SRFLightVal]
	return srfLightVal

I am not sure if the output from this is 100% correct yet, but the ranges do change when I move my hand in and out from the sensor. I was playing with the code trying to query the sensor to see if it was still busy instead of simply doing a pause.

Do you have pull-up resistors on your SCL and SDA lines?

Kurt

3

It looks like I am having success now! I had two problems, one with my circuit, and one with my program. I fixed both and now I seem to be having some success.

My WriteI2C routine is not going to the Failed label now. :smiley:

Ummmm, well, I did have resistors on the SDA/SCL lines, but they were, shall we say, pull downs instead of pull ups… They are pull downs now. :smiley:

My other problem was my device address was not correct. The MCP23017 has three hardware address lines (A0 - A2, pins 15 - 17), and my device address did not match the way I had the hardware address lines jumpered. Now my device address matches the hardware address lines. :smiley:

Now I am understanding how I2C works, or at least am starting to understand it. :slight_smile: It is not so difficult when the device address is correct and there are proper pull ups on the SDA/SCL lines. :smiley:

Now I can go on and see if I can actually read and write data using the MCP23017. I wired up the traffic light circuit from the Atom manual, got that working, and then modified it to have a cross traffic signal also. The new traffic light program almost works the way I want it to, but does not have the short red/red period in one place before the transition to green. That’s OK though, for now, because I can still use this circuit to test whether I am using the MCP23017 correctly for output.

Thanks for your pointers - they helped me find and fix the problems I had. :smiley:

8-Dale

4

You are welcome! :smiley:

5

:smiley::smiley:

I made my WriteI2C routine more general so it can be used to write to any device, to any register, with any data.

[code]devaddr var byte ’ Device Address/Control Byte
regaddr var byte ’ Register Address to write to
outdat var byte ’ Data byte to write
WriteI2C [devaddr, regaddr, outdat]
high yellowLED
pause 1000
low yellowLED

i2cout SDA,SCL, Failed, devaddr, regaddr, [outdat]

serout S_OUT, N2400, "Wrote byte ", HEX outdat, ", at address ", HEX regaddr, 13]
high greenLED
pause 1000
low greenLED
goto WriteDone

Failed:
serout S_OUT, N2400, “Output to I/O Expander failed!”, 13]
high redLED
pause 1000
low redLED
return

WriteDone:
return[/code]

Once I am more confident in my usage of I2C and my code works reliably, I will remove the LED indicators, and will have it return a failed flag (like $FF) when the write fails. :smiley: So far, this routine seems to be working at least some of the time. :slight_smile:

I do seem to have a timing issue, so probably need some sort of a pause after I do a write to the I2C bus, so will research that and make any appropriate change(s) to my code.

I’ll post more when I have solved my timing problem and successfully written data to and read data from the MCP23017.

8-Dale

6

Apparently I did not have a timing issue at all. The MCP23017 was not being properly reset at power up. So, I tied p12 to reset [MCP23017 pin 18] and toggle it low and then high again at the start of my mainline. That seems to have fixed any problem I had. :smiley:

8-Dale

7

I can successfully blink an LED that is connected to port A of the MCP23017 now. :smiley: I am pretty confident now that my WriteI2C routine is reliable. I have defined constants for some registers I am not using.

Here is my current code:

[code]’
’ I2C Test Program for Microchip MCP23017 I/O Expander
’
’
greenLED con p8
yellowLED con p7
redLED con p6

’ I2C Configuration
I2C_SCL con p10 ’ I2C Clock
I2C_SDA con p11 ’ I2C Data

’ MCP23017 Hardware Setup
MCP_Reset con p12 ’ Hardware RESET, tied to MCP23017 pin 18

’ Microchip MCP27013 I/O Expander Configuration
MCP_DevWr con %01000000 ’ MCP23017 Control Byte (Write Register)
MCP_DevRd con %01000001 ’ MCP23017 Control Byte (Read Register)

'======================================================================================
’ Port A Registers
iodira con 0x00 ’ Direction Bit Control Reg
iobitsa con %00000000 ’ Direction Bit Settings Reg (0 = output, 1 = input)

ipola con 0x01 ’ Interrupt Polarity Control Reg
gpintena con 0x02 ’ Interrupt Enable Reg

iocona con 0x05 ’ I/O Configuration Reg
ioconseta con %11110001 ’ IOCON register setting

gppua con 0x06 ’ Pull-Up Control Reg
gpioa con 0x09 ’ General Purpose I/O
olata con 0x0A ’ Output Latch Reg

’ Port B Registers
iodirb con 0x10 ’ Port B Direction Bit Control Address
iobitsb con %00000000 ’ Port B Direction Bit Settings (0 = output, 1 = input)

ipolb con 0x11 ’ Interrupt Polarity Control
gpintenb con 0x12 ’ Interrupt Enable Reg

ioconb con 0x15 ’ I/O Configuration Reg
ioconsetb con %11110001 ’ IOCON register setting

gppub con 0x16 ’ Pull-Up Control Reg
gpiob con 0x19 ’ General Purpose I/O Reg
olatb con 0x1A ’ Output Latch Reg
'========================================================================================
MCP_Status var word ’ Return Status/Result from I2C routines

high redLED
low yellowLED
high greenLED
pause 1000

low redLED
low greenLED

Main:
’ Reset the MCP23017
low MCP_Reset
high MCP_Reset

' Port A
gosub I2C_Write [MCP_DevWr, iocona, ioconseta]
gosub I2C_Write [MCP_DevWr, iodira, iobitsa]		' Set I/O pins direction
gosub I2C_Write [MCP_DevWr, olata, $FF]			' All pins follow the gpioa reg

while 1
	gosub I2C_Write [MCP_DevWr, gpioa, $01]		' Set Bit 0 of Port A
	pause 500
	gosub I2C_Write [MCP_DevWr, gpioa, $00]		' Reset Bit 0 of Port A
	pause 500
wend

goto Exit

devaddr var byte ’ Device Address/Control Byte
regaddr var byte ’ Register Address to write to
outdat var byte ’ Data byte to write
I2C_Write [devaddr, regaddr, outdat]
i2cout I2C_SDA, I2C_SCL, Failed, devaddr, regaddr, [outdat]
goto WriteDone

Failed:
return $FFFF

WriteDone:
return 0

Exit:
low redLED
low greenLED
low yellowLED
end[/code]

I do not yet fully understand how the gpio and olat registers interact. I seem to have to write $FF to the olata register before I can see the LED following what I write to the gpioa register. I have the LED tied to MCP23017 pin 21 (Port A, Pin 0), but if I just write $01 to the olata register, nothing happens when I write to the gpioa register. I thought the olata register just controlled which pins would be allowed to change states, but I am not sure exactly how it works. I am writing $FF to the olata register now and I can blink the LED.

Now that I know how to work with the MCP23017, I can add 16 general purpose I/O pins to any Atom or other microcontroller. :smiley:

8-Dale

8

This is more about my quest to utilize a Microchip MCP23017 I2C I/O Expander with the Atom PRO. I have two MCP23017’s on the I2C bus and I can address both of them properly, but can only write to Port A of each of them (the GPIOA and OLATA registers).

I have been reading the Atom PRO manual about I2C and how the PRO handles it. It says bit 0 of the control byte determines whether 8 or 16 bit addressing is used.

This does not match what the data sheet for the MCP23017 says, which is that bit 0 of the control byte is a Read/Write selection bit. If bit 0 is 0 then a register will be written, and if it is 1, the register will be read.

The control byte for an MCP23017 would be:

[0 1 0 0 A2 A1 A0 R/W] where R/W is 0 to write a register and 1 to read a register.

The MCP23017 has two 8 bit ports or one 16 bit port, depending on how bit 7 of the IOCON register is set. If IOCON bit 7 = 0 then the ports are treated as a single 16 bit port. If IOCON bit 7 = 1 then the ports are two 8 bit ports and are treated separately.

I do not understand how the Atom PRO handles I2C data transfers of more than a single byte. No matter how I configure the MCP23017, I can not get Port B to work - not in either 8 bit or 16 bit mode.

I have read and reread both the Atom PRO manual and the Microchip datasheet for the MCP23017, and no matter how I configure the MCP23017, I can not get it to do what the datasheet says it should do in 16 bit mode. I can’t even access port B in 8 bit mode. :frowning: :frowning:

8-Dale

9

I am only guessing, but my guess is that bit 0 is overloaded here. As there are two commands I2cin and I2cOut, they take care of oring in the low bit on the command. This leaves them the ability to before the and off or or in the low order bit, to test it and use this value to know which type of address to use.

So in your case I do not believe that you need 16 bit addressing as you have only 22 registers to read or write, which fit easily in 8 bit addressing.

I have not used this chip before, but I believe that I would go in 8 bit mode. If I read their datasheet correctly the IOCONs are both the same? But do you need to write the same configuration byte out for both of them?

It looks like you are properly setting the chip into 8 bit made (high bit set in control word).

So it seems like if you duplicate the Port A setion with a Port B section you should be able to write to both? Have you tried to read the values back in to see what is there?

Good Luck
Kurt

10

I have been reading on the Basic Micro forums about I2C and the Atom Pro. From what I read there, it appears there is a problem with the way the Atom PRO is doing I2C. I believe this has to do with the way bit 0 of the control word, which holds the device code (4 bits), device address (3 bits), and the R/W bit (0 = write, 1 = read).

If I set bit 0 of the control byte to 1 as the Atom PRO maual shows for 16 Bit addressing, nothing in my circuit works. This is because the MCP23017 interrprets that bit as R/W mode (0 = Write, 1 = Read), which means read a register. Obviously, I can’t read anything when I use the i2cOUT command. :slight_smile:

Using 16 bit mode gives a much smoother “motion” of the LED lights than 8 bit mode does. In any case, I am trying to learn how to use the I/O Expander, so I want to exercise all of its capability and modes of use. :smiley:

In 8 Bit mode, there are two separate sets of identical registers - one set for Port A and the other for Port B. In my case, I write the same configuration to both sets of registers when I use 8 Bit mode. This is working perfectly now.

It is the 16 Bit mode that is not working for me. When I set the MCP23017 up for 16 Bit mode (IOCONA bit 0 = 0), IODIRA = $0000, OLATA = $FFFF), I can see that there are two data bytes being written, but they are both being written to Port A at the same time. The data is correct, but the second byte should be going to Port B. It almost works like it should.

Now something really odd has happened - 16 Bit mode has started to work. There is still a slight glitch, but it is now working and I don’t understand what I did to make it work.

8-Dale

11

I believe that there is a confusion factor here on 8 bit mode and 16 bit mode.

I believe the I2C 16 bit mode talks is more about the address parameter. Again this is needed for things like I2c EEPROMS where you need to address more than 256 different addresses on the device. So on your chip you want to probably talk to the chip with 8 bit addressing. However you may wish to configure the chip to be in 16 bit mode. This appears to change the order of the registers. So then you could do something like:
i2cout I2C_SDA, I2C_SCL, Failded, MCP_DevWr, gpioa, $00, $00]
to write two byte into the registers starting at gpioa. Note, you may need to set the appropriate control bit to increment to the next register.

I hope this makes sense?

12

There is a conflict between the way the Atom PRO wants to use bit 0 of the control byte and how the device being controlled expects to react to that bit.

My device (the MCP23017) uses bit 0 to tell it whether I want to write (bit 0 = 0) or read (bit 0 = 1) a register. This is where the problem is and where I believe the Atom PRO may not be doing things correctly. If I set bit 0 = 1 in the control byte, that would tell the Atom PRO I want to use 16 Bit addressing, but it would tell the MCP23017 that I want to read a register (either 8 Bit or 16 Bit, depending on the chips IOCON.BANK bit setting. I do not know if this is related to how the Atom PRO wants to write two bytes to Port A sometimes, when the MCP23017 is in 16 Bit mode.

Yes, I address the chip’s registers using an 8 Bit address, and the chip pairs the registers internally when it is configured for 16 Bit mode. The addresses of the chips registers are different for 8 Bit and 16 Bit modes - the registers are banked in 8 Bit mode (Port A and Port B register banks) and paired in 16 Bit mode (gpioA and gpioB are treated as a 16 bit register pair and are at sequential addresses).

This is what I am doing now for the 16 Bit mode of the MCP23017.

It’s really odd, because I have one 16 Bit mode sequence working and the sequence right after it does not work right. :frowning: This is giving me a headache :frowning: so I have to take a break from working on it.

8-Dale

13

Yes, I believe that this is true for all I2C (or TWI) devices. For example the SRF08 Rangefinder default address: E0 for a write E1 for a read. So when I call their I2CWrite function or I2CRead function I always pass E0 to both functions.

I don’t have the I2C interface out right now and the last time I implemented it was on an AVR chip in C, using the hardware support. But my guess is that when you call something like:
I2cRead SDA, SCL, …, ADDR, [b1, b2]

It would translate sortof like a C++ function I had before like:

[code]unsigned int SRF::ReadRegister(unsigned char srf10_register)
{
union i2c_union {
unsigned int rx_word;
unsigned char rx_byte[2];
} i2c;

I2C_START_TX(m_bAddress);
i2c_transmit(srf10_register);
I2C_START_RX(m_bAddress);

/* get high byte msb first */ 
i2c.rx_byte[1]=0;		// in case returning SRF_LIGHT or SRF_COMMAND 
if(srf10_register>=2) 
	i2c.rx_byte[1]=i2c_receive(I2C_CONTINUE);


/* get low byte msb first  */ 
i2c.rx_byte[0]=i2c_receive(I2C_QUIT);                          

i2c_stop();

return(i2c.rx_word);
[/code]
Note: the only difference in the start for read and start for write is the the 0x01 is ored in.

Note sure if this helped, but I have gone through this same headache a few times before (AVR, RoboNova and now Atom Pro) with a few different devices and sometimes I give up (RoboNova).

My Guess is that if you try to do the read passing in E1, their code will end up generating code like above except:

[code]unsigned int SRF::ReadRegister(unsigned char srf10_register)
{
union i2c_union {
unsigned int rx_word;
unsigned char rx_byte[2];
} i2c;

I2C_START_TX(m_bAddress);
i2c_transmit(srf10_register);
            i2c_transmit(0);                        ;;; second byte of address.!!!
I2C_START_RX(m_bAddress);
            ...
i2c_stop();

return(i2c.rx_word);
[/code]
Depending on if it outputs MSB or LSB of the address first, your chip might always write a zero to the register you are trying to read, or it might always write the address you are passing in to register 0.

Just guessing :confused:

Kurt

14

I sure hope it’s true of all I2C devices, because nothing could communicate well if it wasn’t. It should not be this difficult to get a standard protocol working between like devices (those speaking the same protocol). I tend to think that the Atom PRO is not doing something quite right from what I read on the Basic Micro forums.

I am about to give up on the Atom PRO for I2C and in general move to another microcontroller. Besides this I2C thing, there are other things that are not as intuitive as they should be. One case is the MAX function returning the smallest and MIN returning the largest - that’s just plain backwards.

I need to either get my PIC programmer and get to work building one of Pete’s boards or get something lilke a Tini2138 with development board, or the MAKE Controller. I at least need a reference for comparison when things don’t seem to be working, and I don’t have that reference now. The Atoms are the first microcontrollers I have worked with.

8-Dale

15

Well think abou tthe MAX and MIN functions for just a second. MAX limits the MAXimum value. Min limits the MINimum value. Seems pretty intuitive to me.

somevar = someothervar MAX 10 ;somevar will have a MAX value of 10

somevar = someothervar MIN 10 ;somevar will have a MIN value of 10

As for I2C…

I think the one thing that confuses most people about I2c is the command byte. Since the Atom(Pro) has both an in and out command for i2c the command already knows whether you are reading or writing and properly sets the read/write bit of the command byte for you. Instead it uses that bit to determine whether the user is uing 16 or 8bit addressing.

The I2C commands on the Atom and AtomPro(and MBasic in general) are designed to work with those devices that meet the Philips specifiactions and were primarily tested on i2c memory devices(eg eeproms). So far the only complaint I’ve had from a user that came down to a signalling issue would have required me to make the i2c command not conform to the philips spec(by removing a NAK). ALL other cases were users either not connecting their devices correctly(some devices need larger/smaller pullups than others) or not understanding how or what to send to their device to get it to work(eg Command byte,Addressbyte and/or data bytes were incorrect). I have no control over either of these cases.

16

Why do I have to set bit 0 of the control byte according to what my device wants for it to work properly then?? My device (the Microchip MCP23017) wants bit 0 of the control byte to be a R/W flag (0 = write, 1 = read) for registers. If I don’t set bit 0 according to what my device wants, I do not get the results I want. If I set bit 0 = 1, then I can not write to my device’s registers.

Are you saying that I2C on the Atom Pro is just not going to be useful for anything except memory devices? If the I2C of the Atom PRO is designed according to the Philips specifications, then there should not be any problems using it with any I2C compatible device, regardless of type, when interfaciing according to the specifications of the protocol and the device.

Was this user just using a memory device or were they trying to interface with some other type of I2C device?

I see indications of other complaints on your own forums, which I have been reading. I’ve seen posts from users saying there is a problem because the Atom PRO does not implement the bus hold feature of the I2C protocol. There is a thread called “I2CIN and I2COUT” in the Atom Pro Software section of your forums that you should read if you have not seen it. I am digging into the I2C protocol deeper to find out exactly how it is supposed to work so I can understand discussions about it better.

I realize you don’t have any control over the above issues. I was using 1K pull-ups but have switched to 4.7K pull-ups on the I2C bus now.

I have read the datasheet for the MCP23017 many times in order while trying to find something I may be doing wrong. I can’t find any fault with how I am using I2C with the MCP23017. I have three different MCP23017 chips, and they all show the same behavior when using the Atom PRO’s I2COUT command.

If using I2C with the Atom PRO is not going to work with anything but memory devices, I will probably have to find another controller that will work with other things also. There are I2C sensors (SRF02/SRF08/SRF10, TPA01, compass, etc) and devices such as the MCP23017 I want to use. I love to tinker, and when I get bored (a very bad thing for me) or just want to work with something new, I dig into new stuff I have not used before and start working with it. Now is the time for me to explore I2C, especially since the Atom PRO has limited I/O pins available and I need more digital I/O for various things - one having to do with an LED display project I am working on.

I really like the Atom PRO, but I need to be able to use all of the features it has, according to published protocol standards. If there is some place the Atom PRO does not adhere to the I2C standard or where a feature has not been implemented that affects use with some devices, this needs to be corrected so it works with all I2C compatible devices. I’ve done everything I can think of to get this to work properly, and I am out of ideas.

Right now, I have two MCP23017 chips on the I2C bus. One is driving 7 LEDs on Port A and the other chip is driving 16 LEDs using both ports. I can address both chips just fine. I am trying to use the second MCP23017 in 16 Bit mode to get smoother sequencing on the LEDs. I have an Atom PRO pin tied to the RESET line of both chips so I can manually reset them at startup.

I am an advanced user, and I tend to eventually use ALL the features of whatever device I am working with, including the Atom PRO. I’d like to use SPI also, but I have to read up on the PRO’s serial capabilities to see if it can do this.

8-Dale

17

Hi Dale,

I believe that all of our devices meet the Philips standard. As Acidtech mentioned they internally to their command or in the low order bit when necessary.

If you would like you might post your current code or PM it to me and I will take a look to see if I see anything.

The biggest problems I have had in the past is some devices appear to be pretty timing sensitive.

The other thing I was thinking of trying was to try out the hardware support for I2C in the underlying Microcontroller. Or alternatively you can always try it the way I was trying to make it work on the RoboNova.
Which is to manually in Basic do all of the work, such as:

[code]i2c_transmit:

FOR bit = 0 TO 7
	IF  data AND &H80 THEN
		OUT sda, 0
	ELSE 
		OUT sda, 1
	ENDIF
	
    OUT scl, 0
    DELAY 1
    OUT scl, 1
    DELAY 1
    data = data<<1
 
 NEXT bit
 
 
' Release the I2c Bus
OUT sda, 0
OUT scl, 0

'Look FOR AKNOWLEDGE 
error = 0		' assume no errors
delay 1

bit = IN(sda)

IF bit = 0 THEN
	OUT scl, 1
    DELAY 1
ELSE
	 DELAY 50
	 
	 bit = IN(sda)
	 
	 IF bit = 0 THEN
	     out scl, 1
	     delay 1
	 ELSE 
	 	error = 1
	 	RETURN
	 ENDIF
ENDIF

bit = IN(sda)

IF bit = 0 THEN
	DELAY 100
	bit = IN(sda)

	IF bit = 0 THEN
		error = 1	' device busy
		RETURN
	END IF
 END IF
   
RETURN

[/code]
This was real painful, but I was able to make it semi work. But I think this approach would be my last choice!!!

Kurt

18

I’ve been trying to get the H8/3664F manual, but can’t seem to find it anywhere. The Renesas site is a real pain to find anything on. I still haven’t found the hardware manual for the H8/3664F.

8-Dale

19

[quote="linuxguyI’ve been trying to get the H8/3664F manual, but can’t seem to find it anywhere. The Renesas site is a real pain to find anything on. I still haven’t found the hardware manual for the H8/3664F.
]
Try this link: documentation.renesas.com/eng/products/mpumcu/rej09b0142_h83664.pdf

It actually looks like a very nice microcontroller.

Kurt
[/quote]

20

If I read Acidtech’s post correctly you are mis-interpreting how the I2C functions in the atom pro work. bit 0 being R/W is part of the I2C specification and its value determined by whether you call the read or write function. YOU don’t set it, the function sets it. At the programming level the bit has been redefined for the read and write functions to be used as a 8 or 16 bit data size flag. For your device I would expect it to always be set for 8-bit transactions since that is the data size the mcp23017 is expecting.