Shop OBEX P1 Docs P2 Docs Learn Events
Formatted Numeric Output (SX/B 2.0) — Parallax Forums

Formatted Numeric Output (SX/B 2.0)

JonnyMacJonnyMac Posts: 9,214
edited 2009-01-29 22:04 in General Discussion
For those that have struggled with sending numbers to terminals and serial displays this demo should help. It demonstrates the use of local variables, the new STR and HEXSTR instructions, and using libraries -- the result is clean numeric output to a serial device.

Comments

  • Peter VerkaikPeter Verkaik Posts: 3,956
    edited 2009-01-29 19:17
    Jon,

    Thanks for the libraries.
    As the number of libraries is still small, let me make a suggestion.

    You enclose the library code in '{$ifused subname}-'{$endif} blocks
    which is good. You have grouped related subroutines in a single library file which is
    also good.
    Something that may become a problem when the number of libraries grows·is the
    limited number of SUB declaration that sxb supports, the limit is 128 because
    all declared subs require 2 bytes in the lower half of codepage 0.

    Even if you only need TX_STR, the other subroutines still occupy entries
    in the subroutine jumptable. If you need to include more libraries as the program grows,
    this will quickly fill the jumptable.

    The way I resolve this is by using the '{$USES subname} directive
    that I place at the top of the·main program file, before loading the xxx_DEF.SXB files.
    eg. '{$USES TX_STR}
    This informes the sxb compiler TX_STR is to be used so it reserves an entry for it.

    You then enclose the sub declarations like this:
    '{$ifused TX_STR}
    TX_STR········· SUB···· 2······················ ' transmit a string
    '{$endif}

    and enclose the subroutine in xxx_INC.SXB likewise:
    '{$ifused TX_STR}
    SUB TX_STR
    ENDSUB
    '{$endif}

    This saves jumptable entries.
    It still is not ideal, but with a single pass compiler probably the best way.
    regards peter
  • JonnyMacJonnyMac Posts: 9,214
    edited 2009-01-29 19:49
    Peter, your suggestion is valid and one could do that, but for the casual SX/B programmer (which you certainly are not) I think having to add a $USES clause for any routine one wants in the program is more of a burden than the few bytes consumed.

    "Best" is in the eye of the beholder -- or programmer, as the case may be. SX/B doesn't enforce any particular style, and I'm simply sharing what I think works best for me. Perhaps you should post [noparse][[/noparse]full] demos so that others can learn from how you've succeeded with SX/B.
  • Peter VerkaikPeter Verkaik Posts: 3,956
    edited 2009-01-29 21:11
    Jon,

    Attached are your files but modified as per my suggestion.

    Note that I added a '{$define libname} to each library DEF file.
    That define is then used to load the INC later on.
    Big advantage here is when a specific DEF is·no longer·loaded,
    its companied INC is automatically skipped.

    Also note that I listed all requirements·for the libraries in the DEFs,
    like STACK needed, but for TX_SERIAL also the BaudMode constant
    which must be defined externally.

    Adding the '{$uses subname} really·is no big deal.
    When there are a lot·of library subroutines used, you do get
    a long vertical list of·$uses.
    I·have requested in the past, and I still request it, is to have $uses accept
    a comma seperated list.
    My suggestion is:
    '{$uses libname: sub1name, sub2name, ...}
    where libname can be any text, it acts as comment ended by : but using the library name
    seems most appropiate.
    In the attached demo it·then would look like
    '{$uses pvDELAYS: DELAY_MS}
    '{$uses pvTX_SERIAL: TX_STR,TX_BIN,TX_HEX}

    Consider not using $uses and·the subroutine jumptable does get filled with unused subroutine entries
    so your program does not compile (too many subs).
    Then you will need·to copy and rename libraries and removing unrequired subroutines.

    regards peter
  • JonnyMacJonnyMac Posts: 9,214
    edited 2009-01-29 22:04
    Your points are certainly valid and yet, as ever, I look forward to the day when you start posting you own demos instead of simply criticizing the work of others. I'm not holding my breath.... tongue.gif
Sign In or Register to comment.