[gambit-list] quest for running gambit on POS embedded devices

Marc Feeley feeley at iro.umontreal.ca
Mon Mar 5 11:31:06 EST 2012


I can feel your pain and determination.  So here are some ideas which should help debug this.

1) Make sure you use --enable-ansi-c when configuring Gambit.  This will force the use of a small subset of the ANSI-C headers and libraries (such as stdio.h, stdlib.h, math.h).  This is the place to start for a small embedded device with minimal peripherals.  If you are compiling with your own makefile, this will happen automatically (unless you have a config.h or other header file which defines HAVE_WAITPID, which causes lib/os.h to assume you are on a POSIX system with all the POSIX goodies).

2) Make sure you use --enable-debug (or if you are compiling with your own makefile, use -D___DEBUG).  This will cause various traces, including any failed system call error messages and the location of the error in the C source code, to be output to a file.  Typically this file is called "console", but if you configure with --enable-ansi-c, the output will go to stderr.  The logic for this is at the end of the C function ___setup_base_module in the file lib/os_base.c .  The error messages are actually funelled through the C function ___printf in the same file.  In its current definition it sends the messages to ___base_mod.debug, which is the FILE* corresponding to the file "console" or stderr, but you could rewrite this function to use logg(...) which seems to be the way on your device to display something on the LCD.

3) You can also -D___DEBUG_ALLOC_MEM_TRACE if you want a trace of the memory related system calls.

4) You can also -D___DEBUG_HOST_CHANGES if you want a trace of each call between C "host" functions, which will correspond to each jump from one Scheme function to another Scheme function (if you did not use -D___SINGLE_HOST which is recommended for better debuggability).  Of course, this is only useful if you managed to actually get to the execution of Scheme code.  My guess is that you are not even there yet.

5) You should consider replacing in lib/os_time.h the line

#define ___FLOAT_TIME_REPRESENTATION

by

#define ___INT_TIME_REPRESENTATION

This will force the use of an integer representation for time.  I haven't tried this in a long time, so the functionality might have bit-rotted.

6) Don't despair!  Gambit has lots of bells and whistles when compiled on a desktop, but it has been designed to rely on a very small set of OS functionalities.  Even floating-point is used parsimoniously.

Marc

On 2012-03-05, at 5:49 AM, Attila Lendvai wrote:

> hi,
> 
> so, i've managed to fight myself through the forest of compiling
> gambit on the castles POS terminal, and using it as an embedded script
> language managed from a hand written C main function.
> 
> http://www.castech.com.tw/en/in-products-03.aspx?id=P_00000109&cid=C_00000018&pname=VEGA5000&cname=EFT-POS+Terminal
> 
> well, almost. the problem is that when i run it on the device, all i
> get is a random "code 11" error from inside ___setup. it's most
> probably a sigsegv obfuscated by the lost souls in Taiwan who think
> that "for the convenience of the programmer" giving years old cygwin
> exe's of GCC, and translating linux error to their own codes is a
> help... but that sigsegv is just a wild guess. see my main pasted at
> the end of the mail.
> 
> i was pondering what are the requirements for gambit to run in this
> setup? is it a problem e.g. that setup_params.gambcdir is not set, nor
> the files are available?
> 
> any other ideas?
> 
> my plan is to compile gambit with the terminal API libs, and add some
> printf debugging inside ___setup, but these tasks are hard enough to
> ask the more experienced beforehand.
> 
> and as a little feedback, here are a few thoughts on what would have helped me:
> - something as simple as a "git clone foo" for a simple usage as
> mine, and not being exposed to the complexity of all the bootstrapping
> related headaches (which are irrelevant for my use-case). this here is
> way too much details for a simple use-case as mine:
> http://dynamo.iro.umontreal.ca/~gambit/wiki/index.php/Contributing_Patches_to_Gambit_Source_Code
> 
> - an example that compiles on linux, is less complicated than the
> examples/iOS, and demonstrates how to use gambit from C. especially
> the magic -D___LIBRARY trick.
> 
> - more descriptive names. these names very much don't help
> understanding what's going on, let alone the single namespace C has:
> ___setup, ___names_prefixed_with_large_number_of_underscores instead
> of "gmb_" or something, -D___LIBRARY to stop generating a C main
> function.
> 
> meanwhile i've given up on chibi scheme, purely as a subjective
> decision, and slightly influenced by its painfully slow speed of
> loading the libs (which i didn't investigate and may be due to the
> platform). i'm fighting on 3 fronts (lua, chibi, gambit), so it's not
> an absolute judgement on chibi, just my subjective least resistance.
> 
> given the difficulty in approaching gambit, i would also have given up
> on gambit if i didn't met Marc on a conference and didn't have such a
> good impression... :) gambit also seems to be too big for the other
> smaller POS (http://www.justtide.com/products_detail/&productId=897969ac-a238-4fc8-b2b6-163e506edf8c.html),
> the exe is 3.5M, 800k zipped.
> 
> compiling and running lua was by far the simplest task with the least
> number of headaches, even though it's the first time i approached lua.
> if the language wasn't that weird, lacking data types of my taste,
> etc... then i'd have already settled down on lua already. but given
> the headaches i had with compiling scheme's, i'm kinda leaning towards
> swallowing the lesser language and just implement what actually pays
> for the bills, as opposed to the intellectual adventure... :)
> 
> -- 
>  attila
> 
> Notice the erosion of your (digital) freedom, and do something about it!
> 
> PGP: 2FA1 A9DC 9C1E BA25 A59C  963F 5D5F 45C7 DFCD 0A39
> OTR XMPP: 8647EEAC EA30FEEF E1B55146 573E52EE 21B1FF06
> 
> 
> int
> main(void)
> {
>    ___setup_params_struct setup_params;
>    ___setup_params_reset(&setup_params);
> 
>    CTOS_LCDTClearDisplay();
>    logg("Initializing...");
> 
>    getkey();
> 
>    setup_params.version = ___VERSION;
>    setup_params.display_error = gambit_error_trap;
>    setup_params.fatal_error   = gambit_error_trap;
>    setup_params.min_heap      = 3*1024*1024;
>    setup_params.max_heap      = 8*1024*1024;
> 
>    ___setup(&setup_params);
> 
>    logg("Eval'ing...");
> 
>    getkey();
> 
>    CTOS_LCDTPrintXY(1, 2, gambit_eval_string("(+ 2 3)"));
> 
>    logg("Done eval'ing...");
> 
>    getkey();
> 
>    logg("Cleaning up...");
> 
>    ___cleanup ();
> 
>    logg("Exiting...");
>    return 0;
> }
> _______________________________________________
> Gambit-list mailing list
> Gambit-list at iro.umontreal.ca
> https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list




More information about the Gambit-list mailing list