I was sent to this board from the Arduino forums, I was looking for a small, Pro Mini size, Arduino with a bit more memory as my sketches have reached the 32K… But it must be small, Pro Mini is perfect, Nano is also good although the USB is a waste once deployed.
So I was trying to find out how it all works under the hood. It seems the Arduino IDE is heavily based on the ATMEL AVR compiler/toolkit/SDK. I have found out this by digging around:
1) ATMEL AVR C compiler and CRT and libraries:
C:\arduino\arduino-1.6.4\hardware\tools\avr
for example this object file tries to find “int main(….” C:\arduino\arduino-1.6.4\hardware\tools\avr\avr\lib\avr5\crtm328p.o
2) Arduino’s own glue code
C:\arduino\arduino-1.6.4\hardware\arduino\avr\cores\arduino, eg here is the main.cpp file
Weird: it seems the IDE compiles everything in this directory, for example I renamed “main.cpp” to “main – ha ha ha.cpp” and it kept compiling it and using it…
Remoning the “.cpp” makes it ignore it and then it works if you provide a “int main()” in your sketch
3) Some Arduino base libraries
C:\arduino\arduino-1.6.4\hardware\arduino\avr\libraries (eg EEPROM, Wire)
4) Bootloaders are here
C:\arduino\arduino-1.6.4\hardware\arduino\avr\bootloaders\atmega
**************************
So far so good. I have compiled the bootloader to include the watchdog code and it works great.
Now I am missing the link to other CPUs. How would this system support an ARM or an Intel for example.
As I was typing this, and it is a shame to delete it now all, I have discovered the 1.6.4 IDE allows me to download “support” for other CPUs. So I went ahead and downloaded “Arduino SAM boards using ARM”, it downloaded 500MB !!! in “C:\Users\akis\AppData\Roaming\Arduino15” (seriously? in Roaming?…) but I have no specific board to try it on. The IDE refers to it as DUE. I do not even understant what that means.
Any explanation how it all works greatfully needed! Thanks
The installation of the ARM compiler in roaming under Windows make the compiler “user”-centric rather than global. Versionn1.6.1 did not do this. But Arduino is now fragmented … the 1.7.3 version I use is at arduino.org
A number of dedicated members worked for months to get the specifics down as to what must be done to fully support different uC architectures while making that seamless to the Arduino GUI. User Roger (who hosts this web-site) coordinated changes and implemented many changes personally and was central in getting the old Leaflab’s pre-1.0 core upgraded to where it is today.
As you probably know, the Arduino GUI scans the file system when it is executed… that is the delay that is so obvious during opening. User libraries are located and remembered (why we must close and re-open Arduino after adding downloaded libraries) but also during this scan, profiles for 3rd party boards are scanned under the \User\Documents\Arduino\hardware folder. the boards.txt files must be correctly formatted to be added to the GUI menu. As the GUI stores this info during the time the frontend is active, it “knows” how to use the core, libraries, and include files. Much of what needs to be known is here
https://github.com/arduino/Arduino/wiki … cification
Essentially what we do is work with the existing libraries and make changes so they support tge STM32 family of chiPs. These libraries are stored separately from the downloaded libraries in …\Arduino\libraries but in the future, authors may incorporate STM32 specific code directly in the library to support the STM just like Due is being supported today. It just takes a little time for the author to do, but means they need a test platform first…. that is why getting the core files working first was job #1.
I understand that a number of uC are supported under the Arduino GUI umbrella, including chips from manufacturers TI and the ones listed here: http://playground.arduino.cc/Main/Ardui … AtmelChips and of course, the STM32 family which is repressented here and other locations across the Internet. In theory, any of these chips could be used under Arduino if cores were developed:
http://en.wikipedia.org/wiki/GNU_Compiler_Collection
Much of what the Arduino GUI does is “smoke & mirrors”… it sits on top of the real GCC tools that compile and link. While a significant achievement, many Arduino users forget that everything done by Arduino can be done some of the other GUI systems that support an Arduino plugin: for example, Eclipse: http://en.wikipedia.org/wiki/GNU_Compiler_Collection
Another thing many Arduino users forget is that the Arduino language http://en.wikipedia.org/wiki/GNU_Compiler_Collection is really just c/c++ code that has been written to perform the lower-level functions necessary. While not technically correct, one can envision these Arduino-centric language commands as “macros” that are executed that then perform other native functions. Many people simply grow out of the Arduino umbrella and move on to pure C, C++ for increased efficiency and speed.
If you decide on moving some code to the STM32 from the AVR 8-bit processors, I think you will find that the bulk of the Arduino commands do work; especially all of the pre-1.0 commands. There may be some rough edges that need polishing but we have some great members here that will want to resolve anything you find wrong with the core command set. The libraries, however, are a completely different matter – ports are being done as we can get to them and are often selected by the working members themselves to support their own projects. Much work is done, much needs to be done. There is a section in the forum for requests to port a specific library – the emphasis on the word “request” as time is the enemy here. What I am trying to say is that you are the only one that can decide if STM32 under Arduino is right for you and your current need. But the investment is very small, as small as $4 U.S.D. and therefore the risk is small, too.
Ray
But thinking deeper I am not sure that it is important to be able to cross compile Arduino sketches into ARM or other platforms. The Arduino IDE is not exactly great and I have no love affair with the Arduino libraries. For most external hardware I write my own libraries anyway. All I need is a C compiler.
So what I am saying is I would be happy with an “X” board using a “Y” CPU which comes with its own IDE and does not need a 1 million dollar “development board” to be able to work, it should be able to program the target chip through things like FTDI or similar. Cheap and cheerful.
“core”: the STM32 series: for example, all F1 series begin with STM32F1xxx, the F4 with STM32F4xxx. Currently the F1 series are full supported, next one will be the F4-series (I guess so
)“variant”: It’s a container of more specific things:
a) the MCU: more specific to series, for example: STM32F103RBT6 or STM32F103CB, STM32F103C8T6
b) the physical dev board: pinouts, special usb circuit for bootloader mode (“maple mini”), specific LED on pin xyz, upload method (serial, ST-link, native bootloader mode), number/pins of I2c, SPI, USART…
So with “variant” you can create you own specific board related to a series.
There is a common miss conception that all ARM based processors are basically the same, however this isn’t the case.
What the ARM processors have in common, is just the assembler instruction set, e.g the things which move numbers from register to register, add, subtract, multiply, jump, look, store things in memory etc
However every microcontroller with an ARM core, can have completely different ways to physically access the GPIO (e.g. setting individual pins to HIGH or LOW, or sending data using the SPI protocol etc etc)
So although for example, the Arduino Due and the STM32 both have an ARM core and can use the same compiler, all the code that controls access to the hardware inside the chip is completely different.
So if you found another device that had an ARM core that you want to write using the Arduino IDE and the ARM compiler, you would need to write thousands of lines of code to support the specific hardware on that device.
Some manufacturers release the source code to make this a bit easier, as they standardise the lower level functions into a higher level API, but this API is not the Arduino API.
What the Arduino IDE uses, is the “Wiring” API, so you would need to write a wrapper between the Arduino API and the hardware, as well as writing loads of other start-up and memory management code specific for the processor in question.
If you want to write your own core from scratch, I’d suggest you put a several months of your life aside to do it, and contact some like Paul @ pjrc who did it for the Teensy, or Avik De, who has done an F3 implementation, as I’m sure they can elaborate on how tough a job it is
So my recommendation, if you want to mOve forward, is to order At least 2 of the Maple Mini boards; from eBay or AliExpress… there are separate threads here in the forum about experiences with eBay and experiences with AliExpress. Those 2 threads talk about vendors, costs, shipping, etc.
The Maple Mini is similar to the Pro Micro: it is programmed and debugged over USB. It has an onboard 3.3V regulator as the chip is 3.3V but a number of pins are 5V tolerent- so for most projects, level-shifting is not required. Most sensors have gone to 3.3V anyway and GLCD and OLED displays are 3.3V.
Do some research, check out some of the projects, and ask questions here if you need to… If you write your own libraries, you will be right at home – there are plenty of examples to examine snd only a few changes are usually required; excepting assembly instructions.
Ray
If you install multiple copies of libraries, it appears that the ones in your personal libraries trump those in the hardware folders.
For example..
Multiple libraries were found for "RTClock.h"
Used: /home/ahull/Arduino/libraries/RTClock
Not used: /home/ahull/PersonalApps/Arduino.cc/beta/arduino-nightly/hardware/Arduino_STM32/STM32F1/libraries/RTClock
Unfortunately the user libs always override the stm specific ones.
I have asked the IDE team about this on several occasions, but they tell me its definitely the way that everyone wants it to work.
Their reasoning is that the libs are “user” libs and hence must be a replacement for any of the default libs that are supplied
I suppose it kinda of makes sense, but without the option to add AVR libs to the AVR hardware cores folder, it is flawed logic IMHO
I ended up renaming OneWire to OneWireSTM to get around that problem, but its not an ideal solution.
However at the moment, third party hardware doesn’t seem to be the IDE teams priority
I suppose it kinda of makes sense, but without the option to add AVR libs to the AVR hardware cores folder, it is flawed logic IMHO
I’m not sure if the library properties has any bearing on this. We have them for a lot of our libs, but I don’t think it makes any difference.
The IDE Dev guys told me there is no way to stop the Users Library folder overriding the hardware libs
