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

Propforth v5.5 is available for download

1246726

Comments

  • max72max72 Posts: 1,155
    edited 2013-05-27 00:13
    Please find attached the stl I used for the wheels.

    Pla is quite rigid, so even if your participants are probably quite rough you can reduce the total amount of material to be used speeding up the print.

    Massimo
  • prof_brainoprof_braino Posts: 4,313
    edited 2013-05-27 10:02
    max72 wrote: »
    Please find attached the stl I used for the wheels.

    Posted!

    http://code.google.com/p/propforth/downloads/detail?name=Wheels-max72-20130527.zip

    Thanks!
  • LoopyBytelooseLoopyByteloose Posts: 12,537
    edited 2013-05-31 10:49
    I am having trouble with installed the EEPROM file system of v5.5 on a Propeller Demo Board.
    It does install the .spin image in /current release which works fine.

    Then I cut and paste the entire EEprop_boot.f and that seems to install as I get a report with fsls which includes boot.f

    But when I try to reboot in anyway, I am shut out. The USB to serial will not communicate with the Propeller Demo Board, powering down or pushing the reset button does nothing.
    I have tried the 'reboot <enter> ESC' procedure, but no luck.

    If I do not load the EEprop_boot.f , the system works fine.

    ~~~~~
    In need the EEprom file system for 'onboot' and also to store a large data file.
    ~~~~~
    Has anyone else had trouble with v5.5?
  • mindrobotsmindrobots Posts: 6,506
    edited 2013-05-31 11:03
    I haven't done much with it, yet.

    I may be able to play with this tonight: if circumstances allow ; if I can stay awake; if I don't zone out in front of the TV; if the Lord's willin' and the crick don't rise!

    EDIT: I did some playing. This is all on a QuickStart board.

    The first time I tried it: load fresh, cut/paste EEprom_boot.f into terminal, reset, hang.

    Then I started deconstructing EEprom_boot.f and had it hang with one sequence, then I was never able to reproduce it. I played around with the words that caused the hang and never got it to hang again.

    The sequences:
    hA state orC!
    
    and
    hA state andnC!
    

    are cool, they turn the interpreter echo, error reporting and such control bits on and off using the 'state' variable:
    \ state ( -- addr) access as a char
    \ bit 0 -  0 - interpret mode / 1 - forth compile mode
    \ bit 1 -  0 - prompts and errors on / 1 - prompts and errors off
    \ bit 2 -  0 - Other / 1 - PropForth cog
    \ bit 3 -  0 - accept echos chars on / 1 - accept echos chars off
    \ bit 4 -  0 - accept echos line off / 1 - accept echos line on
    \ bit 5 - 7 - free
    

    You could comment them out if you are still having problems, then you'd see everything the boot.f file did and may be better able to pinpoint the problem, but I digress......

    I finally ended up with this for EEprom_boot.f, which seems to work just fine. I added the 'cog?' command in there just to have the boot.f file actually do something.
    fl
    
    fsclear
    
    fswrite boot.f
    
    hA state orC! version W@ .cstr cr cr cr
    \ findEETOP ( -- n1 ) the top of the eeprom + 1
    : findEETOP
    \
    \ search 32k block increments until we get a fail
    \
        0
        h100000 h8000
        do
            i t0 2 eereadpage
            if
                leave
            else
                i h7FFE + t0 3 eereadpage
                if
                    leave
                else
                    drop i h8000 +
                then
            then
        h8000 +loop
    ;
    c" boot.f - Finding top of eeprom, " .cstr findEETOP ' fstop 2+ alignl L! forget findEETOP c" Top of eeprom at: " .cstr fstop . cr cr
    cog?
    c" boot.f - DONE PropForth Loaded~h0D~h0D" .cstr hA state andnC!
    ...
    
    
    

    as far as I've experienced, it works as advertised. (plus we learned about a new feature in the interpreter! :smile: )
  • LoopyBytelooseLoopyByteloose Posts: 12,537
    edited 2013-05-31 13:36
    @Mindrobots
    Thanks ever so much, I will try adding the 'cog?' that you suggest.

    And so, you were having it hang as well.... I have been trying to install this for several days and am stymied.

    If might help to know what 'boot.f' should look like internally. And another thing I don't understand is if one can evoke 'boot.f' as a command.. such as 'boot'.

    Every time I use reboot, the Propeller requires a complete reload to get it running again. Does this my the v5.5 /current release for PropForth EEPROM needs a change in the .zip file?
  • mindrobotsmindrobots Posts: 6,506
    edited 2013-05-31 13:49
    Mine just hung the one time, now I can't recreate the hang. (maybe some bad, invisible character in the file that disappeared when editing?)

    Try my EEprom_boot.f from post #95. You should just be able to cut/paste it into a FRESHLY loaded PropForth.

    Once you are up and running You can do
    fsread boot.f
    to see the text it contains, you can do this for any file on the EEProm file system
    You can do:
    fsload to actually load the file and run it through the interpreter. The one in post #95 runs fine this way.

    This is how you can extend your Forth. You can load .f files that define words, execute them and then forget them. Little PropForth batch jobs!!

    fsls - to list the files on the EEPROM
    fsdrop - to get rid of the last file you created
    fsclear - to wipe it clean
    fstop - puts the top address on the stack (do 'fstop .' to see the top address)
    fsbot - puts bottom (starting address) on the stack

    Actually, a pretty powerful tool to extend things.

    I just thought of one thing - I am running mine a 115200 so I can connect it more places. You could be dropping a character when you do the cut/paste if you are running faster. I rarely see that but one missing character and EEprom_boot.f could create garbage.

    Play more, see what you get, report back.

    It's NAP time!!!
  • Brian RileyBrian Riley Posts: 626
    edited 2013-05-31 16:07
    ....... uuuuuhhhhhhh .... Propeller Demo Board only has a 32K EEPROM .... you can install EEPROM.f but there's no place to put the files ... or did I miss something?????
  • mindrobotsmindrobots Posts: 6,506
    edited 2013-05-31 17:10
    ....... uuuuuhhhhhhh .... Propeller Demo Board only has a 32K EEPROM .... you can install EEPROM.f but there's no place to put the files ... or did I miss something?????

    Good catch, Brian!

    I read right past the board Loopy was using.

    I can go load up a Demo board, bet it won't work!! :lol:
  • prof_brainoprof_braino Posts: 4,313
    edited 2013-05-31 23:05
    I am having trouble with installed the EEPROM file system of v5.5 on a Propeller Demo Board.....Has anyone else had trouble with v5.5?

    As stated, EEprom kernel will load on Demo board but a stock unit with 32K EEprom will not have any place for files.

    On the Demoboard its recommended to use the SD kernel and do the SD-adapter-as-slot trick from
    http://code.google.com/p/propforth/wiki/PropToSDconnection
    and
    http://code.google.com/p/propforth/wiki/SDsetupREVISITED
  • caskazcaskaz Posts: 957
    edited 2013-06-01 00:34
    Updated DS1337.
    No function about A1M4/A1M3/A1M2/A1M1/A2M4/A2M3/A2M2.
  • LoopyBytelooseLoopyByteloose Posts: 12,537
    edited 2013-06-01 07:07
    Thanks, I seemed to have mixed up eeprom specs of my Propeller Demo Boards with my Propeller Proto Boards.

    I am switching over to a Propeller Proto Board for the 64K eeprom.

    It all seems clear now. The eeprom_boot.f file does set up the file system on the 32k board, but it just overwrites the .spin image that is required to reboot.

    Thanks.

    The goal is to simply emulate the QuickStart eeprom space as I do not own a QuickStart board. So no need to use an SDcard.

    On of these days, I am going to upgrade the eeprom on the Demo board.. just for convenience sake.
  • prof_brainoprof_braino Posts: 4,313
    edited 2013-06-01 09:01
    caskaz wrote: »
    Updated DS1337.
    No function about A1M4/A1M3/A1M2/A1M1/A2M4/A2M3/A2M2.

    WOW! Caskaz, your code looks great! I can completely tell what it's doing just by reading it.

    Now my goal is to improve my coding so it reaches this level.
  • prof_brainoprof_braino Posts: 4,313
    edited 2013-06-01 09:15
    [QUOTE=Loopy Byteloose;1187791 as I do not own a QuickStart board. .. just for convenience sake.[/QUOTE]

    Can I just send you a Quickstart? I have a bunch just to give away to folks that are curious, interested, helpful etc.

    You do so much that you should at least have the proper equipment. It REALLY helps to have identical hardware, it removes a whole class of "bugs".

    Please PM me your mailing address.

    NOTE: The protoboard does have electrical differences form the quickstart that will cause the two to behave differently depending on the circuit under investigation. IE the quick start only has the 3.3v regulator and can be powered from USB, this has cause changes from the protoboard version and quickstart version on Sal's and my experiments. Sal finally just got quickstart to stop my stream of "bug" questions.
  • fridafrida Posts: 155
    edited 2013-06-01 11:24
    Hi there!

    I have made a change in "a_next" which provides 30% faster throughput of Forth high level words.
    But there is something I do not understand, I need to insert a "nop", instead of the instruction I have removed?

    Code before.

    a_next
    a_debugonoff
    if_never jmpret a_dum_ret, # a_dum ' when debug is loaded this address will be patched

    rdword tregone,IP ' the next word
    test tregone, fMask wz
    if_z add IP, #2 ' if the one of the hi bits is not set, it is an assembler word, inc IP
    if_z jmp tregone
    rdword tregone, IP ' otherwise it is a forth word
    mov tregfive, IP
    add tregfive, #2
    mov IP, tregone
    call #a_rsPush
    jmp #a_next

    Code after.

    a_next
    a_debugonoff
    if_never jmpret a_dum_ret, # a_dum ' when debug is loaded this address will be patched

    rdword tregone,IP ' the next word
    test tregone, fMask wz
    if_z add IP, #2 ' if the one of the hi bits is not set, it is an assembler word, inc IP
    if_z jmp tregone
    'fjernet instr !PBP 'rdword tregone, IP ' otherwise it is a forth word
    mov tregfive, IP
    add tregfive, #2
    mov IP, tregone
    call #a_rsPush
    jmp #a_next
    a__maskin
    and stTOS, ina wz
    muxnz stTOS, fLongMask
    jmp # a_next
    'nop, der ikke betyder noget, men skal v
  • LoopyBytelooseLoopyByteloose Posts: 12,537
    edited 2013-06-01 11:34
    Some things are about personal preference. I have my own and try to respect other people's. And then there is the problem of international shipping costs.

    Since I reside half way around the world I am reluctant to have people bother with shipping me gifts as it is more costly than they expect when they offer to send. In many cases it is more than the cost of the item. It other cases, items just can't be easily sent due to weight or import/export restrictions... like lithium batteries.

    And I do actually have more Propellers than I have actually ever used. Costs have risen. Even the USPS now sends everything international by air, even books.

    More variety just tends to transfer to being more clutter at this point. Being a pre-QuickStart user, I have my 8 LED display, and other items that plug into the ProtoBoard. And you many not be aware that I authored a spreadsheet that lists the i/o variations for all the earlier Propeller Boards -- the Demo Board, the Hydra, the ProtoBoard, and a few more.

    I just forgot to check the size of the eeprom on the DemoBoard.

    For coding purposes the Propeller ProtoBoard and the QuickStart Board on not that different -- both have the 64k eeprom. Sure the QuickStart has 8 built in LEDs, has 8 touch switches, and can run directly from USB, but I am just working with the other i/o.

    I really do prefer the ProtoBoard with a complete VGA interface, and keyboard and mouse interfaces. And, I am very wary of devices that try to power everything from a USB port. So much of the Propeller ProtoBoard real usefulness is in providing VGA video with conventional interfaces. And the ProtoBoards in a 5 pack makes the shipping problem easier.

    Thanks for the generous thoughts.
  • prof_brainoprof_braino Posts: 4,313
    edited 2013-06-01 23:24
    frida wrote: »
    I have made a change in "a_next" which provides 30% faster throughput of Forth high level words.
    But there is something I do not understand, I need to insert a "nop", instead of the instruction I have removed?

    Thanks for the hint. I'll open an "enhancement" issue report, so Sal can take a look at it.

    I can't really tell from looking at the code what is impacted by the change. Needing a nop when you don't expect one is a warning that something is not quite right. To check if anything got broken, the test automation needs to be run. Are you able to run the automation?
  • kuronekokuroneko Posts: 3,623
    edited 2013-06-02 00:04
    frida wrote: »
    But there is something I do not understand, I need to insert a "nop", instead of the instruction I have removed?
    Looks like the dictionary has been generated for the before code. As it is just a dump it doesn't get updated automatically for your after changes. That said, the nop - if used - should appear before a__maskin but an updated dictionary would be the right solution.
  • prof_brainoprof_braino Posts: 4,313
    edited 2013-06-02 08:42
    frida wrote: »
    Hi there!

    I have made a change in "a_next" which provides 30% faster throughput of Forth high level words.
    But there is something I do not understand, I need to insert a "nop", instead of the instruction I have removed?
    .

    The nop is because the memory map has not been updated via a rebuild from scratch, so the nop can go away at the next full build.

    The full build process is not properly documented, must do build process steps, the kernel being used is different from the kernel being generated. So we just have to keep the sysmbol in order, update symgen. The full build process will be automated in PF6.

    Sal says, yes, that instruction is redundant. it will be removed in PF6, he's working on it now. .... more in a minute. still in the call.
    it makes the kernel one long shorter, and one instruction faster. a_next is run all the time, making it fast is a really good idea.

    Congratulations! This has been in here for a long time, and nobody else noticed it. Thanks a bunch!
  • fridafrida Posts: 155
    edited 2013-06-02 13:59
    Not only is it one instruction shorter, but that instruction takes 8 clockcycles, and it has to wait 12 clockcycles, before it kan be executet while it has to wait for the next hub windue. So it will make the routine 20 clock pulses shorter.

    So you ask: Are you able to run the automation? No, I can not find my way around in the documentation.
  • prof_brainoprof_braino Posts: 4,313
    edited 2013-06-03 07:02
    frida wrote: »
    Not only is it one instruction shorter, but that instruction takes 8 clockcycles, and it has to wait 12 clockcycles, before it kan be executet while it has to wait for the next hub windue. So it will make the routine 20 clock pulses shorter.

    If anybody asks, tell them braino says "FRIDA ROCKS!"
  • prof_brainoprof_braino Posts: 4,313
    edited 2013-06-03 07:07
    frida wrote: »
    So you ask: Are you able to run the automation? No, I can not find my way around in the documentation.

    The automation is the only way to make changes to the kernel and test that nothing got broken; as testing everything by hand would take months or years. It wasn't so difficult at first, but has gotten out of hand. I guess it time to fix this.

    If you are interested, PM me with your email, I can walk you through the process. I would use your feedback to clarify and document the current process.

    This offer is open to any readers of this thread.
  • prof_brainoprof_braino Posts: 4,313
    edited 2013-06-03 07:54
    Yesterday's Call:

    PF6 is going to be significantly more complex than PF5, the estimate is an order of maginitude. There is a specific requirement for real background processing and multitasking. There will be the same set of kernels, with some additions. We don't know if anyone besides Sal and Nick will be able to use this ability, but Sal definitely will, and its his tool. We can still use PF6 the same as previous version and on the Prop 1; but using the new multitasking features to their fullest may be beyond new user's abilities. That's ok, just don't expect to master crafting application multitasking on a microprocessor in one day.

    All the targeted functionality has been implemented in code in one form or another in Sal's projects, adding the completed code to the kerenl is not so much an issue. The majority of the effort will be testing. In this case we will perform what Sal calls "server style testing", where the focus is not so much "did it pass", but rather "did it run under full load 24/7 for months with no glitches". We will have something to test in a couple months. AFter release, the server style testing will continue, and will use the logging package extesnsion that we posted recently.

    Sal looked at frida's suggestion from issue 194. It appears that the instruction in question is in fact redundant, and should be removed. The nop can (will) go away after the kernel is rebuilt from scratch, with a new symgen file created in the build proess. Since a_next is called very often, this will have a significant speed benefit, and we reduce the memory footprint by one long. Thanks again frida! This change will be added to PF6. This issue has triggered forther scrutiny of that section of code. Kuroneko has found two make that three more changes to speed things up. Code review is usually impossible to get started, let alone get through; here is an example of the benefit it brings. Thanks all!

    Issue 192 was in fact a bug. The UNDEFINED WORD condition calls "clear keys" to clear the input stream, and it erroneously leaves a value on the stack. This is fixed in PF6.

    The build process will be easier next round, maybe we will get some documentation.

    The SR04 is giving me problems, I don't know if I have bad modules of the voltage is wrong (alkaline batteries vs USB), but changing to a long distance (greater than 1 meter) seems to time out and the SR04 measurement stops changing. We'll do testing this week, Sal's works, maybe I have loose wires?

    I sorted out detail in the bot.f program in the extensions directory, the changes are in the LittleRobot thread. Hopefully we will refine other offerings in the extensions directory as well, some of those are a bit rough. I'll have to post any changes to the non-kernel files from the download on the wiki.

    None of the changes we have found impact kernel functionality, so we still don't need another release for the PF5 series.
  • caskazcaskaz Posts: 957
    edited 2013-06-05 05:43
  • K6MLEK6MLE Posts: 106
    edited 2013-06-06 17:16
    Does PF have any support for the Dallas 1-wire components? If not, how difficult would it be to include it, perhaps in PF6?
  • caskazcaskaz Posts: 957
    edited 2013-06-06 17:32
  • K6MLEK6MLE Posts: 106
    edited 2013-06-06 18:26
    Awesome! Thanks caskaz. I want to use a Propeller to resurrect an old 1-wire weather station (the original from Dallas Semiconductor) that will allow the Prop to present the WX data to a small vga screen instead of the original requirement of having a dedicated PC. I trust it will run with PF 5.5?
  • K6MLEK6MLE Posts: 106
    edited 2013-06-06 21:27
    I have PF5.5 up and running and have looked at the 1-wire code. How would I output data to a TV_text display, much like TV_Text.spin does? Are there dictionary words already created that support this output?

    Thanks! I'm looking forward to learning PF and putting it to use!
  • prof_brainoprof_braino Posts: 4,313
    edited 2013-06-07 06:38
    K6MLE wrote: »
    How would I output data to a TV_text display, much like TV_Text.spin does?

    In the extensions directory, there is vga.f, that's as far as we took it. We tested the TV out put in 3.2, but the text was too clunky to be useful, and their was not much room for graphics. The thinking was that any modern TV has VGA input anyway, and an older TV would be a giant power hog. Of course, its still perfectly possible to implement TV in your project if you wish.

    Now that the kernel is optimized it may be easier to make something useful, but it is not on Sal's list at this time.

    See section 7 of the propforth manual in the doc directory to get started in assembler. You should be able to borrow the algorithm from TV_text.spin
  • prof_brainoprof_braino Posts: 4,313
    edited 2013-06-07 06:45
    It has been pointed out that the materials were getting harder for new folks instead of easier. As our knowledge increases, I loose touch with what new folks DON'T know.

    The questions that need to be answered are "What's the Goal?" and "Where do I Start?". I've been told that once these are answered, the materials can be found.

    I updated the Google code PropForth landing page to links to these pages:

    http://code.google.com/p/propforth/wiki/GettingStartedWithPropForth

    http://code.google.com/p/propforth/wiki/GettingStartedLittleRobot

    Could folks look at these and see if they could be simplified further, or better made to answer getting started? Thanks!
  • prof_brainoprof_braino Posts: 4,313
    edited 2013-06-09 21:49
    Tody's call:

    Sal is happy with the results of LittleRobot so far.
    Story: Kid spent $500 on a bot, but couldn't get the software to work. It was Arduino, there's tons of stuff, but much of it is proprietary. There are so many hardware configs, and nothing is the same. Kind of a mess, from the kid's point of view. There is a real need for an open source software to drive a bot.

    So, this give us our approach for LittleRobot. The $20 key parts and $50 kit price goals have been met. Can we make the hardware and software acessible?

    SR04 - Sal has found no issue with SR04 that would account for the error I see, which is the SR04 stops responding after a long measurement (greater than 1.5 meters). Today we realized Sal BOT 1 config did NOT use quickstart, and quickstart pins 16 and 17 have LEDs and drivers. These should not affect anything as far as we can tell. But I'm going to move to different piins and see if anything changes. Otherwise maybe I have a bad batch of SR04.

    PROPFORTH 6 Beta test: Sal is looking for folks to Beta test the Propforth 6 multitasking. Here, multitasking is different from just running different apps in separate cogs as infinite loops. The processing opportunities are spread over the available processors/threads. I kind of get the concept, but not really; so we'd like to find folks that really understand true multitasking to participate. He's looking for 2 to 5 people, and he will corespond directly with the folks, rather than through the forums. Please PM me if you are interested trying this out and providing input. Anybody know how to describe a program as a bunch of parallel things?
Sign In or Register to comment.