I said in my notes that par points to the pad area.
Strickly speaking the par register points to the addr in Hub ram allocated to each cog. The pad area is offset
Par + 18, see the offset table below. This was the case in PF4.0, I don't think anything it as changed since PF4.0 in that regard but I have not checked all these offsets out in PF4.6. I only look at these sort of things when I need to.
Ron
+0 > addr of the channel io
+4 > (word) not assigned
+6 > debugcmd
+8 > debugvalue addr
+C > (word) Base value addr
+E > (word) coghere
+10 > exicute addr
+14 > out>
+16 > in>
+18 > the start of the pad area proper padsize = 80
+98 > t0
+9a > t1
+9c > tbuf 32 bytes, but overflows into numpad
Your document is helpful for me because I'm just going to make adc.
But it seems assembler code don't work.
I have no idea.
Do you have idea where is wrong code?
I use generated kernel by PropForthKernel.spin.
It don't involve ctra/frqa/phsa.
I defined "result v_result COG!" inside WORD"sigma_delta".
I think register"v_result" inside Cog5 has result's address in HUB-ram.
I think my idea is wrong because code don't work.
All my idea or pieces is wrong?
I cannot understand them.
Hi cas
You are correct ctra/frqa/phsa are not defined in PF4.0 +. They were dropped from PF3.5.
You will have to define them below the :asm word like so
v_ctra
1f8
v_frqa
1fa
v_phsa
1fc
I will look the asm code tonight.
You cannot write to v_result from forth, it is defined a wconstant. You should pass a variable indirectly via par.
The reason for using par wrlongs are relative to the hub adr allocated to the current cog. So you can run the code in any code and it
is thread safe
About your forthasm document.
1. Temporary storage registers are _treg1 to _treg6.
2. asm.f cannot use "call". I think because "call" is subset of "jmpret".
: blink
16 17 pinout pinout
8 0 do
16 17 pinhi pinlo \ red
150 delms
16 17 pinlo pinhi \ green
150 delms
loop ;
blink
\ I do have a problem with this.
\ I have a dual color led connected to pin 16 and pin 17.
\ When pin 16 is low and pin 17 is hi the color is red.
\ When pin 16 is hi and pin 17 is low the color is green.
\ When loading is finished, it blinks and stop with the green color on.
\ At this point all seems right.
\ But when I use the "word" blink again, only the green color works.
\ When I do a "0 cogreset" and use "blink" again both color blink as they must.
\ so I looked at the word "fl" and changed it to the next :
\
\ fl ( -- ) buffer the input and route to a free cog
: fl
lockdict fl_lock W@
if
freedict
else
-1 fl_lock W! cogid nfcog dup >r iolink freedict
(fl)
cogid iounlink
0 fl_lock W!
r> swap
cr . ." characters overflowed" cr
cogreset
then
;
\ There was also another problem :
\ when this sequence is executed:
cogreset
cr . ." characters overflowed" cr
\ it writes only this "characters overfl" then the cog is reset.
Hi Poul. Thanks for trying out propforth and giving feedback, it is rare and highly valued.
Remember, you need to reset the prop when you are done developing, and reload the "correct" version of your program on a freshly rebooted prop.
Experiments, particularly ones that need further modification, always leave registers and the stacks messed up.
When you get the code right, reset the prop and reload your source code. It have found it useful to execute "reboot" when something acts funny, and if it still acts funny, do a power cycle. If that doesn't clear it up, my code still has an error.
Also, the fl command buffers the source text to unused hum ram, and another cog interprets it. Don't try to buffer too much text at once (load several short definitions instead of one long text file. If you reset individual cogs, you might confuse the kernel if it reliying on them to be in a certain state, as when loading source text. Its a bit complicated and not properly documented yet, Ron and Caskaz are the experts to ask. If you havcve specific questions or run into problems we can open issues; but the fl routine has been pretty solid for a while now. I would be worried if your found a new problem after so long.
Prop0 Cog6 RESET - last status: 0 ok
Prop0 Cog6 ok
#2 Then I copy the next lines into the tera term.
fl
16 pinout
16 pinhi
#3 And get this.
fl
Prop0 Cog0 ok
16 pinout
Prop0 Cog0 ok
16 pinhi
Prop0 Cog0 ok
Prop0 Cog6 ok
#4 It says that cog0 is doing the job.
#5 Now when it is back with cog6 I cant get the led off.
#6 Yes, I use 16 pinout and 16 pinlo, but it dos not work,
because the output is set in cog0, and it was not reset.
#7 When I do a 0 cogreset, the led goes off.
#8 That was because of this, I chanced the fl word.
I believe the results you are seeing are due to the nature of the Propeller I/O pins and not related to PropForth at all. You could create similar results in any language.
The DIRA registers for the COGs are OR'd together and if ANY COG has a pin set to OUTPUT( HIGH), then the pin is an OUTPUT.
The OUTA registers for the COGs are OR'd together and if ANY COG has a pin set to HIGH, then that pin is HIGH.
The only way to get a PIN to OUTPUT a LOW is to have ALL COGs set the pin LOW.
The only way to get a PIN to be INPUT is to have ALL COGs set the bit LOW.
This is from page 8 of the Propeller datasheet, section 4.5
My Forth is rusty and my mind went blank .....there's a word to send a word to be executed on another COG (somebody, help and old guy out!), you could use that or something like:
Yes this output from 4.6 is very mis-leading, infact its a bug, which I think occurs when the SDdriver has been initialized. Unless you have changed the current cog you are if fact in cog 6.
I think that you must have an Sdcard running. Remove the Sdcard and reboot without the SDcard and try your LED blinker again or try your Led Blinker on another pin. I agree with Rick, about the wired Prop I/O but the reporting error does suggest the SDcard driver is running. I have my Sdcard on pins 0..4
but know of others that use pins 16
Lets know how you get on.
Ron
#3 And get this.
fl
Prop0 Cog0 ok
16 pinout
Prop0 Cog0 ok
16 pinhi
Prop0 Cog0 ok
Hi Poul
I chatted with Prof today and I did raise the question about why Propfoth reports Prop0 cog0
during compilation when the current cog is 6. I do think this is very confusing, but I think that what the author would say is that cog0 is communicating with the SDsystem and that the code you have pasted and is currently being compiled has not affected cog0 so it reports cog0 Ok. In other words, all Cogs which are actively processing forth definitions will be reported after the compilation of a new definition by the current cog6.
I think that's the conclusion that we came to, but it will get raised with the author SAL.
I just hope you are now less confused.
It's confusing but it is accurate as to what the interpreter is doing, I don't completely understand it but here goes....
The fl word is defined as:
\ fl ( -- ) buffer the input and route to a free cog
One of the early things it does is to connect the input link of the cog your are on (6) to the input link of the first free cog it finds (in this case, 0). It also links the output link cog 6 had (pointing to the serial output) to the COG 0 output link. At this point, it gets fuzzy because I don't fully understand the buffering word (fl) but both cogs see the same input and output except the input is being buffered into HUB RAM by COG6 as fast as it can go and being read out of the buffer as fast as COG0 can read it and interpret and compile it. If you had already started forth word on COG0 (with cogx for example), you would see the "PROP0 COGn" message from some other cog, 1 through 5.
So, why do we see the output we see?
The (fl) word running on COG6 doesn't create any output, COG0 is running the interpreter and compiler and processing the input stream as fast as it can, echoing its compiling results just as if you were typing it in at the terminal. The interpreter loop in fstart emits a new prompt as it processes each line using the current COGID and PROPID. Since the outputs of the two cogs are pointing to the same place (serial I/O), we see all the output from the fstart interpret/compile loop who's current COG is 0.
COG6 isn't doing anything interesting but if it had output, you would see it too. It would just be mixed in with COG0 output since there isn't anything to mark it by COGID in the (fl) word. A color console with each cog using a different color text would be a fun project....but I distract myself!
Once (fl) finishes, it unlinks the I/O for the two COGs.
Now back to why the pins are left set. This is explained in my earlier post. Your script ended leaving DIRA set for output on pin 16 (HIGH bit 16) and left OUTA with bit 16 set HIGH. The two registers are OR'd across ALL the COGS and whichever bits are set WIN!
This is all valid and working as designed, I believe. You get to see the results from the input stream you added, you can leave a word running in COG0 (I believe) and COG6 gets control back when it's ready to do more interpreting.
The IO channels and links are an interesting and useful implementation detail Sal put in. Fun to play with and appear to provide some amazing power if you understand them. I don't understand them, yet.
You guys keep this up and you're going to make me start playing with Propforth again BEFORE 5.0 comes out! ....I wonder if I have a Prop board at work with me today?
Cog 6 is the one the developer is talking to, cog 0 is the one talking to the SD card.
BUT Hey you might be right, you got me thinking about this, fl certainly routes it to the next free cog.
but its only using cog0 ram, or is it? Hmm.. cog6 is running fl cog0 is compiling......is it?
I have to look at this .
Rick has is correct. Our cog executes fl and starts buffering to ram. This eliminates the need to increase the scratch area beyond the typical 80 bytes.
Linking the interfaces is kung-fu panda awesomeness, and turns out to be much more powerful than we thought. The problem is that it gets complicated for new users, this is why we are bumbling with the documentation for so long. We might be at the point where the documentation stops making it better, and ends up making it worse; perhaps we are moving on the X-Y plane but improvement lies in the Z direction.
Should we just let 5.0 out, and let you guys drive the documentation process with your questions and answers?
As offered before, I'd be happy to assist with the documentation in my Spare time. I had started and then stopped because of the major changes to PF5.0 coming Any Day Now.
If we have MORE Kung Fu Panda awesomeness, then let it out! The Belivers can get to know it and write of it while they answer question for the converts!
Don't be embarrassed, the only reason I became so intimate with the iolinks was when I knew nothing about Forth and refused to give up one day when the SD regression test was driving me nuts. It was a very stubborn day of reading through the Kernal trying to make sense out of something. Now I've graduated to knowing next to nothing about Forth!!
By the way.....RELEASE 5.0!!!!! ....I may have already said that!
Comments
Attached are a few notes on Getting Started with PF assembler.
@caskaz et al
If there are things that should be added please let me know
Ron
Thank you! Will let you know how it goes.
Bob
I said in my notes that par points to the pad area.
Strickly speaking the par register points to the addr in Hub ram allocated to each cog. The pad area is offset
Par + 18, see the offset table below. This was the case in PF4.0, I don't think anything it as changed since PF4.0 in that regard but I have not checked all these offsets out in PF4.6. I only look at these sort of things when I need to.
Ron
+0 > addr of the channel io
+4 > (word) not assigned
+6 > debugcmd
+8 > debugvalue addr
+C > (word) Base value addr
+E > (word) coghere
+10 > exicute addr
+14 > out>
+16 > in>
+18 > the start of the pad area proper padsize = 80
+98 > t0
+9a > t1
+9c > tbuf 32 bytes, but overflows into numpad
I will add these offsets to the notes
Ron
Your document is helpful for me because I'm just going to make adc.
But it seems assembler code don't work.
I have no idea.
Do you have idea where is wrong code?
There is original code(spin) on AN001: Propeller P8X32A Counters page17(http://www.parallaxsemiconductor.com/appnotes).
fl hex 8 wconstant adcpin 9 wconstant fbpin c wconstant bits variable result \ aallot ( n1 -- ) add n1 to coghere, allocates space in the cog or release it, n1 is # of longs [ifndef aallot : aallot coghere W+! coghere W@ par >= if 10 ERR then ; ] \ cog, ( x -- ) allocate 1 long in the cog and copy x to that location [ifndef cog, : cog, coghere W@ COG! 1 aallot ; ] \ lasm ( addr -- ) expects an address pointing to a structure in the following form \ empty long, long upper address of the assembler routine, long lower address of the assembler routine \ a series of longs which are the assembler codes [ifndef lasm : lasm 4+ dup L@ swap 4+ swap over L@ dup coghere W! do 4+ dup L@ cog, loop drop ; ] 152 asmlabel a_entry 151 wconstant v_result 150 wconstant v_asm_dira 14F wconstant v_asm_cycles lockdict variable def_014F 015F l, 014F l, 0 l, 0 l, 0 l, A0BFED50 l, 50BFF008 l, 54BFF009 l, 58FFF048 l, A0FFF401 l, A0BE13F1 l, 80BE134F l, F8BE134F l, A0BE15FC l, 84BE150B l, 80BE170A l, 083E1551 l, 5C3C0159 l, freedict : sigma_delta \ A/D start 1 bits lshift 1- v_asm_cycles COG! 1 fbpin lshift v_asm_dira COG! result v_result COG! def_014F lasm a_entry ; : adc c" sigma_delta" 5 cogx 100 0 do result L@ . cr 64 delms loop ; { fl hex 8 wconstant adcpin 9 wconstant fbpin 1f8 constant ctra 1fa constant frqa 1fc constant phsa :asm v_asm_cycles 0 v_asm_dira 0 v_result 0 a_entry mov dira , v_asm_dira movs ctra , adcpin movd ctra , fbpin movi ctra , # 48 mov frqa , # 1 mov _treg1 , cnt add _treg1 , v_asm_cycles __1 waitcnt _treg1 , v_asm_cycles mov _treg2 , phsa sub _treg2 , _treg3 add _treg3 , _treg2 wrlong _treg2 , v_result jmp __1 ;asm decimal }your code below with changes. look closely at how I to use par + offset to write the result to Hub
fl hex XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXx 8 wconstant adcpin remove and define inside :ASM see my change 9 wconstant fbpin remove and define inside :ASM see my change 1f8 constant ctra not required already defined in Forth and PASM 1fa constant frqa not required already defined in Forth and PASM 1fc constant phsa not required already defined in Forth and PASM XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX :asm v_adcpin 8 v_fbpin 9 v_asm_cycles 0 v_asm_dira 0 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX v_result You are writing phsa to hub location 0 0 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX a_entry mov dira , v_asm_dira movs ctra , adcpin movd ctra , fbpin movi ctra , # 48 mov frqa , # 1 mov _treg1 , cnt add _treg1 , v_asm_cycles __1 waitcnt _treg1 , v_asm_cycles mov _treg2 , phsa sub _treg2 , _treg3 add _treg3 , _treg2 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX wrlong _treg2 , v_result see my note in v_result, XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX jmp __1 ;asm decimal }ron
Thanks for your reply.
I use generated kernel by PropForthKernel.spin.
It don't involve ctra/frqa/phsa.
I defined "result v_result COG!" inside WORD"sigma_delta".
I think register"v_result" inside Cog5 has result's address in HUB-ram.
I think my idea is wrong because code don't work.
All my idea or pieces is wrong?
I cannot understand them.
You are correct ctra/frqa/phsa are not defined in PF4.0 +. They were dropped from PF3.5.
You will have to define them below the :asm word like so
v_ctra
1f8
v_frqa
1fa
v_phsa
1fc
I will look the asm code tonight.
You cannot write to v_result from forth, it is defined a wconstant. You should pass a variable indirectly via par.
The reason for using par wrlongs are relative to the hub adr allocated to the current cog. So you can run the code in any code and it
is thread safe
Ron
Ron
Definition for ctra/frqa/phsa need only assemling source-code.
So I think v_ctra/v_frqa/v_phsa don't need.
My idea;
1.Assembled v_result as variable
2.result v_result COG! inside WORD"sigma_delta" is defined v_result as address for result by COG!
Maybe 2 is wrong.
But I don't have idea why is it wrong.
It's solved.
fl hex 8 wconstant adcpin 9 wconstant fbpin c wconstant bits variable result \ aallot ( n1 -- ) add n1 to coghere, allocates space in the cog or release it, n1 is # of longs [ifndef aallot : aallot coghere W+! coghere W@ par >= if 10 ERR then ; ] \ cog, ( x -- ) allocate 1 long in the cog and copy x to that location [ifndef cog, : cog, coghere W@ COG! 1 aallot ; ] \ lasm ( addr -- ) expects an address pointing to a structure in the following form \ empty long, long upper address of the assembler routine, long lower address of the assembler routine \ a series of longs which are the assembler codes [ifndef lasm : lasm 4+ dup L@ swap 4+ swap over L@ dup coghere W! do 4+ dup L@ cog, loop drop ; ] 154 asmlabel a_entry 153 wconstant v_result 152 wconstant v_asm_dira 151 wconstant v_asm_cycles 150 wconstant v_fbpin 14F wconstant v_adcpin lockdict variable def_014F 0161 l, 014F l, 0 l, 0 l, 0 l, 0 l, 0 l, A0BFED52 l, 50BFF14F l, 54BFF150 l, 58FFF048 l, A0FFF401 l, A0BE13F1 l, 80BE1351 l, F8BE1351 l, A0BE15FC l, 84BE150B l, 80BE170A l, 083E1553 l, 5C3C015B l, freedict : sigma_delta \ A/D start def_014F lasm adcpin v_adcpin COG! fbpin v_fbpin COG! 1 bits lshift 1- v_asm_cycles COG! 1 fbpin lshift v_asm_dira COG! result v_result COG! a_entry ; : adc c" sigma_delta" 5 cogx 100 0 do result L@ . cr 64 delms loop ; { fl hex 1f8 constant ctra 1fa constant frqa 1fc constant phsa :asm v_adcpin 0 v_fbpin 0 v_asm_cycles 0 v_asm_dira 0 v_result 0 a_entry mov dira , v_asm_dira movs ctra , v_adcpin movd ctra , v_fbpin movi ctra , # 48 mov frqa , # 1 mov _treg1 , cnt add _treg1 , v_asm_cycles __1 waitcnt _treg1 , v_asm_cycles mov _treg2 , phsa sub _treg2 , _treg3 add _treg3 , _treg2 wrlong _treg2 , v_result jmp __1 ;asm decimal }You have success ! You have solves a puzzle for me too.
I was never successful in passing variables the way you have done it from Forth to a cog running Pasm.
I always passed the variable by par reference, but yours is a much better way.
I must add this method to my documentation.
Can I add use your code for another example in my documentation ?
(sighting your name)
Ron
I had made another code on 2_wire_LCD.
a_clk_out output clock-pulses(1usec) by number on datastack.
a_reset output reset-pulse(100usec).
Both use macro-code"jnext".
fl :asm v_clk 0 __Ddelay mov _treg5 , # 10 __C djnz _treg5 , # __C __Edelayret ret a_clk_out __1 or outa , v_clk jmpret __Edelayret , # __Ddelay andn outa , v_clk jmpret __Edelayret , # __Ddelay djnz _sttos , # __1 spop jnext a_reset or outa , v_clk mov _treg6 , # 64 __11 jmpret __Edelayret , # __Ddelay djnz _treg6 , # __11 andn outa , v_clk jnext ;asmI will add the macro info to the notes at some stage, because they are specifically ProForth Macros.
When I first saw them in Sal's SDdriver code, they caught me by surprise.
I had to look at the asm source to work them out. There is no other way to know that they even they exist.
Ron
About your forthasm document.
1. Temporary storage registers are _treg1 to _treg6.
2. asm.f cannot use "call". I think because "call" is subset of "jmpret".
Thanks for the feedback and catching the error, I will change _treg7 to _treg6.
Maybe I should not use "call" I will change it from " call to the the Forth loader" to "uses the Forth loader"
I will attach updated file here, check later today.
Ron
: blink
16 17 pinout pinout
8 0 do
16 17 pinhi pinlo \ red
150 delms
16 17 pinlo pinhi \ green
150 delms
loop ;
blink
\ I do have a problem with this.
\ I have a dual color led connected to pin 16 and pin 17.
\ When pin 16 is low and pin 17 is hi the color is red.
\ When pin 16 is hi and pin 17 is low the color is green.
\ When loading is finished, it blinks and stop with the green color on.
\ At this point all seems right.
\ But when I use the "word" blink again, only the green color works.
\ When I do a "0 cogreset" and use "blink" again both color blink as they must.
\ so I looked at the word "fl" and changed it to the next :
\
\ fl ( -- ) buffer the input and route to a free cog
: fl
lockdict fl_lock W@
if
freedict
else
-1 fl_lock W! cogid nfcog dup >r iolink freedict
(fl)
cogid iounlink
0 fl_lock W!
r> swap
cr . ." characters overflowed" cr
cogreset
then
;
\ There was also another problem :
\ when this sequence is executed:
cogreset
cr . ." characters overflowed" cr
\ it writes only this "characters overfl" then the cog is reset.
Sincerely
Poul
I have just hooked up two LEDS on pins 16 17 and your code works fine. I have entered the word blink a few times and it works Ok.
You have changed fl to next what ???
Always leave a couple of lines between fl and the start of your code.
The the error on for cr . ." line is because you have a cr dot dot and there is nothing on the stack. Dot will pop top of stack and emit to console
Ron
Remember, you need to reset the prop when you are done developing, and reload the "correct" version of your program on a freshly rebooted prop.
Experiments, particularly ones that need further modification, always leave registers and the stacks messed up.
When you get the code right, reset the prop and reload your source code. It have found it useful to execute "reboot" when something acts funny, and if it still acts funny, do a power cycle. If that doesn't clear it up, my code still has an error.
Also, the fl command buffers the source text to unused hum ram, and another cog interprets it. Don't try to buffer too much text at once (load several short definitions instead of one long text file. If you reset individual cogs, you might confuse the kernel if it reliying on them to be in a certain state, as when loading source text. Its a bit complicated and not properly documented yet, Ron and Caskaz are the experts to ask. If you havcve specific questions or run into problems we can open issues; but the fl routine has been pretty solid for a while now. I would be worried if your found a new problem after so long.
CON:Prop0 Cog0 RESET - last status: 0 ok
CON:Prop0 Cog1 RESET - last status: 0 ok
CON:Prop0 Cog2 RESET - last status: 0 ok
CON:Prop0 Cog3 RESET - last status: 0 ok
CON:Prop0 Cog4 RESET - last status: 0 ok
CON:Prop0 PROP REBOOT PropForth v4.5 2011JUL25 7:10 0
CON:Prop0 Cog5 RESET - last status: 0 ok
CON:Prop0 Cog6 RESET - last status: 0 ok
Prop0 Cog6 RESET - last status: 0 ok
Prop0 Cog6 ok
#2 Then I copy the next lines into the tera term.
fl
16 pinout
16 pinhi
#3 And get this.
fl
Prop0 Cog0 ok
16 pinout
Prop0 Cog0 ok
16 pinhi
Prop0 Cog0 ok
Prop0 Cog6 ok
#4 It says that cog0 is doing the job.
#5 Now when it is back with cog6 I cant get the led off.
#6 Yes, I use 16 pinout and 16 pinlo, but it dos not work,
because the output is set in cog0, and it was not reset.
#7 When I do a 0 cogreset, the led goes off.
#8 That was because of this, I chanced the fl word.
I'm Danish, so excuse my English.
Sincerely
Poul
I believe the results you are seeing are due to the nature of the Propeller I/O pins and not related to PropForth at all. You could create similar results in any language.
The DIRA registers for the COGs are OR'd together and if ANY COG has a pin set to OUTPUT( HIGH), then the pin is an OUTPUT.
The OUTA registers for the COGs are OR'd together and if ANY COG has a pin set to HIGH, then that pin is HIGH.
The only way to get a PIN to OUTPUT a LOW is to have ALL COGs set the pin LOW.
The only way to get a PIN to be INPUT is to have ALL COGs set the bit LOW.
This is from page 8 of the Propeller datasheet, section 4.5
My Forth is rusty and my mind went blank .....there's a word to send a word to be executed on another COG (somebody, help and old guy out!), you could use that or something like:
0 >con 16 pinlo 16 pinin 6 >con
to get the LED off
c" 16 pinlo 16 pinin " 0 cogx
Always a handy word if you forget to do something on another COG!
Yes this output from 4.6 is very mis-leading, infact its a bug, which I think occurs when the SDdriver has been initialized. Unless you have changed the current cog you are if fact in cog 6.
I think that you must have an Sdcard running. Remove the Sdcard and reboot without the SDcard and try your LED blinker again or try your Led Blinker on another pin. I agree with Rick, about the wired Prop I/O but the reporting error does suggest the SDcard driver is running. I have my Sdcard on pins 0..4
but know of others that use pins 16
Lets know how you get on.
Ron
I chatted with Prof today and I did raise the question about why Propfoth reports Prop0 cog0
during compilation when the current cog is 6. I do think this is very confusing, but I think that what the author would say is that cog0 is communicating with the SDsystem and that the code you have pasted and is currently being compiled has not affected cog0 so it reports cog0 Ok. In other words, all Cogs which are actively processing forth definitions will be reported after the compilation of a new definition by the current cog6.
I think that's the conclusion that we came to, but it will get raised with the author SAL.
I just hope you are now less confused.
Cheers
Ron
The fl word is defined as:
\ fl ( -- ) buffer the input and route to a free cog
One of the early things it does is to connect the input link of the cog your are on (6) to the input link of the first free cog it finds (in this case, 0). It also links the output link cog 6 had (pointing to the serial output) to the COG 0 output link. At this point, it gets fuzzy because I don't fully understand the buffering word (fl) but both cogs see the same input and output except the input is being buffered into HUB RAM by COG6 as fast as it can go and being read out of the buffer as fast as COG0 can read it and interpret and compile it. If you had already started forth word on COG0 (with cogx for example), you would see the "PROP0 COGn" message from some other cog, 1 through 5.
So, why do we see the output we see?
The (fl) word running on COG6 doesn't create any output, COG0 is running the interpreter and compiler and processing the input stream as fast as it can, echoing its compiling results just as if you were typing it in at the terminal. The interpreter loop in fstart emits a new prompt as it processes each line using the current COGID and PROPID. Since the outputs of the two cogs are pointing to the same place (serial I/O), we see all the output from the fstart interpret/compile loop who's current COG is 0.
COG6 isn't doing anything interesting but if it had output, you would see it too. It would just be mixed in with COG0 output since there isn't anything to mark it by COGID in the (fl) word. A color console with each cog using a different color text would be a fun project....but I distract myself!
Once (fl) finishes, it unlinks the I/O for the two COGs.
Now back to why the pins are left set. This is explained in my earlier post. Your script ended leaving DIRA set for output on pin 16 (HIGH bit 16) and left OUTA with bit 16 set HIGH. The two registers are OR'd across ALL the COGS and whichever bits are set WIN!
This is all valid and working as designed, I believe. You get to see the results from the input stream you added, you can leave a word running in COG0 (I believe) and COG6 gets control back when it's ready to do more interpreting.
The IO channels and links are an interesting and useful implementation detail Sal put in. Fun to play with and appear to provide some amazing power if you understand them. I don't understand them, yet.
You guys keep this up and you're going to make me start playing with Propforth again BEFORE 5.0 comes out!
Cog 6 is the one the developer is talking to, cog 0 is the one talking to the SD card.
BUT Hey you might be right, you got me thinking about this, fl certainly routes it to the next free cog.
but its only using cog0 ram, or is it? Hmm.. cog6 is running fl cog0 is compiling......is it?
I have to look at this .
Ron
I will remain embarrassed all day.
Ron
For color coded output on the terminal interface, there is an extension for ANSI escape code http://en.wikipedia.org/wiki/ANSI_escape_code in the extensions file ANSI.f extension file http://propforth.googlecode.com/files/ANSI%20Escape%20Sequences20101227-1535.f, and these have not been optimized for paging yet so would increase the dictionary by a few bytes, but this is to be taken care of in the PF5.0
Linking the interfaces is kung-fu panda awesomeness, and turns out to be much more powerful than we thought. The problem is that it gets complicated for new users, this is why we are bumbling with the documentation for so long. We might be at the point where the documentation stops making it better, and ends up making it worse; perhaps we are moving on the X-Y plane but improvement lies in the Z direction.
Should we just let 5.0 out, and let you guys drive the documentation process with your questions and answers?
If we have MORE Kung Fu Panda awesomeness, then let it out! The Belivers can get to know it and write of it while they answer question for the converts!
NickL
Don't be embarrassed, the only reason I became so intimate with the iolinks was when I knew nothing about Forth and refused to give up one day when the SD regression test was driving me nuts. It was a very stubborn day of reading through the Kernal trying to make sense out of something. Now I've graduated to knowing next to nothing about Forth!!
By the way.....RELEASE 5.0!!!!! ....I may have already said that!