Also added some documentation relating to running STM32CubeMX on OS X and guidelines for setting up new CubeMX projects.
This distribution also includes a few example sketches collected from some of the threads here on http://stm32duino.com.
Currently the generic blink sketch has been tested with the Nucleo F1, Nucleo F4, and the F0 Discovery.
Serial stream writes seem to work on the Nucleo F1 and Nucleo F4 through the CDC device on the STLink-V2.1
The F0 board requires a bridge to a serial monitor as the STLinkV2 does not enumerate as a CDC device. The datasheet DM00050135.pdf which relates to the F0 board has suggested Arduino mapping. While outside the cores normally discussed here on Arduino for STM32 the advantage of using HAL and a common low level API.
An added bonus on the Nucleo F1 is the F1SerialStats sketch which was posted here some time ago. This shows the ram size and a unique Id when run on the Nucleo F1. On the Nucleo F4 it just returns 0xFF values. Not sure where these pointer values come from. There is a lot of docs to read just to get this far.
The real power of using the HAL low level access is that the API can be called directly inside the sketch. Several examples are in this distribution. By using CubeMx to configure the peripherals, these are enabled and ready to access as soon as the Arduino setup() and loop () callbacks are activated.
Even though this branch is in early stages. I wanted to share the work with others. There is a lot still needed to get most of the basic example sketches to work. Many AVR sketches and libraries take advantage of direct hardware access. With this system it is better to let the CubeMx tool do the gruntwork.
I’m sure your core will be invaluable as we move forward.
I’ve played with the mcu/board Configurator and it’s really easy and fast to get an exactly setup for all the special needs.
As a side project I tried to get I2S working with the F1 series – without luck, because there is not even a skeleton in the libmaple api for this.
Furthermore there are a lot of up to date bugfixes inside the HAL drivers (i2c,spi…) so remember: The libmaple is about 3 years old and no one of the original developer is programming one line of code anymore.
So my hard verdict, especially for F103RC and up and every F2-F7: libmaple is dead and every further development is a waste of resources.
I have raised the issue about what core we should be using, on several occasions, but no one seemed interested in trying to write a new core until @sheepdoll got involved,
I did look at Koduino and MakerLabMe ( see my other postings), but neither of them were particularly usable as a whole, for different reasons.
I think Koduino has some libs, which could probably be pulled over and converted to @sheepdoll’s core.
And moving to a new core probably something that the community, needs to actively work on.
Unfortunately I’m really busy with work at the moment, on 3 or 4 simultaneous projects, and I dont have time to do much but maintenance on the current cores ;-(
Now every week a new cool board appears for even more less bucks on several platforms making it nearly impossible to create for each one a new “variant”. And for sure switching to a new core *must* be a community project but it will be necessary in the future to get all those STM32Fx under a hood. ST is going into the right direction with the licenses, so we should follow them….
…and BTW: the STM32cubeMX IOconfigurator is really a fancy tool
just how is the Cube generated code used?
to produce a skeleton for a variant or does it usage go further than that?
could the F4 code be back-ported to F1?
F1<==> F4 hardware, usart/adc/pin/spi/i2c/dac; is the F1 SPI different in some way from a F4 SPI ?
different in some way other than the physical pins & addresses?
do ports have ‘same’ set of register and usage mechanisms?
as the base generating mechanism is currently ‘Cube’,
can we replicate that functionality with open source?
should we?
to what extent?
alas one possibility is being locked into Cube, apologies for my u$ syndrome.
i’m primarily 103 based(TOTT) as i suspect the majority might be
with a couple of (x)nucleo’s and a 429 discovery (lcd one) on way.
stephen
Prior to the Cube, STM’s source code files for the F103 etc had a license which prevented re-distribution, hence why Leaflabs has to write their own core from scratch in order to keep it open source.
The one drawback with the with the Cube is that its a proprietary piece of software, and I’m not sure it runs on all OS’s
Actually, when I said the Cube generates re-usable code, this isn’t 100% true. The linker script files seem to have license issues, however I suspect this was an omission by STM i.e I doubt they intended to use non-redistributable linker files.
So for any core that is generated by the Cube to be effectively free of license constraints, the linker files need to be rewritten.
I found a replacement linker file for the F103 but have not found one to replace the F4 linker file.
So some clever person would need to write a new one for the F4.
java -jar SetupSTM32CubeMX-4.9.0.exe
installs under Debian 8, wants root though.
java -jar STM32CubeMX.exe from the right place seems to run happily
do i need to install the STM32Cube_FW_F1_V1.2.0 & STM32Cube_FW_F4_V1.7.0
directories somewhere or are they already embedded / installed?
my world turned red pill in the post, long 6-7 weeks
seems to be better silk screen printing than the blue & the baite, overhangs a bit on
each side as a result
no sign of the OLS as yet
stephen
I agree that STMs strategy in relation to open source and their licenses in general seems somewhat confused.
I posted to their support forum, about the license on the old standard peripheral lib, over 6 months ago, but didn’t get a response either.
But…
i don’t find TI etc much better when it comes to open source.
I’m working on some BLE stuff at the moment and TI’s BLE stack is closed source and they don’t support any open source compilers on their cc254x series BLE devices 
Which basically rules these devices out for any non large scale commercial development, as only companies with $$$$ to spend on the IAR compiler can effectively use these devices.
Likewise the new STM32F411 based wifi device, EMW3165, uses Broadcom Wifi SDK (WICED) which you have to register to download.
AFIK, The core lib on the ESP8266 is not open either; though there is no need to register to download it.
The GD32F103 docs require registration just to download them
etc
etc
Although I am not capable of rewriting the linker script at the moment, as i have no experience in this area; I think that this is a lesser hurdle than most other embedded stuff I’ve seen recently.
Hi Rickta59,
This issue is fixed with current SW4STM32 version available in AC6 site.
Code generated by CubeMX as well as the examples available in the STM32CubeXX packages will not contain such restriction sentence in coming versions.
-Mayla-
https://my.st.com/public/STe2ecommuniti … tviews=191
Sounds ok for me – or? (But we have to wait IF/WHEN it will happen 
)
I have raised the issue about what core we should be using, on several occasions, but no one seemed interested in trying to write a new core until @sheepdoll got involved,
I did look at Koduino and MakerLabMe ( see my other postings), but neither of them were particularly usable as a whole, for different reasons.
I think Koduino has some libs, which could probably be pulled over and converted to @sheepdoll’s core.
And moving to a new core probably something that the community, needs to actively work on.
Unfortunately I’m really busy with work at the moment, on 3 or 4 simultaneous projects, and I dont have time to do much but maintenance on the current cores ;-(
IAR (and Keil) are best of breed but free only up to 32KB of code.
Lots of experience with it and F4’s and IAR. I see that CubexMX now targets more compilers.
Arduino – for AVR and Teensy3. Time to move on. ST gives us HAL (or the depreciated Std. Periph. Libs) which is a big superset of what ARM M0/M4 people are trying to reinvent from regurgitated Arduino 8 bit stuff.
<…>
Arduino – for AVR and Teensy3. Time to move on. ST gives us HAL (or the depreciated Std. Periph. Libs) which is a big superset of what ARM M0/M4 people are trying to reinvent from regurgitated Arduino 8 bit stuff.
is it a question of how much arduino-i-ness needs to be retained?
is it worth proceeding at risk?
i can see a declining ‘arduino’ set, the switching from 328p in an uno to a stm32 didn’t work
for the maple(ok, prob it wasn’t just that), i was never tempted or thought about switching except
maybe to a mega. (following the brand maybe)
then again i’m used to linux and new hardware, wait a bit and it’ll start working:-)
for me, i’d proceed at risk, next question is
can it be done in such a way that even if ST back tracked it wouldn’t create a problem?
stephen
Sounds ok for me – or? (But we have to wait IF/WHEN it will happen
)is it a question of how much arduino-i-ness needs to be retained?
is it worth proceeding at risk?
<…>
can it be done in such a way that even if ST back tracked it wouldn’t create a problem?
stephen
I guess I should have checked back, but I thought I had heard the final word.
Thanks,
-rick
is there a way to leverage what has been learnt in ‘getting F103 to functionality’ in the move to HAL?
currently is it rather simplistically from clicking on ‘compile&link’ :-
‘arduino’ => generate code for each device/variable, setup and loop => compile & link against the std lib’s & ‘our wrapper/version of ‘libmaple’ => hex
is our wrapper/version of libMaple wrapper the current ‘HAL’?
where does ‘CubeMX/CubeFX’ fit in?
can’t see it being ‘called’ on switching device to generate boiler plate as required?
is it to be used outside of ‘compile&link” to generate boiler plate source ( maximum functionality for each stm32FXXX) to be inserted at the generate code stage, the linker will then simply ignore unused code?
is CubeMX in effect equivalent to <CubeF1xx+CubeF2xx+ … +CubeFnxx>
stephen
I’ll try to compose a long answer to these complex points at the weekend.
But here are a few points to bear in mind in the meantime.
IMHO creating a full new core including the core libraries is non-trivial. Several other sites have tried it, with only limited success.
I’d recommend you read my postings on the 2 main alternative Arduino cores for STM32 (i.e MarkerLabMe and Koduino), and take a look to see if you think these are suitable for what you want to do.
Personally, I feel that moving away from Arduino / Wiring compatibility, is not a good idea, this includes compatibility with existing libraries where possible.
There are plenty of other IDE’s and methods to compile code for the STM32 e.g. Eclipse, but beauty of Wiring is that people without a huge amount of programming skill can at least get something simple working, which may spur them on to greater things (not necessarily within the Arduino family)
Extending the Arduino / Wiring API e.g. to include some event driven stuff etc, would be useful as long as it doesn’t break any existing Arduino core functionality. e.g. We have already extended the SPI API to include DMA, as this has no impact on any existing code e.g. libraries as these are new functions.
I personally don’t have much spare time to help develop a whole new core, as I can guarantee you I will still get at least 20 questions a week either on this forum or github or directly emailed to me, which I’d be remiss if I didn’t at least answer by referring people to the forum.
I suspect most people are in a similar position with also work and home life, competing for their precious time.
Right, because this is what STM32duino stands for: Compatibility with the Arduino API.
Personally I think, leaflabs left a big gap in the libmaple: strange codings, like 3-4 different “spi.h” with the same name,…unfinished things like I2S, no real USB stuff like audio device, mass storage… and so on. Another point is, that libmaple has only a “real” support for STM32F1 series.
So my only real important question for moving to a new core:
When it’s done, is it easier to set up different series and models (like the new STM32F7) and reconcile them? So this would be the major benefit. We wont have to take care what’s on “layer 0” because i.e. cubemx+hal would do the job for us. (updates, bugfixes, new models/series..)
Another benefit could be, that’s more easier to convert all the other examples for STM32 found on the web, so STM32duino could be a “glue” for Arduino and the rest of the STM32 world.
I agree.
Leaflabs seemed to put in all sorts of non-compatible stuff into libmaple which made it harder to use their existing code, e.g. calling Serial , SerialUSB, just because it was via USB. I know at the time there was no precedence like the Arduino Leonardo, but even so, it seems an odd decision.
… And a whole load of other things.
As far as I can see, the key is compatibility with existing code, especially libraries.
Actually, now I come to think of it…
I have been testing Victor_pv’s PIN_MAP in flash code, and I think its stable enough to merge into the Master of the repo. Actually its not all the const stuff thats really in RAM, its just a bunch of pointers to the GPIO dev structures, but it looks like it may solve the issues of the libraries that attempt to use pinMode etc in their constructors, and it doesn’t appear to have an adverse effects, so I may as well merge it at the weekend. and if it needs more work, e.g. pulling the referenced structures into Flash as well, we can do that afterwards.
BTW. On a related note. The HAL based core is only going to work for STM32 based processors, its not going to work for the new GD32 processors, because GigaDevices doesn’t have a tool like the STMCubeMX (well I don’t think they do). They have a CMSIS and possibly a Standard Peripheral Lib, but I don’t think its a HAL SPL (though I’d need to double check)
I’m not sure whether GigaDevices are going to be a major player, but their F103 line is faster and cheaper than the F103 line, and GD also do a F2, and I guess its possible they may license the F4 at some time (who knows)
I wonder whether its worth considering how, if at all, it would be possible to have a HAL type core for GD32 as well as STM32 ???
Skimming their website, I see documents too terse and not in acceptable for for English-speakers.
what’s the attraction of the GD32 based boards (not chips)?
Strangely, the GD32F103 has a spec’ed max clock of 108Mhz, but now that I have one of these boards and am trying to get the USB working, it looks like you can’t run it at 108Mhz and have USB.
This is because the it would need a USB divider ratio of 2.25 but it only had divider ratios of 1, 1.5, 2 and 2.5
So to use USB, you can only run the GD32 at 96Mhz and be within spec, or run it at 120Mhz (11% over clocked) and use the 2.5 divider.
But at the moment I think I must have screwed up the PLL settings as I can’t get USB to enumerate at all, even on 72Mhz (div 1.5)
Thinking about it, I wonder why they’d implement a USB divider of 2.5 unless they thought they’d be able to run the GD32 at 120Mhz, but perhaps in production their yield was not good enough to guarantee 120Mhz over the published temperature band, and hence they say they can operate at 108Mhz
But this is just speculation on my behalf
I did look a bit at what the Due was doing with CMSIS. This CMSIS beats against the CMSIS used in things like Koduino and I think the AreoQuad F4 cores. If GD32 is a separate product, then we should treat it like NXP and TI (Outside the scope of these cores.)
My impression is that wiring and processing are basically front ends to 8bit AVR and atmel style peripherals. So the core basically has to emulate Atmel GPIO etc. This is more straightforward in the Due as there is overlap in the way the peripherals are initialized.
Back in 2012 ST made an attempt to provide some simple “Arduino” libraries for the F0. gpio, serial, and spi. I have been reviewing these. I sort of have a fuzzy recollection attending a seminar about this. At the time ST was pushing the IAR and Kiel toolchains, so the code is written in the same style, but using the wiring/processing function names. The resulting code is next to unreadable.
The real heart of any Arduino core for Cortex is to create the mapping of the pins to what the Arduino user expects them to be. This in turn makes the pin mapping the critical issue. Under maple, this invokes direct access to the register structures (as that is the way it is done in Atmel variants.) This falls apart between F1 and F4 as the CMSIS names differ between the families. With just enough commonality to be confusing.
Then to add sauce to the goose ( I think that is the old expression) One has to deal with small pin devices compared against large pin devices. (Probably why ST came up with Cube.) This means that the pin mapping structures really need to be mutable, as the user expects the resulting device to act as the Atmel AVR would, with dynamic register configurations on the fly. (On AVR I tend to turn LEDs On through the DDR register switching between tristate inputs, and 0 state current sinks.) If I need a second SPI or serial port, I bit bang it. For extended shift registers I use cascaded timers and interrupts. I suspect all this can be done in STM32, with different syntax and mindset.
AFIK, I thought that the devices were pin compatible and had very close software compatibility. i.e @jaconson999 has been running his using the existing generic STM32F103C core, and only had to change the defined for the delay() stuff.
He’s managed this because the board that is on Taobao (which I now have in abundance – thanks to a screwup in the ordering on my part), uses a 12Mhz oscillator / crystal, so the PLL settings are the same i.e 9 x 12MHz = 108Mhz instead of 9 x 8Mhz which gives us the 72Mhz for the STM32
However I can’t get USB working …. And it looks like the GD devices don’t support USB when they are running at their max clock (as they are lacking the correct clock divider option (2.25) to facilitate this… Anyway I won’t cross post
Hi Guys,
Now that I have your attention (BY SHOUTING ….
I think it would be best if I put the HALMX core in a separate repo, as the existing repo is fairly large already, and ideally should have been split into F1, F3 and F4 ages ago…….
I have another GitHub account for stm32duino.com, so I think it would probably make sense if I took Julie’s core and created a new master copy in the github stm32duino account.
Probably the best way to do it, is to separate the library into its own repo, and the tools into another repo, and then have one master repo that has the halmx core and the tools as submodules.
Or can anyone think of a better way to do it.
I’ve also been working out how best to support the Arduino Boards Manager packaging requirement (for future deployment) and had considered splitting the tools into tools_win, tools_linux and tools_osx and possibly tools_source, as the Boards Manager needs separate packages for tools for each platform (well ideally it does, to save Linux users downloading exes they don’t need etc etc)
But one other option is the GitHub “Releases” system. I’ve not used it before, but I have seen release scripts.
So this may be a better way to handle tools deployment for each individual OS.
The other question is libraries.
I presume that an SPI lib written for the HALMX core would work on F1, F2,F3, F4 , F7 etc, but I’m not sure if this is guaranteed, and whether we’d still need to split things up.
E.g. I’ve noticed for example that the GPIO speed settings on an F1 and F4 are not the same. From what vaguely recall the F4 has more GPIO speed granularity than the F1, and it uses different defines for some speeds.
So care would need to be taken when writing libs etc where the HAL seems to differ between series of devices.
I’m going to try to get to grips with the HALMX code in my repo (which is a copy of SheepDoll,s repo).
Currently I’m unsure of whether the initial selections in the CubeMX make any difference to use, apart from processor selection.
e.g. In the cube you initially need to specify the number of USART channels you want to use, as well as the number of Timers, SPI channels, I2C devices etc etc.
Then in the second stage of the CubeMX configuration, I think you need to make sub selections because of pin allocations for each of the functions, as most pins have multiple functions, and some Timers are dedicated for specific purposes, hence if you enable a specific function, the CubeMX shows some Timers in red to indicate they are no longer available for general use.
However I’m not sure if any of this matters to us, i.e whether this is just used to configure what initialisation code that the CubeMX generates.
I suppose what we need is a generic set of instructions that will let us generate the HALMX files for all the processor variants that we need.
(I think this information is in a posting in the forum, but it needs to be in the wiki for the repo)
In addition, I suspect we will probably need to modify some of the files, either manually or using a script. For example, to use a bootloader, the VECT_TAB_OFFSET which is defined in one of the CMSIS headers as 0x00 needs to be changed to be externally defined.
Ideally the CubeMX would wrap this in #ifndef, but it doesn’t in the code in the repo (but I’ll need to take a look at the latest files I’ve exported from the CubeMX just in case STM have improved this).
And of course we need to change main.c to add the calls to setup() and loop() in main.c
Overall, I think we need to start to try this repo, in order to understand what we still need to do
https://github.com/rogerclarkmelbourne/ … _setup.txt
and
Would you folks like some assistance?
steve
Yes. I suspect we do need some assistance
I’m just not sure of what assistance we need at the moment
Perhaps you’d like to have a go at running the HAL MX Core https://github.com/rogerclarkmelbourne/ … ino_STM32/
Getting USB to work on the F103 would be the first thing I think we’d need to do, as not everyone has STLink.
Then we can use the existing bootloader to upload (after we’ve worked out the best way to change the CMSIS vector table offset value to move the start offset to 0x2000 (i.e start address of 0x8002000)
To work with the bootloader we’d also need to work out how to monitor the DTR and chars on the USB Serial, as the existing code uses a special sequence to trigger a reboot of the processor (into the bootloader)
To calibrate me…
Do I understand the goal of HALMX correctly…
HAL = ST’s HAL libraries that replace the SPL (standard peripheral libraries). For STM32F1xx and F4xx?
MX = ST’s CubeMX tool. Yes? With CubeMX, an advanced user, perhaps on behalf of beginners or people who want to take a board and the matching CubeMX config. as below, but pre-configure for that type of user. The advanced user’s method is…
- choose the STM32 chip and package type. Or you start with a given/prior CubeMX configuration and alter it to yield a new different one for the current project.
- choose the on-chip peripherals needed for a certain app. This is independent of how the MCU’s pins are wired to any PC board or breadboard. You setup the default system and bus clock modes and dividers and the PLL, using the graphical user interface.
- For each needed peripheral, you tell CubeMX (via the graphical user interface) what peripheral is mapped to what pins on the MCU’s package (still, not board specific).
- Then for each peripheral, you configure all of its modes and options, e.g., clock speed of SPI, baud rate of UART, GPIO in/out/pullup, external interrupts, etc.
- Configure the desired modes: polling, interrupt, DMA and other details for each peripheral that you config. And so on. This all done, you choose the target compiler (IAR, Keil, GCC and avoid what the IDE is).
- Then tell CubeMX to GENERATE PROJECT for the target compiler/IDE. It generates the code to configure the system clock dividers and the PLL. It gathers all the HAL code needed to satisfy the chosen peripherals.
- It generates code to initialize each peripheral in the chosen modes. It creates interrupt handlers for each peripheral, with optional call-backs to the user app. It creates a main().
- You code into main() whatever. setup() is not needed for I/O initialization. loop() is within main() that you alter to suit.
From here is where it gets fuzzy for me. Are Arduino’s IDE and its GCC compiler command lines incompatible with the above? Arduino’s concept of parsing all the .c and .cpp files to auto-generate function prototypes may be contrary to CubeMX and HAL which use traditional .h files. The necessary .h file #includes are auto-generated by CubeMX.
As to board-specific. I did one project where I used CubeMX and HAL and wrote code for some of the wiring calls (digital.write/read) and interrupt vector establishment (attach interrupt). I did that with the “weak” tribute that CubeMX uses for interrupts and other calls – so these weak-functions can be overridden by you by coding a function of the same name, in C (not C++ overloading).
All if this is in C. No C++ required. But can be used. No use of a heap, but can be used.
For me, I’ve moved on from the Arduino libraries since they are a buggy and small subset of what is in ST’s HAL. Freescale has a lesser but similar HAL and CubeMX equivalent.
Doing so, I have been able to focus on the app, not writing drivers and I/O libraries, avoid open source but incompatible myopic libraries, and so on Arduino’s libraries are, due their AVR heritage.
==========================
I was able to take the above and integrate the big RadioHead protocols… written for Arduino but substitute HAL libraries for Arduino libraries, targeting STM32F. To include SPI, pin change interrupts, timers, micros(), and so on. This suite of code is heavy C++, but made compatible with a mix of C and C++ HAL and user code.
This says the Arduino IDE gets replaced with a conventional IDE (no .ino, use ordinary methods). These IDEs might be Eclipse (non-intuitive), Free Windows-only VisualMicro+Visual Studio Community edition), VisualGDB or ye ole makefiles for those that prefer that. IAR and Keil are there, but free only for 32KB projects. I’ve used IAR for years (professionally).
OK… is this the goal for HALMX_arduino? I guessing the answer is no. But for me, projects are done much faster with CubeMX and the vast amount of supported code in HAL. (happily, I rarely have to look inside of HAL’s code) .. just the APIs.
Have you taken a look at the rough documentation text files I placed in the HALMX_Arduino_STM32 lashup I provided Roger? There are direct links to these, which Roger is placing in the project wiki.
The goal of all this was to make something that could be setup quickly and be understood by someone with one of the Arduino primers. A number of us are using *nix systems, OS X, Linux rather than window$. The alternative for non M$ users is to use eclipse.
I use a similar method to your advance user outline. In my case I am focused on the Nucleo, and discovery kits. I choose these from the board setup. Configure and map the pin functions where there are conflicts with the more expected functions. Then generate the code for the GCC compatible Systems Workbench.
There does not seem to be any issue with the use of the traditional .h file under the Arduino IDE. The Arduino compiler is just GCC, the board.txt file in coordination with platforms.txt setup the GCC compiler options. the .ino file can contain any HAL API callbacks as the .h files are included through these scripts.
The goal was to sort of “float” the arduino API on top of the HAL API. Most of this has been done by using simple “glue” code and some defines where the functions were virtually the same. So far the only hooks I have needed are in main.c and main.h. Like you, I rarely look inside the HAL code, I do however refer extensively to the .pdf that describes the API. I also find that the examples contained in the STMCube/repository “Firmware” examples folder to be most instructive. See the examples folder in the HALMX_Arduino_STM32, where this was done to do a blinky and a simple serial sketch.
I like to use git to contain the CubeMX .ioc, I was reading on the STM forums, that someone else though this is a good idea. This way it is easy to create new variants as branches. It is also good for rolling back the auto generated code if something breaks. I use a differencing editor, git provides this same information as part of the git status reports.
One big difference between STM and Arduino approach, that may also lead to some of the fuzzyness is the way that the code is loaded onto the silicon. I come from the 8051 and AVR worlds, and prefer jtag dongles to do the upload/debug. There does seem to be a desire to make the bootloader work as it does, transparently on an Arduino through the DFU CDC. That seems to be where some minor changes to the CMSIS core might need to be changed, to allocate the boot space.
I found no problem with the linker script for IAR – but I edited it to avoid using some areas of flash so I can use that for read-mostly memory, like 64KB since the ‘415 has 4x16KB and the rest of 1MB is 64KB sectors.
I’ve found only two or so bugs in the HAL drivers – and they are for esoteric drivers (half duplex mode of UARTs).
The app I have is about 35 C files, all the HAL libraries for
UART half duplex; UART normal full duplex, both interrupt driven, one at 250Kbaud, the other at 115K
SDIO and FATFS, 16GB uSD, DMA for both read and write
Two SPI channels, DMA
External pin interrupts
two timers
systick 1mSec (built into HAL)
The HAL drivers are actually wrappers on the SPL drivers.
I download the HALMX_Arduino_STM32. and get some error with build Blink sketch at arduino ide 1.6.5.
below the error message:
C:\Users\booker\AppData\Roaming\Arduino15\packages\arduino\tools\arm-none-eabi-gcc\4.8.3-2014q1/bin/arm-none-eabi-ar rcs {archive_file_path} r:\TEMP\build2787883865254039219.tmp\WString.cpp.o
C:\Users\booker\AppData\Roaming\Arduino15\packages\arduino\tools\arm-none-eabi-gcc\4.8.3-2014q1/bin/arm-none-eabi-g++ -Os -Wl,–gc-sections -mcpu=cortex-m3 -TC:\Users\booker\Documents\Arduino\hardware\HALMX_Arduino_STM32-master\HALMX\variants\MXBluePillF103C8/SW4STM32/MXBluePillF103C8/STM32F103C8Tx_FLASH_0x2000.ld -Wl,-Map,r:\TEMP\build2787883865254039219.tmp/Blink.cpp.map -LC:\Users\booker\Documents\Arduino\hardware\HALMX_Arduino_STM32-master\HALMX\variants\MXBluePillF103C8/ld -o r:\TEMP\build2787883865254039219.tmp/Blink.cpp.elf -Lr:\TEMP\build2787883865254039219.tmp -lm -lgcc -mthumb -Wl,–cref -Wl,–check-sections -Wl,–gc-sections -Wl,–unresolved-symbols=report-all -Wl,–warn-common -Wl,–warn-section-align -Wl,–warn-unresolved-symbols -Wl,–start-group r:\TEMP\build2787883865254039219.tmp\Blink.cpp.o r:\TEMP\build2787883865254039219.tmp\startup_stm32f103xb.S.o r:\TEMP\build2787883865254039219.tmp\system_stm32f1xx.c.o r:\TEMP\build2787883865254039219.tmp\stm32f1xx_hal.c.o r:\TEMP\build2787883865254039219.tmp\stm32f1xx_hal_adc.c.o r:\TEMP\build2787883865254039219.tmp\stm32f1xx_hal_adc_ex.c.o r:\TEMP\build2787883865254039219.tmp\stm32f1xx_hal_cortex.c.o r:\TEMP\build2787883865254039219.tmp\stm32f1xx_hal_dma.c.o r:\TEMP\build2787883865254039219.tmp\stm32f1xx_hal_flash.c.o r:\TEMP\build2787883865254039219.tmp\stm32f1xx_hal_flash_ex.c.o r:\TEMP\build2787883865254039219.tmp\stm32f1xx_hal_gpio.c.o r:\TEMP\build2787883865254039219.tmp\stm32f1xx_hal_i2c.c.o r:\TEMP\build2787883865254039219.tmp\stm32f1xx_hal_pcd.c.o r:\TEMP\build2787883865254039219.tmp\stm32f1xx_hal_pcd_ex.c.o r:\TEMP\build2787883865254039219.tmp\stm32f1xx_hal_pwr.c.o r:\TEMP\build2787883865254039219.tmp\stm32f1xx_hal_rcc.c.o r:\TEMP\build2787883865254039219.tmp\stm32f1xx_hal_rcc_ex.c.o r:\TEMP\build2787883865254039219.tmp\stm32f1xx_hal_spi.c.o r:\TEMP\build2787883865254039219.tmp\stm32f1xx_hal_spi_ex.c.o r:\TEMP\build2787883865254039219.tmp\stm32f1xx_hal_tim.c.o r:\TEMP\build2787883865254039219.tmp\stm32f1xx_hal_tim_ex.c.o r:\TEMP\build2787883865254039219.tmp\stm32f1xx_hal_uart.c.o r:\TEMP\build2787883865254039219.tmp\stm32f1xx_ll_usb.c.o r:\TEMP\build2787883865254039219.tmp\usbd_cdc.c.o r:\TEMP\build2787883865254039219.tmp\usbd_core.c.o r:\TEMP\build2787883865254039219.tmp\usbd_ctlreq.c.o r:\TEMP\build2787883865254039219.tmp\usbd_ioreq.c.o r:\TEMP\build2787883865254039219.tmp\adc.c.o r:\TEMP\build2787883865254039219.tmp\gpio.c.o r:\TEMP\build2787883865254039219.tmp\i2c.c.o r:\TEMP\build2787883865254039219.tmp\main.c.o r:\TEMP\build2787883865254039219.tmp\stm32f1xx_hal_msp.c.o r:\TEMP\build2787883865254039219.tmp\stm32f1xx_it.c.o r:\TEMP\build2787883865254039219.tmp\tim.c.o r:\TEMP\build2787883865254039219.tmp\usart.c.o r:\TEMP\build2787883865254039219.tmp\usbd_cdc_if.c.o r:\TEMP\build2787883865254039219.tmp\usbd_conf.c.o r:\TEMP\build2787883865254039219.tmp\usbd_desc.c.o r:\TEMP\build2787883865254039219.tmp\usb_device.c.o r:\TEMP\build2787883865254039219.tmp\_spi.c.o r:\TEMP\build2787883865254039219.tmp\variant.cpp.o r:\TEMP\build2787883865254039219.tmp/core.a -Wl,–end-group
arm-none-eabi-g++: error: r:\TEMP\build2787883865254039219.tmp/core.a: No such file or directory
Error compiling.
It looks like you may not have installed the g++ from the Due Boards manager. Run the Board manager and select Due. The arm-none-eabi tools are not installed by default.
The other issue is there seems to be some windows paths with the ‘\’ slash. Most of the HalMX stuff is developed on unix or linux. Windows is not really supported. The workaround would be to change a local copy of platform.txt where the unix path is being generated to use the windows ‘\’ separator.
-julie
bookerh wrote:Hi Roger:
I download the HALMX_Arduino_STM32. and get some error with build Blink sketch at arduino ide 1.6.5.
below the error message:
…
arm-none-eabi-g++: error: r:\TEMP\build2787883865254039219.tmp/core.a: No such file or directory
Error compiling.
Thank you for your reply. I forgot to install the due package.
I try that again.
Thank you, sheepdoll .
