Hi,
I am on the look for somebody that has some experience with adding scripting capability to an application on a Coldfire.I have made a piece of hardware and written the basic functions to handle the I/O, RS-232 and LAN.
Now I will like to be able to add the possibility that the user of the hardware can change the functionality by changing a script and then upload it to the Coldfire.
I have been looking at the Lua and Pawn, but find it very hard to get it integrated and running in my application (Could be my skills, but the result remain the same ;-)).
Have any of you tried this, or do you know of any other scripting language that I can use?
Regards
SteenSolved! Go to Solution.
Cremericon wrote:
Have been reading the "Implementer's Guide" and found that the need of memory looked to be big. In the M52236 I only have 4 Kb RAM available for the Pawn. Will that do?
If I remember correctly, RAM is needed mostly to store the script (plus its stack+heap.) Besides, the guide mentions that scripts could be executed out of ROM. Some functions in the implementation of Pawn do use rather big automatic variables, but they are nowhere near 4K bytes. So basically the 4K bytes of RAM mostly limits the size of scripts you can run. Depending on what you want to do, this could be enough. Just try compiling some scripts and see how much memory they need. Don't forget to trim down stack+heap size using compiler options.
Cremericon wrote:
Also I find hard to se were to begin adding the Pawn to my application and find it hard to see if there are any possibilities for success!I don't know what to say. I followed the implementer's guide. Besides, Pawn's source code is sufficiently easy to understand. And there is even an 'official' support forum, although it seems rather deserted. It's a shame, really, since Pawn is such a great tool.
I have successfully integrated Pawn into my design. It was ARM-based, but it doesn't make a big difference. Pawn ships with the virtual machine in ARM assembly among other versions, so I used that. But it worked fine with ANSI C version of VM too. It didn't take too much effort to do the porting. The overall impression of Pawn was very good.
Hi,
scifi wrote:But it worked fine with ANSI C version of VM too. It didn't take too much effort to do the porting.
Have been reading the "Implementer's Guide" and found that the need of memory looked to be big. In the M52236 I only have 4 Kb RAM available for the Pawn. Will that do?
Also I find hard to se were to begin adding the Pawn to my application and find it hard to see if there are any possibilities for success!
Cremericon wrote:
Have been reading the "Implementer's Guide" and found that the need of memory looked to be big. In the M52236 I only have 4 Kb RAM available for the Pawn. Will that do?
If I remember correctly, RAM is needed mostly to store the script (plus its stack+heap.) Besides, the guide mentions that scripts could be executed out of ROM. Some functions in the implementation of Pawn do use rather big automatic variables, but they are nowhere near 4K bytes. So basically the 4K bytes of RAM mostly limits the size of scripts you can run. Depending on what you want to do, this could be enough. Just try compiling some scripts and see how much memory they need. Don't forget to trim down stack+heap size using compiler options.
Cremericon wrote:
Also I find hard to se were to begin adding the Pawn to my application and find it hard to see if there are any possibilities for success!I don't know what to say. I followed the implementer's guide. Besides, Pawn's source code is sufficiently easy to understand. And there is even an 'official' support forum, although it seems rather deserted. It's a shame, really, since Pawn is such a great tool.
Okay perhaps I just was blinded by all the documentation and the fact that there was no sample for the CodeWarrior
Have just now got the first Pawn script running in my application and got the script to call a C function...
I think I will keep working this way.
scifi thanks for showing me the way;-)
Regards
Steen
You might want to take a look at StickOS at www.cpustick.com. It runs on an MCF52235 already, and might just run on a 36 (you can download it on the Downloads page) -- otherwise ports within the ColdFire family usually take a day or so. Right now, it "takes over" the MCU as the only application, but even as we speak I'm trying to turn it into a "library" so it can be linked into other applications to provide generic scripting (and the application trivially can add its own new script statements to the core BASIC engine).
-- Rich
Hi Rich
Been lokking at your homepage, and it looks like somthing that coudt solve my problem;-)
The only thing that it looks like I miss are "printf" look alike functions to the uarts?
Rich T wrote:but even as we speak I'm trying to turn it into a "library" so it can be linked into other applications to provide generic scripting (and the application trivially can add its own new script statements to the core BASIC engine).
mailto:rich@testardi.com" rel="nofollow" target="_blank
Sounds great any ides on when I can try this "library" (This sound like the )?
Regards
Steen
Hi Steen,
I'm working on the library right now (my schedule just cleared up! :smileyhappy:...
It will totally allow you to "print" to a uart, just like we allow you to "print" to the badge board's led matrix with it -- you'll be able to follow the badge board example (in parse2.c and run2.c) and do your own thing using the exact same mechanisms... I hope to have it on the website by the end of next week (6/19).
-- Rich
Hi Rich
Sounds great, looking forward to see the result and the possibility to integrated in to my existing application.
Rich T wrote:you'll be able to follow the badge board example (in parse2.c and run2.c) and do your own thing using the exact same mechanisms...
Have had a look at the parser2.c and run2.c in the skeleton.zip, but they are missing from the zip file?
Sorry, I was unclear and using future tense... :smileyhappy:
Once the new zip is out, with the library version of StickOS, you'll be able to do that.
-- Rich