X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=ygMAToDcayS05rrgCXyS21T8wWSckqojk9Mp85HG9wM=; b=tU5PRHKW0IV8q6cAg3GifbrMmtBiBOTHFvZnflKN3C4PpJW87iLPkiw3WA7VAbjC2j cy16veRmVSQYHZ+y5PWiC+h7aAhrDpjC3GBulLVNcERKpjWXCOuR5F4c5hRyL+H8/pO3 wWjxq6xr5MslhjJ9qsWFcU7Dmyok+60SfixnWy/zFihkV/V62rlUC4oc8mU0vGt0I6VT yVKZohNUqfDcM47CaX/sDHei7qITJigCYYSSg5aNsbr4xv2dPrm6G0YThiMlSOR8vaZE OG1HtVbNAw8SnE/jxd63mD9NNdNigdi3DebPrcdskoURscTdEABGkBx8ySQpqIpfK3e1 EJgQ== MIME-Version: 1.0 In-Reply-To: References: <5040BF06 DOT 9040601 AT ecosensory DOT com> <50415C6B DOT 7020402 AT ecosensory DOT com> Date: Mon, 3 Sep 2012 09:54:45 +0200 Message-ID: Subject: Re: [geda-user] OT scripting inside an MCU From: Levente To: geda-user AT delorie DOT com Content-Type: multipart/alternative; boundary=00248c7690468045da04c8c774a1 Reply-To: geda-user AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: geda-user AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk --00248c7690468045da04c8c774a1 Content-Type: text/plain; charset=ISO-8859-1 Thanks for everyone posting answers. They were very helpfull. After seeing these solutions I came to the conclusion that I roll my own interpreter. On Sun, Sep 2, 2012 at 8:16 PM, Hannu Vuolasaho wrote: > > Date: Fri, 31 Aug 2012 19:52:59 -0500 > > From: john AT ecosensory DOT com > > > > > On 08/31/2012 08:58 AM, Levente wrote: > > > On the root node there is a RTOS (also my code), but on the sensors > and actor nodes there's only a while(1) loop. > > > > > > I don't know how to solve the programmability with your approach. > Maybe I wasn't clear enough. I want to change the program at run > > > time as well for example by writing an SMS to the integrated GSM > modem, or editing from a keypad, etc. I could write code in > > > native C of course, but I don't want to re-program the root-card each > time I want to set new temperature, etc. > > Well, I didn't saw that AVR was specified. > However if AVR is used its flash can be reprogrammed interactively from > the other parts except boot-loader part. > AmForth does this and writes data to flash with i! > > Another problem is that Amforth can't be used with C programs. One > solution might be using ficl. ficl.sf.net > > It would require some modification with printf, select and some other > parts. ficl can't and I don't know how it even could be possible to change > the running code, but ficl could write data to eeprom and with that change > the behaviour of the sytem. However under ficl you can call C functions. > But porting ficl needs some work. > > Most Forths are written with assembler and embedding them to existing > project is next to impossible :( > > Best regards, > Hannu Vuolasaho > --00248c7690468045da04c8c774a1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks for everyone posting answers. They were very helpfull.

After = seeing these solutions I came to the conclusion that I roll my own interpre= ter.

On Sun, Sep 2, 2012 at 8:16 PM, Hann= u Vuolasaho <vuokko AT msn DOT com> wrote:
> Date: Fri, 31 Aug 2012 19:52:59 -0500
> From: john AT ecosensory DOT com

>
> On 08/31/2012 08:58 AM, Levente wrote:
> = > On the root node there is a RTOS (also my code), but on the sensors an= d actor nodes there's only a while(1) loop.
> >
> > I don't know how to solve the programmability wi= th your approach. Maybe I wasn't clear enough. I want to change the pro= gram at run
> > time as well for example by writing an SMS to the = integrated GSM modem, or editing from a keypad, etc. I could write code in<= br> > > native C of course, but I don't want to re-program the root-c= ard each time I want to set new temperature, etc.

Well, I didn= 't saw that AVR was specified.
However if AVR is used its flash can= be reprogrammed interactively from the other parts except boot-loader part= .
AmForth does this and writes data to flash with i!

Another problem = is that Amforth can't be used with C programs. One solution might be us= ing ficl. ficl.sf.net<= br>
It would require some modification with printf, select and some other p= arts. ficl can't and I don't know how it even could be possible to = change the running code, but ficl could write data to eeprom and with that = change the behaviour of the sytem. However under ficl you can call C functi= ons. But porting ficl needs some work.

Most Forths are written with assembler and embedding them to existing p= roject is next to impossible :(

Best regards,
Hannu Vuolasaho
=

--00248c7690468045da04c8c774a1--