Welcome Guest Search | Active Topics | Log In | Register

Post a reply

Maximum number of characters in each post is: 32767
Bold Italic Underline   Highlight Quote Code Insert Image Create Link   Left Justify Center Justify Right Justify   More BBCode Tags
Font Color: Font Size:
Security Image:
Enter Letters From Security Image:
  Preview Post Cancel

Last 10 Posts (In reverse order)
absence Posted: Thursday, January 19, 2017 10:20:23 PM(UTC)
Well, if memory is not a problem then you're good to go, as long as you don't dare multithreaded scripting.
Caveats left are the usual stuff (vsnprintf / vargs for example) you should be able to cope with as embedded dev.

About everything else, hard to tell anything without knowing anything. In general it's a good idea to have MBs around, not KBs :) But well, that depends on the intended app

jthompson Posted: Thursday, January 19, 2017 8:42:53 PM(UTC)
Let's assume memory is not a problem. I'm specifying the board design and I'll make sure we have enough for at least 2 version of everything, plus a couple of wireless devices, FOTA downloader, bootloader, etc. I'll kick off the application from a shell on startup and respawn it if it dies.
absence Posted: Thursday, January 19, 2017 7:59:44 PM(UTC)
Assuming you're talking about Squirrel :D

Your enemy is footprint and mainly RAM size.

Do not use SQ64, stick to 32bit. (SQinteger MUST be the size of a pointer, ALWAYS!)
Disable garbage collector and compiler, use Squirrel core only.
Do not use sqstdlibs if possible.

Omitting the compiler, use /load precompiled bytecode only, and disable debug info when compiling.
When loading a script, execute the script so classes, functions and objects are created in that table and then FREE the memory of the very script you just loaded. You won't need it unless you want to execute the whole script itself (Everything it created WILL be still there!). When done, execute a hook function in your script (for example, a function onload()) to get things running. Hence your Scripts should not directly start actually doing things, your scripts should be designed to simply create functions and objects, but immeidately end and have for example a function "onload" or "main" which you call from your host application after you freed the script memory.

Explanation: If you run a script like this:

function foo()
bar() ;

that script will create an OBJECT named "foo" in the current table, which is the function itself. That object gets called when you call foo(), not the script itself.
Basically, when Squirrel executes code that contains for example "function" or "class" keywords, it creates the corresponding object. You call the created object, but NEVER the code of the "source" object (script). Reason:

function foo(var) { print(var) ; }

is EXACTLY the same as:<-function (var) { print(var) ; } ;

and... you usually won't need the latter again, because you would usually simply call foo().

Last advice:
Write your own memory management (squirrel does allocs and especially a lot of reallocs often) and make it fit your application. Analyse what block sizes are used the most in your case. Also try to take into account squirrel has some block sizes occuring quite often, and most important that reallocs almost always simply DOUBLE existing blocks, hence exponential growth based on squares is quite an issue for optimization, if I remember right.

Also please note that bytecode usually is significantly larger than source text. With like... 64kb free RAM for Squirrel you won't get very far.

Last point, RTOS: Squirrel is NOT multithreading compatible, not even with RTOS. Have it run in a single thread by all means.
jthompson Posted: Thursday, January 19, 2017 3:40:38 PM(UTC)
I'm planning to port an existing application to an STM32 micro (yet to be determined) running FreeRTOS. Any caveats or advice?

Clean Slate theme by Jaben Cargman (Tiny Gecko)
Powered by YAF 1.9.4 | YAF © 2003-2010, Yet Another Forum.NET
This page was generated in 0.062 seconds.