[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#691349: ITP: libopencm3 -- firmware library for ARM Cortex-M3 and similar microcontrollers

Package: wnpp
Severity: wishlist
Owner: chrysn <chrysn@fsfe.org>

* Package name    : libopencm3
  Version         : not released yet
  Upstream Author : Uwe Hermann <uwe@hermann-uwe.de>, Piotr Esden-Tempski <piotr@esden.net> and others
* URL             : http://libopencm3.org/
* License         : LGPL-3+
  Programming Lang: C
  Description     : firmware library for ARM Cortex-M3 and similar microcontrollers

libopencm3 (formerly libopenstm32) provides the basic library functions
for programming ARM Cortex M-3 microcontrollers. These tend to have
around up to 128k RAM and 1024k flash ROM, and onoboard peripherials
like SPI, UARTs, USB and general purpose IO (GPIO) pins. The library
contains drivers for the common core chip functionality (turning on and
off interrupts, managing the systick timer) and for the individual

    * * *

the debian branch i'm keeping in the upstream git repo at [1] is
functional in the sense that libopencm3 can be used from the installed
package, but has several shortcomings:

* it depends on something to provide arm-none-eabi-gcc and an
  appropriate libc (eg newlibc).

  currently, i'm using a popular script to download, compile and install
  the required toolchain: summon-arm-toolchain[2] (by the libopencm3
  authors), for which i wrote a little debian directory[3] -- in that
  form, it's pretty inacceptable as a debian package, though.

* it feels strange to have compiled binaries (statically linked
  libraries) in an "architecture: all" package -- but seems technically
  correct. (things were different if there was a debian port to those
  chips, but only few of them support running linux at all).

* loads of lintian warnings, many about files at strange locations.
  upstream installs to /usr/arm-none-eabi/{lib,include}, which is in
  line with what the gcc used is expecting.

* some essential packaging stuff is missing (copyright and watch file,
  the latter for lack of a release process, which is just being
  discussed on the project mailing list) -- can fix that myself, it's
  just lower priority than getting everything to build in the first

* examples are not installed yet -- can fix that myself too

so what i'd need in order to complete that package is:

* an idea of how to create an arm-none-eabi-gcc package properly.
  my gut feeling says that the gcc-4.[67] packages should build another
  binary package called gcc-4.[67]-arm-none-eabi, similar to
  gcc-4.6-hppa64. i'm not familiar with how gcc actually works, so i
  wonder whether we could have a gcc-4.7-multiarch just like we have
  binutils-multiarch (which works well for libopencm3). same goes for
  gdb (not depended on, but more "essential" than "useful" to

* a packaged newlibc; given how libstdc++ is integrated with gcc, i
  don't know whether that's separate from the above or not.

* a statement on where things should actually go. /usr/share feels just
  as wrong as "architecture: any" feels, and lintian complains about

i'd like to emphasise that (from my understanding) this is neither
related to multiarch nor to emdebian, both of which are dealing with
cross compilation to other debian architectures, and this is about bare
metal programming.

[1] https://github.com/libopencm3/libopencm3/tree/debian
[2] https://github.com/esden/summon-arm-toolchain
[3] https://github.com/chrysn/summon-arm-toolchain

To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom

Attachment: signature.asc
Description: Digital signature

Reply to: