STM32F4 Nucleo - Using Eclipse+GCC - Where is the C manual? - Page 1
Forum section: electronics / general

author: plastygrove
author_rank: Contributor
timestamp: October 07, 2015, 02:53:41 pm
content: Hi All,Coming to the ARM world from AVR and PIC microcontrollers and boy it is difficult.After trying mbed.org and reading up on CMSIS and HAL, I feel HAL is the best way for me to proceed given my level of understanding. I've got some basic blinky stuff and input reading stuff from GPIOs working and also UART from an online link.The biggest problem is the documentation, there are multiple sources for all kinds of info and it's still lacking. I have a lot of patience and am happy to read through docs, but I don't understand why I constantly have this feeling that I'm trying reverse engineer the libs and try to get something working.Is there a single C manual for the GCC that I can refer to? Right now, I'm referring to 3 different docs:The reference manualThe programming manualThe HAL manualand none of them seem to explain how many of the C functions are to be written.For example - what is the syntax for declaring an interrupt function in C for a particular line? I do a search and find something for the discovery board, and try and see if that works for me. I feel this is just wrong. Am I looking at the wrong place? Searching for ARM C Manual, GCC ARM Manual, stm32 c manual doesn't give me anything other than the 3 docs listed above.Any suggestions?Cheers

author: bigdawg
author_rank: Regular Contributor
timestamp: October 07, 2015, 03:08:08 pm
content: Quote from: plastygrove on October 07, 2015, 02:53:41 pmI just started working with STM32F7disco couple of months ago, and I had to extensively use the HAL manual. I also bought this really cheap ebook (http://www.amazon.com/gp/product/B00WBU4BPW?psc=1&redirect=true&ref_=oh_aui_d_detailpage_o02_) and it was a great resource to start out considering it only costs 3 bucks. I also used The Definitive Guide to ARM® Cortex®-M3 and Cortex®-M4 Processors, but I cant say it was that useful. The only good thing is that it uses STM32F4disco for its examples; However, its all Std peripheral lib and no HAL so you'll have to go through HAL reference manual anyways

author: plastygrove
author_rank: Contributor
timestamp: October 07, 2015, 03:19:55 pm
content: Quote from: bigdawg on October 07, 2015, 03:08:08 pmThanks for the book link, it looks great! I wish I had this a few weeks ago when I started. Unfortunately, I already have working code samples for all except the ADC section, so it's not going to be too helpful.I keep going through the HAL manual but it's just a miserable excuse for a manual. It's just a pdf auto-generated from the comments in the source code. There are no complete code examples and in lots of places the functions don't work.For example, the HAL_Delay() function doesn't work. I do the Inits and setups as mentioned in the manual but when I checked, HAL_GetTick() is always zero. I don't know what I need to enable to get this to work.I could just go to mbed.org and use that but I don't want it to be super-simplified to DigitalWrite(). I'd like to learn what's going on under the hood, but to a point that my current schedule allows. This is a hobby.

author: Karel
author_rank: Super Contributor
timestamp: October 07, 2015, 03:37:27 pm
content: Quote from: plastygrove on October 07, 2015, 02:53:41 pmThe GCC manual is here:https://gcc.gnu.org/onlinedocs/

author: plastygrove
author_rank: Contributor
timestamp: October 07, 2015, 03:47:24 pm
content: Quote from: Karel on October 07, 2015, 03:37:27 pmThanks but I did take a look at that, I couldn't find any thing which shows how to set up interrupt handlers.I know the interrupt handler is of the form EXTI0_IRQHandler but is there a doc somewhere which explains this?

author: westfw
author_rank: Super Contributor
timestamp: October 07, 2015, 05:01:51 pm
content: QuoteOn ARM Cortex, interrupt handlers are just standard C functions, that happen to be referenced in the Interrupt vector table.As a C programmer, all you have to do is create a function with the correct name, which is relatively standardized (by CMSIS?) as PERIPHERAL_Handler(); the worst you should have to do if the names aren't documented elsewhere is look at the code for the vector table (usually in the startup code xxxx_startup.c or xxx_startup.S) (The hardware takes care of saving and restoring all of the "extra" context that would normally be the "extra" code required in an ISR vs a normal function. Is that good? It also means that you can't write a really clever extra-fast ISR that saves less context because it doesn't use much...)You might also need the manual for the higher-level libraries; usually "newlib" or "newlib nano", and the CMSIS documentation. (while CMSIS gets a lot of hate here for "bloated libraries", a LOT of it is just standards for structure of a program, naming and access of common core resources, and conventions for naming and defining access to peripherals. And most compilers follow it pretty well, so it's actually useful.http://www.keil.com/pack/doc/cmsis/Core/html/index.html)

author: newbrain
author_rank: Super Contributor
timestamp: October 07, 2015, 06:29:16 pm
content: Quote from: plastygrove on October 07, 2015, 03:19:55 pmDoxygen! I really prefer reading directly the code together with the comments.Quote from: plastygrove on October 07, 2015, 03:19:55 pmYes, that caught me too at first.Ineverysome HAL headerand in most examplesyou can find the statement about using a 1ms tick to make sure the HAL works, but how to get it working is not spelled out very clearly.As westfw says, interrupt handlers are just regular C functions, for the system tick that would be:Code:void SysTick_Handler(void){/* your code here */}Now, the HAL provides a couple of functions to place in the handler, defined in stm32f?xx_hal.c (where ? is the F family number).The first is more or less mandatory, as it increments the tick:Code:__weak void HAL_IncTick(void){uwTick++;}The other one,Code:void HAL_SYSTICK_IRQHandler(void)is optional, it just calls an user overridable (weak) callback function.So the handler should look something like:Code:void SysTick_Handler(void){HAL_IncTick();HAL_SYSTICK_IRQHandler();}And you could insert other things to do every tick in yourCode:void HAL_SYSTICK_Callback(void);Note that this is a very general mechanism used by the HAL: it provides the building blocks for handling the interrupt from the peripherals, but it's up to you to write the xxxx_Hander() functions.One way of learning all this could be using CubeMX to generate the skeleton code for various peripherals (and the clock chain settings) and study that: I used it quite a lot in the beginning, but now I almost know my way around HAL maze.It will generate all the needed initialization code, generally quite easily readable, including (if enabled) interrupt handlers.Quote from: plastygrove on October 07, 2015, 03:19:55 pmRight attitude! mbed can be an easy way to begin if you only have done some Arduino stuff, but using the HAL (and also knwoing the involved registers and how to bypass it) will for sure teach a lot more.

author: Jeroen3
author_rank: Super Contributor
timestamp: October 07, 2015, 06:51:34 pm
content: QuoteThere is no single manual. You learn the C language and you learn the C compiler.Then you learn how to program for ARM with the cross compiler, the programming manual helps.Then you learn about the hardware, which is where the reference manual comes in.The HAL is an set of example peripheral drivers that sometimes help, but shouldn't be the sole way of programming for microcontrollers. (You don't hot-glue in demo boards, or do you?)If it was easy, everyone was doing it.Btw, interrupts are weakly declared in the startup assembler, and the global catch-all loop. There are some more linker keyword there specifying where to put them, and where to put the stacks and heap. An IDE likes to hide this, since it looks "easier" because it was hidden with AVR's as well. It's annoying.

