Scripting
Archiver
Posts: 46,084
I need to write a scripting host that will run on the BS2. The concept is that small byte codes will be loaded into an eeprom. The Stamp will then run this code along with other tasks. I can write this from scratch but I was wondering if anyone has tackled any like projects or has any example source. Thanks!
MH
MH
Comments
>I need to write a scripting host that will run on the BS2. The concept is
>that small byte codes will be loaded into an eeprom. The Stamp will then
>run this code along with other tasks. I can write this from scratch but I
>was wondering if anyone has tackled any like projects or has any example
>source. Thanks!
>
>MH
Hi Michael -
This would be rather difficult to do, primarily due to the lack of RAM space
used for data. The programming space is ample, I'd imagine, but the clear
lack space in 32 bytes of RAM would make it difficult unless you
utilized all the of space, and used the BS-2E or the BS-2SX since they both
offer an extra 64 bytes of scratch pad RAM. The RAM is only capable of
storing 26 variables which might make things rather difficult, regardless.
It would make for an interesting project, and challenging, as well.
Good luck with it, and please let us know how you make out with it.
Regards,
Bruce Bates
using the argument SPSTR L where L is the string length. The data is placed
is the scratch pad ram. By using the GET statement you can transfer the data
to an eeprom or use the STORE command and place it on the BS2p. Hope this get
you thinking.
Chuck
the data.. For example... an example script would looks like this:
func init runs OnLoop{
var d1=15;
var d2=1+d1;
System.Objects.Delay=d2;
}
This will get compiled to byte coded. (I have the compiler working....) I
just need to write the interpeter to run in the bs2(sx)... (kinda funny to
have an interpeter run an interpeter.... Oh well. I am looking for examples
on interpeters or equivilent running on the BS2SX.. I just need simple
functionality such as rvalues, lvalues, assignments, etc... Dont know if
this has been done before but anny help would be great...
MH
Original Message
From: <CHIPKEN@a...>
To: <basicstamps@egroups.com>
Sent: Sunday, January 07, 2001 1:45 AM
Subject: Re: [noparse][[/noparse]basicstamps] Scripting
> The new BS2p can take in up to 126 ram bytes on the input at a given time
by
> using the argument SPSTR L where L is the string length. The data is
placed
> is the scratch pad ram. By using the GET statement you can transfer the
data
> to an eeprom or use the STORE command and place it on the BS2p. Hope this
get
> you thinking.
> Chuck
>
>
>
>
>concept is that small byte codes will be loaded into an eeprom. The
>Stamp will then run this code along with other tasks. I can write
>this from scratch but I was wondering if anyone has tackled any like
>projects or has any example source. Thanks!
>... For example... an example script would looks like this:
>
>func init runs OnLoop{
> var d1=15;
> var d2=1+d1;
> System.Objects.Delay=d2;
>}
>
>
>This will get compiled to byte coded. (I have the compiler working....) I
>just need to write the interpeter to run in the bs2(sx)... (kinda funny to
>have an interpeter run an interpeter.... Oh well. I am looking for examples
>on interpeters or equivilent running on the BS2SX.. I just need simple
>functionality such as rvalues, lvalues, assignments, etc... Dont know if
>this has been done before but anny help would be great...
Hi Mike,
I don't know if this has any relation to what you are trying to do...
FWIW my data logger programs for the BS2e function as kind of a
interpreter within an interpreter.
There is a "script", which I call a "scantable", stored in one eeprom
bank. PBASIC code reads that script to determine a sequence of
actions. For example, a simple action would be to read temperature
from a sensor connected to a certain input channel, apply a specific
calibration constant, and do something with the data depending on
some system flags. The channel number and the calibration constant
and data format specifiers are stored as fields in the current record
in the scantable. Also stored there up front is the RUN address of
the "driver" subroutine for processing that kind of sensor input.
The RUN branches to a "driver" subroutine in another bank, which
actually reads the sensor and uses the parameters to finish the
action and then returns back to the main program. The main program
then reads the next record in the scan table, and so on through the
table in a loop.
The advantage of this is that it is possible to configure the system
to do quite a few different things without every changing a line of
PBASIC code. If five temperature sensors with different calibration
constants are installed on the system, then the configuration file
will be five instances of the call to the temperature driver, with 5
different calibration constants. I have a set of standard driver
subroutines available. New drivers can be installed (conforming to
the spec!), also without touching the main program code. Another
program module handles the user interface to the scantable, to set up
or modify the script.
On the BS2e (or BS2sx) there are quite a few gyrations necessary to
read the data from the scantable into a buffer in the scratchpad RAM,
so that it can be accessed in different banks. There are also
gyrations to jump from the main program to the drivers in other banks
and back. I have some more information about how I do that on my web
pages.
I can tell you, I'm really looking forward to the BS2P. Chuck Gracey
included the STORE command, which allows READ and WRITE access to the
entire 16k eeprom independent of the running program bank. So, it
will not be necessary to buffer all that in scratchpad. Furthermore,
I have heard that Chuck is contemplating a BS2Pe that would have a
total of 32k eeprom in 16 banks for data logging applications, and
run at lower power with the same timing as the BS2 (8 mhz in turbo
mode).
The STORE command opens up hacker opportunities. It will be possible
to poke pieces of tokenized program code from one bank to another,
and then RUN it. For example, a new program module could be loaded
in via a modem hookup, the received bytes poked directly into an
uninitialized bank. That might offer some opportunities for your
compiler.
regards,
-- Tracy Allen
electronically monitored ecosystems
http://www.emesystems.com/BS2SX.htm <--- more bank-switching info.