Thanks for the tips.

The project does already have a bootloader and I can store a small "pseudo
program"
in the Data Flash on board the PIC16F876 to test the method.

Later the project can be modified to accommodate external memory for larger
programs.

The debugging idea is useful.

The aim of the project is to allow non-programmers to
set up small applications to perform specific functions without needing to
know
anything much about programming or assemblers etc.

They may for example want to do something like. Read ADC port every 1
second.
If Value > threshold then send com message or set port pin etc.

I thought the instruction set for this would be very small and limited to
Pause, Write Pin, Read Pin, Get ADC, Repeat, Jump, If (single condition)
THEN
(single response).

Mainly IO control.

Thanks

Regards

David Huisman


-----Original Message-----
From: pic microcontroller discussion list
[mailto:PICLIST@MITVMA.MIT.EDU]On Behalf Of Ashley Roll
Sent: Friday, 14 September 2001 13:16
To: PICLIST@MITVMA.MIT.EDU
Subject: Re: [PIC]: pseudo code


Hi David

One way I've seen this, and did myself many years ago (though not on a
microcontroller) is to have a "compiler" on a PC that tokenises a human
readable language to something that is represented by single byte op-codes
followed by their arguments.

You then implement a program on the uC to read the instruction stream from
the external memory, use a jump table to "decode" the instruction and jump
to the code that pulls any arguments needed from the next locations in the
external memory and then executes the instruction.

You also need to have a way to allocate and manage variables and it would be
nice to be able to implement array storage in the external memory for
strings and tables. You could lock the compiler to a particular version of
the hardware/firmware and have it deal with allocating the memory as needed
as it has more resources to throw at optimisation, then encode your
tokenised instructions with actual memory addresses. However, you loose
portability this way but it will make the firmware on the uC easier.

I'd suggest that you have some "high level" instructions like "send serial
byte" "receive serial byte", "configure port" for O/I, "access constant
array" (strings, table etc), "access variable array". But also it would be
good to be able to do lower level stuff. The instruction set requires
careful thought..

Also it may be useful to have a "debug" mode in your firmware which will
validate all instructions and args and allow you to single step and access
variables and other state information. If this could be accessed by a
"monitor" or "bootloader" via a serial interface for instance, people using
your system could use it to do in-circuit debugging. You will probably want
a "bootloader" anyway to load the contents of the Flash/EEPROM.

Hope this helps.
Cheers,
Ash

---
Ashley Roll
Digital Nemesis Pty Ltd
www.digitalnemesis.com
Mobile: +61 (0)417 705 718




> -----Original Message-----
> From: pic microcontroller discussion list
> [mailto:PICLIST@MITVMA.MIT.EDU]On Behalf Of David Huisman
> Sent: Friday, 14 September 2001 12:41 PM
> To: PICLIST@MITVMA.MIT.EDU
> Subject: [PIC]: pseudo code
>
>
> Hi,
>
> I am looking for some ideas for implementing a program in AVR
> that runs a
> "pseudo code" from external serial flash memory.
>
> ie.
> "pseudo code" is written on PC (tokens such as "Delay(100) etc).
> The "pseudo code" is downloaded to external memory on target
> application
> using AVR UART from PC.
> The AVR then runs through the tokens listed in the "pseudo code" and
> performs tasks as required.
>
> Thanks for any constructive ideas.
>
> Best Regards
>
> David Huisman
>
> --
> http://www.piclist.com hint: To leave the PICList
> mailto:piclist-unsubscribe-request@mitvma.mit.edu
>
>
>

--
http://www.piclist.com hint: To leave the PICList
mailto:piclist-unsubscribe-request@mitvma.mit.edu

--
http://www.piclist.com hint: To leave the PICList
mailto:piclist-unsubscribe-request@mitvma.mit.edu