24LC16 addresses for i2c testing

Puzzled myself when using a 24LC16 as a way of testing i2c operation.

The idea was to put one of these chips on a board so that my i2c Master chip could try writing and saving locally to the 24LC16 and contrast this with the result of trying to write and read to other Picaxe chips acting as Slaves elsewhere on the network. I've found i2c to be a bit temperamental when testing on breadboards (and have two or three 20x2's which work fine except for i2c)

What confused me was the addressing of the 24LC16. It IS NOT the same as for a 24LC256.

Both chips have a default address of 160 (1010 0000), and three pins (A0, A1 and A2) for addressing.

But that is as far as the commonality goes.

For the 24LC256, the setting for the three bits  - A0, A1 and A2 - determines the address of the chip above 160. So set A1 to high and the address becomes 164. The unit won't answer to 160 or any of the other possible values.

But for the 24LC16 the datasheet has an enigmatic phrase that I didn't really understand:


It should be noted that the
protocol limits the size of the memory to eight blocks
of 256 words, therefore, the protocol can support only
one 24XX16 per system.


This seems to mean that on the 24LC16 - the chip will answer for EACH of the eight addresses 160 to 174 inclusive (in two's - Picaxe addresses for i2c are always even). It is as if it is an array of eight 2Kb memory chips, at each consecutive even-numbered address from 160 to 174.

i2c failure causes

Warning: this isn't the result of systematic testing and reporting (if anybody has done this, I'd love to read their results) - just the "as far as I can tell" notes from someone who has battled with uncooperative i2c communications between Picaxe chips (mainly via P82B96PN extender chips: see separate note).

My conclusions on i2c Master-Slave communciations between Picaxe chips - if the Master sets a value on the slave, and then reads it back, there are four results you can get:

1. The value you expected. No more to be said.
2. A value of 255 - this probably signifies that the slave isn't there: perhaps the slave chip isn't seeing the i2c, or perhaps there is a problem with SerialIn/SerialOut not having the appropriate resistors, or the rest pin floating.
3. A value of one-more-than-the-i2c-address (ie if the address of your slave is 16, then whatever the actual value of the slave byte, it will read as 17) - this signifies a connection problem on your i2c network. For example, I use a crude set of LEDs to check whether the i2c and 12v power (better for longer runs) lines are at the expected voltages - and whilst the LEDs work as expected, while the tester is connected to the i2c network, any attempts at writing/reading by the Master will result in this n+1 response - presumably because the current drain of the LEDs is too great. Another possible cause would be that you had  accidentally specified an i2c pin (SDA or SCL) as an output on one of the chips. In my experience, if you usually find that if you get this n+1 response from any address on the i2c network, you will get it from all of them. 
4. A value of ZERO. In my experience this results from running the hi2cout and hi2cin commands at too high a speed. For example, if your Master is a 40x2 running at em64 with an eternal resonator, you need to drop the speed (I recommend to m8) for the i2c transactions (remember to reset the speed immediately afterwards). If you don't then you will probably find that other 40x2 Picaxe chips running at em64 will perform correctly, but lower-speed chips will fail, either with a zero or a 255

Picaxe VSM, Virtual Terminal and sertxd

Trying to use a Virtual Terminal on VSM to output status messages: everything seemed fine, but no output visible.

Solution, run simulation, Right-Click on the Virtual Terminal component, then find thebottom option (something like Virtual Terminal - VT1, if you called it VT1) and click on it (right or left). The hitherto-hidden window will appear - the output has been there all the time, but you may not have the window visible unless you specify that.

Picaxe i2c as Slave

Not difficult - but there is one pitfall I fell into.

Having set the slave up to be a slave, it needs to keep looping. It doesn't matter what the loop does (and in a simple application at least, I haven't needed to bother with interrupts).

Example:


#picaxe 20x2
#no_table
symbol counter=b5
HI2CSETUP I2CSLAVE, 20 'sets up with address 20, which I find easier to debug than 010100
main:
inc counter  
goto main


