20X2 I2C slave missing bytes.

[NXTreme]

I'm trying to use a 20X2 as an I2C slave to a Mindstorms NXT. I have a Sirf III GPS attached to the Picaxe, which reads the time into six bytes, puts them in the scratchpad and sends them to the computer. I'm hoping to get the the Picaxe and GPS to act as a super accurate RTC. I also have a pin on the Picaxe attached to pin 1 on the NXT with a 2.2K resistor to simulate a touch sensor. Since the Picaxe spends quite a bit of time waiting for data from the GPS, I have it signal the NXT when new data is available by pulling the pin low, and returning it to an input or high-Z state when it is hanging on the serin command.

However, it's not working . I tested it out with a single byte first, a value from a LDR. It would read onto the NXT screen just fine. However, when I switched over to the GPS, the NXT would lose the connection with the Picaxe after the first read and stop displaying any values. By restarting the whole setup, I could get it to work again. Just restarting the Picaxe or NXT wouldn't have any effect (I think I used the right one, right Dippy? Or should it be affect... ).
So, I attached a potentiometer to the Picaxe as well and tried just reading the LDR and pot. Still no luck. So, I tried the single byte program again, no luck! Somehow something got messed up...

So, it would seem as if reading values into the NXT by way of Picaxe doesn't work for me. Mattallen37 has had luck reading multiple ADC values into the Picaxe and passing them onto the NXT but I didn't have any luck even when I tried his programs. Technical also said that he had success using a Picaxe 20X2 as a NXT slave.

The code below reads one byte and makes it available to the NXT in the scratchpad. This code worked in the beginning, but not anymore.

#no_table 'no need to extend download times...
pullup %10100000 'activate internal pullups to minimize part count...
hi2csetup i2cslave,80 'setup as I2C slave
	
main:	readadc B.6,b0 'read LDR
	put 0,b0 'put LDR value in scratchpad
	sertxd (#b0,CR,LF) 'send it to computer
	low B.0
	pause 800
	input B.0
	goto main

This code below is supposed to read the time from a GPS into the scratchpad. It outputs the time just fine to the computer, but the NXT doesn't read it properly, it just displays zeros.

#no_table
pullup %10100000
hi2csetup i2cslave,80

main:	serin C.7,T4800_8,("GGA,"),b0,b1,b2,b3,b4,b5
	let b0=53
	put 0,b0,b1,b2,b3,b4,b5
	sertxd (b0,b1,b2,b3,b4,b5,CR,LF)
	low B.0
	pause 600
	input B.0
	pause 10
	goto main

Can anyone confirm if I'm doing something wrong on the Picaxe side of things? I think I could debug my NXT program, but my understanding of the scratchpad and all associated commands is still a bit weak. I attached a screenshot of the program running on the NXT.

 

[John West]

I think I can confirm that it is indeed "effect" in this case, as you are referring to the word as a "thing," a noun, but that's about it. For help with the real difficulty you describe, you will need to get it from the forum "Big Guns," and that's way above my pay-grade.

 

[Milos]

I do not know anything about NXT. But, is the address - 80 - a decimal number in both cases (NXT and PICAXE)? Your slave address on PICAXE is 80 = $50.

 

[westaust55]

You could also have a read at this thread, particularly later posts):
http://www.picaxeforum.co.uk/showthread.php?t=17307&highlight=lego

Believe it is the one I have a recollection of where Techncial from Rev Ed gave some details and that there is some quirk in the Lego NXT i2c comms.

 

[hippy]

So, I attached a potentiometer to the Picaxe as well and tried just reading the LDR and pot. Still no luck. So, I tried the single byte program again, no luck! Somehow something got messed up...

I would suggest the first thing is to determine why what worked no longer works, what's causing that, without getting that working it seems pointless to try and get anything more complicated working.

It may be worth / necessary going right back to basics, getting the NXT to read a single pre-stored value from the PICAXE to prove that works. You may have to try with another NXT if that won't work to see if the NXT has been damaged during experimentation.

When things stop working it's normally necessary to back-up, see where it starts working and move forward again. If you back-up to a point where it was working but not now then something is different to last time and you need to work out what; code, wiring, voltages, damage.

So, it would seem as if reading values into the NXT by way of Picaxe doesn't work for me.

More accurately; it did work but is no longer working.

 

[NXTreme]

I think I can confirm that it is indeed "effect" in this case, as you are referring to the word as a "thing," a noun, but that's about it.

Thanks!

I do not know anything about NXT. But, is the address - 80 - a decimal number in both cases (NXT and PICAXE)? Your slave address on PICAXE is 80 = $50.

Yes, it is a decimal 80 in both cases. I've made the mistake before, so that was one of the first things I checked. Something about learning from your mistakes...

You could also have a read at this thread, particularly later posts):
http://www.picaxeforum.co.uk/showthread.php?t=17307&highlight=lego

Believe it is the one I have a recollection of where Techncial from Rev Ed gave some details and that there is some quirk in the Lego NXT i2c comms.

Yes! That is the post I was talking about. Thanks! One thing that could be a problem is that the Picaxe 20x2 I'm using has V. C.0 firmware. I bought it from SparkFun just a couple months ago, so they must have had old stock lying around. Mattallen37 probably used a Picaxe with newer firmare...

