YetAnotherForum
Welcome Guest Search | Active Topics | Log In | Register

New Topic Post Reply
Porting an application to an ST micro running FreeRTOS
jthompson
#1 Posted : Thursday, January 19, 2017 3:40:38 PM(UTC)
Rank: Newbie

Groups: Registered
Joined: 1/18/2017(UTC)
Posts: 3
Location: Cary, NC

Thanks: 3 times
Was thanked: 0 time(s) in 0 post(s)
I'm planning to port an existing application to an STM32 micro (yet to be determined) running FreeRTOS. Any caveats or advice?
absence
#2 Posted : Thursday, January 19, 2017 7:59:44 PM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 8/23/2014(UTC)
Posts: 105
Man
Location: Northern Germany & Lincolnshire, U.K.

Thanks: 1 times
Was thanked: 9 time(s) in 9 post(s)
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:

this.foo<-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.
1 user thanked absence for this useful post.
jthompson on 1/19/2017(UTC)
jthompson
#3 Posted : Thursday, January 19, 2017 8:42:53 PM(UTC)
Rank: Newbie

Groups: Registered
Joined: 1/18/2017(UTC)
Posts: 3
Location: Cary, NC

Thanks: 3 times
Was thanked: 0 time(s) in 0 post(s)
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
#4 Posted : Thursday, January 19, 2017 10:20:23 PM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 8/23/2014(UTC)
Posts: 105
Man
Location: Northern Germany & Lincolnshire, U.K.

Thanks: 1 times
Was thanked: 9 time(s) in 9 post(s)
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

1 user thanked absence for this useful post.
jthompson on 1/20/2017(UTC)
Quick Reply Show Quick Reply
Users browsing this topic
Guest
New Topic Post Reply
Forum Jump  
You can post new topics in this forum.
You can reply to topics in this forum.
You can delete your posts in this forum.
You can edit your posts in this forum.
You cannot create polls in this forum.
You can vote in polls in this forum.

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.119 seconds.