author: nctnico
author_rank: Super Contributor
timestamp: October 07, 2015, 07:55:20 pm
content: IMHO it helps a lot to read and understand how a C compiler (or better put: a toolchain) turns a piece of sourcecode into a 'binary' which the processor can execute. A lot is hidden to make things 'easier' but you have to understand the magic.

author: plastygrove
author_rank: Contributor
timestamp: October 08, 2015, 12:13:19 am
content: Thanks for the replies everyone!Quote from: westfw on October 07, 2015, 05:01:51 pmYES!!! Amazing, thank you! For my setup, it's in the system/src/cmsis/vectors_stm32f4xx.c file and it has all the Interrupt function names defined for my micro. This is very helpful!FYI, I set up my toolchain as perthis very useful guideonline.Quote from: westfw on October 07, 2015, 05:01:51 pmThanks for the link! This looks like a decent set of docs and I'll definitely spend some time going through these, I think I missed the CMSIS documentation.Quote from: newbrain on October 07, 2015, 06:29:16 pmExcellent tips! I added the handler as you said and I can now use HAL_Delay() instead of my own for-loop. Thanks so much, I didn't know we had to write our own Handler for Systick as well!Quote from: newbrain on October 07, 2015, 06:29:16 pmYup, I have nothing but respect for the Arduino since that's what launched me into electronics 4 years ago, but I stopped using it 2 years ago for all my main projects, preferring to work directly with the registers for AVR and PIC. ARM seems to be in a completely different league and I figured I should lean on the HAL unless I want to take a month to build a blinky. :|Quote from: Jeroen3 on October 07, 2015, 06:51:34 pmThanks, I don't expect to completely rely on HAL for everything and do realise there are times when going a little lower can help improve performance.Quote from: Jeroen3 on October 07, 2015, 06:51:34 pmThis is exactly what I was missing and what westfw also spoke about. I didn't understand what the term "weak" actually meant and didn't realise that the names were already declared elsewhere in the code. Thanks for pointing it out! I think Microchip has done a good job with a manual for the XC8 compiler which explains all the functions and nuances of the compiler. It was invaluable for me when I was writing my own interrupts for the PIC18.Quote from: nctnico on October 07, 2015, 07:55:20 pmAgreed. I just want something that I can work with before I start from the absolute basics. Eventually, I hope to learn how the toolchain works and maybe even start doing bare metal coding in vim.