Starting with ARM Cortex-M

[illusive]

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!

[shebu18]

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.

[sambran]

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 course https://www.edx.org/course/embedded-systems-shape-world-utaustinx-ut-6-03x which uses TI boards, IMO it is pretty good.

Emedded.fm has a series of blog post on the ST Discovery board http://embedded.fm/blog/?author=56b8dd4360b5e9ab3bbfc486, you might find them useful.

[andersm]

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.

[newbrain]

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.

Just 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.

[Jeroen3]

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.

Hard. 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.

[zapta]

Two suggestions

1. 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.

[Sal Ammoniac]

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

[nctnico]

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.

[illusive]

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.

[farsi]

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.

[nctnico]

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.

Ofcourse 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.

[zapta]

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.

Assuming 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

[rstofer]

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.

[ajb]

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.

[Sal Ammoniac]

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.

Atollic 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.

[Brutte]

Can't i  just buy the bare microcontroller, hook it up to a breadboard and a programmer and use some IDE to program it?

You 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.

[Kremmen]

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 ([/url]http://www.openstm32.org/HomePage[/url]) 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.

[illusive]

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?

[thm_w]

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?

yep, or you can buy a stlink 2 clone for ~$3 too.

[langwadt]

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?

yes you just remove two jumpers and there is header with the SWD debugger signals

[ez24]

Book:

https://leanpub.com/mastering-stm32

746 pages and 80 % done !  The remaining 20% is additional topics, not on what has already been written about

Book, board (Nucleo) and compiler for $99 and debugger for $50:

https://imagecraft.com/

[julianhigginson]

There may even be a coupon code for free delivery but I can't seem to find it ATM.

FALLFREESHIP

worked for me the other day...

[julianhigginson]

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.aspx

I'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_Modules

And 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..

[newbrain]

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.

[illusive]

That is a good deal from TI, but i had already placed my order on NUCLEO-F103RB board 
I 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?

[newbrain]

That is a good deal from TI, but i had already placed my order on NUCLEO-F103RB board 
I 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?

There 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 are mostly hidden.
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).

[Sal Ammoniac]

If you really want to learn the chip and its peripherals, I recommend you stay away from the vendor libraries and write your own driver code.

[Jeroen3]

If you really want to learn the chip and its peripherals, I recommend you stay away from the vendor libraries and write your own driver code.

This. If you want to trust your software. You must do this.

[julianhigginson]

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.

[Jeroen3]

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.

[illusive]

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.

[snarkysparky]

One vote for bare metal setup.  You will learn the way the thing really works and have the most un bloated code.

[Sal Ammoniac]

If you try to write everything from scratch you'll never get anything useful made in time.

Why 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.

[janoc]

If you try to write everything from scratch you'll never get anything useful made in time.

Why 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.

Well, 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).

[julianhigginson]

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).

I 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.

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?

You 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.html

https://my.st.com/content/my_st_com/en/products/development-tools/software-development-tools/stm32-software-development-tools/stm32-configurators-and-code-generators/stm32cubemx.html

Pull 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.

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.

ARM 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..

[newbrain]

Well, 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.

Definitely 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 of threads where opinions on IDE preferences are exchanged..

Consider also another learning opportunity: depending on the country you live in, ST organizes free hands-on workshops where 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.

[illusive]

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?

[Kremmen]

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.

[newbrain]

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?

"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 in xxx\Drivers\CMSIS\Device\ST\STM32F1xx\Include, where xxx is 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: STM32F103xB in your case; note that the project template will generate some defines (that you can see in Project->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.

[Kremmen]

[...]
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.

Technically 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.

[FreddyVictor]

I decided to go with STM32F103RBT6 Cortex-M3 micro, it was even cheaper than the Cortex-M0 one, go figure.

The hierarchy of ARM cores can be a little confusing to the beginner
The CM3 I believe are the older ones (STMF1xx and STM32F2xx parts) hence the lower price
CM0 (& CM0+) are newer parts (STM32F0xx and STM32L0xx) and are IMHO preferable
The 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

[janoc]

I decided to go with STM32F103RBT6 Cortex-M3 micro, it was even cheaper than the Cortex-M0 one, go figure.

The hierarchy of ARM cores can be a little confusing to the beginner
The CM3 I believe are the older ones (STMF1xx and STM32F2xx parts) hence the lower price
CM0 (& CM0+) are newer parts (STM32F0xx and STM32L0xx) and are IMHO preferable
The 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

STM32F1xx series are Cortex-M3, a bit older chips with some issues, such as the notoriously buggy I2C

STMF32F0xx 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.

[westfw]

The CM3 I believe are the older ones (STMF1xx and STM32F2xx parts) hence the lower price
CM0 (& CM0+) are newer parts (STM32F0xx and STM32L0xx) and are IMHO preferable

The "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.

[andersm]

STM32F1xx series are Cortex-M3, a bit older chips with some issues, such as the notoriously buggy I2C

AFAIK, the STM32F10x (and specifically the STM32F101) was the second Cortex-M family on the market, after Luminary.

[Kremmen]

The "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.

Speaking 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.

[janoc]

The CM3 I believe are the older ones (STMF1xx and STM32F2xx parts) hence the lower price
CM0 (& CM0+) are newer parts (STM32F0xx and STM32L0xx) and are IMHO preferable

The "core" (CM0 or 0+ vs CM3) has very little to do with the simplicity or bugginess of the peripherals.

No, 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.

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.)

Cortex-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.

ST also has STM32F2xx CM3 chips, STM32f4xx and STM32F4xx CM4 chips, and STM32F7xx CM7 chips that get less attention for some reason.

Mainly 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.