STM32, Maple and Maple mini port to IDE 1.5.x

Other Hardware 3rd Party Boards
121

Hi Ray,

I totally agree.

User centric paths are a definite no-no...

Looking at the Due thread, people seem to be writing Due ports of the common libraries, rather than attempting cross-platform versions.

I can understand why people would want to do this, because (a) its easier to do and (b) sometimes the scope of the changes are large and would require big sections of the code ifdef'ed in and out.

Perhaps the ultimate solution is to have sub folders under the Arduino/libraries folder

one per architecture

e.g. libraries/avr/
libraries/sam
libraries/cortex-m3

Note. I think the Maple stuff would need to be called cortex-m3 as its the gcc name for this

I wonder how hard it would be to change this in the IDE, possibly not that hard.

122

I think the Maple stuff would need to be called cortex-m3 as its the gcc name for this

That depends. Peripherals vary greatly between different ARM chips from different vendors (or even from the same vendor), so putting a DMA-based I2C driver for STM32F103 (maple) in a "cortex-m3" directory would be a big mistake. OTOH, generic optimized algorithms for a 32bit ARM, or libraries built on top of the arduino core functions could go there.

123

Hi Guys,

Does anyone know why memcpy is not implemented as part of maple implementation (well at least not the files I have ...)

Can someone try putting memcpy in some code, even in blink and see if it compiles for them.

I get a message straight away saying its not defined.

Does anyone know why this may be happening ?

Note. The Due seems to have memcpy, and it uses the same compilor, so there must be something else that different in the hardware stuff for the due and the STM32

124

@westfw

OK. I'll need to do some more research about why people are posting Due specific libraries to the forum.

I thought perhaps some thing like progmem were the reason that Due needed specific libraries for some things, but as these are re-defined in the avr folder (which you previously sent).

The differences must be other stuff, e.g. attach interrupt perhaps ?

Either way, I don't have an issue with having

arduino/libraries/avr
arduino/libraries/sam
arduino/libraries/stm32F1xx

If this is the way to do it.

Its not too much of an overhead for a normal avr (only) user to go into libraries/avr and put their avr libraries in there !

and the rest of us who dabble in the more exotic processors should be capable of making new folders :wink:

125

why memcpy is not implemented

