And thankyou for pioneering!
How are you physically using the chip at the moment? Standard ssop breakout board? I've never tried them, I fear my soldering skills would damage the chip... still, at £3 each, worth a try...
Paul
AS1115 Led Driver - I2C
- Thread starter NVHLVNOP
- Start date
How are you physically using the chip at the moment? Standard ssop breakout board? I've never tried them, I fear my soldering skills would damage the chip... still, at £3 each, worth a try...
Paul
But should simply setting the slave address to "0" cause unexpected behavior on a Picaxe? I don't think "not recommended" means that the Picaxe may hang or reset upon initialization / configuration of the Picaxe as an I2c master device. The Picaxe hang / reset is considerably beyond simply not working. I disagree that this behavior falls within the category of "not recommended". Seems more like firmware bug.
hippy
Ex-Staff (retired)
As I understand it the firmware simply takes the 8-bit device address specified and places it in the 8-bit SSPxADD register and the undesirable outcome is a result of having done that.
The I2C specification does not prohibit use of the 'special meaning' and 'reserved' values as device addresses but we have no control over how PICmicro hardware may behave once given one of those values as an address.
It is possible to have the compilers reject any %0000xxxx or %1111xxxx address with an error and update the documentation to indicate those addresses are not supported. I have passed that suggestion along.
Last edited:
Then that would in effect prohibit the use of an as1115 with a Picaxe since %00000001 works ok. In my non extensive testing, only %00000000 caused the hang / reset, so why would you want to disable the ability to use the other reserved address possibilities? ...
Given the choice between what you have suggested and how it behaves now, I say leave it as is. Or only have the compilers reject %00000000.
westaust55
Moderator
In all reality it is a pretty poor design by AMS for their AS 1115 chip to use $00 as the default address.
It is the General Call slave address with the prime purpose that all slave devices capable of using a general call can respond.
Rather than the reserved + general call %0000 xxxx group address why did AMS not use the more standard %0111 xxxx slave address assigned for display relayed chips as per the Philips/NXP conventions:
http://www.diolan.com/downloads/i2c-address-allocation-table.pdf
It it one thing to have their method of changing the slave address using some of the LED driver pins, but why they could not have used say $10 as the base/default slave address only AMS knows.
Possibly just assigned a slave address (to save registration costs?) without reference to the Philips/NXP i2c address registration to keep like devices with the same address group.
Last edited:
It certainly is odd that AMS chose 0x00 as the default address.
Could it possibly be to facilitate the quick reset and / or address configuration on all As1115 devices in a system where multiple As1115 are used? As I understand, it after the general call address is sent, the next byte ($06) can tell those devices that support it, to reset and then to read the address select pins. This in effect quickly resets all the devices on the I2C bus. That's my best guess.
Could it possibly be to facilitate the quick reset and / or address configuration on all As1115 devices in a system where multiple As1115 are used? As I understand, it after the general call address is sent, the next byte ($06) can tell those devices that support it, to reset and then to read the address select pins. This in effect quickly resets all the devices on the I2C bus. That's my best guess.
hippy
Ex-Staff (retired)
It is normally possible to avoid compiler checks by staging commands through variables rather than constants, so while the following would not compile -
HI2cSetup I2CMASTER, %00000001, I2CSLOW, I2CBYTE
This would -
b0 = %00000001
HI2cSetup I2CMASTER, b0, I2CSLOW, I2CBYTE
That seems to me to be a good solution. It allows us to say they are "not supported" and, if a trick is used to get such use past the compiler, then the programmer takes responsibility for whatever behaviour follows.
That would be consistent with not allowing "HIGH pinC.0" but allowing that to be worked around by using -
b0 = pinC.0
High b0
Buzby
Senior Member
We've been through this Address $00000000 issue before.
I don't consider AMS's choice of address as a poor design, it is a proper use of the General Call as specified by NXP.
See here for the explanation from Technical as to why PIC chips can't do General Call, and so a PICAXE can't either.
http://www.picaxeforum.co.uk/showthread.php?23729-HI2CSETUP-error-on-Address-0&p=236203&viewfull=1#post236203
As the explanation is in an errata note from Microchip, it would seem that they expected it to work, but it doesn't.
We need a new silicon revision from Microchip to fix it, so don't blame AMS for sticking to the NXP spec, blame Microchip !.
Cheers,
Buzby
hippy
Ex-Staff (retired)
My thoughts as well but the I2C specification does allow reserved values to be used, though I am not convinced using it as a pre-programmed address in this chip is fully compliant with the specification -
http://www.nxp.com/documents/user_manual/UM10204.pdf
It would have made sense for the chip to default to a non-reserved address then use General Call ($00) to set each to a unique non-reserved addresses.
hippy
Ex-Staff (retired)
Not necessarily. A read using General Call address becomes a Start byte and "No device is allowed to acknowledge at the reception of the START byte" according to the spec. The device though does acknowledge or it could not return any data.
After configuring multiple device use their addresses then conflict with the reserved values use -
0000 000x - General Call / START byte
0000 001x - CBUS address
0000 010x - Reserved for different bus format
0000 011x - Reserved for future purposes
It's pretty moot though because that's what they've done.
Buzby
Senior Member
I can not see any problem with the initial requirement of a GC to set the address by reading IO pins.
If the chip started up with a fixed address then multiple AS1115 chips would all have the same address, and still need a GC to set a different address.
A fixed address would also need to be unique from any other I2C chips on the bus, so the fixed address would need to be registered with NXP ( or whoever ).
Maybe any commercial product using a 'crippled' PIC and needing GC uses bit-banging to to do the initial setup, then switches to hardware I2C from then on.
It is a real shame that PICs can't do GC, I've got a few ideas that would be nice to try, but need GC.
Does Rev-Ed have any inside knowledge from Microchip as to when this silicon bug is to be fixed ?
Cheers,
Buzby
westaust55
Moderator
Consider beyond just having an AS1115 on your i2c bus.
The general call addresses all devices on the bus using the I2C address $00.
If someone has a project with a number of different i2c devices and we send out slave address $00 to communicate with the AS1115, what happens to the non AS1115 devices that can work properly with the General Call?
Many of us do have multiple type of i2c devices such as EEPROM, RTC, LED drivers, even compass modules and speech modules etc.
It can casue chaos for those non AS1115 devices
The general call addresses all devices on the bus using the I2C address $00.
If someone has a project with a number of different i2c devices and we send out slave address $00 to communicate with the AS1115, what happens to the non AS1115 devices that can work properly with the General Call?
Many of us do have multiple type of i2c devices such as EEPROM, RTC, LED drivers, even compass modules and speech modules etc.
It can casue chaos for those non AS1115 devices
Buzby
Senior Member
Yes, I fully understand the 'Send no Ack, send no data' requirement of the GC, and any chip which does Ack or send data in response to a GC is in breach of the spec.
GC is a powerful tool for configuring the devices on the I2C bus, without needing any of the devices to have any preset address, or .
Anyway, it is as you say a moot point. The AAS1115 is as it is, and the PIC is as it is as well.
There is nothing we can do to change the behaviour of these chips, we just need to comply with their interpretations and limitations regarding the NXP spec.
Cheers,
Buzby
Buzby
Senior Member
It is the responsibility of the circuit designer to know what the chips in his product are doing.
If the CMD $06 is sent to the GC address, then the designer should know what each device will do with that command.
Any ensuing chaos is due to not reading the datasheets !.
Cheers,
Buzby
I bought an SSOP to DIP adapter board, so now the chip just looks like a 28-DIP (4 unused pins). I was scared of SSOP packages before and could never solder them, but a few months ago my work sent me off to get a soldering certification. That gave me plenty of practice and confidence to do this at home now. The 2 most important things are a magnifying lens/microscope, and plenty of flux!
I can get a photo of my breadboard as it is later on. I'm not not sure my code will ever be "final" as I tend to make many revisions. I actually cleaned up the code I posted earlier and got the memory reduced in half. I posted what I have below, and then it is really straightforward to figure out how to do all the other commands.
I played around with the brightness feature, as well as the blinking feature last night. Both pretty neat and easy. This chip is actually very easy to use, once we sorted out the whole GC address issue. I'll post if I ever run into strange things happening as a result of the 00000001 address.
Code:
#picaxe 20x2
#no_table
'=======================================================================================================================================================
'===[TITLE & DESCRIPTION]===============================================================================================================================
'=======================================================================================================================================================
'AS1115 Test Code
'This is test code to figure out how to use the AS1115 LED driver.
'The "counter" variable counts from 0 to 999 and the result is shown on a 3-digit 7-segment LED display with common cathode.
'
' PICAXE-20X2 (defaults to 8MHz internal operation)
' __________
'+5V (+V) -|1 20|- (0V) GROUND
'SERIAL IN (Serial In) -|2 19|- (A.0/Serial Out/16) SERIAL OUT
' (ADC3/C.7/15) -|3 18|- (B.0/ADC1/hint1/0)
' (C.6/input only/14) -|4 17|- (B.1/ADC2/hint2/SRQ/1)
' (hpwm A/pwm C.5/C.5/13) -|5 16|- (B.2/ADC4/C2+/2)
' (hpwm B/SRNQ/C.4/12) -|6 15|- (B.3/ADC5/C2-/3)
' (hpwm C/ADC7/C.3/11) -|7 14|- (B.4/ADC6/hpwm D/C1-/4)
' kb clk/ADC8/C.2/10) -|8 13|- (B.5/ADC10/hi2c sda/hspi sdi/5) I2C SDA
' (hspi sdo/kb data/adc9/C.1/9) -|9 12|- (B.6/ADC11/hserin/6)
' (hserout/C.0/8) -|10 11|- (B.7/hi2c scl/hspi sck/7) I2C SCL
' ----------
'=======================================================================================================================================================
'===[PIN DEFINITIONS]===================================================================================================================================
'=======================================================================================================================================================
'inputs:
'(none)
'outputs:
SYMBOL SCL = b.7
SYMBOL SDA = b.5
'=======================================================================================================================================================
'===[CONSTANTS]=========================================================================================================================================
'=======================================================================================================================================================
SYMBOL TENTHSDIG = %00000001
SYMBOL ONESDIG = %00000010
SYMBOL TENSDIG = %00000011
SYMBOL AS1115_ADDRESS = %00000001 'Bit0 is ignored, and must be 1 for the PICAXE to function
'=======================================================================================================================================================
'===[VARIABLES]=========================================================================================================================================
'=======================================================================================================================================================
SYMBOL TENTHSDIGVAL = b1
SYMBOL ONESDIGVAL = b2
SYMBOL TENSDIGVAL = b3
SYMBOL BRIGHTNESS = b8 'a vaule of 0 to 15 stored in b8 gives minimum to maximum brightness
SYMBOL counter = W9
'=======================================================================================================================================================
'===[INITIALIZATION]====================================================================================================================================
'=======================================================================================================================================================
'prepare for data transfer with LED controller:
hi2csetup i2cmaster, SYMBOL AS1115_ADDRESS, i2cslow_8, i2cbyte 'prepare for data transfer with LED controller.
'reset the registers of the AS1115:
hi2cout 0x0C, (0x01)
'decode mode:
hi2cout %00001001, (0x07)
'set AS1115 LED controller to max brightness:
BRIGHTNESS = 15: hi2cout %00001010, (BRIGHTNESS)
'set AS1115 LED controller to display 8 of the 8 digits even though this code only uses 3 digits:
hi2cout %00001011, (0x07)
'=======================================================================================================================================================
'===[MAIN ROUTINE]======================================================================================================================================
'=======================================================================================================================================================
do
for counter = 0 to 999
TENTHSDIGVAL = counter dig 0 'get the tenths digit of the counter variable
ONESDIGVAL = counter dig 1 'get the ones digit of the counter variable
TENSDIGVAL = counter dig 2 'get the tens digit of the counter variable
if counter <10 THEN LET ONESDIGVAL = 0: endif
if counter <100 THEN LET TENSDIGVAL = 15: endif
SETBIT ONESDIGVAL, 7 'turns on the decimal point between the ones digit and the tenths digit
hi2cout TENTHSDIG, (TENTHSDIGVAL)
hi2cout ONESDIG, (ONESDIGVAL)
hi2cout TENSDIG, (TENSDIGVAL)
pause 100 'this delay can be changed to make the counter go faster or slower.
next
loop
Last edited: