"Shell" or Commandline interpreter for microcontrollers

Hi,

We are currently using an interpretive environment on 68hc12 series of
microcontrollers. We are now moving towards ARM7TDMI and 68hcs12
series.
The interpretive environment is very convenient for manufacturing and
support staff to do some tweaking in the environment.
Are there any C/C++ based RTOS or any other way to have a shell
interpreter/command line interpreter on the serial port for the 68hc12
and ARM7TDMI
Maybe something like this...
http://acceleratedtechnology.com/embedded/nuc_term_app.html

Thanks
Nihar Desai

nihar.desai@gmail.com wrote:
> We are currently using an interpretive environment on 68hc12 series of
> microcontrollers. We are now moving towards ARM7TDMI and 68hcs12
> series.
> The interpretive environment is very convenient for manufacturing and
> support staff to do some tweaking in the environment.
> Are there any C/C++ based RTOS or any other way to have a shell
> interpreter/command line interpreter on the serial port for the 68hc12
> and ARM7TDMI
> Maybe something like this...
> http://acceleratedtechnology.com/embedded/nuc_term_app.html

You might want to ask this question on comp.lang.forth.

Regards,
Paul.

This is my idea of an integrated virtual machine, which seems similar
to the shell you are talking about, but it is a compiler on the PC
side. Once you download your program to the device it runs under the
control of the VM, which includes multi-tasking and RTOS functionality.
A "fat" debugger on the PC side has total remote control of the
embedded VM over the serial port, so you have extensive debugging
support.

http://www.ericengler.com/downloads/EmbeddedVM.txt

My open source tools currently work on the 68hcs12 (9s12) family, and
I'm looking at Arm7 for the future. But I didn't implement this
Embedded VM yet due to lack of time. 

Eric

:) We currenty use forth and want to move away from it. My experience
has been that barely anyone knows about forth and a lot of my
questions, end up on discussions of forth at best or flame wars at
worst!

Thanks
Nihar

Hi,

Looks very promising. But I wonder how much realtime response would you
have to sacrifice?

Regards
Nihar

<nihar.desai@gmail.com> wrote in message 
news:1142285018.261907.151410@e56g2000cwe.googlegroups.com...
> Hi,
>
> We are currently using an interpretive environment on 68hc12 series of
> microcontrollers. We are now moving towards ARM7TDMI and 68hcs12
> series.
> The interpretive environment is very convenient for manufacturing and
> support staff to do some tweaking in the environment.
> Are there any C/C++ based RTOS or any other way to have a shell
> interpreter/command line interpreter on the serial port for the 68hc12
> and ARM7TDMI
> Maybe something like this...
> http://acceleratedtechnology.com/embedded/nuc_term_app.html

It's fairly easy to write a command line interpreter. However, what commands 
should it recognise? You haven't said what you want it to actually do ;).

Steve
http://www.fivetrees.com 

Well yes. It should not be very difficult to write a simple commandline
interpreter.
I was thinking of now re-inventing the wheel.

We currently use Forth in our systems and manufactuing/support use it
for
1. View/Manipulate memory location/registers/EEPROM
2. Write simple loops/functions to automate setup parameters.

Thanks
Nihar

Well yes. It should not be very difficult to write a simple commandline
interpreter.
I was thinking of not re-inventing the wheel.

We currently use Forth in our systems and manufactuing/support use it
for
1. View/Manipulate memory location/registers/EEPROM
2. Write simple loops/functions to automate setup parameters.

Thanks
Nihar

<nihar.desai@gmail.com> wrote in message 
news:1142353051.604879.217590@i40g2000cwc.googlegroups.com...
> Well yes. It should not be very difficult to write a simple commandline
> interpreter.
> I was thinking of now re-inventing the wheel.
>
> We currently use Forth in our systems and manufactuing/support use it
> for
> 1. View/Manipulate memory location/registers/EEPROM
> 2. Write simple loops/functions to automate setup parameters.

Elsewhere you've said you'd like to move away from Forth, so I'll refrain 
from suggesting that ;).

Re not re-inventing the wheel - I sympathise, but I'm certainly not aware of 
any "standard" CLI. I've written such things many times in the past, for 
similar reasons to yourself - I also wrote a PC-hosted scripting system to 
talk to the CLI to provide both ATE and regression testing. Works well. (But 
is sadly proprietary, i.e. I wrote it for a client with specific needs and 
cannot share it.)

Steve
http://www.fivetrees.com 

nihar.desai@gmail.com wrote:
> Hi,
>
> We are currently using an interpretive environment on 68hc12 series of
> microcontrollers. We are now moving towards ARM7TDMI and 68hcs12
> series.
> The interpretive environment is very convenient for manufacturing and
> support staff to do some tweaking in the environment.
> Are there any C/C++ based RTOS or any other way to have a shell
> interpreter/command line interpreter on the serial port for the 68hc12
> and ARM7TDMI
> Maybe something like this...
> http://acceleratedtechnology.com/embedded/nuc_term_app.html
>
> Thanks
> Nihar Desai

Have you considered Lua?

  http://www.lua.org/about.html

I run Lua under embedded Linux on an ARM processor, and it is very
capable.  My understanding is that Lua is used in embedded systems such
as routers to provide an ad hoc tuning/configuration port.

Lua is also very popular with game programmers as a scripting language
that sits on top of lower level C/C++ functions.  I am not personally
interested in game programming, but I think that speaks to Lua's fit in
some quasi-embedded applications where Python is too large.

Lua is written in C for maximum portability.  But note that to get the
most out of it, your RTOS must support shared libraries.  This
requirement kept me from getting Lua to do everything I wanted under
the new Minix 3.  However, statically linked Lua still has a lot to
offer (and worked well under Minix 3).

Since Lua also works under desktop Linux, Windows, etc., you could
easily develop Lua scripts for your embedded system in a convenient
Linux or Windows environment, perhaps simulating your embedded
application, and then migrate the scripts to the actual embedded
target.

Lua is small and fast and should be a good fit for many embedded
applications that would benefit from a scripting language.

Thanks.

Jim