From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id 47FC57EF28 for ; Fri, 26 Jun 2015 15:39:42 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of ontologiae@gmail.com) identity=pra; client-ip=74.125.82.42; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="ontologiae@gmail.com"; x-sender="ontologiae@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of ontologiae@gmail.com designates 74.125.82.42 as permitted sender) identity=mailfrom; client-ip=74.125.82.42; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="ontologiae@gmail.com"; x-sender="ontologiae@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-wg0-f42.google.com) identity=helo; client-ip=74.125.82.42; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="ontologiae@gmail.com"; x-sender="postmaster@mail-wg0-f42.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0B9AwDRVI1VlCpSfUpBGoNlXwaDGKddAQaDHYQjgjKIBYIZgkSDNAKBMgdMAQEBAQEBEgEBAQEHCwsJHzCEIgEBAQMBEhEdARsSCwEDAQsGAwILDQ0dAgIhAQERAQUBChIGCgkSEId3AQMKCA06mweQaz4xiz+Ba4J5ix0KGScDCleFHAEBAQEBAQEDAQEBAQEBAQEUAQUOhg6FLoI7EoFqSwQHgmiBQwWFWgqBH40BhFiFGYFhgTpCjyODHCGCERIjgQ0JEQaCGAMcgVQ8MQGCRwEBAQ X-IPAS-Result: A0B9AwDRVI1VlCpSfUpBGoNlXwaDGKddAQaDHYQjgjKIBYIZgkSDNAKBMgdMAQEBAQEBEgEBAQEHCwsJHzCEIgEBAQMBEhEdARsSCwEDAQsGAwILDQ0dAgIhAQERAQUBChIGCgkSEId3AQMKCA06mweQaz4xiz+Ba4J5ix0KGScDCleFHAEBAQEBAQEDAQEBAQEBAQEUAQUOhg6FLoI7EoFqSwQHgmiBQwWFWgqBH40BhFiFGYFhgTpCjyODHCGCERIjgQ0JEQaCGAMcgVQ8MQGCRwEBAQ X-IronPort-AV: E=Sophos;i="5.13,685,1427752800"; d="scan'208";a="167467436" Received: from mail-wg0-f42.google.com ([74.125.82.42]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 26 Jun 2015 15:39:41 +0200 Received: by wgck11 with SMTP id k11so89051032wgc.0 for ; Fri, 26 Jun 2015 06:39:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Kty/NMeJ3Wxbk1HZoHmqb9ObLrS8VvIBgrV8f3SZo1U=; b=uhf92h9bbPyqSH1obuZp8uFklc11tUGlVDBzunWWv/bzIXza9js+E5VkFmbaHrbCsK zhX+aLC0fsa7pZJuVwabM10kGHHG1n9xJKCEfB+eBatEdHChthaGKY8XBicjS7EmGb2R i9QSb1sg7uy+YpflqRVav148KHRt2vyMJsextPfrSMS3XNuURv+SJPbSWQogxX4TT/71 eaHMeT8gfBMq6ZhK3vLN8wV1YiZZIt8Fh6RXk6CUIzYEfzYkAlrySyuzlMURc2JCb7fL nQ1X3GC6nHS6ziyehFs/xSGFIWMAUy7WMfiA77l7CoWrIM/9dnB0dqAFdymU4XLqeiq3 QcwQ== X-Received: by 10.180.81.106 with SMTP id z10mr4869424wix.22.1435325981072; Fri, 26 Jun 2015 06:39:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.179.153 with HTTP; Fri, 26 Jun 2015 06:39:21 -0700 (PDT) In-Reply-To: References: <1e86d3d4e5a1e3ba3051d8c928b0dbd2@in.tum.de> From: Pierre-Alexandre Voye Date: Fri, 26 Jun 2015 15:39:21 +0200 Message-ID: To: xavier deschuyteneer Cc: Berke Durak , =?UTF-8?Q?Markus_Wei=C3=9Fmann?= , caml-list Content-Type: multipart/alternative; boundary=f46d041828463d289f05196bdf0c Subject: Re: [Caml-list] OCaml embedded --f46d041828463d289f05196bdf0c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable So, maybe you could have a look on two differents projects : - Ocapic http://www.algo-prog.info/ocapic/web/index.php?id=3DOCAPIC (1) - Ocamlcc https://github.com/ocaml-bytes/ocamlcc (2) Ocapic (1) provide a caml virtual machine for a PIC, and tools to minimise code size. Ocamlcc (2) is a tool to generate plain C code from ocaml bytecode. There's risks that the code could be two large, but it can work. Of course, these way are slower because of bytecode. 2015-06-26 11:57 GMT+02:00 xavier deschuyteneer < xavier.deschuyteneer@gmail.com>: > When i say embedded system, i really mean embedded system running on a > minimal Linux with low power CPU, not so much flash, same for the RAM. > It's similar to think that a raspberry pi is a IOT. It's not, it's mini > computer on ARM platform. In my case, it's really an embedded system, low > cpu, not so much ram, neither flash. > > And btw i know exactly how yocto works because i build myself our OS. And > that's not exactly python, it's a mix between python and bash. > We build two different distributions: one ARM and one x86 (for emulation > purpose, valgrind, etc.). and all tools(chains) associated. > This ocaml software needs to be integrated in this workflow. > > Right now, we use plain C, and yes cross compilation is a specific setup, > but it's not difficult to achieve. > The advantage right now to use cross compilation are: > We can use all the power of a real computer to build/debug/code. > I can use all the interfaces that my computer have and not my end > (embedded) system: multiple ethernet cards, bluetooth, usb, etc. > I have multiple projects to manage and all of them are not embedded > related. > > Thanks for your answer and the time spent for my question :-) > > TL;DR: i need to cross compile ocaml code to arm because my device is not > powerful enough and that's not possible in industrial purpose to change > that. > > > Xavier Deschuyteneer > > 2015-06-26 5:04 GMT+02:00 Berke Durak : > >> On Tue, Jun 23, 2015 at 6:32 AM, Markus Wei=C3=9Fmann >> wrote: >> > >> > I can offer experience in the following cases: >> > 1) If your system is powerful enough (e.g. rasperry pi), you can just >> install the ocaml toolchain on your system and develop there on your tar= get >> system. >> >> Seconded. We did almost that for one of our projects and it works >> pretty well. The difference is that we didn't use QEmu, but two of >> our custom Q7 board (based on a Zynq ARM Cortex A9 with 512 MB RAM, >> see http://xiphos.com/products/q7-processor/ ). >> >> We use Yocto to generate two versions of a Linux system: the target >> system, and a much larger version that contains developer tools (C >> compiler, m4, etc.) The development system runs from microSD cards, >> and takes the better part of a gigabyte, while the target system has >> to run from < 64 megs of flash. The required run-time dependencies of >> the target system have to be manually configured in the Yocto recipes. >> >> We then manually install opam on the developer board, and use it to >> compile our OCaml code. The generated native ARM executables are then >> packaged into .ipks and transferred to the target Q7 board (connected >> to actual hardware: >> http://www.ghgsat.com/wp-content/uploads/2015/03/Payload-Selfie.jpg ) >> The packaging is done using a simple shell script that invokes ar and >> tar. >> >> We did try using QEmu but it's significantly slower, however it may >> come into play as automating the build process (using a virtual >> machine or dedicated hardware) is on our to do list, and build time >> isn't as important when it's a nightly automated build. >> >> Initially we looked into using a cross-compiler but we decided that >> being able to use Opam largely outweighs any possible benefit we could >> get from cross-compiling. And cross-compiling is often a source of >> headaches, even when compiling plain old C. We would have to write a >> lot of Yocto recipes to get it running. Note that Yocto is written in >> a progarmming language called Python and requires recipes to be >> expressed mostly the same language. >> >> To conclude, as powerful ARM systems are very cheap and plentiful >> these days, and since the convenience of Opam is immense, I'm not sure >> there is much incentive in using a cross-compiler. BTW, is there a >> maintained ARM cross-compiler? >> -- >> Berke Durak >> >> -- >> Caml-list mailing list. Subscription management and archives: >> https://sympa.inria.fr/sympa/arc/caml-list >> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners >> Bug reports: http://caml.inria.fr/bin/caml-bugs >> > > --=20 --------------------- https://twitter.com/#!/ontologiae/ http://linuxfr.org/users/montaigne --f46d041828463d289f05196bdf0c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
So, maybe you could have a look o= n two differents projects :

