Propforth v5.5 is available for download
prof_braino
Posts: 4,313
Propforth v5.5 is available for download from Google code
http://code.google.com/p/propforth/downloads/detail?name=PropForth-V5.5-20130317.zip
Propforth 5.5 is now on GitHub
https://github.com/prof-braino/PropForth5.5
Thanks to the team members and users that help with testing and documentation, this is the hardest part. Thanks for your patience with getting the release up.
The kernel is unchanged since v5.0, only the packaging has been modified to be easier for new users to get started with the kerrnel. The build and test automation has been moved to a subdirectory, since it is only for advanced users; most folks won't use it until they are comfortable with using the kernel.
The kernel itself is very stable, we don't even see interrmittent issues. That might mean we've been looking at it too long, hopefully new sets of eyes can discover and point out things we've missed.
Focus is now shifting from developing the kernel to using the kerrnel. Now the REAL fun begins!
Please give PropForth v5.5 a try. In particular, try to follow the docs included in teh download, and let us know what neds to change. Post comments and questions here or on the google code site, or PM me.
http://code.google.com/p/propforth/downloads/detail?name=PropForth-V5.5-20130317.zip
Propforth 5.5 is now on GitHub
https://github.com/prof-braino/PropForth5.5
Thanks to the team members and users that help with testing and documentation, this is the hardest part. Thanks for your patience with getting the release up.
The kernel is unchanged since v5.0, only the packaging has been modified to be easier for new users to get started with the kerrnel. The build and test automation has been moved to a subdirectory, since it is only for advanced users; most folks won't use it until they are comfortable with using the kernel.
The kernel itself is very stable, we don't even see interrmittent issues. That might mean we've been looking at it too long, hopefully new sets of eyes can discover and point out things we've missed.
Focus is now shifting from developing the kernel to using the kerrnel. Now the REAL fun begins!
Please give PropForth v5.5 a try. In particular, try to follow the docs included in teh download, and let us know what neds to change. Post comments and questions here or on the google code site, or PM me.
Comments
We decided we can't make any further improvements without user input. The kernel itself has been stable for over a year. The only changes have been to the organization of the download and documentation. The build and test automation is still included, now its in a subdirectory. Previously there had been confusion about whether the automation is required to user propforth. The automation is not required to use propforth. Th automation is only required for Go-Language support, for the automated build and test. Casual users and beginners will only use the standard dev kernel. Anything beyond loading the kernel is optional.
Focus is now on using propforth. It looks like the LittleRobot demo will continue to be the example configuration. This means a Quickstart, a HC05 bluetooth module (wireless, cable replacement), some sensor and some actuator.
We're trying to figure out how to handle this. My initial goal was a stand alone development environment (achieved!
REQUEST: We need folks that are conversant in both forth and java script. This is a fairly unique skill set, please don't be shy. Sal needs your input on how to we can approach this. Sal started an android app which runs on the phone and talks over bluetooth. It talks to a prop on the other end of the bluetooth and serves as a programmable GUI interface to propforth. IT IS TOTALLY COOL. Its not at all documented, unsigned, and seems to do everything we need. Email or PM me if you want to try the Alpha. (I got it to work, so its actually pretty easy). We need to figure out how to go from demo to App.
Anyway, it looks like the next iteration of the JupiterACE will NOT rely on VGA + keyboard as the interface. The GUI may be offloaded to an android device for the cost of a HC05 bluetooth, and two prop I/O pins.
Cheers!
I wrote GraphicLCD And LCD-drivers for PropForth5.5.
Now, GraphicLCD can use on 2 LCD(WD-2406B and DMF-51026).
I installed DevKernel(no SD/no eeprom).
I often use "send file" on TeraTerm.
I found out WORD"fl" do strange on PF5.5.
If there is not empty line on last of source-code, "fl" stop as soon as starting file-load and file-load re-start after typing return-key.
I think this is caused by speed(230400bps). I don't know details. If this is saved, loading by "send file" re-start by return-key.
If you use copy/paste on TeraTerm, no problem.
Hi caskaz
I never tried "send file" before! That's cool! To your issue:
The word "fl" requires a line terminator at the end of each line. If there isn't a terminator after the last line, fl does not exit. I think this has not changed.
The comment in the last line makes send file APPEAR to work correctly, but I just tested it and it does NOT terminate. Running word TEST does not execute, as the definition has not been terminated correctly, as fl has not terminated correctly. (To reproduce this, make sure you reboot or reset the prop between experiments, or you may have a previous valid definition for test which is fooling you.)
edit - did this work out, or did I nor understand the issue?
This includes the non-kernel support extensions that Sal uses frequently and feels are completely debugged and stable.
This has kernel extensions:
software float, double math, assembler, MCS (go channels or CSP channels to everyone except heater), snet (interprop async serial) term (serial terminal driver for snet) wordlister (lexical order for dictionary), Logic Analyzer (capture pin states and transistion in real time, halfduplexserial (from loopy's investigations)
This also hase drivers for hardware add-ons:
ds1302, sr04, hc05, bpm085, VGA, servo, stepper (4step), littleRobot (bot)
The big task is to document these. I was thinking these would be an opportunity to increase community involvement. Any team member can start a wiki page for any of these, and post just about anything regarding the function. We can reveiw and check each others work, add examples etc.
Anybody up for this?
The software extensions are fairly simple, but extremely powerful once one gets familliar with how to use them. They offer insightinto how Sal codes, and how a developer of his level constructs functions.
As time permits, I may help. I was excited to see the extensions folder. Some actual usable examples to start off with!
I currently have "Cheap Robot" versions build with steppers, so there's hardware that can be tested with a number of languages: Spin, PropGCC, Forth, 12 Blocks, etc. so that effort is going on. That should cover sr04, hc05, stepper an any robot code in littleRobot. None of my 4-H kids have mentioned doing their projects in Forth, yet!
If you look in here, take a peek at GREEN. This is the work on using an android device as a generic interface to propforth and propforth applications. The idea is an android app runs java script. it sends out text, for example over blue tooth. This goes to for example HC05 serial cable replacement on the prop (for example on the quickstart, with propforth recompiled using HC05 on pins 24 and 25 for serial instead of 30 & 31). The text sent could be forth scripts.
Green also recieves text from the communication channel, and can put this on the screen.
The android app supports touch buttons. These can be configured from the code on the prop (in EEprom or on SD) . So any prop can tell GREEN "this is what my buttons look like, and this is what they do".
Because its scripts, none of the application need affect the prop dictionary. Or it could temporarily add definitions, then forget them what execution is complete, so there is no additional dictionary space is consumed.
Anyway, this is the next thing we will be working on. Sal uses it everyday and it works great. But its a little involved if one doesn't know the reletionships and interfaces to tall the parts. We have organize it such that regular users like me can use it. Mostly reorganize and document.
We think this might be suitable method for something like JupiterACE or OBC's Prop Minicomputer BASIC
Great!
If you could start a wiki page for any of the parts you experiment with, I would greatly appreciate it. Just log in and edit for example SR04 or SR04ultrasonic (which do you think is better?) and it creates a page automagically.
Please let me know if there are any differences from your cheap robot and my cheap robot (or Garth's or ercos or any of the others)
Usually folks don't consider forth until the method they are using proves inadequate in some way, and they NEED to explore other options. That is the point at which they tend to have enough perspective to notice and exploit advantages of forth. If they are fine with SPIN or BASIC, then leave forth till later. This is a long term project, propforth will still be here. I think I am the only one that is specifically trying to start kids with forth, this is probably a good thing. Must be very careful with kids lest they become evil mad scientists.
So far we have two type of user supplied documentation: The wiki pages (mostly from me, unfortunately) and sepaterate downloads authored by team members (thanks guys!)
I tend to rely on the wiki, as I like to have an internet connection running while I work. The separate downloads have an advantage for work offline (but it doesn't show who the author is). I have not noticed much feedback on the downloads nor the wiki pages.
This information should be a two way flow. Many of us raised in the TV generatation (per internet) tend to consume the media, but are not accustomed to responding and actively participating and guiding its creating and development. We think there may be 451 folks with questions and answers about propforth and forth applications. Please participate!
How to to evoke more interaction with the community at large?
There is not kernel-directory in PropForth5.5.
Kernel-sourse(Forth source of dictionary) cannot watch?
Kernel-sourse(Forth source of dictionary) is same as PropForth5.2?
Under the misc directory, find 2013FEB23mygo V5.5 RC1.zip
This is the full release:
* Propforth.spin kernels source and extensions,
* documentation,
* Go languge source and setup,
* build and test automation scripts and reference results.
2013FEB23mygo V5.5 RC1.zip is the internal release package Sal sends out. But because it is centered around the build and test automation, it was confusing for folks that only wanted the pre-built kernels. Folks were worried that they would be required to run the automation in order to use forth. So we moved the full release packed (still zipped) to the misc directory, move the kernels to the top, and deleted the unzipped copies of the automation files, re-zipped to make the final release package.
So everything is still there. The advanced material is a little buried so it doesn't confuse newcomers.
The differences in teh 5.x kernels is the packaging, and which version of kernel that was used to generate the release package. For example, 5.2 was used to generate a new v5.5, then the new v5.5 was use to generate itself (v5.5) again and the results were check to ensure the behave identiaclly.
I'm pretty sure that code for any 5.x release will work the same on 5.5. Please let me know if the is not the case.
Sorry that it is not PropForth code.
But maybe will still be usable for any of You.
Actually, this is applicable to a project in the works. Thanks!
Good to hear.
: demo 16 pinout 16 pinhi ;
: onreset1 onreset demo ;
saveforth
My question is where can I find the doc for "onreset1". Is it called during reboot? What does "onreset" do?
onreset is called by prop forth as part of the reset process. you can add your function to on reset by defining
: onreset onreset myword ;
this ensure onreset does whatever it used to do, then does what ever you define in myword.
onreset1 is specific to cog1, onreset2 for cog2, etc
I don't know the nuts and bolts of the internals' you would have to dig thru the kernel source for that, we usually don't care unless we are on the kernel optimization team.
all the current words are listed in prop forth.htm
if the entry is not sufficient, please let me know what should change so I can update it.
You can look at this document on the wiki to get an idea where a word is defined (this is for release 5.0, I need to rerun for 5.5) and then go look in the propForth code (not much help if you are just learning Forth but it's a start).
For example, onreset's entry from the index:
onreset ('bootPLAB23.f', 698, 700) ('PLAB0boot.f', 226, 228) ('PLAB0_boot.f', 226, 228) ('PropForthDevKernel.f', 1105, 1147) ('PropForthStartKernel.f', 2503, 2505)
from this you'd go look in the PropForthDevKernel.f file between lines 1105 and 1147 or PropForthStartKernel.f lines 2503-2505. The line numbers may be off because of
different releases but it should be close. I usually ignore the PLAB files if looking for a definition but they are good for ideas.
When I get a new release, I usually end up copying all the .f files to one directory (I also leave them where they were for the release). I use it as an online reference.
I certainly don't understand much of the kernel code but it's helpful sometimes to find words or see how things have been done by someone that really knows Forth.
First to load the "asm.f" seems to take a while (even after I add "fl" at the beginning of the file"). Then when I pasted in :
build_BootOpt :rasm
jexit
;asm noop
It said "UNDEFINED WORD jexit"
I am able to see C" jexit" in line 618 of the asm.f So I pasted in from lockdict stringmap _asm .... till freedict
But it still tells me "jexit" undefined.
Please help
Welcome to PropForth world!!
It shold be able to assemble.
Please check section7.2 for v5.5/doc/PropForth.htm again.
There is asm.f in v5.5/CurrentRelease/Extentions.
There are several possible projects in the works. These are in the exploration phase.
* Learning Propforth -
The primary propforth reference Propforth.htm is written by and for a person conversant in forth. This may be too obtuse for new users, particulary kids or their semi-interested parents. While the existing general forth referencs do a great job of discussing generic forth, I think theres a need for "getting stuff to work" type docs geared for kids in particular. I'm taking this task for the time being.
* Documentation for extensions:
Propforth.htm (included in the download) is the primary refernce for the propforth kernel.
So far there is no particular reference for the extensions. Aside from the software Logic Analyzer (lac.f) in section 5 and assembler in section 7, none of the extensions are covered.
** Logic Analyzer LAC
This is cool. If folks need a logic analyzer, they already have one, and if they don't have one they usually don't know how to use one. The propforth Logic Analyzer implemented in software is really cool if you'v never played with a logic analyzer before.
I'm starting with lac.f and making a wiki page. My thought is to provide more detail to suppliment propforth.htm section 5, and then provide another example using a known application. For now, I'm using Caskaz's propforth implementation of the Quickstart touch button demo.
Please check out lac if you have a quickstart and a few minutes to spare. Its grreat! This page might not be so great, but its a start:
http://code.google.com/p/propforth/wiki/LogicAnalyzerLAC
Please send feedback. You help is appreciated.
** Propforth Assembler
There have been several requests concerning propforth assembler. Please share your notes and findings. We want to start with the instuctions in section 7 and build on that to create beginner instructions for:
** All the other extensions
Anyone may also create documentation for the other extensions. Chose one that looks like fun (and you have the parts). Start writing the steps to get the part to work. You can follow the pattern of the existing wiki pages, or try something else. Your input is appreciated.
If you've made extensions in the past that have not found their way into the release, please take some time and create a wiki page. Even if its just a cut and paste of the code, it will be a start. The intent is the creation and documentation of extension will be eventually be driven by the community at large. Author a page and become famous! (at least among propforth users).
* Possible project - BASIC in Propforth
There's been a lot of background discussion for some time now on BASIC implented in forth. Historically, BASIC implemented in forth has been an early project on many platforms. Its relatively quick to implement BASIC in forth (faster then for example pure assembler) and can be easier to maintain (or harder, depending on the skill and discipline of the team).
Implementing BASIC in Propforth may have several advantages. Execution speed should be significantly faster than a spin implementation. Propforth may provide options tfor dealing with other resource limitations.
The existing BASIC implementations have already maxed the resources of the prop. Further expansion requires more memory and other resourrces. Typically the memory added is expensive RAM.
We did some general noodling about [PropForthv5.5 + PagedAssembler + SD => BASIC]. SD is super cheap cost per gigabyte. With the simple (non dev) kernel, a BASIC interpretter should only take about 8-10K leaving tons of room for apps. Having the BASIC functions reside on SD and streaming them in should be crazy fast. As long as writing to SD is kept to a minimum (logging, periodic file saves) it should run like a bat out of hell. (Exactly how fast DO Chlrotera exit the underworld? This might be out of scope and require a separate investigation).
In any case, this has the potential to be a fun project for forth, and additionally be beneficial to non-forth folks. More as this develops....
* Generic Android Interface
I'm really loving the idea of using an android device as a generic interface for propforth development. So far the drawback is that it requires external hardware (the cheap HC05 bluetooth module) and the obstacle is the unsigned android app. It uses significantly less resources than VGA + key board support. While VGA support is very appropriate for and final APPICATION, it is clutter when required as support for the development environment. Offloading the display and user interface to a common, generic device is an attractive solution. PM me for info on the prototype.
Many years ago I had some discussions with a forth expert at Unisys. Ya, forth was used in the supervisory control software of many of our machines.
I was running out of memory in an Intel 8052 using Bryte Forth. Mostly because of data space for a DtoA application.
Anyway, I asked about optimizing the forth kernel by throwing away unused words from the dictionary. He called it an optimizer. This freed up quite a bit of memory so my program would run in the allotted size.
Do we have something like this in PropForth?
The way it worked was to search for unused words, i.e, words that are not forward referenced. As I recall this was relatively slow as each time a word was removed it started a new search until no more unlinked words were found.
His program was quite aggressive, so forth often was not able to be extended unless the process was started over. But my application fit and ran rather well.
BTW, this was a weather device that measured hail stone size and quantity.
Duane J
Here's what we do know:
A) The DevKernel has lots of developer support that is unneeded in a final application.
Here's an idea: If we were to take the boot kerrnel, and optimize it to use paged assembler, and run off of either EEprom or SD, we might be able to have the dev extensions (and maybe everything else) reside on EEprom or SD. Your Application could then also reside on SD or in EEprom. This is just off the top of my head, I don't know if I'm thinking about this the right way. Sal didn't do this before, prossibly because we didn't suggest a use case like this. It might be a very cool, general solution. It could fit with the BASIC project, maybe even provide a starting point for that.
In any case, it involves rebuilding a custom kernel. Sal may or may not have time to do this for us, but he cetainly would answer questions. And it sound very cool and worth while.
Does this sound like what you are looking for? Care to give it a try? I'll run it by Sal and get his advice. Maybe some of the other users will help too.
Still learning to use PropForth.
Me too! Remember, reboot between experiments, its very common for a simple typo to change something you didn,t expect. Much easier to start clean than try to undo some unknown effect. Also, if you saveforth and find you need to change a savforth'd definition, just re-burn the kernel using proptool, at least till you start getting comfortable with the dictionary, etc.
caskaz is still the best person to ask about converting functions to propforth assembler. He does more assembler optimiation than anybody except Sal.
Opened issue 190 to capture your question
http://code.google.com/p/propforth/issues/detail?id=190
I started looking at the context highlighter in gedit.
IN
/usr/share/gtksourceview-3.0/language-specs$
I think we should copy
forth.lang
to
forth-propforth.lang
and modify the file using Section 9 of propforth.htm and Ricks wordlister from the wiki.
Is this the right way to do this?
Does anybody want to take this task?
I modified V5.5/misc/4step.f.
I used SPG20-1362 as stepping motor.
* 1: Talked about Issue 190 *
A) Duane's question:
To directly answer Duane's question, there is not yet a function to check that dictionary entries are called by other functions. Such a function should not be difficult, just a little involved; one would have to get familliar with the dictionary structure and compare link fields.
But this excercise might not be necessary. Conside that the INTENT of such a word is to determine the minimum wordset required to run forth, to minimimize the dictionary footprint to allow maximium space for an application.
This has already been provided with the BOOTKERNEL. This is the propforth kernel with no-nuthin' added. No "noisy" reset messages, no stack dump, no build? etc. Still is where Sal starts when he needs max space for the application, the sugestion is to give this a try since the work is already done.
Also consider the BootOptimizedKernel. This is the BootKernel optimized in assemble. It is smaller and faster, being in assembler. This should be what you want. This is the recommended starting point for minimum kernel, and the result Sal's many iterations on BootKernel.
All the developer extensions can be found in devkernel.f and can be added or omitted to any boot kernel to suit your needs. This may be the solution that answers this need. Please post if this assessment is incorrect or if there are additional factors to consider.
This model was used in the http kernel (done in the build and test automation, if you want to take a look). A minimal kernel is activated at boot time, with support for access to external memory, EEprom or SD. Various applications function require the entire available resource of the prop. When a given function is needed, that application subsecion is loaded into memory, executed, and the result saved. The application subsection is "forgotten" fro memory, and control returns to the "supervisor application", a minimal loop that just calls the sub applications as needed.
The choise of minimal kernel is EEprom or SD, either/or, not both. We tried both, but turns out that if you have SD, the EEprom is just in the way. EEprom suppot takes under 1K and gets an additional 32k, 64k or 128K (so far). SD support costs under 5k, and gets 4Gig to 32Gig (so far). If you ned tiny, use EEprom, if you need huge, use SD. Sal will look at both, I'm leaning towards SD.
Example Application for SD model:
Using the "execute from SD model" might be nice for something like a BASIC interpreter inplemented in propforth. The highest level supervisor loop listen for input from the user, and look for functions on SD. In the case of a BASIC interpreter, example functions could be print, run, and edit.
Print: 'print' would be a "file" on the SD that contains the implementation of the BASIC print function. When a BASIC program has a PRINT, this file is called loaded, executed and forgotten. The source could modified or updated at will, and no net resources are consumed. The function need only fit in available memory. If the function were to grow beyond the size of available memory, it could be further split into subfunctions.
Run: 'run' would be a function on SD that reads a file of BASIC source code from the SD, and executes it. Execution would consist of calling an executiong the defintion files for the sequence of BASIC words.
Edit: The 'edit' function would be loaded into memory when called. Edit would manage loading source files into memory, modifing them, and writing them back to storage. It could also handl statment numbering. It could also launch the 'run' word for the file in memory, or any file on SD.
My task is to talk to OBC and find if this might be interesting to try with COLORBASIC.
* 2: LAC wiki page *
I started a wiki page with more detail on using the software Logic Analyzer included in the propforth extensions. The goal was to work through the example in PROPFORTH.HTM and end up using LAC to look at the Quickstart touch Demo.
Some observations:
Tiny, fast loops like SCAN_BUTTONS and LIGHT_LED running of separate cogs are Too Fast! I could not capture the touch buttons bouncing. The hundreds of nanoseconds for the loop gets lost compared to the 22 millisecond for turning the LED on. By the time LAC detects the transition and reads the pins, the state is already stable.
I had to put the scan button and light LED functions in the same loop on the same cog. The LEDs would only light dimly, the loop was resetting the state before the LEDs could light. I ended up putting a 1 millisecond delay (smallest possible with that function) after the LED is illuminated, this returned maximum brightness.
I also had to change the sample period from 40 clock cycles to 41 clock cycles. At 40 cycles, only 193 samples are collected (there isn't enough time sample more at 40 cycles or below). At 41 cycles and above, LAC coolect sample to the end of available memory, in this case 2724 samples.
With this set up, I could see the button transistion and a few bounces. The bounces look very long from a few to a dozen samples. Then, 635 ns later, (hundreds of samples later) the LED transisions to HIGH.
So I got it to work as I expected, but really, the example should have a little more substance that lighting an LED to show off LAC. I'm going to finish writing up what i have, and wait till a better example come along.
* 3: Low Power Mode *
Next task is to solder up an HC05 bluetooth to a QuickStart, load GREEN android application, run from a 4 AA batery pack, and play with low power mode. Sal says propforth goes to sleep until you hit a keypress. Normal mode lasted some hours on batteries for continuously sending the WORDS command output. Now I will see how long it lasts from batteries using "sleep till queried" mode.