From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id 6878A7EEF8 for ; Thu, 16 Jul 2015 20:46:12 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of xavier.deschuyteneer@gmail.com) identity=pra; client-ip=209.85.217.170; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="xavier.deschuyteneer@gmail.com"; x-sender="xavier.deschuyteneer@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of xavier.deschuyteneer@gmail.com designates 209.85.217.170 as permitted sender) identity=mailfrom; client-ip=209.85.217.170; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="xavier.deschuyteneer@gmail.com"; x-sender="xavier.deschuyteneer@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-lb0-f170.google.com) identity=helo; client-ip=209.85.217.170; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="xavier.deschuyteneer@gmail.com"; x-sender="postmaster@mail-lb0-f170.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AzAwA++6dVm6rZVdFag2dpBoMeqHSPBYIogkODNAKBTAdMAQEBAQEBEgEBAQEBBgsLCSEuhCMBAQEDARIRHQEbEgsBAwELBgMCCw0NHQICIQEBEQEFAQoSBgoJEgkHh3YBAwoIDZ1Bjz+BLD4xiz+BbIJ5iykKGScDChVChFYBAQEBAQUBAQEBAQEBFQEFDos+gjsSgWAKBEcEB4JogUMFhWAMi2aCdIRuhUSBZoFDRo9Pg0aCFxIjgRURBoIcHIFVPDEBgQOBRwEBAQ X-IPAS-Result: A0AzAwA++6dVm6rZVdFag2dpBoMeqHSPBYIogkODNAKBTAdMAQEBAQEBEgEBAQEBBgsLCSEuhCMBAQEDARIRHQEbEgsBAwELBgMCCw0NHQICIQEBEQEFAQoSBgoJEgkHh3YBAwoIDZ1Bjz+BLD4xiz+BbIJ5iykKGScDChVChFYBAQEBAQUBAQEBAQEBFQEFDos+gjsSgWAKBEcEB4JogUMFhWAMi2aCdIRuhUSBZoFDRo9Pg0aCFxIjgRURBoIcHIFVPDEBgQOBRwEBAQ X-IronPort-AV: E=Sophos;i="5.15,489,1432591200"; d="scan'208";a="140269058" Received: from mail-lb0-f170.google.com ([209.85.217.170]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 16 Jul 2015 20:46:10 +0200 Received: by lblf12 with SMTP id f12so48988639lbl.2 for ; Thu, 16 Jul 2015 11:46:10 -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=XH47C+Bc3sUR80a0PIaLPp1jW49gky/w63eTU6GAjGA=; b=yhnRfhskCE0ictcuWJXxlzYtLo3H6OwBOnVxxn92+sE5ri86IPRy69jAwJXJjOe8dx uIzE5kjslm7thJHaeOsWXUaw/MUpx8qKHZwTwOfZmhbH6N+k8lLzPerMjidiNVj+6du3 hfbDjWEk537aFA+/kj++REu4447Ddpv/fZZzrHh7nCqXYa91wIywGccA50QT1tyd3UJa DmVZzaNdwlZ71fOUVlc0+L5nFSbo2kRD7ElkJpviyU8K4gcBOh9RimeBYFTr2LXGtZQ5 7jMF+spl+P6dfK5LUcUo/x0l9KB4CHRWySJV8ZlU1HRzWK+pkB4nJ0OCemtft7QUVKPb 82fA== X-Received: by 10.112.167.202 with SMTP id zq10mr10435941lbb.118.1437072370131; Thu, 16 Jul 2015 11:46:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.205.209 with HTTP; Thu, 16 Jul 2015 11:45:50 -0700 (PDT) In-Reply-To: <20150716100607.GB32592@frosties> References: <1e86d3d4e5a1e3ba3051d8c928b0dbd2@in.tum.de> <20150716100607.GB32592@frosties> From: xavier deschuyteneer Date: Thu, 16 Jul 2015 20:45:50 +0200 Message-ID: To: Goswin von Brederlow Cc: caml-list Content-Type: multipart/alternative; boundary=001a11c269c2236879051b027c43 Subject: Re: [Caml-list] OCaml embedded --001a11c269c2236879051b027c43 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Xavier Deschuyteneer 2015-07-16 12:06 GMT+02:00 Goswin von Brederlow : > On Fri, Jun 26, 2015 at 11:57:07AM +0200, xavier deschuyteneer wrote: > > 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, l= ow > > cpu, not so much ram, neither flash. > > If you are running Linux you aren't really embedded anymore or the > overhead of the kernel would already kill you. If you aren't running > on a Raspberry Pi equivalent or better than maybe you want to drop > linux too and go real embedded. > Not really... It's embedded because very limited resources. Thinking that a Raspberry pi is an embedded platform is like thinking that an A330 is a delta plane. Yes it flies, yes it's not as big as a A380, but it's not a delta plane. With multi-core ARM, a lot of RAM and flash, I don't really see any limitations. But it's another discussion and in the end it's not the purpose of my question. Regarding my specific case, we have an old ARM cpu (high grade industry certifications), less than 20Mo of flash, etc. I know it's not an ATTiny, but what we are doing is impossible with a microchip and this specifications are perfectly fitting our needs, even if it's not a raspberry pi. > > > And btw i know exactly how yocto works because i build myself our OS. A= nd > > 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 setu= p, > > 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 n= ot > > 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 ju= st > > > install the ocaml toolchain on your system and develop there on your > target > > > 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 > > I've used ocaml on a Raspberry Pi natively to compile ocaml code for > ARM. I also used qemu-arm (not qemu-system-arm) on an Atom330 (also > slow) to run an ARM chroot without much delay. Using the user level > emulation is much faster than emulating a full system. And you can > match and mix. E.g. use a native gcc cross-compiler for arm with an > ARM ocaml binary so only ocaml is slow. You can also use distcc on an > ARM board to offload C compile jobs to a cross compiler on a faster > server. > > And then there is the Raspberry Pi 2 or any other ARMv7 multi-core > boards. It's easy and cheap to scale up processing power to > comfortable levels. > > MfG > Goswin > > Some people already proposed this solution, on a POC/prototyping scale, why not. On an industry level in production, it's not even thinkable (at least in my field). And in any case, OCaml needs to integrate in our existing workflow which is: Yocto based OS building using custom Linux kernel with custom drivers + some "in house" softwares. This produce in the end: Filesystems to directly burn on flash. Cross-compilation toolchain with associated sysroot. This is (from my point of view) just taking a little bit more time to setup, but in the end, it's really nice on a daily basis to add new feature, develop, debug, release, build, etc. Thanks for your answer. > -- > 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 > --001a11c269c2236879051b027c43 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


