Shop OBEX P1 Docs P2 Docs Learn Events
PropForth4.6 is available for download - Page 2 — Parallax Forums

PropForth4.6 is available for download

2456

Comments

  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2011-08-26 00:03
    The 10K pull-up is a little high for I2C but with a light load, short lines, and as long as you don't run the I2C too fast (standard-mode) then it is fine. There is no problem with reducing this value down to much less with a value of around 2.2K or less being preferable if you are using fast-mode and/or driving multiple devices etc. Of course with 10K on the board and 10K externally plus another 10K elsewhere you would have 3.3K effective pull-up which would also work well.
  • prof_brainoprof_braino Posts: 4,313
    edited 2011-08-26 07:42
    Great work! Well done! 128k eeproms will be on my next order.
  • caskazcaskaz Posts: 957
    edited 2011-08-28 05:18
    Hi.
    I did to use SDSC(512MB,256MB) on sd_driver.
    I tested on QuickStart board.
    sd_driver_modify_0.1's using pin are P0 - P3.
    I use micro 2GB on protoboard's system-SD.
    fat-viewer(another SD-card adapter) use sdsc-driver.
    If you never use SDSC(512MB,256MB), this don't need.
    Inserting 512MB SD-card(formatted WindowsXP) to adaptor
    
    Loading sd_driver_modify_0.1
    Loading sdfs
    reboot <Enter> 
    <ESC>  <--- skipping .autoload
    1 sd_mount <Enter> 
    Loading sd_script
    reboot <Enter>
    

    Using SD-card(SDSC) is 512MB.
    Prop0 Cog6 ok
    
    reboot <Enter>
    
    CON:Prop0 Cog0 RESET - last status: 0 ok
    
    CON:Prop0 Cog1 RESET - last status: 0 ok
    
    CON:Prop0 Cog2 RESET - last status: 0 ok
    
    CON:Prop0 Cog3 RESET - last status: 0 ok
    
    CON:Prop0 Cog4 RESET - last status: 0 ok
    
    CON:Prop0 PROP REBOOT PropForth v4.5 2011JUL25 7:10 1
    
    CON:Prop0 Cog5 RESET - last status: 0 ok
    
    Prop0 Cog0 ok
    
    decimal
    
    Prop0 Cog0 ok
    
    [ifndef mountsys : mountsys 0000000001 sd_mount ; ]
    
    Prop0 Cog0 ok
    
    \ mountusr ( -- ) mount the user disk
    
    Prop0 Cog0 ok
    
    [ifndef mountusr : mountusr 65538 sd_mount ; ]
    
    Prop0 Cog0 ok
    
    mountsys
    
    Prop0 Cog0 ok
    
    fread .sdcardinfo
    
    SDCard size:        501,240 Kbytes
    
    File System: sys
    
                          Start Block:              1
    
                            End Block:         65,538
    
            File System Size (blocks):         65,537
    
            File System Size  (bytes):         32,760 Kbytes
    
    
    File System: usr
    
                          Start Block:         65,538
    
                            End Block:      1,002,496
    
            File System Size (blocks):        936,958
    
            File System Size  (bytes):        468,470 Kbytes
    
    
    Prop0 Cog0 ok
    
    fload .autousr.f
    
    Prop0 Cog1 ok
    
    Prop0 Cog0 ok
    
    Prop0 Cog0 ok
    
    CON:Prop0 Cog6 RESET - last status: 0 ok
    
    Prop0 Cog6 RESET - last status: 0 ok
    
    Prop0 Cog6 ok
    
    ls <Enter>
    
    337 .partion-sys/
    
    130 .sdcardinfo
    
    136 .autousr.f
    
    133 .autoload.f
    
    
    Prop0 Cog6 ok
    
    free <Enter>
    
    9552 bytes free - 4 cog longs free
    
    Prop0 Cog6 ok
    
    hex
    
    Prop0 Cog6 ok
    
    free <Enter>
    
    2550 bytes free - 4 cog longs free
    
    Prop0 Cog6 ok
    
    mountusr
    
    Prop0 Cog6 ok
    
    ls
    
    10083 .partion-usr/
    
    Prop0 Cog6 ok
    
  • Brian RileyBrian Riley Posts: 626
    edited 2011-08-28 15:53
    If anybody out there has been doing or is interested in doing PropForth on a Mac, one item you need is a good terminal program. There is such a beast, Zterm. But, alas, version 1.1b7 dated from 2002 has been the only game in town. 2002 was long before Apple went Intel so its no surprise that Zterm is a PPC binary ... and of course with the recent release of Mac OSX Lion (OSX 10.7) Rosetta is not supported ... bummer ... but wait ... in my search for a replacement I stumbled on the fact that Zterm's author, after 9 years, updated Zterm to a Universal binary.

    Zterm version 1.2 is available free at http://homepage.mac.com/dalverson/zterm/. It's not cripple ware and he accepts 'registrations.' I had been using Zterm for 12 years, so I made a donation. I was impressed that he bothered to update 15 year old software.
  • mindrobotsmindrobots Posts: 6,506
    edited 2011-08-28 18:47
    Thanks, Brian!

    Great news. I'm on a slow road to conversion to Mac and have been looking for a terminal program to use with PropForth!
  • Brian RileyBrian Riley Posts: 626
    edited 2011-09-10 15:21
    In PropForth is there any equivalent to AUTOEXEC.BAT ?? I mean is there a reserved wordname, that if defined, then do a 'saveforth,' upon reboot that word will begin executing ??

    ... and if we do that word right there will be a loop that will look for a keystroke or a pin setting to let us regain control ... or not, if we want it bulletproof.
  • Mike GreenMike Green Posts: 23,101
    edited 2011-09-10 15:42
    For a simple terminal program for the Mac, I use goSerial. It's free. It's "no frills', but it gets the job done. For a full-featured terminal program, I use MacWise which is not free, but seems to be priced reasonably ($95) for the feature set (includes Telnet, Kermit, and a variety of terminal emulators).
  • prof_brainoprof_braino Posts: 4,313
    edited 2011-09-10 15:43
    In PropForth is there any equivalent to AUTOEXEC.BAT ?? I mean is there a reserved wordname, that if defined, then do a 'saveforth,' upon reboot that word will begin executing ??

    ONBOOT is the word that is executed at boot time. You can define this word how ever you need. Examples in SD and spineret regression tests.
  • caskazcaskaz Posts: 957
    edited 2011-09-11 01:54
    Hi.
    I have question.
    Prop0 Cog6 ok
    1 2 r> 1+ >r
    Prop0 Cog6 ok
    st?
    ST: 0000000001 0000000002 0000010766
    Prop0 Cog6 ok
    
    I expected [ST:0000000002 0000000002]
    Why?
  • caskazcaskaz Posts: 957
    edited 2011-09-11 05:24
    Hi.
    I'm confused.
    r> is "pop top of RS to stack" and >r is "push stack top to RS" ?

    But 1 >r result error.
    Prop0 Cog6 ok
    1 >r
    
    COM:Prop0 Cog6 RESET - last status: 2 RETURN STACK OVERFLOW
    Prop0 Cog6 RESET - last status: 2 RETURN STACK OVERFLOW
    Prop0 Cog6 ok
    

    How to use r> and >r?
  • prof_brainoprof_braino Posts: 4,313
    edited 2011-09-11 07:01
    caskaz wrote: »
    I have question. [return stack operators]
    1 2 r> 1+ >r
    st?
    ST: 0000000001 0000000002 0000010766
    
    I expected [ST:0000000002 0000000002]
    caskaz wrote: »
    r> is "pop top of RS to stack" and >r is "push stack top to RS" ? But 1 >r result error.
    Prop0 Cog6 ok
    1 >r
    
    COM:Prop0 Cog6 RESET - last status: 2 RETURN STACK OVERFLOW
    Prop0 Cog6 RESET - last status: 2 RETURN STACK OVERFLOW
    Prop0 Cog6 ok
    

    How to use r> and >r?

    Hi caskaz

    The return stack can ONLY be use WITHIN A DEFINITION. If you use the return stack from the command line, you break the interpreter.

    >r (to-return stack) puts a value (from top of data stack) on the return stack. You can only put your temporary values on the return stack within a functin definition.

    r> (from-return stack) takes a value off the return stack (and puts it on top of data stack). You can only take values off the return stack that YOU previously put on there.

    @r copies the top value off the return stack (to the top of the data stack), but also leaves it on the return stack

    YOU MUST consume all the values you put on the return stack before the function ends, or you can crash the interpreter.

    In your command line tests above, once it did not crash the interpreter, and once it did crash. In both cases the interpreter was broken, all further execution is undefined, and the prop needs a reboot.


    I think this is the correct example for what you want to do.
    : test 5 7 >r 1+ r> st? ;
    

    Best advise: Be care with the return stack, only use it when there is no other way.

    http://lars.nocrew.org/dpans/dpans3.htm#3.2.3 See 3.2.3.3 Return stack
  • prof_brainoprof_braino Posts: 4,313
    edited 2011-09-11 07:24
    upon reboot that word will begin executing ??
    ONBOOT is the word that is executed at boot time. You can define this word how ever you need. Examples in SD and spineret regression tests.

    Improved response:

    : old-boot onboot ; <- define a word "old-boot" to do the previous (required) boot-time behavior

    : onboot old-boot MyApplication ; <- make a new definition "onboot" to to call the previous boot behavior word, and to call you application word.

    At boot time, propforth looks for the most recent definition of onboot, and calls that. the old-boot definition sets up the last of the house keeping, and turn control back to the interpreter.
    If there is no word in the input stream, it drops back to the command line.
    If your word MyApplication is there, My Application begins executing.
    If MyApplication crashes or terminates unexpectedly, it can be made to drop back to the command line.

    There is another option to make the kernel HALT upon termination of MyApplication, so that the user does not get access to the interpreter in the event of a crash (for security, etc) but I never use this and I don't know exactly how to set it up. If you need this we can ask Sal when he gets back from his journey, hopefully this month.
  • Brian RileyBrian Riley Posts: 626
    edited 2011-09-11 10:28
    ... hmmmmmmmm ... I see the writing of an App-Note in my near future ...

    In PF 4.6 I see words

    onboot

    onreset

    onreold - (old-onreset ?????)

    onbold - (old-onboot ?????)

    reboot

    reset

    Please differentiate, tell me hardware and software conditions under which they come to play.

    Am I correct in saying that power cycling and the word 'reboot' are one in the same as far as PF is concerned? The word 'reset' seems to reset current cog .. what else does it do?

    I will play with them and write up an AppNote/HOW-TO and submit it to the wiki and you can see if I got it right
  • Brian RileyBrian Riley Posts: 626
    edited 2011-09-11 17:50
    Improved response:

    : old-boot onboot ; <- define a word "old-boot" to do the previous (required) boot-time behavior

    : onboot old-boot MyApplication ; <- make a new definition "onboot" to to call the previous boot behavior word, and to call you application word.

    At boot time, propforth looks for the most recent definition of onboot, and calls that. the old-boot definition sets up the last of the house keeping, and turn control back to the interpreter.
    If there is no word in the input stream, it drops back to the command line.
    If your word MyApplication is there, My Application begins executing.
    If MyApplication crashes or terminates unexpectedly, it can be made to drop back to the command line.

    OK, I played with this, found out 'the hard way' what happens when you do not include the old onboot word as part of the new onboot word ... PF goes faaaarrrr away! I had to redo the kernal and fs all over again.

    I understand onboot and onreset, but I still need coming up to speed for onbold and onreold.

    It appears to me now that 'reboot,' power cycling and, hardware reset switch all bring the same software results.
  • prof_brainoprof_braino Posts: 4,313
    edited 2011-09-12 15:28
    OK, I played with this, found out 'the hard way' what happens when you do not include the old onboot word as part of the new onboot word ... PF goes faaaarrrr away! I had to redo the kernal and fs all over again.

    I understand onboot and onreset, but I still need coming up to speed for onbold and onreold.

    It appears to me now that 'reboot,' power cycling and, hardware reset switch all bring the same software results.

    I THINK:

    onboot - does the last word that needs to be executed to start the kernel (interpreter, quit loop, stacks) at boot time. This needs to be done before your application word,
    onbold - Sal is "old school" in that it seem imperative to to save a single byte in every weird place, but I guess they add up. onbold is what I would call old-onboot or onboot-old; FYI - Sal pronounces "onbold" as "onboot-old" in discussions.

    There IS a difference between onboot and onreset, etc; although I don't know what it is, although each assumes and performs a different level of initialization. I DO know that it is NOT safe to assume the executing any software word is the equivalent of a power cycle. (although I do accept that hardware reset is as effective as power cycle) IE, if something crashes or otherwise goes south, power must be cycled to ensure the issue has been cleared. Perhaps its a ham-fisted approach, but even Sal gets caught where these words do not resolve an execution error, when he thought they would. And this is not a limitation of forth, I'm pretty sure it applies to any micro controller application. But I'm a "nuke them from orbit, its the only way to be SURE" kind of a guy.
  • caskazcaskaz Posts: 957
    edited 2011-09-16 21:05
    Hi.
    I built up USB-Host curcuit by using MAX3421E.
    I refered MAX3421EKIT's curcuit.
    And I translated maxim's sample code to PropForth.

    When connected mouse, it seems to work finly.
    But USB-memory and scanner don't work.

    On Send_packet inside max3421e_0.11_1.f, when executed "80 19 Hwreg" response is 0xd(hrJERR).
    Anybody know solution about hrJERR?
    ---- Connected 2-button mouse ---------
    
    
    
    hex
    
    
    
    Prop0 Cog6 ok
    
    
    
    usb
    
    
    
    Waiting for device connect
    
    
    Low-Speed Device Detected
    
    
    Issuing USB bus reset
    
    
    First 8 bytes of Device Descriptor ( 0 NAKS )
    
    
    12 1 0 1 0 0 0 8
    
    
    EP0 maxPacketSize is 8 bytes
    
    
    Issuing USB bus reset
    
    
    Setting address to 0x07
    
    
    Device Descriptor ( 0  NAKS )
    
    -----------------
    
    
    12 1 0 1 0 0 0 8 6E 5 3 0 91 4 1 2 0 1
    
    
    USB 1.0
    
    
    This device has 1  configuration
    
    
    Vendor ID is 0x569
    
    
    Product ID is 0x3
    
    
    Language ID String Descriptor is 4 3 9 4
    
    
    Manuf. string is ELECOM
    
    
    Product string is ELECOM USB
    
    
    There is no Serial Number
    
    
    Configuration Descriptor ( 0 NAKS )
    
    ------------------------
    
    
    9 2 22 0 1 1 4 A0 32
    
    
    Full Configuration Data
    
    
    9 2 22 0 1 1 4 A0 32 9 4 0 0 1 3 1
    
    
    2 5 9 21 0 1 0 1
    
    
    Configuration 1  has 1 interface
    
    
    This device is bus powered and uses 64 milliamps
    
    
    2EndPoint1 I
    
    
    Config string is HID Mouse
    
    
    Waiting for device disconnect
    
    
    Device disconnected
    
    
    Prop0 Cog6 ok
    
    
    ---- Connected 3-button wheel mouse ---------
    
    
    
    usb
    
    
    
    Waiting for device connect
    
    
    Low-Speed Device Detected
    
    
    Issuing USB bus reset
    
    
    First 8 bytes of Device Descriptor ( 0 NAKS )
    
    
    12 1 0 2 0 0 0 8
    
    
    EP0 maxPacketSize is 8 bytes
    
    
    Issuing USB bus reset
    
    
    Setting address to 0x07
    
    
    Device Descriptor ( 0  NAKS )
    
    -----------------
    
    
    12 1 0 2 0 0 0 8 CF 1B 7 0 10 0 0 2 0 1
    
    
    USB 2.0
    
    
    This device has 1  configuration
    
    
    Vendor ID is 0x1BB4
    
    
    Product ID is 0x7
    
    
    Language ID String Descriptor is 4 3 9 4
    
    
    There is no Manuf. string
    
    
    Product string is USB Optical
    
    
    There is no Serial Number
    
    
    Configuration Descriptor ( 0 NAKS )
    
    ------------------------
    
    
    9 2 22 0 1 1 0 A0 31
    
    
    Full Configuration Data
    
    
    9 2 22 0 1 1 0 A0 31 9 4 0 0 1 3 1
    
    
    2 0 9 21 10 1 0 1
    
    
    Configuration 1  has 1 interface
    
    
    This device is bus powered and uses 62 milliamps
    
    
    
    There is no Config string
    
    
    Waiting for device disconnect
    
    
    Device disconnected
    
    
    Prop0 Cog6 ok
    
    
    ---- Connected USB memory ---------
    
    
    usb
    
    
    Waiting for device connect
    
    
    Full-Speed Device Detected
    
    
    Issuing USB bus reset
    
    
    First 8 bytes of Device Descriptor ( >>>>> Error >>>>>
    
    
    FS Timeout
    
    
    Waiting for device disconnect
    
    
    Device disconnected
    
    
    Prop0 Cog6 ok
    
    

    If you take an interst in MAX3421E, I recommend sparkfun's board.
    http://www.sparkfun.com/products/9947
  • Ron SutcliffeRon Sutcliffe Posts: 420
    edited 2011-09-17 06:33
    Hi Cas

    I don't know the device, but if you are running PropForth4.6 and if you have your the SDdriver running in Cog 0, try 0 cogstop before you test your code.

    Just a suggestion

    cheers

    ron.
  • caskazcaskaz Posts: 957
    edited 2011-09-20 06:09
    Hi.

    I tried below;
    1.Wires betwen USB A-type connector and MAX3421E(pin20[D-] pin21[D+] replaced twisted wire.
    2.I replaceed to propeller NCO-pulse although clock was used ceramic resonator(12MHz) as MAX3421E's clock.
    3.USB A-type connector's shield was tied to GND.

    But FullSpeed Device error occure.

    And I found out Full Configuration Descriptor is strange.
    (End point Descriptor is strange)

    Ron, SPI for MAX3421E don't use SD's line.
  • prof_brainoprof_braino Posts: 4,313
    edited 2011-09-25 13:34
    FYI - Sal is back. :) I've updated the wiki and FAQ's for 5.0 and 5.a releases with decisions from today's meeting.
    http://code.google.com/p/propforth/w/list

    Summary:

    - pf 5.0 will use the existing hardware configuration for the test bed, and have no test automation implemented. ETA is a couple weeks.

    - ETA for pf 5.1 is tentatively targeted for Decemberr 2011. pf 5.1 will consist of a new general hardware configuration that supports full test automation, and demonstrates correct operation of all supported functions. So the regression tests will serve as verification of correct function, examples of use-cases, and training tutorial for intended use of each function. Support will be based on this model. It looks like there will be two spinneret boards (or wiz5100 equivalent) and four "bare" prop chips, and assorted wires and resistors for MSC (highspeed multichannel serial) and regular RS232 serial. This will allow immediate, non-invasive over internet diagnostics and debugging. There is also a possibility of scaled cooperative multiprocessing on this configuration, but implementation will be left to a later release.
  • caskazcaskaz Posts: 957
    edited 2011-09-26 20:45
    Hi.
    I think my mistake use NCO to supply MAX3421E's clock.
    Protoboard's Xstal is 5MHz.
    So NCO output 11999999.99254942Hz.
    This cause jitter.
    It seems to be ok on LowSpeedDevice.
    But not good on FullSpeedDevice.

    Using NCO to supply MAX3421E's clock need to replace Protoboard's Xtal to 6MHz.
    And PropForth.spin must be also modified.

    I orderd Xtal(12MHz) for MAX3421E.
  • prof_brainoprof_braino Posts: 4,313
    edited 2011-09-27 06:10
    caskaz wrote: »
    I think my mistake use NCO to supply MAX3421E's clock.
    Protoboard's Xstal is 5MHz. So NCO output 11999999.99254942Hz. This cause jitter.
    Using NCO to supply MAX3421E's clock need to replace Protoboard's Xtal to 6MHz.

    That sounds similar to other threads reporting USB needs a 6Mhz clock. Did you check how other projects accomplished this? They might have some help for you.
  • Brian RileyBrian Riley Posts: 626
    edited 2011-09-28 09:31
    Prof,

    In a recent post on the PFIG thread you said ....
    I had started on the "Sieve of Eratosthenes" for parallel processing and recursion experiments, but decided to leave off until the 5.x releases. Many folks have stated these are silly on any microcontroller, prop in particular; but these are still fun and will be on the list later for benchmarking if nothing else. Please continue to keep us posted on your progress, or at least know that this will be bigger in the propforth v5.x time frame.

    Also, let us know any feedback for improvements on the docs.

    Indeed PropForth is a 'great work, in progress.' Documentation is critical, but from a new user standpoint, we no more get done fully wading through and digesting what documentation there is, than its obsolete. Version 4.x has been replaced by 4.x+1, 20 core words have changed and everything has been restructured.

    Now, as a volunteer on the documentation effort, I cannot tell you how many times I have blessed as opposed to cursed my procrastination tendencies, when a HOW-TO I had mentally sketched out would have been wasted because of revisions.

    In my gut I get the feeling that 5.0/5.1 is getting us near a relatively stable configuration ... but WHO KNOWS what stroke of divine inspiration the mad genius, Sal Sanci, will have between now and New Year ??!!??!!

    I realize we are guests and beneficiaries at the creation of PropForth. But maybe if we had a better idea of where we are going it would help our support efforts. Does 5.1 look like stable configuration or just a way point on the journey?
  • prof_brainoprof_braino Posts: 4,313
    edited 2011-09-28 12:13
    @Brian - Good question, thanks for your patience and hard work.

    The 5.x release is intended to be the final version of the kernel. Sal is pretty accurate with his development and release path.

    5.0 will take all the pieces up to and including the paged assembler, and make single unified package. So all the functions that have been demonstrated are to be optimized and included. To reduce the number of unknowns, we are using the "old" (existing) hardware test bed configuration and no test script automation.

    5.1 will consist of a new hardware test bed configuration to support automated regression testing. This test bed will allow non-invasive over the internet examination and debugging. It will also be the basis for the automated regression suites. Of course the test bed will be optional. But if you want to run the "stock" regression tests like Sal and I do, this would be where to start. It would also allow someone like Sal to diagnose a running system over the internet, the model is "on-site consulting without travel".

    With the 5.x release, we expect the kernel to be stable. Somewhere after 5.0 we will also begin scrubbing the bug list (functions are already implemented) and the documentation (to catch up this the changes). The plan also includes scrubbing the previously release functions, such as VGA (HiRes and LoRes) support, JupiterACE, Hive, debugger, disassembler, etc and bringing all these up to 5.x kernel, and add tests and documentation.

    The final step will be to take all the existing non-kernel functions (extensions) from caskaz, Nick, Ron, you, me, and the others and roll them into the regression test suite(s) and make a single download archive package that is periodically re-released as additions are made. By the final step, the entire project should be less of a "Sal's tool" project and more of a "group project" where we all contribute to the regression suite.

    I don't know when this will finally happen or if it will work out as described, but that's the idea.
  • Brian RileyBrian Riley Posts: 626
    edited 2011-09-29 13:12
    In the time I have been with this project, one theme has been dominant, i.e.that PF, unchanged save for conflicting pin numbers, should run on any Propeller board.The coming development with the dictionary on the SD card seems to shove the ubiquitous Demo Board out into the cold dark night and crowning the Spinneret the new Homecoming Queen!

    ... or will 5.1 be built in layers that will let you stop when you have gone as far as your target board allows leaving you with the core of 5.1?

    An aside here ... I wonder if KenG et al. at Parallax realize what a monster they have created in the Spinneret. I defy anyone to build up a $20 PropProto to a Spinneret equivalent for less than the $60 bucks it costs. If they come up with a WiFi version it will a grand slam home run.
  • caskazcaskaz Posts: 957
    edited 2011-09-29 21:17
    Hi.

    I found out ascii-characters are strange with using "dump".
    hex
    
    Prop0 Cog6 ok
    1000 80 dump
    
    1000 0080:
    1000: 72 73 70 6F 70 5F 72 65 74 00 1F 00 00 01 FA 0F   rspop_ret.....E
    1010: 89 24 43 5F 61 5F 6E 65 78 74 1F 00 75 00 10 10           $C_a_next..u...
    1020: 8B 24 43 5F 76 61 72 73 74 61 72 74 1F 00 01 01
                                                            $C_varstart....
    1030: 20 10 89 24 43 5F 76 61 72 65 6E 64 1F 00 4F 01    .      $C_varend..O.
    1040: 32 10 83 5F 63 76 2C 10 FE 12 73 00 42 10 86 5F   2._cv,.þ.s.B._
    1050: 66 6D 61 73 6B 00 C2 10 46 10 73 00 4E 10 8A 5F   fmask.Â.F.s.N.
                                                                          _
    1060: 72 65 73 65 74 64 72 65 67 00 6A 00 03 00 46 10   resetdreg.j...F.
    1070: 73 00 5E 10 82 69 70 00 6A 00 04 00 46 10 73 00   s.^.ip.j...F.s.
    Prop0 Cog6 ok
    

    I re-wrote WORD"(dumpe)".
    : (dumpe)
    	tbuf 10 bounds
    	do
    		i C@ .byte space
    	loop
    	2 spaces tbuf 10 bounds
    	do
    		i C@ dup dup bl < swap 7f > or if drop 2e then emit
    	loop
    ;
    
    hex
    
    Prop0 Cog6 ok
    1000 80 dump
    
    1000 0080:
    1000: 72 73 70 6F 70 5F 72 65 74 00 1F 00 00 01 FA 0F   rspop_ret.......
    1010: 89 24 43 5F 61 5F 6E 65 78 74 1F 00 75 00 10 10   .$C_a_next..u...
    1020: 8B 24 43 5F 76 61 72 73 74 61 72 74 1F 00 01 01   .$C_varstart....
    1030: 20 10 89 24 43 5F 76 61 72 65 6E 64 1F 00 4F 01    ..$C_varend..O.
    1040: 32 10 83 5F 63 76 2C 10 FE 12 73 00 42 10 86 5F   2.._cv,...s.B.._
    1050: 66 6D 61 73 6B 00 C2 10 46 10 73 00 4E 10 8A 5F   fmask...F.s.N.._
    1060: 72 65 73 65 74 64 72 65 67 00 6A 00 03 00 46 10   resetdreg.j...F.
    1070: 73 00 5E 10 82 69 70 00 6A 00 04 00 46 10 73 00   s.^..ip.j...F.s.
    Prop0 Cog6 ok
    
  • prof_brainoprof_braino Posts: 4,313
    edited 2011-09-30 08:08
    caskaz wrote: »
    ascii-characters are strange with using "dump".
    i C@ dup dup bl < swap 7f > or if drop 2e then emit
    

    I think what you are seeing has to do with the TERMINAL program treats ASCII special characters. That is, in one mode the terminal treats all the ascii codes as character to display, and in another mode, the terminal treat characters outside the "normal" ranges (a-z, 0-9, etc) as command codes. Example is value 8 (tab) is "displayed" as BEL and the bell rings (or keyboard beeps), or whare the CF and LF make cursor position change versus displaying the tiny CR LF characters.

    Since a given byte can have any value based on bit pattern, 0-255 decimal or 0000 to 1111 binary, about half the time values are those that can be control codes.

    The solution you have found changes the "command code" range of values into something that gets displayed as a period. (Just glancing). This is a good way to do it, the dump looks better but we don't see a uniqe character dipsated for each byte value.

    The other alternative is to change the terminal program to display command codes instead of interpret command codes. This is easily done, (I did it years ago for the blue ADM VT100 compatiable terminal I worked on in 1987). BUT each terminal program can be different, and it is not necessarily standardized (yet) so Sal did not put this feature in the kernel. If you want to get fancy, the dump program can be modified such that it tells the terminal to change its display mode from "interpret ASCII special characters" mode to "display ASCI spacial characters" mode. This is on my long list of things I am supposed to do but am putting off until the kernel is released.

    Its a good excersise in terminal emulator if you or anybody wants to do this extension.
  • prof_brainoprof_braino Posts: 4,313
    edited 2011-09-30 08:39
    I PF, unchanged save for conflicting pin numbers, should run on any Propeller board.The coming development with the dictionary on the SD card ... Demo Board ... Spinneret
    .....
    build up a $20 PropProto to a Spinneret ....

    OK. You got it nailed.

    1) Propforth will always run on ANY existing prop chip to date, regardless of EEPROM memory, from 0 to N k bytes. While propforth supports ROMless slaves, and externded EEPROM, the default kernel to date will always work on the stock demo board and stock protoboard.

    2) To load propforth.spin and boot to forth from power up, at least 32k eeprom is required. This is always the default.

    3) TO USE EEPROM FILESYSTEM, etc, 64k EEPROM or greater is required. EEPROM files system and EEPROM storage are ALWAY an extension, due to (2)

    4) SD support is an extension. The demoboard can load the deafult kernel, add the SD support extension, saveforth, and now contain SD support at boot time. The demoboard can boot and run boot-time scripts as described in the SD regression tests.

    5) SPINNERET is being incorporated into the Standard Hardware Testbed to allow a) ethernet access to the target application and b) internet debugging abilities to the testbed. Particularly by Sal on my hardware, with Sal in his lab in Vancouver and my hardware with me in my lab in Chicago. Sal got tired of waiting for me to ship my hardware to him when I have a bug, and tired of paying return shipping. With the EEPROM hardware questions raised in issue 22, we realized that debuggin hardware issues was not limited to me only, and merited a general solution. After 5.1, Sal (or anybody else) will be able to provide debugging over internet, and it will behave exactly as if the unit was on his desk in his shop. (we have to cyce power for him, but that's it). No questions, no waiting. Sal can "just look at it and fix it" much faster than asking question over email, wait for answer, determine answer makes no sense, clarify question, email new question, wait two days, etc. SPINERET configuration is OPTIONAL and will only be required for folks that want Sal to look into their hardware. But, it will also be very handy if folks want to learn propforth by running theregression tests and following the tutorials. Perhaps the BIGGEST advantage of the standard test bed is allowing all users to take advantage of automated regression tests, which totally awsome and high tech. Regression test in general, and automated regression test in particular, are to software as interchangable parts were to manufacturing. To paraphrase Dr. Kleiner, "I can't put enough undue empahasis on the importance of" automated regression test.

    6) I have a w5100 board from sparkfun which was used in the original spinforth telnet demo. protoboard + w5100 should be equivalent to spinneret, but I never finished getting it working. The cost is from the wiznet chip. It might turn out to be cheaper to just buy a second spineret, but this will not a priority issue until 5.1 is imminent.
  • caskazcaskaz Posts: 957
    edited 2011-09-30 09:50
    Hi.
    I updated worddump.
    hex
    
    Prop0 Cog6 ok
    
    wordDump saveforth
    
    31D4: saveforth
    
    
    
    Addr  pfa  nfa  WORD name
    31DE: 2F5A 2F56 cq
    31E0: 04
    31E1: 68 h
    31E2: 65 e
    31E3: 72 r
    31E4: 65 e
    31E6: 21C4 21BE find
    31E8: 00D8 1346 0branch
    31EA: 006C
    31EC: 0D2C 0D24 version
    31EE: 11EC 11E8 W@
    31F0: 0032 127C dup
    31F2: 11E0 11DC C@
    31F4: 12FE 12FC +
    31F6: 0032 127C dup
    31F8: 11E0 11DC C@
    31FA: 19C6 19C2 1+
    31FC: 00B1 136A swap
    31FE: 120E 120A C!
    3200: 1F9C 1F94 pfa>nfa
    3202: 0C84 0C7E here
    3204: 11EC 11E8 W@
    3206: 00B1 136A swap
    3208: 0032 127C dup
    320A: 11EC 11E8 W@
    320C: 0081 12F2 over
    320E: 2EA0 2E9C EW!
    3210: 19E2 19DE 2+
    3212: 0032 127C dup
    3214: 006A 129A litw
    3216: 003F
    3218: 11BA 11B6 and
    321A: 198A 1986 0=
    321C: 00D8 1346 0branch
    321E: FFEA
    3220: 009D 133E 2>r
    3222: 1E9A 1E92 ibound
    3224: 1E82 1E80 i
    3226: 12DE 12DC -
    3228: 006A 129A litw
    322A: 0040
    322C: 12D4 12D0 min
    322E: 0032 127C dup
    3230: 1E82 1E80 i
    3232: 0032 127C dup
    3234: 008F 1306 rot
    3236: 2E30 2E24 eewritepage
    3238: 00D8 1346 0branch
    323A: 0008
    323C: 006A 129A litw
    323E: 000A
    3240: 1510 150C ERR
    3242: 180E 180A _p?
    3244: 00D8 1346 0branch
    3246: 0008
    3248: 006A 129A litw
    324A: 002E
    324C: 18D4 18CE emit
    324E: 00A6 135E (+loop)
    3250: FFD2
    3252: 001B 122C branch
    3254: 0004
    3256: 0011 1272 drop
    3258: 180E 180A _p?
    325A: 00D8 1346 0branch
    325C: 0004
    325E: 1AF0 1AEC cr
    3260: 0073 128A exit
    
    Prop0 Cog6 ok
    
    
  • Brian RileyBrian Riley Posts: 626
    edited 2011-10-03 12:44
    One of my projects is aimed at a small prop board taking a few measurements and then setting a couple switches based upon those measurements. I didn't want to have to lug a laptop around to check progress, I wanted a 4 line by 20 char serial enabled LCD.

    Sal gave me some code to get me started and I have been fooling around with it for several days. What I have here is a set of basic words to initialize the serial process in its own cog and words to make and break the iolink that mirrors the main console out to the serial LCD. I have a string print routine and a screen clear. Still to be done is formatted number displays.
    fl
    
    \ fswrite lcdserlnk.f
    
    { LCD Serial Link
      Routines to setup a serial process in a cog to permit
      writing to a serial enabled LCD. You initialize the
      serial cog with 'startLCD' and display text with
      'strlnk' (still to be completed - routines for formatted 
      numbers). All display routines start with a 'maklnk' and
      conclude with 'brklnk', which, effectively, turns console
      mirroring on then off.
    
       3 October 2011   Brian Riley, Underhill Center, VT, USA
    }
    
    {
      create console link to LCD using cog 4
      maklnk ( -- )
    }
    : maklnk 4 cogid swap iolink ;
    
    
    {
      break console link to LCD
      brklnk ( -- )
    }
    : brklnk cogid iounlink ;
    
    
    {
      display string  ( cstr -- )
      - based upon string write word from CasKaz's parallel LCD
        routines
      - the 10 ms delay just before brklnk MUST be there to give
        the iolink routines time to flush its buffer 
    }
    : strlnk
    	maklnk
    	C@++ dup if bounds do i C@ emit loop else 2drop then 
    	10 delms brklnk cr
    ;
    
    
    {
      clear/home screen of LCDpa
      clrlcd ( -- )
      - "?f" is the string for a Peter Anderson serial
        LCD chip, edit this to your flavor
    }
    : clrlcd c" ?f" strlnk ;
    
    
    {
      initiate serial process in cog 4
      startLCD ( -- )
      - by using the same pin spec for tx and rx, pin 7,
        you get a simple loopback and mirroring of main
        console whenever iolink is active
    }
    : startLCD 
    	7 7 19200 4 startserialcog
    	10 delms
    	clrlcd
    ;
    
    ...
    
    

    Enjoy ...
  • prof_brainoprof_braino Posts: 4,313
    edited 2011-10-03 13:01
    Might I suggest that the propforth.spin defines the FIRST TIME BOOT I/O Pins using the CON statement.

    The RamBlade board...I/O is redirected through Pins $16 and $17 ...
    I would appreciate if you would pass this on to Sal for his comments.

    @Ron

    Sal has started looking at Issue 53. He needs some details on the hardware
    Could you add comments directly to issue 53?

    Thanks!
Sign In or Register to comment.