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

Remote script updates

Expand Messages
  • Scott Miller
    My original hope was that I d be able to build a complete script editor into the T2, but there just wasn t enough code space. So as a compromise, I ve come up
    Message 1 of 3 , Jun 1, 2008
    • 0 Attachment
      My original hope was that I'd be able to build a complete script editor
      into the T2, but there just wasn't enough code space. So as a
      compromise, I've come up with another option.

      The script editor in otwincfg can now generate a series of PATCH
      commands that'll write the compiled p-code to the appropriate memory
      area. This means you can do script updates over the air, though it
      could get a little tedious for large script.

      Here's an example that prints 'Message 1' and 'Message 2' every 10
      seconds on port A.

      PATCH f60020811500bc00000a5a0d4d65737361676520312e0a000000bc0000145a0d4d6573
      PATCH f620117361676520322e0a003c3c0000000000ff

      You may have to paste both lines separately if you don't have flow
      control turned on.

      If you're running a recent firmware build with the script engine
      compiled in, you'll have a SCRIPT command. Turn SCRIPT OFF, run the
      patch commands, and turn SCRIPT ON and you should start seeing the messages.

      The p-code is simple enough that you could write a script out by hand
      and send patch commands from a TH-D7A, if you were really desperate
      and/or masochistic.

      Scott
    • Bob Poortinga
      ... I hope that includes a CRC or checksum. Without one, a fat-fingered or dropped character could produce unexpected and potentially disasterous results.
      Message 2 of 3 , Jun 2, 2008
      • 0 Attachment
        Scott Miller <scott@...> writes:

        > Here's an example that prints 'Message 1' and 'Message 2' every 10
        > seconds on port A.
        >
        > PATCH f60020811500bc00000a5a0d4d65737361676520312e0a000000bc0000145a0d4d6573
        > PATCH f620117361676520322e0a003c3c0000000000ff

        I hope that includes a CRC or checksum. Without one, a fat-fingered or dropped
        character could produce unexpected and potentially disasterous results.

        Thanks for the scipting engine. This should be fun. At some point down
        the road, I envision an OT3 or OT4 running embedded Linux with a lot of
        memory to play with for things like a Perl or Python interpreter.

        73 de
        --
        Bob Poortinga K9SQL <http://www.linkedin.com/in/bobpoortinga>
        Bloomington, Indiana US
      • Scott Miller
        ... If it s sent over the air, the packet will have a checksum at least. Otherwise I d suggest pasting it one line at a time. The script engine is pretty safe
        Message 3 of 3 , Jun 2, 2008
        • 0 Attachment
          > I hope that includes a CRC or checksum. Without one, a fat-fingered or
          > dropped
          > character could produce unexpected and potentially disasterous results.

          If it's sent over the air, the packet will have a checksum at least.
          Otherwise I'd suggest pasting it one line at a time. The script engine
          is pretty safe and shouldn't do anything harmful if the script gets
          corrupted - worst case, it could poke values into RAM and cause problems.

          > Thanks for the scipting engine. This should be fun. At some point down
          > the road, I envision an OT3 or OT4 running embedded Linux with a lot of
          > memory to play with for things like a Perl or Python interpreter.

          I've got an LPC2387 board sitting on my desk now. 512 KB flash, 96 KB
          RAM, 72 MHz (vs. 60K, 2K, and 7.3 MHz for the T2), USB, Ethernet, SD/MMC
          interface, real-time clock, etc. All for about $3 more than the T2's
          processor.

          Of course, that Ethernet port has the potential to eat up a LOT of code
          space with new features. It'll need to work as an IGate, of course, and
          then a web-based configuration system would be nice, and it could
          function as an RF Ethernet bridge...

          Embedded Linux would be a little heavy... I'll probably stick with
          FreeRTOS (which I've already used on an Atmel ARM7 chip), unless
          switching to a commercial system like uC/OS-II would make more sense.
          In my original prototype I wrote my own USB drivers, SD/MMC interface,
          FAT file system, and so on. If I can afford it, though, I'd rather just
          focus on the TNC stuff and not have to reinvent the wheel.

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