Xavier Deschuyteneer

2015-07-16 12:06 GMT+02:00 Goswin von Breder= low <goswin-v-b@web.de>:
<= span class=3D"">On Fri, Jun 26, 2015 at 11:57:07AM +0200, xavier deschuyten= eer wrote:
> 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 syst= em, low
> cpu, not so much ram, neither flash.

If you are running Linux you aren't really embedded anymore or t= he
overhead of the kernel would already kill you. If you aren't running
on a Raspberry Pi equivalent or better than maybe you want to drop
linux too and go real embedded.

Not rea= lly...
It's embedded because very limited resources.

Thinking that a Raspberry pi is an embedded platform is li= ke thinking that an A330 is a delta plane.
Yes it flies, yes it&#= 39;s not as big as a A380, but it's not a delta plane.
With m= ulti-core ARM, a lot of RAM and flash, I don't really see any limitatio= ns.

But it's another discussion and in the end= it's not the purpose of my question.

Regardin= g my specific case, we have an old ARM cpu (high grade industry certificati= ons), less than 20Mo of flash, etc.
I know it's not an ATTiny= , but what we are doing is impossible with a microchip and this specificati= ons are perfectly fitting our needs, even if it's not a raspberry pi.
=C2=A0

> 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 emulati= on
> 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 set= up,
> 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 re= lated.
>
> 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 c= hange
> that.

> 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 y= our target
> > system.
> >
> > Seconded.=C2=A0 We did almost that for one of our projects and it= works
> > pretty well.=C2=A0 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 RA= M,
> > see http://xiphos.com/products/q7-processor= / ).
> >
> > We use Yocto to generate two versions of a Linux system: the targ= et
> > system, and a much larger version that contains developer tools (= C
> > compiler, m4, etc.)=C2=A0 The development system runs from microS= D 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 de= pendencies of
> > the target system have to be manually configured in the Yocto rec= ipes.
> >
> > 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 (conne= cted
> > to actual hardware:
> > http://www.ghgsat.com/wp-content/uploads/2015/03/Payload-Selfie.jpg )<= br> > > 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 ti= me
> > isn't as important when it's a nightly automated build. > >
> > Initially we looked into using a cross-compiler but we decided th= at
> > being able to use Opam largely outweighs any possible benefit we = could
> > get from cross-compiling.=C2=A0 And cross-compiling is often a so= urce of
> > headaches, even when compiling plain old C.=C2=A0 We would have t= o write a
> > 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
> > there is much incentive in using a cross-compiler.=C2=A0 BTW, is = there a
> > maintained ARM cross-compiler?
> > --
> > Berke Durak

I've used ocaml on a Raspberry Pi natively to compile ocaml code= for
ARM. I also used qemu-arm (not qemu-system-arm) on an Atom330 (also
slow) to run an ARM chroot without much delay. Using the user level
emulation is much faster than emulating a full system. And you can
match and mix. E.g. use a native gcc cross-compiler for arm with an
ARM ocaml binary so only ocaml is slow. You can also use distcc on an
ARM board to offload C compile jobs to a cross compiler on a faster
server.

And then there is the Raspberry Pi 2 or any other ARMv7 multi-core
boards. It's easy and cheap to scale up processing power to
comfortable levels.

MfG
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Goswin


Some people al= ready proposed this solution, on a POC/prototyping scale, why not. On an in= dustry level in production, it's not even thinkable (at least in my fie= ld).

And in any case, OCaml needs to integrate in = our existing workflow which is:
Yocto based OS building using cus= tom Linux kernel with custom drivers + some "in house" softwares.=
This produce in the end:
Filesystems to directly burn = on flash.
Cross-compilation toolchain with associated sysroot.

This is (from my point of view) just taking a little= bit more time to setup, but in the end, it's really nice on a daily ba= sis to add new feature, develop, debug, release, build, etc.

=
Thanks for your answer.
=C2=A0
--
Caml-list mailing list.=C2=A0 Subscription management and archives:
https://sympa.inria.fr/sympa/arc/caml-list
Beginner's list: http://gro= ups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs

--001a11c269c2236879051b027c43--