Forum Update - Announcement about May 10th, 2018 update and your password.

P2 Monitor/Debug for possible inclusion in the ROM

2»

Comments

  • kwinnkwinn Posts: 7,873
    David Betz wrote: »
    ......

    I had originally envisioned TAQOZ as a programmable monitor for the P2. I don't think it is absolutely essential that it be blindingly fast. I imagine that when Peter or anyone else wants to write a full application in Forth they will use full Tachyon not what is in the ROM. As it stands now we get a simple monitor and a stripped down implementation of a programming language.

    As I currently understand it, it is a limitation of using 16 bit word codes as pointers to the actual code that makes up TAQOZ. That makes it very fast but limits it to 64K. No doubt Peter or some clever forum member will come up with a way to get around that limitation with minimal impact on execution speed. Worst case a different implementation of TAQOZ can be loaded after booting.
    In science there is no authority. There is only experiment.
    Life is unpredictable. Eat dessert first.
  • Isn't part of the problem here how FORTH is?

    A stripped down programming language means only having some tools, but otherwise making new programs is possible.

    With Forth, a new program becomes a new word, does it not?

    Without being extensible, one would be limited to the one liners, or more generally whatever interactive code is already defined.

    Do not taunt Happy Fun Ball! @opengeekorg ---> Be Excellent To One Another SKYPE = acuity_doug
    Parallax colors simplified: http://forums.parallax.com/showthread.php?123709-Commented-Graphics_Demo.spin<br>
  • I second David's general comments. No need for speed. That's a different use case.

    Do not taunt Happy Fun Ball! @opengeekorg ---> Be Excellent To One Another SKYPE = acuity_doug
    Parallax colors simplified: http://forums.parallax.com/showthread.php?123709-Commented-Graphics_Demo.spin<br>
  • kwinn wrote: »
    David Betz wrote: »
    ......

    I had originally envisioned TAQOZ as a programmable monitor for the P2. I don't think it is absolutely essential that it be blindingly fast. I imagine that when Peter or anyone else wants to write a full application in Forth they will use full Tachyon not what is in the ROM. As it stands now we get a simple monitor and a stripped down implementation of a programming language.

    As I currently understand it, it is a limitation of using 16 bit word codes as pointers to the actual code that makes up TAQOZ. That makes it very fast but limits it to 64K. No doubt Peter or some clever forum member will come up with a way to get around that limitation with minimal impact on execution speed. Worst case a different implementation of TAQOZ can be loaded after booting.
    If TAQOZ can't be used as a resident monitor so we're forced to also have a simple monitor program in ROM and if any serious Forth application will likely load a different version of Tachyon anyway, what's the point of having it in ROM at all? It seems to me that it is only useful if it can be the resident monitor. Otherwise, just load full Tachyon like you'll have to load the Spin interpreter or the C runtime.

  • Cluso99 wrote: »
    ...

    Try "> " to set autobaud in Chip's code, followed by one of...

    <esc> to run TAQOZ
    <ctl-d> to boot a file named "_BOOT_P2.BIX" or _"BOOT_P2.BIY" from an SD card
    <ctl-e> to run my monitor
    ..

    how about

    <ctl-b> to boot
    <ctl-d> for debug and
    <ctl-t> for TAQOZ

    would make more sense, at least to me.

    Enjoy

    Mike



    I am just another Code Monkey.
    A determined coder can write COBOL programs in any language. -- Author unknown.
    Press any key to continue, any other key to quit

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this post are to be interpreted as described in RFC 2119.
  • Cluso99Cluso99 Posts: 13,769
    msrobots wrote: »
    <ctl-b> to boot
    <ctl-d> for debug and
    <ctl-t> for TAQOZ

    would make more sense, at least to me.
    Yes.
    History: I originally used ctl-d as in "SD" (because ctl-s & ctl-q is used in xon/xoff protocols) and Peter requested <esc>.
    Later I added the debug/monitor so ctl-e was next.

    BUT...
    Makes me wonder about the "> " for autobaud too. Why not use an "AT"/"at" sequence ???
    I now Chip used/uses ">" for resyncing the timing.
    Probably too late to try a change here tho'
  • jmgjmg Posts: 11,657
    I seem to have over 1kB free in the ROM. I wonder if I can squeeze something useful in there....

    I'm not following who includes what here ?
    Is that 1k spare with TAQOZ plus Cluso99 SD boot reader plus Chip's UART/SPI boot loader (expanded with address-size ? )

  • jmgjmg Posts: 11,657
    Cluso99 wrote: »
    BTW I think all those serial problems were to do with the Interrupt stealing some input characters.

    Serial INT traps '>' and uses as an Autobaud char, then discards.
    I guess since it knows what it was, it does not need to discard it, but can still use it for autobaud tracking. Other code outside the int, already checks chars.

  • I did manage to free up some space for various reasons but I'd like to include a version of SPLAT to capture and display port timing signals. Having TAQOZ in rom means we can debug hardware even if nothing seems to work properly. There would never be any need to have more then 64kB code addressing but even this little baby has tricks up its sleeve to run code in 32-bit address space. But do we need to?

    Tachyon Forth - compact, fast, forthwright and interactive
    useforthlogo-s.png
    --->CLICK THE LOGO for more links<---
    Latest binary V5.4 includes EASYFILE +++++ Tachyon Forth News Blog
    P2 SHORTFORM DATASHEET +++++ TAQOZ documentation
    Brisbane, Australia
  • Cluso99Cluso99 Posts: 13,769
    I did manage to free up some space for various reasons but I'd like to include a version of SPLAT to capture and display port timing signals. Having TAQOZ in rom means we can debug hardware even if nothing seems to work properly. There would never be any need to have more then 64kB code addressing but even this little baby has tricks up its sleeve to run code in 32-bit address space. But do we need to?
    No. And there is not enough time left before the ROM gets frozen. Splat would be nice if you have time.
  • jmgjmg Posts: 11,657
    Cluso99 wrote: »
    BUT...
    Makes me wonder about the "> " for autobaud too. Why not use an "AT"/"at" sequence ???
    I now Chip used/uses ">" for resyncing the timing.
    Probably too late to try a change here tho'

    ? AT sequence does not work, as you have no idea what baud rate is being asked for, until you make measurements.

    Thus Autobaud needs a single character, and it needs to be a quite special character with a unique Logic-Analyzer footprint.
    Chip uses the smart pins to extract that 'signature' which works over a wide dynamic range, and ideally, needs to work if the P2 exists reset with a serial stream active.
    That's how you get fastest Serial boot.

    The only changes I would suggest to Chip's code would be minor ones like :

    * Reduce the TX turnaround delay, as the fixed 1ms is very long, and adds directly to the serial-boot-delay. A single char time should be fine here.

    * Allow Address and size parameters for loading, and Flash reading, and allow Serial-boot to call SPI-load under user command. (& maybe even SD-load too, for symmetry)

    All this better covers using small MCUs as serial loaders/watchdogs/security.
  • Cluso99Cluso99 Posts: 13,769
    jmg,
    Seems you were not around when the "AT" command set was introduced. This not only sets the baud rate, but also determines if parity is being used, what type, and IIRC if it was 9 bit character, all from an "AT" or "at".
  • jmgjmg Posts: 11,657
    Cluso99 wrote: »
    jmg,
    Seems you were not around when the "AT" command set was introduced. This not only sets the baud rate, but also determines if parity is being used, what type, and IIRC if it was 9 bit character, all from an "AT" or "at".
    "AT" command strings may be ok if you know the starting baud rate, but it's not going to work from a widely varying RC oscillator, with unknown baud incoming.
  • Cluso99Cluso99 Posts: 13,769
    jmg wrote: »
    Cluso99 wrote: »
    jmg,
    Seems you were not around when the "AT" command set was introduced. This not only sets the baud rate, but also determines if parity is being used, what type, and IIRC if it was 9 bit character, all from an "AT" or "at".
    "AT" command strings may be ok if you know the starting baud rate, but it's not going to work from a widely varying RC oscillator, with unknown baud incoming.
    What???

    It's no different to timing "> " !!!
  • jmgjmg Posts: 11,657
    edited May 5 Vote Up0Vote Down
    Cluso99 wrote: »
    jmg wrote: »
    Cluso99 wrote: »
    jmg,
    Seems you were not around when the "AT" command set was introduced. This not only sets the baud rate, but also determines if parity is being used, what type, and IIRC if it was 9 bit character, all from an "AT" or "at".
    "AT" command strings may be ok if you know the starting baud rate, but it's not going to work from a widely varying RC oscillator, with unknown baud incoming.
    What???

    It's no different to timing "> " !!!

    Provide an example.


    For best elastic Autobaud, you need to have the best precision measurement of the character.
    Google suggests 'A' was used, and that does give info but of much lower precision than '>'
    You ideally want the highest counts in the capture counters, to avoid clock rounding effects and to make best use of fractional baud.
    'A' gives you just one tH, and one =\_ to =\_, compared with 5 & 7 for '>' - far inferiour, which is why it was not even on the shortlist.
    You also need to reject false positives, as you cannot guarantee the first char, is the valid auto baud one.


    Of course, way, way back when AT was conceived, fractional baud was not even an idea yet.... nor were smart pins that could do live capture...

  • Cluso99Cluso99 Posts: 13,769
    edited May 5 Vote Up0Vote Down
    jmg wrote: »
    Cluso99 wrote: »
    jmg wrote: »
    Cluso99 wrote: »
    jmg,
    Seems you were not around when the "AT" command set was introduced. This not only sets the baud rate, but also determines if parity is being used, what type, and IIRC if it was 9 bit character, all from an "AT" or "at".
    "AT" command strings may be ok if you know the starting baud rate, but it's not going to work from a widely varying RC oscillator, with unknown baud incoming.
    What???

    It's no different to timing "> " !!!

    Provide an example.


    For best elastic Autobaud, you need to have the best precision measurement of the character.
    Google suggests 'A' was used, and that does give info but of much lower precision than '>'
    You ideally want the highest counts in the capture counters, to avoid clock rounding effects and to make best use of fractional baud.
    'A' gives you just one tH, and one =\_ to =\_, compared with 5 & 7 for '>' - far inferiour, which is why it was not even on the shortlist.
    You also need to reject false positives, as you cannot guarantee the first char, is the valid auto baud one.


    Of course, way, way back when AT was conceived, fractional baud was not even an idea yet.... nor were smart pins that could do live capture...
    Then google is wrong! I know because I've done it!!!

    Back in the days, we had to cater for much wider tolerance than today, with much slower processors, and up to 56K baud. The Apple //c was 1.5% out.

    Just because the start bit on an "A" is only 1 bit time, it doesn't preclude you timing the whole character. It doesn't preclude re-syncing on following character start bits either.

    And I've better thigs to do than prove something to you!!!
  • jmgjmg Posts: 11,657
    Cluso99 wrote: »
    Just because the start bit on an "A" is only 1 bit time, it doesn't preclude you timing the whole character. It doesn't preclude re-syncing on following character start bits either.
    Sure, anything is possible but now your coding and timing is more complex and critical..
    Once you time over multiple edges, your false positive risk increases too.

    The > method is proven and uses just 2 smart pins, and works up to 2MBd

  • Cluso99Cluso99 Posts: 13,769
    Here is the latest. Is anyone working on the P2???

    Please test the code out on BeMicroCV-A9 :)

    Instructions as above, except for
    If pullup on P61 (sd_cs currently) then it will boot from the SD card (the pullup is from the SD card itself on this pcb)
    Otherwise, the code will boot Chip's serial.
    Enter "> " for autobaud as above
    <esc> runs TAQOZ
    <ctl-D> runs the Debug/Monitor
    <ctl-B> runs the SD card (if you have since inserted it)

    If the SD card fails, or the file/boot is not found, then the monitor is started (note the id sequence misses out for an unknown reason)
  • Do I understand right, that the build-in pull up from the SD is used to sense if to boot serial or SD?

    So If I have a SD attached I can NOT boot serial?

    This is not so smart, since it should be possible to boot serial even if there is a bootable sd connected.

    There are systems where it is a PITA to get a SD card in or out.

    Enjoy

    Mike
    I am just another Code Monkey.
    A determined coder can write COBOL programs in any language. -- Author unknown.
    Press any key to continue, any other key to quit

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this post are to be interpreted as described in RFC 2119.
  • Cluso99Cluso99 Posts: 13,769
    edited May 5 Vote Up0Vote Down
    msrobots wrote: »
    Do I understand right, that the build-in pull up from the SD is used to sense if to boot serial or SD?

    So If I have a SD attached I can NOT boot serial?

    This is not so smart, since it should be possible to boot serial even if there is a bootable sd connected.

    There are systems where it is a PITA to get a SD card in or out.

    Enjoy

    Mike
    Easy,
    1, Don't connect your SD to these boot pins
    2. Don't have valid boot sectors or valid boot files on the SD
    3. Have the Serial pull-up pin fitted (priority is then first)
    4. Have FLASH fitted and pull-up fitted (priority is second)
    5. Don't have the pull-up/pull down (TBD) fitted to ignore Serial
    And of course,
    6. Remove the SD card
  • Aah, I missed the serial pull up.

    So even with bootable SD installed one can jumper serial pull up and boot from serial.

    All good,

    Mike
    I am just another Code Monkey.
    A determined coder can write COBOL programs in any language. -- Author unknown.
    Press any key to continue, any other key to quit

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this post are to be interpreted as described in RFC 2119.
Sign In or Register to comment.