With the addition of the EECOPY command Tachyon has some interesting abilities to store and reload alternate configurations.
Its not a simple matter of copying the 32K of RAM to EEPROM ... Peter's masterful use/reuse of RAM means, unfortunately that key items in setup have come and gone by the time the terminal console is handed to the user!
BUT WAIT! Don't despair! Peter has another trick, BACKUP. Didn't you ever wonder why bACKUP has so much to it ... it does because it has to assemble the pieces to look like they came in s neat package from the compiler.
The following examples are based on an improved version of the Propeller Platform Through-Hole board I am working on. It has two AT24C1024B EEPROMs yielding 256 KBytes addressed $0 to $3FFFF. The first 32K, as usual belongs to the current boot image.
So load up you favorite kernal spinfile, apply your extensions and custom tools. Several lBACKUPs later you are ready to rock and roll ... BUT WAIT!!! Let's buy some insurance ... type in ...
$0 $38000 $8000 EECOPY
Copy, starting at $0 the 32K boot image and store it in the top of the EEPROM array. Now to work creating. Sooner or later you need to put it all on the line and BACKUP merging development code with new code ... test it out, does it work? YES, save it
$0 $30000 $8000 EECOPY
... or NO, it doesn't, time to start over, recover the original development configuration ...
$38000 $0 $8000 EECOPY REBOOT
It beats the heck out of multiply redoing 2-5 lengthy Copy/Pastes.
I just did a test run of loading in EXTEND.fth, I have a fairly fast PC, and I was very surprised that it took some fifteen minutes (approx) to cut and paste it into Tera Term, sure glad he has BACKUP. At the end of the cut and paste, it showed that there was one error ( I had a 60ms delay), I failed to write the error down, so now I am not sure at what point that will show up. There must be a better way, or at least a faster way.
I went ahead and ran the MULTITASKING example, now it ran successfully. The obvious question is, how do you stop the event(s), is this where REBOOT or COLD comes in?
Since I am using a QuickStart board for this, I wonder if the next test should be, being able to use the touch buttons to light up the LEDs, anybody have any ideas as to how that would be done?
I just did a test run of loading in EXTEND.fth, I have a fairly fast PC, and I was very surprised that it took some fifteen minutes (approx) to cut and paste it into Tera Term, sure glad he has BACKUP. At the end of the cut and paste, it showed that there was one error ( I had a 60ms delay), I failed to write the error down, so now I am not sure at what point that will show up. There must be a better way, or at least a faster way.
I went ahead and ran the MULTITASKING example, now it ran successfully. The obvious question is, how do you stop the event(s), is this where REBOOT or COLD comes in?
Since I am using a QuickStart board for this, I wonder if the next test should be, being able to use the touch buttons to light up the LEDs, anybody have any ideas as to how that would be done?
Ray
Likely you didn't have an actually error during the copy/paste. I am running a 2.5 GHz quad core I5 iMac with ZTerm and 80 Msec line wait and about one in 10 copy/paste actions hiccup.15 minutes is all wrong. Are you sure you didn't set a character wait too?
The answers to your multi-Task questions are in Message #241 of this thread.
Since I am using a QuickStart board for this, I wonder if the next test should be, being able to use the touch buttons to light up the LEDs, anybody have any ideas as to how that would be done?
Here is caskaz's quickstart demo in propforth, this should be similar
I just did a test run of loading in EXTEND.fth, I have a fairly fast PC, and I was very surprised that it took some fifteen minutes (approx) to cut and paste it into Tera Term, sure glad he has BACKUP. At the end of the cut and paste, it showed that there was one error ( I had a 60ms delay), I failed to write the error down, so now I am not sure at what point that will show up. There must be a better way, or at least a faster way.
I went ahead and ran the MULTITASKING example, now it ran successfully. The obvious question is, how do you stop the event(s), is this where REBOOT or COLD comes in?
Since I am using a QuickStart board for this, I wonder if the next test should be, being able to use the touch buttons to light up the LEDs, anybody have any ideas as to how that would be done?
Ray
There is a faster way! That was supposed to be a 60ms line delay, that is it only waits after each end of line. I timed the load and it took 36 seconds and this is the output:
End of source code, there were 0 errors found
CODE @$3627 - bytes used in this load = 1511
NAMES @$2021 - bytes used in this load = 751
YCALLS @ 243 entries free
ok
''
A ... EEPROM ... 9600d BAUD ok
.LAP 36,113,223us ok
?BACKUP ok
It might be a good idea for me to include the time to load in the STATS report as I did manually in this example.
If you have a look back at some of the other posts you will see your questions answered. Essentially we don't have any direct control over a cog in any language, we can stop it or we can reload it, that's all. Also the only reason we normally would want to stop the cog itself it is because we are testing so it is just as easy to reboot (<ctrl> C or break etc). The other way is to place something in your software that can look at a hub command and decide what to do. Have a look at post #241.
EDIT: Looks like Brian answered this a bit already
FWIW - here's my numbers for essentially the same file - 37+ SECONDS - it may even have been faster than Peter ... but i had set it to 133ms and had not put it back to 65 ms.
END
End of source code, there were 0 errors found
CODE @$3D4F - bytes used in this load = 1512
NAMES @$1D3A - bytes used in this load = 751
YCALLS @ 140 entries free
ok
''
A ... EEPROM ... 19200d BAUD ok
ok
CR .LAP CR
37,610,922us
ok
?BACKUP ok
.Thanks. The EECOPY word, as you suggested, will prove very useful in working with Tachyon.
I have been trying out the sdcard word set. Executing SD with all my cards only results in a card error message, apparently due
to a timeout error. Have you eXperienced any problems with this word set?
.Thanks. The EECOPY word, as you suggested, will prove very useful in working with Tachyon.
I have been trying out the sdcard word set. Executing SD with all my cards only results in a card error message, apparently due
to a timeout error. Have you eXperienced any problems with this word set?
NickL.
Hi Nick, there are some cards that aren't working but I've been stretched here and there but I fully intend to sort out what's going on. Having all the primitives required at your fingertips make it very easy to test as you can just issue CMDs and ACMDs etc on the fly and look at the results. Once I do that then I will introduce the virtual memory and file system layers on top of that.
The Dropbox files are not the bleeding edge files as you need to look at the Google docs versions for that. But when I'm happy with a version I then update it. In this case I think it just didn't get updated perhaps but I've done that now.
Yes, I started having a look at it and just seeing if I could convince the counters to work together without dedicating a cog for this. Well you can and Tracy Allen did some work on using 2 counters with an external XOR gate or 3 counters otherwise you need to dedicate a cog to it so that's what I will do. So as soon as I get a few minutes when I'm not on the forum or documenting what I've done, reviewing and testing changes and requests, scratching myself etc I will check it out and try it on some of my 8A H-bridge modules just to make sure
Ditto with the CASE structure although I have my own ideas on that. Did you check out the simpler indexed LOOKUP structure?
I discovered my error with the cut/paste procedure. In Tera Term, Serial port setup, it has a Transmit delay section, I put the 60ms in msec/char, where it should of been 60ms in msec/line. Now that I got that corrected, the cut/paste session goes a lot quicker.
Since I am using the QuickStart board, I was playing around with the code below. After you get the code running, the LED is flashing, I type in STOPCOG4, which stops the LED. Then I STARTBLINK4, and the LED starts up again, the problem is, when I STOPCOG4, and then STARTBLINK4, again, nothing happens. It is if STARTBLINK4 is no longer functioning, so I have to do a ' BLINKY >PFA 4 RUN to get it going again. I thought that once you created a new WORD, it is valid until you reboot or do a COLD? Is there something that I missed?
Ray
#16 MASK CONSTANT .RDY
: BLINKY 50d BEGIN .RDY OUTSET DUP ms .RDY OUTCLR DUP ms ATN? DUP 1 > IF NIP DUP THEN 1 = UNTIL ;
' BLINKY >PFA 4 RUN
: STOPCOG4 1 4 RUN ;
: STARTBLINK4 ' BLINKY >PFA 4 RUN ;
I discovered my error with the cut/paste procedure. In Tera Term, Serial port setup, it has a Transmit delay section, I put the 60ms in msec/char, where it should of been 60ms in msec/line. Now that I got that corrected, the cut/paste session goes a lot quicker.
Since I am using the QuickStart board, I was playing around with the code below. After you get the code running, the LED is flashing, I type in STOPCOG4, which stops the LED. Then I STARTBLINK4, and the LED starts up again, the problem is, when I STOPCOG4, and then STARTBLINK4, again, nothing happens. It is if STARTBLINK4 is no longer functioning, so I have to do a ' BLINKY >PFA 4 RUN to get it going again. I thought that once you created a new WORD, it is valid until you reboot or do a COLD? Is there something that I missed?
Ray
#16 MASK CONSTANT .RDY
: BLINKY 50d BEGIN .RDY OUTSET DUP ms .RDY OUTCLR DUP ms ATN? DUP 1 > IF NIP DUP THEN 1 = UNTIL ;
' BLINKY >PFA 4 RUN
: STOPCOG4 1 4 RUN ;
: STARTBLINK4 ' BLINKY >PFA 4 RUN ;
Because Tachyon compiles word by word it isn't possible (at present anyway) to do certain things the way that they are normally done in conventional Forth which has it's own limitations. The tick word is immediate and as of yet I have not put in any compensations so that if you try to put it in a definition it will of course execute immediately as you would expect it to but the address is on the stack but not compiled as it needs to be. That's why in my examples I create a constant first and then use it like this from your example:
I was playing with the ANSI VT100 words.
There is some strange thing in the source.
The definition of pri CUR is not finished.
I marked with an arrow
Please can you take a look?
TACHYON
\ **** ANSI VT100 terminal support
pri ESC ( ch -- ) $1B EMIT EMIT ;
pri ESCB ( ch -- ) "[" ESC EMIT ;
pri ESCH ( ch -- ) "#" ESC EMIT ;
pri CUR ( cmd n -- ) "[" ESC SWAP <=
pri .PAR SWAP #10 .NUM EMIT ;
pub XY ( x y -- ) ";" SWAP CUR "H" .PAR ;
pub HOME "H" ESCB ;
pub ERSCN "2" ESCB "J" EMIT ;
pub ERLINE "2" ESCB "K" EMIT ;
pub CLS HOME ERSCN ;
pub CURSOR ( on/off -- ) "?" ESCB ." 25" IF "h" ELSE "l" THEN EMIT ;
I have tried Kingston 2 GB micro SD cards and they work fine. I bought 10 SanDisk 2 GB micro SD cards and the first two I have tried generate "Card error" .... suggestions for further investigation ???
I was playing with the ANSI VT100 words.
There is some strange thing in the source.
The definition of pri CUR is not finished.
I marked with an arrow
Please can you take a look?
<snip>
pri CUR ( cmd n -- ) "[" ESC SWAP <=
pri .PAR SWAP #10 .NUM EMIT ;
pub XY ( x y -- ) ";" SWAP CUR "H" .PAR ;
<snip>
This is deliberate as CUR's final act is to call .PAR but that's silly to call it when you can "fall-through" into it which is possible in Tachyon Forth. Normally this is not possible in any Forth that I know of as each word normally has a header and even if it didn't it would still have a CFA. TF keeps the headers completely separate and there is no real CFA as such, as it's all interpreted as Tachyon bytecode instructions which are executed by the Tachyon VM cog. The header does not even point to the code but it does have the one or two bytecodes necessary that represent the call or the instructions for the word. The address is actually in the XCALL vector table which is indexed with a single byte. In this case the header for CUR looks like this:
I have tried Kingston 2 GB micro SD cards and they work fine. I bought 10 SanDisk 2 GB micro SD cards and the first two I have tried generate "Card error" .... suggestions for further investigation ???
Is it possible to implement the case structure in TACHYON?
Sorry to butt in to a question addressed to Peter-
CASE is always possible, but tends to be very cumbersome and expensive from a forth dictionary perspective. Usually it is implemented on PC environments where there is tons of memory that needs to be wasted.
Tachyon is very fast and small. CASE doesn't feel like Tachyon.
Could you describe what you want to do? Usually there is a nice way to accomplish what case does, but faster using less memory, etc.
More on SanDisk 2 GB microSD .. I got out one of my PropBOE boards loaded with Mike Green's PropBOEBasic and the SanDisk was read and written to by Mike's routines.
I'm just playing with this right at the moment and I have isolated the "bad" cards and I am now getting them to read. Looks like it's an initialization thing so I will continue to check them out and post an update soon.
More on SanDisk 2 GB microSD .. I got out one of my PropBOE boards loaded with Mike Green's PropBOEBasic and the SanDisk was read and written to by Mike's routines.
I've updated the Google and Dropbox files so have a look at it now. I've tested this out on at least 1/2 dozen different cards or more from 1GB to 8GB in various brands etc. It's also setup to do the automatic polling so it will report the card's stats as soon as you insert it. That's probably all I will do for tonight (here) but I know I have more testing to do as I have some Eye-Fi cards here that didn't respond although I haven't really looked into it yet. The initialization is fairly basic and I will do some more checks
SDCARD.fth has just been upgraded to allow SD pins to be defined or changed on the fly. You can specify an individual pin change only or even all 4 pins as a long. I've got boards with 2 or more SD card slots so this is convenient for me. Here's the output from my test board with a 4GB microSD and an 8GB SD:
Hi Brian,
The P11xx numbers are actual PCB model numbers so that I could just enter the appropriate name You can remove these from your copy of the source code but they are useful to me. So you would just name yours as PLATFORM or something unique enough to identify it with the board and pinout. The curly comments are just the alternative way of defining the pins as you have guessed whereas the SDPINS version is more efficient.
Even though I could probably do some more work on testing other cards I can do that later on and as for now it would be good to introduce the other layers, first virtual memory, then FAT16 (yuck), then FAT32 (yuck). However it's really good to work with files as virtual memory as you can directly access any part of the file that you want so I will probably demonstrate some applications using this as well. Certainly a text editor and at least a character based text display would be a good app to demonstrate this plus it is a big step towards being totally self-hosted.
NOTE: This thread has now passed the 10,000 views mark a couple of hours ago!
Here's a quick little update that I may expand upon as I was converting some Spin code and thought, hey wait, I can leave this part as it is, I'll just tweak the compiler to process it. When you enter variables in spin you can have them separated by commas so that's what I did also. The only other change was using LONG,WORD,BYTE always in uppercase as I like to leave lowercase to denote variables and constants etc rather than code which in in uppercase or CamelCase at least.
In Spin or Tachyon variables are entered like this:
LONG faddr,flen,flen2,cold
WORD c2cmd,c2dat
BYTE chip,c2code
The reason I changed it was because.....
Before I get going on the full SD software I've been sidetracked by some software I wrote a couple of years ago to program a SILABS C8051F in-circuit using just the SDA line plus a dedicated C2CK/RST line. As some of you may know I use support micros in many of my designs rather than a dumb and more expensive chip. So rather than an MCP3208 for 12-bit ADC I use a SILABS micro that has everything including a faster ADC, voltage reference, temp sensor, a 25MIPS core, 0.5% internal oscillator and various bus interfaces including I2C. They cost a little bit more than many other "8-bit" micros but they are worth it and better and cheaper than a dumb chip. If you are interested I will be starting a project page for this family as well which will be linked at the bottom of the Intro page as usual. Writing code for the 8051 is trivial and plenty of tools are available although I will have precompiled modules available as well so it's easy peasy (super simple).
Comments
Its not a simple matter of copying the 32K of RAM to EEPROM ... Peter's masterful use/reuse of RAM means, unfortunately that key items in setup have come and gone by the time the terminal console is handed to the user!
BUT WAIT! Don't despair! Peter has another trick, BACKUP. Didn't you ever wonder why bACKUP has so much to it ... it does because it has to assemble the pieces to look like they came in s neat package from the compiler.
The following examples are based on an improved version of the Propeller Platform Through-Hole board I am working on. It has two AT24C1024B EEPROMs yielding 256 KBytes addressed $0 to $3FFFF. The first 32K, as usual belongs to the current boot image.
So load up you favorite kernal spinfile, apply your extensions and custom tools. Several lBACKUPs later you are ready to rock and roll ... BUT WAIT!!! Let's buy some insurance ... type in ...
Copy, starting at $0 the 32K boot image and store it in the top of the EEPROM array. Now to work creating. Sooner or later you need to put it all on the line and BACKUP merging development code with new code ... test it out, does it work? YES, save it
... or NO, it doesn't, time to start over, recover the original development configuration ...
It beats the heck out of multiply redoing 2-5 lengthy Copy/Pastes.
I went ahead and ran the MULTITASKING example, now it ran successfully. The obvious question is, how do you stop the event(s), is this where REBOOT or COLD comes in?
Since I am using a QuickStart board for this, I wonder if the next test should be, being able to use the touch buttons to light up the LEDs, anybody have any ideas as to how that would be done?
Ray
Likely you didn't have an actually error during the copy/paste. I am running a 2.5 GHz quad core I5 iMac with ZTerm and 80 Msec line wait and about one in 10 copy/paste actions hiccup.15 minutes is all wrong. Are you sure you didn't set a character wait too?
The answers to your multi-Task questions are in Message #241 of this thread.
Here is caskaz's quickstart demo in propforth, this should be similar
http://propforth.googlecode.com/files/QuickstartTouchDemo20120611-1540.txt
I thought somebody already ported this, but I can't find the link right now
There is a faster way! That was supposed to be a 60ms line delay, that is it only waits after each end of line. I timed the load and it took 36 seconds and this is the output: It might be a good idea for me to include the time to load in the STATS report as I did manually in this example.
If you have a look back at some of the other posts you will see your questions answered. Essentially we don't have any direct control over a cog in any language, we can stop it or we can reload it, that's all. Also the only reason we normally would want to stop the cog itself it is because we are testing so it is just as easy to reboot (<ctrl> C or break etc). The other way is to place something in your software that can look at a hub command and decide what to do. Have a look at post #241.
EDIT: Looks like Brian answered this a bit already
FWIW - here's my numbers for essentially the same file - 37+ SECONDS - it may even have been faster than Peter ... but i had set it to 133ms and had not put it back to 65 ms.
Where is EECOPY located? It doesn't appear in the QWORD list.
NickL
Its in recent (last three days) copied of EXTEND.fth
.Thanks. The EECOPY word, as you suggested, will prove very useful in working with Tachyon.
I have been trying out the sdcard word set. Executing SD with all my cards only results in a card error message, apparently due
to a timeout error. Have you eXperienced any problems with this word set?
NickL.
Hi Nick, there are some cards that aren't working but I've been stretched here and there but I fully intend to sort out what's going on. Having all the primitives required at your fingertips make it very easy to test as you can just issue CMDs and ACMDs etc on the fly and look at the results. Once I do that then I will introduce the virtual memory and file system layers on top of that.
Peter,
Plese can you take a look at my question about PWM with TACHYON
Thanks
Is it possible to implement the case structure in TACHYON?
Ditto with the CASE structure although I have my own ideas on that. Did you check out the simpler indexed LOOKUP structure?
Since I am using the QuickStart board, I was playing around with the code below. After you get the code running, the LED is flashing, I type in STOPCOG4, which stops the LED. Then I STARTBLINK4, and the LED starts up again, the problem is, when I STOPCOG4, and then STARTBLINK4, again, nothing happens. It is if STARTBLINK4 is no longer functioning, so I have to do a ' BLINKY >PFA 4 RUN to get it going again. I thought that once you created a new WORD, it is valid until you reboot or do a COLD? Is there something that I missed?
Ray
Because Tachyon compiles word by word it isn't possible (at present anyway) to do certain things the way that they are normally done in conventional Forth which has it's own limitations. The tick word is immediate and as of yet I have not put in any compensations so that if you try to put it in a definition it will of course execute immediately as you would expect it to but the address is on the stack but not compiled as it needs to be. That's why in my examples I create a constant first and then use it like this from your example:
I was playing with the ANSI VT100 words.
There is some strange thing in the source.
The definition of pri CUR is not finished.
I marked with an arrow
Please can you take a look?
TACHYON
\ **** ANSI VT100 terminal support
pri ESC ( ch -- ) $1B EMIT EMIT ;
pri ESCB ( ch -- ) "[" ESC EMIT ;
pri ESCH ( ch -- ) "#" ESC EMIT ;
pri CUR ( cmd n -- ) "[" ESC SWAP <=
pri .PAR SWAP #10 .NUM EMIT ;
pub XY ( x y -- ) ";" SWAP CUR "H" .PAR ;
pub HOME "H" ESCB ;
pub ERSCN "2" ESCB "J" EMIT ;
pub ERLINE "2" ESCB "K" EMIT ;
pub CLS HOME ERSCN ;
pub CURSOR ( on/off -- ) "?" ESCB ." 25" IF "h" ELSE "l" THEN EMIT ;
TACHYON FORTH permits you to leave out the ";" and 'run on' into the next definition. IN this case the word definition CUR is finished by .PAR
I have tried Kingston 2 GB micro SD cards and they work fine. I bought 10 SanDisk 2 GB micro SD cards and the first two I have tried generate "Card error" .... suggestions for further investigation ???
This is deliberate as CUR's final act is to call .PAR but that's silly to call it when you can "fall-through" into it which is possible in Tachyon Forth. Normally this is not possible in any Forth that I know of as each word normally has a header and even if it didn't it would still have a CFA. TF keeps the headers completely separate and there is no real CFA as such, as it's all interpreted as Tachyon bytecode instructions which are executed by the Tachyon VM cog. The header does not even point to the code but it does have the one or two bytecodes necessary that represent the call or the instructions for the word. The address is actually in the XCALL vector table which is indexed with a single byte. In this case the header for CUR looks like this:
[FONT=courier new][FONT=arial]CUR HEADER:[/FONT] 1FB3: 43 55 52 82 BD 24 [FONT=arial]CUR CODE:[/FONT] ' CUR >PFA 10 DUMP 37A0: 73 5B BD 1A 15 [COLOR=#808080]15 73 0A C0 DA C0 41 06 73 3B 15 s[....s....A.s;. [/COLOR][B]"[" ESC SWAP[/B] ok ' .PAR >PFA 10 DUMP 37A5: 15 73 0A C0 DA C0 41 06 [COLOR=#808080]73 3B 15 BD 24 73 48 BD .s....A.s;..$sH.[/COLOR] [B]SWAP #10 .NUM EMIT EXIT[/B] [/FONT]Sorry to butt in to a question addressed to Peter-
CASE is always possible, but tends to be very cumbersome and expensive from a forth dictionary perspective. Usually it is implemented on PC environments where there is tons of memory that needs to be wasted.
Tachyon is very fast and small. CASE doesn't feel like Tachyon.
Could you describe what you want to do? Usually there is a nice way to accomplish what case does, but faster using less memory, etc.
: P1146 '' PP-USB/uSD-PM #26 MASK OUTCLR '' P1146 PPC reset $01020003 SDPINS { #03 SDCS '' SD CS - Card chip select #01 SCK '' SD CLK - Card clock #02 MOSI '' SD DI - data in from Prop #00 MISO '' SD DO - data out to Prop } ;I couldn't, for the life of me, figure the scheme for naming the "P11xx" so I picked next in sequence.
The P11xx numbers are actual PCB model numbers so that I could just enter the appropriate name
Even though I could probably do some more work on testing other cards I can do that later on and as for now it would be good to introduce the other layers, first virtual memory, then FAT16 (yuck), then FAT32 (yuck). However it's really good to work with files as virtual memory as you can directly access any part of the file that you want so I will probably demonstrate some applications using this as well. Certainly a text editor and at least a character based text display would be a good app to demonstrate this plus it is a big step towards being totally self-hosted.
NOTE: This thread has now passed the 10,000 views mark a couple of hours ago!
In Spin or Tachyon variables are entered like this:
LONG faddr,flen,flen2,cold
WORD c2cmd,c2dat
BYTE chip,c2code
The reason I changed it was because.....
Before I get going on the full SD software I've been sidetracked by some software I wrote a couple of years ago to program a SILABS C8051F in-circuit using just the SDA line plus a dedicated C2CK/RST line. As some of you may know I use support micros in many of my designs rather than a dumb and more expensive chip. So rather than an MCP3208 for 12-bit ADC I use a SILABS micro that has everything including a faster ADC, voltage reference, temp sensor, a 25MIPS core, 0.5% internal oscillator and various bus interfaces including I2C. They cost a little bit more than many other "8-bit" micros but they are worth it and better and cheaper than a dumb chip. If you are interested I will be starting a project page for this family as well which will be linked at the bottom of the Intro page as usual. Writing code for the 8051 is trivial and plenty of tools are available although I will have precompiled modules available as well so it's easy peasy (super simple).