[Caml-list] OCaml embedded

[Caml-list] OCaml embedded

[xavier deschuyteneer]

[-- Attachment #1: Type: text/plain, Size: 306 bytes --]

I would like to develop in ocaml for ARM based embedded systems running
custom Linux (build with yocto).

My main questions are how to achieve this:
- cross compilation (ARM/x86)
- stack size control/analysis (valgrind massif tools for ocaml?)

Do you have some pointers? experience?

Xavier Deschuyteneer

[-- Attachment #2: Type: text/html, Size: 490 bytes --]

Re: [Caml-list] OCaml embedded

[Markus Weißmann]

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.
2) Another possibility would be to use qemu (scratchbox, deboostrap, 
..) to run a complete ARM-linux-root on your x64/x86 linux system via 
chroot.
I especially like the 2nd one, as you can use your powerful development 
CPU but your software and toolchain behave nearly perfectly like you are 
on your target system.

regards
-Markus

On 2015-06-23 12:07, xavier deschuyteneer wrote:
> I would like to develop in ocaml for ARM based embedded systems 
> running
> custom Linux (build with yocto).
>
> My main questions are how to achieve this:
> - cross compilation (ARM/x86)
> - stack size control/analysis (valgrind massif tools for ocaml?)
>
> Do you have some pointers? experience?
>
> Xavier Deschuyteneer

-- 
Markus Weißmann, M.Sc.
Technische Universität München
Institut für Informatik
Boltzmannstr. 3
D-85748 Garching
Germany
http://wwwknoll.in.tum.de/

Re: [Caml-list] OCaml embedded

[Berke Durak]

On Tue, Jun 23, 2015 at 6:32 AM, Markus Weißmann
<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.  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

Re: [Caml-list] OCaml embedded

[Kenneth Adam Miller]

[-- Attachment #1: Type: text/plain, Size: 3151 bytes --]

It's easy to compile images that can be run in qemu with buildroot. I don't
know much about yocto, but you can use the crosstool-ng toolkit to compile
a tool chain for cross compiling. You can have multiple tool chains, and
have unique images for each of your respective targets, possibly just
running your ocaml code locally and recompiling it for arm when you want to
put it on the device :)

On Thu, Jun 25, 2015 at 11:04 PM, Berke Durak <berke.durak@gmail.com> wrote:

> On Tue, Jun 23, 2015 at 6:32 AM, Markus Weißmann
> <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.  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
>

[-- Attachment #2: Type: text/html, Size: 4234 bytes --]

Re: [Caml-list] OCaml embedded

[Kenneth Adam Miller]

[-- Attachment #1: Type: text/plain, Size: 3431 bytes --]

Oh yeah, you need a OCaml tool chain targeted to arm... whoops. Sorry about
that, I missed that part.

On Fri, Jun 26, 2015 at 1:40 AM, Kenneth Adam Miller <
kennethadammiller@gmail.com> wrote:

> It's easy to compile images that can be run in qemu with buildroot. I
> don't know much about yocto, but you can use the crosstool-ng toolkit to
> compile a tool chain for cross compiling. You can have multiple tool
> chains, and have unique images for each of your respective targets,
> possibly just running your ocaml code locally and recompiling it for arm
> when you want to put it on the device :)
>
> On Thu, Jun 25, 2015 at 11:04 PM, Berke Durak <berke.durak@gmail.com>
> wrote:
>
>> On Tue, Jun 23, 2015 at 6:32 AM, Markus Weißmann
>> <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.  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
>>
>
>

[-- Attachment #2: Type: text/html, Size: 4744 bytes --]

Re: [Caml-list] OCaml embedded

[Francois Berenger]

On 06/26/2015 05:04 AM, Berke Durak wrote:
> On Tue, Jun 23, 2015 at 6:32 AM, Markus Weißmann
> <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.  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.

If the feature request for opam called opam-mkbundle

cf. https://github.com/ocaml/opam/issues/929

is implemented some day, this would allow people to
ship ocaml software as source code without requiring
end users to install opam.

>  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?
>

-- 
Regards,
Francois.
"When in doubt, use more types"

Re: [Caml-list] OCaml embedded

[xavier deschuyteneer]

[-- Attachment #1: Type: text/plain, Size: 4098 bytes --]

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 <berke.durak@gmail.com>:

> On Tue, Jun 23, 2015 at 6:32 AM, Markus Weißmann
> <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.  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
>

[-- Attachment #2: Type: text/html, Size: 5461 bytes --]

Re: [Caml-list] OCaml embedded

[Pierre-Alexandre Voye]

[-- Attachment #1: Type: text/plain, Size: 4878 bytes --]

So, maybe you could have a look on two differents projects :

- Ocapic http://www.algo-prog.info/ocapic/web/index.php?id=OCAPIC (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 <berke.durak@gmail.com>:
>
>> On Tue, Jun 23, 2015 at 6:32 AM, Markus Weißmann
>> <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.  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
>>
>
>


-- 
---------------------
https://twitter.com/#!/ontologiae/
http://linuxfr.org/users/montaigne

[-- Attachment #2: Type: text/html, Size: 6906 bytes --]

Re: [Caml-list] OCaml embedded

[Gerd Stolpmann]

[-- Attachment #1: Type: text/plain, Size: 1633 bytes --]


Am Donnerstag, den 25.06.2015, 23:04 -0400 schrieb Berke Durak:
> 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. 

There is when you develop for a closed system like iOS.

Also, there is now arm64, and so far I know there are no boards yet.

>  BTW, is there a maintained ARM cross-compiler?

It's in mainline, 4.02.2. It's still a little bit difficult to use,
because IMHO some convenience targets are missing in the Makefile.
Whitequark in his Android packages just generates a configuration and
avoids the problems (see
https://github.com/whitequark/opam-android/blob/master/packages/ocaml-android32.4.02.2/files/config/Makefile.in, it is in particular essential to set CAMLRUN to the host compiler's ocamlrun). For the iOS branch (not yet in mainline) we added cross-all and cross-opt targets to the Makefile (see https://github.com/gerdstolpmann/ocaml/tree/gs-4.02.2+ios). This might be easier to start with (this branch contains the changes required for the iOS assembler, but should also work for a GNU toolchain). See the build.sh script in this repo for an example how to configure and build.

Gerd

-- 
------------------------------------------------------------
Gerd Stolpmann, Darmstadt, Germany    gerd@gerd-stolpmann.de
My OCaml site:          http://www.camlcity.org
Contact details:        http://www.camlcity.org/contact.html
Company homepage:       http://www.gerd-stolpmann.de
------------------------------------------------------------


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [Caml-list] OCaml embedded

[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, low
> 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.

> 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 <berke.durak@gmail.com>:
> 
> > On Tue, Jun 23, 2015 at 6:32 AM, Markus Weißmann
> > <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.  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

Re: [Caml-list] OCaml embedded

[xavier deschuyteneer]

[-- Attachment #1: Type: text/plain, Size: 6923 bytes --]

Xavier Deschuyteneer

2015-07-16 12:06 GMT+02:00 Goswin von Brederlow <goswin-v-b@web.de>:

> 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, low
> > 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. 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 <berke.durak@gmail.com>:
> >
> > > On Tue, Jun 23, 2015 at 6:32 AM, Markus Weißmann
> > > <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.  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
>

[-- Attachment #2: Type: text/html, Size: 9271 bytes --]