I would suggest the first thing is to determine why what worked no longer works, what's causing that, without getting that working it seems pointless to try and get anything more complicated working.

It may be worth / necessary going right back to basics, getting the NXT to read a single pre-stored value from the PICAXE to prove that works. You may have to try with another NXT if that won't work to see if the NXT has been damaged during experimentation.

When things stop working it's normally necessary to back-up, see where it starts working and move forward again. If you back-up to a point where it was working but not now then something is different to last time and you need to work out what; code, wiring, voltages, damage.

Yes, good point. I guess I was mainly asking if my Picaxe programs looked fine, especially since I haven't done much with the scratchpad yet. I should order a couple more 20X2 chips, to try inter-Picaxe I2C comms first, then move on to more difficult projects, like this one.

More accurately; it did work but is no longer working.

Thanks for all the help!

 

[brw3sbc]

I've very limited experience, but I am wondering: I see in the code that the 20X2 is being set up as an I2C slave - which would mean that it is generally on the receiving end of I2C commands. I2C commands arrive, and the hardware places the received instruction/data into the scratchpad, setting a flag to allow the on-board programming to know of and thus act upon the new command/data. Yet, another part of the program is using that same scratchpad space for another purpose. Perhaps it might be better to store the LDR reading (or GPS data, or whatever) in storage variable memory (using Poke and Peek).

 

[NXTreme]

I'm actually trying to read the Picaxe with the NXT, so the reason I'm sticking the values into the scratchpad is so that they can be read externally (by the NXT).

 

[brw3sbc]

I could well leave this for more experienced contributors, but the questions that come to my mind are: How does the NXT read the 20X2 scratchpad? What instruction does the NXT issue? Over what channel? I2C? And where does that instruction go? How does the 20X2 know what to do with this 'command?' It is my understanding that when a 20X2 is in I2C slave mode, incoming data goes into the scratchpad sequentially, and a program in the 20x2 has to read that data and deal with it. I do not believe that another processor, as 'master,' has direct access to reading any of the 'slave' PICAXE internals. The master can 'write' to the 'picaxe as slave,' but it's up to the slave to deal with it. An I2C EEPROM has an internal program that responds to read and write requests,but you would have to write such a program to run in the 20x2 serving as an i2c slave. I could be wrong on this. We shall see what others offer.

 

[NXTreme]

I suggest taking a look at manual 2, at the "hi2csetup - slave mode" command. To quote the manual, "An i2c master can read or write to the slave PICAXE chip as if it was a 128 (X1, 20X2) or 256 (X2) byte 24LCxx series EEPROM, with the scratchpad area acting as the memory transfer area."

I had some luck with getting the NXT to read a single byte again, however that luck was somewhat limited. It would read anywhere from one to ~20 times successfully, then stop reading correctly. Then, to top it all off, my programming cable stopped working. I tracked it down to a faulty USB cable that wouldn't make a connection properly. With a slight tap I could make the computer play the "recognize/un-recognize" sound in quick succession. This leads me to believe that the cable connecting and disconnecting quickly might make the Picaxe lock up, waiting for a new download or something. I will keep testing, eliminating all the unnecessary parts 'till I find out exactly what is causing problems. (Yes Hippy, I hear you say "Get an AXE027 or we shall tar and feather you!" )

Thanks again to all for the help!

 

[brw3sbc]

Yes, don't you love a manual that says that something can be done without an explanation of how? Anyway, after more research, I concede that a master should be able to read a 'PICAXE-in-I2C-slave-mode' scratchpad. Might I suggest that you try a higher scratchpad address for your specific application?

 

[NXTreme]

Yes, there are a few spots in the manuals that could probably use a few changes to make things clearer. However, I find the Picaxe manuals are the most complete of almost any manuals out there, be it for the laptop I use, my Garmin eTrex and even some car manuals! And yes, you may suggest that, although I'm not sure what the results might be. I'm still doing some testing, but when I figure something out, I'll be sure to post it.

 

[Technical]

A simple readadc into the scratchpad should work fine with the PICAXE as a Lego slave, so something is not quite right with the setup.

However the main issue here in your more complex program is likely to be a conflict between i2c and serial (serin /sertxd in your program) timing.

It's one of those unavoidable clashes in this case. The PICAXE chip cannot respond to an i2c request from the master (the NXT brick) whilst doing a serin. This is because the i2c request requires the processor time, but serin also requires the processor time to maintain accurate timing (to ensure the serin data is not corrupt as it is read). There is no control over when the NXT does the i2c read, and so at point there will be a clash when the PICAXE is expected to do both at the same time - and can't. In that case the serin will win and the i2c read will fail. So really serin/i2c slave mode together will never works 100% - see the conflicting commands section of the manual for more details.

Howver i2c slave with non timing critical commands (e.g. reading inputs etc) with an NXT should work fine.

 

[NXTreme]

Yes, the hang time when using serin is a problem. I (think I) overcame this by setting up the Picaxe to look like a touch sensor. I just wait in a loop until the 'touch sensor' is pressed, which signals the NXT that the Picaxe is no longer waiting for serin, then I read the scratchpad with the NXT. Another thought that crossed my mind is that if the NXT sets a certain port to work with the touch sensor, it may not work at times with other sensors (or the Picaxe). However, I'm not sure about this. I hope I explained it well enough, as it is rather hard to understand. Thanks!