I'm in the middle of our garden with an angry rototiller right now but I'd be happy to help with "fl" this weekend if I get play time. Documenting that is a good "how do I make a forth application" tutorial.
To your one question about forward references, Forth applications are built from the bottom up due to the basic way the compiler works. Since it compiles words as it reads input and builds threads of tokens in the dictionary for the new word it can only use words that already exist in the dictionary. This is why bottom up coding is key to forth and you can't do top down coding.
Another quirk you may have noticed I'd that you can't define word1, use it in word2 and then go back and redefine word1 and expect word2 to use the new word1....that sounds more confusing than it is.
I hadn't seen the behaviors you have with "fl" but then except for little stuff, I've only used "fl" to load up the code modules that come with PF.
If you could post one of your problem files, we can all play with it and help.
fl is one of those words that I am tangling with greatly.
I thought that I could create a project, pull it all together in a fastload file, set it in an Eeprom .f file and just load it at will.
Correct.
But it becomes very obvious that what I think fl does and what is wants are two very different things.
If you say so.
It seems that it will take curly bracket comments without any trouble, but balks at / comments due to some sort of parsing issue.
Can you give an example? It does not give me a problem.
It also seems that one needs to be sure to have the new words sequenced so that any new word does not refer to a yet to be defined word.
This is how all forths work all the time.
And one should investigate loading each word individually to debug specific word definition bugs before trying a global fast load.
Obvioulsy.
So far I have spent more than a week on debugging a couple of fast load files. I feel the feature is an important asset to PropForth, so maybe a style sheet and a list of DO's and DON'Ts is appropriate. Please provide input of what you might be worthy of inclusion.
While the index listing stack note is a little sparse,
9.1.213 fl
\ fl ( -- ) buffer the input and route to a free cog
this one is covered in detail in the manual that has always been there yet few read.....
6 PropForth Input/Output
6.1 Overview
A PropForth cog by default has ...
...
Recall >con from the getting started section, all it is doing is disconnecting and connection IO channels.
This is a very straightforward case. There are more complex uses which involve linking cogs.
The most common one is fl .
fl
\ a gratuitous comment
cogid st? drop
{
A comment block
}
cog?
<examples you really should read have been trimmed out>
fl takes the input it is receiving, strips out comments, and comment blocks, strips leading whitespace,
buffers it, and simultaneously send it to another cog to process. This allows PropForth to accept input
faster than it can interpret or compile it. So in this case we see cog 5 is now linked between cog 6 and cog 7.
Cog 7 is the serial driver, sends the characters received to cog 6 who strips out comments, does buffering,
and send the characters to cog 5, who does the actual processing of the input, and send it’s output to cog 7,
who buffers and transmits over the serial line.
That's pretty much all it does.
The simple answer is you need to debug your code before you put it in a file to be loaded from eeprom. This should not be a surprise.
Can you give an example? It does not give me a problem.
This is how all forths work all the time.
Obvioulsy.
While the index listing stack note is a little sparse,
9.1.213 fl
\ fl ( -- ) buffer the input and route to a free cog
this one is covered in detail in the manual that has always been there yet few read.....
6 PropForth Input/Output
6.1 Overview
A PropForth cog by default has ...
...
Recall >con from the getting started section, all it is doing is disconnecting and connection IO channels.
This is a very straightforward case. There are more complex uses which involve linking cogs.
The most common one is fl .
fl
\ a gratuitous comment
cogid st? drop
{
A comment block
}
cog?
<examples you really should read have been trimmed out>
fl takes the input it is receiving, strips out comments, and comment blocks, strips leading whitespace,
buffers it, and simultaneously send it to another cog to process. This allows PropForth to accept input
faster than it can interpret or compile it. So in this case we see cog 5 is now linked between cog 6 and cog 7.
Cog 7 is the serial driver, sends the characters received to cog 6 who strips out comments, does buffering,
and send the characters to cog 5, who does the actual processing of the input, and send it’s output to cog 7,
who buffers and transmits over the serial line.
That's pretty much all it does.
The simple answer is you need to debug your code before you put it in a file to be loaded from eeprom. This should not be a surprise.
1. Yes, I am debugging my code before I load it into eeprom. I eventually want to load it into eeprom, but it is still being debugged. NOT surprised at all.
2. The / comments may have a bug if they follow a line of code rather than standing on their own line.
3. And then, it does seem that the order in which the word definitions are presented can be critical.
The DEFER and IS words are useful for redefining the function of a word. I used this in pfth to redefine REFILL. At boot, REFILL only handles console I/O, but it is redefined later to handle SD file I/O as well. This way I didn't have to redefine all of the words that used REFILL. DEFER and IS are also used in the Forth chess program to change the action of the move evaluator.
2. The / comments may have a bug if they follow a line of code rather than standing on their own line.
3. And then, it does seem that the order in which the word definitions are presented can be critical.
Enjoy yourself.
First thing:
/ is division,
\ is the single line comment.
Several of my bug reports against single line comments were due confusion of the two.
Yes, forth does not do forward references, as the interpreter operates in a single pass. Regular forths use DEFER and other tricks to get around forward refences, but propforth does not; propforth uses the Proptool to resolve forward refenernce difficultites when compiling the kernel spin files. If you are working with this level of material, you are not at a beginner level.
Remember that 'Starting Forth' was not written for Propforth, and Propforth was not written for 'Starting Forth'. There is a bunch of overlap, but eventually they diverge. There's little to do about it as we have moved so far past the IBM PC XT era forth for which 'Starting Forth' was written.
If you have a problem or other difficultly, and can describe the situation such that we can reproduce it, then we can help. If we cannot reproduce the issue, it becomes less likely that we can figure out where the problem lies or fix it.
Really, the key is posting the code that is giving you the problem. Nobody minds that don't want to contribute to the documentation, but allowing us to reproduce your issue would certainly make it easier to help you.
Prop0 Cog6 ok
: test ." this is a test with the comment after the source " cr cr ; \ does a comment afte source work?
Prop0 Cog6 ok
Prop0 Cog6 ok
test
this is a test with the comment after the source
Prop0 Cog6 ok
Prop0 Cog6 ok
fswrite testcomment.f
: test ." this is a test in fswrite with comment afte the source " cr cr ; \ does fswrite like comments?
test
Prop0 Cog6 ok
Prop0 Cog6 ok
fsls
0_000_032_768 04_322 4step.f
0_000_037_120 00_447 sr04.f
0_000_037_632 00_506 boot.f
0_000_038_208 02_024 bot.f
0_000_040_256 00_436 btstat.f
0_000_040_704 00_313 btinit.f
0_000_041_088 00_117 testcomment.f
0_000_024_256 bytes free in EEPROM file system
Prop0 Cog6 ok
test
this is a test with the comment after the source
Prop0 Cog6 ok
fsload testcomment.f
Prop0 Cog5 ok
: test ." this is a test in fswrite with comment afte the source " cr cr ; \ does fswrite like comments?
Prop0 Cog5 ok
Prop0 Cog5 ok
test
this is a test in fswrite with comment afte the source
Prop0 Cog5 ok
Prop0 Cog5 ok
Prop0 Cog5 ok
Prop0 Cog6 ok
test
this is a test in fswrite with comment afte the source
Prop0 Cog6 ok
Near as I can tell the single line comment works in all cases. It works when the entire line is a comment, we use this all the time. It works to comment out the rest of the line after some source code as shown above. Can you post a particular case where it does not work?
One thing to notice, not displayed in the snip above, the fswrite MUST be terminated by three periods
...
which marks the end of the file being written to eeprom, but do not apprear on the output screen. The three periods are in every example of source code that uses fswrite.
fl
Prop0 Cog5 ok
: test ." this is a test with the comment after the source " cr cr ; \ does a comment afte source work?
Prop0 Cog5 ok
Prop0 Cog5 ok
test
this is a test with the comment after the source
Prop0 Cog5 ok
Prop0 Cog5 ok
fswrite testcomment.f
: test ." this is a test in fswrite with comment afte the source " cr cr ; \ does fswrite like comments?
test
Prop0 Cog5 ok
Prop0 Cog5 ok
fsls
0_000_032_768 04_322 4step.f
0_000_037_120 00_447 sr04.f
0_000_037_632 00_506 boot.f
0_000_038_208 02_024 bot.f
0_000_040_256 00_436 btstat.f
0_000_040_704 00_313 btinit.f
0_000_041_088 00_117 testcomment.f
0_000_041_280 00_117 testcomment.f
0_000_024_064 bytes free in EEPROM file system
Prop0 Cog5 ok
Prop0 Cog5 ok
Prop0 Cog6 ok
test
this is a test with the comment after the source
Prop0 Cog6 ok
fsload testcomment.f
Prop0 Cog5 ok
: test ." this is a test in fswrite with comment afte the source " cr cr ; \ does fswrite like comments?
Prop0 Cog5 ok
Prop0 Cog5 ok
test
this is a test in fswrite with comment afte the source
Prop0 Cog5 ok
Prop0 Cog5 ok
Prop0 Cog5 ok
Prop0 Cog6 ok
test
this is a test in fswrite with comment afte the source
Prop0 Cog6 ok
The DEFER and IS words are useful for redefining the function of a word.... REFILL.
Since we don't need to worry about forward references in propforth build process, we haven't had need of these words. Thanks to the buffered assembler, we can work from the initial kernel, and load the proper definitions from storage. Saves a bunch of complexity, so far.
DEFER and IS can be used for forward references, but they're also useful for changing the meaning of a word to different backward references. It really doesn't introduce much complexity. However, it would be hard to do in PropForth since it doesn't support DOES>.
How does the buffered assembler work? Can PropForth assemble PASM code?
DEFER and IS can be used for forward references, but they're also useful for changing the meaning of a word to different backward references. It really doesn't introduce much complexity. However, it would be hard to do in PropForth since it doesn't support DOES>.
How does the buffered assembler work? Can PropForth assemble PASM code?
As I understand it, you optimize your function in assembler. The routine(s) are stored as base 64, so occupy fewer bytes, but load quickly. When called, you load from SD or EEprom, into cog memory. The result is fast execution, and no additional hub dictionary memory footprint. The function in cog memory and can be called again, until the next function is called into memory and overwrites it. So we can have as many routines as we care to fit on the SD card, and we never need to exceed the props memory limit at at any given time. Of course you still have to be aware of what is going on, and not all applications can be fitted into this method. Not many folks seem to need assembler so much aside from simple drivers; once the kernel is optimized the applications are already fast enough (so far).
"Much complexity" is relative and subjective. Sal was really excited when Poul saved 1 long and 1 slow instruction, so he might have a different perspective.
In the case of DOES>, we decided since we never use it, and most folks have trouble with it, and we can get around it by just writing one word for the immediate function and another word for the runtime function, it would be less painful to skip it rather that deal with folks that don't understand. (Which actually happens more than you might think). Of course, anybody can write DOES>, but I don't think anybody has, so the need seems very low.
I think the dictionary structure needs to accommodate a pointer for DOES>, and the inner loop needs to be aware of it. So it's not as easy as you think to add DOES> if the interpreter doesn't support it. That's probably why nobody uses it in PropForth.
I think the dictionary structure needs to accommodate a pointer for DOES>, and the inner loop needs to be aware of it. So it's not as easy as you think to add DOES> if the interpreter doesn't support it. That's probably why nobody uses it in PropForth.
Possibly. Usually if one needs DOES>, one understands the inner loop and is capable of recompiling the kernel. The thinking was that if somebody made a case for it, it could get put in, but nobody has. So maybe nobody uses it because its not there, or nobody really needs it in the first place. In either case, its not on the list and we haven't missed it so far.
First thing:
/ is division,
\ is the single line comment.
Several of my bug reports against single line comments were due confusion of the two.
Yes, forth does not do forward references, as the interpreter operates in a single pass. Regular forths use DEFER and other tricks to get around forward refences, but propforth does not; propforth uses the Proptool to resolve forward refenernce difficultites when compiling the kernel spin files. If you are working with this level of material, you are not at a beginner level.
Remember that 'Starting Forth' was not written for Propforth, and Propforth was not written for 'Starting Forth'. There is a bunch of overlap, but eventually they diverge. There's little to do about it as we have moved so far past the IBM PC XT era forth for which 'Starting Forth' was written.
If you have a problem or other difficultly, and can describe the situation such that we can reproduce it, then we can help. If we cannot reproduce the issue, it becomes less likely that we can figure out where the problem lies or fix it.
Really, the key is posting the code that is giving you the problem. Nobody minds that don't want to contribute to the documentation, but allowing us to reproduce your issue would certainly make it easier to help you.
Well, I will have to investigate if the backslash versus slash typo hazard was the source of my woes. I am not sure I can at this point as I just pulled such comments and settled for just the { and } to reduce the amount of bugs I had to deal with.
It certainly is a problem that will surface again and again. Linux versus Windows have a problem with these two characters.
~~~~~~~~~~~~
Has it ever occured to you that my actual contributions to PropForth may have been a greater disaster than my pulling out of contributing? You could have been overrun with documents that have more problems than solutions.
Anyway, I have pretty much decided that I have had enough of PropForth for a while and feel I should shift over to Tackyon and/or pfth. I will try to run a few tests of the 'backslash' in fastload to see if my bug is real or unreal.
Part of the confusion might be that the
{
.... text...
}
does not echo in fastload, but the
\ ......
does echo.
And then the \ is like all Forth words in that it demands a whitespace immediately after it. Without the white space it crashes the load.
'fl' is somewhat primitive in that it echoes other things besides error and crash messages, and it all scrolls by quite quickly. Hopefully you are not offended by my saying so.
Has it ever occured to you that my actual contributions to PropForth may have been a greater disaster than my pulling out of contributing? You could have been overrun with documents that have more problems than solutions.
Same goes for my contributions. Most of mine are mediocre at best, as you can see. But we'll never know about the ones that we don't see. Since I have not found a tech writer to convert the tech talk inot human speak, we work with what we got. I'm using the "throw the underwear on the wall" technique, eventually something will stick. We can deprecate pages that turn out to be no good, but we need some for folks to read to stat with.
\ is like all Forth words in that it demands a whitespace immediately after it. Without the white space it crashes the load.
Yes, without the whitespace delimiter you are using a different identifier, that starts with a slash. Forth lets you do what ever you want, even when its nutty.
'fl' is somewhat primitive in that it echoes other things besides error and crash messages, and it all scrolls by quite quickly. Hopefully you are not offended by my saying so.
Of course I'm not offended. Sometime I get annoyed, but that's more about things over here, the kids stepping in the wet paint etc.
Notice that ALL words in propforth are primitative by design. Assuming that any are more complex is the cause of most errors. These functions do nothing more than exactly what they say, they don't do anything extra "for" you.
Well, my fl problems were very mixed, but the slash/backslash reversal did make for additional confusion.
All my fastload files are now behaving properly and the project is complete. I am going to explore pfth067 a bit to see what Dave achieved.
Documents are either for personal use or for a particular audience. Sometimes we think that the two can be one in the same, but anytime you want to reach an audience you have a teaching role that may not be necessary when writing for yourself.
On the forum, on can kick around ideas such as How to use fl well and discover some key points that might frustrate a new user.
1. When the comments (both the { and } and the \ are working properly, they do NOT visually appear during a fastload.
2. Build fast load files in small segments rather than just open a file and write all and everything you think will work into it. Test the loading process after each segment is included until you have a complete load.
3. Sometimes you have to rearrange what you load so that the you avoid references to as-yet-to-be defined words.
4. Getting the @ and the ! confused is a common source of stack errors and resets.
5. Fastload will echo word definitions that are being successful accepted. If one is look for errors, seek out the only the first error after successfully loaded items as it appears that subsequent message items might lead one astray.
Writing is pretty much like language learning, one always has more to learn. It is a never-ending process. On the other hand, physics, maths, and electronics begin to stabilize and flatten the learning curve after you reach a certain level of competence.
Forth has alway be very close to the machine, so services are what many would consider 'primative' when compared to other more fancy user interfaces. I actually prefer the more primative user interface as I see how the code is doing what it does... it isn't just a WYSIWYG Black Box.
Any lastly, the only thing I really know about 'good writing' is that it is rewritten many, many times. Excellence is a painstaking process.
1. When the comments (both the { and } and the \ are working properly, they do NOT visually appear during a fastload.
Comments are IGNORED. The input stream throws them away, we only see what the interpreter saw
2. Build fast load files in small segments rather than just open a file and write all and everything you think will work into it. Test the loading process after each segment is included until you have a complete load.
BUT FIRST test each function individually and thoroughly from the command line. Skipping this step guarantees problems (at least for me). You should be convienced that the function already works before adding it to the fast load. Load the working stuff automatically, add the function under development manually (by pasting that couple lines function) until its working.
3. Sometimes you have to rearrange what you load so that the you avoid references to as-yet-to-be defined words.
ALWAYS you have to arrange your words to avoid yet-to-be-defined references, or the interpreted will respond with "UNDEFINED WORD". If you want to define a PLACEHOLDER now and fill in the executable part later, look at defered execution DEFER, IS , `'` (ththis word is pronounced "tick") these are used in other forths. They add a bunch of complexity that we ty to avoid, but it can still be done.
4. Getting the @ and the ! confused is a common source of stack errors and resets.
An this is why we test one function at a time, thoroughly, before moving on. Each time I do this eror its because I trued to skip this, because I was feeling too smart to follow all the steps.
5. Fastload will echo word definitions that are being successful accepted. If one is look for errors, seek out the only the first error after successfully loaded items as it appears that subsequent message items might lead one astray.
After the first eror, all bets are off. After any error, you should always do a reset or power cycle before trying again, as you never know exactly what the error caused, the errors tend to cause crazy stuff. If you ty to debug with out a reset, you can spend hours track to track down a ghost, when it goes away after the eventual reset your changed the wrong code.
'good writing' is that it is rewritten many, many times.
Documents AND source code. Another set of eyes always helps. Feedback is essential if the audience is more than "self".
Yes, when Comments appear and are not ignored... there is a typo and a poorly formed commet. So that is an excellent indicator of where any fastload bugs from poorly formed comments are.
And. 'after the first error, all bets are off' is extremely helpful. A novice can waste a lot of time trying to figure out whats going on when it is just confusion.
I suppose that I find it easiest to just clean up all the comments first, and then take one definition at a time from top to bottom.
What I did not discuss is my other fastload task.
I have written a lookup table starting at 63000 in Eeprom of 1430 bytes at 715 Word entries. It seems to not colide with the Eeprom file system until you have a file load overwrite it.
That doesn't use Comments and doesn't use colon definitions.
It is simple a list of one line entries that are 715 words of numberical data and addresses are incremented by twos.
654 63000 EW!
54 63002 EW!
877 63004 EW!
97 63006 EW!
and so on to 64430.................
See ya.
More progress on my SR04 issues. Turns out I have to recalculate the resistor values using 6 volts, the alkaline batterries are 1.5 volts, not the 1.2 rechagables like Sal uses. Also, Sal's power supply include a reverse current diode. Issue seems I was way overvolting eveything. So the voltage is in several ranges that over lap but tend to be at the edge of spec. Seems like its always a power supply issue these days....
On a tangental note, in the course of the SR04 discussion, we talked about complete, detailed circuit analysis (which I did not know about before). TURNS OUT that one can drive the prop using JUST the INPUT PINS. That's what the man says. Something to do with the clamping diodes. For example, if we set up several props in for example multiprop configurateion, and/or had powered sensors connected to the prop input pins, the prop could run with nothing connected to Vin or Vdd. Having one prop powered on and one powered off becomes equivalent to both props powerrred on, with one 3.3 volts LESS than the powered one. Anybody know about this? Sal says the techinical term is "weird $h1t happens".
PF6 is coming along. The multitasker is multitasking. A logger test is being developed to test the multitasker, the logger, and the SD. Sal has a total of about 15 threads going, with 5 generating data, 5 loggin the data to SD, the others are overhead (the command line, the serial driver, the SD driver, etc). The test logged about 500 meg in two days, and logged about 30 record per second. This test is to make the SD fail, so there is no SD page buffering, every record causes a separate update. It took 40 hous to pull the data, obviously in a real world application we would want ethernet or something that's faster than the serial blue tooth on the test rig. Looks like logging can be faster than the curent 33 milliseconds per record, once bufering is added.
We've already got a couple PF6 Beta test volenteers. We still have room for a couple more, seats are limited, reserve yours now!
There will be a bunch of paticipation options:
* The build process will run on ANY prop chip
* testing will run on an assortment of stock props
* MSC will need a specific hardware configuration
I believe Sal is still planning to make a "Hardware Testbed version 1" and deprecate the old hardware test bed prototype that he hacked together years ago. I don't think the spineret will be requied this time, but that plan is that it will still be included as an option. So anyone can still to the testing, just not the parts that need hardware that isn't present. The custom hardware will likely center around MCS and logging. I'm pushing for at least one configuration that includes a Raspbery Pi specifically instead of a generic PC, as RPi may figure in to future LittleRobot designs.
lookup table starting at 63000 in Eeprom of 1430 bytes at 715 Word entries. It seems to not colide with the Eeprom file system until you have a file load overwrite it.
I don't know if this is how you are doing it, but if you let the file system know about your look up table, it won't over write it.
If you define a file that happens to stat at 63000 and runs for 715 words, the file system know to start writing AFTER this.
Also, if you:
* put BOOT.f first on your your fs, and have it call a file "myboot.f" (not defined yet, the boot.f script willl just try to call myboot.f if it exists)
* put your lookup table right after Boot.f, and define a file of appropriate size to reserve that space,
* put "myboot.f" right after the file.
Then you can change myboot.f by using fsdrop (to remove the last file). This way, you can remove and restore myboot.f and any files after it, without touching your lookup table. Sal recommends the "drop the last file" method, although I personally tend to use the "nuke everything and start from scratch" method as it guarantees a clean, known start state.
I was wondering if I could just redefine the value of fstop to below the 63000 address, say 62999.
But I have not yet tested it any am unsure if that will upset the overall utility of the file system.
I have been exploring Lookup tables in CogRam, HubRam, and EEprom. ... all are possible, but CogRam is very limited in space and resets do something I don't understand to the 176 Longs that are supposed to be unused.
At this point I am more concerned that looking up from EEprom may be too slow, and I will likely shift to a Lookup table in HubRam to speed things up.
But having the ability to divide the extra EEprom into a well-behanved EEprom file system from the bottom up and using a second portion from the top-down for Loop-up tables or data arrays seems possible.
The use here is to have a stepper motor provide a non-linear motion cycle and have the data for delays read off at a quick rate.
In theory, one can set aside a portion of the CogRam, the HubRam, or the EEprom to act as generic storage and then have @ and ! exploit those areas.
CogRam is very limited in space and resets do something I don't understand to the 176 Longs that are supposed to be unused.
Resets turn the 176 longs to undefined. The prop does whatever the prop does, and these are in no particular (or predictable) state.
At this point I am more concerned that looking up from EEprom may be too slow, and I will likely shift to a Lookup table in HubRam to speed things up.
Ok, how about save the table in EEprom, and load it into COG ram when you need to use it? Periodically save it if it ever gets updated, but don't read the cog ram until you've loaded it with something specific.
Yes, I can and have saved the table in a xxxx.f file in EEprom and then had the Propeller load it anywhere that is final.
This helps with issues of both the CogRam and HubRam being volatile as restoration is quick and consistent. Rebooting the Propeller does not change either the EEprom file system or a modified EEprom above the 32K that is half file system and half other tables. But having it all in a memory mapped table allows code to reach each individual item in the form of a Word in address driven maths.
I have no problem with reboots erasing data, but when resets do.. it gets tricky. Accidental stack overflow or underflow brings everything down. I have yet to figure out the means to trigger an immediate reload of data tables in CogRam after a reset.
I suppose a checksum routine after reset might sort out the need to reload.
I have no problem with reboots erasing data, but when resets do.. it gets tricky. Accidental stack overflow or underflow brings everything down. I have yet to figure out the means to trigger an immediate reload of data tables in CogRam after a reset
define your onreset word to load the tables. Onreset is called.... on reset , as part of the reset routine. There are examples in the extensions directory.
onreset and onboot have no explaination within the PropForth.htm.
My first impression was that I had to have 64k eeprom to use these.. 32k might be unsupported. But now I am thinking that they might not be dependent on extra eeprom. That they just might refer to another word previously defined in dictionary.
Having said that I need to run some tests to verify. Something like the following...
onreset and onboot have no explaination within the PropForth.htm.
Is the above well-formed? Or is it off in the weeds?
I haven't really figured them out either. Sal explained it and it was simple, but I never wrote it down. I just look at the examples and do the same until it works.
Opening issue 197 to capture this better. We'll talk about this Sunday, maybe I can get notes up Sunday afternoon
Comments
I'm in the middle of our garden with an angry rototiller right now but I'd be happy to help with "fl" this weekend if I get play time. Documenting that is a good "how do I make a forth application" tutorial.
To your one question about forward references, Forth applications are built from the bottom up due to the basic way the compiler works. Since it compiles words as it reads input and builds threads of tokens in the dictionary for the new word it can only use words that already exist in the dictionary. This is why bottom up coding is key to forth and you can't do top down coding.
Another quirk you may have noticed I'd that you can't define word1, use it in word2 and then go back and redefine word1 and expect word2 to use the new word1....that sounds more confusing than it is.
I hadn't seen the behaviors you have with "fl" but then except for little stuff, I've only used "fl" to load up the code modules that come with PF.
If you could post one of your problem files, we can all play with it and help.
If you say so.
Can you give an example? It does not give me a problem.
This is how all forths work all the time.
Obvioulsy.
While the index listing stack note is a little sparse,
this one is covered in detail in the manual that has always been there yet few read.....
6 PropForth Input/Output 6.1 Overview A PropForth cog by default has ... ... Recall >con from the getting started section, all it is doing is disconnecting and connection IO channels. This is a very straightforward case. There are more complex uses which involve linking cogs. The most common one is fl . fl \ a gratuitous comment cogid st? drop { A comment block } cog?<examples you really should read have been trimmed out>
That's pretty much all it does.
The simple answer is you need to debug your code before you put it in a file to be loaded from eeprom. This should not be a surprise.
1. Yes, I am debugging my code before I load it into eeprom. I eventually want to load it into eeprom, but it is still being debugged. NOT surprised at all.
2. The / comments may have a bug if they follow a line of code rather than standing on their own line.
3. And then, it does seem that the order in which the word definitions are presented can be critical.
Enjoy yourself.
First thing:
/ is division,
\ is the single line comment.
Several of my bug reports against single line comments were due confusion of the two.
Yes, forth does not do forward references, as the interpreter operates in a single pass. Regular forths use DEFER and other tricks to get around forward refences, but propforth does not; propforth uses the Proptool to resolve forward refenernce difficultites when compiling the kernel spin files. If you are working with this level of material, you are not at a beginner level.
Remember that 'Starting Forth' was not written for Propforth, and Propforth was not written for 'Starting Forth'. There is a bunch of overlap, but eventually they diverge. There's little to do about it as we have moved so far past the IBM PC XT era forth for which 'Starting Forth' was written.
If you have a problem or other difficultly, and can describe the situation such that we can reproduce it, then we can help. If we cannot reproduce the issue, it becomes less likely that we can figure out where the problem lies or fix it.
Really, the key is posting the code that is giving you the problem. Nobody minds that don't want to contribute to the documentation, but allowing us to reproduce your issue would certainly make it easier to help you.
Near as I can tell the single line comment works in all cases. It works when the entire line is a comment, we use this all the time. It works to comment out the rest of the line after some source code as shown above. Can you post a particular case where it does not work?
One thing to notice, not displayed in the snip above, the fswrite MUST be terminated by three periods
which marks the end of the file being written to eeprom, but do not apprear on the output screen. The three periods are in every example of source code that uses fswrite.
Since we don't need to worry about forward references in propforth build process, we haven't had need of these words. Thanks to the buffered assembler, we can work from the initial kernel, and load the proper definitions from storage. Saves a bunch of complexity, so far.
How does the buffered assembler work? Can PropForth assemble PASM code?
As I understand it, you optimize your function in assembler. The routine(s) are stored as base 64, so occupy fewer bytes, but load quickly. When called, you load from SD or EEprom, into cog memory. The result is fast execution, and no additional hub dictionary memory footprint. The function in cog memory and can be called again, until the next function is called into memory and overwrites it. So we can have as many routines as we care to fit on the SD card, and we never need to exceed the props memory limit at at any given time. Of course you still have to be aware of what is going on, and not all applications can be fitted into this method. Not many folks seem to need assembler so much aside from simple drivers; once the kernel is optimized the applications are already fast enough (so far).
"Much complexity" is relative and subjective. Sal was really excited when Poul saved 1 long and 1 slow instruction, so he might have a different perspective.
In the case of DOES>, we decided since we never use it, and most folks have trouble with it, and we can get around it by just writing one word for the immediate function and another word for the runtime function, it would be less painful to skip it rather that deal with folks that don't understand. (Which actually happens more than you might think). Of course, anybody can write DOES>, but I don't think anybody has, so the need seems very low.
Possibly. Usually if one needs DOES>, one understands the inner loop and is capable of recompiling the kernel. The thinking was that if somebody made a case for it, it could get put in, but nobody has. So maybe nobody uses it because its not there, or nobody really needs it in the first place. In either case, its not on the list and we haven't missed it so far.
Well, I will have to investigate if the backslash versus slash typo hazard was the source of my woes. I am not sure I can at this point as I just pulled such comments and settled for just the { and } to reduce the amount of bugs I had to deal with.
It certainly is a problem that will surface again and again. Linux versus Windows have a problem with these two characters.
~~~~~~~~~~~~
Has it ever occured to you that my actual contributions to PropForth may have been a greater disaster than my pulling out of contributing? You could have been overrun with documents that have more problems than solutions.
Anyway, I have pretty much decided that I have had enough of PropForth for a while and feel I should shift over to Tackyon and/or pfth. I will try to run a few tests of the 'backslash' in fastload to see if my bug is real or unreal.
Part of the confusion might be that the
{
.... text...
}
does not echo in fastload, but the
\ ......
does echo.
And then the \ is like all Forth words in that it demands a whitespace immediately after it. Without the white space it crashes the load.
'fl' is somewhat primitive in that it echoes other things besides error and crash messages, and it all scrolls by quite quickly. Hopefully you are not offended by my saying so.
Same goes for my contributions. Most of mine are mediocre at best, as you can see. But we'll never know about the ones that we don't see. Since I have not found a tech writer to convert the tech talk inot human speak, we work with what we got. I'm using the "throw the underwear on the wall" technique, eventually something will stick. We can deprecate pages that turn out to be no good, but we need some for folks to read to stat with.
Yes, without the whitespace delimiter you are using a different identifier, that starts with a slash. Forth lets you do what ever you want, even when its nutty.
Of course I'm not offended. Sometime I get annoyed, but that's more about things over here, the kids stepping in the wet paint etc.
Notice that ALL words in propforth are primitative by design. Assuming that any are more complex is the cause of most errors. These functions do nothing more than exactly what they say, they don't do anything extra "for" you.
All my fastload files are now behaving properly and the project is complete. I am going to explore pfth067 a bit to see what Dave achieved.
Documents are either for personal use or for a particular audience. Sometimes we think that the two can be one in the same, but anytime you want to reach an audience you have a teaching role that may not be necessary when writing for yourself.
On the forum, on can kick around ideas such as How to use fl well and discover some key points that might frustrate a new user.
1. When the comments (both the { and } and the \ are working properly, they do NOT visually appear during a fastload.
2. Build fast load files in small segments rather than just open a file and write all and everything you think will work into it. Test the loading process after each segment is included until you have a complete load.
3. Sometimes you have to rearrange what you load so that the you avoid references to as-yet-to-be defined words.
4. Getting the @ and the ! confused is a common source of stack errors and resets.
5. Fastload will echo word definitions that are being successful accepted. If one is look for errors, seek out the only the first error after successfully loaded items as it appears that subsequent message items might lead one astray.
Writing is pretty much like language learning, one always has more to learn. It is a never-ending process. On the other hand, physics, maths, and electronics begin to stabilize and flatten the learning curve after you reach a certain level of competence.
Forth has alway be very close to the machine, so services are what many would consider 'primative' when compared to other more fancy user interfaces. I actually prefer the more primative user interface as I see how the code is doing what it does... it isn't just a WYSIWYG Black Box.
Any lastly, the only thing I really know about 'good writing' is that it is rewritten many, many times. Excellence is a painstaking process.
BUT FIRST test each function individually and thoroughly from the command line. Skipping this step guarantees problems (at least for me). You should be convienced that the function already works before adding it to the fast load. Load the working stuff automatically, add the function under development manually (by pasting that couple lines function) until its working.
ALWAYS you have to arrange your words to avoid yet-to-be-defined references, or the interpreted will respond with "UNDEFINED WORD". If you want to define a PLACEHOLDER now and fill in the executable part later, look at defered execution DEFER, IS , `'` (ththis word is pronounced "tick") these are used in other forths. They add a bunch of complexity that we ty to avoid, but it can still be done.
An this is why we test one function at a time, thoroughly, before moving on. Each time I do this eror its because I trued to skip this, because I was feeling too smart to follow all the steps.
After the first eror, all bets are off. After any error, you should always do a reset or power cycle before trying again, as you never know exactly what the error caused, the errors tend to cause crazy stuff. If you ty to debug with out a reset, you can spend hours track to track down a ghost, when it goes away after the eventual reset your changed the wrong code.
Documents AND source code. Another set of eyes always helps. Feedback is essential if the audience is more than "self".
And. 'after the first error, all bets are off' is extremely helpful. A novice can waste a lot of time trying to figure out whats going on when it is just confusion.
I suppose that I find it easiest to just clean up all the comments first, and then take one definition at a time from top to bottom.
What I did not discuss is my other fastload task.
I have written a lookup table starting at 63000 in Eeprom of 1430 bytes at 715 Word entries. It seems to not colide with the Eeprom file system until you have a file load overwrite it.
That doesn't use Comments and doesn't use colon definitions.
It is simple a list of one line entries that are 715 words of numberical data and addresses are incremented by twos.
654 63000 EW!
54 63002 EW!
877 63004 EW!
97 63006 EW!
and so on to 64430.................
See ya.
More progress on my SR04 issues. Turns out I have to recalculate the resistor values using 6 volts, the alkaline batterries are 1.5 volts, not the 1.2 rechagables like Sal uses. Also, Sal's power supply include a reverse current diode. Issue seems I was way overvolting eveything. So the voltage is in several ranges that over lap but tend to be at the edge of spec. Seems like its always a power supply issue these days....
On a tangental note, in the course of the SR04 discussion, we talked about complete, detailed circuit analysis (which I did not know about before). TURNS OUT that one can drive the prop using JUST the INPUT PINS. That's what the man says. Something to do with the clamping diodes. For example, if we set up several props in for example multiprop configurateion, and/or had powered sensors connected to the prop input pins, the prop could run with nothing connected to Vin or Vdd. Having one prop powered on and one powered off becomes equivalent to both props powerrred on, with one 3.3 volts LESS than the powered one. Anybody know about this? Sal says the techinical term is "weird $h1t happens".
PF6 is coming along. The multitasker is multitasking.
We've already got a couple PF6 Beta test volenteers. We still have room for a couple more, seats are limited, reserve yours now!
There will be a bunch of paticipation options:
* The build process will run on ANY prop chip
* testing will run on an assortment of stock props
* MSC will need a specific hardware configuration
I believe Sal is still planning to make a "Hardware Testbed version 1" and deprecate the old hardware test bed prototype that he hacked together years ago. I don't think the spineret will be requied this time, but that plan is that it will still be included as an option. So anyone can still to the testing, just not the parts that need hardware that isn't present. The custom hardware will likely center around MCS and logging. I'm pushing for at least one configuration that includes a Raspbery Pi specifically instead of a generic PC, as RPi may figure in to future LittleRobot designs.
I don't know if this is how you are doing it, but if you let the file system know about your look up table, it won't over write it.
If you define a file that happens to stat at 63000 and runs for 715 words, the file system know to start writing AFTER this.
Also, if you:
* put BOOT.f first on your your fs, and have it call a file "myboot.f" (not defined yet, the boot.f script willl just try to call myboot.f if it exists)
* put your lookup table right after Boot.f, and define a file of appropriate size to reserve that space,
* put "myboot.f" right after the file.
Then you can change myboot.f by using fsdrop (to remove the last file). This way, you can remove and restore myboot.f and any files after it, without touching your lookup table. Sal recommends the "drop the last file" method, although I personally tend to use the "nuke everything and start from scratch" method as it guarantees a clean, known start state.
But I have not yet tested it any am unsure if that will upset the overall utility of the file system.
I have been exploring Lookup tables in CogRam, HubRam, and EEprom. ... all are possible, but CogRam is very limited in space and resets do something I don't understand to the 176 Longs that are supposed to be unused.
At this point I am more concerned that looking up from EEprom may be too slow, and I will likely shift to a Lookup table in HubRam to speed things up.
But having the ability to divide the extra EEprom into a well-behanved EEprom file system from the bottom up and using a second portion from the top-down for Loop-up tables or data arrays seems possible.
The use here is to have a stepper motor provide a non-linear motion cycle and have the data for delays read off at a quick rate.
In theory, one can set aside a portion of the CogRam, the HubRam, or the EEprom to act as generic storage and then have @ and ! exploit those areas.
Resets turn the 176 longs to undefined. The prop does whatever the prop does, and these are in no particular (or predictable) state.
Ok, how about save the table in EEprom, and load it into COG ram when you need to use it? Periodically save it if it ever gets updated, but don't read the cog ram until you've loaded it with something specific.
This helps with issues of both the CogRam and HubRam being volatile as restoration is quick and consistent. Rebooting the Propeller does not change either the EEprom file system or a modified EEprom above the 32K that is half file system and half other tables. But having it all in a memory mapped table allows code to reach each individual item in the form of a Word in address driven maths.
I have no problem with reboots erasing data, but when resets do.. it gets tricky. Accidental stack overflow or underflow brings everything down. I have yet to figure out the means to trigger an immediate reload of data tables in CogRam after a reset.
I suppose a checksum routine after reset might sort out the need to reload.
My first impression was that I had to have 64k eeprom to use these.. 32k might be unsupported. But now I am thinking that they might not be dependent on extra eeprom. That they just might refer to another word previously defined in dictionary.
Having said that I need to run some tests to verify. Something like the following...
: blinky 7 pinout 5 0 do 250 delms 7 pinhi 250 delms 7 pinlo loop ." ready " ;
: onreset blinky ;
Is the above well-formed? Or is it off in the weeds?
I made HardWare for POV_II(LED-Drum).
Now, only 1-character for display.
LED-driver-board is curcuit on #59 of this thread.
Maybe known problem, but someone might not know
There is mistake I often have.
Copy/paste to TeraTerm code below;
Error happen.
Word"fl" use free-area to compile source.
So buffer reserve 832bytes and "fl" can't operate. [It's cog5, not cog6]
To prevent this, you write codes between "fl" and "wvariable buffer d830 allot"
Reserve-bytes depend on codes-amount.
http://code.google.com/p/propforth/issues/detail?id=196
I haven't really figured them out either. Sal explained it and it was simple, but I never wrote it down. I just look at the examples and do the same until it works.
Opening issue 197 to capture this better. We'll talk about this Sunday, maybe I can get notes up Sunday afternoon
http://forums.parallax.com/showthread.php/146693-Propforth-v5.5-is-available-for-download?p=1190654&viewfull=1#post1190654
Totally cool, dude!