Loading ...
Sorry, an error occurred while loading the content.

Re: [tracker2] Digi config sample

Expand Messages
  • James Ewen
    ... Which is always an issue in these micro devices... ... Okay, so that would be the the area that would store the actual scripts that we would write and
    Message 1 of 8 , Nov 14, 2007
    • 0 Attachment
      On Nov 14, 2007 3:01 PM, Scott Miller <scott@...> wrote:

      > This (mostly) comes down to a matter of storage space.

      Which is always an issue in these micro devices...

      > So that leaves 944 bytes currently unallocated. I had planned to use
      > this for programming space for a simple scripting language.

      Okay, so that would be the the area that would store the actual
      scripts that we would write and upload to the unit. That's a pretty
      healthy chunk of space for scripts.

      > One of my
      > design goals was that it should be programmable from the serial console,
      > but that introduces some heavy parsing requirements.

      Yeah, I could see that eating up a lot of space. It would be nice to
      be able to write scripts from the CLI, but I would be happy with
      having the config program do the heavy lifting, and simply store the
      scripts into the flash memory.

      > Anyway, what I'm thinking of doing is implementing features like the
      > beacon text as commands in this as-yet-undeveloped language. Each
      > string would be prefixed with a series of opcodes like <DO EVERY 10
      > MINUTES><SEND RAW BEACON TEXT>"blah blah blah".

      So, for all intents and purposes, your scripting language would allow
      us to do exactly what we want to do. I say get that scripting language
      implented. Theres no need to move things around and squeeze stuff in
      the way we have been suggesting when you have a better plan of attack
      already waiting in the wings... I was wondering what the heck we would
      do with a scripting language in the OT2, but now I understand... You
      certainly are one smart cookie!

      > The interpreter then just scans the list of instructions and executes
      > each one. It could initially support just the basic instructions
      > needed, with more to be added in the future.

      Yup, so for sending a beacon text string, we would want a command that
      would allow us to set periodicity (with an optional offset), path, and
      the actual string to send.

      With that simple capability, you could send a bunch of different
      beacons from the OT2, rather than being limited to just one in the
      status text line.

      > As for code space, at last check the T2 stands at 8146 bytes free. Not
      > a lot, but still a decent amount - a little more than the total space
      > available in the OT1, anyway.

      Well, if you were a code programmer for Microsoft, I doubt you could
      make the caps lock led blink on and off with that little code space,
      but efficient coding skills can sure to a lot in that much space.

      James
      VE6SRV
    • Scott Miller
      ... I ll have to consider how to do a variable path. You could just use the PATH command, but that causes a flash write and erase, and the flash has limited
      Message 2 of 8 , Nov 14, 2007
      • 0 Attachment
        > Yup, so for sending a beacon text string, we would want a command that
        > would allow us to set periodicity (with an optional offset), path, and
        > the actual string to send.

        I'll have to consider how to do a variable path. You could just use the
        PATH command, but that causes a flash write and erase, and the flash has
        limited write endurance (about 100,000 cycles), and every time you do
        that it flushes the RX buffer since that's the only place it has room
        for the flash block.

        Maybe I'll add a script command to send an entire raw packet, or at
        least from the path section on - that'd allow alternate PIDs (like
        OpenTRAC!) too. It'd just be up to the config program/editor to compose
        the packets properly.

        > With that simple capability, you could send a bunch of different
        > beacons from the OT2, rather than being limited to just one in the
        > status text line.

        Exactly, limited only by available space, and with as much flexibility
        in the timing as you want. And with the remote command capability, you
        can change the behavior remotely - for example, you could make a macro
        that sets a flag to change to an alternate set of beacons during an
        emergency response.

        As I was out driving this evening it occurred to me that I should also
        add a message substring search, for regular APRS messages and not just
        authenticated commands. That way, you can add USER functions that are
        accessible to anyone and not just sysops. That could be a subset of the
        configuration functions, or entirely new functions. Have it watch for
        the string 'LIGHTS ON', and your macro can turn on your driveway lights
        for a pre-set period (via the 12-volt switch and a relay) without having
        to add users to the AUTHLIST.

        > Well, if you were a code programmer for Microsoft, I doubt you could
        > make the caps lock led blink on and off with that little code space,
        > but efficient coding skills can sure to a lot in that much space.

        By this point most of the common library functions are already in
        memory, so the last 8k goes a lot further than the first 8k did. Still,
        next time I'm going with at LEAST 256k of flash, and 64k of RAM!

        Scott
      Your message has been successfully submitted and would be delivered to recipients shortly.