Async Serial from "sensors" I use has always been an issue for me parsing with Tachyon. Lines come in with " " " and "," and " " and LF and CR/LF delimiters around AT style control words. Anything that helps us create "dispatch" words to handle this IO is greatly appreciated. And documentation/examples for the new words in Tachyon is also greatly welcome. Still grinding through the Tachyon intro for V3 updates.
I will have to see exactly what is going on here ... but it looks very cool.
Peter, what does TF do when a cog is running in the background and a new bit of source code is downloaded that affects that cog? Should I explicitly STOP the cog first? I am starting to see strange behaviour, and coupled with my troubles using PropellerIDE (inconsistent transfers of the kernel) I am getting messed up. Sometimes it looks like the whole system is bricked. It sometimes responds to a ?BACKUP with the word FAIL followed by a counter of some sort and the spinning symbol. I see the EXTEND code that triggers this, but not sure why the EEPROM would be failing the ack unless it is colliding with a background cog running I2C ... I thought that collisions were avoided in the I2C codes.
When you BACKUP the state of the "machine" is saved including running cogs. I've had various issues running multiple cogs and I2C. What I do is use different I2C pins for each cog. If you look at the code in EXTEND.fth the "?I2C" word tests for a busy bus, this is not foolproof for concurrent cogs accessing the same pins hence why I use separate pins for each cog. Also some devices just don't play well on the same bus no matter what the datasheets say!
Bricked or strange behavior is a symptom of something having gone bad in the stack, I know this well. Peter showed this trick for stack debugging to at least make you get DEADBEEF in and out of you routines and overall system.
pub !!SP !SP $DEADBEEF ; --- Init the datastack but leave a $DEADBEEF marker on it for stack debug
At the end of your system/word running check to make sure $DEADBEEF is the only thing left.
Yes, I often put a sequence of 1 2 3 4 5 on the stack then watch it go. Works well.
When you use multiple I2C buses do you set the I2C pins back to the EEPROM defaults after using them? I have an analog I/O board that has 2 I2C buses because the chips are fixed addresses (need two boards on the project), and I did this for safety. Not sure if needed.
I will have to see exactly what is going on here ... but it looks very cool.
Peter, what does TF do when a cog is running in the background and a new bit of source code is downloaded that affects that cog? Should I explicitly STOP the cog first? I am starting to see strange behaviour, and coupled with my troubles using PropellerIDE (inconsistent transfers of the kernel) I am getting messed up. Sometimes it looks like the whole system is bricked. It sometimes responds to a ?BACKUP with the word FAIL followed by a counter of some sort and the spinning symbol. I see the EXTEND code that triggers this, but not sure why the EEPROM would be failing the ack unless it is colliding with a background cog running I2C ... I thought that collisions were avoided in the I2C codes.
While we can download new code with an app running and then get it to run that, we can't replace running code, we need to stop the app and then restart it. There's also some caveats with running BACKUP and that usually requires that an app isn't running. Why? Because it may have initialized certain variables and cogs and the app may not always start up properly unless we are careful in our initialization. For instance, I have the "boot" variable which is loaded with a random number on every boot so that an app can tell if it has been restarted by comparing a copy of the last boot value with the current one, but only if the app explicitly does this.
Recommended backup procedure is to do so with everything stopped, so I normally disable autostart, perhaps even with a ^A after a reset to abort the autostart. Then I load the new code followed by BACKUP.
While doing some work on a datalogger I decided to mount one of those Nokia 5110 LCDs as well and so I have added that code to the Tachyon extras folder. Although you can specify new pins very simply at runtime I have elected to share the clock and data with the I2C lines so that I only need D/C and CE although I do have a method that generates the D/C signal from the data line through a resistor using RC charge hold so that in reality if you use the I2C lines then you only need a CE but I will tidy up this mode later. The reset is tied to the Prop reset to simplify it even further.
Although I have a 5x7 font table I have also allowed for 32 programmable characters rather than trimming and offsetting the table. Perhaps I will add some simple graphics and scaled fonts too, much as I do with VGA. The driver is of course driven as a simple revectorable output device so that LCD $0C EMIT PRINT" HELLO WORLD" CR will produce the desired effect as you would expect on any terminal.
While doing some work on a datalogger I decided to mount one of those Nokia 5110 LCDs as well and so I have added that code to the Tachyon extras folder. Although you can specify new pins very simply at runtime I have elected to share the clock and data with the I2C lines so that I only need D/C and CE although I do have a method that generates the D/C signal from the data line through a resistor using RC charge hold so that in reality if you use the I2C lines then you only need a CE but I will tidy up this mode later. The reset is tied to the Prop reset to simplify it even further.
Although I have a 5x7 font table I have also allowed for 32 programmable characters rather than trimming and offsetting the table. Perhaps I will add some simple graphics and scaled fonts too, much as I do with VGA. The driver is of course driven as a simple revectorable output device so that LCD $0C EMIT PRINT" HELLO WORLD" CR will produce the desired effect as you would expect on any terminal.
great, thanks - I am sure I have a few of those in the box
Here's the LCD mounted with a Prop and keypad etc. BTW, I wanted a connector on the keypad but I didn't want it sitting high off the board so I used a right-angle pin on the keypad and slide it horizontally into a right angle socket (bent one of my stacker sockets) so it can be unplugged but won't just fall off and it's low-profile.
Hi there,
I was tired of setting the newline delay in minicom manually so this patched version of the amd64 debian minicom-2.7 package came to life to load the nl_delay parameter from the config file.
In the tgz you'll find the deb and a small documentation.
my efforts to build a tachyon image via Makefile are so far successful as they can.
Making a complete build for the IoT5500 is now made like this:
make iot5500
The generated build looks like this:
/usr/local/bin/bstc.linux -p 2 "./Tachyon V3.0 JUNO.spin"
Found a USB Serial Device
Brads Spin Tool Compiler v0.15.3 - Copyright 2008,2009 All rights reserved
Compiled for i386 Linux at 08:17:46 on 2009/07/20
Loading Object Tachyon V3.0 JUNO
Program size is 32656 longs
Compiled 4181 Lines of Code in 0.144 Seconds
We found a Propeller Version 1
Propeller Load took 11.466 Seconds
sleep 6
ascii-xfr -s -l 20 EXTEND.FTH > /dev/ttyUSB0
ASCII upload of "EXTEND.FTH"
Line delay: 20 ms, character delay 0 ms
sleep 6
ascii-xfr -s -l 20 ./more/hardware_headers/P8.FTH > /dev/ttyUSB0
ASCII upload of "./more/hardware_headers/P8.FTH"
Line delay: 20 ms, character delay 0 ms
sleep 6
ascii-xfr -s -l 20 EASYFILE.FTH > /dev/ttyUSB0
ASCII upload of "EASYFILE.FTH"
Line delay: 20 ms, character delay 0 ms
sleep 6
echo "COMPACT" > /dev/ttyUSB0
sleep 35
echo "BACKUP" > /dev/ttyUSB0
sleep 10
ascii-xfr -s -l 20 EASYNET.FTH > /dev/ttyUSB0
ASCII upload of "EASYNET.FTH"
Line delay: 20 ms, character delay 0 ms
sleep 6
The build process lasts
make iot5500 0.33s user 0.34s system 0% cpu 3:55.67 total
without any manual interventions. Currently there are still a lot of sleeps that should be removed, but the build is now safely working.
There is one thing braking me a little bit: you are using whitespace in file names, this is one of the few things Makefiles are not able to handle correctly. If you'd remove them I could share the Makefile here.
@D.P. Have you tried setting the delimiter to a comma? See AVAR in EXTEND for an example of this. That way your message would come back as
+CMTI: "SM" 7
to which I would define "SM" perhaps as a constant and +CMTI: as a deferred execution word so that at the end of the line it will execute its deferred word with two parameters, the constant for "SM" and location 7.
+CMTI: pushes a vector onto a deferred execution stack and your ATCOMS word which is automatically executed before the next line with ' ATCOMS prompt W! can read that stack and call the vector, nice and simple.
EDIT: coming to think of it I have a substitution table for the control keys built into JUNO so I think if I extended it for all 128 codes it could simply substitute a space for a comma etc. Along with deferred execution this is another solution. Even the " codes could be replaced with a space.
I was to replace the comma via the AVAR example but I'm just not sure how I would read my async buffer into ukey and setup the defer execution of the +CMTI: word? This is the magic guts of revectoring ukey that I haven't explored.
FONA.fth is using a task to RX from the module into a 256 byte circular buffer so I should use this task to also do the processing of the buffer contents via it's ukey?
I've just added KEYPAD.FTH for scanning small 4x4 or 4x3 keypads using the background timer (no extra cogs).
The encoder scans, debounces, encodes, and buffers the keys while timing an optional piezo buzzer.
You can even change the encoder table at runtime by treating the keycodes table as a string like this:
" 147*2580369#ABCD" keycodes $! ok
keycodes QD
0000_3F38: 31 34 37 2A 32 35 38 30 33 36 39 23 41 42 43 44 147*2580369#ABCD
0000_3F48: 00 BA 3F 03 7D 2B 7D C1 48 8C BA 3F 03 7D C1 48 ..?.}+}.H..?.}.H ok
keycodes PRINT$ 147*2580369#ABCD ok
To change the group of pins that the keypad is connected to just overwrite the constant:
#P16 ' *keypad 1+ !
Same with the piezo using *beep but if you want to disable it just set it to >31.
I've got PropellerIDE to send the kernel over again ... probably a glitch unrelated to the board etc. Then sent over EXTEND.fth.
The last line of the EXTEND load seems odd, and the stack has 2 longs that seem to be a new behaviour. Manual BACKUP seemed to go fine. When I reset the board the stack is clear, but it detects no ROMS, which is OK because I don't use them yet, but I thought it reported several previously.
Am I screwing something up here? My only tweak to EXTEND was to enable PBASIC Serial IO, but that was long ago.
2704 EXTEND.bootILD DATE 160804:180000 BOOTS: 0 runtime 0230
18:00:00 End of source code, 2705 lines processed and 0000 errors found
Load time = 0.000us
MODULES LOADED:
1800: EXTEND.fth Primary extensions to TACHYON kernel - 160828-1400
VER: Propeller .:.:--TACHYON--:.:. Forth V3.0 JUNO 300160819.2230
PCB: UNKNOWN (0)
FREQ: 80MHZ (PLLEN OSCEN XTAL1 PLL16X)
NAMES: $5ABD...74DC for 6,687 bytes (+4,046)
CODE: $0930...3879 for 12,105 bytes (+8,313)
RAM: 8,772 bytes free
BUILD: FIRMWARE BUILD DATE 160804:180000 BOOTS: 0 runtime 0
BOOT: EXTEND.boot ok
ok
ok
?BACKUP DATE@ build.date E! TIME@ build.time E! ok ************************* seems odd ************************
ok
ok
ok
ok
BACKUP ok
ok
.s Data Stack (2) *************************************************************** seems odd ************************
$0007.1E99 - 466585
$0007.1E99 - 466585 ok
Propeller .:.:--TACHYON--:.:. Forth V3.0 JUNO 300160819.2230
VER: Propeller .:.:--TACHYON--:.:. Forth V3.0 JUNO 300160819.2230
PCB: UNKNOWN (0)
FREQ: 80MHZ (PLLEN OSCEN XTAL1 PLL16X)
NAMES: $5ABD...74DC for 6,687 bytes (+4,046)
CODE: $0930...3879 for 12,105 bytes (+8,313)
RAM: 8,772 bytes free
BUILD: FIRMWARE BUILD DATE 160804:180000 BOOTS: 0 runtime 38
BOOT: EXTEND.boot
MODULES LOADED:
1800: EXTEND.fth Primary extensions to TACHYON kernel - 160828-1400
NO ROMS ********************************************************************** seems odd *******************************
----------------------------------------------------------------
ok
.s Data Stack (0) ok
I think I may have stumbled onto a small problem with variable/code alignment. I am running TF Forth V3.0 JUNO 300160819.2230
In the section of code shown here, I can run the SET_C, SET_COURSE routines from console with no problems. Once I launch 4 cogs to do background work, then running SET_C from the console resets the TF interpreter, I get the screen of status info, and I am back running. The next routine SET_COURSE works always, but as you can see, it is identical code. SET_C also fails when called from within a cog. The problem seems to be only in the first code definition immediately after the myNum$ definition.
12 LONGS PID1 --- response based on error between desired and actual course; 12 is found as PIDsize in code to follow
12 LONGS PID2 --- response based on rolling of boat measured by gyro
15 BYTES myNUM$
-75 Deviation !
pub SET_C ( course -- )
36000 + 3600 MOD Course ! ;
pub SET_COURSE ( course -- ) --- ensures course is between 0 and 3600 in tenths of degree
36000 + 3600 MOD Course ! ;
When I change the definition of myNum$ to be 16 bytes instead of 15, it always works, SET_C and SET_COURSE have the same behaviour regardless of the background cog execution. They work from within a cog.
12 LONGS PID1 --- response based on error between desired and actual course; 12 is found as PIDsize in code to follow
12 LONGS PID2 --- response based on rolling of boat measured by gyro
16 BYTES myNUM$
-75 Deviation !
pub SET_C ( course -- )
36000 + 3600 MOD Course ! ;
pub SET_COURSE ( course -- ) --- ensures course is between 0 and 3600 in tenths of degree
36000 + 3600 MOD Course ! ;
BTW ... I have no idea why I tried 15 in the first version ...
Cheers!
I think I may have stumbled onto a small problem with variable/code alignment. I am running TF Forth V3.0 JUNO 300160819.2230
In the section of code shown here, I can run the SET_C, SET_COURSE routines from console with no problems. Once I launch 4 cogs to do background work, then running SET_C from the console resets the TF interpreter, I get the screen of status info, and I am back running. The next routine SET_COURSE works always, but as you can see, it is identical code. SET_C also fails when called from within a cog. The problem seems to be only in the first code definition immediately after the myNum$ definition.
12 LONGS PID1 --- response based on error between desired and actual course; 12 is found as PIDsize in code to follow
12 LONGS PID2 --- response based on rolling of boat measured by gyro
15 BYTES myNUM$
-75 Deviation !
pub SET_C ( course -- )
36000 + 3600 MOD Course ! ;
pub SET_COURSE ( course -- ) --- ensures course is between 0 and 3600 in tenths of degree
36000 + 3600 MOD Course ! ;
When I change the definition of myNum$ to be 16 bytes instead of 15, it always works, SET_C and SET_COURSE have the same behaviour regardless of the background cog execution. They work from within a cog.
BTW ... I have no idea why I tried 15 in the first version ...
Cheers!
Where the data area of myNUM$ ends the start of SET_C begins so if you write a string it must be less than 15 bytes long as all strings must have a null terminator. So trying to write a 15-byte string will end up writing a null to the first code byte in SET_C, thus corrupting it with a "reset" bytecode.
I've got PropellerIDE to send the kernel over again ... probably a glitch unrelated to the board etc. Then sent over EXTEND.fth.
The last line of the EXTEND load seems odd, and the stack has 2 longs that seem to be a new behaviour. Manual BACKUP seemed to go fine. When I reset the board the stack is clear, but it detects no ROMS, which is OK because I don't use them yet, but I thought it reported several previously.
Am I screwing something up here? My only tweak to EXTEND was to enable PBASIC Serial IO, but that was long ago.
The ROMs are moved from hub RAM near the end of EXTEND when SAVEROMS is executed (then forgotten) but only if an EEPROM larger than 32k is detected.
During the course of loading EXTEND it also detects the type of RTC using SELRTC (which is also forgotten) and uses that timestamp for the build info.
will end up writing a null to the first code byte in SET_C, thus corrupting it with a "reset" bytecode.
Well it is pretty obvious when you put it that way!
So is ERASE$ an unusual string routine, in that it checks the length of the buffer from the header?
Thanks Peter!
ERASE$ has a bug in that the 3 - should now be 2- although I can see that this scheme is a bit obsolete and needs to have something better to mark the end of string space after a terminator. Perhaps I will just create strings with $FF after the terminator so that a " HELLO WORLD" would have this appearance:
Why not just use the max length information from the header information?
As it turns out my current app uses $F0-$FF within strings being send out and received from devices. For the same reason you want to use them ... they don't look like normal ASCII ..
Cheers!
Why not just use the max length information from the header information?
As it turns out my current app uses $F0-$FF within strings being send out and received from devices. For the same reason you want to use them ... they don't look like normal ASCII ..
Cheers!
Strings are just data structures, they might not have a header associated with them so we can't depend upon that mechanism. Maybe I just have to put the maximum length before the structure....
btw, an $FF or any character with the 8th bit set will serve as a terminator in addition to nulls.
Cluso99 sent me a couple of P8XBlade2s to play with and they look really good although I haven't used them yet but he did include one of those 128x128 color LCD modules which I interfaced as a regular output device in Tachyon. I've just got the basic 5x7 font driver in there for the moment but I will probably include font scaling and alternative fonts as well as graphics commands.
I'm only using the 4 wire I/O at present but I will see if it is possible to tell it to use the 3-wire mode.
My console session while testing the display.
!lcd ok
blue to bg ok
white to fg ok
LCD .VER CON ok
white to bg ok
red to fg ok
LCD .VER CON ok
white to fg ok
blue to bg ok
ok
ok
LCD $0C EMIT lsroms CON ok
red green + to fg ok
LCD .S CON ok
0 to bg ok
LCD .VER CON ok
blue green + to fg LCD .VER CON ok
red blue + to fg LCD .VER CON ok
To fill a window you can specify X Y Width and Height independently:
64 W 64 H 32 X 32 Y blue fillWindow ok
38 X red fillWindow ok
Nice work Peter. These LCDs are nice and cheap ~US$2.70+
I am using an 8*8 font which gives 16*16 chars/lines. A 5*7 font gives 21*16 chars/lines.
I power the LCD from prop pins, so I just plug the LCD into P0..P7.
I haven't really tried 3 pin mode. Software reset works so there is no need for this pin. I set CS=0 at the start, so this shouldn't matter either. So this just leaves CLK, D/C, SDA.
I've just added font scaling too. I noticed that the CE doesn't need to be brought high again but if there is ever a glitch then the whole SPI transfer may become out of synch. I'm sharing clk and data with the I2C bus so if I can use 3-pin mode with these display which the controller chip itself supports then it is effectively only one pin.
terminal session
5 5 *XY LCD 1234 . CON ok
1 1 *XY yellow to fg ok
LCD .VER CON ok
blue to fg ok
2 2 *XY LCD PRINT" HELLO WORLD" CON ok
Nice work Peter. These LCDs are nice and cheap ~US$2.70+
I am using an 8*8 font which gives 16*16 chars/lines. A 5*7 font gives 21*16 chars/lines.
I power the LCD from prop pins, so I just plug the LCD into P0..P7.
I haven't really tried 3 pin mode. Software reset works so there is no need for this pin. I set CS=0 at the start, so this shouldn't matter either. So this just leaves CLK, D/C, SDA.
Nice work Peter. These LCDs are nice and cheap ~US$2.70+
I am using an 8*8 font which gives 16*16 chars/lines. A 5*7 font gives 21*16 chars/lines.
I power the LCD from prop pins, so I just plug the LCD into P0..P7.
I haven't really tried 3 pin mode. Software reset works so there is no need for this pin. I set CS=0 at the start, so this shouldn't matter either. So this just leaves CLK, D/C, SDA.
Are you selling these?
No. I bought a few a while back on eBay. Just noticed a few days ago that they are on AliExpress for $2.70+ including shipping. Cost me more than that for just postage
Last night I posted an update to my LCD driver that breaks the code into an object and demo files. I added rotation 0/90/180/270 degrees as well as the offsety=32 for the red pcbs. The PASM driver runs in its own cog which.includes the 8*8 128 char font.
Can you post your 5*7 (6*8) font please as it will save me making one
Comments
Async Serial from "sensors" I use has always been an issue for me parsing with Tachyon. Lines come in with " " " and "," and " " and LF and CR/LF delimiters around AT style control words. Anything that helps us create "dispatch" words to handle this IO is greatly appreciated. And documentation/examples for the new words in Tachyon is also greatly welcome. Still grinding through the Tachyon intro for V3 updates.
Peter, what does TF do when a cog is running in the background and a new bit of source code is downloaded that affects that cog? Should I explicitly STOP the cog first? I am starting to see strange behaviour, and coupled with my troubles using PropellerIDE (inconsistent transfers of the kernel) I am getting messed up. Sometimes it looks like the whole system is bricked. It sometimes responds to a ?BACKUP with the word FAIL followed by a counter of some sort and the spinning symbol. I see the EXTEND code that triggers this, but not sure why the EEPROM would be failing the ack unless it is colliding with a background cog running I2C ... I thought that collisions were avoided in the I2C codes.
When you BACKUP the state of the "machine" is saved including running cogs. I've had various issues running multiple cogs and I2C. What I do is use different I2C pins for each cog. If you look at the code in EXTEND.fth the "?I2C" word tests for a busy bus, this is not foolproof for concurrent cogs accessing the same pins hence why I use separate pins for each cog. Also some devices just don't play well on the same bus no matter what the datasheets say!
Bricked or strange behavior is a symptom of something having gone bad in the stack, I know this well. Peter showed this trick for stack debugging to at least make you get DEADBEEF in and out of you routines and overall system.
At the end of your system/word running check to make sure $DEADBEEF is the only thing left.
When you use multiple I2C buses do you set the I2C pins back to the EEPROM defaults after using them? I have an analog I/O board that has 2 I2C buses because the chips are fixed addresses (need two boards on the project), and I did this for safety. Not sure if needed.
While we can download new code with an app running and then get it to run that, we can't replace running code, we need to stop the app and then restart it. There's also some caveats with running BACKUP and that usually requires that an app isn't running. Why? Because it may have initialized certain variables and cogs and the app may not always start up properly unless we are careful in our initialization. For instance, I have the "boot" variable which is loaded with a random number on every boot so that an app can tell if it has been restarted by comparing a copy of the last boot value with the current one, but only if the app explicitly does this.
Recommended backup procedure is to do so with everything stopped, so I normally disable autostart, perhaps even with a ^A after a reset to abort the autostart. Then I load the new code followed by BACKUP.
Although I have a 5x7 font table I have also allowed for 32 programmable characters rather than trimming and offsetting the table. Perhaps I will add some simple graphics and scaled fonts too, much as I do with VGA. The driver is of course driven as a simple revectorable output device so that LCD $0C EMIT PRINT" HELLO WORLD" CR will produce the desired effect as you would expect on any terminal.
great, thanks - I am sure I have a few of those in the box
I was tired of setting the newline delay in minicom manually so this patched version of the amd64 debian minicom-2.7 package came to life to load the nl_delay parameter from the config file.
In the tgz you'll find the deb and a small documentation.
Best regards,
proplem
my efforts to build a tachyon image via Makefile are so far successful as they can.
Making a complete build for the IoT5500 is now made like this:
The generated build looks like this:
The build process lasts
without any manual interventions. Currently there are still a lot of sleeps that should be removed, but the build is now safely working.
There is one thing braking me a little bit: you are using whitespace in file names, this is one of the few things Makefiles are not able to handle correctly. If you'd remove them I could share the Makefile here.
Regards,
proplem
I was to replace the comma via the AVAR example but I'm just not sure how I would read my async buffer into ukey and setup the defer execution of the +CMTI: word? This is the magic guts of revectoring ukey that I haven't explored.
FONA.fth is using a task to RX from the module into a 256 byte circular buffer so I should use this task to also do the processing of the buffer contents via it's ukey?
The encoder scans, debounces, encodes, and buffers the keys while timing an optional piezo buzzer.
You can even change the encoder table at runtime by treating the keycodes table as a string like this:
To change the group of pins that the keypad is connected to just overwrite the constant:
Same with the piezo using *beep but if you want to disable it just set it to >31.
The last line of the EXTEND load seems odd, and the stack has 2 longs that seem to be a new behaviour. Manual BACKUP seemed to go fine. When I reset the board the stack is clear, but it detects no ROMS, which is OK because I don't use them yet, but I thought it reported several previously.
Am I screwing something up here? My only tweak to EXTEND was to enable PBASIC Serial IO, but that was long ago.
In the section of code shown here, I can run the SET_C, SET_COURSE routines from console with no problems. Once I launch 4 cogs to do background work, then running SET_C from the console resets the TF interpreter, I get the screen of status info, and I am back running. The next routine SET_COURSE works always, but as you can see, it is identical code. SET_C also fails when called from within a cog. The problem seems to be only in the first code definition immediately after the myNum$ definition.
When I change the definition of myNum$ to be 16 bytes instead of 15, it always works, SET_C and SET_COURSE have the same behaviour regardless of the background cog execution. They work from within a cog. BTW ... I have no idea why I tried 15 in the first version ...
Cheers!
Where the data area of myNUM$ ends the start of SET_C begins so if you write a string it must be less than 15 bytes long as all strings must have a null terminator. So trying to write a 15-byte string will end up writing a null to the first code byte in SET_C, thus corrupting it with a "reset" bytecode.
The ROMs are moved from hub RAM near the end of EXTEND when SAVEROMS is executed (then forgotten) but only if an EEPROM larger than 32k is detected.
During the course of loading EXTEND it also detects the type of RTC using SELRTC (which is also forgotten) and uses that timestamp for the build info.
So is ERASE$ an unusual string routine, in that it checks the length of the buffer from the header?
Thanks Peter!
As it turns out my current app uses $F0-$FF within strings being send out and received from devices. For the same reason you want to use them ... they don't look like normal ASCII ..
Cheers!
Strings are just data structures, they might not have a header associated with them so we can't depend upon that mechanism. Maybe I just have to put the maximum length before the structure....
btw, an $FF or any character with the 8th bit set will serve as a terminator in addition to nulls.
Thanks Peter!
I'm only using the 4 wire I/O at present but I will see if it is possible to tell it to use the 3-wire mode.
My console session while testing the display.
To fill a window you can specify X Y Width and Height independently:
I am using an 8*8 font which gives 16*16 chars/lines. A 5*7 font gives 21*16 chars/lines.
I power the LCD from prop pins, so I just plug the LCD into P0..P7.
I haven't really tried 3 pin mode. Software reset works so there is no need for this pin. I set CS=0 at the start, so this shouldn't matter either. So this just leaves CLK, D/C, SDA.
terminal session
The pixels around the right and bottom edges are possibly because you haven't set the window to 0,0,127,127 for clearing.
Yeah, I decided to fix that immediately after the last post, it was just due to some changes so now I set them to 128,128
Can you post your 5*7 (6*8) font please as it will save me making one