Simple example of I2c code " My World" request

[olzeke51]

Okay,
the data sheet indicates that P0.10 & P0.11 are not open drain pins
pg 8 of the DataSheet, - may need to select another pair.
The GPIO section does mention that most pins can be configured for 'open-drain';
so I assume those can't be 'opened' - maybe need a different pair.
'
since you are using the I2C.bas - those are bit-banged (iirc) and any two can be used.
HTH,
Gary

PS I think the board can handle 5v inputs - but it is a 3.3v supplied chip , so the
question is can the Display board handle the 'hi' signal of about whatever voltage
kyou have the pullups tied to??

[basicchip]

Yes those pins are not normally open drain, but the I2C.bas routines either drive the pin low, or make it an input, effectively open drain.

Check power to the display, make sure you are actually wiggling the right pins, if you don't have a scope, I posted a blog article about how to build a logic probe. You can use any of our boards, and change pin assignments. I found it sometimes more useful than a scope, as it was a quick way to trace out control lines wiggling.

https://www.coridium.us/coridium/blog/b ... ogic-probe

Pullups to 5V are OK for all the NXP parts. You mentioned 4.7K, normally I use 1K, but that might be OK, depending on the capacitance loading, that is where a scope would help.

[olzeke51]

Yo',
I think I have an Adafruit I2C display,
I'll dig out my SP and see what happens.
Be a day or two....
Gary

OOPs - it is an SPI device

[olzeke51]

Okay, got a system scanning and displaying the address of an RTC on I2C
here is the code - took out the cruft that was in it:::

Code: Select all

' i2c device present per AB example in helpfile
' 
'SUB I2CIN ( DATApin, CLKpin, addr, OUTcnt, BYREF shortMessage as string, INcnt, BYREF INlist as string)
'
'FUNCTION I2COUT (DATApin, CLKpin, addr, OUTcnt, BYREF shortMessage as string)
' 
'#define I2Cspeed100                 ' add this statement before the #include <I2C.bas> for 100 Kb shift rate
#define I2Cspeed50                   ' for 50 Kb shift rate
#include "CORIDIUM_PCB.bas"

#include <I2C.bas>


DIM shortMessage(20) as STRING
DIM shortResponse(20) as STRING

'******************************

'/* Function that probes all available slaves connected to an I2C bus */
'_i2c_probe_slaves:
main:

	DIM i, Dev_addr, present, temp
	shortMessage(0)=&H00	'not sure what a probe takes or address query


	print "Probing available I2C devices..."
	print "     00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F"
	print "====================================================" 
	'for i = 0 to (i <= 0x7F)'
stop
		'if (not (i AND 0x0F)) then 			print "0";i;"   ";	'( i >> 4);
		print "    ";
				for 	i = 0 to  7		'then '((i <= 7) or (i > 0x78)) then
			    print " -";
				 next
				 
			for i = 8 to 120

			temp = i	
			Dev_addr = temp << 1	'shifts the addy one bit 
			shortMessage(0)=&H00
    		 present = I2COUT (10, 11, Dev_addr, -1, shortMessage)		'Coridium routine'pinned for 1768-sda2
				if present =  0	then 	print " .."; else print "   "; HEX(i);		'i2c_error(true, probe.status)
				if i mod 15 = 0 then 
					print 
					print "    ";
				endif
				'i += 1
				wait(100)  'was 10
			next
				'
				for  i = 121 to 128		'&H78
				print " --";
				next


print
stop

'
and then this is what BT printed out..... my address is 68
maybe the 80 address is the hex value - as my doc didn't specify HEX
check youir SDA & SCL - my SCL had to goto IO-11, and SDA to IO-10
per my programmed line ::
present = I2COUT (10, 11, Dev_addr, -1, shortMessage) 'Coridium routine'pinned for 1768

'

... Finished in 50240 ms
Executing...

Probing available I2C devices...
00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
====================================================

Coridium Break:

@ hex [yy] - dump at hex yy words
! hex yy - write yy to hex
^ to continue^

- - - - - - - - .. .. .. .. .. .. .. ..
.. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
.. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
.. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
.. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
.. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
.. .. .. .. .. .. .. .. .. .. .. .. .. 68 ..
.. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
-- -- -- -- -- -- -- --

Coridium Break:

@ hex [yy] - dump at hex yy words
! hex yy - write yy to hex
^ to continue

[basicchip]

While it mentions 80 as the default address in the spec, it never specifies hex or decimal. I see your code uses decimal, maybe its hex? But you should narrow down why the i2c routines are returning 0, which means ACKs are not being received.

[jmcdougall]

I think I may have found the issue. Please note that many of the Matrix Orbital display also have GPIO pins. On the main display I have, ( I have a main and 2 secondary ones that will be driven from the smaller Coridium processors) there are 3 bicolor leads and a 7 button input.

I ofund this in one of the MO app notes.
"We usae a standard Phillips 7 bit addres as defioned by Phillips. However we at MO specify the I2C address ion 8 bits. The 8th bit, least significant bit (LSBor LOW Order BIT) of teh 8 bit address is read/write bit. If we take a std Phillips 7 bit address of 45hex this would be binary 1000101. t6his is 7 bits. If one ads the read write bit to thsi 7 bit address and assume that you are writing one gets 10001010. MO would describe the Phillips I2C address if 45hex as 8A hex. The read address would be 8B hex."

I am assuming that I2C.bas does not do this.

What do I need to do to I2C.bas to accommodate this? I am more of an app and variable person and not a hex and binary person

Thank you!

[basicchip]

I2C.bas treats the address as an 8 bit value with the LSB indicating read or write.

What that does tell me that the 80 address is decimal as 80 hex would be an 8 bit address not 7.

So there is something else going on.

[olzeke51]

so did my latest suggested code work and identify the address??
check your SDA & SCL pin assignments
Gary

[basicchip]

Debugging involves walking before you can run.

Once you made sure power is correct to both devices.

Next you check whether the i2c SCL and SDA lines are wiggling (logic probe is fine, maybe even a meter)

Then can you address the device? Note that the I2Cspeed50 must be done before I2C.bas (maybe that is your issue)

Code: Select all

#define I2Cspeed50
#include <I2C.bas>

DIM LCD_CMD(8)
DIM LCD_DATA(16)

LCD_CMD(0) = 254
LCD_CMD(1) = 54  ' get the version number
print I2CIN(10,11,80,2,LCD_CMD,1,LCD_DATA)      ' if this does not show 1, then the display is not responding
print LCD_DATA(0)                               ' unless the previous number is 1, then this is meaningless

If you don't get a 1 printed, the display is not responding.

No sense in proceeding until you figure out why, maybe that why is the spec is very specific for serial, but doesn't really speak about i2c

[jmcdougall]

I moved the positive lead for the display to a separate PS and tied the grounds from the PS and the display and the processor together. I changed teh resisters from the SDA and SCl lines to 2.2k and tied them to the processor +5v. The processor is power by the USB adapter(from Coridium) I ran the BT example and it can back with x28 - decimal 40. OK so far so good.

I changed my program to use decimal 40 and tried to compile.
From then on, I get this.
(see attachment)
Now that is all I get no matter what I do.

Next steps?