memcpy() is part of libc, which is typically NOT considered part of the compiler for deeply embedded system. (for avr, you get avr-libc, and there are numerous "generic" libc implementations for various other chips with various licenses. Typically this is one of the things you get from a compiler "vendor" (including a chip company) even when they are using gcc for the actual compiler. And there are usually license restrictions on using their library code on other vendors cpys. There are also open source versions of libc, including "newlib" (which is "big"), "newlib nano" (smaller, for more deeply embedded apps), and ... I dunno.

It looks like Due is using newlib nano from .../hardware/tools/gcc-arm-none-eabi-4.8.3-2014q1/arm-none-eabi/lib (there's a "nano.specs" there.) It's unclear whether this is Atmel-specific or licensed., or how much trouble you would get in for using atmel libc on an ST microcontroller. (I'm not even sure which library is used, among the 4 or 5 different arm libraries that are in there...)

Are you re-using the avr arm compiler, or do you still have the toolset (somehow?) download the arm compiler from somewhere else?

126

Thanks. @westfm

I'm just using the ARM compilor that comes with 1.5.x

Looking at this page

It mentions open source a lot and newlib-nano, but I've not specifically seen a license

I will need to take a look at the Due linking stuff etc, so we how nano has been integrated and why its not being called in by the Maple installation (it probably wasn't available when LeafLabs originally did their dev work, but I'll also check their IDE installtion to see if it was there)

I'll post back when I find out or make any progress, as this sort of lib seems quite fundamental to allowing a lot of other libraries to compile, and I often use memcpy in my code e.f. to copy arrays and buffers.

Anyway, Thanks again

Roger

127

It's possible that the Maple stuff does not include a libc. After all, the arduino documentation doesn't explicitly mention most of the libc functions, and they may not be explicitly necessary to support Arduino sketches. (although most of us expect those functions to be present.)

You might look at some of the ChipKit (PIC32) forum archives. They counted their conversion from Microchip libc libraries (which have odd license requirements) to newlib as a pretty significant accomplishment.

Hmm. Downloading the (old) MapleIDE, I find a libc in hardware/tools/arm/arm-none-eabi/lib
I can't tell where it's from, though. I do see memcpy() in there, but I need to #include <string.h> for a sketch to find it.

128

@westfm

I've been looking through the compiler intermediate output, and it looks like stdlib.h was not included from wirish.h (which is included from Arduino.h)

ie Due includes

#include <stdlib.h>
#include <string.h>
#include <math.h>

and some others that wirish,h doesn't

However, just adding in <stdlib.h> gives errors because the macro _EXFUN which is used in the prototyping of memcpy and other functions.

i.e I get this error

c:\program files (x86)\arduino\hardware\tools\gcc-arm-none-eabi-4.8.3-2014q1\arm-none-eabi\include\stdlib.h:67:5: error: expected unqualified-id before 'int'
 int _EXFUN(abs,(int));

It appears that _EXFUN is defined in

Arduino\hardware\tools\gcc-arm-none-eabi-4.8.3-2014q1\arm-none-eabi\include

But just including _ansi.h doesn't seem to fix it either, and its quite possible that _ansi.h is already included already at this point.

and in reality there is something else that needs to be included before this, which has not been included ;-(

Or possibly one of the gcc -DDefines that the Due uses

I have tried just putting the _EXFUN def's in wirish.h but that just gave other errors

So at the moment I'm at a loss to work out quite what needs to be defined or included in order that the stuff in stdlib actually compiles

129

Update.

I found this on the LeafLabs site

Which gave me a bit of an idea of how to fix this, and I tried including <strlib.h> into my test sketch but it didn't fix it.
However I noticed in the Due's Arduino.h, that it also included <string.h> which I think is where the memcpy functions are also declared.
So I included that as well, and it worked.

So I tried moving these includes into wirish.h under <stdint.h> but it didnt work.

However I found that if I included the files at the top of wirish.h it did compile fine.

So I've now included the files that the Due includes in the top of Arduino.h into the top of wirish.h.

Doing this, doesn't seem to cause any problems. My I2C test sketch connecting to a barometer module still works fine.

I guess that compiles may be slightly slower

I've pushed the changes to my github repo

Note. I think I seriously confused Github, because the clock on my PC went to the wrong timezone after I booted back from Linux into Windows.

So the commits look like they are out of order.

I'm thinking of actually doing the whole git repo thing again

By putting bobs code into the repo first, then replacing it with my changed code so that we get tracked changed from the beginning, but at the moment I'm just going to leave it, as I have better things to waste my time on :wink:

130

Update.

I needed EEPROM lib for one of the libraries I want to use (RTIMULib), so I found this library and have added it to the other Maple libs.

HACK ALERT. I don't know what EEPROM page size is required for the Maple. I have just put in a define for the MCU_STM32F103RB to get it to compile

The EEPROM_PAGE_SIZE and EEPROM_START_ADDRESS all need to be changed to work with the Maple or Maple Mini or Generic STM32 boards.

However the only reference I can find is this application note from ST
http://www.st.com/web/en/resource/technical/document/application_note/CD00165693.pdf

and it doesn't make any mention of device variations.

STM also have a file (suite) which includes an EEPROM_Emulation/src/eeprom.c however I'm not sure where it can be downloaded from.
It may require login and is probably under their non-distributable license anyway, but it may give a hint about memory pages etc

BTW. I now need to get I2CDev to compile - which is currently not doing

BTW. Apologies for the various mistakes while checking stuff into the git repo.. Its been a long day :wink:

131

rogerClark:
I already have an arduino pro on my github account, so I'll add it to that rep and post when its finished uploading.

Thank you Roger, that's awesome ! I'll have spare time this week-end to check all this out to have the led flashing :wink: Hope you saw the schematics I made for the board.

132

Note: Please make reference to:

For a summarized version of pertinent information contained in this lengthly
thread. Also, some simple Mini Maple projects with source may be found on
my blog: http://www.hackster.io/rayburne

To follow-up on #118 re: library architecture, the answer was easy to find but may be more difficult to implement: Arduino-IDE-1.5:-Library-specification
Summary:

In 1.5.x, libraries placed in the user’s sketchbook folder (in the libraries/ sub-folder) will be made available for all boards, which may include multiple different processor architectures. To provide architecture-specific code or optimizations, library authors can use the ARDUINO_ARCH_XXX preprocessor macro (#define), where XXX is the name of the architecture (as determined by the name of the folder containing it), e.g. ARDUINO_ARCH_AVR will be defined when compiling for AVR-based boards. For example,

#if defined(ARDUINO_ARCH_AVR)
// AVR-specific code
#elif defined(ARDUINO_ARCH_SAM)
// SAM-specific code
#else
// generic, non-platform specific code
#endif
Alternatively, if a library only works on certain architectures, you can provide an explicit error message (instead of allowing the compilation to fail in an difficult to understand way):

#if defined(ARDUINO_ARCH_AVR)
// AVR-specific code
#elif defined(ARDUINO_ARCH_SAM)
// SAM-specific code
#else
#error “This library only supports boards with an AVR or SAM processor.”
#endif

rogerClark:
I pulled a ZIP from you Github and overlayed what I already had... using the 1.5.7 GUI, nothing broke which is to say, I can compile without error blinky, point to the COMxx port for the Mini, and have the COMxx DTR force a DFU and the batch file, maple_upload.bat does execute and load the compiled binary.

So, users pulling your Github ZIP should be able to compile programs not dependent on Arduino lib support and upload the the Maple Mini utilizing a virtual comm port and DFU using Arduino GUI 1.5.7.
Users should unZIP the archive from Github into their Arduino home directory which will be similar to:
\Documents\Arduino\hardware\maple-asp
Note:maple-asp is the original name but roger's ZIP defaults to: Arduino_STM32-master

Roger, I'm thinking a name more specific to the board-type should be utilize as the folder name subordinate to \hardware\ but maybe with more intelligence than maple-asp? Maybe, "maplemini_ARM" or something... I'm not hung up on this as I'm using the maple-asp directory name myself.

I'm going to look into the library thing a bit more and attempt to implement an example.

PROGMEM:
Here is an answer from leaflabs
PROGMEM

Replacing PROGMEM: If you need to store a lot of constant data, you can store variables in Flash (instead of RAM) by using the libmaple macro FLASH. Here’s an example:

uint32 array[] FLASH = {0, 1, 2};
This will help you save RAM when you need to store large amounts of data, like look-up tables.

You can only store values which are compile-time constants (like numbers and strings, and arrays of numbers and strings) in this way. Also, if you try to change a variable stored in Flash, your program will crash.

If you need to port over AVR/Arduino code that uses pgmspace.h, these declarations may help you:

typedef const unsigned char prog_uchar;
#define pgm_read_byte_near(x) ((prog_uchar)x)
#define pgm_read_byte(x) ((prog_uchar)x)

Ray

133

Hi Ray

I'm not hung up on the name. But I wanted to convey that its not just maple boards it supports, its also other generic stm32 boards.

Perhaps

Maple_STM32

Would be a better title.

I'm glad the maple stuff still works, as I wasn't able to test it, as my maple clones still have not arrived, nor has the other larger generic STM32 board, I.e more akin to a uno sized board

Re: progmem

I have not tested it, but I have copied the avr folder from the SAM core of Arduino 1.5.x and added the includes for this into wirish.h

I have not had time to look in var/progmem but I think it provides macros and definitions to make progmem statements work on the due

However I have not had time to test whether this has resolved the progmem issue or just allowed the code to compile.

Just to reiterate, the EEPROM library I found and added, is also untested, and although it compiles I have not verified the correct flash page it should use, or the page size.
So currently the EEPROM code may possibly overwrite the program.

Re ARDRUINO_ARC_xxx

It should be easy to add this to the boards.txt etc

Perhaps @westfm is the best person to advise us on this question, he / she seems to be more of an ARM expert than I am :wink:

But at a minimum it would need to be

ARDRUINO_ARC_STM32

And possibly as stm do lots of variants, it may need to be

ARDRUINO_ARC_STM32F1XX

And even then... Looking at the code in EEPROM.h. Minor variations in the part number at the end, e.g. The bit like C6T at the end of the part number, possibly have an effect on what needs to go in the code.

However for the moment I will add a definition as

ARDRUINO_ARC_STM32F1XX

As its my best guess.

Also...

The guy who wrote the EEPROM library, also has a CAN bus library, so I think I will add it as untested code to my repo, so that at least all these things are kept in one place.

BTW. I noticed on the Due forum there is a thread of libraries ported to the Due, but they are not in one central location, ie some on people's github account, some on google code, some in blogs as code, some posted to the forum as code etc etc.

I'm surprised someone has not setup a git repo and put them all in one place.

I may do this, and also do the same thing for any maple libs I find.

One other thing.

I'm not sure how long leaflabs will keep their wiki pages going, so I may find out if I can add their maple pages to my git repo

However I think they are copyright leaflabs so I will need to get permission.

Cheers

Roger

134

Hobby16

I'm not sure if you have a maple clone or a generic stm32 board.

Be aware that the generic stm32 boards seem to have their led on a different pin to the maple boards

I think my generic board has the led on pin PC13

On my generic board I soldered on another led to the same pin as on the maple mini.

Also.

As a general point. If you need to address the pins by their real names, and not the maple overlay of numbers. The original pins e..g PB0 etc are also defined in one of the headers, and personally, I think it may make more sense to do it that way.

Oh one other thing.

If you are using USB to serial, for debugging to the terminal, it works fine, but, its on serial1, so currently I'm using #define Serial Serial1 in the top of existing sketches so that I don't need to change all the code.

I may add this statement to boards.txt for the generic stm32 board

135

Ray,

Sorry. I forgot...

I'm not sure why my boards.txt defaults to stm32, its the last one in the list.

Arduino must write something to one of the hardware files to store this.

I will check.

136

Note: Please make reference to:

For a summarized version of pertinent information contained in this lengthly
thread. Also, some simple Mini Maple projects with source may be found on
my blog: http://www.hackster.io/rayburne

More info on 1.5.x

manpage 1.5.x

Of interest:

--board package:arch:board[:parameters]

1.5.8
Introduced --save-prefs.

--pref options are now not saved to the preferences file, just like --board and --port, unless --save-prefs is specified.

A path passed to --preferences-file, or set in the build.path, preferences.path or settings.path is now interpreted relative to the current directory instead of the location of the arduino command itself.

137

Ray,

I just dumped the defines for the Due and the Maple and the Maple has this for its ARC

ARDUINO_ARCH_MAPLE

the Due has

ARDUINO_ARCH_SAM

I can't quite see where the MAPLE and SAM bit is being defined, so I've tried changing the name of the folder inside the hardware folder from maple to STM32F1XX and it changed the def to

ARDUINO_ARCH_STM32F1XX

Changing the folder name seemed to have no ill effects, the boards are still recognized in the menu and it compiles OK

Can I have a show of hands for the name of this, as its important in terms of this

ARDUINO_ARCH

statement

Personally, I'd prefer the STM32F1XX as it fits with the SAM which is Atmels line of devices,
where as Maple is effectively a brand name of leaflabs

138

Guys

As neither the PM's on the forum or the notifications are working for me.

Please feel free to email me with suggestions etc. My email is my first name (no not clark :wink:
and my domain name is rogerclark.net (surprising huh!)

Cheers

Roger Clark

139

Note: Please make reference to:

For a summarized version of pertinent information contained in this lengthly
thread. Also, some simple Mini Maple projects with source may be found on
my blog: http://www.hackster.io/rayburne

Personally, I'd prefer the STM32F1XX as it fits with the SAM

+1

140

Ray

Thanks

I'll wait for a few more votes.

BTW.

If anyone wants to suggest a repo name, please let me know.

I already have an Arduino on my github account, but that has other stuff in it, and I think its best to keep this separate.

I guess it doesn't need to have Arduino in the title necessarily, but it does make it clear what its for.

Perhaps

Maple_STM32 would be an OK repo name.