- Ocapic http://www.algo-prog.info/oca= pic/web/index.php?id=3DOCAPIC (1)
- Ocamlcc https://github.com/ocaml-bytes/ocamlcc= (2)

Ocapic (1) provide a caml virtual machine for a PIC, and = tools to minimise code size.
Ocamlcc (2) is a tool to generate pla= in C code from ocaml bytecode. There's risks that the code could be two= large, but it can work.

Of course, these way are slower becau= se of bytecode.

2015-06-26 11:57 GMT+02:00 xavier deschuyteneer &= lt;xavi= er.deschuyteneer@gmail.com>:
When i say embedded system, i really mean embedded syste= m running on a minimal Linux with low power CPU, not so much flash, same fo= r the RAM.
It's similar to think that a raspberry pi is a IOT. It&#= 39;s not, it's mini computer on ARM platform. In my case, it's real= ly an embedded system, low cpu, not so much ram, neither flash.
<= br>
And btw i know exactly how yocto works because i build myself= our OS. And that's not exactly python, it's a mix between python a= nd bash.
We build two different distributions: one ARM and one x8= 6 (for emulation purpose, valgrind, etc.). and all tools(chains) associated= .
This ocaml software needs to be integrated in this workflow.

Right now, we use plain C, and yes cross compilation= is a specific setup, but it's not difficult to achieve.
The = advantage right now to use cross compilation are:
We can use all = the power of a real computer to build/debug/code.
I can use all t= he interfaces that my computer have and not my end (embedded) system: multi= ple ethernet cards, bluetooth, usb, etc.
I have multiple projects= to manage and all of them are not embedded related.

