Now, that is interesting. Anybody had any experience with this?
Reply by ●March 14, 20062006-03-14
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
Reply by Steve at fivetrees●March 14, 20062006-03-14
<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
Reply by ●March 14, 20062006-03-14
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
Reply by ●March 14, 20062006-03-14
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
Reply by Steve at fivetrees●March 14, 20062006-03-14
<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
Reply by ●March 14, 20062006-03-14
Hi,
Looks very promising. But I wonder how much realtime response would you
have to sacrifice?
Regards
Nihar
Reply by ●March 14, 20062006-03-14
:) 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
Reply by Eric●March 14, 20062006-03-14
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
Reply by Paul Marciano●March 14, 20062006-03-14
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.