Starting with ARM Cortex-M - Page 1
Forum section: electronics / general

author: illusive
author_rank: Regular Contributor
timestamp: November 07, 2016, 02:16:27 pm
content: Hello everyone!I want to start learning ARM microcontrollers, writing code, using them in projects and so on, but i'm a bit confused how to start. My background experience is with AVR's. With them it was easy, tons of organised tutorials, videos, books and forums. I'm browsing the internet for several days now and i still can't even figure out what does it takes to program an ARM chip (i mean what programmer, are there any official ones like with AVR). I figured out the basic stuff, that the ARM just develops the architecture and then different vendors fabricate the IC's. I learned about the different ranges of processors - Cortex-A, Cortex-R, Cortex-M. For my current needs i think that the basic Cortex-M family will be more than enough and will be a good starting point. And from here on out i am in a crossroads.It seems that every vendor (ST, NXP, TI) has its own development tools, chip variants and so on, which is really confusing for me. I need to choose one and stick to it at least in the beginning. I'm leaning towards the ST Cortex-M0 chips, because one of my favorite youtubers (Patrick Hood-Daniel) has started a series about them and my local electronics suppliers are well stocked with a variety of them.What can you recommend for a complete beginner with ARM microcontrollers?Starting with a book maybe? I have found one called "The Definitive Guide to ARM® Cortex®-M0 and Cortex-M0+ Processors". Are there any ARM-related forums like AVRFreaks for AVR?Thanks for your time!

author: shebu18
author_rank: Frequent Contributor
timestamp: November 07, 2016, 02:36:47 pm
content: Hello,I would recommend a STM32F103 nucleo board (the programmer is integrated) and you could use Atollic TrueStudio as the IDE. This is the setup i am currently playing on.You can start with a blink and work your way up.

author: sambran
author_rank: Contributor
timestamp: November 07, 2016, 03:27:06 pm
content: Hey,The ARM eco system is quite large so I recommend getting your hands dirty with whatever dev board is easiest for you (ST is as good an option as any other) to get and figuring out things as you go. Most dev boards have a debugger built in so you don't need to worry about it at this point.The main difference between the various vendors is the peripherals available. Each vendor does offer proprietary dev tools but there are third party tools that support most large vendors.I did not read the book you mentioned but if it is anything like the one for Cortex M3 and M4 then I would not recommend it as a getting started book.EDX has a free coursehttps://www.edx.org/course/embedded-systems-shape-world-utaustinx-ut-6-03xwhich uses TI boards, IMO it is pretty good.Emedded.fm has a series of blog post on the ST Discovery boardhttp://embedded.fm/blog/?author=56b8dd4360b5e9ab3bbfc486, you might find them useful.

author: andersm
author_rank: Super Contributor
timestamp: November 07, 2016, 03:45:37 pm
content: There's a ton of threads on this forum asking the same question, I doubt anyone has anything new to add this time around. I've read the Cortex-M3/M4 version of the book you mentioned, and while I thought it was good, you have to understand that it is generic - ie. you will learn all there is about the Cortex-M0, not the ATSAMD21 or whatever.

author: newbrain
author_rank: Super Contributor
timestamp: November 07, 2016, 04:29:36 pm
content: Quote from: andersm on November 07, 2016, 03:45:37 pmJust a small selection, what I could find quickly, i.e. recent or where I posted a message:https://www.eevblog.com/forum/microcontrollers/which-board-to-buy/https://www.eevblog.com/forum/microcontrollers/where-to-begin-stm32f0-vs-pic32mx-vs-msp432-vs/https://www.eevblog.com/forum/microcontrollers/so-how-do-you-even-start-working-with-stm32-without-paying-an-arm-and-a-leg/https://www.eevblog.com/forum/microcontrollers/arm-cortex-development-board/https://www.eevblog.com/forum/microcontrollers/arm-starting-platform/Many different opinions and points of view.I'm partial to cheap ST Nucleo boards, but cannot advice much on learning process:I only use datasheets and technical references by now, and of course some googling.See the threads above for various free, cheap, expensive, and outrageous (for hobby use) development environments.