Thanks for your answer and the time spent for my question :-)
=
TL;DR: i need to cross compile ocaml code to arm because my = device is not powerful enough and that's not possible in industrial pur= pose to change that.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0
=
Xavier Deschuyteneer

2015-06-26 5:04 GMT+02:00 Berke Durak <= berke.durak@gmail.com>:
On Tue, Jun 23, 2015 at 6:32 AM, Markus Wei=C3=9Fmann
<markus.= weissmann@in.tum.de> wrote:
>
> I can offer experience in the following cases:
> 1) If your system is powerful enough (e.g. rasperry pi), you can just = install the ocaml toolchain on your system and develop there on your target= system.

Seconded.=C2=A0 We did almost that for one of our projects and it wo= rks
pretty well.=C2=A0 The difference is that we didn't use QEmu, but two o= f
our custom Q7 board (based on a Zynq ARM Cortex A9 with 512 MB RAM,
see http://xiphos.com/products/q7-processor/ ).

We use Yocto to generate two versions of a Linux system: the target
system, and a much larger version that contains developer tools (C
compiler, m4, etc.)=C2=A0 The development system runs from microSD cards, and takes the better part of a gigabyte, while the target system has
to run from < 64 megs of flash.=C2=A0 The required run-time dependencies= of
the target system have to be manually configured in the Yocto recipes.

We then manually install opam on the developer board, and use it to
compile our OCaml code. The generated native ARM executables are then
packaged into .ipks and transferred to the target Q7 board (connected
to actual hardware:
http://www.ghgsat.com/wp-content/= uploads/2015/03/Payload-Selfie.jpg )
The packaging is done using a simple shell script that invokes ar and
tar.

We did try using QEmu but it's significantly slower, however it may
come into play as automating the build process (using a virtual
machine or dedicated hardware) is on our to do list, and build time
isn't as important when it's a nightly automated build.

Initially we looked into using a cross-compiler but we decided that
being able to use Opam largely outweighs any possible benefit we could
get from cross-compiling.=C2=A0 And cross-compiling is often a source of
headaches, even when compiling plain old C.=C2=A0 We would have to write a<= br> lot of Yocto recipes to get it running.=C2=A0 Note that Yocto is written in=
a progarmming language called Python and requires recipes to be
expressed mostly the same language.

To conclude, as powerful ARM systems are very cheap and plentiful
these days, and since the convenience of Opam is immense, I'm not sure<= br> there is much incentive in using a cross-compiler.=C2=A0 BTW, is there a
maintained ARM cross-compiler?
--
Berke Durak

--
Caml-list mailing list.=C2=A0 Subscription management and archives:
https://sympa.inria.fr/sympa/arc/caml-list
Beginner's list: http://groups.yahoo.com/group/ocam= l_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs




--
---------------------
https://twitter.com/#!/ontologiae/
http://linuxfr.or= g/users/montaigne
--f46d041828463d289f05196bdf0c--