Custom LCD controller using I2C/Serial

[drjeseuss]

I'm working on a custom LCD controller and having some trouble figuring out the best way to get all working. My design goals are:

- Standalone controller taking input from another picaxe
- Selectable I2C or serial input from "master" picaxe
- Ability to connect up to 3 LCDs, each up to 2x40 or 4x20
- Typical abilities of an LCD controller

As for the design, I have managed to get 3 LCDs all controlled by a single picaxe using the 8 outputs. I have used standard wiring for the first LCD. Then on the second two, all is the same except I have their 'E' pins connected to outs 0 and 1. My test code was able to initialize each and send commands and data to each properly by pulsing E1, E2, or E3.

My struggles are in the rest of the project. For example, how would I enable it to accept data from I2C or serial? I know roughly how to do each, but I'm not sure about how to make it 'discover' which is connected and being used. Should this be a jumper setting and if so, how might the code look without duplicating it for each method?

My next trouble is the actual 'listening' mode. How would I have the controller listen for data, then execute, then listen again? Would I simply serrxd, check for null, then loop. Once data is seen (not null) send those bytes to LCD, then loop? If so, once data is seen and I begin to send the byte(s) to LCD, will additional data cache, be lost, or what? For example, if the 'master' sends "Hello" will the controller get "H" and begin or "Hello" then begin? If just "H" what happens to "ello"? And how does the controller know when to stop listening and begin execute?

Aside from the multi-LCD output, the remainder seems to be standard for LCD controllers so I'm guessing it's not that out of reach, though it's a larger project than I've tackled before and covers a few subjects I haven't learned fully yet. Any help would be great!

 

[Dippy]

I've never done I2C slave on PICAXE, but if you are using an X2 for asynch serial can't you make use of the background receive? Then test the string that has come in with a quick parse.

 

[hippy]

Dippy's on the right track IMO; enable as I2C Slave and enable Hardware Serial background receive.

Either 'hserflag' or 'hi2cflag' will be set whenever one of the two receives data. Wait to see which gets set first, then remember that as the source, and enter your 'From I2C' or 'From Serial' data handler.

 

[drjeseuss]

Thanks hippy and Dippy for the above suggestions. I'll whip something up to see how far I can get. I think I understand enough to at least get comms going for the hi2c and hser, using hserptr or hi2clast to determine incoming string length. Once I get that done, I'll move into parsing to LCD output, then it should be downhill from there (I hope).

 

[drjeseuss]

I'm working my way into setting up the hser and hi2c background recievers. I have a few questions about this.

hser:
- Manual 2 p.76
"Upon the hsersetup command the serial pointer (hserptr) is reset to 0."
Is hserptr = ptr? Or are they seperate pointers? Can i use hserptr = 0 to reset to byte 0 for next recieve?

"When a byte is received...the hserinflag flag is set." Does this occur at the beginning of a rec., immediately after first byte rec., or after last byte rec.? Is there a sure way of discovering when the last byte is rec.? I was thinking of checking hserptr until it stops increasing. Is this the best way to know?

"hserinflag = 1 indicates a byte has been received" Is hserinflag = flag5? If one is reset, does the other mirror this reset?

hi2c:
- Manual 2 p.60
"An i2c master can read or write to the slave PICAXE chip as if it was a...24LCxx series EEPROM, with the scratchpad area acting as the memory transfer area." I assume the master device would control where it stores the bytes unlike hser which stores in the hserptr location.

"...when the master writes to the slave PICAXE memory the ‘hi2cflag’ is set..." before or after data rec.? After 1 byte, or final byte? Is hi2cflag = flag6. Resetting one does both?

"...and the last address written to is saved in the ‘hi2clast’ variable." Check until stops increasing as with hser?

 

[hippy]

Is hserptr = ptr? Or are they seperate pointers?

Separate. 'ptr' is completely under your program's control.

Can i use hserptr = 0 to reset to byte 0 for next recieve?

Yes.

"When a byte is received...the hserinflag flag is set." Does this occur at the beginning of a rec., immediately after first byte rec., or after last byte rec.?

Set whenever any byte is received, so notionally the first, then the next after hserinflag has been cleared.

Is there a sure way of discovering when the last byte is rec.? I was thinking of checking hserptr until it stops increasing. Is this the best way to know?

It's the only way possible I can think of if you don't know how much data you will be receiving in advance. If 'hserptr' hasn't increased or 'hserflag' not been set for a certain time then you can use that to indicate the transmission has ended, all data has been received.

Is hserinflag = flag5? If one is reset, does the other mirror this reset?

Yes, they're just two different aliases for the same flag bit.

hi2c: I assume the master device would control where it stores the bytes unlike hser which stores in the hserptr location.

Yes, it's the address used in WRITEI2C etc which indicates where it will be placed in slave.

"...when the master writes to the slave PICAXE memory the ‘hi2cflag’ is set..." before or after data rec.? After 1 byte, or final byte?

I believe on every byte written but will have to check that.

Is hi2cflag = flag6. Resetting one does both?

Yes, just two aliases for the same bit.

"...and the last address written to is saved in the ‘hi2clast’ variable." Check until stops increasing as with hser?

I'd say so, though you may be able to use "hi2cflag" depending on when it is set. If sending over multiple WRITEI2C etc commands you'd likely have to check hi2clast had stopped changing.

 

[hwholmes]

I've just been wrestling with some of the same questions.
The master does control where the data lands in the scratchpad.
If the messages were all the same length then you would only have to know if the pointer equaled the correct length.
If the messages are of various lengths, you might have the master send the length in the first byte and use that to check.
If using ASCII you could have the master terminate with CR LF or EOT etc and you could check the bytes just below the pointer for this code.
If you want the master to wait 'till you process the data, you can hand shake by setting a flagbyte at an agreed upon location in the scratchpad where the master can read it. It could then reverse the flag when finished to let you know the message is complete.

My concern is I am sending full byte data 0-255 so no codes are illegal, probably fixed length, but I am concerned about noise so I am considering checksum validation.

Hope this might spark some other ideas.
Bert