caskaz said...
Hi.
In case of executing wrong code, finally massage is " Forth cogs: 0 - 6".
Actually proceeding cogs: 0 - 6?
The default propforth.spin starts with the spin interpreter in cog0. It loads an assembler routine which is that forth kernel running the serial driver in cog 7. It also starts a forth kernel on cog6. So you start out talking THROUGH the cog7 forth kernel running the serial driver TO the forth kernel running on cog6, although it appears as though you are talking directly to cog6.
If the running cog has an error, the forth kernel resets itself and starts another forth cog. Since you indicate that there are six forth cog running, I would guess that you have been running several words, and maybe there was an error, at least six times. So at this point there are actually cogs 0-6 running forth kernels that you can experiment with, and cog 7 handling the serial communications.
At this point, you might want to reboot the prop, and reload the words that you know are working correctly, and continue from that point.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
There are 10 types of people in the world,
Those who understand binary, and those who don't
Definition of ffcog is different. no : and ;.
I cannot understand word-ffcog.
ffcog call onself by ffcog?
Good question. This is an example of the chicken and egg problem when making a new version of forth using the running version of forth.
It is also an example of the author's personal coding style, and why we are reviewing and editing for clarity.
ffcog is a 2 byte variable that is a stoarge loaction for the number of the first forth cog. This variable will probably be renamed FirstForthCog
When the spinmaker runs, it makes code for the the currently running image. What you see here is part of the process of RE-DEFINING a new forth image on top of a running forth image.
In this case, I would re-format and comment it like this:
ffcog w@ \ get the current value stored in variable ffcog an put it on the stack
wvariable ffcog \ define a new variable ffcog to hold the number of the FirstForthCog in the new version of propforth
ffcog w! \ Store the number of the FirstForthCog of the currently running kernel that was left on the stack into
\ the new variable FirstForthCog that will exist in the next version, as generated by spinmaker
When all the definition of the new forth image are compiled and running, spinmaker is executed. IT gets all the (NEW) currently running words and makes code for them. It only sees the most recent definition of ffcog. This is what gets pasted into Propforth-template.spin
This is how the word ffcog is carried into the next iteration of the forth kernel in propforth
Now you might ask, "If spinmaker only sees the most recent definition, and ffcog is the same, why redefine it at all? Why not just leave the old version or ffcog and let spinmaker use that?" There could be a technical reason that this is necessary, or its possible this was done to account for the all words needed, or possibly it is simply unnecessary and can be removed. We will determine if it is needed and document why; or remove it, in the next review cycle.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
There are 10 types of people in the world,
Those who understand binary, and those who don't
Post Edited (prof_braino) : 6/20/2010 8:07:55 PM GMT
FYI - WE started the first pass of the next version of propforth. Propforth3.0 uses the standard names for the forth words implemented, as defined in DPANS94. The plan is to use long, descriptive names in the HAL (hardware application layer) words that implement the standard forth words on the prop. The plan also includes implementing a scheme such that the long names do not take up dictionary space on the prop.
So please bear with the cryptic names for a little bit longer. When the next version is done and documented, things should be much clearer.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
There are 10 types of people in the world,
Those who understand binary, and those who don't
The "Forth cogs: 5 - 6" message is displayed when cog7 (which is running the serial communications between the user terminal and a forth cog) starts and discovers which cogs are running forth. The default is that only cog6 is a forth cog. If there is an error, like a stack overrun/under-run, the cog with an error is reset and another cog is launched as a forth cog. The new forth cog is the diagnostic message that tells you something failed. This was done by the author as a convenience to whatever he was making at the time, and is still used to indicate something (unexpected) happened.
Your case is unusual in that it keeps repeating but does not add any more forth cogs. So it makes sense that it was a power issue. I will pass this on to Sal and put something in the FAQ.
So I also guess that you don't have a stock demo board nor a proto board. Can I log that propforth 2.7 has been successfully run on a properly assembled and powered PE kit?
tmaynard said...
While I'm pretty sure I have downloaded, compiled, and burned v2.7 of PropForth before ... I'm having problems now.
I downloaded a fresh copy (from code.google.com), compiled it with the Propeller Tool, and pressed F11 to burn the EEPROM.
When I connect to it with Tera Term (57600, 8-bit, 1-stop, no flow) it keeps saying:
prof_braino said...
So I also guess that you don't have a stock demo board nor a proto board. Can I log that propforth 2.7 has been successfully run on a properly assembled and powered PE kit?
Yes. I have the Propeller Education Kit -- PropStick USB version (although it doesn't differ from the DIP-40 version in any significant way). With the PEKit you are free to connect anything anywhere you like, but after completing the PEKit Labs (if you don't undo anything) you'll have LEDs on P4..P9, pushbuttons on P21..P23, and several other components scattered about the protoboard (piezo speakers, IR LED, potentiometers, etc.).
The whole shebang is powered by an external 9V battery, and that was the source of my problem. While the battery had sufficient charge to illuminate the Power LED, it seems it didn't have enough to drive the Prop, um, "properly." Switching to a wall-wart supply solved this (and several other) problems that surfaced recently.
Thanks for your input -- I was intrigued by the messages I was getting -- and I look forward to experimenting with PropForth.
Tom.
P.S. FWIW, I have defined a new helper word
: |< ( n -- )
1 swap lshift
;
But I haven't had time to study all the existing words so this may be redundant.
[noparse][[/noparse]EDIT: It is. The existing word >m does this.]
Comments
The default propforth.spin starts with the spin interpreter in cog0. It loads an assembler routine which is that forth kernel running the serial driver in cog 7. It also starts a forth kernel on cog6. So you start out talking THROUGH the cog7 forth kernel running the serial driver TO the forth kernel running on cog6, although it appears as though you are talking directly to cog6.
If the running cog has an error, the forth kernel resets itself and starts another forth cog. Since you indicate that there are six forth cog running, I would guess that you have been running several words, and maybe there was an error, at least six times. So at this point there are actually cogs 0-6 running forth kernels that you can experiment with, and cog 7 handling the serial communications.
At this point, you might want to reboot the prop, and reload the words that you know are working correctly, and continue from that point.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
There are 10 types of people in the world,
Those who understand binary, and those who don't
Good question. This is an example of the chicken and egg problem when making a new version of forth using the running version of forth.
It is also an example of the author's personal coding style, and why we are reviewing and editing for clarity.
ffcog is a 2 byte variable that is a stoarge loaction for the number of the first forth cog. This variable will probably be renamed FirstForthCog
When the spinmaker runs, it makes code for the the currently running image. What you see here is part of the process of RE-DEFINING a new forth image on top of a running forth image.
In this case, I would re-format and comment it like this:
ffcog w@ \ get the current value stored in variable ffcog an put it on the stack wvariable ffcog \ define a new variable ffcog to hold the number of the FirstForthCog in the new version of propforth ffcog w! \ Store the number of the FirstForthCog of the currently running kernel that was left on the stack into \ the new variable FirstForthCog that will exist in the next version, as generated by spinmakerWhen all the definition of the new forth image are compiled and running, spinmaker is executed. IT gets all the (NEW) currently running words and makes code for them. It only sees the most recent definition of ffcog. This is what gets pasted into Propforth-template.spin
This is how the word ffcog is carried into the next iteration of the forth kernel in propforth
Now you might ask, "If spinmaker only sees the most recent definition, and ffcog is the same, why redefine it at all? Why not just leave the old version or ffcog and let spinmaker use that?" There could be a technical reason that this is necessary, or its possible this was done to account for the all words needed, or possibly it is simply unnecessary and can be removed. We will determine if it is needed and document why; or remove it, in the next review cycle.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
There are 10 types of people in the world,
Those who understand binary, and those who don't
Post Edited (prof_braino) : 6/20/2010 8:07:55 PM GMT
So please bear with the cryptic names for a little bit longer. When the next version is done and documented, things should be much clearer.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
There are 10 types of people in the world,
Those who understand binary, and those who don't
I downloaded a fresh copy (from code.google.com), compiled it with the Propeller Tool, and pressed F11 to burn the EEPROM.
When I connect to it with Tera Term (57600, 8-bit, 1-stop, no flow) it keeps saying:
[code]
PropForth v2.7 2010MAY26 14:50 0
Cog6 o
The "Forth cogs: 5 - 6" message is displayed when cog7 (which is running the serial communications between the user terminal and a forth cog) starts and discovers which cogs are running forth. The default is that only cog6 is a forth cog. If there is an error, like a stack overrun/under-run, the cog with an error is reset and another cog is launched as a forth cog. The new forth cog is the diagnostic message that tells you something failed. This was done by the author as a convenience to whatever he was making at the time, and is still used to indicate something (unexpected) happened.
Your case is unusual in that it keeps repeating but does not add any more forth cogs. So it makes sense that it was a power issue. I will pass this on to Sal and put something in the FAQ.
So I also guess that you don't have a stock demo board nor a proto board. Can I log that propforth 2.7 has been successfully run on a properly assembled and powered PE kit?
The whole shebang is powered by an external 9V battery, and that was the source of my problem. While the battery had sufficient charge to illuminate the Power LED, it seems it didn't have enough to drive the Prop, um, "properly." Switching to a wall-wart supply solved this (and several other) problems that surfaced recently.
Thanks for your input -- I was intrigued by the messages I was getting -- and I look forward to experimenting with PropForth.
Tom.
P.S. FWIW, I have defined a new helper word
But I haven't had time to study all the existing words so this may be redundant.
[noparse][[/noparse]EDIT: It is. The existing word >m does this.]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
cat .sig > /dev/null
Post Edited (tmaynard) : 7/4/2010 10:07:02 PM GMT
Please see the thread for PropForth 3.2
You can download the new version as a complete archive from google code
http://code.google.com/p/propforth/
I will unsubscribe to this thread, if you have any questions on version 2.7 please send me a message directly.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
There are 10 types of people in the world,
Those who understand binary, and those who don't