[chbot] Nucleo

[Volker Kuhlmann]

On Tue 21 Oct 2014 10:08:04 NZDT +1300, Jasper Mackenzie wrote:

> Does anyone have any experience with these devboards, or STM32, or more
> generally the Arm that they are (left?)?

I used LPCxpresso (NXP ARM, Cortex M3) in the past, and it was pretty
good. Nice IDE (eclipse based), an M3 is an M3, but the LPC1768 has a
pretty good set of peripherals on board. Because the CPU core is always
the same the only difference between ARM chips is what peripherals they
come with, and how they are accessed. I found the (much-maligned?) NXP
peripheral docs (800+ pages) easy to navigate to get me to what register
I needed to get to.

ARM made an effort to streamline peripheral access through a set of
defined functions (functional API), with code being supplied by chip
vendors for their chips. I found that there are some subtleties not
mentioned in the docs with that, and code size goes up noticably.
However you do keep your chip vendor independence.

I can't help you specifically with STM. The only difference is in the
peripherals data sheets, and things like flash + RAM size.

> I come from a C on Arduino background (ATMega328p), where C is sort of like
> basic without the goto's 8)

C is much better than BASIC! But seriously, for a new project you ought
to be writing in C++ instead. It even works well on the 8-bit AVR, and
surprisingly, if done right, does not increase code size over C. I think
it's referred to embedded C++, which you can view as a subset of C++.
The full C++ is still available on ARM to use if you wish, but you pay
the price (in code and RAM size).

>  Toolchain is hoped to be entirely GNU, mostly running in GNU/Linux.

The gcc toolchain is almost the de-facto industry standard, or that was
the impression I got. If you still pay $5-10k for the tool chain, what
you are getting is better debugging support (which however is always
proprietory). The compiler etc and IDE are the same.

You can access the debugging support integrated into ARM chips with open
source tools, i.e. gdb, a JTAG debugging interface, and an open source
driver (openocd) for the JTAG box. The main JTAG interfaces I looked at
were from Amontec (expensive, good), Olimex (cheaper, wasn't too
impressed with docs), flyswatter (cheap, good docs). Make sure you get a
high speed one, otherwise the flash reprogramming takes forever. None of
the newer generation fast JTAG boxes had schematics available so don't
blow the hardware lines (the older slow ones were open hardware
designs with common components, nobody would even tell me what the line
driver chips in the newer designs are, commercial bla bla bla).

HTH,

Volker

-- 
Volker Kuhlmann
http://volker.top.geek.nz/	Please do not CC list postings to me.