Shop OBEX P1 Docs P2 Docs Learn Events
Propforth v5.5 is available for download — Parallax Forums

Propforth v5.5 is available for download

prof_brainoprof_braino Posts: 4,313
edited 2015-11-28 16:27 in Propeller 1
Propforth v5.5 is available for download from Google code

Propforth 5.5 is now on GitHub

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.


  • prof_brainoprof_braino Posts: 4,313
    edited 2013-03-17 10:45
    Today's Call

    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! :) ) along the lines of the JupiterACE. Turns out that VGA support and the development kernel both consume a lot of the prop resources, so one or the other is great, but both gets a little crowded. In the course of the last five years, netbooks, smart phones, and android tablets have come into the picture. NOW all the UI can be off-loaded to one of these devices, leaving the prop open to do our embedded cotrol system for the robots, etc. Sal is looking into a java script solution to run on an external device and manage a user interface to the prop.

    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.
  • prof_brainoprof_braino Posts: 4,313
    edited 2013-03-17 12:21
    I just notice I put up the file with the wrong name. Now the name is corrected to be constitent with previous releases, the content is the same.

  • caskazcaskaz Posts: 957
    edited 2013-03-18 05:06
    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.
    : test d10 0 do i . loop ;
    decimal     \ There is no empty line in last.
    If this is saved, loading by "send file" re-start by return-key.
    If you use copy/paste on TeraTerm, no problem.
  • prof_brainoprof_braino Posts: 4,313
    edited 2013-03-18 08:23
    caskaz wrote: »
    ... DevKernel... "send file" on TeraTerm...."fl" ... 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.
    : test d10 0 do i . loop ;
    decimal     \ There is no empty line in last.
    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?
  • prof_brainoprof_braino Posts: 4,313
    edited 2013-03-19 08:28
    Please notice the extensions directory in the download, under Current Release.

    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.
  • mindrobotsmindrobots Posts: 6,506
    edited 2013-03-19 08:39
    Can we get a free copy of PropForth if we help?? :lol:

    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!
  • prof_brainoprof_braino Posts: 4,313
    edited 2013-03-19 08:43
    Please note the misc directory. It is NOT under current release. this is the new stuff still under development. Anybody can look at this stuff, but it might be hard to use for a beginner (or me for that matter).

    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
  • prof_brainoprof_braino Posts: 4,313
    edited 2013-03-19 09:02
    mindrobots wrote: »
    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 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.
  • prof_brainoprof_braino Posts: 4,313
    edited 2013-03-19 09:27
    Please notice the v5.5 kernel is supposed to be fucntionally identicle to 5.0 kernel. All we did was use 4.5 to gener ate 5.0, then use the generated 5.0 to regenerate a new 5.0, and test that these two resuflts were the same. The kernel has proven fo be stable. Using to 5.x generated kernels, we refined the automation and packaging. We also struggled witht he documentation, and kept coming back to the same method, which is Sal authoring Propforth.htm as the core refernce, with the absolute necessary and sufficient to cover the core. All the remaining documentation is to come from the community. This means that further materials will be driven by user questions, and the hopefully the users will begin to supply ansers to each others questions.

    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?
  • caskazcaskaz Posts: 957
    edited 2013-03-20 00:39
    Hi prof_braino.

    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?
  • prof_brainoprof_braino Posts: 4,313
    edited 2013-03-20 06:53
    caskaz wrote: »
    Hi prof_braino.

    There is not kernel-directory in PropForth5.5.

    Under the misc directory, find 2013FEB23mygo V5.5

    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 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.
  • SapiehaSapieha Posts: 2,964
    edited 2013-03-20 08:34

    Sorry that it is not PropForth code.

    But maybe will still be usable for any of You.
  • prof_brainoprof_braino Posts: 4,313
    edited 2013-03-20 08:53
    Sapieha wrote: »
    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!
  • SapiehaSapieha Posts: 2,964
    edited 2013-03-20 09:55
    Hi prof_braino

    Good to hear.
    Actually, this is applicable to a project in the works. Thanks!
  • iammegatroniammegatron Posts: 40
    edited 2013-03-22 08:22
    By looking at "", I am able to save a simple program by typing the following at "tera term"

    : demo 16 pinout 16 pinhi ;
    : onreset1 onreset demo ;

    My question is where can I find the doc for "onreset1". Is it called during reboot? What does "onreset" do?
  • prof_brainoprof_braino Posts: 4,313
    edited 2013-03-22 08:38
    By looking at "", I am able to save a simple program by typing the following at "tera term"

    : demo 16 pinout 16 pinhi ;
    : onreset1 onreset demo ;

    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.
  • mindrobotsmindrobots Posts: 6,506
    edited 2013-03-22 08:56

    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.
  • prof_brainoprof_braino Posts: 4,313
    edited 2013-03-23 07:23
    mindrobots wrote: »
    t this document

    that is a really handy list. did you post the script? if not, maybe add another section at the bottom of the page with the code pasted in?

    remember, this list is of all definitions in the source, they are not all present or used at the same time. the kernel build words are only present during build. the lowest level stuff is sometimes hard to figure out where and what the definition is. if you make any head way on the really deep ones, please post. thanks!
  • iammegatroniammegatron Posts: 40
    edited 2013-03-23 11:51
    Thanks a lot for the quick reply. Now I am trying to follow the "PropForth.htm" to define assembly words. (Tera Term; quickstart board)

    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
    ;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

  • caskazcaskaz Posts: 957
    edited 2013-03-24 06:16
    Hi iammegatron.
    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.
  • prof_brainoprof_braino Posts: 4,313
    edited 2013-03-24 10:00
    Todays call

    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:

    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:
    • creating an assembler routine
    • converting an exsting (high level forth) routine to assembler
    • using a routine with paged assembler
    • using paged assembler from EEprom
    • Using paged assembler from SD
    • Paged assembler from SD example application

    ** 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.
  • Duane C. JohnsonDuane C. Johnson Posts: 955
    edited 2013-03-24 12:18
    Hi Professor:

    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
  • prof_brainoprof_braino Posts: 4,313
    edited 2013-03-24 13:17
    I don't know it there is a particular routine that does this. I know Sal manually checks which words are used, and which words are exectuted most often. This is how he knows which words to optimize in assembler and which to leave as is. Sal kind of "just knows" after a lot of very thorough analysis. This process has not yet been documented (although I may nominate someone to author this shortly) :)

    Here's what we do know:

    A) The DevKernel has lots of developer support that is unneeded in a final application.

    B) The BOOT KERNEL is unoptimized and with no developer extensions. If you look at the build process, there is a point in the beginning where we start by rebuilding boot kernel. I belive this is about as minimal as you can get and still have something that works.

    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.
  • iammegatroniammegatron Posts: 40
    edited 2013-03-24 17:01
    hi prof_braino, thanks for the help. Yes, I re-flash my propeller and load asm.f with success. I think I used asm.f in v5.5/misc/ before.

    Still learning to use PropForth.
  • prof_brainoprof_braino Posts: 4,313
    edited 2013-03-25 08:48
    hi prof_braino, thanks for the help. Yes, I re-flash my propeller and load asm.f with success. I think I used asm.f in v5.5/misc/ before.

    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.
  • prof_brainoprof_braino Posts: 4,313
    edited 2013-03-25 14:40

    Opened issue 190 to capture your question
  • prof_brainoprof_braino Posts: 4,313
    edited 2013-03-28 07:50
    Any propforth user also Ubuntu user?

    I started looking at the context highlighter in gedit.


    I think we should copy
    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?
  • caskazcaskaz Posts: 957
    edited 2013-03-29 07:20
    I modified V5.5/misc/4step.f.
    I used SPG20-1362 as stepping motor.
  • prof_brainoprof_braino Posts: 4,313
    edited 2013-03-31 10:11
    Today's Call

    * 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.

    B) Maximize available resources by "running from external memory":

    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.
Sign In or Register to comment.