ARMduino – a generic implementation of Arduino on ARM Cortex-M chips

All:

have been a user of STM32Duino for a while and liked its simplicity but not the IDE. Never bothered to do anything about it, however.

Only recently a friend of mine got me thinking of porting Arduino to some PIC24F/dsPIC chips and I started to take the same approach to port Arduino on STM8S chips.

Once that’s done, I took it to a more modular level and got the code running on a generic Cortex-M chip – in this case, a STM32F100 chip on the STM32VLDiscovery board. Otherwise, the code should also work for STM32F10x chips.

The implementation is fairly barebone at this point, but most Arduino functions are implemented, short of serial comm, analog read/write and external interrupts.

It is implemented via a layered / compartmentalized approach where hardware dependent code is separated from hardware independent code, allowing the user to hook in different modules for his/her target mcu and the code will compile and run with no or minimum changes.

So far, I have got it running on STM32F100/103, MSP432 and LM4F120. The details / code are available here: https://dannyelectronics.wordpress.com/ … x-m-chips/

it is not complete so watch out for updates -> the code is now at v0.11, vs. v0.10 posted, for example.

Your comments are greatly appreciated.

Hi Danny,

do you know the STM32GENERIC project? There you can easily add every board you have.

STM also started to support more MCUs:
viewtopic.php?f=48&t=2098

You might want to move your post to the “Cores” section so more people will see it:

http://www.stm32duino.com/viewforum.php?f=42

I see you have a PIC24F port, how are you going to deal with C++ libraries? Aren’t those compilers ‘C’ only or did they add C++?

BTW.

Several other people and already use the name ARMduino

https://www.google.com.au/search?q=armduino

I dont think its trademarked, but it is rather confusinb if you search for that term

PS. i also moved it to Cores

PPS.

As well as @danieleff’s STMGeneric core, and STMs own Cores, there is Koduino which is also an Arduino core for STM32F3 and STM32F4, plus our old faithful of Libmaple, plus several abandoned cores like the MakerlabMe core

However you core appears to be the only core that spans different manufacturers, apart from of course mbed
But mbed is not Arduino, its just a similar dev paradigm

dannyf wrote:… I started to take the same approach to port Arduino on STM8S chips.

Chris: didn’t know the stm32generic project. thanks. a lot of similarities there:

1. our approaches to gpio are identical.
2. the stm32generic project isolated the device-specific things into individual files.

we differ in that his aim is to produce a generic template for STM32, and my goal is to produce a generic template for all ARM chpis – but not writing the device-specific things myself.

but two projects are quite expandable into each other’s spheres.

Rick: i’m taking a C-approach to the porting so all Cpp functions have to be replicated in C, sometimes with slightly different names. like Random(min, max) gets maxed to Random2(min, max), as the Random(max) already exists.

Ken: the STM8S project is linked on the ARMduino page but you can click it here: https://dannyelectronics.wordpress.com/ … tm8s-mcus/

I just ported the analogWrite() and analogRead() functions but have not had the time to update the code yet. will do that later.

dannyf wrote:Rick: i’m taking a C-approach to the porting so all Cpp functions have to be replicated in C, sometimes with slightly different names. like Random(min, max) gets maxed to Random2(min, max), as the Random(max) already exists.

Rick Kimball wrote:….

Sadly, the problem with that approach is that you miss out on all the rich libraries that people have written for the Arduino platform. I think it is unlikely people will port C++ libraries to C to work with your core. The 3rd party libraries are why people put up with the inefficient Arduino platform in the first place. At least that is how I see it.

” Sadly, the problem with that approach is”

Unfortunately true: if the compiler doesn’t support cop, there is no way around that.

But if you step back and the situation may be a little different, as you have two options here:

1. Don’t support Arduino as the compiler doesn’t support all Arduino code. Or

2. Support at least some Arduino code (those coded in C).

I took the later approach knowing that some of the cop code will have to be rewritten.

The downside of that approach, particularly to the Arduino crowd, is that they may find it too challenging to e ven attempt.

But then you are no different from if you had taken approach 1.