The "main" loop could just have a "pause 5000" in it - but it DOES need to loop

VSM and i2c: Beware

Why are companies so reluctant to tell you what their products won't do?


The Picaxe VSM simulator is a great product if it simulates the functions that you want to use. The problem is that it is sold by Revolution Education with broad claims - ie that it will do simulation "for all M, X, X1, X2 PICAXE chips" and "Support for all major protocols, including RS232, spi, i2c, 1-wire, etc."


But - after investing five or six hours learning my way around VSM (which provides reasonable-but-not-brilliant documentation and limited tutorials, but still involves a big learning curve) - I hit problems with an i2c interaction between two 20x2 Picaxe chips not working as I expected.


So I reduced everything to the absolute basic, with one chip acting as Master, trying to update a single byte on the other, set up as Slave.


It failed - and there in the log (as an item of Information, not an Error) was the message:
Background i2c receive (slave mode) cannot be simulated


I've googled for workarounds or updates - and there are none. So everything points to this being a fundamental limitation of the VSM simulation program as supplied by Revolution Education.


I don't expect the world for sixpence - but I do think it would be rather more grown-up for companies selling products that have known limitations to treat their potential customers like adults and say "This product does all these brilliant things, but please be aware before you buy it that it won't do the following".


UPDATE 23 April 2012


Reply from Picaxe Technical Support:


The current PICAXE X2 VSM models have only been recently added, are in beta state and therefore don't support all that a physical PICAXE may offer; I2C master mode is supported but I2C slave mode currently is not. I2C slave emulation is quite complicated (effectively a whole different model to layer on top) and we do not currently have an estimate as to when that may be supported. 

VSM and the AXE033 display

My first test of the VSM simulator didn't go well - I tried to output a simple text message from a 20x2 to an AXE033 LCD component, and nothing happened.


For once, a quick Google sent me in nearly the right direction, and a bit of trial and error got it sorted soon afterwards


Key points:

• Despite a 2008 promise on the Forum to provide improvements, the VSM will still (in 2012) only write to the AXE033 at T2400 (or T2400_8 if frequency is at m8, eg 20x2)
• If you are writing to the AXE033 as the first thing your program does, you may need to add a delay: in my case 150 milliseconds is enough: a bit less gets you part of the string, and no pause results in no string!

Here is a program to run on a 20x2 with an AXE033 connected to pin C.0:

'test program to get 033 LCD working 
#define forVSM




#ifdef forVSM
symbol baudRate=T2400_8 'for VSM
#else
symbol baudRate=N2400_8 'for physical chip
#endif


symbol pinForDisplay=C.0




#ifdef forVSM

#rem
VSM needs 150 milliseconds (in my configuration) before it can write to the LCD/OLED. 
This is only needed if writing at the very start of the program, 
so if your LCD/OLED write happens at least 150 msecs after program starts
then you won't need this
You can try a shorter pause (eg 120) - in my case I only got the end of the string displayed


#endrem
pause 150
#endif


serout pinForDisplay,baudRate,(254,1) 'clear screen
pause 30 'give screen clear time to execute


serout pinForDisplay,baudRate,(254,128) 'go to start of line 1
serout pinForDisplay,baudRate,("0123456789abcdef")


serout pinForDisplay,baudRate,(254,192) 'go to start of line 2
serout pinForDisplay,baudRate,("fedcba9876543210")

Timer and settimer

There's a lot of detail on settimer in the manual, but I still struggled how to reset the timer. In fact it is blindlingly obvious:

timer=0

timer is just a word variable, which gets incremented when a second (hidden) "minor tick" variable overflows. The preload value in settimer specifies what value the "minor tick" counter moves to once it has hit 65535: the higher the preload value, the fewer increments needed, and so the sooner the "minor tick" overflows and increments timer.

The pitfall is that wheras the first settimer command will set the timer to zero, any subsequent settimer commands will change the rate at which the timer increments, but will NOT reset the timer