LOADROM AND SAVEROM excited me. They had so much potential .... 20 minutes, a few tweaks, and about an hour of testing and here we go. LOADROM/SAVEROM are located at the bottom of MULTIFILE.FTH. Just replace them withe code below and reload.
{
2013-12-06 - modified LOADROM/SAVEROM to allow multiple IMAGE files.
I cloned ROM.BIN four times, creating ROM0.BIN, ROM1.BIN, ROM2.BIN,
and ROM3.BIN.
LOADROM and SAVEROM, either invoked without stack parameters reads from or
or writes to the file ROM.BIN just as PBJ coded it.
But, clinb under the hood by invoking LOADIMG or SAVEIMG prefaced by the
quoted filename and you can load from or save to any 32768 byte file
already present on the SD Card. Examples.
LOADROM \ loads image from ROM.BIN to EEPROM
" ROM2.BIN" SAVEIMG \ saves RAM image to ROM2.BIN
SAVEROM \ saves RAM image to ROM.BIN
" ROM1.BIN" LOADIMG \ loads image from ROM1.BIN to EEPROM
BBR _ Underhill Center, VT 2013-12-06
}
pub SAVEROM ( -- )
" ROM.BIN"
pub SAVEIMG ( "filename$" -- )
1 FILE FOPEN$
IF
0 $8000 FIXCKSUM
." Saving to File "
0 FILE@ $8000
ADO
DUP BUFFERS $200 ELOAD $200 +
BUFFERS I 9 SHR SDWR DROP \ write one full sector
$200 +LOOP
DROP
THEN
;
pub LOADROM ( -- )
" ROM.BIN"
pub LOADIMG ( "filename$" -- )
FOPEN$ IF ." Loading ROM Image to EEPROM "
FILE@ 0 $7FE0 ADO DUP I + XADR I $40 ESAVE $40 +LOOP
DROP
THEN
;
{
2013-12-06 - modified LOADROM/SAVEROM to allow multiple IMAGE files.
I cloned ROM.BIN four times, creating ROM0.BIN, ROM1.BIN, ROM2.BIN,
and ROM3.BIN.
LOADROM and SAVEROM, either invoked without stack parameters reads from or
or writes to the file ROM.BIN just as PBJ coded it.
But, clinb under the hood by invoking LOADIMG or SAVEIMG prefaced by the
quoted filename and you can load from or save to any 32768 byte file
already present on the SD Card. Examples.
LOADROM \ loads image from ROM.BIN to EEPROM
" ROM2.BIN" SAVEIMG \ saves RAM image to ROM2.BIN
SAVEROM \ saves RAM image to ROM.BIN
" ROM1.BIN" LOADIMG \ loads image from ROM1.BIN to EEPROM
BBR _ Underhill Center, VT 2013-12-06
}
pub SAVEROM ( -- )
" ROM.BIN"
pub SAVEIMG ( "filename$" -- )
1 FILE FOPEN$
IF
0 $8000 FIXCKSUM
." Saving to File "
0 FILE@ $8000
ADO
DUP BUFFERS $200 ELOAD $200 +
BUFFERS I 9 SHR SDWR DROP \ write one full sector
$200 +LOOP
DROP
THEN
;
pub LOADROM ( -- )
" ROM.BIN"
pub LOADIMG ( "filename$" -- )
FOPEN$ IF ." Loading ROM Image to EEPROM "
FILE@ 0 $7FE0 ADO DUP I + XADR I $40 ESAVE $40 +LOOP
DROP
THEN
;
LOADROM AND SAVEROM excited me. They had so much potential .... 20 minutes, a few tweaks, and about an hour of testing and here we go. LOADROM/SAVEROM are located at the bottom of MULTIFILE.FTH. Just replace them withe code below and reload.
{
2013-12-06 - modified LOADROM/SAVEROM to allow multiple IMAGE files.
I cloned ROM.BIN four times, creating ROM0.BIN, ROM1.BIN, ROM2.BIN,
and ROM3.BIN.
LOADROM and SAVEROM, either invoked without stack parameters reads from or
or writes to the file ROM.BIN just as PBJ coded it.
But, clinb under the hood by invoking LOADIMG or SAVEIMG prefaced by the
quoted filename and you can load from or save to any 32768 byte file
already present on the SD Card. Examples.
LOADROM \ loads image from ROM.BIN to EEPROM
" ROM2.BIN" SAVEIMG \ saves RAM image to ROM2.BIN
SAVEROM \ saves RAM image to ROM.BIN
" ROM1.BIN" LOADIMG \ loads image from ROM1.BIN to EEPROM
BBR _ Underhill Center, VT 2013-12-06
}
pub SAVEROM ( -- )
" ROM.BIN"
pub SAVEIMG ( "filename$" -- )
1 FILE FOPEN$
IF
0 $8000 FIXCKSUM
." Saving to File "
0 FILE@ $8000
ADO
DUP BUFFERS $200 ELOAD $200 +
BUFFERS I 9 SHR SDWR DROP \ write one full sector
$200 +LOOP
DROP
THEN
;
pub LOADROM ( -- )
" ROM.BIN"
pub LOADIMG ( "filename$" -- )
FOPEN$ IF ." Loading ROM Image to EEPROM "
FILE@ 0 $7FE0 ADO DUP I + XADR I $40 ESAVE $40 +LOOP
DROP
THEN
;
{
2013-12-06 - modified LOADROM/SAVEROM to allow multiple IMAGE files.
I cloned ROM.BIN four times, creating ROM0.BIN, ROM1.BIN, ROM2.BIN,
and ROM3.BIN.
LOADROM and SAVEROM, either invoked without stack parameters reads from or
or writes to the file ROM.BIN just as PBJ coded it.
But, clinb under the hood by invoking LOADIMG or SAVEIMG prefaced by the
quoted filename and you can load from or save to any 32768 byte file
already present on the SD Card. Examples.
.
.
.
Nice work Brian, very cool, I can now change from Fully Automated Pressure Sterilizer ROM0.BIN to Full TCP/IP Server mode ROM1.BIN, althought with TF I can run everything at the same time still and Peter is still busy reclaiming more memory
LOADROM AND SAVEROM excited me. They had so much potential .... 20 minutes, a few tweaks, and about an hour of testing and here we go. LOADROM/SAVEROM are located at the bottom of MULTIFILE.FTH. Just replace them withe code below and reload.
{
2013-12-06 - modified LOADROM/SAVEROM to allow multiple IMAGE files.
I cloned ROM.BIN four times, creating ROM0.BIN, ROM1.BIN, ROM2.BIN,
and ROM3.BIN.
LOADROM and SAVEROM, either invoked without stack parameters reads from or
or writes to the file ROM.BIN just as PBJ coded it.
But, clinb under the hood by invoking LOADIMG or SAVEIMG prefaced by the
quoted filename and you can load from or save to any 32768 byte file
already present on the SD Card. Examples.
LOADROM \ loads image from ROM.BIN to EEPROM
" ROM2.BIN" SAVEIMG \ saves RAM image to ROM2.BIN
SAVEROM \ saves RAM image to ROM.BIN
" ROM1.BIN" LOADIMG \ loads image from ROM1.BIN to EEPROM
BBR _ Underhill Center, VT 2013-12-06
}
pub SAVEROM ( -- )
" ROM.BIN"
pub SAVEIMG ( "filename$" -- )
1 FILE FOPEN$
IF
0 $8000 FIXCKSUM
." Saving to File "
0 FILE@ $8000
ADO
DUP BUFFERS $200 ELOAD $200 +
BUFFERS I 9 SHR SDWR DROP \ write one full sector
$200 +LOOP
DROP
THEN
;
pub LOADROM ( -- )
" ROM.BIN"
pub LOADIMG ( "filename$" -- )
FOPEN$ IF ." Loading ROM Image to EEPROM "
FILE@ 0 $7FE0 ADO DUP I + XADR I $40 ESAVE $40 +LOOP
DROP
THEN
;
{
2013-12-06 - modified LOADROM/SAVEROM to allow multiple IMAGE files.
I cloned ROM.BIN four times, creating ROM0.BIN, ROM1.BIN, ROM2.BIN,
and ROM3.BIN.
LOADROM and SAVEROM, either invoked without stack parameters reads from or
or writes to the file ROM.BIN just as PBJ coded it.
But, clinb under the hood by invoking LOADIMG or SAVEIMG prefaced by the
quoted filename and you can load from or save to any 32768 byte file
already present on the SD Card. Examples.
LOADROM \ loads image from ROM.BIN to EEPROM
" ROM2.BIN" SAVEIMG \ saves RAM image to ROM2.BIN
SAVEROM \ saves RAM image to ROM.BIN
" ROM1.BIN" LOADIMG \ loads image from ROM1.BIN to EEPROM
BBR _ Underhill Center, VT 2013-12-06
}
pub SAVEROM ( -- )
" ROM.BIN"
pub SAVEIMG ( "filename$" -- )
1 FILE FOPEN$
IF
0 $8000 FIXCKSUM
." Saving to File "
0 FILE@ $8000
ADO
DUP BUFFERS $200 ELOAD $200 +
BUFFERS I 9 SHR SDWR DROP \ write one full sector
$200 +LOOP
DROP
THEN
;
pub LOADROM ( -- )
" ROM.BIN"
pub LOADIMG ( "filename$" -- )
FOPEN$ IF ." Loading ROM Image to EEPROM "
FILE@ 0 $7FE0 ADO DUP I + XADR I $40 ESAVE $40 +LOOP
DROP
THEN
;
Hi Brian, I wasn't intending to load multiple ROMs but there's no reason you can't so I have incorporated a slightly modified version of this using your SAVEIMG and LOADIMG names.
Oooopppss! Here we go again ... I had this problem last night, but being tired, I waited until I could grab some shuteye as well as grab a set of fresh files from the "Links" page. The .SPIN file was edited for pll16x/5_000_000. The .FTH-files were loaded "'as-is" in this order ... EXTEND, QS, SDCARD, MULTIFILE. Upon completion I typed SAVEROM and the board rebooted. I repeated the whole load procedure with the same result. I tried typing MOUNT before SAVEROM. It rebooted. I changed QS boards ... same drill .... I reloaded, first commenting out the RECLAIM at the end of MULTIFILE ... same results ----> REBOOT!
Obviously, SAVEROM/LOADROM need a MOUNTed SDcard... I rather suspect the problem is there.
...
Removing (NULLOUT)
Removing @ATR
Removing LEMIT
Reclaimed 728 bytes ok
END
0252
00:00:00 End of source code, 0253 lines processed and 0000 errors found
Load time = 20,451ms
NAMES: $59E8...73B4 for 6604 (0112 bytes added)
CODE: $0000...40EA for 10014 (2094 bytes added)
CALLS: 0328 vectors free
RAM: 6398 bytes free
ok
AUTORUN BOOT \
?BACKUP ok
ok
SAVEROM
Propeller .:.:--TACHYON--:.:. Forth V23131204.0300
NAMES: $59E8...73B4 for 6604 (0112 bytes added)
CODE: $0000...40EA for 10014 (2094 bytes added)
CALLS: 0328 vectors free
RAM: 6398 bytes free
AUTORUN BOOT
MODULES LOADED:
38BC: MULTIFILE.fth FAT32/16 MultiFile Layer V1.1 131207-0000
3181: SDCARD.fth SD CARD Toolkit - 131114.0000
2FDF: QuickStart.fth QuickStart + W5200 HARDWARE DEFINITIONS 131204.1200
17C0: EXTEND.fth Primary extensions to TACHYON kernel - 131124-0000
----------------------------------------------------------------
Oooopppss! Here we go again ... I had this problem last night, but being tired, I waited until I could grab some shuteye as well as grab a set of fresh files from the "Links" page. The .SPIN file was edited for pll16x/5_000_000. The .FTH-files were loaded "'as-is" in this order ... EXTEND, QS, SDCARD, MULTIFILE. Upon completion I typed SAVEROM and the board rebooted. I repeated the whole load procedure with the same result. I tried typing MOUNT before SAVEROM. It rebooted. I changed QS boards ... same drill .... I reloaded, first commenting out the RECLAIM at the end of MULTIFILE ... same results ----> REBOOT!
Obviously, SAVEROM/LOADROM need a MOUNTed SDcard... I rather suspect the problem is there.
...
Removing (NULLOUT)
Removing @ATR
Removing LEMIT
Reclaimed 728 bytes ok
END
0252
00:00:00 End of source code, 0253 lines processed and 0000 errors found
Load time = 20,451ms
NAMES: $59E8...73B4 for 6604 (0112 bytes added)
CODE: $0000...40EA for 10014 (2094 bytes added)
CALLS: 0328 vectors free
RAM: 6398 bytes free
ok
AUTORUN BOOT \
?BACKUP ok
ok
SAVEROM
Propeller .:.:--TACHYON--:.:. Forth V23131204.0300
NAMES: $59E8...73B4 for 6604 (0112 bytes added)
CODE: $0000...40EA for 10014 (2094 bytes added)
CALLS: 0328 vectors free
RAM: 6398 bytes free
AUTORUN BOOT
MODULES LOADED:
38BC: MULTIFILE.fth FAT32/16 MultiFile Layer V1.1 131207-0000
3181: SDCARD.fth SD CARD Toolkit - 131114.0000
2FDF: QuickStart.fth QuickStart + W5200 HARDWARE DEFINITIONS 131204.1200
17C0: EXTEND.fth Primary extensions to TACHYON kernel - 131124-0000
----------------------------------------------------------------
I was shuffling the kernel's memory around last night so if you used the bleeding edge web documents for source then that might have something to do with it. I'm checking it out now and making a few adjustments. If you do happen to use the bleeding edge source then it might be a good idea to keep a copy of the last files that proved stable just in case. If you do that you can also do a file compare to find out what's changed too if you are curious enough to want to know.
Oooopppss! Here we go again ... I had this problem last night, but being tired, I waited until I could grab some shuteye as well as grab a set of fresh files from the "Links" page. The .SPIN file was edited for pll16x/5_000_000. The .FTH-files were loaded "'as-is" in this order ... EXTEND, QS, SDCARD, MULTIFILE. Upon completion I typed SAVEROM and the board rebooted. I repeated the whole load procedure with the same result. I tried typing MOUNT before SAVEROM. It rebooted. I changed QS boards ... same drill .... I reloaded, first commenting out the RECLAIM at the end of MULTIFILE ... same results ----> REBOOT!
Obviously, SAVEROM/LOADROM need a MOUNTed SDcard... I rather suspect the problem is there.
Hi Brian, don't get mad at me but I think your problems may have resulted from a vector that failed to get initialized at compile time. I just ran into the problem now but I found that whenever CARD? was invoked that it crashed. This was traced back to the "ucard" vector which is normally 0 and not taken except in this case it had garbage in it. In recent versions when I create a variable it also inits it's storage to zero but "ucard" was moved over to the DS style variable, one that is basically a constant that points to the storage area, which was not being initialized. Now that it's specifically zeroed at compile time it now works.
Hi Brian, don't get mad at me but I think your problems may have resulted from a vector that failed to get initialized at compile time. I just ran into the problem now but I found that whenever CARD? was invoked that it crashed. This was traced back to the "ucard" vector which is normally 0 and not taken except in this case it had garbage in it. In recent versions when I create a variable it also inits it's storage to zero but "ucard" was moved over to the DS style variable, one that is basically a constant that points to the storage area, which was not being initialized. Now that it's specifically zeroed at compile time it now works.
Sorry about that
That was not an easy bug find Peter!
With all these [MODULES] we should be able to get a validation load for all new TACHYON builds. How can I help? I'm thinking the SD card could hold the results of valid operations that are tested. I used a similar "validation file" technique when I tested cross platform in-memory database engines .
With all these [MODULES] we should be able to get a validation load for all new TACHYON builds. How can I help? I'm thinking the SD card could hold the results of valid operations that are tested. I used a similar "validation file" technique when I tested cross platform in-memory database engines .
These bugs are few and far between and when you consider the almost interactive nature of the source code "release", in that it always released in that sense via Google docs and webdocs, then Dropbox , then I am very surprised that there are not more problems. When you are on the bleeding edge you expect to get cut!
However if I devoted too much time to validation testing I would get far less done and everyone would have to wait for a release, maybe only twice a year! The Tachyon project as it is, is a WIP, but a very usable one at that.
I noticed that my ISP is blocking port 80 so I am going to find out if I can get it unblocked. In the meantime ports 81 and 82 are forwarded to the Prop and still work fine. tachyonforth.com:81
My apologies if this is not the place to ask the following question:
While converting some C code (from an ARM) to PASM this morning, the need to create and then index 2D arrays got a little tedious. What is so simple to code in C was a chore in PASM. It made me wonder if it was time consider TF.
Acknowledging that there would be a steep learning curve, I simply want to know if at the end of the road there would be the sought-after payoff? Are 2D arrays convenient to create and index in Forth, and TF specifically?
Edit: The code and data arrays (smallish) would preferably reside in COG RAM.
My apologies if this is not the place to ask the following question:
While converting some C code (from an ARM) to PASM this morning, the need to create and then index 2D arrays got a little tedious. What is so simple to code in C was a chore in PASM. It made me wonder if it was time consider TF.
Acknowledging that there would be a steep learning curve, I simply want to know if at the end of the road there would be the sought-after payoff? Are 2D arrays convenient to create and index in Forth, and TF specifically?
Edit: The code and data arrays (smallish) would preferably reside in COG RAM.
I'm still new to Forth, and can't speak for Tachyon specifically, but Forth is a lower level language. You don't get data structures like arrays out of the box like you would with C, so in this regards it is similar to assembler. But the language is interactive and extensible, so you can implement arrays easier than you would in PASM. The extensions then become part of the language, so the language becomes easier to use as you add onto it.
The joke is that if Forth were a car it would arrive as a kit, you could build any car imaginable out of it, but it will drive backwards when it is done. Which raises the obvious question why did I bother to learn how to use it?
Everyone has their own reasons, but for me where Forth shines is that you build a domain specific language to solve your problem. This language can then be scripted via a serial command window. This is really useful for developing motion scripts for my robot arms.
The GOOD NEWS ... but, first, the BAD NEWS ... the bleeding edge code still suffers from REBOOT when dealing with MOUNT and its related commands. I did builds morning, afternoon, and evening pulling fresh source each new load attempt.
But, on a brighter note THE GOOD NEWS is that current DropBox package comes up clean ... Peter I have two small issues . ..
- You have MULTIFAT instead of MULTIFILE ... is that an OOOPPPSS or a change of heart?
- PLEASE, PLEASE, PLEASE ( this is me groveling!!! ;-] ) update the date code in the filename line so we easily tell what file revision we are dealing with. For example in the terminal output below, the date code is 131124, but CHANGELOG buried farther into the code is 131201 ... TNX
...
RECLAIM
...
Removing (rnd)
Removing @X
Removing (NULLOUT)
Removing @ATR
Removing LEMIT
Reclaimed 735 bytes ok
END
0321
00:01:08 End of source code, 0322 lines processed and 0000 errors found
Load time = 25,211ms
NAMES: $5AF5...74C3 for 6606 (0105 bytes added)
CODE: $0000...4176 for 10152 (2242 bytes added)
CALLS: 0327 vectors free
RAM: 6527 bytes free
ok
AUTORUN BOOT \
?BACKUP ok
ok
MOUNT Mounted SD Card
Media mounted as 3C18.8F1F TACHYON1 FAT32 Cluster size = 32,768 Sectors = 15,269,888 ok
" ROM0.BIN" SAVEIMG Saving EEPROM image to ROM0.BIN ok
ok
REBOOT
Propeller .:.:--TACHYON--:.:. Forth V23131209.1100
NAMES: $5AF5...74C3 for 6606 (0105 bytes added)
CODE: $0000...4176 for 10152 (2242 bytes added)
CALLS: 0327 vectors free
RAM: 6527 bytes free
AUTORUN BOOT
MODULES LOADED:
38B4: MULTIFILE.fth FAT32/16 MultiFile Layer V1.1 131207-0000
3179: SDCARD.fth SD CARD Toolkit - 131114.0000
2FD7: QuickStart.fth QuickStart + W5200 HARDWARE DEFINITIONS 131204.1200
17C0: EXTEND.fth Primary extensions to TACHYON kernel - 131124-0000
----------------------------------------------------------------
ok
My apologies if this is not the place to ask the following question: While converting some C code (from an ARM) to PASM this morning, the need to create and then index 2D arrays got a little tedious. What is so simple to code in C was a chore in PASM. It made me wonder if it was time consider TF. Acknowledging that there would be a steep learning curve, I simply want to know if at the end of the road there would be the sought-after payoff? Are 2D arrays convenient to create and index in Forth, and TF specifically?
The section from "And so Forth" on multidimensional arrays might get you headed in the right direction. Of course TF is a little different, so if you haven't already, you should go through Peter's Forth Introduction. The nice thing about TF (Forth generally) is that you can burn a board and start playing with things "live" to see what works and what doesn't right away. Fully interactive. That's where Forth really shines, in my view. Anyway, I hope this helps.
Hi Brian, I've been making that many little changes lately that even I can't keep up with it, are you expecting more!!!?
Putting aside labeling of builds I just wonder what it is about your setup that should cause a reboot? Simply disabling the autorun and interactively running sections of startup code should reveal the problem. Can you track it down this way? If you really want some interactive help I can do so via remote desktop software such as Splashtop Streamer so you can see what I'm doing and vice-versa on your system.
I will look at what I can do for snapshots, perhaps putting all the files into snapshot folders which are named accordingly although the file names would still be the same.
Hi Brian, I've been making that many little changes lately that even I can't keep up with it, are you expecting more!!!?
l am glad to see that I am not alone in this.
Putting aside labeling of builds I just wonder what it is about your setup that should cause a reboot? Simply disabling the autorun and interactively running sections of startup code should reveal the problem. Can you track it down this way? If you really want some interactive help I can do so via remote desktop software such as Splashtop Streamer so you can see what I'm doing and vice-versa on your system.
The REBOOT occurs in the NETWORK.fth word GO when it executes "MOUNT ls". To examine this I need only to build;
At this point I need only type MOUNT. It will either "mount" the SD card or REBOOT. There is no need to load W5200 and NETWORK.
Next step ... since there is no console emission between MOUNT and the REBOOT, I will 'walk' a console message through the code and trace how far it gets before it goes kablooey!
I will look at what I can do for snapshots, perhaps putting all the files into snapshot folders which are named accordingly although the file names would still be the same.
PERFECT ... its more or less what I have started to do here, though its a greater effort since I have to do it sans your knowledge of where you have been tinkering.
My apologies if this is not the place to ask the following question:
While converting some C code (from an ARM) to PASM this morning, the need to create and then index 2D arrays got a little tedious. What is so simple to code in C was a chore in PASM. It made me wonder if it was time consider TF.
Acknowledging that there would be a steep learning curve, I simply want to know if at the end of the road there would be the sought-after payoff? Are 2D arrays convenient to create and index in Forth, and TF specifically?
Edit: The code and data arrays (smallish) would preferably reside in COG RAM.
so if you come from ARM-C did you think about directly moving to PropGCC.
Most standard code should run with little or no modification.
As far as TF is concerned
Edit: The code and data arrays (smallish) would preferably reside in COG RAM
the COG contains the TF kernel, so there is no space for an array of significant size.
But depending on what you want to do TF is woth a look nevertheless.
I like it very much.
so if you come from ARM-C did you think about directly moving to PropGCC.
Most standard code should run with little or no modification.
As far as TF is concerned
the COG contains the TF kernel, so there is no space for an array of significant size.
But depending on what you want to do TF is woth a look nevertheless.
I like it very much.
Taking a guess at what you want to do here's a quick example using hub RAM:
DECIMAL
\ Create an 8 x 64 long array (the 4 * for bytes/long)
TABLE myarray 8 64 * 4 * ALLOT
\ Create the array access word which returns with the element address
\ the 5 SHL as there are 8*4 bytes/record and 2* 2* as a quick way of indexing longs
pub MYARRAY ( x y -- addr ) 5 SHL SWAP 2* 2* + myarray + ;
Usage:
\ Store a long at 5th element in 3rd record
12345678 5 3 MYARRAY !
Of course a more general method can be defined such as ARRAY so that you could say:
8 64 ARRAY MYARRAY
12345678 5 3 MYARRAY !
I may add a general-purpose two dimensional array construct to EXTEND as it is very simple to do.
Taking a guess at what you want to do here's a quick example using hub RAM:
DECIMAL
\ Create an 8 x 64 long array (the 4 * for bytes/long)
TABLE myarray 8 64 * 4 * ALLOT
\ Create the array access word which returns with the element address
\ the 5 SHL as there are 8*4 bytes/record and 2* 2* as a quick way of indexing longs
pub MYARRAY ( x y -- addr ) 5 SHL SWAP 2* 2* + myarray + ;
Usage:
\ Store a long at 5th element in 3rd record
12345678 5 3 MYARRAY !
Of course a more general method can be defined such as ARRAY so that you could say:
8 64 ARRAY MYARRAY
12345678 5 3 MYARRAY !
I may add a general-purpose two dimensional array construct to EXTEND as it is very simple to do.
Just want to clarify my understanding of this syntax. You are "allocating" 2048 bytes total, the design of the arrary is 64 long members by 8 records?
This syntax is very straight forward just wrapping my brain around it is the problem, thanks.
Just want to clarify my understanding of this syntax. You are "allocating" 2048 bytes total, the design of the arrary is 64 long members by 8 records?
This syntax is very straight forward just wrapping my brain around it is the problem, thanks.
We could just say 2048 ALLOT but here we pass the figures to Forth to calculate. The ARRAY construct would do just that but it could also take a further parameter to define the word length.
So we could say:
8 64 4 ARRAY MYARRAY
which would take the x y and word length parameters and allocate 2048 bytes for MYARRAY which at runtime would take x and y and calculate the address. If we were storing strings in such an array then we might allocate 16 bytes per record and say
8 64 16 ARRAY MYARRAY
and then end up using it like this for strings:
" Greetings" 5 3 MYARRAY $!
5 3 MYARRAY PRINT$ Greetings
When I get some time today I will quickly write (and test) the code but also outline it's usage.
We could just say 2048 ALLOT but here we pass the figures to Forth to calculate. The ARRAY construct would do just that but it could also take a further parameter to define the word length.
So we could say:
8 64 4 ARRAY MYARRAY
which would take the x y and word length parameters and allocate 2048 bytes for MYARRAY which at runtime would take x and y and calculate the address. If we were storing strings in such an array then we might allocate 16 bytes per record and say
8 64 16 ARRAY MYARRAY
and then end up using it like this for strings:
" Greetings" 5 3 MYARRAY $!
5 3 MYARRAY PRINT$ Greetings
When I get some time today I will quickly write (and test) the code but also outline it's usage.
Sounds great, still I'm confusing something here, in the previous example (longs) the 5th element of the 3rd record should be addressed 2 x 64 x 4 + (5 x 4) for the address i.e. 532 bytes away from the origin of myarray no?
The GOOD NEWS ... but, first, the BAD NEWS ... the bleeding edge code still suffers from REBOOT when dealing with MOUNT and its related commands. I did builds morning, afternoon, and evening pulling fresh source each new load attempt.
But, on a brighter note THE GOOD NEWS is that current DropBox package comes up clean ... Peter I have two small issues . ..
- You have MULTIFAT instead of MULTIFILE ... is that an OOOPPPSS or a change of heart?
- PLEASE, PLEASE, PLEASE ( this is me groveling!!! ;-] ) update the date code in the filename line so we easily tell what file revision we are dealing with. For example in the terminal output below, the date code is 131124, but CHANGELOG buried farther into the code is 131201 ... TNX!!
Latest news from the fringe GOOD NEWS ... BETTER NEWS ... and A PUZZLE ...
- the GOOD - Drop Box load 131209 Kernal loads clean and runs
- the BETTER - while the bleeding edge code from the "Links" page is again generating reboots, substituting the MULTIFILE.fth from the DropBox folder (the file misnamed MULTIFAT.fth) ... and IT WORKED ... THE PUZZLE.
Latest news from the fringe GOOD NEWS ... BETTER NEWS ... and A PUZZLE ...
Hi Brian, I've found that depending upon the system that you format your cards on it might be in CHS or LBA format. Can you do a 0 $400 XDUMP and copy the output in your reply?
A normal card's partition information should have:
0000_01B0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 ................
0000_01C0: 03 01 0B 30 F0 C0 00 20 00 00 00 0C 76 00 00 00 ...0... ....v...
0000_01D0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0000_01E0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0000_01F0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 AA ..............U.
But I find that some have been formatted with no information in the first sector and this in the second ($200..$3FF)
0000_03E0: 00 00 00 00 72 72 41 61 1B BE 0E 00 02 00 00 00 ....rrAa........
0000_03F0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 AA ..............U. ok
I'm trying to track down the information on this and update the code accordingly.
That doesn't look right as there is no partition table at $01BE onwards. sdcard.org "STRONGLY" recommend using their SD FORMATTER rather than the one that comes with your O/S as I have had mixed results with Windows formatting myself. I may have to write my own FORMAT definition though.
That doesn't look right as there is no partition table at $01BE onwards. sdcard.org "STRONGLY" recommend using their SD FORMATTER rather than the one that comes with your O/S as I have had mixed results with Windows formatting myself. I may have to write my own FORMAT definition though.
Looks like a bug with the init as the first sector read if it's zero isn't read at all. Easy fix, I'll do it shortly.
EDIT: found where the bug crept in, must have when I introduced multiple files, it's in !SD, the line: sector 16 ERASE
just needs to be replaced with.
sector 16 $FF FILL
Looks like a bug with the init as the first sector read if it's zero isn't read at all. Easy fix, I'll do it shortly.
EDIT: found where the bug crept in, must have when I introduced multiple files, it's in !SD, the line: sector 16 ERASE
just needs to be replaced with.
sector 16 $FF FILL
After the above mods and format with SD Formatter.
Hi all,
as mentioned earlier I'm still a Prop and Tachyon noob.
So I'm playing around with it. I managed to set up a counter to count the duration of a HIGH pulse of a square wave and convert it to microsecs and a frequency (assuming perfect 50% duty cycle).
Now I wanted to run this in a seperate cog and still display the counts and frequency in the terminal (TeraTerm, set up as suggested by Peter, thanks :-))
Here are the words I created so far:
So, if "test" were the code I want to run in a seperate cog, I tried
' test TASK? RUN
but nothing happens on the LCD. I guess the target cog doesn't know anything about the LCD (or the console? I tried to display on the console as well), right?
My goal is to "copy" an application I have developed using Spin (and lots of 3rd party objects) which consists of one master Prop and 2 to 5 slave props which reside on a seperate PCB each. The slave Props use counters to evaluate capacitive sensors, do some simple processing. the master Prop collects the sensor values from the slaves using Beau's HSP2P objects and also communicate with the PC and store the data to SD card.
So the next step after learning how to run code in a seperate cog would be to establish Prop-to-Prop communication.
Hi all,
as mentioned earlier I'm still a Prop and Tachyon noob.
So I'm playing around with it. I managed to set up a counter to count the duration of a HIGH pulse of a square wave and convert it to microsecs and a frequency (assuming perfect 50% duty cycle).
Now I wanted to run this in a seperate cog and still display the counts and frequency in the terminal (TeraTerm, set up as suggested by Peter, thanks :-))
Here are the words I created so far:
<snip>
My goal is to "copy" an application I have developed using Spin (and lots of 3rd party objects) which consists of one master Prop and 2 to 5 slave props which reside on a seperate PCB each. The slave Props use counters to evaluate capacitive sensors, do some simple processing. the master Prop collects the sensor values from the slaves using Beau's HSP2P objects and also communicate with the PC and store the data to SD card.
So the next step after learning how to run code in a seperate cog would be to establish Prop-to-Prop communication.
Since you are new to the Prop what you might not be fully aware of is that each cog has it's own I/O registers and to allow them to share pins without one trying to set a pin high and another trying to set the same pin low, the Prop simply ORs them together. So any cog can set a pin high but if another cog tries to set it low then it will stay high.
What this means is that if you want another cog to talk to say P9 then you should also let that same cog handle the initialization for that pin. At present your init is calling GutenMorgen which in the process leaves P9 high (serial idle) and then when you start the test task it tries to signal a low on that same pin but due to the OR'd nature of the I/O pins it never happens.
So simply have your test task say GutenMorgen rather than the init task or else release the P9 pin before you start the task with the sequence #P9 PININP.
BTW, Forth "layout" styles vary considerably but it seems your code is bunched up way too tight, even just having a blank line between definitions would make it easier to follow. Don't forget that you can cascade or fall-through into the next definition so instead of calling CSetup you could "fall into it" like this:
I haven't tried to include the code for P9 here but I did also notice that your task is not really a task as it exits (rather than BEGIN .. AGAIN ) which will put it back into the IDLE loop for that cog. I also like to say #P8 APIN rather than #8 APIN (the # is redundant for single digit decimals) as this helps us to see that it's the P8 pin. TF allows "symbols" to be interspersed with digits in a prefixed number as long as it ends with a digit.
EDIT: Re Prop2Prop coms I would just use a single wire common to all Props as the communications "bus" Use a 220R resistor in series with the pin so there aren't any problems with more than one Prop trying to drive the line. The SERIN and SEROUT work just fine up to 250K baud for a really simple network without requiring any special drivers. In fact I might just demonstrate such an arrangement with basically a cog dedicated to listening to the line and working out if it has been selected and buffering the receive data. Serial data can be buffered and then transmitted normally once the bus signals it's ready. Since the cog is listening all the time it can timeout to say the bus is free after which if it has data to send it will send out an address character, if that is acknowledged correctly then any data can then be sent. I can't see why a specialized point-to-point high-speed object would be needed though especially with slow sensor data.
In this multi-master scheme using the single common pin it would mean that there would be no need to "interrogate" the "slaves" as the "slaves" would be sending their data when they need to. The "master" can receive these data broadcasts and determine the source and do what it needs to do with the data or just ignore it.
[DATA BROADCAST ADDRESS] <ACK> [SOURCE ADDRESS] [DATA] [EOP]
The EOP is just a way of saying the packet is finished, no need to wait for a timeout as the bus is now free.
Comments
{ 2013-12-06 - modified LOADROM/SAVEROM to allow multiple IMAGE files. I cloned ROM.BIN four times, creating ROM0.BIN, ROM1.BIN, ROM2.BIN, and ROM3.BIN. LOADROM and SAVEROM, either invoked without stack parameters reads from or or writes to the file ROM.BIN just as PBJ coded it. But, clinb under the hood by invoking LOADIMG or SAVEIMG prefaced by the quoted filename and you can load from or save to any 32768 byte file already present on the SD Card. Examples. LOADROM \ loads image from ROM.BIN to EEPROM " ROM2.BIN" SAVEIMG \ saves RAM image to ROM2.BIN SAVEROM \ saves RAM image to ROM.BIN " ROM1.BIN" LOADIMG \ loads image from ROM1.BIN to EEPROM BBR _ Underhill Center, VT 2013-12-06 } pub SAVEROM ( -- ) " ROM.BIN" pub SAVEIMG ( "filename$" -- ) 1 FILE FOPEN$ IF 0 $8000 FIXCKSUM ." Saving to File " 0 FILE@ $8000 ADO DUP BUFFERS $200 ELOAD $200 + BUFFERS I 9 SHR SDWR DROP \ write one full sector $200 +LOOP DROP THEN ; pub LOADROM ( -- ) " ROM.BIN" pub LOADIMG ( "filename$" -- ) FOPEN$ IF ." Loading ROM Image to EEPROM " FILE@ 0 $7FE0 ADO DUP I + XADR I $40 ESAVE $40 +LOOP DROP THEN ; { 2013-12-06 - modified LOADROM/SAVEROM to allow multiple IMAGE files. I cloned ROM.BIN four times, creating ROM0.BIN, ROM1.BIN, ROM2.BIN, and ROM3.BIN. LOADROM and SAVEROM, either invoked without stack parameters reads from or or writes to the file ROM.BIN just as PBJ coded it. But, clinb under the hood by invoking LOADIMG or SAVEIMG prefaced by the quoted filename and you can load from or save to any 32768 byte file already present on the SD Card. Examples. LOADROM \ loads image from ROM.BIN to EEPROM " ROM2.BIN" SAVEIMG \ saves RAM image to ROM2.BIN SAVEROM \ saves RAM image to ROM.BIN " ROM1.BIN" LOADIMG \ loads image from ROM1.BIN to EEPROM BBR _ Underhill Center, VT 2013-12-06 } pub SAVEROM ( -- ) " ROM.BIN" pub SAVEIMG ( "filename$" -- ) 1 FILE FOPEN$ IF 0 $8000 FIXCKSUM ." Saving to File " 0 FILE@ $8000 ADO DUP BUFFERS $200 ELOAD $200 + BUFFERS I 9 SHR SDWR DROP \ write one full sector $200 +LOOP DROP THEN ; pub LOADROM ( -- ) " ROM.BIN" pub LOADIMG ( "filename$" -- ) FOPEN$ IF ." Loading ROM Image to EEPROM " FILE@ 0 $7FE0 ADO DUP I + XADR I $40 ESAVE $40 +LOOP DROP THEN ;Nice work Brian, very cool, I can now change from Fully Automated Pressure Sterilizer ROM0.BIN to Full TCP/IP Server mode ROM1.BIN, althought with TF I can run everything at the same time still and Peter is still busy reclaiming more memory
Hi Brian, I wasn't intending to load multiple ROMs but there's no reason you can't so I have incorporated a slightly modified version of this using your SAVEIMG and LOADIMG names.
Obviously, SAVEROM/LOADROM need a MOUNTed SDcard... I rather suspect the problem is there.
I was shuffling the kernel's memory around last night so if you used the bleeding edge web documents for source then that might have something to do with it. I'm checking it out now and making a few adjustments. If you do happen to use the bleeding edge source then it might be a good idea to keep a copy of the last files that proved stable just in case. If you do that you can also do a file compare to find out what's changed too if you are curious enough to want to know.
Hi Brian, don't get mad at me but I think your problems may have resulted from a vector that failed to get initialized at compile time. I just ran into the problem now but I found that whenever CARD? was invoked that it crashed. This was traced back to the "ucard" vector which is normally 0 and not taken except in this case it had garbage in it. In recent versions when I create a variable it also inits it's storage to zero but "ucard" was moved over to the DS style variable, one that is basically a constant that points to the storage area, which was not being initialized. Now that it's specifically zeroed at compile time it now works.
Sorry about that
That was not an easy bug find Peter!
With all these [MODULES] we should be able to get a validation load for all new TACHYON builds. How can I help? I'm thinking the SD card could hold the results of valid operations that are tested. I used a similar "validation file" technique when I tested cross platform in-memory database engines .
These bugs are few and far between and when you consider the almost interactive nature of the source code "release", in that it always released in that sense via Google docs and webdocs, then Dropbox , then I am very surprised that there are not more problems. When you are on the bleeding edge you expect to get cut!
However if I devoted too much time to validation testing I would get far less done and everyone would have to wait for a release, maybe only twice a year! The Tachyon project as it is, is a WIP, but a very usable one at that.
I noticed that my ISP is blocking port 80 so I am going to find out if I can get it unblocked. In the meantime ports 81 and 82 are forwarded to the Prop and still work fine. tachyonforth.com:81
While converting some C code (from an ARM) to PASM this morning, the need to create and then index 2D arrays got a little tedious. What is so simple to code in C was a chore in PASM. It made me wonder if it was time consider TF.
Acknowledging that there would be a steep learning curve, I simply want to know if at the end of the road there would be the sought-after payoff? Are 2D arrays convenient to create and index in Forth, and TF specifically?
Edit: The code and data arrays (smallish) would preferably reside in COG RAM.
I'm still new to Forth, and can't speak for Tachyon specifically, but Forth is a lower level language. You don't get data structures like arrays out of the box like you would with C, so in this regards it is similar to assembler. But the language is interactive and extensible, so you can implement arrays easier than you would in PASM. The extensions then become part of the language, so the language becomes easier to use as you add onto it.
The joke is that if Forth were a car it would arrive as a kit, you could build any car imaginable out of it, but it will drive backwards when it is done. Which raises the obvious question why did I bother to learn how to use it?
Everyone has their own reasons, but for me where Forth shines is that you build a domain specific language to solve your problem. This language can then be scripted via a serial command window. This is really useful for developing motion scripts for my robot arms.
But, on a brighter note THE GOOD NEWS is that current DropBox package comes up clean ... Peter I have two small issues . ..
- You have MULTIFAT instead of MULTIFILE ... is that an OOOPPPSS or a change of heart?
- PLEASE, PLEASE, PLEASE ( this is me groveling!!! ;-] ) update the date code in the filename line so we easily tell what file revision we are dealing with. For example in the terminal output below, the date code is 131124, but CHANGELOG buried farther into the code is 131201 ... TNX
Hi Brian, I've been making that many little changes lately that even I can't keep up with it, are you expecting more!!!?
Putting aside labeling of builds I just wonder what it is about your setup that should cause a reboot? Simply disabling the autorun and interactively running sections of startup code should reveal the problem. Can you track it down this way? If you really want some interactive help I can do so via remote desktop software such as Splashtop Streamer so you can see what I'm doing and vice-versa on your system.
I will look at what I can do for snapshots, perhaps putting all the files into snapshot folders which are named accordingly although the file names would still be the same.
l am glad to see that I am not alone in this.
The REBOOT occurs in the NETWORK.fth word GO when it executes "MOUNT ls". To examine this I need only to build;
Tachyon_V23.spin EXTEND.fth QS.fth SDCARD.fth MULTIFILE.fth
At this point I need only type MOUNT. It will either "mount" the SD card or REBOOT. There is no need to load W5200 and NETWORK.
Next step ... since there is no console emission between MOUNT and the REBOOT, I will 'walk' a console message through the code and trace how far it gets before it goes kablooey!
PERFECT ... its more or less what I have started to do here, though its a greater effort since I have to do it sans your knowledge of where you have been tinkering.
so if you come from ARM-C did you think about directly moving to PropGCC.
Most standard code should run with little or no modification.
As far as TF is concerned the COG contains the TF kernel, so there is no space for an array of significant size.
But depending on what you want to do TF is woth a look nevertheless.
I like it very much.
Taking a guess at what you want to do here's a quick example using hub RAM:
DECIMAL
\ Create an 8 x 64 long array (the 4 * for bytes/long)
TABLE myarray 8 64 * 4 * ALLOT
\ Create the array access word which returns with the element address
\ the 5 SHL as there are 8*4 bytes/record and 2* 2* as a quick way of indexing longs
pub MYARRAY ( x y -- addr ) 5 SHL SWAP 2* 2* + myarray + ;
Usage:
\ Store a long at 5th element in 3rd record
12345678 5 3 MYARRAY !
Of course a more general method can be defined such as ARRAY so that you could say:
8 64 ARRAY MYARRAY
12345678 5 3 MYARRAY !
I may add a general-purpose two dimensional array construct to EXTEND as it is very simple to do.
Just want to clarify my understanding of this syntax. You are "allocating" 2048 bytes total, the design of the arrary is 64 long members by 8 records?
This syntax is very straight forward just wrapping my brain around it is the problem, thanks.
We could just say 2048 ALLOT but here we pass the figures to Forth to calculate. The ARRAY construct would do just that but it could also take a further parameter to define the word length.
So we could say:
8 64 4 ARRAY MYARRAY
which would take the x y and word length parameters and allocate 2048 bytes for MYARRAY which at runtime would take x and y and calculate the address. If we were storing strings in such an array then we might allocate 16 bytes per record and say
8 64 16 ARRAY MYARRAY
and then end up using it like this for strings:
" Greetings" 5 3 MYARRAY $!
5 3 MYARRAY PRINT$ Greetings
When I get some time today I will quickly write (and test) the code but also outline it's usage.
Sounds great, still I'm confusing something here, in the previous example (longs) the 5th element of the 3rd record should be addressed 2 x 64 x 4 + (5 x 4) for the address i.e. 532 bytes away from the origin of myarray no?
dp
Latest news from the fringe GOOD NEWS ... BETTER NEWS ... and A PUZZLE ...
- the GOOD - Drop Box load 131209 Kernal loads clean and runs
- the BETTER - while the bleeding edge code from the "Links" page is again generating reboots, substituting the MULTIFILE.fth from the DropBox folder (the file misnamed MULTIFAT.fth) ... and IT WORKED ... THE PUZZLE.
The load looks like this
I ran a diff on the 2 files, the output was over 800 lines, but closer inspection revealed most were the same code reformatted...
Hi Brian, I've found that depending upon the system that you format your cards on it might be in CHS or LBA format. Can you do a 0 $400 XDUMP and copy the output in your reply?
A normal card's partition information should have:
0000_01B0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 ................
0000_01C0: 03 01 0B 30 F0 C0 00 20 00 00 00 0C 76 00 00 00 ...0... ....v...
0000_01D0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0000_01E0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0000_01F0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 AA ..............U.
But I find that some have been formatted with no information in the first sector and this in the second ($200..$3FF)
0000_03E0: 00 00 00 00 72 72 41 61 1B BE 0E 00 02 00 00 00 ....rrAa........
0000_03F0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 AA ..............U. ok
I'm trying to track down the information on this and update the code accordingly.
401A: W5200.fth WIZNET W5200 driver 131107.0000
3756: MULTIFILE.fth FAT32/16 MultiFile Layer V1.1 131207-0000
2FD7: SDCARD.fth SD CARD Toolkit - 131114.0000
17C0: EXTEND.fth Primary extensions to TACHYON kernel - 131124-0000
That doesn't look right as there is no partition table at $01BE onwards. sdcard.org "STRONGLY" recommend using their SD FORMATTER rather than the one that comes with your O/S as I have had mixed results with Windows formatting myself. I may have to write my own FORMAT definition though.
Looks like a bug with the init as the first sector read if it's zero isn't read at all. Easy fix, I'll do it shortly.
EDIT: found where the bug crept in, must have when I introduced multiple files, it's in !SD, the line:
sector 16 ERASE
just needs to be replaced with.
sector 16 $FF FILL
After the above mods and format with SD Formatter.
as mentioned earlier I'm still a Prop and Tachyon noob.
So I'm playing around with it. I managed to set up a counter to count the duration of a HIGH pulse of a square wave and convert it to microsecs and a frequency (assuming perfect 50% duty cycle).
Now I wanted to run this in a seperate cog and still display the counts and frequency in the terminal (TeraTerm, set up as suggested by Peter, thanks :-))
Here are the words I created so far:
: LCDEMIT #9 SEROUT ; : LCD ' LCDEMIT uemit W! ; : clrlcd #254 #9 SEROUT #01 #9 SEROUT ; : GutenMorgen clrlcd LCD ." Guten Morgen :-) " CON ; : C1KHZ A #8 APIN 1 KHZ ; : ToMuS ( counter ticks -- µs ) 2* #125 * #10000 / ; ( assuming perfect 50% duty cycle ) : ToFreq ( µs -- freq ) #1000000 SWAP / ; : PHSB@ DROP CR $D SFR@ DUP DUP DUP ." HEX: " $4810 .NUM SPACE ." DEC: " $000A .NUM SPACE ." microsec: " ToMuS DUP $000A .NUM SPACE ." µs " SPACE ." Freq: " ToFreq $000A .NUM SPACE ." Hz "; : PHS! ( n -- ) PHSA ctr C@ + COG! ; : CSetup B #10 APIN %01000 CTRMODE #1 FRQ ; : Init HEX GutenMorgen C1KHZ CSetup ; : CountHigh #10 MASK WAITPNE B #0 PHS! #10 MASK WAITPEQ #10 MASK WAITPNE B #0 CTRMODE PHSB@ ; : CountLoop #10 #0 DO CountHigh CSetup LOOP ; AUTORUN Init BACKUP pub test #5 #0 DO CR clrlcd LCD I $000A .NUM SPACE ." Test" 125 ms LOOP CON ;So, if "test" were the code I want to run in a seperate cog, I tried but nothing happens on the LCD. I guess the target cog doesn't know anything about the LCD (or the console? I tried to display on the console as well), right?Here is my INFO output:
My goal is to "copy" an application I have developed using Spin (and lots of 3rd party objects) which consists of one master Prop and 2 to 5 slave props which reside on a seperate PCB each. The slave Props use counters to evaluate capacitive sensors, do some simple processing. the master Prop collects the sensor values from the slaves using Beau's HSP2P objects and also communicate with the PC and store the data to SD card.
So the next step after learning how to run code in a seperate cog would be to establish Prop-to-Prop communication.
Since you are new to the Prop what you might not be fully aware of is that each cog has it's own I/O registers and to allow them to share pins without one trying to set a pin high and another trying to set the same pin low, the Prop simply ORs them together. So any cog can set a pin high but if another cog tries to set it low then it will stay high.
What this means is that if you want another cog to talk to say P9 then you should also let that same cog handle the initialization for that pin. At present your init is calling GutenMorgen which in the process leaves P9 high (serial idle) and then when you start the test task it tries to signal a low on that same pin but due to the OR'd nature of the I/O pins it never happens.
So simply have your test task say GutenMorgen rather than the init task or else release the P9 pin before you start the task with the sequence #P9 PININP.
BTW, Forth "layout" styles vary considerably but it seems your code is bunched up way too tight, even just having a blank line between definitions would make it easier to follow. Don't forget that you can cascade or fall-through into the next definition so instead of calling CSetup you could "fall into it" like this:
[FONT=courier new]: [B]Init[/B] HEX GutenMorgen A #8 APIN 1 KHZ : [B]CSetup[/B] B #10 APIN %01000 CTRMODE #1 FRQ ; [/FONT]I haven't tried to include the code for P9 here but I did also notice that your task is not really a task as it exits (rather than BEGIN .. AGAIN ) which will put it back into the IDLE loop for that cog. I also like to say #P8 APIN rather than #8 APIN (the # is redundant for single digit decimals) as this helps us to see that it's the P8 pin. TF allows "symbols" to be interspersed with digits in a prefixed number as long as it ends with a digit.
EDIT: Re Prop2Prop coms I would just use a single wire common to all Props as the communications "bus" Use a 220R resistor in series with the pin so there aren't any problems with more than one Prop trying to drive the line. The SERIN and SEROUT work just fine up to 250K baud for a really simple network without requiring any special drivers. In fact I might just demonstrate such an arrangement with basically a cog dedicated to listening to the line and working out if it has been selected and buffering the receive data. Serial data can be buffered and then transmitted normally once the bus signals it's ready. Since the cog is listening all the time it can timeout to say the bus is free after which if it has data to send it will send out an address character, if that is acknowledged correctly then any data can then be sent. I can't see why a specialized point-to-point high-speed object would be needed though especially with slow sensor data.
In this multi-master scheme using the single common pin it would mean that there would be no need to "interrogate" the "slaves" as the "slaves" would be sending their data when they need to. The "master" can receive these data broadcasts and determine the source and do what it needs to do with the data or just ignore it.
[DATA BROADCAST ADDRESS] <ACK> [SOURCE ADDRESS] [DATA] [EOP]
The EOP is just a way of saying the packet is finished, no need to wait for a timeout as the bus is now free.