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 309FF7EE49 for ; Fri, 20 Sep 2013 18:19:46 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of dschauer@gmail.com) identity=pra; client-ip=209.85.220.173; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="dschauer@gmail.com"; x-sender="dschauer@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of dschauer@gmail.com designates 209.85.220.173 as permitted sender) identity=mailfrom; client-ip=209.85.220.173; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="dschauer@gmail.com"; x-sender="dschauer@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-vc0-f173.google.com) identity=helo; client-ip=209.85.220.173; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="dschauer@gmail.com"; x-sender="postmaster@mail-vc0-f173.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUCAF90PFLRVdytlGdsb2JhbABBGoM/UrJEjnWBEggWDgEBAQEHCwsJEiqCJQEBBAFAARsdAQMBCwYFCwMfGSIBEQEFARwGEwmHaQEDCQYMNpt7jFGDB4QeChknDWSJAAEFDI8zJgcKhBQDiTiORIEvjH2BYRgphGoe X-IPAS-Result: AgUCAF90PFLRVdytlGdsb2JhbABBGoM/UrJEjnWBEggWDgEBAQEHCwsJEiqCJQEBBAFAARsdAQMBCwYFCwMfGSIBEQEFARwGEwmHaQEDCQYMNpt7jFGDB4QeChknDWSJAAEFDI8zJgcKhBQDiTiORIEvjH2BYRgphGoe X-IronPort-AV: E=Sophos;i="4.90,945,1371074400"; d="scan'208";a="27564776" Received: from mail-vc0-f173.google.com ([209.85.220.173]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 20 Sep 2013 18:19:44 +0200 Received: by mail-vc0-f173.google.com with SMTP id if17so470560vcb.32 for ; Fri, 20 Sep 2013 09:19:43 -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; bh=uWWm+vtDqTvIK92EMnA8zDGiUInbxM8sVZboTnzQgnI=; b=DVHGjBqqGQYntbcoVnhxbiWss91EPz/BBl1RgmaKeDFRG53msmqU7X4TN8+mnaBtML AwlAvHRQ3EKWdNkIa4ZgLsZCtzARrY7v+GaG270ZnQSOau5hbzU0Lx7USQeVNaA6j/z0 qtkoS7THyO9zGC+dF+Jj/a+tYCz0eZWyrMwsSzrGp7rI21mn5i7U7f45F3E8MsnQwlh6 X+CakCztR/vXwXD54cUkjOy6Zi2PEVO7n8LLb1QsE7ocJOoxNwAmyPJW6y/Ry7uVdWLR HrOAhrlkxIGS6uFLFOGqYf25h/jaHtXTBoNdg1I+uWqH2H/PReycmBDOjsS/B35wRi1k v5wQ== MIME-Version: 1.0 X-Received: by 10.220.237.208 with SMTP id kp16mr7131931vcb.4.1379693983575; Fri, 20 Sep 2013 09:19:43 -0700 (PDT) Received: by 10.52.228.71 with HTTP; Fri, 20 Sep 2013 09:19:43 -0700 (PDT) In-Reply-To: <1379692480.11824.28.camel@thinkpad> References: <1379692480.11824.28.camel@thinkpad> Date: Fri, 20 Sep 2013 11:19:43 -0500 Message-ID: From: Dwight Schauer To: Gerd Stolpmann Cc: caml-list@inria.fr Content-Type: multipart/alternative; boundary=047d7b343464ca384304e6d30909 Subject: Re: [Caml-list] Ocaml on an embedded arm system (no linux) --047d7b343464ca384304e6d30909 Content-Type: text/plain; charset=ISO-8859-1 No, the Flash/RAM sizes I mentioned are not a typo. OCaPIC is a similar OCaml project for PIC microntrollers. http://www.algo-prog.info/ocapic/web/index.php?id=OCAPIC:OCAPIC The microcontrollers targetted by OCaPIC have the following characteristics: RAM memory: a few kB. Flash memory: a few tens of kB. Clock: a few MHz The ARM microcontrollers I'm looking to target are much bigger than PIC microcontrollers on all 3 of those counts are significantly larger. On Fri, Sep 20, 2013 at 10:54 AM, Gerd Stolpmann wrote: > Am Freitag, den 20.09.2013, 09:13 -0500 schrieb Dwight Schauer: > > > The ARM processors I'm looking to target are: > > STM32F407ZGT6 ARM Cortex-M4, 1MB Flash, 196KB RAM (Has floating point) > > STM32F103RB ARM Cortex-M3, 128 KB Flash, 20K RAM (No floating point) > > I hope this isn't a typo. 196 KB RAM is way too low to even run a hello > world program. The predecessor of ocaml, caml-light, needed 640K at > minimum for running it on DOS, and that was 16 bit code. Ocaml is a lot > larger, and generates less dense 32 bit code. > > For a very small app on bare metal, I think you need at least 4-8 MB of > memory. For making you happy, calculate 64 MB. I cannot say much about > the split flash mem vs. RAM - but you should take into account that the > representation of values isn't optimized for compactness, and you also > need extra RAM to give the garbage collector room. > > Maybe it is possible to lower the memory requirements by modifying the > ocaml runtime (e.g. make the bytecode more compact at the cost of extra > decoding steps, remove unneeded parts like the compactor, ...), but I > doubt you'll be able to hit the mentioned limits. > > Gerd > > > > > > > > On both I'd like to be able to run bytecode both out of Flash and RAM. > > (Primarily flash, but RAM for debugging). > > > > > > Speed is on overly important as long as I can control when the garbage > > collection is run (could be done in C in the multitasker?). > > > > > > > > Dwight > > > > > > -- > ------------------------------------------------------------ > Gerd Stolpmann, Darmstadt, Germany gerd@gerd-stolpmann.de > Creator of GODI and camlcity.org. > Contact details: http://www.camlcity.org/contact.html > Company homepage: http://www.gerd-stolpmann.de > ------------------------------------------------------------ > --047d7b343464ca384304e6d30909 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
No, the Flash/RAM sizes I mentioned are not a ty= po.

