[chbot] Nucleo

[Stephen Irons]

We did a project using an STM32, all written in C. We tried C++, but found
it difficult to keep the code size down. Perhaps we could have explicitly
forced the EC++ subset.

If you have enough performance for your application, it does not matter
which core you use. You choose the language: C or C++ or Lua. An ARM xx
core is an ARM xx core, whoever makes the chip.

You get different peripherals from different manufacturers, and that is
what you are really choosing. You use an Arduino because of the libraries,
not because of the core.

The ST peripherals were pretty good, with a wide range of useful functions,
mostly involving DMA:

   - AD converter with simultaneous sampling with DMA to a memory buffer
   (up to 8K), with an interrupt when nearly full. Good for high-speed
   sampling, though you have to make sure your processing does not fall behind.
   - DMA on SPI peripherals, so sending data to the small LCD (128x64 or
   so) took little overhead.
   - Free-running timer/counter which can reset on input change, and
   trigger outputs, and trigger DMA, so we made an RS-485 driver that would
   wait for line idle for a length of time, then enable the output driver some
   time later, then a bit later trigger the DMA to start transmitting data,
   all under hardware control; made for nice reliable timing.

Peripheral docs were ok. I still like the TI docs best.

However, the library functions provided by ST (STM-SIS or something) to
configure the peripherals were pretty bad. We did use them, and they
worked, but they were slow. Fine for the application, because of the 72 MHz
clock, but...just offensively slow.

We used gcc and gdb, running on Linux. We used the Codesourcery tools (now
Mentor Graphics), though it would have been easy enough to compile our own
cross-toolchain. The Codesourcery tools are still available free from
Mentor Graphics, but they make it difficult to find the free ones.

We used a Ethernet connected JTAG debug adapter, which speaks GDB directly.
It was easy enough to connect to Eclipse, though it was a bit funky getting
the code into the flash. $expensive (many K).

We also made a serial GDB stub that we linked in with the application, so
we could debug via a UART.

Other projects at the company have used OpenOCD. That was 4 years ago or
so: it might be better now, but I remember a lot of blue air around that
team -- OpenOCD was flaky and the cheap USB hardware was slow. $cheap,
though.



On 21 October 2014 10:08, Jasper Mackenzie <jasper.mackenzie at gmail.com>
wrote:

> So, on the topic of dev boards...
>  We are about to begin a new project redesigning the open source BMS for
> EV Lithium stacks, but will be using STM32 chips which I have absolutely no
> experience with.
>
> The prototype board is already on the way apparently!! (No pressure)
>
> The idea is to start with a Nucleo which seems crazy cheap at only $16
> from Element14 (More expensive on DX!)
>
> Does anyone have any experience with these devboards, or STM32, or more
> generally the Arm that they are (left?)?
>
> I come from a C on Arduino background (ATMega328p), where C is sort of
> like basic without the goto's 8)
>  Toolchain is hoped to be entirely GNU, mostly running in GNU/Linux.
>
> Cheers.
>
> Jasper
>
> _______________________________________________
> Chchrobotics mailing list Chchrobotics at lists.linuxnut.co.nz
> http://lists.ourshack.com/mailman/listinfo/chchrobotics
> Mail Archives: http://lists.ourshack.com/pipermail/chchrobotics/
> Web site: http://kiwibots.org
> Meetings 3rd Monday each month.
>
> When replying, please edit your Subject line to reflect new content.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ourshack.com/pipermail/chchrobotics/attachments/20141021/408006d8/attachment-0001.html>