So approach 2 gives you some upside but no downside.

I spent some time trying out the pic24f chips when I was getting started with MCUs about 7 years ago. I would have spent more time with the pic24 series if it had a C++ compiler. I might have even spent more time if the free ‘C’ compiler wasn’t crippled by the way they disabled the higher level optimization features. This approach to software seemed rather backwards thinking. Why penalize people who want to use your chip? When I noticed your posting here I thought, hmm maybe they have come around since they bought ATMEL. I now see nothing has changed. It’s too bad I was hoping that eventually they would see the light.

The whole pic24f family is my favorite, for its vectors interrupts, remarkable pins and peripheral consistency. They offer great speed for numerical calculations. Both c30 and xc16 generate good quality code. It is my goto chip for microchip.

I don’t mind having to pay for a quality compiler. You get more than your moneys worth in one project.

What matters to me is that the vendor offers quality products and services. On that front, microchip does a good job here. I do hope that they can invest more in marketing the pic24f however.

Spent more time on this and implemented analogRead(), analogWrite() and DACnWrite().

analogWrite() offers up to 16 bit of resolution and is available on 16 separate pins.

DACnWrite() utilizes the 12 bit dac channels to produce analog output.

Next is exti and serial comms.

Do you seriously publish your code in wordpress pages? And where is that analogread/write implementation?

I started playing with your STM8S project, and was wondering if you will also be updating it, and if you would consider hosting it on GitHub?

if you will also be updating it,

yes. my code is not v0.11a, added pulseIn(), tone()/noTone(), analogWrite(), analogRead(), attachInterrupt() and detachInterrupt() – ugly implementation and I’m thinking of revamping it soon.

I wanted to get it to a critical state and then push it out, but can publish an intermediate version if you want to try it.

if you would consider hosting it on GitHub?

don’t know about that. don’t want to create an account when I don’t have to,

Regarding STM8, have you seen this project: https://tenbaht.github.io/sduino?

Kenjutsu wrote:Regarding STM8, have you seen this project: https://tenbaht.github.io/sduino?

Kenjutsu wrote:Regarding STM8, have you seen this project: https://tenbaht.github.io/sduino?

Stm8 is really under appreciated. I hope all the ports hopefully will get more people into it, given where the avr family is.

dannyf wrote:Mine is easier to set up and get going however.

Since I have two of these STM8 cheap boards….
I’m watching this project on github and on blog.
Hope to find time to test it soon.

Any plans on making STM8Sduino compile using SDCC? STM8S Standard Peripheral Library Ported to SDCC for multiple STM8 targets is already done. Since I use macOS it would be nice to use the native port of SDCC for playing with STM8Sduino

Kenjutsu, there is currently no plan to port it to other compilers.

With that said, the code is fairly standard c so I wouldn’t expect much issue porting it over to a decent c compiler.

Of the two other compilers for stm8, I have limited experience with SDCC – played around it briefly and discovered that it would discard unused sections and moved on.

Porting to cosmic should be fairly easy – mostly around ist declarations.

If you want, show me the error log for SDCC and I can go through the document to help you port it to that compiler.

In the mean time I will make the code work for cosmic.

edit: the existing STM8Sduino code base actually was written to allow compilation under COSMIC and RAISONANCE compilers but I commented out the cross-platform stuff. so I have re-instated the support now for those two compilers and the code now should compile under all three compilers, IAR, COSMIC and RAISONANCE.

I also took a quick look at SDCC compiler manual and the only difference I saw was the declaration of interrupts. The INTERRUPT_HANDLER macro could be written fairly easily to map back to the SDCC style – ST showed how to do that towards the end of stm8s.h.

edit 2: I uploaded the revised files to provide support for COSMIC (tested) and RAISONANCE. aside from interrupt handling, COSMIC doesn’t support “inline” – fairly easy to deal with. Should compile for RAISONANCE – not tested however.

I am not sure I would bother building an STM8 in preference to a STM32F103 board.

But, I have noticed a lot of cheap devices use the STM8, so having a way to repurpose those devices would be good.