author: Jeroen3
author_rank: Super Contributor
timestamp: November 07, 2016, 04:58:26 pm
content: Quote from: newbrain on November 07, 2016, 04:29:36 pmHard. Peripherals are more complex, which is good, but this means there will be implicit details that you'd need to do. Such as some IRQ flags must be written 1 to clear, others 0.Their ST Cube MX HAL code generator makes it somewhat faster. But you'll get a huge mess of complicated code you'll need to sort trough before anything useful is running.It took me two days to get the two ADC's in an STM32F103 working with timer trigger and DMA. But that's a complicated example.A nucleo with the mbed environment is a good place to get your feet wet. But beware, mbed was designed for an LPC1768, and has since exploded. But not all features went platform hopping.

author: zapta
author_rank: Super Contributor
timestamp: November 07, 2016, 05:00:11 pm
content: Two suggestions1. Prefer a board/mcu that is supported by mbed.2. When considering mcu/vendor, consider also the development environment, not just the hardware. Some are easier to install and use then others.When I was in your situation I ended up with LPC11U35 and LPCXpresso. YMMV.

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: November 07, 2016, 05:01:24 pm
content: The development tool that I recommend is Segger Embedded Studio. It's free for non-commercial use and has no code size or optimization limits. It's fast and lean compared to some other tools out there (such as Atollic) as it's a derivative of Rowley CrossWorks. It does require a Segger J-Link debugger pod, however, either a genuine J-Link or J-link firmware loaded on one of the supported debuggers such as the NXP LPC-Link2 or the ST-Link/v2.You can get a genuine Segger J-Link EDU for USD$60. The LPC-Link2 and the ST-Link/v2 are around USD$20.https://www.segger.com/embedded-studio.html

author: nctnico
author_rank: Super Contributor
timestamp: November 07, 2016, 05:03:08 pm
content: I'd definitely look at NXP's LPC series of ARM processors. Their peripherals are way more consistent and easier to deal with than the ones from ST so you don't have to rely on a crappy peripheral library.Reading a book about the core isn't very helpfull unless you are going to build a compiler for it.

author: illusive
author_rank: Regular Contributor
timestamp: November 07, 2016, 05:16:27 pm
content: Can't i just buy the bare microcontroller, hook it up to a breadboard and a programmer and use some IDE to program it? I have always liked that approach with the AVR's, it gave me freedom, program the chip and then stick it in the project i need it for.

author: farsi
author_rank: Regular Contributor
timestamp: November 07, 2016, 05:21:14 pm
content: ARM Cortex M is an instruction set - the compiler (e.g. gcc-arm-none-eabi should take care of translating C to byte code that the CPU can understand). The hard thing indeed is to understand the drivers of peripherals as well as memory mapping of that. And, since you buy your supper at two restaurants (ARM and ST or ARM and NXP), it can taste a bit funny the first time.

author: nctnico
author_rank: Super Contributor
timestamp: November 07, 2016, 05:22:18 pm
content: Quote from: illusive on November 07, 2016, 05:16:27 pmOfcourse you can. That is what I mostly do (based on the schematic of an evaluation bord) but that also involves getting the board right and an ARM controllers will need a dual layer board and a good layout (almost solid ground plane and good power supply decoupling). You'll need some way to program the controller when it is soldered onto the board though. IMHO NXP has a neat solution for that through their serial bootloader and a tool called Flashmagic which also allows reading back the memory including RAM. Another way would be to bring out the SWD pins and use an SWD dongle but it depends on your workflow whether you want that or not.

author: zapta
author_rank: Super Contributor
timestamp: November 07, 2016, 05:24:29 pm
content: Quote from: illusive on November 07, 2016, 05:16:27 pmAssuming that 'breadboard' doesn't mean 'solderless breadboard' and that you are willing to use SMT package breakout boards (cheap on ebay) than yes, you can.Here is my standard 'simple' M0 design and you don't even need a programmer to program. It mount itself to your computer as a usb disk drive to which you drag your compiled file.https://github.com/zapta/arm/blob/master/pro-mini/board/arm-pro-mini-schematic.pdf

