Remote script updates
- 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.
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
- Scott Miller <scott@...> writes:
> Here's an example that prints 'Message 1' and 'Message 2' every 10I hope that includes a CRC or checksum. Without one, a fat-fingered or dropped
> seconds on port A.
> PATCH f60020811500bc00000a5a0d4d65737361676520312e0a000000bc0000145a0d4d6573
> PATCH f620117361676520322e0a003c3c0000000000ff
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.
Bob Poortinga K9SQL <http://www.linkedin.com/in/bobpoortinga>
Bloomington, Indiana US
> I hope that includes a CRC or checksum. Without one, a fat-fingered orIf it's sent over the air, the packet will have a checksum at least.
> character could produce unexpected and potentially disasterous results.
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 downI've got an LPC2387 board sitting on my desk now. 512 KB flash, 96 KB
> 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.
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
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.