OCaPIC is a similar OCaml project for PIC microntrollers.<= br>http://www.algo-prog.info/ocapic/web/index.php?id=3DOCAPIC:OCAPIC=

The microcontrollers targetted by OCaPIC have the following chara= cteristics:
=A0 RAM memory: a few kB.
=A0 Flash memor= y: a few tens of kB.
=A0 Clock: a few MHz

The ARM microcontrollers I'm looking to target= are much bigger than PIC microcontrollers on all 3 of those counts are sig= nificantly larger.



On Fri, Sep 20, 2013 at 10:54 AM, Gerd S= tolpmann <info@gerd-stolpmann.de> wrote:
Am Freitag, den 20.09.2013, 09:13 -0500 schrieb Dwight Schauer:

> The ARM processors I'm looking to target are:
> STM32F407ZGT6 ARM Cortex-M4, 1MB Flash, 196KB RAM (Has floating point)=
> STM32F103RB ARM Cortex-M3, 128 KB Flash, 20K RAM (No floating point)
I hope this isn't a typo. 196 KB RAM is way too low to even run a= hello
world program. The predecessor of ocaml, caml-light, needed 640K at
minimum for running it on DOS, and that was 16 bit code. Ocaml is a lot
larger, and generates less dense 32 bit code.

For a very small app on bare metal, I think you need at least 4-8 MB of
memory. For making you happy, calculate 64 MB. I cannot say much about
the split flash mem vs. RAM - but you should take into account that the
representation of values isn't optimized for compactness, and you also<= br> need extra RAM to give the garbage collector room.

Maybe it is possible to lower the memory requirements by modifying the
ocaml runtime (e.g. make the bytecode more compact at the cost of extra
decoding steps, remove unneeded parts like the compactor, ...), but I
doubt you'll be able to hit the mentioned limits.

Gerd


>
>
> On both I'd like to be able to run bytecode both out of Flash and = RAM.
> (Primarily flash, but RAM for debugging).
>
>
> Speed is on overly important as long as I can control when the garbage=
> collection is run (could be done in C in the multitasker?).
>
>
>
> Dwight
>
>

--
------------------------------------------------------------
Gerd Stolpmann, Darmstadt, Germany =A0 =A0gerd@gerd-stolpmann.de
Creator of GODI and camlc= ity.org.
Contact details: =A0 =A0 =A0 =A0http://www.camlcity.org/contact.html
Company homepage: =A0 =A0 =A0 http://www.gerd-stolpmann.de
------------------------------------------------------------

--047d7b343464ca384304e6d30909--