author: rstofer
author_rank: Super Contributor
timestamp: November 07, 2016, 05:29:14 pm
content: I have used various incantations of the LPC2106 and LPC2148s from Olimex. They are quite good but pretty much obsolete.https://www.olimex.com/Products/ARM/NXP/LPC-H2148/i almost always recommend the LPC1768 version of the mbed board. It's a great chip and the 'stamp' form factor make it easy to work with. You don't need to install a toolchain because everything can be done via the web. This makes it easy to do your programming from wherever you happen to be.https://developer.mbed.org/platforms/mbed-LPC1768/The STM32F4 series boards are also quite nice but the mbed has well debugged libraries that help speed development.

author: ajb
author_rank: Super Contributor
timestamp: November 07, 2016, 06:14:33 pm
content: If you've been using Atmel Studio with AVRs, then Atmel's SAM series will at least allow you to use a familiar IDE. Some of the XPlained dev boards are fairly inexpensive and have a debugger on board. Otherwise an Atmel ICE isn't too expensive and will program the entire range of Atmel MCUs. Or if you look around, I expect that there are third-party dev boards that come with a USB bootloader pre-installed. Isn't there an Arduino based on the SAMD21?One big downside to the Atmel ARM stuff is that there's isn't nearly as much example material around as, for instance, the STM32 series, since they're not as popular among hobbyists.As far as other IDE options, I've been using Atollic TrueStudio lately. The free version is unlimited, unlike the free versions of most pro IDEs that hobbyists tend to favor. It supports a wide range of parts, and I know that ST's code generator tool (CubeMX) supports it, which is helpful if you want to use their USB stack, etc.

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: November 07, 2016, 06:44:49 pm
content: Quote from: ajb on November 07, 2016, 06:14:33 pmAtollic would be a good option if it weren't so friggin' sluggish. I fail see how a company could have taken Eclipse and screwed it up so badly.

author: Brutte
author_rank: Frequent Contributor
timestamp: November 07, 2016, 09:39:10 pm
content: Quote from: illusive on November 07, 2016, 05:16:27 pmYou can, but there aren't many Ms in PDIPs.LPC1114, LPC800 ..As for programming - all Ms can be programmed by SWD. If the pin count is >32 then most likely it can also be programmed with JTAG (check datasheet). And if its memory size is >16k then most likely it comes with some kind of bootloader (check datasheet) via UART, CAN or USB (check datasheet).I'd pick some breadboard friendly eval.

