Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #20459 > unrolled thread
| Started by | Tim Wescott <seemywebsite@myfooter.really> |
|---|---|
| First post | 2015-03-13 16:27 -0500 |
| Last post | 2015-03-19 12:02 +0100 |
| Articles | 20 on this page of 80 — 21 participants |
Back to article view | Back to comp.arch.embedded
Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? Tim Wescott <seemywebsite@myfooter.really> - 2015-03-13 16:27 -0500
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? Don Y <this@is.not.me.com> - 2015-03-13 15:03 -0700
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? Tim Wescott <seemywebsite@myfooter.really> - 2015-03-13 19:04 -0500
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? rickman <gnuarm@gmail.com> - 2015-03-18 02:34 -0400
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? Paul E Bennett <Paul_E.Bennett@topmail.co.uk> - 2015-03-18 12:37 +0000
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? Tim Wescott <seemywebsite@myfooter.really> - 2015-03-13 19:06 -0500
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? Don Y <this@is.not.me.com> - 2015-03-13 18:14 -0700
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? Tom Gardner <spamjunk@blueyonder.co.uk> - 2015-03-13 22:30 +0000
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? David Brown <david.brown@hesbynett.no> - 2015-03-14 00:48 +0100
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? Paul Rubin <no.email@nospam.invalid> - 2015-03-13 19:45 -0700
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? David Brown <david.brown@hesbynett.no> - 2015-03-15 23:01 +0100
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? mroberds@att.net - 2015-03-14 00:28 +0000
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? Don Y <this@is.not.me.com> - 2015-03-13 18:45 -0700
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? Clifford Heath <no.spam@please.net> - 2015-03-14 13:14 +1100
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? Don Y <this@is.not.me.com> - 2015-03-13 20:35 -0700
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? George Neuner <gneuner2@comcast.net> - 2015-03-14 23:59 -0400
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? Don Y <this@is.not.me.com> - 2015-03-14 22:30 -0700
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? George Neuner <gneuner2@comcast.net> - 2015-03-15 21:44 -0400
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? Don Y <this@is.not.me.com> - 2015-03-15 20:09 -0700
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? George Neuner <gneuner2@comcast.net> - 2015-03-14 23:59 -0400
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? Don Y <this@is.not.me.com> - 2015-03-16 15:42 -0700
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? George Neuner <gneuner2@comcast.net> - 2015-03-17 04:25 -0400
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? Don Y <this@is.not.me.com> - 2015-03-17 10:39 -0700
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? George Neuner <gneuner2@comcast.net> - 2015-03-17 17:06 -0400
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? Don Y <this@is.not.me.com> - 2015-03-17 19:36 -0700
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? George Neuner <gneuner2@comcast.net> - 2015-03-18 01:50 -0400
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? Don Y <this@is.not.me.com> - 2015-03-17 23:32 -0700
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? Robert Wessel <robertwessel2@yahoo.com> - 2015-03-18 05:30 -0500
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? Don Y <this@is.not.me.com> - 2015-03-18 10:32 -0700
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? Robert Wessel <robertwessel2@yahoo.com> - 2015-03-18 16:11 -0500
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? Don Y <this@is.not.me.com> - 2015-03-18 18:26 -0700
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? George Neuner <gneuner2@comcast.net> - 2015-03-19 02:09 -0400
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? Don Y <this@is.not.me.com> - 2015-03-19 12:04 -0700
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? George Neuner <gneuner2@comcast.net> - 2015-03-19 17:52 -0400
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? Don Y <this@is.not.me.com> - 2015-03-19 15:44 -0700
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? George Neuner <gneuner2@comcast.net> - 2015-03-20 02:38 -0400
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? David Brown <david.brown@hesbynett.no> - 2015-03-20 10:05 +0100
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? Don Y <this@is.not.me.com> - 2015-03-20 02:51 -0700
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? David Brown <david.brown@hesbynett.no> - 2015-03-20 11:49 +0100
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? Don Y <this@is.not.me.com> - 2015-03-20 05:12 -0700
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? David Brown <david.brown@hesbynett.no> - 2015-03-20 14:55 +0100
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? Don Y <this@is.not.me.com> - 2015-03-20 15:07 -0700
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? George Neuner <gneuner2@comcast.net> - 2015-03-20 14:11 -0400
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? Don Y <this@is.not.me.com> - 2015-03-20 15:20 -0700
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? George Neuner <gneuner2@comcast.net> - 2015-03-22 09:28 -0400
OT: EoL Don Y <this@is.not.me.com> - 2015-03-22 12:19 -0700
Re: OT: EoL Reinhardt Behm <rbehm@hushmail.com> - 2015-03-23 07:30 +0800
Re: OT: EoL Don Y <this@is.not.me.com> - 2015-03-22 17:19 -0700
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? Don Y <this@is.not.me.com> - 2015-03-20 02:12 -0700
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? Mel Wilson <mwilson@the-wire.com> - 2015-03-20 13:24 +0000
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? Don Y <this@is.not.me.com> - 2015-03-20 10:20 -0700
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? George Neuner <gneuner2@comcast.net> - 2015-03-22 08:12 -0400
OT: senses Don Y <this@is.not.me.com> - 2015-03-22 13:53 -0700
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? Wouter van Ooijen <wouter@voti.nl> - 2015-03-15 10:11 +0100
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? mroberds@att.net - 2015-03-14 07:50 +0000
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? Mel Wilson <mwilson@the-wire.com> - 2015-03-14 12:24 +0000
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? Don Y <this@is.not.me.com> - 2015-03-14 11:46 -0700
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? George Neuner <gneuner2@comcast.net> - 2015-03-14 23:58 -0400
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? Clifford Heath <no.spam@please.net> - 2015-03-14 12:59 +1100
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? Paul Rubin <no.email@nospam.invalid> - 2015-03-13 20:16 -0700
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? Tim Wescott <tim@seemywebsite.com> - 2015-03-13 23:20 -0500
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? Paul Rubin <no.email@nospam.invalid> - 2015-03-13 22:29 -0700
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? Paul Rubin <no.email@nospam.invalid> - 2015-03-13 22:46 -0700
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? Stefan Reuther <stefan.news@arcor.de> - 2015-03-14 11:02 +0100
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? Anders.Montonen@kapsi.spam.stop.fi.invalid - 2015-03-16 11:37 +0000
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? Paul Rubin <no.email@nospam.invalid> - 2015-03-16 13:53 -0700
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? Robert Wessel <robertwessel2@yahoo.com> - 2015-03-14 03:16 -0500
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2015-03-14 10:27 +0200
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? Paul E Bennett <Paul_E.Bennett@topmail.co.uk> - 2015-03-14 08:43 +0000
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2015-03-14 13:55 +0200
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? Paul E Bennett <Paul_E.Bennett@topmail.co.uk> - 2015-03-14 12:14 +0000
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? stephen@mpeforth.com (Stephen Pelc) - 2015-03-14 18:04 +0000
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2015-03-14 23:14 +0200
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? Allan Herriman <allanherriman@hotmail.com> - 2015-03-14 10:08 +0000
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? George Neuner <gneuner2@comcast.net> - 2015-03-15 00:55 -0400
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? Paul Rubin <no.email@nospam.invalid> - 2015-03-14 22:20 -0700
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? George Neuner <gneuner2@comcast.net> - 2015-03-15 20:35 -0400
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? Paul Rubin <no.email@nospam.invalid> - 2015-03-15 18:47 -0700
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? stephen@mpeforth.com (Stephen Pelc) - 2015-03-18 10:03 +0000
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2015-03-19 12:02 +0100
Page 4 of 4 — ← Prev page 1 2 3 [4]
| From | Tim Wescott <tim@seemywebsite.com> |
|---|---|
| Date | 2015-03-13 23:20 -0500 |
| Message-ID | <hKSdnRD7kPOFKp7InZ2dnUU7-dWdnZ2d@giganews.com> |
| In reply to | #20471 |
On Fri, 13 Mar 2015 20:16:32 -0700, Paul Rubin wrote: > Tim Wescott <seemywebsite@myfooter.really> writes: >> I'm planning on having a chunk of serial flash (or an SD card)... my >> understanding is that I can expect Lua to use about 100k of flash, >> which is a bit much for me but bearable. ... We briefly considered >> Java, but it just looks entirely too big -- it would basically drive us >> to use Linux or some other "real" OS ... I'm looking for opinions, >> so fire away! > > OK, embedded enterpreters were one of my favorite subjects for a while, > so here goes. > > 1. The smallest SD cards available these days are in the gigabytes, so > 100k is nothing. The interpreter's RAM footprint is probably of more > concern on a small embedded system. How much ram are you willing to > use? I also have to ask whether you're going to be the one writing the > customizations at the user's request, or if the customer him/herself > wants to write customizations. You should probably stay away from weird > or difficult languages if the customer is doing the customization. > > 2. TCL and Lua are both quite easy to embed but Lua is a more modern and > generally better language, so I'd pick it over Tcl. Lua has more of a > programmer community these days (lots of mobile games and apps embed it) > and there's a high performance compiler (LuaJIT) available if you want > that. > > 3. However, from my language snob perspective, Lua and Tcl are both > somewhat distasteful. Also, you'll probably get much better user uptake > from Javascript (another distasteful language) since so many people know > it. Javascript will need a lot more machine resources and I don't know > what the embedding side is like, but you might want to consider it if > you have the CPU and RAM for it. > > 4. Other alternatives include Lisp dialects--I used to be into these. > You might look at GNU Guile (Scheme), Hedgehog Lisp (sort of a > functional subset of Scheme), and Lysp > (http://piumarta.com/software/lysp/). I guess each of these have > drawbacks. > > 5. You can use Javacard or J2ME in an embedded (non-Linux) environment > but I'm not sure why you'd want to. It requires external compilation > tools and a somewhat bureaucratic approach to development. I mention it > because you brought it up. Main thing it tries to supply (with some > success but not total) is security against untrusted, potentially > hostile scripts trying to mess with the surrounding application or with > other scripts in the same container. I don't know if that's an issue > for what you're doing. > > 6. You can also consider Python though its embedding challenges are > harder. I think it can be used without Linux but I've never done it. If > you go this route it's probably better to write your outer application > in it, calling C modules from Python as necessary, rather than the other > way around (writing the outer app in C and loading Python into it). > > 7. If you're -really- resource constrained or your scripts need realtime > guarantees, there is Forth, but I'd stay away from it if you have enough > cpu and memory to run something like Lua. > > Of all the above, based on the limited info you've given, the quick > answer is probably "Lua unless you can afford Javascript or you're a > language geek and like Lisp". If you can say more about your > application and your hardware constraints, that might help narrow things > down. I'm trying to stick with an ARM M4 cored processor that has 256kB to 512kB of flash, and maybe 64kB of RAM, and a 72MHz CPU speed. Everything can run at "human time", so delays of no less than 50ms are OK. There is an issue that a really hot operator shouldn't be able to overrun the machine, but the buttons are actuated by a wand (it's complicated -- they just are), which should slow things down. Even if I loved Lisp (or Forth) more than anything else in the world, I'd still use Lua if it meant better user acceptance. I'll consider Javascript for that very reason, particularly if I can find an open- source interpreter that seems serious and well-supported. -- www.wescottdesign.com
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2015-03-13 22:29 -0700 |
| Message-ID | <87mw3g5eqm.fsf@nightsong.com> |
| In reply to | #20473 |
Tim Wescott <tim@seemywebsite.com> writes: > I'm trying to stick with an ARM M4 cored processor that has 256kB to > 512kB of flash, and maybe 64kB of RAM, and a 72MHz CPU speed. Hmm, ok, I think Javascript is not practical in something that small. Lua can work but will be a little bit cramped. How much of that flash and ram will actually be available to Lua (i.e. not needed by the non-Lua code)? How complicated do you expect the scripts to be? Are you ok with cross-compiling the scripts? That means loading a script by compiling it to bytecode with a PC application, then loading the bytecode to your embedded board, instead of including the compiler in the board so you can talk to it with a terminal. http://wiki.eluaproject.net/FAQ#minimumrequirements has some info. TCL (especially old versions) is probably smaller. I know there are some bigger Cortex M4 parts, like ST has one with 2MB of flash and 256k of ram -- do they cost too much or something? > I'll consider Javascript for that very reason, particularly if I can > find an open- source interpreter that seems serious and > well-supported. You'd have to use a bigger processor, but it still may be worth it. I worked on something a couple years ago that could have been done in C on an 8 bitter, but we used an embedded ARM7/Linux system with 64 meg of ram for development convenience, adding maybe $5 to the hardware BOM which was acceptable for what we were doing. I think it was well justified by the flexibility it gave us. We were able to ship a better product faster. I don't know anything about JS embeddability. I've only programmed it at the application level. I know that various applications other than web browsers do embed JS, but it may be a lot more complicated than using Lua. Will your scripts have to process much non-numeric data like strings and complicated structures? If not, maybe there's some BASIC dialect that your users would find comfortable, especially if they're hardware types who have been around for a while.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2015-03-13 22:46 -0700 |
| Message-ID | <87ioe45dy8.fsf@nightsong.com> |
| In reply to | #20474 |
Paul Rubin <no.email@nospam.invalid> writes: > I think Javascript is not practical in something that small. Hmm, this may be of interest: http://www.espruino.com/ It claims to run JS in a 64k ram part like yours. I just came across it and don't know any more. I don't know what dialect of JS it uses. It could be limited in a way that frustrates your users who are used to programming browser JS. I'm sure that fancy modern JS implementations like V8 are way larger.
[toc] | [prev] | [next] | [standalone]
| From | Stefan Reuther <stefan.news@arcor.de> |
|---|---|
| Date | 2015-03-14 11:02 +0100 |
| Message-ID | <me14f8.22c.1@stefan.msgid.phost.de> |
| In reply to | #20473 |
Tim Wescott wrote: > On Fri, 13 Mar 2015 20:16:32 -0700, Paul Rubin wrote: >>7. If you're -really- resource constrained or your scripts need realtime >>guarantees, there is Forth, but I'd stay away from it if you have enough >>cpu and memory to run something like Lua. >> >>Of all the above, based on the limited info you've given, the quick >>answer is probably "Lua unless you can afford Javascript or you're a >>language geek and like Lisp". +1 for that. Lisp can be implemented in 5k flash, but still has the problem of user acceptance. So I would choose Lua; I have already used it for writing test drivers. Another group managed to sneak a Python interpreter into their product, but that's a huge Java blob, so I cannot say how much memory the Python takes. > I'm trying to stick with an ARM M4 cored processor that has 256kB to > 512kB of flash, and maybe 64kB of RAM, and a 72MHz CPU speed. Everything > can run at "human time", so delays of no less than 50ms are OK. There is > an issue that a really hot operator shouldn't be able to overrun the > machine, but the buttons are actuated by a wand (it's complicated -- they > just are), which should slow things down. This should be enough for Lua. If it's not enough, I believe Lua can be off-line compiled. Stefan
[toc] | [prev] | [next] | [standalone]
| From | Anders.Montonen@kapsi.spam.stop.fi.invalid |
|---|---|
| Date | 2015-03-16 11:37 +0000 |
| Message-ID | <me6f97$nok$1@speranza.aioe.org> |
| In reply to | #20471 |
Paul Rubin <no.email@nospam.invalid> wrote: > 6. You can also consider Python though its embedding challenges are > harder. I think it can be used without Linux but I've never done it. I don't know anything about it, but Micro Python is a thing that exists. It is a Python 3 implementation optimized for microcontrollers. <http://micropython.org/> -a
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2015-03-16 13:53 -0700 |
| Message-ID | <87oansoe9t.fsf@jester.gateway.sonic.net> |
| In reply to | #20505 |
Anders.Montonen@kapsi.spam.stop.fi.invalid writes: > I don't know anything about it, but Micro Python is a thing that exists. > It is a Python 3 implementation optimized for microcontrollers. > <http://micropython.org/> It's too large for this purpose, apparently. I'm told it needs around 256k. I've been looking at Microscheme and Picobit (both small Scheme implementations). Microscheme (intended for AVR8) is too minimalistic but Picobit is interesting. There is an ARM port of Picobit but I don't know how well maintained it is.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2015-03-14 03:16 -0500 |
| Message-ID | <vkq7ga5gj7f3uugd380mvml72di7j6kat2@4ax.com> |
| In reply to | #20459 |
On Fri, 13 Mar 2015 16:27:12 -0500, Tim Wescott <seemywebsite@myfooter.really> wrote: >The title says most of it. > >I'm working on a project for which the customer wants a lot of flexibility >to customize a product. The existing "macro language" is ancient (ca >1985), cryptic (it looks like machine language), limited, clunky, etc. >The customer is willing to change. > >I'm planning on having a chunk of serial flash (or an SD card) with a file >system on it (maybe FAT, maybe something home-rolled and primitive). >Scripts will be stored as text files, and read in as appropriate. > >Rather than just use some clunky cryptic and limited language that's >unique to the problem and to me (and charging my customer up the wazoo for >it), I'd like to use something that's open-source and available. >Something that uses modest resources is to be preferred -- my >understanding is that I can expect Lua to use about 100k of flash, which >is a bit much for me but bearable. I don't know how Tcl compares -- I >just know that it's an alternative. > >So -- anyone have any direct experience with either of these, or with >something else? We briefly considered Java, but it just looks entirely >too big -- it would basically drive us to use Linux or some other "real" >OS (even the little linuxes are too big for my tastes) -- I'd really >rather just have a scripting engine that gets called whenever a script >needs to run, and otherwise doesn't need much hand-holding from the >application code. > >I'm looking for opinions, so fire away! My limited experience is that Lua is a more "normal" language, not that Tcl is hard, it's just going to look weirder to most users, and Lua (in its smaller forms) has a smaller footprint, and is a bit faster than Tcl (whether either of those is an issue is obviously application dependent, but Tcl's "everything is a string" metaphor hurts performance some). Both interface fairly easily to your application, and allow you to add your own commands/functions easily. Both are actively supported, developed, and have widespread use. If you eventually move to Java, Tcl does have a JVM version, which might be useful for migration purposes. I really don't think you'd go far wrong with either though.
[toc] | [prev] | [next] | [standalone]
| From | Tauno Voipio <tauno.voipio@notused.fi.invalid> |
|---|---|
| Date | 2015-03-14 10:27 +0200 |
| Message-ID | <me0rbd$egm$1@dont-email.me> |
| In reply to | #20459 |
On 13.3.15 23:27, Tim Wescott wrote: > The title says most of it. > > I'm working on a project for which the customer wants a lot of flexibility > to customize a product. The existing "macro language" is ancient (ca > 1985), cryptic (it looks like machine language), limited, clunky, etc. > The customer is willing to change. > > I'm planning on having a chunk of serial flash (or an SD card) with a file > system on it (maybe FAT, maybe something home-rolled and primitive). > Scripts will be stored as text files, and read in as appropriate. > > Rather than just use some clunky cryptic and limited language that's > unique to the problem and to me (and charging my customer up the wazoo for > it), I'd like to use something that's open-source and available. > Something that uses modest resources is to be preferred -- my > understanding is that I can expect Lua to use about 100k of flash, which > is a bit much for me but bearable. I don't know how Tcl compares -- I > just know that it's an alternative. > > So -- anyone have any direct experience with either of these, or with > something else? We briefly considered Java, but it just looks entirely > too big -- it would basically drive us to use Linux or some other "real" > OS (even the little linuxes are too big for my tastes) -- I'd really > rather just have a scripting engine that gets called whenever a script > needs to run, and otherwise doesn't need much hand-holding from the > application code. > > I'm looking for opinions, so fire away! > My vote to Jim-TCL or LUA. -- Tauno Voipio
[toc] | [prev] | [next] | [standalone]
| From | Paul E Bennett <Paul_E.Bennett@topmail.co.uk> |
|---|---|
| Date | 2015-03-14 08:43 +0000 |
| Message-ID | <cmialpF8ag3U1@mid.individual.net> |
| In reply to | #20459 |
Tim Wescott wrote: > The title says most of it. > > I'm working on a project for which the customer wants a lot of flexibility > to customize a product. The existing "macro language" is ancient (ca > 1985), cryptic (it looks like machine language), limited, clunky, etc. > The customer is willing to change. > > I'm planning on having a chunk of serial flash (or an SD card) with a file > system on it (maybe FAT, maybe something home-rolled and primitive). > Scripts will be stored as text files, and read in as appropriate. > > Rather than just use some clunky cryptic and limited language that's > unique to the problem and to me (and charging my customer up the wazoo for > it), I'd like to use something that's open-source and available. > Something that uses modest resources is to be preferred -- my > understanding is that I can expect Lua to use about 100k of flash, which > is a bit much for me but bearable. I don't know how Tcl compares -- I > just know that it's an alternative. > > So -- anyone have any direct experience with either of these, or with > something else? We briefly considered Java, but it just looks entirely > too big -- it would basically drive us to use Linux or some other "real" > OS (even the little linuxes are too big for my tastes) -- I'd really > rather just have a scripting engine that gets called whenever a script > needs to run, and otherwise doesn't need much hand-holding from the > application code. > > I'm looking for opinions, so fire away! > Weighing in with a base-line requirement of about 8k of code-space and easily extensible I would suggest Forth could probably suit your needs very well. You add a little bit to it and design the script language environment you need. You didn't mention which processor you are using in the product but there is a Forth for most targets out there. See <http://www.mpeforth.com/> or <http://www.forth.com/> for further information. There are also some free to download books to help. -- ******************************************************************** Paul E. Bennett IEng MIET.....<email://Paul_E.Bennett@topmail.co.uk> Forth based HIDECS Consultancy.............<http://www.hidecs.co.uk> Mob: +44 (0)7811-639972 Tel: +44 (0)1392-426688 Going Forth Safely ..... EBA. www.electric-boat-association.org.uk.. ********************************************************************
[toc] | [prev] | [next] | [standalone]
| From | Tauno Voipio <tauno.voipio@notused.fi.invalid> |
|---|---|
| Date | 2015-03-14 13:55 +0200 |
| Message-ID | <me17hd$m44$1@dont-email.me> |
| In reply to | #20479 |
On 14.3.15 10:43, Paul E Bennett wrote: > Tim Wescott wrote: > >> The title says most of it. >> >> I'm working on a project for which the customer wants a lot of flexibility >> to customize a product. The existing "macro language" is ancient (ca >> 1985), cryptic (it looks like machine language), limited, clunky, etc. >> The customer is willing to change. >> >> I'm planning on having a chunk of serial flash (or an SD card) with a file >> system on it (maybe FAT, maybe something home-rolled and primitive). >> Scripts will be stored as text files, and read in as appropriate. >> >> Rather than just use some clunky cryptic and limited language that's >> unique to the problem and to me (and charging my customer up the wazoo for >> it), I'd like to use something that's open-source and available. >> Something that uses modest resources is to be preferred -- my >> understanding is that I can expect Lua to use about 100k of flash, which >> is a bit much for me but bearable. I don't know how Tcl compares -- I >> just know that it's an alternative. >> >> So -- anyone have any direct experience with either of these, or with >> something else? We briefly considered Java, but it just looks entirely >> too big -- it would basically drive us to use Linux or some other "real" >> OS (even the little linuxes are too big for my tastes) -- I'd really >> rather just have a scripting engine that gets called whenever a script >> needs to run, and otherwise doesn't need much hand-holding from the >> application code. >> >> I'm looking for opinions, so fire away! >> > > > Weighing in with a base-line requirement of about 8k of code-space and > easily extensible I would suggest Forth could probably suit your needs very > well. You add a little bit to it and design the script language environment > you need. You didn't mention which processor you are using in the product > but there is a Forth for most targets out there. > > See <http://www.mpeforth.com/> or <http://www.forth.com/> for further > information. There are also some free to download books to help. AFAIK, Forth is the language of OpenBoot and its ancestors. I have last really used Forth with boot of Intergraph workstations (based on M68k) in early 1980's. Forth is a fascinating language for old HP calculator users, but in my classification, it belongs to the group of write-only languages. -- -TV
[toc] | [prev] | [next] | [standalone]
| From | Paul E Bennett <Paul_E.Bennett@topmail.co.uk> |
|---|---|
| Date | 2015-03-14 12:14 +0000 |
| Message-ID | <cmin1jFbeo0U1@mid.individual.net> |
| In reply to | #20482 |
Tauno Voipio wrote: >> Weighing in with a base-line requirement of about 8k of code-space and >> easily extensible I would suggest Forth could probably suit your needs >> very well. You add a little bit to it and design the script language >> environment you need. You didn't mention which processor you are using in >> the product but there is a Forth for most targets out there. >> >> See <http://www.mpeforth.com/> or <http://www.forth.com/> for further >> information. There are also some free to download books to help. > > > AFAIK, Forth is the language of OpenBoot and its ancestors. I have last > really used Forth with boot of Intergraph workstations (based on M68k) > in early 1980's. It still is and there is also a version called FICL which most BSD users might recognise. > Forth is a fascinating language for old HP calculator users, but in my > classification, it belongs to the group of write-only languages. Whilst the underlying VM model has remained the same, there have been a number of changes in the language definition. However, it still performs well as an Application Specific Language Builder allowing you to create the script language you need. With a reasonable coding style it is far from Write-Only. As Chuck would say, Forth is an "Amplifier of Programmer ability". It has been used in some collaborative projects where reading others code was an important aspect of the project. Still, it is Tim's choice. -- ******************************************************************** Paul E. Bennett IEng MIET.....<email://Paul_E.Bennett@topmail.co.uk> Forth based HIDECS Consultancy.............<http://www.hidecs.co.uk> Mob: +44 (0)7811-639972 Tel: +44 (0)1392-426688 Going Forth Safely ..... EBA. www.electric-boat-association.org.uk.. ********************************************************************
[toc] | [prev] | [next] | [standalone]
| From | stephen@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2015-03-14 18:04 +0000 |
| Message-ID | <550477c2.103262209@news.eternal-september.org> |
| In reply to | #20482 |
On Sat, 14 Mar 2015 13:55:08 +0200, Tauno Voipio <tauno.voipio@notused.fi.invalid> wrote: >AFAIK, Forth is the language of OpenBoot and its ancestors. I have last >really used Forth with boot of Intergraph workstations (based on M68k) >in early 1980's. > >Forth is a fascinating language for old HP calculator users, but in my >classification, it belongs to the group of write-only languages. All languages of that period suffered from such remarks. Try a modern Forth in order to make current observations. I speak as someone who wrote their first software in 1967. Stephen -- Stephen Pelc, stephenXXX@mpeforth.com MicroProcessor Engineering Ltd - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web: http://www.mpeforth.com - free VFX Forth downloads
[toc] | [prev] | [next] | [standalone]
| From | Tauno Voipio <tauno.voipio@notused.fi.invalid> |
|---|---|
| Date | 2015-03-14 23:14 +0200 |
| Message-ID | <me28ak$i64$1@dont-email.me> |
| In reply to | #20485 |
On 14.3.15 20:04, Stephen Pelc wrote: > On Sat, 14 Mar 2015 13:55:08 +0200, Tauno Voipio > <tauno.voipio@notused.fi.invalid> wrote: > >> AFAIK, Forth is the language of OpenBoot and its ancestors. I have last >> really used Forth with boot of Intergraph workstations (based on M68k) >> in early 1980's. >> >> Forth is a fascinating language for old HP calculator users, but in my >> classification, it belongs to the group of write-only languages. > > All languages of that period suffered from such remarks. Try a modern > Forth in order to make current observations. > > I speak as someone who wrote their first software in 1967. I win by a few years, June 1964, with an IBM 1620. -- -TV
[toc] | [prev] | [next] | [standalone]
| From | Allan Herriman <allanherriman@hotmail.com> |
|---|---|
| Date | 2015-03-14 10:08 +0000 |
| Message-ID | <55040887$0$2843$c3e8da3$76491128@news.astraweb.com> |
| In reply to | #20459 |
On Fri, 13 Mar 2015 16:27:12 -0500, Tim Wescott wrote: > The title says most of it. > > I'm working on a project for which the customer wants a lot of > flexibility to customize a product. The existing "macro language" is > ancient (ca 1985), cryptic (it looks like machine language), limited, > clunky, etc. The customer is willing to change. > > I'm planning on having a chunk of serial flash (or an SD card) with a > file system on it (maybe FAT, maybe something home-rolled and > primitive). Scripts will be stored as text files, and read in as > appropriate. > > Rather than just use some clunky cryptic and limited language that's > unique to the problem and to me (and charging my customer up the wazoo > for it), I'd like to use something that's open-source and available. > Something that uses modest resources is to be preferred -- my > understanding is that I can expect Lua to use about 100k of flash, which > is a bit much for me but bearable. I don't know how Tcl compares -- I > just know that it's an alternative. > > So -- anyone have any direct experience with either of these, or with > something else? We briefly considered Java, but it just looks entirely > too big -- it would basically drive us to use Linux or some other "real" > OS (even the little linuxes are too big for my tastes) -- I'd really > rather just have a scripting engine that gets called whenever a script > needs to run, and otherwise doesn't need much hand-holding from the > application code. > > I'm looking for opinions, so fire away! We had a related discussion in this thread from the middle of last year: https://groups.google.com/d/msg/comp.arch.embedded/geUFbpOZ2J4/eY4zcBLWsJYJ Reading through it, I think Squirrel is the only language that this thread hasn't mentioned. Regards, Allan
[toc] | [prev] | [next] | [standalone]
| From | George Neuner <gneuner2@comcast.net> |
|---|---|
| Date | 2015-03-15 00:55 -0400 |
| Message-ID | <951agalj4iglmlroguhea2ctqtm52g28bt@4ax.com> |
| In reply to | #20459 |
On Fri, 13 Mar 2015 16:27:12 -0500, Tim Wescott <seemywebsite@myfooter.really> wrote: >Rather than just use some clunky cryptic and limited language that's >unique to the problem and to me (and charging my customer up the wazoo for >it), I'd like to use something that's open-source and available. >Something that uses modest resources is to be preferred -- my >understanding is that I can expect Lua to use about 100k of flash, which >is a bit much for me but bearable. I don't know how Tcl compares -- I >just know that it's an alternative. Javacard would fit depending on the libraries you include. Javacard is a Java VM, but pure interpreter and very small. It does not support dynamic load or verification of class files. Be aware though that Javacard also has no GC - applets have to request heap space at startup and manage it (if they are so inclined) themselves. I haven't used Lua myself (dose of salt) but my understanding is that the VM is separable. If you can cross compile the bytecode, it should be workable. TCL will look weird to many people. IME (not recent) it also has lousy feedback on script errors. I have never tried to use it in a really small space so I can't comment on it's minimum RAM needs. Code space wise, any of these should have plenty of headroom with 100KB. The real question is how much RAM can they use? >So -- anyone have any direct experience with either of these, or with >something else? We briefly considered Java, but it just looks entirely >too big -- it would basically drive us to use Linux or some other "real" >OS (even the little linuxes are too big for my tastes) -- I'd really >rather just have a scripting engine that gets called whenever a script >needs to run, and otherwise doesn't need much hand-holding from the >application code. > >I'm looking for opinions, so fire away! If you have a little more [well, 3x] space I'd mention TCC. Have you looked at PicoC ? https://code.google.com/p/picoc/ George
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2015-03-14 22:20 -0700 |
| Message-ID | <87lhiyu99i.fsf@jester.gateway.sonic.net> |
| In reply to | #20492 |
George Neuner <gneuner2@comcast.net> writes: > Javacard also has no GC - applets have to request heap space at > startup and manage it (if they are so inclined) themselves. GC is present in some Javacard devices. Maybe more of a problem is that I don't think Javacard is open source. > TCL will look weird to many people.... I can't comment on it's minimum > RAM needs. I checked into this yesterday and tcl these days has gotten rather bloated. The "small footprint" version is 100k-200k of code: http://jim.tcl.tk/index.html/doc/www/www/index.html I used an embedded tcl several versions back and it was smaller then, but people probably expect the recent improvements. > If you have a little more [well, 3x] space I'd mention TCC. > Have you looked at PicoC ? https://code.google.com/p/picoc/ It doesn't sound like there's much need to host the compiler on the embedded board, and using C defeats a main benefit of scripting languages, which is to supply automatic memory management and protect the user from the usual C hazards like pointer errors causing memory corruption. I do see there are some Scheme implementations around with mighty small ram requirements, e.g. http://armpit.sourceforge.net/ (scroll down the page) discusses some targets with as little as 32k of flash and 8k of ram. It is written in ARM assembler though, making me wonder if it has a reasonable C FFI. https://github.com/ryansuchocki/microscheme might also be interesting: someone just pointed it out to me and I haven't looked at it much yet. For simple purposes like UI customization, Scheme is probably ok for non-Schemers since they can probably get their stuff working by copying and modifying existing examples. There are also lots of books on Scheme. So it seems worth looking into these if Lua turns out to be too large. I looked at Tiny Scheme which is a well known small implementation (about 40k), but its ram footprint looks rather large, maybe since it uses a recursive S-expression evaluator instead of a VM. I'm a fan of Hedgehog Lisp which has an offline compiler and a very compact VM (about 20k), but it's a weird dialect with almost no users. Sometimes I think of hacking it to be more compatible with Scheme, and maybe adding alternative front end to it. For a while I thought using its VM as a runtime for a Haskell dialect for microcontrollers that I wanted to call "Control-H", so that the file extension would be a backspace character. ;-)
[toc] | [prev] | [next] | [standalone]
| From | George Neuner <gneuner2@comcast.net> |
|---|---|
| Date | 2015-03-15 20:35 -0400 |
| Message-ID | <7t5cga18tid0lq37km71v98krkom89dk8k@4ax.com> |
| In reply to | #20493 |
On Sat, 14 Mar 2015 22:20:25 -0700, Paul Rubin <no.email@nospam.invalid> wrote: >George Neuner <gneuner2@comcast.net> writes: >> Javacard also has no GC - applets have to request heap space at >> startup and manage it (if they are so inclined) themselves. > >GC is present in some Javacard devices. Javacard does not require GC - that's an extension. The standard manager allocates but does not recycle until the applet ends. >Maybe more of a problem is that I don't think Javacard is open source. Oracle's VM isn't *libre*, but it is an open reference platform. There are FOSS versions available. >For simple purposes like UI customization, Scheme is probably ok for >non-Schemers since they can probably get their stuff working by copying >and modifying existing examples. There are also lots of books on >Scheme. So it seems worth looking into these if Lua turns out to be too >large. I also like Scheme, but it is a non-starter for a lot of people. Notwithstanding that a lot of scripts could be accomplished by modifying examples, the prefix notation just seems to turn off many people. >I'm a fan of Hedgehog Lisp which has an offline compiler and a very >compact VM (about 20k), but it's a weird dialect with almost no users. >Sometimes I think of hacking it to be more compatible with Scheme, and >maybe adding alternative front end to it. For a while I thought using >its VM as a runtime for a Haskell dialect for microcontrollers that I >wanted to call "Control-H", so that the file extension would be a >backspace character. ;-) I have, on occasion, embedded Guile and mzScheme. Bare bones, they are small enough, but useful configurations grow quickly. George
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2015-03-15 18:47 -0700 |
| Message-ID | <877fuhu30g.fsf@jester.gateway.sonic.net> |
| In reply to | #20499 |
George Neuner <gneuner2@comcast.net> writes: >>GC is present in some Javacard devices. > Javacard does not require GC - that's an extension. Right, fair enough, but some devices do include it. > The standard manager allocates but does not recycle until the applet > ends. Sort of like Microscheme :) > Oracle's [J2ME, Javacard?] VM isn't *libre*, but it is an open > reference platform. There are FOSS versions available. Oh cool, good to know. > I also like Scheme, but...the prefix notation just seems to turn off > many people. I have, on occasion, embedded Guile and mzScheme. Bare > bones, they are small enough, but useful configurations grow quickly. Hmm, I had been wondering about the memory footprint of Guile. I know that it has some front ends for other language syntaxes, particularly Ecmascript a/k/a Javascript, with Lua supposedly in development. I spent yesterday evening looking into very small ram-stingy Scheme implementations and I wonder whether the Guile Ecmascript front end could be used with them. But, it probably increases the product's support burden. Picobit looks interesting: https://github.com/stamourv/picobit Absolutely unsuitable for non-nerd user scripting, but maybe of interest to language geeks: Purescript (purescript.org) is a Haskell dialect that compiles to Javascript, and could be probably made to generate Scheme instead. I think someone is already working on retargeting it to Lua. But I think the pure functional approach (no mutable data, lots of GC) isn't a good fit for small embedded systems.
[toc] | [prev] | [next] | [standalone]
| From | stephen@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2015-03-18 10:03 +0000 |
| Message-ID | <55094c23.419778925@news.eternal-september.org> |
| In reply to | #20459 |
On Fri, 13 Mar 2015 16:27:12 -0500, Tim Wescott <seemywebsite@myfooter.really> wrote: >I'm planning on having a chunk of serial flash (or an SD card) with a file >system on it (maybe FAT, maybe something home-rolled and primitive). >Scripts will be stored as text files, and read in as appropriate. > >Rather than just use some clunky cryptic and limited language that's >unique to the problem and to me (and charging my customer up the wazoo for >it), I'd like to use something that's open-source and available. There are a number of Forth systems out there that fit the bill, including ours. A basic multi-tasking Forth system with SD card driver, FAT file system and file API layer can be done in around 32 kb of Flash on a Cortex-Mx class CPU. Note that our Forth systems are proprietary, not FOSS. Our website and contact details are below. Stephen -- Stephen Pelc, stephenXXX@mpeforth.com MicroProcessor Engineering Ltd - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web: http://www.mpeforth.com - free VFX Forth downloads
[toc] | [prev] | [next] | [standalone]
| From | Matthias Koch <matthias.koch@hot.uni-hannover.de> |
|---|---|
| Date | 2015-03-19 12:02 +0100 |
| Message-ID | <meeacb$rbc$1@newsserver.rrzn.uni-hannover.de> |
| In reply to | #20459 |
Hi Tim, I am the author of Mecrisp-Stellaris, a Forth implementation that compiles to native code on the target and needs 16 kb Flash and about 1.5 kb RAM on an ARM Cortex M0/M3/M4 for its core when used standalone. RAM is necessary mostly for input buffers and its two stacks. As you called for Open Source, I think you are fine with GPL3 licencing ? If you are, then I am there for your help. Until now, Mecrisp-Stellaris is designed to be monolithic, but you can change initialisation code, memory map and interrupt handling for your needs. Something you still need to think of is wiring the parts of your code which should be user available into the dictionary and do parameters-on-stack interfaces for them. If you like to try, Mecrisp-Stellaris already runs on chips from TI, STM, Freescale and NXP. An emulator for a Freescale M0 target running on Linux is included. Best wishes from Germany, Matthias Koch mecrisp.sourceforge.net
[toc] | [prev] | [standalone]
Page 4 of 4 — ← Prev page 1 2 3 [4]
Back to top | Article view | comp.arch.embedded
csiph-web