WizFi250 PicoC interactive mode

아래 링크되어 있는 NPE사의 WiFi-IT이라는 제품은 모듈 내부에 <WiFi-Basic>이라는 스크립트 엔진을 포함하여, Host Process 없이 독립적으로 운용 가능하게 만든 제품이다.
http://www.npe-inc.com/products/products-wifi-it-wl11.html

기본적으로 Basic 언어로 구성되어 있고, WiFi 단과 Network 함수들을 지원하고 있어서, 아래 샘플처럼 비교적 간단하게 데모를 구현할 수 있게 되어 있다.
http://www.npe-inc.com/products/documentation/Temperature%20Code%20Example.pdf

작년에 WizFi250에 PicoC를 포팅하고 테스트 했었던 적이 있었는데, 간단하게 요약해 보겠다. 먼저, 임베디드에서 사용 가능한 스크립트 엔진을 살펴보자.

PicoC (we use it and already have a small API and some scripts)
+ quite small (~50K) => could fit in nightly builds without much trouble
+ easily hackable (the code is easy to understand and modify)
+ it's pretty much plain C with relaxed rules (e.g. you can hack pointers, examine Canon code)
- slow (around 1000-5000x slower than gcc). Not a problem for simple bracketing scripts, but don't even think about image processing at pixel level
- not very well tested. I've ran around 100 problems from Google Code Jam and a bunch of random tests with CSmith, found and fixed a few bugs, and now it's pretty much OK.
- C might be a bit harder for novice programmers
- development is pretty much stalled, the author just merges patches from contributors

TCC (almost ported)
+ this is a real ANSI C compiler (C90, many C99 extensions, can compile Linux kernel)
+ very small for what it does (~200K, only required at compile time, can be unloaded after that)
+ built-in ELF loader (we use it for modules)
+ fast (you can do image processing, at least in playback mode). On desktop it's pretty much as fast as gcc -O0. Image processing test (720x480) was almost instant, on PicoC took 1 minute.
+ compilation is instant
+ calling existing C code just works (no extra wrapper functions needed)
+ active development, active mailing list
- needs a bit of work to get it running with all our memory constraints
- existing PicoC scripts will have to be rewritten (TCC is more strict, it requires a main function)
- still has some compiler bugs (passed most tests that I've ran on PicoC/gcc, but not all)
- source code is a bit difficult to understand (see also http://bellard.org/otcc/ )

TinyPy (I've ported it these days, more like a test for the new module system; can be loaded as a module and can print Hello World)
+ fairly small (~150K)
+ in-camera compiler and interpreter
+ pretty much as fast as regular Python (it uses a virtual machine inspired from Lua, but not as efficient)
+ the parser/compiler is implemented in Python and runs in the camera as bytecode (so, fairly good test coverage just from this)
+ clean syntax
- memory hungry (the current hello world example from the repo needs 16K of stack and ~1MB heap, with very aggressive GC)
- with default GC settings, with 2 simple loops, e.g. while(1) for (1 to 1000), it fills gigabytes of RAM (!)
- very few built-in tests (I expect many quirks in slightly more complex programs)
- no function prototypes: you can write sin(1,2,3,4,5) without any warning
- batteries not included: not even a basic printf...
- code base was not touched since 2009 (!)

PyMite
+ quite small (~50K)
- you have to compile the scripts on the PC (it reuses the full-blown Python compiler)
=> why not just use gcc?

Lua (I've tried it in early 2011, on 550D, when memory limits were not known; Sztupy also tried it on 60D in early 2012 - and it's still in ML tree as a plugin, but nobody maintained it)
+ fairly small (~150K)
+ fast (only ~20x slower than gcc)
+ mature language, widely used
+ nice docs, e.g. http://www.lua.org/doc/jucs05.pdf
+ used by CHDK
- memory usage was a bit too high for some cameras; now with the module system, this is no longer an issue
- minor syntax quirks, e.g. print(string.format("%d", 5)), or x ~= y, or... all variables are global by default

eLua (didn't try this one)
+ the Lua advantages
+ some nice modules, e.g. PWM, UART, interactive console, see http://www.eluaproject.net/doc/v0.8/en_status.html
+ optimizations for low-memory environments: Lua Tiny RAM , Emergency GC
- I'm just not familiar with it, so can't say too much here.

tiny-js
+ small (2000 lines, no idea about binary size)
+ web developers may find it easy
- who else uses javascript?
- it executes directly from source, like PicoC, so I expect it to be just as slow
- it's written in C++, so the integration effort may be higher (no idea about RAM usage)

ubasic
+ tiny
+ used by CHDK
- even slower than PicoC

<출처>
http://www.magiclantern.fm/forum/index.php?topic=5014.0

이 외에도 몇 가지 후보들을 선택하여 검토를 해보았는데, 개발자들에게 가장 보편적인 C 언어 스타일을 사용하고 있고, 상대적으로 이식성이 무난해보이는 PicoC를 선택하여, WizFi250에 포팅하고 몇 가지를 테스트 해 보았다.

https://code.google.com/p/picoc/

요약.......

1. 제일 중요한 Stack에 사용되는 Heap Size로 12KB를 할당하였다.

2. 이번에 구현한 C 함수들의 Header 파일은 아래와 같다.

IncludeRegister(pc, "stdio.h", StdioSetupFunc, StdioFunctions[0], StdioDefs);
IncludeRegister(pc, "stdlib.h", StdlibSetupFunc, StdlibFunctions[0], NULL);
IncludeRegister(pc, "string.h", StringSetupFunc, StringFunctions[0], NULL);
IncludeRegister(pc, "time.h", StdTimeSetupFunc, StdTimeFunctions[0], StdTimeDefs);
IncludeRegister(pc, "stdbool.h", StdboolSetupFunc, NULL, StdboolDefs);

WizFi250의 WiFi 기능을 사용 하기 위해서, 확장 Library 형태인 가칭 <WizFi250-WiFi.h>와 <WizFi250-Socket.h>를 구현하고 싶었지만, 뭐 그렇게까지 할 필요가 있을까 싶은 생각에 스크립트 기본 동작 확인에 만족했다.

3. 이번 테스트에는 Code Size 기준으로 약 50KB 정도가 필요했지만, Network 등의 확장 Library를 고려하면 최소한 70KB ~ 80KB 정도의 공간에서 작업을 해야 할 듯 하다.

4. 기본적인 C 문법 처리, STDIO, 문자열 처리, 포인터 연산 등 기본적인 동작 확인을 하였지만, 효율적인 메모리 관리를 위해서는 최적화 작업이 필요할 듯 싶다.

5. 단순히 스크립트의  동작 테스트를 확인하고 싶었던 것이니, Interactive mode만 구현하였는데, 최종적으로는 

- 스크립트 파일을 플래쉬에 저장/삭제 하는 기능

- Power On시에 지정한 스크립트 파일을 실행시키는 기능

- Memory Usage 관리

등이 필요할 것이다.