author: Kremmen
author_rank: Super Contributor
timestamp: November 07, 2016, 09:41:47 pm
content: An earlier poster noted that much (too much?) has been said already on this subject. Nevertheless, my 2c worth:Unless you already made up your mind, maybe this is worth considering. ST Nucleo boards tend to be dirt cheap, ST has one of the largest selection of ARM Cortex M processors available so you are sure to find a chip to fit most needs. And as to the toolchain, there is a simple solution that works. Actually there are several, but why not go with the OpenSTM (http://www.openstm32.org/HomePage) SW4STM32 (aka System Workbench). It is the same Eclipse as most others but configured for the STM32'es out of the box. Together with the CubeMX HAL configurator and the ST Link/v2 programmer/debugger built into every Nucleo board, what's not to like?Some complain that the Cube makes hard to use and bloated HAL code. However, they may not have realized that you can directly import the Cube output as a new Workbench project with zero manual modifications and just stat typing your own app. And if you don't want the HAL layer, there will be/is a Cube version that supports Low Layer initialization. Or so the ST guys said (and showed) in a recent workshop.Nucleos also have Arduino compatible pin headers if that is something you can use.

author: illusive
author_rank: Regular Contributor
timestamp: November 08, 2016, 12:14:29 am
content: So, if i get a nucleo board (i like NUCLEO-F030R8, at this point i don't think i need any more features that it offers) i will be able to use the on-board ST Link/v2 programmer to externally program any other Cortex-M microcontroller from ST?

author: thm_w
author_rank: Super Contributor
timestamp: November 08, 2016, 12:57:54 am
content: Quote from: illusive on November 08, 2016, 12:14:29 amyep, or you can buy a stlink 2 clone for ~$3 too.

author: langwadt
author_rank: Super Contributor
timestamp: November 08, 2016, 01:01:13 am
content: Quote from: illusive on November 08, 2016, 12:14:29 amyes you just remove two jumpers and there is header with the SWD debugger signals

author: ez24
author_rank: Super Contributor
timestamp: November 08, 2016, 01:29:01 am
content: Book:https://leanpub.com/mastering-stm32746 pages and 80 % done ! The remaining 20% is additional topics, not on what has already been written aboutBook, board (Nucleo) and compiler for $99 and debugger for $50:https://imagecraft.com/

author: julianhigginson
author_rank: Frequent Contributor
timestamp: November 08, 2016, 05:49:27 am
content: Quote from: wilfred on November 08, 2016, 04:19:42 amFALLFREESHIPworked for me the other day...

author: julianhigginson
author_rank: Frequent Contributor
timestamp: November 08, 2016, 06:10:02 am
content: Yes I agree - OP could do a lot worse than an MSP432 eval board with the bonus TI optimised compiler license and free shipping. (FALLFREESHIP at checkout!)https://store.ti.com/MSP432P401R-LaunchPad-Development-Kit-with-Code-Composer-Studio-Promotion-P51093.aspxI'd recommend OP spending a little more money on some booster packs that sound interesting to them, because booster packs really open up what you can play with. sensors, motor control, displays, joysticks, wifi, all sorts of stuff - (just use the online compatibility tool to make sure any boosterpack works with the 432 launchpad.. because the launchpad/boosterpack covers a range of processor families, not everything is 100% compatible with everything else...)From there, you'd have the basic MSP432 support and training for CCS , specifically covering CCS and MSP432 and coming with examples that just run out of the box......http://processors.wiki.ti.com/index.php/Category:CCSv6_Training#Workshops_and_ModulesAnd when you feel like trying out other options, then atollic truestudio should also work nicely with the MSP432 launchpad board, using its built in debugger.. (actually, atollic will seem pretty similar, as it's also basically just eclipse)Also you have the TI web IDE that looks very interesting (I never tried it..) kind of mbed classic-like, but seems to allow debugging of the target attached to your computer, through the web IDE too...Once you've done that for a while, then it's time to pick a NEW platform (FRDM-k64F is pretty great I think. STM nucleos are also nice if much lower powered) and try that out.. noticing the subtle differences in free GCC toolchains (this is why you should try atollic!) and library code that different arm suppliers give you..

author: newbrain
author_rank: Super Contributor
timestamp: November 08, 2016, 10:45:14 am
content: I won't express my opinion on the quality of CCS and TI's driverlib, as I did already more than once.Just one caveat for the MSP432 board: the MCU IOs are not 5V tolerant, so if you have sensors, peripherals and what nots from your previous AVR experience, you have to be careful.STM32s, NXP LPCs and also other TI's offerings are.PSoCs can be powered directly with 5V, but they are not 5VT if powered with 3.3V.

author: illusive
author_rank: Regular Contributor
timestamp: November 08, 2016, 10:45:45 am
content: That is a good deal from TI, but i had already placed my order on NUCLEO-F103RB boardI decided to go with STM32F103RBT6 Cortex-M3 micro, it was even cheaper than the Cortex-M0 one, go figure.I expect that the code to program the different Cortex-M micros from ST will be the same, just occasionally change same pin number and register bit like with programming different AVRs?

author: newbrain
author_rank: Super Contributor
timestamp: November 08, 2016, 11:43:24 am
content: Quote from: illusive on November 08, 2016, 10:45:45 amThere are some differences in the peripherals, but not major ones; of course their number and variety changes a lot, but that's true even inside the same family.If you use the HAL (or as long as it is still supported the Standard Peripheral Library) they aremostlyhidden.In C/C++ you won't notice any difference due to the ARM core themselves (F1xx: Cortex M3 vs. F0xx: Cortex M0+), apart from more efficient M3 code, due to the wider instruction set.All in all, I found less distance than going from ATtiny to ATmega.As an example, I retargeted my PSU controller from STM32F4 to F0 without much hassle, and it uses I2C (display), SPI(DAC), ADC, UART(PC control), timers and, obviously, GPIO(encoders, PSU controls).Also, the CubeMX software will allow you to change target, and give a list of incompatibilities and things to check (I think this has been introduced recently).

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: November 08, 2016, 04:58:21 pm
content: If youreallywant to learn the chip and its peripherals, I recommend you stay away from the vendor libraries and write your own driver code.

author: Jeroen3
author_rank: Super Contributor
timestamp: November 09, 2016, 06:41:10 am
content: Quote from: Sal Ammoniac on November 08, 2016, 04:58:21 pmThis. If you want to trust your software. You must do this.

author: julianhigginson
author_rank: Frequent Contributor
timestamp: November 09, 2016, 09:58:26 am
content: If you try to write everything from scratch you'll never get anything useful made in time.Vendor libraries have a place, they're certainly a great start for someone who is new to ARM systems.. but they also let you build things way faster than you could from scratch - the trick is to test and verify *everything* you want to use, and then fix and refactor what isn't right. To do this you do sometimes have to be able to go back to the register settings, so having a platform that lets you do this easily (ie, not mbed..) is important. As is being able to understand the registers when required.

author: Jeroen3
author_rank: Super Contributor
timestamp: November 09, 2016, 10:14:46 am
content: It's not like all libraries are arduino easy. ST's simply adds another layer of functions the bit definitions have to pass trough and add up to the total image size.

author: illusive
author_rank: Regular Contributor
timestamp: November 09, 2016, 04:56:24 pm
content: While i am waiting for my board to arrive i have been browsing the trying to grasp the vast possible ways of programming ARM's. In my eyes there are 2 main ways - bare metal, as it seems to be called, i.e. working directly with the registers, diving in deep into the datasheet, flipping bits and so on, and the second way is through a library (CMSIS, HAL and Standard Peripherals Library). With the AVR's i have never used an Arduino, because i like to be more direct with the microcontroller, but with ARM it seems to me that this task will be overwhelming, or more so tedious and time consuming. In this perspective i need to choose something in between, but with no experience i am blind. Then there is the whole dilemma of choosing IDE...Any advice?Anyway, is there any website, article, video, tutorial or something, where all the basic information about starting with ARM is presented? I feel like the information is wayyy to spreaded all over the place and a beginner can feel a bit lost. The hardest think about anything are the fist steps i guess.

author: snarkysparky
author_rank: Frequent Contributor
timestamp: November 09, 2016, 05:03:15 pm
content: One vote for bare metal setup. You will learn the way the thing really works and have the most un bloated code.

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: November 09, 2016, 09:52:10 pm
content: Quote from: julianhigginson on November 09, 2016, 09:58:26 amWhy not? If given the choice between spending the time writing it myself or spending the time trying to figure out quirky, buggy vendor libraries, I'll choose to write it myself every time.Another thing to keep in mind is that vendor libraries have to support every peripheral and every option on every peripheral. I only have to write driver code for the peripherals and the features that I actually use. This is a much smaller effort.

author: janoc
author_rank: Super Contributor
timestamp: November 10, 2016, 12:25:04 am
content: Quote from: Sal Ammoniac on November 09, 2016, 09:52:10 pmWell, yes, but e.g. writing something like an USB driver/stack or just figuring out I2C on an STM32F1 series could be an enormous job, especially for someone who is only starting on the platform.Let's be realistic, you are probably a very experienced developer who knows the MCU inside out, but for a beginner that's just not possible in the general case - even basic stuff like GPIO and timers can be pretty daunting to set up. A newbie should start with libraries and known-working example code and then optimize by replacing the library code with own routines where needed, learning the hardware on the go. Then in the future they could perhaps get by without the vendor libraries (and/or write their own).

author: julianhigginson
author_rank: Frequent Contributor
timestamp: November 10, 2016, 06:33:44 am
content: Quote from: illusive on November 09, 2016, 04:56:24 pmI understand bare metal to mean no OS. There's a bit of grey area as you move up from a simple hand written event queue dispatcher, through compiled in RTOS libraries moving towards full blown OSes... But I don't see having a HAL or supplier libraries in your code precludes you from being able to call your development bare metal, if that's what you want to do.QuoteYou need to just get started with something. you've picked an eval board, so that's your biggest choice made for now.Install these (I'm not sure if stm32cube eclipse plugin is already in the SW4STM32 IDE or not... but I prefer it standalone having tried the plugin in atollic, and assume it will be the same in SW4STM32)http://www.st.com/en/development-tools/sw4stm32.htmlhttps://my.st.com/content/my_st_com/en/products/development-tools/software-development-tools/stm32-software-development-tools/stm32-configurators-and-code-generators/stm32cubemx.htmlPull down some example projects for your board into the IDE and look at them. Then read the getting started PDF for the STM32cube, and see if you can generate a simple project, then load it up in the IDE, add some basic LED flashing functionality, and compile it, ready to debug.then when your board shows up you can plug it in and see what happens.Once you have had some wins with this setup, I recommend you start looking at atollic truestudio, which is a general purpose arm cortex IDE. Then start using other suppliers eval boards, start with their proprietary IDE offering, then try moving that to atollic, too...You can also play with the mbed website (and I recommend you do - the speed with which you can get an example project up and running with mbed and your nucleo is amazing) but really the abstraction that exists in that platform is huge because it tries to embrace boards form every single cortex m supplier into one single unchanging API, so as a result if you ever have any conflicts in mbed it can be terrible just trying to trace down your under the hood hardware configuration to actual register settings.QuoteARM isn't a product range of one company, it's a whole ecosystem of companies doing similar stuff with small differentiation. And they are all doing things mostly the same but not exactly... (because they want to make it hard for people to move from them to their nearly the same competitor)Nobody is responsible for the whole thing, so information is siloed and hard to always get consistently - also open source tools always seem to have breaking changes because open source programmers are apparently useless at architecting anything in any meaningful way that can ever last...so whatever info you do find has to be up to date or it will be wrong..that's why, starting out, it's wise to just stick with one supplier's tools and documentation and demo projects for their eval board that you own. dig around their example projects, see what goes on under the hood, then work out how you want to code once you are understanding what you have been given..

author: newbrain
author_rank: Super Contributor
timestamp: November 10, 2016, 08:02:55 am
content: Quote from: janoc on November 10, 2016, 12:25:04 amDefinitely this.As for IDEs, System Workbench -SW4STM32- is quite decent, if you are comfortable with Eclipse.The CubeMX plugin is not included (you have to download it separately) and I agree with julianhigginson that's better to keep it standalone.There are a number of alternatives for development environments, but in the beginning better stick to something known to be working out of the box, to avoid at least the whole class of problems due to the tools*.The process of defining the used peripherals, pins, clock setting etc. in CubeMX, generating the code for SW4STM32 and importing it in the IDE works quite smoothly.Then you can go scouting the forum for some of the legion ofthreads where opinionson IDE preferences are exchanged..Consider also another learning opportunity: depending on the country you live in,ST organizes free hands-on workshopswhere they go through the basics or some specific aspects of a product.The only requirement is to register in time, and bring a laptop to go through the exercises: they usually provide the needed HW.On the linked page you can also find a number of online courses, but I never tried one of those; I just attended a workshop and was quite satisfied with the experience: the FAEs were prepared and helpful when problems (for the most part between the chair and the keyboard) were found.*SW4STM32 could not contact the gdb server (OpenOCD) on my work laptop, in the end I traced it to be a conflict on TCP port 3333, used also by a remote connection SW. The rest worked as expected, no problems on my fixed PCs.

author: illusive
author_rank: Regular Contributor
timestamp: November 15, 2016, 12:14:19 am
content: Some basic questions.I downloaded System Workbench for STM32. I'm trying to start a project without libraries, should i check the "No firmware" option? Then is seems that i manually need to create the main.c file, what header file i need to include to have all the macros for the registers?

author: Kremmen
author_rank: Super Contributor
timestamp: November 15, 2016, 08:18:13 am
content: Answer to 1st Q: That is what the option tries to tell you.To answer your 2nd Q is undoable since you haven't said what specific processor you plan to use. Anyway, you won't have the peripheral library files until you have specified at least once in an earlier project the processor you are going to use and downloaded the target firmware. So using the libraries with the "no firmware" option will only work if you already have those files. And then you have to manually import each and every one to your project.I have a hard time seeing the benefit of the above approach. It would be a big task to locate each and every file since there is quite a number of them scatterd in the various layered repository directories.Why not do it the easy way and create a prototype project using e.g. CubeMX. Then you can directly see what got included and based on that you have a good idea what you need to make your peripherals work. That is what i do and usually i won't bother to change anything afterwards. What does it matter if the HAL code is a bloated monster of say 20k instead of the lean 10k you can achieve by hand coding. When the chip has 512k or 1M of flash, who cares about 10k.The only thing i sometimes do is to access plain GPIO directly instead of the HAL layer but even there the saving in code size and execution time is often meaningless.P.S. For your information: ST deprecates the use of Std Peripheral Library in new designs and recommends using CubeMX HAL instead. For those who don't want to, there is/will_be_real_soon_now an advanced option in CubeMX app to use Low Layer library functions instead of the HAL. Those are direct register access functions essentially replicating what you would have to do manually anyway, with minimal overhead. The other side of the coin is that they are stateless i.e. have no memory of any earlier operation. That may be a good thing or a bad thing depending on what you are after.But anyway, this functionality was demonstrated in a recent ST workshop and should be the answer for those who consider the HAL too bloated or something.

author: newbrain
author_rank: Super Contributor
timestamp: November 15, 2016, 03:32:54 pm
content: Quote from: illusive on November 15, 2016, 12:14:19 am"No Firmware" is the right option to select if you do not want to use any library.If only register definitions are needed, the file to include is "stm32f1xx.h" (for your STM32F103): it's the CMSIS file that contains (actually, includes from the MCU specific file...) all the structures and defines to directly access peripherals registers.This file is located inxxx\Drivers\CMSIS\Device\ST\STM32F1xx\Include, wherexxxis the base directory where the Cube SW for your MCU has been unzipped.As far as I can tell, you need to download the whole Cube to get the CMSIS, but if you've tried or used CubeMX you should already have all that's needed.So, you'll need to add that dir to the list of include directories of the project.This is not enough, as you need either to uncomment the #define line containing your MCU in the above file, or to define the appropriate symbol in the compiler command line options:STM32F103xBin your case; note that the project template will generate some defines (that you can see inProject->Properties->C/C++ Builds->Settings->Symbols) but not this one expected by CMSIS.For first steps, I would generate a project with CubeMX, import it, and then just use direct register access if that's what you want to do.You can use the HAL just for initialization of the clock/power system and the needed peripherals.The unused HAL functions will not be linked in the final code, so I would not expect too much bloat.Low Level libraries have been delivered up to now only for the STM32 L0 and L4 series, with the promise that they'll be available for the F family later on (I've been to one of the workshops Kremmen mentioned above), the latest CubeMX can generate code for either library (L4 and L0 only, of course).Apart from some minimal structured peripheral initialization, most of the LL lib functions are not much more than direct register writes or reads, wrapped in an inline function. I'm not too convinced of their real usefulness, but I haven't used them extensively.

author: Kremmen
author_rank: Super Contributor
timestamp: November 17, 2016, 06:14:48 am
content: Quote from: newbrain on November 15, 2016, 03:32:54 pmTechnically that is so. But considering that the registers must be initialized one way or another, this offers a standard way to do it. An added bonus is that you have a nice interface to the definitions in Cube. I would consider that useful even if the Low Layer itself doesn't do anything complicated.

author: FreddyVictor
author_rank: Regular Contributor
timestamp: November 17, 2016, 08:56:19 am
content: Quote from: illusive on November 08, 2016, 10:45:45 amThe hierarchy of ARM cores can be a little confusing to the beginnerThe CM3 I believe are the older ones (STMF1xx and STM32F2xx parts) hence the lower priceCM0 (& CM0+) are newer parts (STM32F0xx and STM32L0xx) and are IMHO preferableThe Alternate Function for setting pins to particular functions was not great on the CM3 and is much better for the later cores plus i2c can be a pain

author: janoc
author_rank: Super Contributor
timestamp: November 17, 2016, 08:49:09 pm
content: Quote from: FreddyVictor on November 17, 2016, 08:56:19 amSTM32F1xx series are Cortex-M3, a bit older chips with some issues, such as the notoriously buggy I2CSTMF32F0xx series are Cortex-M0, newer product, but much simpler (and slower) ARM core compared to M3/M4. F10x runs up to 72MHz, F0xx only 48MHz, for example.That will probably not matter for many applications, but it is worth keeping in mind.

author: westfw
author_rank: Super Contributor
timestamp: November 18, 2016, 02:03:35 am
content: QuoteThe "core" (CM0 or 0+ vs CM3) has very little to do with the simplicity or bugginess of the peripherals.The CM0 chips ARE "newer" and may have better-implemented peripherals, or ... not. The CM0 *core* is pretty annoying (no divide, missing a bunch of the instructions and modes you might expect, less space-efficient, slower.)ST also has STM32F2xx CM3 chips, STM32f4xx and STM32F4xx CM4 chips, and STM32F7xx CM7 chips that get less attention for some reason.

author: andersm
author_rank: Super Contributor
timestamp: November 18, 2016, 06:50:26 am
content: Quote from: janoc on November 17, 2016, 08:49:09 pmAFAIK, the STM32F10x (and specifically the STM32F101) was the second Cortex-M family on the market, after Luminary.

author: Kremmen
author_rank: Super Contributor
timestamp: November 18, 2016, 09:23:43 am
content: Quote from: westfw on November 18, 2016, 02:03:35 amSpeaking of those, i am just in the process of developing some real-time signal filtering software for the STM32F303RETI. That is a nice chip with the CM4 floating point unit making filter calculations more straightforward. (Of course one could use fixed point math as well but this is nicer). The 72 MHz max clock could be higher but it helps a lot to run the filter code in Core Coupled RAM that is a rare bird but available in this series. It lets you copy code from flash to static RAM and run it with zero wait states.

author: janoc
author_rank: Super Contributor
timestamp: November 18, 2016, 10:21:08 am
content: Quote from: westfw on November 18, 2016, 02:03:35 amNo, certainly not - only in this case the older buggy chips used Cortex-M3 core and the newer ones happen to be Cortex-M0. Correlation, not causation.Quote from: westfw on November 18, 2016, 02:03:35 amCortex-M0 *is* newer (no need for the scare quotes), it was released by ARM only after Cortex-M3, when it was clear the M3 is an expensive overkill for many applications. M0 is meant to be a direct competition and migration path to the 8bit '51, AVRs and PICs. M3 is a more upscale part for more complex tasks.Quote from: westfw on November 18, 2016, 02:03:35 amMainly price and complexity. Most hobby projects don't need a $20 micro with a megabyte of memory, built-in DSP and graphic accelerator. CM7 is a huge beast, hobbyist would be often better served using something like RaspberryPi or a BeagleBone if an application needs a CM7 power - the price difference will be minimal and development comfort much higher.F3 and F4 series are seen here and there, but the F0 series can handle most needs already, so why to pay more.