I've just downloaded the latest compiler software. I've also been reading the data sheets on the 20x2 and I'm as happy as a pig in mud. I've also realised I'm suddenly on the steep part of the picaxe learning curve again.
I'm wondering if these newer chips might be able to do strings. eg, in MBASIC:
This is a trivial example, and it is a little more complex than it seems, certainly for smaller picaxes. But the 20x2 has a lot more possibilities.
First is memory. When a program has A$="Hello", the software in the background is allocating some space for A$, as well as filling it with bytes. In MBASIC the strings are dynamic to save memory space, so that might save only 5 bytes with a pointer table where the bytes are stored. But every now and then you have to resort the table and remove any unused strings. Another method is to allocate a fixed number of bytes, eg 32, for each string and terminate the string with ascii 0.
Memory can be cheap, eg this http://www.futurlec.com/Memory/23K256.shtml is a 32k SPI ram chip for only $1.35 (kilobytes too, not kilobits!) It doesn't wear out (unlike eeprom). I wonder if anyone has used serial ram?
First thing that leaps out from the datasheet is the 3V supply, but the 20x2 is 3.3V too so maybe there is a case for migrating designs to 3.3V? All the maths for analog input/outputs might need to change...
Anyway, that was one idea, but then I noticed the 20x2 has 1024 scratchpad ram bytes. Hmm - that is 32 strings of 32 bytes each (or more if strings are compressed with lookup tables). 32 strings may be more than many programs need, especially if some strings are 'working' strings, and some are data strings that are stored in eeprom.
For example, you might print out a message on a LCD display and that would come from eeprom strings. Then you might ask the user to type something on a keyboard, and the prompt string would also come from eeprom as it is read only. But the keyboard input might get stored in a ram string, and then manipulated (eg making it all caps).
So, maybe no external ram is needed? Maybe no external eeprom either as the program size is a lot bigger
Ok, how would strings work?
I'm thinking a simple little subroutine, where you pass b0 with the number of the string (0-31) and it works out the address (multiply by 32) and then does a GET on the 32 bytes and fills b1 to b32. Oh, I do like the idea of more than 14 b registers!
Ditto save a string, but in reverse.
Now we could start looking at string routines.
LEFT()
MID()
RIGHT()
INSTR()
UCASE()
LCASE()
STR()
HEX()
VAL()
Some of these already exist but with different syntax, eg Bintoascii is the same as STR(). Just put an ascii 0 at the end as the string terminator.
And some are not that hard to write. I've written all the above in Z80 assembly and it should not be hard to translate eg Left:
Some functions are implied in MBASIC but have to be explicitly written, eg
A$=B$
would need to be instead a gosub
b0=3
b1=6
gosub copystring ' copies string in b0 to string in b1
So, a question to the picaxe gurus - is this on the right track? Are there simpler ways of doing things?
Can a keyboard be connected to a 20x2? If so, one can consider a subroutine that reads keyboard input and puts it into a string and continues until the user hits 'Enter'.
I've got all sorts of other ideas. I have had these ideas for some time, indeed I tried putting a lot of this into an 18X but it ran out of code space. But I think the newer chips may well open up a lot more possibilities, especially if there were libraries of generic routines that you could drop into a program.
I'm wondering if these newer chips might be able to do strings. eg, in MBASIC:
Code:
A$="Hello "
B$="World"
C$=A$+B$
D=5
E$=STR$(D)
F$=A$+B$+E$
PRINT F$
Hello World 5
First is memory. When a program has A$="Hello", the software in the background is allocating some space for A$, as well as filling it with bytes. In MBASIC the strings are dynamic to save memory space, so that might save only 5 bytes with a pointer table where the bytes are stored. But every now and then you have to resort the table and remove any unused strings. Another method is to allocate a fixed number of bytes, eg 32, for each string and terminate the string with ascii 0.
Memory can be cheap, eg this http://www.futurlec.com/Memory/23K256.shtml is a 32k SPI ram chip for only $1.35 (kilobytes too, not kilobits!) It doesn't wear out (unlike eeprom). I wonder if anyone has used serial ram?
First thing that leaps out from the datasheet is the 3V supply, but the 20x2 is 3.3V too so maybe there is a case for migrating designs to 3.3V? All the maths for analog input/outputs might need to change...
Anyway, that was one idea, but then I noticed the 20x2 has 1024 scratchpad ram bytes. Hmm - that is 32 strings of 32 bytes each (or more if strings are compressed with lookup tables). 32 strings may be more than many programs need, especially if some strings are 'working' strings, and some are data strings that are stored in eeprom.
For example, you might print out a message on a LCD display and that would come from eeprom strings. Then you might ask the user to type something on a keyboard, and the prompt string would also come from eeprom as it is read only. But the keyboard input might get stored in a ram string, and then manipulated (eg making it all caps).
So, maybe no external ram is needed? Maybe no external eeprom either as the program size is a lot bigger
Ok, how would strings work?
I'm thinking a simple little subroutine, where you pass b0 with the number of the string (0-31) and it works out the address (multiply by 32) and then does a GET on the 32 bytes and fills b1 to b32. Oh, I do like the idea of more than 14 b registers!
Ditto save a string, but in reverse.
Now we could start looking at string routines.
LEFT()
MID()
RIGHT()
INSTR()
UCASE()
LCASE()
STR()
HEX()
VAL()
Some of these already exist but with different syntax, eg Bintoascii is the same as STR(). Just put an ascii 0 at the end as the string terminator.
And some are not that hard to write. I've written all the above in Z80 assembly and it should not be hard to translate eg Left:
Code:
STRINGS_LEFT: ; check string de, returns string in hl, number of bytes in B
PUSH HL
STRINGS_LEFT_1:
LD A,(DE) ; GET CHARACTER
LD (HL),A ; MOVE IT
INC HL ; HL+1
INC DE ; DE+1
DJNZ STRINGS_LEFT_1 ; LOOP UNTIL B=0
LD A,0 ; 0 AT THE END OF THIS SHORTER STRING
LD (HL),A
POP HL ; RESTORE START
RET
A$=B$
would need to be instead a gosub
b0=3
b1=6
gosub copystring ' copies string in b0 to string in b1
So, a question to the picaxe gurus - is this on the right track? Are there simpler ways of doing things?
Can a keyboard be connected to a 20x2? If so, one can consider a subroutine that reads keyboard input and puts it into a string and continues until the user hits 'Enter'.
I've got all sorts of other ideas. I have had these ideas for some time, indeed I tried putting a lot of this into an 18X but it ran out of code space. But I think the newer chips may well open up a lot more possibilities, especially if there were libraries of generic routines that you could drop into a program.
Last edited: