Sal is having lots of fun with the little robot design. He is happy with the physical lay out of the version 2 chassis, but will make a version 3 chassis that uses less plastic (and prints quicker.
It looks like the Little Robot default configuration will be built using a Quickstart board and a daughter card to plug in to the 40 pin header, or solder directly to the provided through holes. The quick start resistive touch buttons and LEDs will provide the first level user interface.
Sal has gone back over the stepper motor driver code. He decided it was a hack, and so went back to the math. It looks like the stepper algorithm works really well with fixed point math, so we can make an application of fixed point math as part of the demo. Its very easy and should help get folks with questions up to speed.
The new stepper code will have ridiculous precision compared to what the cheap steppers care about, but the same drivers will be applicable to any upgrade steppers we care to use. The new "very good stepper driver" isn't necessary for the little robot, but Sal feel as long as he's doing the work, its going to be RIGHT.
I asked about releasing v5.3 (nagged actually), Sal will do the cut over to the new code maybe this week. We will NOT include the Little Robot demo package at this time. But I figure the release and the demo are two different things, so the release can be staggered. Also, I'm starting to have trouble answering questions based on the previous release(s) while working with the new release.
After this release, be plan to redo the hardware test bed. The current version includes a prop board, a bare prop, and a spineret board. The majority of users do NOT have a spineret board, so we will separate out the spineret into a separate module. The spinerete, IP, Telnet and HTTP support will still be present, but an optional module. This should allow more folks to give it a try. We will alos try to structure it so the MCS is also a separate , optional module, as not everybody has a stack of bare prop chips laying around (yes, I know it sounds weird, but folks tell me its true). So while we're at it, we just might make the SD support a separate add on module, since not everybody is willing to sacrifice as SD adapter and commit an SD for prop internal use. SO the outline for Propforth Hardware Testbed might be:
1) Prop Board 32k (demo board, old Quickstart)
2) Prop Board 64k+ (protoboard, new quickstart, most third party boards)
3) Prop Board + SD
4) Prop Board + N additional prop chips (MCS)
5) Prop Board + Spineret
This way, any user can run at least some of the automated build and test. Which is REALLY powerful, it might eventually find a use.
We looked at this weeks two new issues: "UNKNOWN ERROR" and ".digit"
Thanks Loopy and Peter
Issue 167) "UNKNOWN ERROR" actually is a stupid message. We ALWAYS know the error, in the case of the SD (where this is typically seen), the message is:
"166 UNKNOWN ERROR".
166 error means the SD did not respond. We will put in the docs a list of the errors and what they mean. We DON'T want to waste kernel space with text for the messages, but the list will allow us to implement any messages we need in our final applications. Sal will change the messages to the form "166 ERROR"
And this is a good thing, that UNKNOWN has been bugging me since the SD support was added.
Issue 168) ".digit" Actually, I think this should be "todigit", as ".digit" is not a kernel word. The issue was that the word would accept letters beyond A-F, so it also accepts G-Z. Turns out that there are two things at work here:
1) propforth supports ANY number base, not just decimal and hex. Recall the decimal values can be forced in code by using d_NNN and hex values can be forces my using h_NNN. Notice that we can also foce base 63 by using x_NNN.
2) The kernel words are designed to work with ANY number base up to what the prop can handle. IT IS THE DEVELOPER'S RESPONSIBILITY to use valid values. If your application needs to check for valid decimal or hex digits, we have to write our own extensions to include such. This is propforth's design decision. Recall that in the non-development kernels, NO error messages are implemented. Not even stack underflow. Because they take up space, and are not needed in most final applications, particularly turnkey applications. .
So far, this functions correctly per requirements. Unless we get further detail on the issue, this will be closed as "not an error".
Prop0 Cog4 ok
UNDEFINED WORD Prop0
Prop0 Cog5 ok
Prop0 Cog4 ok
UNDEFINED WORD Prop0
Prop0 Cog5 ok
Prop0 Cog4 ok
UNDEFINED WORD Prop0
Prop0 Cog5 ok
Prop0 Cog4 ok
UNDEFINED WORD Prop0
Prop0 Cog5 ok
I read Tutorial4.1.
Does I need to install eeprom-system before sd-system?
Why PropForthSDFastSerialKernel.spin don't use on Tutorial4.1?
Hello all, I have tried to take a Words list from PropForth v5.03 and the PropForth Quick Reference and compared it to the "Starting Forth Lexicon" as an aid to new learners.
Enclosed is a ROUGH rough Draft.. if you get my meaning. At this point, I am wondering if I have used a good basis for what the true PropForth lexicon is or might be.
For the sake of efficency, I have converted the "Starting Forth Lexicon" to all lower case. I started out in Linux and used some old Unix utilities to create a sorted list of one word per line. And then I used the Unix utility "comm" to create a three column list of a) words unique to the Starting Forth Lexicon, b) words unique to the PropForth Lexicon, and c) words that both have.
In additon, I may notes of what I know as issues and observations about many of the words.
At this point, there seems to not be as much in common as I had hoped for. And that means that learning PropForth via beginning with Starting Forth might be harder than expected for some. If you happen to know a lot about the Propeller before you started, the learning curve is likely much easier.
There is mistake in "FILES on SD".
Not fsls, sd_ls.
How does files save to SD-card?
Can SD-card use as source-buffer when using"fl"?
I tried to serch Forth-sorce-code word[cd,cd/ cwd,fstat sd_cd,sd_ls,etc], I cannot understand them.
I want Forth-source code for PropForthSDFastSerialKernel.spin.
But I cannot find out these.
Where are these words's Forth-sorce-code?
There is mistake in "FILES on SD".
Not fsls, sd_ls.
Sorry, I'm getting confused from the release version 5.03, the beta version 5.2, and the final version (ready but not released) v5.3.
There are little details changed. The biggest thing at the monent for v5.3 is that all the doc must be gone over and corrected for detail.
How does files save to SD-card?
from propfroothdevkernel.f:
\ 100 fwrite DevKernel.f
uncommenting this line writes the text that follows to file DevKernel.f on the SD, terminated by ... ( the ... is same terminator as on the EEPROM file system)
Can SD-card use as source-buffer when using"fl"?
I believe fl is used with all text stream interpretation, until we get to the telnet interface, that is the only one that does NOT use fl, I think the buffering is done by the ethernet hardware.
I tried to serch Forth-sorce-code word[cd,cd/ cwd,fstat sd_cd,sd_ls,etc], I cannot understand them.
I want Forth-source code for PropForthSDFastSerialKernel.spin.
But I cannot find out these.
Where are these words's Forth-sorce-code?
This is the part of the docs we are straightening out. SWal is traveling for a couple weeks, hopefully we get this sorted out when he gets back. I'll try to put up a further explanation after I handle a brief emergency reading a bedtime story to one of the brainettes.......
Hello all,
I spent most of today banging away on the keyboard and trying to get this is a very nice state. Along the way, I have learned that maybe I could be most useful in a stylistic clean up of the PropForth.htm file so that it is a bit easier for the reader.
I will PM Prof. Braino with some suggestions. But the attached is just a limited listing of Section/Chapter 9 of the PropForth.htm.
At least for me, it makes study all the easier. And above it, I think I have discover the reasons that I have been ignoring the PropForth.htm and exploring other documents. I suspect this is very fixable.
In the interim, I will finalize a comparison of Starting Forth Lexicon to PropForth as I pretty much commited to doing so for the sake of any new Forth users. The tast has gotten a bit side tracked as I got into the PropForth.htm as the best listing of PropForth Lexicon. And there were very clear requests that is add functional groups to make it a more useful reference. I am in the process of doing all that.
This is another study aid for those that began with "Starting Forth" and are moving over to PropForth. I could add quite a bit more and will try to later. But this will get you started.
This is another study aid for those that began with "Starting Forth" and are moving over to PropForth. I could add quite a bit more and will try to later. But this will get you started.
This is much better and will likely allow me to graduate from Starting Forth to just working with PropForth v5.03 (or better). I have been worried that other new Forthers have felt left to fend for themselves.
Attached someting I noticed during writing Forth-code as Tips.txt.
I continue to upload sometimes it.
Thanks for the tips.txt!
This is a good example of what to do during development for a particular app. As caskaz shows, just write a bunch of extensions for your paticular app or driver. In this case, that text descriptors are invaluable diagnostics during development, but might not be needed in the final end user application after all the bugs are worked out.
The technique of defining all the messages in a one array that is indexed is a handy way to implement this. Great example!
Caskaz - could you also post you material to the propforth wiki?
All - when you post a new version, please increment the version number in a reasonable manner, and DEPRECATE the previous version. In search version drop down, you can sort by current version, or deprecated version. This keeps them without deleting them.
Version numbering scheme - what makes sense? Loopy's most recent example has versions in the name "revised" and "rev-two". Confusing versioning makes me crazy.
PLEASE consider using the following (or similar) as the version number.
At the time you make a post, look at the time, and make a string YYYYMMDD-hhmm . So right now it was November 20, 2012, at 6:23 am. This would be converted to a time stamp of
20121120-0623.
IF we use YYYMMDD-hhmm the file name will always sort in chronilogical order for the same file.
We see caskaz has similar for his tip.txt above. Caskaz implies that he will not be changing or at least posting his tips more than once per day. This is fine; all we need is some clue as to which came first. Braino recommends the "best practice" is to always to use the full data stamp, that way its present if you ever have exception that requires it (and there are ALWAYS exceptions) but its up to the individual doing the work.
This project is a turning into a good example of a team that follow some consistent set of standards, even though they are not required by any regulation and we are not doing it for pay. Thanks for participating in this experiment.
I expect opinions to upload my tips to this thread.
There might be mistakes. I will upload to re-write Tips-documents to wiki later.
As caskaz says, we can use these forum discussion for soliciting review comments, feedback and opinions, and any other input on the materials submitted. All viewers are invited to add input to all items posted.
These wiki and downloads other the Google code prop forth site ideally should contain the current, most up to date version of the item under discussion. The same item may appear here in the context of the discussion, and on the propforth site. Thing is after the discussion moves on to the next topic, the materials get buried in the thread.
My though it that the actual item be posted in the Google site, and thread contain a LINK to that item. This ensures that there is exactly one copy of the item, and we don;t be versions messed up.
Of course there can be exceptions for any reason at any time. This is voluntary compliance with any "rule". This is just to establish something we can all depend on as the project grows.
because PF 5.0 was supposed to have rather complete docs.
Who told you THAT? It should have been "rather a lot of completely useless docs". The KERNEL is pretty complete, and propforth.htm is off to a good start.
But so far, there have been very few questions, and fewer contributions to the docs. The contributions have been very good, jut not so many.
If fact, Loopy has contributed more to the propforth documentation that any other single contributor, apart from my numerous initial drafts.
@Prof. Braino.
The documents are far from useless.... everything ever written goes through formative rough drafts. And Peter at TachyonForth seems to want to avoid any documentation other than what may become the world's longest Forth thread.
I'd say for someone that knows something about SPIN and PASM and Forth, there is quite a bit that is useful.
I just don't happen to be that person and we do desire a much wider base of users. Forth isn't that hard. I just want to make is as easy as possible for all the 'easily confused' people like myself. With 86 Wiki entries, there is quite a bit there. Improve the quality of what is on hand rather than provide more rough drafts.
Good writing is all about rewriting. I tend to go back and re-edit my Forth post at least 5 times for spelling and typos or missing content. I also try to tone down a bit of my rather forceful tone. Parallax must think I am trying to bust their servers.
I do accept that PropForth is non-ANS Forth and a minimalist Forth. Now it just has to be an easily teachable Forth with the ability to exploit wider examples of code from the decades of writing on Forth.
I thought there were only 3 Kernels, but you have recently posted some rather confounding (to me) stuff about other Kernels. And to be honest, I am still not even sure that Kernel is the right term for what a Forth system basically provides in code. That term Kernel was from OS system levels.
Please don't confuse beginners about where the FRONT DOOR is. There are 3 spin files that are ready-to-go -- A minimal PF Forth, a larger EEPROM PF Forth, and an SDcard supporting PF Forth. I guess these are all kernels as well.
You must think that people really want to begin by building their own from scratch. To me that is pretty advanced stuff. I am not ready to do so. And I have doubts about wanting to do so.
BTW, Casak's tip in #289 above is interesting - a bit of memory mapping. Still, I am not quite sure I am ready for memory maps. He is much farther along that I am, but I do peek at what he is writing.
I will try to contribute more documents, but not for quantity's sake. Whatever I write will have to be rather complete and of reasonable quality.
Are the startring points, depending if you want "plain" propforth dev system, same with EEPROM file system, or same with SD file system support.
We expect all users to start there. Beginners may spend months with these, advanced user typically spend days or minutes before moving to building custom kernels. I think Brain needed a custom kernel after one day, but nobody else reported banging their head against the ceiling of quickly yet.
Eventual, some users will want to roll their own, that is want is done when one has an actual end user application to produce. Because we can fit a lot more app functionality when we remove the (unused and unneeded in the final product) dev support.
In my case, I always want the dev support in the final product, as its educational, so Sal made it easiest for me. But the other directories are where one build ANY arbitrary kernel from scratch, Sal made those easiest for him. Anyone can chose either level of complexity, or any in between.
Please, I think I can rewrite my own documents. If facts are wrong, corrections and mention of omissions are always welcome, but I don't want people doing a lot of unnecessary work. In some cases, it just causes more confusion - writers writing about what writers should write and so on.
I was suggesting that everything might be improved by not writing more documents so much as improving what exists.
Several of the wikis by you and Sal have "Work in Progress" on them. Those are a high priority to become genuine. Especially the Dictionary specification and some of the overview Wikis of PropForth.
BTW, the Dictionary specification does have a typo in that it mentions the flags are bits 7, 6, and 4. I suspect that 4 should be a 5 as the rest of the 5 bits of that byte are suppose to indicate the number of characters in a words name.
~~~~~~~~~~~~~~~~~
I do have a more pressing problem though.
I need a 9600 8N1 serial port in PropForth that has a shared TX/RX pin for my Serial Inkjet Printer Board to interface with it. In other words, just one pin, not two. And not via the regular Console, another serial port. In other words, I need to have both the Console I/O available for development and another RS232 port for control of the printer head AND that has this half-duplex over one wire in TTL voltages.
Is this a big project that I might have to start from scratch? Or can I simply hook into the serial software that is on Cog7 and redirect its use?
The fate of the Chopstick Printer lies in the balance.
And, it seems that PropForth never considered support a 2nd RS232port. Oh my, I think I'm drowning........................................................................
Of course. I meant no disrespect. I meant to review and offer comments. The key to proper documentation is to have the targeted readership (everybody) read the draft and offer input while its being created, rather than after its "completed" when the comments are too late. Nothing against your docs or abilities, this is from working on large projects spanning years and involving large numbers of engineers. Just my suggestion.
I do have a more pressing problem though.
I need a 9600 8N1 serial port in PropForth that has a shared TX/RX pin for my Serial Inkjet Printer Board to interface with it. In other words, just one pin, not two. And not via the regular Console, another serial port.
Ah! A bit of fun!
Please see Propforth.htm 9.1.131 _serial
and Propforth.htm 9.1.300 serial
For the notes on how to set up and use the simple async serial function.
Also look in
..V5.0\kernels\BootKernel\BootOptimizeKernel\BootOptimizeFsrdKernel
serial.f
which, is the 64 bit encoded assembler optimization, so i guess that isnt much help. WTF? I thought the high level source was included?
Oh wait, look in
..V5.0\\kernels\BootKernel\BootOptimizeKernel\\BootOptimizeFsrdKernel
serial.f
This is the same 64 bit encoded optimization, except includes forth code for setting up the terminal (This happens to be a remote prop example, but that shouldn't affect how you are going to use it).
So, I don't know why I can't find the high level forth for _serial. It could be the the window search is acting up? Maybe not. This might be one of those things that is so elementary to the kernel that the high level forth was optimized out, just as with the support for the interpreter.
Anyway, next you want to look at
..\V5.0\kernels\doc\tutorials
tutorial-3.2 Serial Loopback.txt
This is the example of the code for serial being used correctly. You have to execute the prerequisite tutotislals to set up for this example. But it will show you the correct usage and execution for the serial function.
REMEMBER - you have to read the propforth.htm, look at the source code, and execute the example (tutorial). This is how all of propforth materials are set up. If you don't follow the instructions, it probably won't work unless you are an advanced user like Brian or caskaz.
I didn't run these just now, but I did run them about ten times when we did the testing, and the code hasn't changed, so I'm pretty confident this works. If it doesn't work the first time, please try it again.
Your chopstick printing is imminent.
EDIT
FOUND IT!
Yes, there is something weird with the windows search tool. The high level forth source for serial is in
..\V5.0\kernels\BootKernel
PropForthStartKernel.f
I don't know why windows search can't find text in a file.
Anyway, the forth source is used in the pre-optimized build, so this is supposed to be included in every release. And there it is.
And, it seems that PropForth never considered support a 2nd RS232port. Oh my, I think I'm drowning........................................................................
No, its in there. The recommended process is:
Read HTM - Read source code - Do example
It's straighforward. Time consuming the first time through, but simple.
Well, I ordered a new Inkjet cartridge as the old one seems to have become clogged after sitting for 5 or so years.
I will investigate the above and have looked at some of this already. The use of EMIT is not going to fully support the serial port. I need to sent ESC sequences and CNTL sequences - just having the visually displayed ASCII character sent out of the serial port is a dead end.
I can provide the raw 8 bit binary equivalents of the rather complex ESC and CNTL sequence conversions, but I require a binary equivalent of an EMIT, let's say bEMIT would be a good name for a new word.... provide a number between 0 and 255 and get the binary sent without conversion.
I guess I am thinking a bit out loud. I may be able to create bEMIT myself.
Of course. I meant no disrespect. I meant to review and offer comments. The key to proper documentation is to have the targeted readership (everybody) read the draft and offer input while its being created, rather than after its "completed" when the comments are too late. Nothing against your docs or abilities, this is from working on large projects spanning years and involving large numbers of engineers. Just my suggestion.
Well this is neither a large project nor well-funded. You refer to 'your team' and all I can figure is that there are 3 of us. I try not to waste other's time out of politeness when they are doing stuff independently. And when they are working for me, I try not to waste their time as it gets very expensive.
....which, is the 64 bit encoded assembler optimization, so i guess that isnt much help. WTF? I thought the high level source was included?
Just a bit curious on how you got the Propeller to do 64 bit encoded assembler and how I am ever going to get up to speed on that. After all, the Propeller is a 32bit device. Please point the way to this bit of new news.
Comments
Sal is having lots of fun with the little robot design. He is happy with the physical lay out of the version 2 chassis, but will make a version 3 chassis that uses less plastic (and prints quicker.
It looks like the Little Robot default configuration will be built using a Quickstart board and a daughter card to plug in to the 40 pin header, or solder directly to the provided through holes. The quick start resistive touch buttons and LEDs will provide the first level user interface.
Sal has gone back over the stepper motor driver code. He decided it was a hack, and so went back to the math. It looks like the stepper algorithm works really well with fixed point math, so we can make an application of fixed point math as part of the demo. Its very easy and should help get folks with questions up to speed.
The new stepper code will have ridiculous precision compared to what the cheap steppers care about, but the same drivers will be applicable to any upgrade steppers we care to use. The new "very good stepper driver" isn't necessary for the little robot, but Sal feel as long as he's doing the work, its going to be RIGHT.
I asked about releasing v5.3 (nagged actually), Sal will do the cut over to the new code maybe this week. We will NOT include the Little Robot demo package at this time. But I figure the release and the demo are two different things, so the release can be staggered. Also, I'm starting to have trouble answering questions based on the previous release(s) while working with the new release.
After this release, be plan to redo the hardware test bed. The current version includes a prop board, a bare prop, and a spineret board. The majority of users do NOT have a spineret board, so we will separate out the spineret into a separate module. The spinerete, IP, Telnet and HTTP support will still be present, but an optional module. This should allow more folks to give it a try. We will alos try to structure it so the MCS is also a separate , optional module, as not everybody has a stack of bare prop chips laying around (yes, I know it sounds weird, but folks tell me its true). So while we're at it, we just might make the SD support a separate add on module, since not everybody is willing to sacrifice as SD adapter and commit an SD for prop internal use. SO the outline for Propforth Hardware Testbed might be:
1) Prop Board 32k (demo board, old Quickstart)
2) Prop Board 64k+ (protoboard, new quickstart, most third party boards)
3) Prop Board + SD
4) Prop Board + N additional prop chips (MCS)
5) Prop Board + Spineret
This way, any user can run at least some of the automated build and test. Which is REALLY powerful, it might eventually find a use.
We looked at this weeks two new issues: "UNKNOWN ERROR" and ".digit"
Thanks Loopy and Peter
Issue 167) "UNKNOWN ERROR" actually is a stupid message. We ALWAYS know the error, in the case of the SD (where this is typically seen), the message is:
"166 UNKNOWN ERROR".
166 error means the SD did not respond. We will put in the docs a list of the errors and what they mean. We DON'T want to waste kernel space with text for the messages, but the list will allow us to implement any messages we need in our final applications. Sal will change the messages to the form "166 ERROR"
And this is a good thing, that UNKNOWN has been bugging me since the SD support was added.
Issue 168) ".digit" Actually, I think this should be "todigit", as ".digit" is not a kernel word. The issue was that the word would accept letters beyond A-F, so it also accepts G-Z. Turns out that there are two things at work here:
1) propforth supports ANY number base, not just decimal and hex. Recall the decimal values can be forced in code by using d_NNN and hex values can be forces my using h_NNN. Notice that we can also foce base 63 by using x_NNN.
2) The kernel words are designed to work with ANY number base up to what the prop can handle. IT IS THE DEVELOPER'S RESPONSIBILITY to use valid values. If your application needs to check for valid decimal or hex digits, we have to write our own extensions to include such. This is propforth's design decision. Recall that in the non-development kernels, NO error messages are implemented. Not even stack underflow. Because they take up space, and are not needed in most final applications, particularly turnkey applications. .
So far, this functions correctly per requirements. Unless we get further detail on the issue, this will be closed as "not an error".
I use PropForth5.2.1.
I confuse how to install sd-system I don't have installed it.
I get spinnert.
I try to install sd-system.
I read below;
http://code.google.com/p/propforth/wiki/SDsetupREVISITED
After installed PropForthSDFastSerialKernel.spin, I copied sd_scripts.f to TeraTerm.
Result ;
I read Tutorial4.1.
Does I need to install eeprom-system before sd-system?
Why PropForthSDFastSerialKernel.spin don't use on Tutorial4.1?
Sorry, I forgot "power-cycle".
After "power-cycle", SD-system start up.
Enclosed is a ROUGH rough Draft.. if you get my meaning. At this point, I am wondering if I have used a good basis for what the true PropForth lexicon is or might be.
For the sake of efficency, I have converted the "Starting Forth Lexicon" to all lower case. I started out in Linux and used some old Unix utilities to create a sorted list of one word per line. And then I used the Unix utility "comm" to create a three column list of a) words unique to the Starting Forth Lexicon, b) words unique to the PropForth Lexicon, and c) words that both have.
In additon, I may notes of what I know as issues and observations about many of the words.
At this point, there seems to not be as much in common as I had hoped for. And that means that learning PropForth via beginning with Starting Forth might be harder than expected for some. If you happen to know a lot about the Propeller before you started, the learning curve is likely much easier.
I read SDsetupREVISITED
http://code.google.com/p/propforth/wiki/SDsetupREVISITED
There is mistake in "FILES on SD".
Not fsls, sd_ls.
How does files save to SD-card?
Can SD-card use as source-buffer when using"fl"?
I tried to serch Forth-sorce-code word[cd,cd/ cwd,fstat sd_cd,sd_ls,etc], I cannot understand them.
I want Forth-source code for PropForthSDFastSerialKernel.spin.
But I cannot find out these.
Where are these words's Forth-sorce-code?
Sorry, I'm getting confused from the release version 5.03, the beta version 5.2, and the final version (ready but not released) v5.3.
There are little details changed. The biggest thing at the monent for v5.3 is that all the doc must be gone over and corrected for detail.
from propfroothdevkernel.f:
\ 100 fwrite DevKernel.f
uncommenting this line writes the text that follows to file DevKernel.f on the SD, terminated by ... ( the ... is same terminator as on the EEPROM file system)
I believe fl is used with all text stream interpretation, until we get to the telnet interface, that is the only one that does NOT use fl, I think the buffering is done by the ethernet hardware.
This is the part of the docs we are straightening out. SWal is traveling for a couple weeks, hopefully we get this sorted out when he gets back. I'll try to put up a further explanation after I handle a brief emergency reading a bedtime story to one of the brainettes.......
Where is "propfrorthdevkernel.f"?
I cofuse because there are many PropForth's files(spin or f) and file-names is a near likeness.
I spent most of today banging away on the keyboard and trying to get this is a very nice state. Along the way, I have learned that maybe I could be most useful in a stylistic clean up of the PropForth.htm file so that it is a bit easier for the reader.
I will PM Prof. Braino with some suggestions. But the attached is just a limited listing of Section/Chapter 9 of the PropForth.htm.
At least for me, it makes study all the easier. And above it, I think I have discover the reasons that I have been ignoring the PropForth.htm and exploring other documents. I suspect this is very fixable.
In the interim, I will finalize a comparison of Starting Forth Lexicon to PropForth as I pretty much commited to doing so for the sake of any new Forth users. The tast has gotten a bit side tracked as I got into the PropForth.htm as the best listing of PropForth Lexicon. And there were very clear requests that is add functional groups to make it a more useful reference. I am in the process of doing all that.
Added strings in Report_Descruptors
Attached someting I noticed during writing Forth-code as Tips.txt.
I continue to upload sometimes it.
This is much better and will likely allow me to graduate from Starting Forth to just working with PropForth v5.03 (or better). I have been worried that other new Forthers have felt left to fend for themselves.
Thanks for the tips.txt!
This is a good example of what to do during development for a particular app. As caskaz shows, just write a bunch of extensions for your paticular app or driver. In this case, that text descriptors are invaluable diagnostics during development, but might not be needed in the final end user application after all the bugs are worked out.
The technique of defining all the messages in a one array that is indexed is a handy way to implement this. Great example!
Some interresting links
A Beginner's Guide to Forth (HTML)
Old, text-only version
List of on-line Forth tutorials, with links, other stuffLinks to various Forth-related sites
The ANS Forth Standard Document
draft v. 6, in HTML format ...in *.zip format
Forth system and example programs
All - when you post a new version, please increment the version number in a reasonable manner, and DEPRECATE the previous version. In search version drop down, you can sort by current version, or deprecated version. This keeps them without deleting them.
Version numbering scheme - what makes sense? Loopy's most recent example has versions in the name "revised" and "rev-two". Confusing versioning makes me crazy.
PLEASE consider using the following (or similar) as the version number.
At the time you make a post, look at the time, and make a string YYYYMMDD-hhmm . So right now it was November 20, 2012, at 6:23 am. This would be converted to a time stamp of
20121120-0623.
IF we use YYYMMDD-hhmm the file name will always sort in chronilogical order for the same file.
We see caskaz has similar for his tip.txt above. Caskaz implies that he will not be changing or at least posting his tips more than once per day. This is fine; all we need is some clue as to which came first. Braino recommends the "best practice" is to always to use the full data stamp, that way its present if you ever have exception that requires it (and there are ALWAYS exceptions) but its up to the individual doing the work.
This project is a turning into a good example of a team that follow some consistent set of standards, even though they are not required by any regulation and we are not doing it for pay. Thanks for participating in this experiment.
I expect opinions to upload my tips to this thread.
There might be mistakes.
I will upload to re-write Tips-documents to wiki later.
As caskaz says, we can use these forum discussion for soliciting review comments, feedback and opinions, and any other input on the materials submitted. All viewers are invited to add input to all items posted.
These wiki and downloads other the Google code prop forth site ideally should contain the current, most up to date version of the item under discussion. The same item may appear here in the context of the discussion, and on the propforth site. Thing is after the discussion moves on to the next topic, the materials get buried in the thread.
My though it that the actual item be posted in the Google site, and thread contain a LINK to that item. This ensures that there is exactly one copy of the item, and we don;t be versions messed up.
Of course there can be exceptions for any reason at any time. This is voluntary compliance with any "rule". This is just to establish something we can all depend on as the project grows.
This would be better in in the PF50 thread
Who told you THAT? It should have been "rather a lot of completely useless docs". The KERNEL is pretty complete, and propforth.htm is off to a good start.
But so far, there have been very few questions, and fewer contributions to the docs. The contributions have been very good, jut not so many.
If fact, Loopy has contributed more to the propforth documentation that any other single contributor, apart from my numerous initial drafts.
The documents are far from useless.... everything ever written goes through formative rough drafts. And Peter at TachyonForth seems to want to avoid any documentation other than what may become the world's longest Forth thread.
I'd say for someone that knows something about SPIN and PASM and Forth, there is quite a bit that is useful.
I just don't happen to be that person and we do desire a much wider base of users. Forth isn't that hard. I just want to make is as easy as possible for all the 'easily confused' people like myself. With 86 Wiki entries, there is quite a bit there. Improve the quality of what is on hand rather than provide more rough drafts.
Good writing is all about rewriting. I tend to go back and re-edit my Forth post at least 5 times for spelling and typos or missing content. I also try to tone down a bit of my rather forceful tone. Parallax must think I am trying to bust their servers.
I do accept that PropForth is non-ANS Forth and a minimalist Forth. Now it just has to be an easily teachable Forth with the ability to exploit wider examples of code from the decades of writing on Forth.
I thought there were only 3 Kernels, but you have recently posted some rather confounding (to me) stuff about other Kernels. And to be honest, I am still not even sure that Kernel is the right term for what a Forth system basically provides in code. That term Kernel was from OS system levels.
Please don't confuse beginners about where the FRONT DOOR is. There are 3 spin files that are ready-to-go -- A minimal PF Forth, a larger EEPROM PF Forth, and an SDcard supporting PF Forth. I guess these are all kernels as well.
You must think that people really want to begin by building their own from scratch. To me that is pretty advanced stuff. I am not ready to do so. And I have doubts about wanting to do so.
BTW, Casak's tip in #289 above is interesting - a bit of memory mapping. Still, I am not quite sure I am ready for memory maps. He is much farther along that I am, but I do peek at what he is writing.
I will try to contribute more documents, but not for quantity's sake. Whatever I write will have to be rather complete and of reasonable quality.
We expect all users to start there. Beginners may spend months with these, advanced user typically spend days or minutes before moving to building custom kernels. I think Brain needed a custom kernel after one day, but nobody else reported banging their head against the ceiling of quickly yet.
Eventual, some users will want to roll their own, that is want is done when one has an actual end user application to produce. Because we can fit a lot more app functionality when we remove the (unused and unneeded in the final product) dev support.
In my case, I always want the dev support in the final product, as its educational, so Sal made it easiest for me. But the other directories are where one build ANY arbitrary kernel from scratch, Sal made those easiest for him. Anyone can chose either level of complexity, or any in between.
Can any one read his docs and send comments? Or post here? More input is what is need to get things rolling.
Discussion of the docs is the experiment at hand.
Can anyone step up?
I was suggesting that everything might be improved by not writing more documents so much as improving what exists.
Several of the wikis by you and Sal have "Work in Progress" on them. Those are a high priority to become genuine. Especially the Dictionary specification and some of the overview Wikis of PropForth.
BTW, the Dictionary specification does have a typo in that it mentions the flags are bits 7, 6, and 4. I suspect that 4 should be a 5 as the rest of the 5 bits of that byte are suppose to indicate the number of characters in a words name.
~~~~~~~~~~~~~~~~~
I do have a more pressing problem though.
I need a 9600 8N1 serial port in PropForth that has a shared TX/RX pin for my Serial Inkjet Printer Board to interface with it. In other words, just one pin, not two. And not via the regular Console, another serial port. In other words, I need to have both the Console I/O available for development and another RS232 port for control of the printer head AND that has this half-duplex over one wire in TTL voltages.
Is this a big project that I might have to start from scratch? Or can I simply hook into the serial software that is on Cog7 and redirect its use?
The fate of the Chopstick Printer lies in the balance.
And, it seems that PropForth never considered support a 2nd RS232port. Oh my, I think I'm drowning........................................................................
Of course. I meant no disrespect. I meant to review and offer comments. The key to proper documentation is to have the targeted readership (everybody) read the draft and offer input while its being created, rather than after its "completed" when the comments are too late. Nothing against your docs or abilities, this is from working on large projects spanning years and involving large numbers of engineers. Just my suggestion.
Ah! A bit of fun!
Please see Propforth.htm 9.1.131 _serial
and Propforth.htm 9.1.300 serial
For the notes on how to set up and use the simple async serial function.
Also look in
..V5.0\kernels\BootKernel\BootOptimizeKernel\BootOptimizeFsrdKernel
serial.f
which, is the 64 bit encoded assembler optimization, so i guess that isnt much help. WTF? I thought the high level source was included?
Oh wait, look in
..V5.0\\kernels\BootKernel\BootOptimizeKernel\\BootOptimizeFsrdKernel
serial.f
This is the same 64 bit encoded optimization, except includes forth code for setting up the terminal (This happens to be a remote prop example, but that shouldn't affect how you are going to use it).
So, I don't know why I can't find the high level forth for _serial. It could be the the window search is acting up? Maybe not. This might be one of those things that is so elementary to the kernel that the high level forth was optimized out, just as with the support for the interpreter.
Anyway, next you want to look at
..\V5.0\kernels\doc\tutorials
tutorial-3.2 Serial Loopback.txt
This is the example of the code for serial being used correctly. You have to execute the prerequisite tutotislals to set up for this example. But it will show you the correct usage and execution for the serial function.
REMEMBER - you have to read the propforth.htm, look at the source code, and execute the example (tutorial). This is how all of propforth materials are set up. If you don't follow the instructions, it probably won't work unless you are an advanced user like Brian or caskaz.
I didn't run these just now, but I did run them about ten times when we did the testing, and the code hasn't changed, so I'm pretty confident this works. If it doesn't work the first time, please try it again.
Your chopstick printing is imminent.
EDIT
FOUND IT!
Yes, there is something weird with the windows search tool. The high level forth source for serial is in
..\V5.0\kernels\BootKernel
PropForthStartKernel.f
I don't know why windows search can't find text in a file.
Anyway, the forth source is used in the pre-optimized build, so this is supposed to be included in every release. And there it is.
EDIT 2
http://code.google.com/p/propforth/wiki/SERIAL
Is an explanation from and earlier release, but most of the general stuff should still apply.
No, its in there. The recommended process is:
Read HTM - Read source code - Do example
It's straighforward. Time consuming the first time through, but simple.
I will investigate the above and have looked at some of this already. The use of EMIT is not going to fully support the serial port. I need to sent ESC sequences and CNTL sequences - just having the visually displayed ASCII character sent out of the serial port is a dead end.
I can provide the raw 8 bit binary equivalents of the rather complex ESC and CNTL sequence conversions, but I require a binary equivalent of an EMIT, let's say bEMIT would be a good name for a new word.... provide a number between 0 and 255 and get the binary sent without conversion.
I guess I am thinking a bit out loud. I may be able to create bEMIT myself.
Well this is neither a large project nor well-funded. You refer to 'your team' and all I can figure is that there are 3 of us. I try not to waste other's time out of politeness when they are doing stuff independently. And when they are working for me, I try not to waste their time as it gets very expensive.
Just a bit curious on how you got the Propeller to do 64 bit encoded assembler and how I am ever going to get up to speed on that. After all, the Propeller is a 32bit device. Please point the way to this bit of new news.