e.g. I have a several LED panel mount volt meters which use the STM8, and I recently took a USB voltage and current dongle apart and it also contains a STM8.

Considering STM have literally sold billions of STM8 MCUs, I am sure having a usable STM8 Arduino toolchain would be very beneficial to device hackers

dannyf wrote:
edit: the existing STM8Sduino code base actually was written to allow compilation under COSMIC and RAISONANCE compilers but I commented out the cross-platform stuff. so I have re-instated the support now for those two compilers and the code now should compile under all three compilers, IAR, COSMIC and RAISONANCE.

I had to order some other things from eBay so I ordered 2 x STM8 boards as they are cheap

I probably will never use them, but I like to be prepared in case I need something like that

zoomx wrote:
Testing with SDCC I get
In file included from stm8sduino.h:56,
from example.c:1:
stm8s.h:90:3: error: #error "Unsupported Compiler!"
stm8s.h:2735:25: fatal error: intrinsics.h: No such file or directory
compilation terminated.

RogerClark wrote:But, I have noticed a lot of cheap devices use the STM8, so having a way to repurpose those devices would be good.

The intrinsic come from stm8s.h and you can comment it out – I don’t remember using anything there in particular. Maybe mop?

The complaints around line 590 on tmp is because it was declared in the middle of that function. I have since moved it to the beginning of the function.

Fixed that and see what else may pop up.

The complaints about unreachable issue to infinite loop.

Not sure about Evelyn and Dog.

Those 4 digit volt meters use rx and tx pins routed out, making it possible for then to be daise chained together as a 4 digit standalone or 8 digit or 12 digit displays.

dannyf wrote:The complaints around line 590 on tmp is because it was declared in the middle of that function. I have since moved it to the beginning of the function.

Fixed that and see what else may pop up.

I cannot find anything of interest on line 249 / 250, or 899 and 935. Maybe you can copy those lines over, +/- 5 lines?

Again, those mentions of Evelyn / Dog mean nothing to me. Looks to be very SDCC specific.

Kenjutsu wrote:RogerClark wrote:But, I have noticed a lot of cheap devices use the STM8, so having a way to repurpose those devices would be good.

[dannyf – Sat Jun 17, 2017 4:50 pm] –
I cannot find anything of interest on line 249 / 250, or 899 and 935. Maybe you can copy those lines over, +/- 5 lines?

Again, those mentions of Evelyn / Dog mean nothing to me. Looks to be very SDCC specific.

I got rid of the ” Evelyn / Dog” messages by removing inline from

• void pinMode(PIN_TypeDef pin, uint8_t mode)
• void digitalWrite(PIN_TypeDef pin, uint8_t val)
• int digitalRead(PIN_TypeDef pin)

The “warning 116: left shifting more than size of object changed to zero” and “error 9: FATAL Compiler Internal Error” messages are in void mcu_init(void) at the following lines:
TIM1->ARRL = (PWM_PR); //top at 0x0fff

The first two are ok. They cast the lab of a 16 bit type to arrl. If you want, you can manually cast pwm pr to uint8.

I will take a look at interrupts. It maps back to ei and I will see how interrupts are enabled or disabled in sdcc.

I took a look at the SDCC manual. The issue with interrupts() is its use of an IAR-specific call.

You can recreate that via assembly instructions “rim” and “sim”.

To make it more seamless, you can change the stm8s.h file, especially in the beginning where it complains about unsupported compiler – simply insert another #elif for SDCC and you are ready to go.

[dannyf – Sun Jun 18, 2017 9:37 pm] –
I took a look at the SDCC manual. The issue with interrupts() is its use of an IAR-specific call.

You can recreate that via assembly instructions “rim” and “sim”.

To make it more seamless, you can change the stm8s.h file, especially in the beginning where it complains about unsupported compiler – simply insert another #elif for SDCC and you are ready to go.

I use stm8s.h from STM8S Standard Peripheral Library Ported to SDCC for multiple STM8 targets which contain the required #idefs for SDCC, including what is needed for interrupts, but still “error 9: FATAL Compiler Internal Error” is in void mcu_init(void). I have a feeling SDCC is not happy about something else in this function, and not about that specific line

