Cog6 ok
c" :test 4 dira COG! begin 4 outa COG! 64 delms 0 outa COG! 64 delms 0 until ;" 4 cogx
Cog6 ok
c" test" 4 cogx
Cog6 ok
This execute on cog5?
Why cog5 although 'test' is sent to cog4?
Cog6 ok
c" 1 2 3" 4 cogx
Cog6 ok
5 >con
Cog5 ok
st?
ST: 00000001 00000002 00000003
Cog5 ok
Cog6 ok
c" 1 2 3" 3 cogx
Cog6 ok
4 >con
no response
Cog6 ok
c" 1 2 3" 2 cogx
Cog6 ok
3 >con
no response
Cog6 ok
c" 1 2 3" 1 cogx
Cog6 ok
2 >con
no response
Cog6 ok
c" 1 2 3" 0 cogx
Cog6 ok
1 >con
no response
Cog6 ok
c" :test 4 dira COG! begin 4 outa COG! 64 delms 0 outa COG! 64 delms 0 until ;" 4 cogx
Cog6 ok
c" test" 4 cogx
Cog6 ok
This execute on cog5?
Why cog5 although 'test' is sent to cog4?
Cog6 ok
c" 1 2 3" 4 cogx
Cog6 ok
5 >con
Cog5 ok
st?
ST: 00000001 00000002 00000003
Cog5 ok
Cog6 ok
c" 1 2 3" 3 cogx
Cog6 ok
4 >con
no response
Cog6 ok
c" 1 2 3" 2 cogx
Cog6 ok
3 >con
no response
Cog6 ok
c" 1 2 3" 1 cogx
Cog6 ok
2 >con
no response
Cog6 ok
c" 1 2 3" 0 cogx
Cog6 ok
1 >con
no response
The :test word you use DEFINES a word in the dictionary using another cog, but does NOT execute it. So this is not help diagnose the issue. I don't know if its a typo, but there must be a space between the ':' and the 't'; and there must be space between the ';' and the " double quote. Sending this would make the other cog respond "UNDEFINED WORD" which you would not see because there is no terminal.
ALSO you did not show which cogs are running forth, and which are idle. IF you are using the default standard kernel, only cog5 and cog6 are running, and sending commands to other cogs does no do anything.
Suggestion:
FIRST you must execute
cog?
To see which cogs are running forth.
Second define a word that blinks the LED, and test that is works. Make it blink for say, 30 seconds. : blinky30 ... ;
Third
6 >con
to each running forth cog to check the stacks are empty ST?
Fourth run blinky30 on a different cog:
Cog6
c" blinky30 " 5 cogx
fifth check that the cogs all have no stack checks while blinky is running, and check after.
At least, this is what I will do next Saturday if you say that there is an error (and this method can reproduce it).
Ok, I use hex for the pin assignments as you posted. They look correct Interesting thing, I loaded the code using serial terminal cog6 WITHOUT the sd car plugged into the slot. When thesd card is plugged in, I get
Cog5 RESET - last status: MAIN STACK UNDERFLOW
So right off the bat, we can tell there is an error someplace. Whether it is in PropForth3.5c or your code I can't tell right off the bat.
So.... I see that there is a main stack error when the card is plugged in or unplugged and plugged in again.
So simply loading the code does something that affects the way the interpreter loop runs. I say this because I didn't see anything in the code that started a task in the background, and I think the interpreter loop is the only thing running.
There aren't many comments, and there aren't any stack notes, and I'm just not so smart, I'll have to say that I won't be able to say anything more helpful until I get some time go through this definition by definition and test everything. Of course, I will need to find the SD standard and see what is specifically called for. What reference did you use to write this, can you send me a link? If I can read-up on it before Saturday, I might make better progress.
I use standard PropForth3.5.
c" :test .. is typo.
No space between ';' and '"' is ok.
Cog6 ok
cog?
Forth cogs: 0 - 6
Running Forth cogs: 5 - 6
Spin cogs: NONE
Cog6 ok
c" : test 4 dira COG! begin 4 outa COG! 64 delms 0 outa COG! 64 delms 0 until ;" 5 cogx
Cog6 ok
c" test" 5 cogx
Cog6 ok
(return key when LED of P2 is blinking)
Cog6 ok
1 2 st?
ST: 00000001 00000002
Cog6 ok
5 >con
No response
LED blinking execute on cog5.
c" 1 2 3" 4 cogx
Cog6 ok
4 >con
no response
reboot
c" 1 2 3" 4 cogx
Cog6 ok
5 >con
Cog5 ok
st?
ST: 00000001 00000002 00000003
Cog5 ok
When sending to cog4, there is on stack of cog5.
I'm confused.
Ok, I use hex for the pin assignments as you posted
Interesting thing, I loaded the code using serial terminal cog6 WITHOUT the sd car plugged into the slot.
When thesd card is plugged in, I get
Cog5 RESET - last status: MAIN STACK UNDERFLOW
So right off the bat, we can tell there is an error someplace.
Whether it is in PropForth3.5c or your code I can't tell right off the bat.
So....
I see that there is a main stack error when the card is plugged in or unplugged and plugged in again.
So simply loading the code does something that affects the way the interpreter loop runs. I say this because I didn't see anything in the code that started a task in the background, and I think the interpreter loop is the only thing running.
Without SD-card, viewer print out "error" to quit.
Typing "sd_init", it print out "SDSC initialize success".
Please check below:
a constant _sd_di \ connected SD's di
c constant _sd_do \ connected SD's do
Starting 'viewer' of sd_viewer_1.0.f, sd_init of sd_func_1.0.f execute at first.
About sd_init
SD-soft-reset CMD0 -- If no card, quit.
Check of SDHC CMD8 -- If response is illegal, SDSC --> CMD55 ACMD41 --> If ok,message"SDSC initialize success".
If ng(MMC or brolen),loop. Needing power-reset
If response is ok,card's iniitialize using CMD55 ACMD41
next reading OCR using CMD58
Caution: When I check 2G SDSC(Kingston), its card response ok to CMD8.
So I check SDSC/SDHC reading CSD at last.
Cog6 ok
cog?
Forth cogs: 0 - 6
Running Forth cogs: 5 - 6
Spin cogs: NONE
Cog6 ok
This is the key. Only cogs 5 & 6 are running forth. Cog 4 will not respond, its not running.
c" : test 4 dira COG! begin 4 outa COG! 64 delms 0 outa COG! 64 delms 0 until ;" 5 cogx
Cog6 ok
This is the key: Define word on cog6 (or whatever cog you are running on), not remotely to cog5, unless you know why you are doing it. While equivalenet (if functioning correctly) it does not report errors to console (no console on remote cog). You are encountering errors, so don't do this.
c" test" 5 cogx
Cog6 ok
(return key when LED of P2 is blinking)
Cog6 ok
1 2 st?
ST: 00000001 00000002
Cog6 ok
5 >con
No response
This is key: LED blinking is executing on cog5. So it will not respond, its busy doing the blinking LED
c" 1 2 3" 4 cogx
Cog6 ok
4 >con
no response
Of course. Cog4 is not running.
reboot
c" 1 2 3" 4 cogx
Cog6 ok
5 >con
Cog5 ok
st?
ST: 00000001 00000002 00000003
Cog5 ok
>> When sending to cog4, there is on stack of cog5.
>> I'm confused.
- If cog is not running and you send it a command, result is undefined. If your experiment shows that sending a string to a non running cog causes the string to end up in the next cog, that's an interesting discovery. Solution - don't send command to cogs that are not running.
I will play with this on weekend, and see if I can reproduce it. I will report it and see if it is a bug. But so far, all function appear to be correct.
Starting 'viewer' of sd_viewer_1.0.f, sd_init of sd_func_1.0.f execute at first.
About sd_init
SD-soft-reset CMD0 -- If no card, quit.
Check of SDHC CMD8 -- If response is illegal, SDSC --> CMD55 ACMD41 --> If ok,message"SDSC initialize success".
If ng(MMC or brolen),loop. Needing power-reset
If response is ok,card's iniitialize using CMD55 ACMD41
next reading OCR using CMD58
Caution: When I check 2G SDSC(Kingston), its card response ok to CMD8.
So I check SDSC/SDHC reading CSD at last.
sd_init finally worked with correct pins and card plugged in.
BUT I get the main stack errors sometimes.
When I tried to load sd_viewer, I received "out of memory" error
dira/outa for cog5 is separately them for cog4.
My idea is wrong?
Yes, I think the error is the DIRA command. I believe the prop reference says that there is only one dira register that is common to all cogs and controls all pins. The way you are using it, it turns off all the others. For this case, you want to AND the current pins with the new pin
DIRA L@ 8 AND DIRA L!
or something to that affect.
PLEASE!!! STOP defining words in cogs other than the terminal using
c" : test 4 dira COG! 40 0 do 4 outa COG! 64 delms 0 outa COG! 64 delms loop ; " 5 cogx
Please understand that when you define a word in the dictionary from ANY cog, it all goes into the same dictionary. BUT the above method does not get to see any errors or status, and it makes it hard to debug.
I updated to PropForth3.5e.
But message is "PROPELLER REBOOT PropForth v3.5c 20101017 15:30 0".
I make sd_func_1.0_test.
Loading sd_func_1.0_test.
(please chage number for _sd_cs/_sd_di/_sd_clk/_sd_do)
Executing word"sd_init", please check messages.
I attached log_sdinit.
I checked 4G/2G/512M.
If ok, loading 1st:sd_func_1.0_test or sd_func_1.0 2nd:fat_1.0 3rd:sd_viewer_1.0
executing "viewer".
I did experiments.
I copy/paste codes from TeraTerm.
: test dira COG@ or dira COG! 40 0 do dup dup outa COG@ or outa COG! f0 delms outa COG@ - outa COG! f0 delms loop drop ;
c" : test dira COG@ or dira COG! 40 0 do dup dup outa COG@ or outa COG! f0 delms outa COG@ - outa COG! f0 delms loop drop ;" 5 cogx
c" : test dira COG@ or dira COG! 40 0 do dup dup outa COG@ or outa COG! f0 delms outa COG@ - outa COG! f0 delms loop drop ;" 4 cogx
Executing below:
Cog6 ok
c" 10 10 test" 4 cogx <-- LED blinking connected to P4
Cog6 ok
c" 8 8 test" 5 cogx <-- LED Off connected to P3
Cog6 ok
4 4 test <-- LED blinking connected to P2 (P4/P2 blinking at same time)
Cog6 ok
Cog6 ok
c" 8 8 test" 5 cogx <-- LED blinking connected to P3
Cog6 ok
c" 10 10 test" 4 cogx <-- LED Off connected to P4
Cog6 ok
4 4 test <-- LED blinking connected to P2(P3/P2 blinking at same time)
Cog6 ok
I did experiments.
I copy/paste codes from TeraTerm.
: test dira COG@ or dira COG! 40 0 do dup dup outa COG@ or outa COG! f0 delms outa COG@ - outa COG! f0 delms loop drop ;
c" : test dira COG@ or dira COG! 40 0 do dup dup outa COG@ or outa COG! f0 delms outa COG@ - outa COG! f0 delms loop drop ;" 5 cogx
c" : test dira COG@ or dira COG! 40 0 do dup dup outa COG@ or outa COG! f0 delms outa COG@ - outa COG! f0 delms loop drop ;" 4 cogx
What you are trying to do with defining test three times? Aaaargh! The explanation for cogx must be wrong, I will try to re-write it. The definition for all forth words is exactly the same for all cogs 0 through seven. Only the last definition for any words will be called from the command prompt. The earlier definitions of test are hidden by the most recent one.
Please Eliminate the definitions you are sending to cog5 and cog4.
This is what I would do:
Write the word "test" so that is accepts two parameters: "number of blinks" and "out pin".
Define the word exactly once. Do not fool your yourself by re-defining it on different cogs.
Demonstrate that the word test works from the console cog for each led and for varying numbers of blinks with no stack error.
Send the parameters and test word to running forth cogs where each cogs gets a different pin and a different number of blinks.
Incorrect comment for word"nip" in PropForthPart1.f
( x1 x2 -- x1 ) --> ( x1 x2 -- x2 )
About coment on PropForth.spin:
main memory:
So using c@ with an empty stack will return a value and not trigger stack checking. However c! with an empty stack will trigger a stack underflow.
I think it is correct below:
So using c! with an empty stack will return a value and not trigger stack checking. However c@ with an empty stack will trigger a stack underflow.
My idea is wrong?
I have question.
Where does word "here" define?
I cannot find out it in PropForthPart1/PropForthPart2.
>> About coment on PropForth.spin:
>> main memory:
>>So using c@ with an empty stack will return a value and not trigger stack checking. However c! with an empty stack will trigger a stack underflow.
The FIRST item on the stack is BUFFERED, so the stack over/under flow is not activated on items that only use the top location of the stack.
HOWEVER, most cases eventually use an additional item and the stack checking gets triggered. The cost of stack checking on the first item would add additional code size and code execution time for all items. The decision was made to keep it small and simple. So far this has not been a problem, just something to be aware of. If it gives you problems we can look at the situation, but its probably better to just be aware
>> I think it is correct below:
So using c! with an empty stack will return a value and not trigger stack checking. However c@ with an empty stack will trigger a stack underflow.
>>My idea is wrong?
Your idea is correct. Just be aware that the FIRST STACK ITEM IS BUFFERED and the under/over flow checking is NOT triggered until another stack operation takes place.
>>> I have question.
>>> Where does word "here" define?
>>> I cannot find out it in PropForthPart1/PropForthPart2.
I think "here" is defined in the assembler code in PROPFORTH.SPIN
The dictionary structure, the threading model, and something else (I think the console I/O) are initially defined directly in spin assembler
That is the explanation of the c_<**labelname**> entries in the bottom of the dictionary. I'm a little hazy about what is going on down there,
but basically that stuff is the transition from non-forth spin assembler to the forth kernel. I think those labels are only called by the spin compiler and serve to set up forth.
I'll ask about that today in as my understanding is incomplete.
I have question.
Where does word "here" define?
I cannot find out it in PropForthPart1/PropForthPart2.
Thanks for the question. This has been added to the FAQ:
OK, there are three words that are defined and set in propforth.spin instead of PropForthpart1.f and propforthpart2.f
These are
here
dictend
memend
These can't be easily re-defined while forth is running, it is very dangerous and things tend to go crazy. Sal had to do it several times and had problems, so these ended up like this.
These three words are the absolute beginning of the forth kernel. Once the kernel began, memory access was added, the variables, then colon definitions, eventually it got to the point where ther was enough defined that the preliminary stuff could be removed, and there was enough to make a working forth kernel from forth.
The spin tool is used to create the forth kernel from spin code. Normally in a native forth, the forth system is used to create itself from scratch without the use of external tools (a pc and non forth compiler for example). The decision was made NOT to do this at this time for propforth.
Using the SPIN tool as the starting point for propforth has two main advantages:
1) it is relatively easy to bring in or interface to spin and assembly objects
2) the spin tool takes care of any forward references (which usually require special handling during forth kernel build).
So, the definitions for here, dictend, and memend are first in the forth dictionsary. Do "words" whcih prints out the dictionary reverse order, and these are the very last to print.
These words are defined and values assigned in Propforth.spin at around line 165.
here is pretty much always 0D72 to start with, although it does automatically adjust itself as shown in the HiResVGA versions.
I did experiment.
Although transmitting data to Cog4, this is correct way?
Cog6 ok
4 cogreset
COG 4 RESET - last status: OK
Cog6 ok
4 _fcog W!
Cog6 ok
c" 1 2 3" 4 cogx
Cog6 ok
4 >con
Cog4 ok
st?
ST: 00000001 00000002 00000003
Cog4 ok
Cog6 ok
cog?
Forth cogs: 0 - 6
Running Forth cogs: 5 - 6
Spin cogs: NONE
Cog6 ok
variable OUTA
Cog6 ok
: test
0 dira COG! dira COG!
40 0 do dup dup
OUTA L@ or dup OUTA L!
outa COG!
64 delms
OUTA L@ xor dup OUTA L!
outa COG!
64 delms
loop
driop
;
Cog6 ok
0 cogreset
COG 0 RESET - last status: ok
Cog6 ok
1 cogreset
COG 1 RESET - last status: ok
Cog6 ok
2 cogreset
COG 2 RESET - last status: ok
Cog6 ok
3 cogreset
COG 3 RESET - last status: ok
Cog6 ok
4 cogreset
COG 4 RESET - last status: ok
Cog6 ok
0 _fcog W!
Cog6 ok
c" 4 4 test" 0 cogx <-- blinking LED connected to P2
Cog6 ok
c" 8 8 test" 1 cogx <-- blinking LED connected to P3
Cog6 ok
c" 10 10 test" 2 cogx <-- blin ing LED connected to P4
Cog6 ok
c" 20 20 test" 3 cogx <-- blinking LED connected to P5
Cog6 ok
c" 40 40 test" 4 cogx <-- blinking LED connected to P6
Cog6 ok
80 80 test <-- blinking LED connected to P7
{
-----------------------------------------------------------------------------------------
display all defined word's name on dictionary (1st: lastest word last: first word)
-----------------------------------------------------------------------------------------
}
wvariable tmp
: to_decimal
0 tmp W!
3e8 swap over
4 0 do
u/mod dup 0> if 1 tmp W! .hex else tmp W@ if 0> .hex else drop then then swap a / swap over
loop
3drop
;
: disp_all_word
0 wlastnfa W@
begin
swap 1+ dup to_decimal ." : " swap
dup
\ dup C@ 1f and 0 do 1+ dup C@ emit loop drop cr
\ namelen 0 do dup C@ emit 1+ loop drop cr \ same as above
.strname cr \ same as above
nfa>next
dup 0=
until
2drop
;
I found out very little mistake on PropForth.spin.
\ lockclr (n1 -- n2) set lock n1...........the lock was set ... --> clear lock n1 .... the lock was clear ...
: checkdict here W@ + dictend W@ >=
if cr here W@ . dictend . _eoom clearkeys reset then ; --> if cr here W@ . dictend W@ . _eoom clearkeys reset then ;
And one more on end of Propforth.spin
Assembler's part of PropForth.spin
:
:
cogdataPFA
:
:
{{
Start of the Forth Dictionary
:
:
- bit 4 ($20) set if it is an eXecute word ---> bit 5 ($20) set if it is an eXecute word
:
}}
ForthDictiStart
:
Comments
LED Of P2 blink below: This execute on cog5?
Why cog5 although 'test' is sent to cog4?
The :test word you use DEFINES a word in the dictionary using another cog, but does NOT execute it. So this is not help diagnose the issue. I don't know if its a typo, but there must be a space between the ':' and the 't'; and there must be space between the ';' and the " double quote. Sending this would make the other cog respond "UNDEFINED WORD" which you would not see because there is no terminal.
ALSO you did not show which cogs are running forth, and which are idle. IF you are using the default standard kernel, only cog5 and cog6 are running, and sending commands to other cogs does no do anything.
Suggestion:
FIRST you must execute
cog?
To see which cogs are running forth.
Second define a word that blinks the LED, and test that is works. Make it blink for say, 30 seconds. : blinky30 ... ;
Third
6 >con
to each running forth cog to check the stacks are empty ST?
Fourth run blinky30 on a different cog:
Cog6
c" blinky30 " 5 cogx
fifth check that the cogs all have no stack checks while blinky is running, and check after.
At least, this is what I will do next Saturday if you say that there is an error (and this method can reproduce it).
Cog5 RESET - last status: MAIN STACK UNDERFLOW
So right off the bat, we can tell there is an error someplace. Whether it is in PropForth3.5c or your code I can't tell right off the bat.
So.... I see that there is a main stack error when the card is plugged in or unplugged and plugged in again.
So simply loading the code does something that affects the way the interpreter loop runs. I say this because I didn't see anything in the code that started a task in the background, and I think the interpreter loop is the only thing running.
There aren't many comments, and there aren't any stack notes, and I'm just not so smart, I'll have to say that I won't be able to say anything more helpful until I get some time go through this definition by definition and test everything. Of course, I will need to find the SD standard and see what is specifically called for. What reference did you use to write this, can you send me a link? If I can read-up on it before Saturday, I might make better progress.
I use standard PropForth3.5.
c" :test .. is typo.
No space between ';' and '"' is ok.
Cog6 ok cog? Forth cogs: 0 - 6 Running Forth cogs: 5 - 6 Spin cogs: NONE Cog6 ok c" : test 4 dira COG! begin 4 outa COG! 64 delms 0 outa COG! 64 delms 0 until ;" 5 cogx Cog6 ok c" test" 5 cogx Cog6 ok (return key when LED of P2 is blinking) Cog6 ok 1 2 st? ST: 00000001 00000002 Cog6 ok 5 >con No responseLED blinking execute on cog5.When sending to cog4, there is on stack of cog5.
I'm confused.
Without SD-card, viewer print out "error" to quit.
Typing "sd_init", it print out "SDSC initialize success".
Please check below:
a constant _sd_di \ connected SD's di
c constant _sd_do \ connected SD's do
http://www.microsoft.com/whdc/system/platform/firmware/fatgen.mspx
Reference about SD-card
http://elm-chan.org/docs/mmc/mmc_e.html
Part 1 Physical Layer Simplified Specification Ver3.01 in HTML below:
http://www.sdcard.org/developers/tech/sdcard/pls/simplified_specs/
Starting 'viewer' of sd_viewer_1.0.f, sd_init of sd_func_1.0.f execute at first.
About sd_init
SD-soft-reset CMD0 -- If no card, quit.
Check of SDHC CMD8 -- If response is illegal, SDSC --> CMD55 ACMD41 --> If ok,message"SDSC initialize success".
If ng(MMC or brolen),loop. Needing power-reset
If response is ok,card's iniitialize using CMD55 ACMD41
next reading OCR using CMD58
Caution: When I check 2G SDSC(Kingston), its card response ok to CMD8.
So I check SDSC/SDHC reading CSD at last.
Cog6 ok cog? Forth cogs: 0 - 6 Running Forth cogs: 5 - 6 Spin cogs: NONE Cog6 okThis is the key. Only cogs 5 & 6 are running forth. Cog 4 will not respond, its not running.This is the key: Define word on cog6 (or whatever cog you are running on), not remotely to cog5, unless you know why you are doing it. While equivalenet (if functioning correctly) it does not report errors to console (no console on remote cog). You are encountering errors, so don't do this.
This is key: LED blinking is executing on cog5. So it will not respond, its busy doing the blinking LED
Of course. Cog4 is not running.
>> When sending to cog4, there is on stack of cog5.
>> I'm confused.
- If cog is not running and you send it a command, result is undefined. If your experiment shows that sending a string to a non running cog causes the string to end up in the next cog, that's an interesting discovery. Solution - don't send command to cogs that are not running.
I will play with this on weekend, and see if I can reproduce it. I will report it and see if it is a bug. But so far, all function appear to be correct.
sd_init finally worked with correct pins and card plugged in.
BUT I get the main stack errors sometimes.
When I tried to load sd_viewer, I received "out of memory" error
I'll try again tomorrow.
(data -- ) send out serial data
sd_shift_out
( -- data) read in serial data
sd_shift_in
( -- ) sd-card initialize
sd_init
(address[hex] -- ) display 512byte[16column x 32row]
Block
(hex[0 .. c] -- decimal[1 .. 9 10 11 12])
month
( -- )display CID
cid
(hex[from 0 to 0x270f) -- decimal[from 0 to 9999])
to_decimal
(hex[from 1 to 0x270f) -- decimal[from .1 to 999.9])
to_decimal_dot
( -- )display CSD
CSD
( -- ) setting top address that save reading data(generally 512bytes) from SD-card
clear_buff_ptr
(address[hex] -- ) save reading data(generally 512bytes) from SD-card to buffer
block_read
( -- ) display information
collect_info
(hex -- decimal[M/k byte])
conversion
I check below: LED of P2 blink.
After LED is off, I check below; LED of P3 blink.
I execute to continue them. Only LED of P2 blink.
dira/outa for cog5 is separately them for cog4.
My idea is wrong?
jnext is defined in the forth assembler, file is asm.f
Yes, I think the error is the DIRA command. I believe the prop reference says that there is only one dira register that is common to all cogs and controls all pins. The way you are using it, it turns off all the others. For this case, you want to AND the current pins with the new pin
DIRA L@ 8 AND DIRA L!
or something to that affect.
PLEASE!!! STOP defining words in cogs other than the terminal using
c" : test 4 dira COG! 40 0 do 4 outa COG! 64 delms 0 outa COG! 64 delms loop ; " 5 cogx
Please understand that when you define a word in the dictionary from ANY cog, it all goes into the same dictionary. BUT the above method does not get to see any errors or status, and it makes it hard to debug.
sd_func_1.0.txt loads, but gives the erros I mentioned.
sd_viewer_1.0.txt does not finish loading, it get the error
MBR NOT DEFINED
I think I have old versions.
Could you post or send your latest version?
Does NOT Hive-board work word'sd_init'(sd_func or sd_func_1.0)?
I checked sd_viewer on proto board.(not using vga)
Do you have proto board?
I make sd_init's test-code.
I will post it later.
Loading 1st:sd_func_1.0 2nd:fat_1.0 3rd:sd_viewer_1.0
I ordered HIVE board, too.
Yes, drohne235 told me your order arrived in time. Welcome to Hive. You will be assimilated.
I did not load the fat_1.0, I will try that next chance.
I am using Hive Regnatix propchip, no vga, regular Propforth3.5e kernel.
I do have a protoboard, I'll try to get that wired to a socket on the weekend.
A friend here is also going to build a Hive unit and wants to join the propforth team, we might make better progress when he joins.
I updated to PropForth3.5e.
But message is "PROPELLER REBOOT PropForth v3.5c 20101017 15:30 0".
I make sd_func_1.0_test.
Loading sd_func_1.0_test.
(please chage number for _sd_cs/_sd_di/_sd_clk/_sd_do)
Executing word"sd_init", please check messages.
I attached log_sdinit.
I checked 4G/2G/512M.
If ok, loading 1st:sd_func_1.0_test or sd_func_1.0 2nd:fat_1.0 3rd:sd_viewer_1.0
executing "viewer".
I did experiments.
I copy/paste codes from TeraTerm.
Executing below:
I think 3 LED shoud be Off.
Why is LEDs on?
What you are trying to do with defining test three times? Aaaargh! The explanation for cogx must be wrong, I will try to re-write it. The definition for all forth words is exactly the same for all cogs 0 through seven. Only the last definition for any words will be called from the command prompt. The earlier definitions of test are hidden by the most recent one.
Please Eliminate the definitions you are sending to cog5 and cog4.
This is what I would do:
Write the word "test" so that is accepts two parameters: "number of blinks" and "out pin".
Define the word exactly once. Do not fool your yourself by re-defining it on different cogs.
Demonstrate that the word test works from the console cog for each led and for varying numbers of blinks with no stack error.
Send the parameters and test word to running forth cogs where each cogs gets a different pin and a different number of blinks.
( x1 x2 -- x1 ) --> ( x1 x2 -- x2 )
About coment on PropForth.spin:
main memory:
So using c@ with an empty stack will return a value and not trigger stack checking. However c! with an empty stack will trigger a stack underflow.
I think it is correct below:
So using c! with an empty stack will return a value and not trigger stack checking. However c@ with an empty stack will trigger a stack underflow.
My idea is wrong?
I have question.
Where does word "here" define?
I cannot find out it in PropForthPart1/PropForthPart2.
>> ( x1 x2 -- x1 ) --> ( x1 x2 -- x2 )
We'll look at this in today's call
>> About coment on PropForth.spin:
>> main memory:
>>So using c@ with an empty stack will return a value and not trigger stack checking. However c! with an empty stack will trigger a stack underflow.
The FIRST item on the stack is BUFFERED, so the stack over/under flow is not activated on items that only use the top location of the stack.
HOWEVER, most cases eventually use an additional item and the stack checking gets triggered. The cost of stack checking on the first item would add additional code size and code execution time for all items. The decision was made to keep it small and simple. So far this has not been a problem, just something to be aware of. If it gives you problems we can look at the situation, but its probably better to just be aware
>> I think it is correct below:
So using c! with an empty stack will return a value and not trigger stack checking. However c@ with an empty stack will trigger a stack underflow.
>>My idea is wrong?
Your idea is correct. Just be aware that the FIRST STACK ITEM IS BUFFERED and the under/over flow checking is NOT triggered until another stack operation takes place.
>>> I have question.
>>> Where does word "here" define?
>>> I cannot find out it in PropForthPart1/PropForthPart2.
I think "here" is defined in the assembler code in PROPFORTH.SPIN
The dictionary structure, the threading model, and something else (I think the console I/O) are initially defined directly in spin assembler
That is the explanation of the c_<**labelname**> entries in the bottom of the dictionary. I'm a little hazy about what is going on down there,
but basically that stuff is the transition from non-forth spin assembler to the forth kernel. I think those labels are only called by the spin compiler and serve to set up forth.
I'll ask about that today in as my understanding is incomplete.
UPDATE -- see follow up post further down
opened issue #13, should be in next release
Thanks caskaz
Thanks for the question. This has been added to the FAQ:
OK, there are three words that are defined and set in propforth.spin instead of PropForthpart1.f and propforthpart2.f
These are
These can't be easily re-defined while forth is running, it is very dangerous and things tend to go crazy. Sal had to do it several times and had problems, so these ended up like this.
These three words are the absolute beginning of the forth kernel. Once the kernel began, memory access was added, the variables, then colon definitions, eventually it got to the point where ther was enough defined that the preliminary stuff could be removed, and there was enough to make a working forth kernel from forth.
The spin tool is used to create the forth kernel from spin code. Normally in a native forth, the forth system is used to create itself from scratch without the use of external tools (a pc and non forth compiler for example). The decision was made NOT to do this at this time for propforth.
Using the SPIN tool as the starting point for propforth has two main advantages:
1) it is relatively easy to bring in or interface to spin and assembly objects
2) the spin tool takes care of any forward references (which usually require special handling during forth kernel build).
So, the definitions for here, dictend, and memend are first in the forth dictionsary. Do "words" whcih prints out the dictionary reverse order, and these are the very last to print.
These words are defined and values assigned in Propforth.spin at around line 165.
here is pretty much always 0D72 to start with, although it does automatically adjust itself as shown in the HiResVGA versions.
Thanks details about my question.
I understand reasons 3 word are defined on PropForth.spin to read your post.
Still incorrect inside PropForthStatus on Wiki.
Planned PropForth 3.7 December 2010/January 2022 --> December 2010/January 2011
Got it thanks!
I did experiment.
Although transmitting data to Cog4, this is correct way?
Cog6 ok cog? Forth cogs: 0 - 6 Running Forth cogs: 5 - 6 Spin cogs: NONE Cog6 ok variable OUTA Cog6 ok : test 0 dira COG! dira COG! 40 0 do dup dup OUTA L@ or dup OUTA L! outa COG! 64 delms OUTA L@ xor dup OUTA L! outa COG! 64 delms loop driop ; Cog6 ok 0 cogreset COG 0 RESET - last status: ok Cog6 ok 1 cogreset COG 1 RESET - last status: ok Cog6 ok 2 cogreset COG 2 RESET - last status: ok Cog6 ok 3 cogreset COG 3 RESET - last status: ok Cog6 ok 4 cogreset COG 4 RESET - last status: ok Cog6 ok 0 _fcog W! Cog6 ok c" 4 4 test" 0 cogx <-- blinking LED connected to P2 Cog6 ok c" 8 8 test" 1 cogx <-- blinking LED connected to P3 Cog6 ok c" 10 10 test" 2 cogx <-- blin ing LED connected to P4 Cog6 ok c" 20 20 test" 3 cogx <-- blinking LED connected to P5 Cog6 ok c" 40 40 test" 4 cogx <-- blinking LED connected to P6 Cog6 ok 80 80 test <-- blinking LED connected to P7What does _fcog do?
Everything else looks right. So now they all blink independently?
Excellent.
I still haven't gotten to SD yet, sorry to keep you waiting, still busy here.
_fcog is valid (first forth) cog.
_fcog W@ wvariable _fcog _fcog W!
Cog6 ok variable OUTA Cog6 ok : test 0 dira COG! dira COG! 40 0 do dup dup OUTA L@ or dup OUTA L! outa COG! 64 delms OUTA L@ xor dup OUTA L! outa COG! 64 delms loop driop ; Cog6 ok cog+ COG 4 RESET - last status: ok Forth cogs: 0 - 6 Running Forth cogs: 4 - 6 Spin cogs: NONE Cog6 ok c" 40 40 test" 4 cogx <-- blinking LED connected to P6 Cog6 ok 80 80 test <-- blinking LED connected to P7Please check sd_viewer later when you have much time.
{ ----------------------------------------------------------------------------------------- display all defined word's name on dictionary (1st: lastest word last: first word) ----------------------------------------------------------------------------------------- } wvariable tmp : to_decimal 0 tmp W! 3e8 swap over 4 0 do u/mod dup 0> if 1 tmp W! .hex else tmp W@ if 0> .hex else drop then then swap a / swap over loop 3drop ; : disp_all_word 0 wlastnfa W@ begin swap 1+ dup to_decimal ." : " swap dup \ dup C@ 1f and 0 do 1+ dup C@ emit loop drop cr \ namelen 0 do dup C@ emit 1+ loop drop cr \ same as above .strname cr \ same as above nfa>next dup 0= until 2drop ;I found out very little mistake on PropForth.spin.
\ lockclr (n1 -- n2) set lock n1...........the lock was set ... --> clear lock n1 .... the lock was clear ...
: checkdict here W@ + dictend W@ >=
if cr here W@ . dictend . _eoom clearkeys reset then ; --> if cr here W@ . dictend W@ . _eoom clearkeys reset then ;
And one more on end of Propforth.spin
Assembler's part of PropForth.spin
:
:
cogdataPFA
:
:
{{
Start of the Forth Dictionary
:
:
- bit 4 ($20) set if it is an eXecute word ---> bit 5 ($20) set if it is an eXecute word
:
}}
ForthDictiStart
: