From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 884C97EF28 for ; Fri, 26 Jun 2015 05:04:10 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of berke.durak@gmail.com) identity=pra; client-ip=209.85.223.178; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="berke.durak@gmail.com"; x-sender="berke.durak@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of berke.durak@gmail.com designates 209.85.223.178 as permitted sender) identity=mailfrom; client-ip=209.85.223.178; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="berke.durak@gmail.com"; x-sender="berke.durak@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-ie0-f178.google.com) identity=helo; client-ip=209.85.223.178; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="berke.durak@gmail.com"; x-sender="postmaster@mail-ie0-f178.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DwAQB2wIxVlLLfVdFbgzA1XwaDGKklhg+MMYV4AoE0B0wBAQEBAQESAQEBAQcLCwkfMIQjAQEEEhEdARsdAQMMBgULDQICJgICIgERAQUBHAYKCSKHdwEDEg2rYD4xiz+Ba4J5iyEKGScNV4UcAQEBAQYBAQEBGAEFDoETiimCO4IYMweCaIFDBZQGhFiGeoE6QpJhghESI4ENCReCGxyBbiIxAYJHAQEB X-IPAS-Result: A0DwAQB2wIxVlLLfVdFbgzA1XwaDGKklhg+MMYV4AoE0B0wBAQEBAQESAQEBAQcLCwkfMIQjAQEEEhEdARsdAQMMBgULDQICJgICIgERAQUBHAYKCSKHdwEDEg2rYD4xiz+Ba4J5iyEKGScNV4UcAQEBAQYBAQEBGAEFDoETiimCO4IYMweCaIFDBZQGhFiGeoE6QpJhghESI4ENCReCGxyBbiIxAYJHAQEB X-IronPort-AV: E=Sophos;i="5.13,682,1427752800"; d="scan'208";a="167357504" Received: from mail-ie0-f178.google.com ([209.85.223.178]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 26 Jun 2015 05:04:09 +0200 Received: by iebrt9 with SMTP id rt9so67421014ieb.2 for ; Thu, 25 Jun 2015 20:04:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=DWobE4c/Ri624DG3+M80YiZfi+yzyfxbSrbhdUwG1T8=; b=P2n0eIN0pOuHHL4AXw0arnmUL86fyE+FqCjcIi1KeT3n1aUWh1ig3Zh42RK6svtRdO vfP95T58AZzVGzLVjmKR2KL3KwlqdzKTy7jHX3bnr0cVm/AAVJxJnZC/WONyNpR8hLHE AiIXyksYgirz+nxvwIp8xpjUJCM4WQV+svEluQHKsXXgP17aLaw7nDsPkSjqZEQLU/Zg TilTG7DpfVPQEBjnr/q/hH1qKdVVM9V7KB1W2NBgjptg/1haS/HhG5pKALVC/4H6PgC0 RNIPRTKfNvnj9NGRVKUuKC27aju6YEVMcabYdPB9iZSE3vPQOLhqKD+EqHaOI0endRHe LIlw== MIME-Version: 1.0 X-Received: by 10.50.64.243 with SMTP id r19mr427666igs.5.1435287848234; Thu, 25 Jun 2015 20:04:08 -0700 (PDT) Received: by 10.36.64.132 with HTTP; Thu, 25 Jun 2015 20:04:08 -0700 (PDT) In-Reply-To: <1e86d3d4e5a1e3ba3051d8c928b0dbd2@in.tum.de> References: <1e86d3d4e5a1e3ba3051d8c928b0dbd2@in.tum.de> Date: Thu, 25 Jun 2015 23:04:08 -0400 Message-ID: From: Berke Durak To: =?UTF-8?Q?Markus_Wei=C3=9Fmann?= Cc: caml-list Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Caml-list] OCaml embedded 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 ins= tall the ocaml toolchain on your system and develop there on your target sy= stem. 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? --=20 Berke Durak