Update:
I placed a simple for loop after the line SDCC complains about, and now interrupts() no longer generates the error, but the for loop after it… Will have to dig deeper

for maximum compatability, I mapped interrupts() -> ei() -> enableInterrupts(), which is then mapped to __asm()__ by your STM8S.h file. so it should work.

but the for loop after it.

that would suggest that the issue is with the preceding statements – you can confirm it by commenting out interrupts() in mcu_init().

What do your USE_XXX macros look like?

[dannyf – Sat Jun 17, 2017 1:19 pm] –
Those 4 digit volt meters use rx and tx pins routed out, making it possible for then to be daise chained together as a 4 digit standalone or 8 digit or 12 digit displays.

I ordered a couple of those units from eBay to test out that concept. While waiting for them, I wrote up a simple piece of code on a PIC16F193x (@16Mhz). So far, it has lived nicely on a simulator – I daisy-chained two of them together to form an 8-digit display. The code is available from github.

I would expect minimum changes to retarget the code for STM8.

now interrupts() no longer generates the error

I got SDCC installed and used it to compile stm8sduino.c. didn’t get any error, especially the critical error that you got. Just three warnings.

I used the latest SDCC for windows. 3.6.0 I think.

Thank you for the feedback.

Here is what I am using:

• SDCC : mcs51/z80/z180/r2k/r3ka/gbz80/tlcs90/ds390/pic16/pic14/TININative/ds400/hc08/s08/stm8 3.6.6 #9921 (Mac OS X i386)
• stm8s.h from STM8S Standard Peripheral Library Ported to SDCC for multiple STM8 targets which contain the required #idefs for SDCC, including what is needed for interrupts
• the latest STM8Sduino code from github: https://github.com/dannyf00/STM8Sduino
• a “STM8S103F3P6 Minimum System Development Board” similar to these: https://goo.gl/9pkUuD

I am using your simple blink.c example:

#include "stm8sduino.h" //include stm8suduino defs

#define LED PB5 //LED attached to pin 13 (=PB5 on STM8Sblue)
#define LED_DLY 500 //waste some time, in ms

//user setup
void setup(void) {
pinMode(LED, OUTPUT); //set LED as output
}

//user loop
void loop(void) {
digitalWrite(LED, !digitalRead(LED)); //flip LED
delay(LED_DLY); //waste some time
}

Pb4 and pb5 are od pins and unable to source current. You can either sink current on those pins or move to a different pin.

[dannyf – Mon Jun 26, 2017 2:48 pm] –
Pb4 and pb5 are od pins and unable to source current. You can either sink current on those pins or move to a different pin.

Using your initial release (version: v0.10) and IAR EMSTM8, everything compiles and the LED on PB5 is blinking. However, with the latest release and IAR EMSTM8, the LED on PB5 does not blink. I will connect a LED to another pin and try again

I just started porting the ARMduino to STM32F0xx – testing on a STM32F030F now. So far, the generics and GPIO are working and will fill in the rest later. Code is here: https://github.com/dannyf00/ARMduino/tr … er/STM32F0

your comments / feedback are most welcome.

edit: I added analogRead(), attachInterrupts(), detachInterrupts() and uart-related routines. PWM coming up next.

That’s a very short framework.
Probably an interval timer would be a good idea. With this many peripherals could be implemented in software ( as long there is no hardware driver ).

DanielEff did it here with PWM, Tone, analogWrite

that’s fairly easy to do. i already have a set of routines that do that.

So now I have 17 “virtual timers” that you can set their periods independently and install handlers independently. I can add a few more but I guess that’s more than one would need for 99% of the applications.

I just came up to an interesting feature of the STM32F0: it has caliberated values for its temperature sensor (at 30C and 110C) and its internal voltage reference. Those values are measured at factory and stored in those devices.

They can obviously be used to more accurately measure analog values, including temperature or Vdda; and they can also be used as another form of UID – which STM32F0 has “undocumentedly”,