this is an announcement for "OCAPIC", a project which brings OCaml to programming PIC micro-controllers.
Some PIC18 series characteristics: - 8 bit architecture - low cost (a few US dollars), fairly spread in electronics world - very low volatile memory (a few bytes only, up to ~5000 bytes, depending on the model) - very low non-volatile memory (less than a KB up to 128 KB) - EEPROM : 0 to 1024 bytes
How to program those little chips with OCaml: - write an OCaml program, compile it, transfer it to the PIC.
Well, actually it demands a little more than just that: - write an OCaml program, like usually, while keeping in mind that the stack is more limited than usual, same for the heap - compile it (with ocamlc) - reduce the binary (with ocamlclean : a bytecode reducer which removes dead-code) - transform the (reduced or not) binary (with bc2asm : take back not useful zeros, thence reducing the binary size) - transfer it to the PIC along with its OCaml VM.
Indeed, an OCaml VM has been implemented in PIC18 ASM in order to run OCaml programs on a PIC ! :-)
An example of real program is in the distribution (open source, downloadable from the website): ocapic-1.3/src/tests/goblet/ (722 lines of ML code).
We also provide a simulator in order to run on a PC (needs X11 (Linux/MacOSX) and GCC) your programs written for PIC18.
The whole implementation has been fairly well tested, however the documentation is still quite young.
PIC ASM is the first "programming language" Benoît learnt, a few years ago. He has practiced it ever since. But meanwhile he learnt OCaml (among other languages). A few months ago, he suggested me to implement an OCaml virtual machine running on PICs, with maximum performance efficiency in mind. This is why OCAPIC's VM is implemented in ASM.
The purpose is of course to program PICs with a high level language while remaining (relatively) *very* efficient.
The "side effect" of our project — which can interest many OCaml users — is that OCAPIC provides "ocamlclean", which is a tool that takes an OCaml bytecode binary (produced by ocamlc) and reduces it by (statically) eliminating most of its deadcode (and of course dynlink is thence broken; note that dynlink is not relevant on PICs). This tool is independent from the rest of OCAPIC. Actually, this tool was mandatory for programs using OO-layer : without it, bytecode binaries embedding OO-layer were to big to fit on our PICs.
Cheers,
Philippe
On Nov 5, 2010, at 1:35 PM, Daniel Bünzli wrote:
> Interesting project. Was the choice of PIC based on technical reasons > or just familiarity of the authors with these chips ?
> I would have liked to give it a try but unfortunately I work AVRs and avr-gcc.
Philippe Wang <philippe.w...@lip6.fr> writes: > Dear all,
> this is an announcement for "OCAPIC", a project which brings OCaml to > programming PIC micro-controllers.
> Some PIC18 series characteristics: > - 8 bit architecture > - low cost (a few US dollars), fairly spread in electronics world > - very low volatile memory (a few bytes only, up to ~5000 bytes, depending on > the model) > - very low non-volatile memory (less than a KB up to 128 KB) > - EEPROM : 0 to 1024 bytes
Doesn't the overhead of boxed structures as well as loosing a bit on ints make that impractical given the extremly limited memory?
>> this is an announcement for "OCAPIC", a project which brings OCaml to >> programming PIC micro-controllers.
>> Some PIC18 series characteristics: >> - 8 bit architecture >> - low cost (a few US dollars), fairly spread in electronics world >> - very low volatile memory (a few bytes only, up to ~5000 bytes, depending on >> the model) >> - very low non-volatile memory (less than a KB up to 128 KB) >> - EEPROM : 0 to 1024 bytes
> Doesn't the overhead of boxed structures as well as loosing a bit on > ints make that impractical given the extremly limited memory?
> MfG > Goswin
Thanks for the question. Let me try to give an (indirect) answer.
OCAPIC has 16-1=15bit integers and 16bit blocks. And the overhead is quite acceptable to us.
A gobblet game [1] I.A. was implemented and tested. (The OCaml code is included in the distribution so anyone can check it out.) The first version of this game was very hard to beat (for a human). Then a strategy was found (to beat the I.A.). So some randomization was supplied to the I.A. to make it more interesting. Now the I.A. has become really very hard to beat. (We used a PIC18F4620: flash memory = 64kiB; volatile memory = 3968B ; EEPROM = 1KiB ; speed = 10 MIPS)
Between two moves, the I.A. may trigger the GC about ten times or more. However, the time between two moves is less than 2 seconds, and generally quite less than half a second (and in the beginning of the game it's hard to realize the time it takes).
Providing a GC to programming PIC microcontrollers is a tremendous gain comparing to manually manage everything (memory and computing). Providing a high-level language allows to implement algorithms that would be very hard or impossible to implement in ASM (or most low-level languages such as C or Basic).
We haven't yet experimented real-time constrained programming (e.g., ReactiveML might bring OCAPIC to a step further).
Now, maybe the direct answer to the question can be : programming PICs has been impractical to most people, now all readers of this list can potentially program them without much difficulties (and without paying a too high cost on performance efficiency).
Shortly: ocamlclean is now available in a separate package so that you don't have to get the whole ocapic distribution just to try ocamlclean.
More information: ocamlclean takes a bytecode executable (which are generally but not necessarily produced by "ocamlc" compiler) and reduces its size by eliminating some dead code. Dead code is discriminated statically. (It's impossible to eliminate all dead code, but in some cases it can reduce bytecode executables tremendously) It is meant to be compatible with standard bytecode such as produced by ocamlc. (DBUG section is currently not supported and is removed during the cleaning process. Other unsupported sections are left untouched.)
> Shortly: > ocamlclean is now available in a separate package so that you don't have to > get the whole ocapic distribution just to try ocamlclean.
> More information: > ocamlclean takes a bytecode executable (which are generally but not > necessarily produced by "ocamlc" compiler) and reduces its size by > eliminating some dead code. Dead code is discriminated statically. (It's > impossible to eliminate all dead code, but in some cases it can reduce > bytecode executables tremendously) It is meant to be compatible with > standard bytecode such as produced by ocamlc. (DBUG section is currently not > supported and is removed during the cleaning process. Other unsupported > sections are left untouched.)
Is ocamlclean compatible with dynamic loading? That is code potentially used by some unknown dynamically-loaded code must be kept.
ocamlclean removes code to which there is no possible path. For instance, this program : let plop = List.map succ [1;2;3];; uses module List (for map) and module Pervasives (for succ) but doesn't use a lot of functions of List or Pervasives (e.g., List.iter, List.fold_left, Pervasives.print_endline). So most functions of modules Pervasives and List are removed from the bytecode executable.
If one dynamically loads some bytecode, for instance the previous program becomes let plop = List.map succ [1;2;3];; let _ = Dynlink.load "stuff.cmo";; then stuff.cmo should not reference anything that may not exist, such as Pervasives.(@) since it has been removed by ocamlclean. And we are not supposed to know at compile-time what stuff.cmo needs from stdlib. Hence I guess everything should be kept and ocamlclean not used.
On the other hand, if we statically know what is in stuff.cmo, then why load it dynamically? (I guess the answer can be "just for fun" but I'm not so sure it's such a good answer :-)
Though, I'm not very familiar with Dynlink, and I'm not sure what "Dynlink.allow_only" really does...
I haven't tested using dynlink to load a self-sufficient module. I might work, but I don't really see how it can be usefull anyway...
Cheers, Philippe Wang
On Nov 11, 2010, at 06:52 AM, Julien Signoles wrote:
> Hello, > Is ocamlclean compatible with dynamic loading? That is code potentially used by some unknown dynamically-loaded code must be kept. > -- > Julien
