ive taken this from J-P thread in the archive.. ive try with phanderson bit bang style of i2c communication controlling the DAC (MAX518) and it works fine.. but, maybe slow response i guess.. since im using 18x now, which it already have i2c SDL SDA naturally, im thinking why not i try with this code above that using writei2c instead.. then, when i try with this code, it never work as expected.. can we revise this thread again, finding a better solution of communicating i2c DAC with PICAXE?
MAX518 solution again
- Thread starter Akat
- Start date
hippy
Ex-Staff (retired)
There is no better solution for using hardware I2C as those are the only commands available to use that. The question is why it doesn't work for yourself ...
* Incorrect 18X pins used for SDA and SCL ?
* Missing / incorrect pull-ups on SDA or SCL ?
* Different / wrong address selection on MAX518
* Incorrect I2CSLAVE addresses ?
An example of your bit-banged code which works, hardware I2C code which doesn't, and a circuit diagram is the best way to let people see if there's anything obvious they can spot.
A link to the original MAX518 postings would also help, saving people from having to hunt that down to see if it contains any useful or applicable information.
* Incorrect 18X pins used for SDA and SCL ?
* Missing / incorrect pull-ups on SDA or SCL ?
* Different / wrong address selection on MAX518
* Incorrect I2CSLAVE addresses ?
An example of your bit-banged code which works, hardware I2C code which doesn't, and a circuit diagram is the best way to let people see if there's anything obvious they can spot.
A link to the original MAX518 postings would also help, saving people from having to hunt that down to see if it contains any useful or applicable information.
this is the bit bang codes that works (for 18x).. bit bang from phanderson:
this is nor working codes from J-P (i'm sorry, not to say that ur codes not working at all, it just not working on my 18x, maybe my implementation is wrong somewhere):
and this my circuit:
where i think pin 10 and 7 is correct for scl and sda.. ??? where did i do wrong here? why the first code works and second doesn't?
Code:
Symbol SCL = outpin10
Symbol SDA = outpin7
Symbol MAX518SetChannel0 = $00
Symbol DevAdr = B0
Symbol DACVal = B1
Symbol OByte = B2
Symbol N = B3
setFreq m8 'i overclocked this for some reason
Main:
GoSub I2CStart
OByte = DevAdr * 2 + $58
GoSub I2COutByte
OByte = MAX518SetChannel0 ' set DAC on Channel 0 (i only need to read from channel0)
GoSub I2COutByte
ReadADC 0,OByte ' send the DAC value
GoSub I2COutByte ' and the PWM duty in the low five bits
GoSub I2CStop
GoTo Main
I2CStart:
SDA = 1
SCL = 1
SDA = 0 ' bring SDA low when SCL is high
SCL = 0
Return
I2CStop:
SCL = 1
SDA = 1 ' bring SDA high when SCL is high
Return
I2COutByte:
For N = 1 to 8
SDA = OByte / 128 ' most sign bit
SCL = 1
SCL = 0
OByte = OByte * 2 ' shift byte such that next bit is in most sig bit position
Next
SDA = 1 ' null clock pulse to allow for slave to acknowledge
SCL = 1
SCL = 0
SDA = 0
Return
Code:
symbol oByte, b0
setfreq m8 'i overclocked this for some reason
i2cslave $58, i2cfast, i2cbyte 'MAX518 DAC
main:
readADC 0,oByte
writei2c $00,(oByte) 'DAC Channel 0
goto main
Code:
both scl and sda were 4.7k pull up
------------- -----------
| picAxe18x | | MAX518 |
| scl 10|------------------------------------------|scl |
| sda 7|------------------------------------------|sda |
------------- ----------BeanieBots
Moderator
leg 7 is sda
leg 10 is scl
leg 10 is scl
hippy
Ex-Staff (retired)
I cannot see any obvious reason it shouldn't work ( ignoring the SYMBOL typo ) and it's how I'd do it - Leg 7 SDA, Leg 10 SCL is correct, 4K7 pull-ups should be okay.
I'd suggest changing 'i2cfast' to 'i2cslow', removing 'setfreq m8', and seeing if that does any better. It could be that the I2C command version is simply running too fast for the MAX518.
The bit-banged code violates the I2C specification in that it always keeps SDA driven high or low, even when it should be high-impedence ( input / floating ) during ACK - Unless you have a diode, from SDA pull-up, pointy-end to PICAXE leg 7.
Without the diode it is possible to damage the PICAXE output pin; it's high, the MAX518 shorts it to 0V, lots of current. This is a short term event so there's a good chance the PICAXE would survive but no guarantee of that.
An improvement without such a diode would be to remove the SDA=1 after the NEXT and put an SDA=0 after the SCL=0 in the FOR-NEXT loop. This is electrically safer and, as you're not checking the ACK is actually generated, what's on the SDA line at that time should not matter.
The differences between the bit-banged version and I2C command version is -
* The bit-banged version runs much slower than using the I2C commands.
* The bit-banged version hard-drives both SCL and SDA, the I2C command will soft-drive both SCL and SDA. The pull-ups are not as important ( not even necessary ) for the bit-banged version, they are very important in the I2C command version.
* The bit-banged version does not check the ACK reply, the I2C command version likely does.
I'd therefore presume the reason it doesn't work comes down to one of the above.
I'd suggest changing 'i2cfast' to 'i2cslow', removing 'setfreq m8', and seeing if that does any better. It could be that the I2C command version is simply running too fast for the MAX518.
The bit-banged code violates the I2C specification in that it always keeps SDA driven high or low, even when it should be high-impedence ( input / floating ) during ACK - Unless you have a diode, from SDA pull-up, pointy-end to PICAXE leg 7.
Without the diode it is possible to damage the PICAXE output pin; it's high, the MAX518 shorts it to 0V, lots of current. This is a short term event so there's a good chance the PICAXE would survive but no guarantee of that.
An improvement without such a diode would be to remove the SDA=1 after the NEXT and put an SDA=0 after the SCL=0 in the FOR-NEXT loop. This is electrically safer and, as you're not checking the ACK is actually generated, what's on the SDA line at that time should not matter.
The differences between the bit-banged version and I2C command version is -
* The bit-banged version runs much slower than using the I2C commands.
* The bit-banged version hard-drives both SCL and SDA, the I2C command will soft-drive both SCL and SDA. The pull-ups are not as important ( not even necessary ) for the bit-banged version, they are very important in the I2C command version.
* The bit-banged version does not check the ACK reply, the I2C command version likely does.
I'd therefore presume the reason it doesn't work comes down to one of the above.
Just a thought.
You mention that you will also have an eeprom in circuit.
Found when breadboarding with i2c that the bus must not have any unused sections.
Had a 28X1, RTC, Accelerometer and MCP23016 wired but the accelerometer was not powered - the i2c bus just did not work. If the wiring was removed to the accelerometer, or, the accelerometer was powered everything worked OK.
Are there any non-functional parts to the bus in your development circuit?
You mention that you will also have an eeprom in circuit.
Found when breadboarding with i2c that the bus must not have any unused sections.
Had a 28X1, RTC, Accelerometer and MCP23016 wired but the accelerometer was not powered - the i2c bus just did not work. If the wiring was removed to the accelerometer, or, the accelerometer was powered everything worked OK.
Are there any non-functional parts to the bus in your development circuit?
phew, its working now 
... and as well in VSM.. the only problem is in VSM it simulate it slow.. which ive tried with bit bang code in the same simulation circuit it works quite fast though.. which make me wonder, which one is really the fastest? bit bang or writei2c?? or is it just slow in simulation, but really fast in reality?
... and as well in VSM.. the only problem is in VSM it simulate it slow.. which ive tried with bit bang code in the same simulation circuit it works quite fast though.. which make me wonder, which one is really the fastest? bit bang or writei2c?? or is it just slow in simulation, but really fast in reality?BeanieBots
Moderator
Harware I2C will always be a lot faster than any bit-bang method.
In a simulation, it simulates the software using software, for the hardware, it must "convert" the hardware into software and then simulate that as well.
This is always a problem with simulators, the very fast hardware solutions may often 'appear' to run slower because there is more simulation to be done.
In a simulation, it simulates the software using software, for the hardware, it must "convert" the hardware into software and then simulate that as well.
This is always a problem with simulators, the very fast hardware solutions may often 'appear' to run slower because there is more simulation to be done.