Want to get started with ARM stm32 - Page 1
Forum section: electronics / general

author: rwgast_lowlevellogicdesin
author_rank: Frequent Contributor
timestamp: January 23, 2015, 02:03:54 am
content: Ive been using the propeller microcontoller along with arduino and AVRs for about two years now. I would like to start learning arm, the chips are cheaper than AVRs and have beefy peripherals.I found this book,http://www.cs.indiana.edu/~geobrown/book.pdfit seems to be a very good introduction to using stm32 micro controllers. The issue is the author uses an stm32 LV discovery board which has an stm32f1 on board. I currently have stm32f0, stm32L1, stmf3 discovery boards. Can I use any of these with this book? I.E is the f3 code compatible with the f1? Im hoping the only thing I would need to adapt to is the boards pinouts?

author: dannyf
author_rank: Super Contributor
timestamp: January 23, 2015, 12:46:57 pm
content: First of all, it is a very good book to get started.QuoteIt depends on your level of skills.You definitely cannot directly use the examples - they rely on (slightly) different libraries.However, the basic principles between the series of chips and libraries are highly similar so with minimum changes, you can indeed port most / all of the examples from one series to another series.Whether you can do that or not is a total unknown to anyone but yourself.

author: Jeroen3
author_rank: Super Contributor
timestamp: January 23, 2015, 02:27:36 pm
content: ST put effort in keeping their products very similar. Reducing the effort required to change code and hardware to a better chip.For books on ARM I can recommend "The Definitive Guide to ARM Cortex...".

author: neslekkim
author_rank: Super Contributor
timestamp: January 23, 2015, 02:48:04 pm
content: Quote from: Jeroen3 on January 23, 2015, 02:27:36 pmI think there are two books in this series, are both equally good?

author: dannyf
author_rank: Super Contributor
timestamp: January 23, 2015, 03:04:10 pm
content: There are a few, from M0 to M4, and some with multiple revisions.But they are not useful (at all?) for a practitioner's point of view. When you learn a chip, the biggest distinguisher is the peripherals, which differ vastly from chip to chip, and vendor to vendor. The books by Yue cover none of that.What the books do teach is largely transparent for a high level language programmer, save for debugging, etc.End of the day, the datasheets, and if you use libraries, the library documents / source code, are the best learning materials for any chip.

author: neslekkim
author_rank: Super Contributor
timestamp: January 24, 2015, 12:37:01 am
content: So, learning from M0-M3-M4 these books are not useful?For peripherals I understand that the books don't cover it, since it differs from implementors, but I was more curious about the Mx cores.

author: Yansi
author_rank: Super Contributor
timestamp: January 24, 2015, 12:49:12 am
content: These books sure are useful.

author: dannyf
author_rank: Super Contributor
timestamp: January 24, 2015, 01:08:56 am
content: QuoteIt is definitely useful, just not sufficiently useful to justify the investment to learn it, to me.There are far more things that we do NOT learn than things we do learn. That does not mean those things we don't learn are not useful.QuoteThen get those books - they are great for that purpose.For learning to use a particular chip, not so much.

author: westfw
author_rank: Super Contributor
timestamp: January 24, 2015, 06:54:38 am
content: QuoteLibraries that have been replaced by ST with a NEW set of libraries :-((The book uses the ST Standard Peripheral Library. The new thing us the "ST Cube HAL libraries.")In theory, I believe the new HAL libraries are supposed to have fewer differences from one family to another. It's hard to tell; the documentation is pretty sucky.I'm not convinced that the libraries are easier to use than writing low-level C yourself, based on the datasheets. Especially if the libraries keep changing, aren't anywhere near the same on chips from different vendors (they all have "easy to use libraries"; all different!), and have a substantial level of complexity and verbosity. :-(If you want a set of libraries to do basic embedded things like pin-twiddling, and want it to work across multiple chip families from multiple vendors, it may be that your only choice is Arduino. (which is depressing.) Possible contender: MBed (I haven't looked at it much.)

author: Yansi
author_rank: Super Contributor
timestamp: January 24, 2015, 11:20:14 am
content: dannyf: I can't tell, because I don't know you, but if I want to program a chip, it is a good start to learn about the architecture first.Judging byrwgast_lowlevellogicdesin's nickname, the book is right for him.If he needs only continuing arduino style slapping libraries together, then the book is useless.Two ways:a) learn ARM properly. From the architecture, through assembly to the top level of RT systems.With STM32 I'd suggest sticking with StdPeriph libraries. They are supported so far, but new STM32 series will not have them, only Cube/HAL. Shame, these HAL libraries was meant good, made some things easier to implement for beginners, but are useless for anything little more advanced, than using example codes. The HAL libraries are slow, sometimes badly designed and have almost zero support for low-power applications, even on the STM32L series. User needs to modify the libraries and spends a lot of time with that, I think sometimes more than it would take writing the thing from scratch yourself.b) Just toying style, slapping libraries together. Then the HAL has some potential, so does that MBED nonsense.Just a related note:StdPeriph exists for these: F0, F1, F2, F4, partly F3 (not for the new ones like 334), L1. Doesn't exist fort L0 and L4. Probably also will not exist for F7.HAL exists for all of them, for some, STM32Cube support is nowhere near.

author: russian2
author_rank: Contributor
timestamp: January 24, 2015, 01:36:00 pm
content: Quote from: rwgast_lowlevellogicdesin on January 23, 2015, 02:03:54 amf1 is defenitely not the same thing as f3. With all this weird peripheral register magic, I suggest you invest in the same exact chip/board the book is describing.I also want to suggest ChibiOS - the magic of ChibiOS is HAL, hardware abstract layer - which hides all the register insanity behind a nice driver API

author: dannyf
author_rank: Super Contributor
timestamp: January 24, 2015, 01:53:31 pm
content: QuoteYou can simply use the libraries to do that.

author: madires
author_rank: Super Contributor
timestamp: January 24, 2015, 01:56:05 pm
content: I've also just started with Cortex-M and settting up a tool chain under linux at the moment. From what I've already learned there are two abstraction layers available. The basic one is CMSIS to set up the MCU (clock etc.) and it seems to be some standard, available from other vendors too. The other one is the HAL to hide the hardware, somewhat similar to arduino. I'm sure I won't use the HAL, but I'm thinking about using CMSIS. I would like to know from someone already done several ARM based projects about CMSIS. Is it useful?

author: Yansi
author_rank: Super Contributor
timestamp: January 24, 2015, 02:10:28 pm
content: Crap or crap, thats the choice.If you need to hide hardware and are afraid of learning the basics, then it is doesn't matter, what will you use.Good designer does know about the architecture, from the low level to the top and can combine or make a right choice depending on the requirements of things he is doing.There is no "what is better, HAL or CMSIS", each are good for something. I personally prefer (on STM32) using StdPeriph combined with direct access to registers, sometimes with inline assembly.For example: I don't know, why would I use some crap hundred-line code HAL_GPIO_TogglePin() whoknowswhat-it-is-doing function, if it is right enough, to just XOR an GPIOx->ODR register?

author: madires
author_rank: Super Contributor
timestamp: January 24, 2015, 04:23:35 pm
content: I'm with you, I don't like a HAL_GPIO_TogglePin() either. What I meant was CMSIS CORE, which offers a standardized way to initialize the MCU. It also supports a nice way to access the registers (by a C structure). That's quite convenient if you want to support different Cortex-M types. Of course you could go for lovely #ifdef orgiesI've just started to look into the STM32 and trying to figure out the best way for me.

author: Yansi
author_rank: Super Contributor
timestamp: January 24, 2015, 05:10:41 pm
content: Initializing the MCU clock and memory system, is about 20-30 lines of assembly, or 5 to 10 lines in C, directly accessing the registers or about 5 commands by a StdPeriph library. Means for the simplier devices, F439 like-ones are a bit complicated, but nothing impossible to do "manually".Why the hell would somene like to use standardized CMSIS? It only adds ballast and unnecessary overhead for the intended functionality.What is so complicated on setting up an ARM Cortex MCU? Only set the desired FLASH wait states (number found in a documentation) - that means single write to a register, start needed clock sources (eg external crystal oscillator, which is called HSE //high speed external// on STM32), wait for stabilization of the clock source - flipping and polling a single bit. Setup the PLL (if needed) clock source, divide and multiply ratios, start PLL and wait for its lock. Then switch the system clock source t the PLL output and check the success.Sounded difficult? If yes, programming ARM MCU's wasn't a good choice then. There is hell of a lot much more complicated stuff, then setting a clock source and distribution system on the chip. And its cost is only to open the manual (which you must do if you want or not) and learn, how the clock system works. Otherwise it is better to choose simpler MCU, than ARM.Here a small minimalistic example how to setup F051 via registers, also with a SysTick timer. Using registers.Code:void SystemInit() {RCC->CFGR = 0x00280000; //0b0000 0000 0010 1000 0000 0000 0000 0000RCC->CR |= RCC_CR_PLLON; //set PLL ONwhile (! RCC->CR2 & RCC_CR_PLLRDY); //wait for PLL to lockFLASH->ACR = FLASH_ACR_PRFTBE | 0x01; //FLASH prefetch enabled, 1 WaitStateRCC->CFGR |= RCC_CFGR_SW_1; //switching clock source to PLL output//SysTick configurationSysTick->LOAD = 48000-1; //Reload value (48000-1) -> 1msSysTick->VAL = 0;SysTick->CTRL = SysTick_CTRL_CLKSOURCE_Msk | SysTick_CTRL_TICKINT_Msk | SysTick_CTRL_ENABLE_Msk;NVIC_EnableIRQ(SysTick_IRQn);}Yes, it is not as transparent and not done absolutely properly, but that was my absolute first try on ARM. And after a one or two afternoons, it worked.If someone tells you, that for a beginner, this is way too hard... He lies. And note that the MCU also works with the clock system in its default state. Will be slow, won't be ideal (arduino is not ideal at all), so where's the problem to start that way?And that's an proper init of F103, using StdPeriph (again, no timeouts or error handling, but for simple educational purposes)Code:void SystemInit(){/* Set 2 wait states for FLASH */FLASH_SetLatency(FLASH_Latency_2);/* enable prefetch buffer */FLASH_PrefetchBufferCmd(FLASH_PrefetchBuffer_Enable);/* start HSI (internal high speed oscillator), it should be running default, but to be sure */RCC_HSICmd(ENABLE);/* wait for the oscillator to start */while (!RCC_GetFlagStatus(RCC_FLAG_HSIRDY));/* Set the clock source as HSI/2 for the PLL, multiply by 16 */RCC_PLLConfig(RCC_PLLSource_HSI_Div2, RCC_PLLMul_16);/* Enable the PLL */RCC_PLLCmd(ENABLE);/* Wait for PLL to lock */while (!RCC_GetFlagStatus(RCC_FLAG_PLLRDY));/* Set the prescalers for the AHB and APB buses */RCC_HCLKConfig(RCC_SYSCLK_Div1); //AHB = 64MHzRCC_PCLK1Config(RCC_HCLK_Div2); //APB1 = 32MHzRCC_PCLK2Config(RCC_HCLK_Div1); //APB2 = 64MHz/* now we switch system clock to the PLL's output */RCC_SYSCLKConfig(RCC_SYSCLKSource_PLLCLK);/* check it is switched to the requested source */while (RCC_GetSYSCLKSource() != 0x08);}Now you've seen some code examples, how simple the basic init is. I don't see there any need to rely on 3rd party libraries.Now I expect someone starts bitching me out, that I am too much vintage style or I am not using libraries, or I hate multiplatform-stuff, etc... I get it, but he will not change my opinion. If he wants to use libraries, especially HAL, good luck using them (respectively hacking them to be usable) for advanced applications or to even fit devices without megabytes of flash.And to be exact, the init in the HAL is also made quite wrongly. Sometimes, HAL just tries to start LSE, if there is not even connected any crystal, or starts it, then shuts it down, so sometimes it can take a few seconds to start the MCU.So you can make a decision yourself, which way will you go. I don't want to obtrude anybody, to learn anything... So shouldn't you tell me that this knowledge is useless. (It is useful as you wouldn't beleive maybe)As a standard "it depends"... on many things. Hope my little insight into this topic was helpful for you.//So what kind of application will you do? STM32 only or must be easily portable to other vendors' chips? - These and like so are the questions you must ask yourself. Based on that you can make a decision, what is suitable for you.//By the way - if you are brave enough to throw away HAL, I woul'd suggest doing the same with CMSIS.

author: Jeroen3
author_rank: Super Contributor
timestamp: January 24, 2015, 09:24:32 pm
content: The above two code fragments are usually called even before main from within the startup assembly. (for when you cannod find them in the examples )This is done to speed up the scatter loading process the compiler inserts before main() and after the startup assembly. In this scatter loading code the default values are copied from flash to sram for global scope variables that use them.The realview compiler does it this way, I'm not sure about gcc but it wouldn't be strange if it worked similar.Running the above two fragments inside main will also work, but you'll have slower boot.CMSIS is ideal for accesring peripherals that are standardised on all ARM cores, such as the systick, nvic, debug and the core itself.They also provide math and dsp code optimised for ARM for free.

author: Yansi
author_rank: Super Contributor
timestamp: January 24, 2015, 11:05:48 pm
content: Where did I say to run them in main?Call them from the startup. A little knowledge required, so what I told ya about the Yiu's book?Still I get that, any knowledge additional to so called "libraries" is useless (for most people).Code:;Reset handlerReset_Handler PROCEXPORT Reset_Handler IMPORT __mainIMPORT SystemInitLDR R0, =SystemInitBLX R0LDR R0, =__mainBX R0ENDPYou can modify the startup code as your wishes go. Also you can simply combine assembly and C modules, because of the clever IMPORT/EXPORT functionality.Yea, the math and dsp code is the only thing what the CMSIS is really good for.

author: rwgast_lowlevellogicdesin
author_rank: Frequent Contributor
timestamp: January 25, 2015, 01:59:36 am
content: Well thanks for this info, I guess I will definitely buy the VL discovery board. What I want is to learn how to use an ARM chip at the lower level, I.E using C and bit twiddling registers, Im not opposed to using something like a HAL but then thats not really learning arm chips, its implementing a high level library and programming in C.What I guess im asking is if stm32 is like the Atmega line where you have standard librarys and methods of doing things, once you learn those switching between chips in the line is as a quick look at the data sheet and adjusting your code for the register names and pin numbers. It seems to me switching between arm chip vendors is not an easy thing and you have to learn a whole new chip landscape to use a different vendors peripherals. Almost as complicated as switching from AVR to 8 bit PIC.I like the STM chips but the more I read the more convoluted im starting to think the line is... maybe it is as simple as an Atmega and people are just whiners. What im looking for is for a vendor of arm chips that makes it easy to just choose a chip with the peripherals you need and start programming it, i.e. i guess where the standard libraries are the same across most or all of the same chips, not necessarily register names and pin out though.

author: Yansi
author_rank: Super Contributor
timestamp: January 25, 2015, 03:14:32 am
content: "I want is to learn how to use an ARM chip at the lower level"Nicely done, I appreciate that.If you'd like to compare ARMs ant AVRs, I can partly tell ya, that an Cortex M0 (STM32F0) series is "like atmega", but 32bits adult only edition.With Cortex M3 or M4 or now the new M7, things start getting complicated more and more.If you really want to take ARMs from the basic, I'd suggest staaring with an M0 and go for bigger then. A good choice is STM32F0-DISCOVERY. There is an Cortex M0, STM32F051RB. Or the F0 VL (there is an F030 chip, simillar to F051, but a little bit stripped). Then I'd suggest visiting F1 series, with an F103 NUCLEO. And then whatever you want (again my suggestion is 32F429I-DISCOVERY )QuoteIf you mean old AVRs (yes, now almost obsolete) atmegas and attinys, there are big differences from chip to chip. Especially microchip is an expert for having each 8bit chip different.The advantage of ST's stuff is that we keep the series of STM32 compatible as much as possible, so it is easy to switch between chips or sometimes between series. For example, if you have TIMER1, you can be almost sure, it is an advanced control timer and will have same functionality in a serie and almost same between series. I admit, that the documentations isn't always as good, but you will quickly learn how to orient in the documentation (datasheet, reference and programming manuals)Going from vendor to vendor is a big leap every time... But once started, fear dissapears.QuoteSometimes I think the same, when seeing different sort of arduino style slap-together masterpieces.Yes, StdPeriph library is almost the same on every series. Sometimes only modified a little or with added functionality to fit the exact specifics of that chip or series. Unlike HAL, which tries to be standard as a law, and then must be bent with much effort to meet the specifics. And some functionality is not even implemented in HAL, which is getting designers angry, bending the HAL libraries yourself is not so easy, HAL is sometimes just overcomplicated.Most of the peripheral types are shared across the MCU families. So are the register names. If you learn them on F0, most of them will be similar on any STM32.Good you have mentioned the pinouts. They are compatible on most chips with the same package size. So you can just take F407 discovery boad and swap to chip for f205 and make a custom discovery board that way (because F2-discovery does not exist). An the F2 and F4 series are similar in many things.I will add som more info "tomorrow", now I'll tak a nap, 4:14AM the clock told me. Crazy.

author: westfw
author_rank: Super Contributor
timestamp: January 25, 2015, 05:08:22 am
content: QuoteHow do you figure that? Complexity (especially with C) goes up with the peripheral set, rather than with the core. It's true that the "faster" cores tend to come on the same chips with more and more complex peripherals, but that's just a coincidence.

author: dannyf
author_rank: Super Contributor
timestamp: January 25, 2015, 01:50:56 pm
content: QuoteWait to be shocked,Pick a datasheet and read it yourself to see what's involved. No need to guess.

author: Yansi
author_rank: Super Contributor
timestamp: January 25, 2015, 03:09:44 pm
content: Here's the shocker, try urself(for a STM32F051 from the F0-DISCOVERY.. it is a basic, entry level ARM MCU)Datasheet:http://www.st.com/st-web-ui/static/active/en/resource/technical/document/datasheet/DM00039193.pdfReference manual:http://www.st.com/web/en/resource/technical/document/reference_manual/DM00031936.pdf

author: Jeroen3
author_rank: Super Contributor
timestamp: January 25, 2015, 03:57:35 pm
content: With most vendors, the peripherals are just bought drop-in blocks of HDL. As is the Core itself.They work the same registers and they have the same address offsets. However, some vendors tend to make a mess of the header files translating these address offsets into usable C names across the product families.

author: dannyf
author_rank: Super Contributor
timestamp: January 25, 2015, 04:18:08 pm
content: QuoteYou probably want to check a few datasheets to be sure.Those peripherals are vastly different from vendor to vendor, and sometimes from family to family and chip to chip.

author: Yansi
author_rank: Super Contributor
timestamp: January 25, 2015, 04:26:23 pm
content: QuoteI smell bullshit hereI can sure you, that ST implements their own peripherals. (so is thefamousI2C peripheral on F1, 2, 4 series, as well as L4 and L1 has the same I think)And really no, offset or base addresses are not same between vendors. Where did you get that?ST's header files for registers are pretty nicely done, but I haven't much to compare that to.

author: KM4FER
author_rank: Regular Contributor
timestamp: January 25, 2015, 05:33:57 pm
content: OK folks, here's my take on this.Learning new hardware is pretty easy. Most of the time there is quite a bit of documentation available and the biggest problem is wading through it to find the bits and pieces you need. Sure, there's the occasional undocumented quirk or misunderstanding on your part that can be frustrating but generally you can work through them.Well conceived, designed, written and documented libraries can save you a lot of effort but .... If any of those requirements are missing then your life can be hell. For the most part I use libraries for large and/or complex chunks of code that it would take me forever to write. For simple or small tasks I just write the code myself and get on with it. Once you've done it once you have a piece of code that you understand and can easily modify to meet your new needs. Trying to modify somebody else's library to make it work with your new device can be alluring but quickly become a nightmare since the deeper you go into the code the less you understand and the more likely there will be side effects of a "simple" change.And, call me a control freak if you want, but I hate black magic. A compiler should be just that, a compiler of your code and not interject code that it thinks you need.earl...

author: Yansi
author_rank: Super Contributor
timestamp: January 25, 2015, 06:37:21 pm
content: Modifying StdPeriph is mostly unnecessary, but when needed, modifications are straightforward. StdPeriph consist of independet and simple commands, which are accurately named and mostly reading help is not needed, it is enough just to find he right name of a command in the header file.The Cube/HAL, uses mostly complex code, callback handling everything and messing with settings of peripherals when you even don't know it is beeing done. It is a nightmare to go throug the code, to bend the library to let's say not to use half-transfer complete intterupt in DMA (just an example). It gets you really angry, if the core is woken up halfway through some lowpower transfer from memory to a communication hardware.For those curious, HAL and StdPeriph is not compatible in any means. Porting older StdPeriph applications to Cube is damn laborious and time consuming. I have ported I think two small apps to Cube, that was horrendous. I wouldn't recommend anybody to do that, unless it is a command from your boss.

author: zapta
author_rank: Super Contributor
timestamp: January 25, 2015, 06:46:03 pm
content: Quote from: rwgast_lowlevellogicdesin on January 25, 2015, 01:59:36 amIf you are 'upgrading' from Arduino/AVR/PIC to ARM you may want to check the ARM PRO MINI.https://github.com/zapta/arm/tree/master/pro-mini#arm-pro-miniI was in exact situation as you, got a ST board, didn't like it for several reasons and after researching the ARM scene came up with the APM. Simple, effective, supports all three OSs, single install fully featured IDE (or use mbed.org if you prefer), can easily we derived into your own custom PCB designs, and doesn't require any adapter or software for in filed firmware upgrades. You can start with a simple program and then dive deeper, closer to the hardware as you like.This is for example my abstraction of digital i/o pins, working directly with the registers. You can write your own if you like.https://github.com/zapta/arm/blob/master/pro-mini/lpcxpresso/arm_pro_mini_lib/inc/io_pins.hIf you are are familiar with the AVR registers, you should be able to understand the ARM registers. They are actually easier IMO.https://github.com/zapta/arm/blob/master/pro-mini/resources/LPC11U3X/LPC11U3X_user_manual.pdf?raw=true

author: Yansi
author_rank: Super Contributor
timestamp: January 25, 2015, 07:08:31 pm
content: Offering mbed rubbish to someone, who said he wants to learn low level, is out.Whats wrong with ST boards? That would be interresting to know.By the way, if I remember it right, we talk about STM32 (rwgast wants them). Not NXPs LPC.And also, Keil or IAR is a single install, but professional tool. The only other neccessary install is the driver for STLINK, which is fully featured HW debugger and is present on every* ST board.*some older EVAL boards like STM3210E doesn't have STLINK onboard.Does your board have any debugging capability built in? I think not. That is a fatal flaw for a beginner. Understanding the behavior of some more complex peripherals is simply impossible without it.Does user get a fully featured SWD/JTAG capable programmer slash debugger with your board, usable for programing external devices? No. Almost every ST DISCOVERY or NUCLEO board have that.And note, that every STM32 has internal loader code inside, from the moment it leaves the factory. You can easily feed the MCU via UART, when crisis strikes.Hundreds of example projects are offered for ST products.So I don't see any advantage using your board instead of ST DISCOVERY / NUCLEO board. But that's my opinion, I do not constrain anybody. Only trying to think practically.

author: zapta
author_rank: Super Contributor
timestamp: January 25, 2015, 08:28:04 pm
content: Quote from: Yansi on January 25, 2015, 07:08:31 pm>> Offering mbed rubbish to someone, who said he wants to learn low level, is out.Nothing prevents using low level register access with mbed or Arduino. It's a matter of choice. ARM PRO MINI also works very well with lpcxpresso, a fully featured local IDE software (a single package install, works on all three OSs).>> Whats wrong with ST boards? That would be interresting to know.Didn't fit my needs for a few reasons. For example, the board was too complex, I prefer a minimal board that I can use as a starting point for my custom PCB designs. Also, I didn't find a free single package install IDE that runs on all three OSs. This is very important to make OSH project more accessible.>> By the way, if I remember it right, we talk about STM32 (rwgast wants them). Not NXPs LPC.That what I though initially but then I got the feeling that he has a more general interest in ARM and is more or less where I was a few months ago.>> And also, Keil or IAR is a single install, but professional tool. The only other neccessary install is the driver for STLINK, which is fully featured HW debugger and is present on every* ST board.NPX gives it for free and with no need to install drivers. Yes, it also supports HW debuggers, single stepping, breakpoints, register evaluation, expression watching, etc.>> Does your board have any debugging capability built in? I think not. That is a fatal flaw for a beginner. Understanding the behavior of some more complex peripherals is simply impossible without it.Yes, it does, a SWD header.>> Does user get a fully featured SWD/JTAG capable programmer slash debugger with your board, usable for programing external devices? No. Almost every ST DISCOVERY or NUCLEO board have that.If needed, you can attach a $20 debugger via the SWD header. I prefer to have the target board separated from the debugger, this is a more realistic scenario for custom PCBs. My end goal is not just to program evaluation boards but have my own designs. The ARM PRO MINI makes the transition to own design much easier, similar to the Arduino Pro Mini.>> And note, that every STM32 has internal loader code inside, from the moment it leaves the factory. You can easily feed the MCU via UART, when crisis strikes.Yes, but it requires the user to install software for field firmware upgrade. The LPX11U35, doesn't, it just requires a standard USB cable and a standard file copy operation.>> Hundreds of example projects are offered for ST products.Good. The important thing are documentation,, drivers and driver example, not complete applications.>> So I don't see any advantage using your board instead of ST DISCOVERY / NUCLEO board. But that's my opinion, I do not constrain anybody. Only trying to think practically.I do and I chose the configuration of the ARM PRO MINI was chosen to be very practical. Suggesting that ST is the only good solution is not serious. Mine went to the trash (literally) because I found something that fit my goals better.

author: Yansi
author_rank: Super Contributor
timestamp: January 25, 2015, 09:16:59 pm
content: Combining register access with mbed, what a glorious joke.Whats complex on such a F0 DISCOVERY board? There's only 64pin MCU with neccessary supply decoupling. (Plus the standalone programmer, which can be easily disconnected). What more minimal would you need? Don't like the programmer? Snap it off the NUCLEO board.Awww... OSH.. That explains everything. I usually do not do OSH, or support for other OS. I just dont care about apple, and unix people usualy help themselves better, than I possibly could.What gives NXP for free? Professional design tools specific for the purpose or some huge eclipse/GCC nest? Have you ever tried such a Keil or IAR?QuoteI think you didn't understood my question. Your board has no capability of debug on its own, you need $20 + shipping + other turd $$ external programmer. This is only a complication, istead of having a single plug-and-work board for half the price.QuoteThis makes no sense. On the first side you have a complete development board, on the other the application. What is the real advantage having development board separated in many pieces? Is this some illness from OSH, that every HW must be separated into so called "shields"? And as you said, it is only a preference, not any advantage.Conclusion: With STM boards, beginner simply takes a board, and can work with it, having the full featured debugger already integrated on board, without the need of investigating how to connect those together.As for the STM32 bootloader, I've mentioned the UART. If it is not enough, then read thishttp://www.st.com/web/en/resource/technical/document/application_note/CD00167594.pdfOn NUCLEO boards with STLINK v2.1, mass storage file-copy programming also works. But as I (tried to) explain you, having no debugger is a crapped way how to begin with ARM. ARM is not an atmega328. It's not as stupid as arduino is, learning it without a debugger is almost impossible to do. (Or if you do, I suspect, the highest achivement is mbed and slaptogether libraries).As I should remind you,rwgast_lowlevellogicdesinwants to learn the proper way, from basics, low level. It is simply a waste of time for him, to begin with such things like mbed. It won't help him with anything.QuoteThats exact. Fits you, notrwgast_lowlevellogicdesinwho I am trying to help, suggesting a solution.Maybe I am too much affected by professional design, that's why I hate all that mbed and arduino stuff. But I have no problems with OSH. OSH is a really good thing, but must be done properly, so one could even use that to learn something. If I sounded to much offensive, sorry for that, but I really hate mbed and anything related to that. I would really like to help him, because it is a small mirracle, when someone has an interrest to acually learn MCUs properly. So I am defending him from the mbed world, not offending you or your work.PS: ST offers a set of example codes for each peripheral on each productline of chips. These multiple examples are indeed useful for beginner and/or anyone else.Y//EDIT: Summary:ARM PRO MINI:- small- nothing on it- no debug (except using external tools)- bootloader code inside- single install IDE (but not sure if that is an advantage)ST-DISCOVERY / NUCLEO- bigger, because it simply uses MCUs with higher count pin packages- sometimes useful hardware appears directly on the kit, such as: e-Ink display, STN LCD display, sound codec, MEMS microphone, USB OTG, gyro/accel or compass, external RAM, TFT LCD, power conversion stuff,...- bootloader also inside, including USB, CAN, (ETH*?)- no ide obtruded with that, free for your choice. (uggesting use of KEIL or IAR.)- professionally written code examples, no mbed.- HW debugger onboard, allowing to program&debug MCUs off board.*not sure how it works, haven't worked with it yet.Not much diference between those, but the requirement was STM32, so am I glad to help with that.

author: asgard20032
author_rank: Regular Contributor
timestamp: January 25, 2015, 10:21:48 pm
content: KEIL and IAR have code limit at about 16kb (or it was 32kb). This is a huge restriction, not because everyone will make 80k program, but more because it mean if you have a discovery board with 64k, you can't use the potential of it, you are restricted to half or quarter of it. Also, even if the program size is small, if we need to store some lookup table, some array for image (if driving a display), we can't. Also, when i look at keil or iar, it look like windows 95 era (i am talking about the visual look and layout)Else, I agree, STM has lot to offer, way more people are using it, more documentation, an IRC around it.For the IDE, I have to thumb up ATMEL, TI and NXP for at least, providing something usable to do everything and use all the potential of the mcu, even if its not perfect. Even freescale now give their IDE free. Its a matter of time (maybe 6 month - 2 year) before ST start offering a derivative of eclipse with gcc equipped with all the header and linker script for their mcu line.NXP has a limit for their IDE, max 256 kb flash. I doubt someone learning or a hobyist will use device with 256 kb in the near futur. And if it do, then it mean he has mastered the mcu (since 256 kb is a big project, and usually, people will have done many small project before a big). And once the mcu is mastered, maybe its time to learn more how to set up a toolchain.I currently own 3 discovery board, but no IDE to use them.What is OSH?What is OSH?

author: zapta
author_rank: Super Contributor
timestamp: January 25, 2015, 10:26:23 pm
content: Quote from: Yansi on January 25, 2015, 09:16:59 pmOK

author: dannyf
author_rank: Super Contributor
timestamp: January 25, 2015, 10:45:17 pm
content: QuoteA little google would help: CoIDE, or emblocks, for example.

author: dannyf
author_rank: Super Contributor
timestamp: January 25, 2015, 10:49:09 pm
content: QuoteThe utilitarian look is exactly why I liked them.Plus, you can always hook an external editor in the IDE.QuoteI doubt someone learning or a hobyist will use device with 256 kb in the near futur. I think all the arguments you laid out earlier against the 32KB limitations apply to the 256KB limitation as well.

author: dannyf
author_rank: Super Contributor
timestamp: January 25, 2015, 11:18:34 pm
content: Aside from those gifted few, many newbies will likely find it daunting to understand the ARM architecture, code in assembly, deal with those tens of registers to operate just a simple peripheral on those devices, etc., and generally be overwhelmed and frustrated.Other people can help point them in the right directions but end of the day, they have to make those mistakes themselves so they will truly understand why people were pointing them in certain directions.So I would suggest that everyone chill off and take it easy.

author: zapta
author_rank: Super Contributor
timestamp: January 26, 2015, 01:33:49 am
content: Quote from: asgard20032 on January 25, 2015, 10:21:48 pmOpen source hardware (and firmware). You want to make this kind of designs easily accessible for mixing and reuse.

author: westfw
author_rank: Super Contributor
timestamp: January 26, 2015, 01:52:16 am
content: QuoteI think you're implying the MBed is NXP-only. While that was true, originally, MBed has expanded and now supports assorted NXP, ST, Freescale, and Nordic eval boards (including most of the ST "Nucleo" Eval boards.) Yeah, it's probably not a good choice if you want to learn low-level things. But it's nice to have around.Don't forget the "one dollar" and "ghetto" ARM threads?https://www.eevblog.com/forum/microcontrollers/one-dollar-one-minute-arm-development/https://www.eevblog.com/forum/microcontrollers/stm32-ghetto-style/

author: asgard20032
author_rank: Regular Contributor
timestamp: January 26, 2015, 03:05:23 am
content: It would be nice to have a comparaison of the available free IDE. Anyone used them?Em::Blocks VS CoIDE vs emIDE

author: hydrabus
author_rank: Contributor
timestamp: January 26, 2015, 06:41:36 pm
content: Hi,I'm the author of an Open Hardware/Firmware HydraBus/HydraFW and I recommend Em::Blocks.My project hardware is available on github:https://github.com/bvernoux/hydrabusMy project firmware is available on github:https://github.com/bvernoux/hydrafwAlso it support makefile with GCC ARM (for those who hate IDE)Actual firmware v0.4+ do lot of things I2C, SPI(Slave/Master), UART,like an advanced Bus Pirate / GoodFET as my project is based on STM32F405 32bits CortexM4F @168MHz, 1MB flash ....Best RegardsBenjamin

author: Yansi
author_rank: Super Contributor
timestamp: January 26, 2015, 06:55:51 pm
content: QuoteHow did you get that feeling? Mbed is rubbish independently on what architecture it is on.There is no advantage using the ARM PRO MINI board for a beginner like rwgast, who likes to learn things properly.F0-DISCOVERY has same Cortex M0 core microcontroller, but with more advanced peripherals, compared to the NXP chip on the armuino. Only omitting the USB, which beginner won't need though. Recommended price of F0-DISCOVERY is $10 and for that price you get the same minimalistic board, but with a HW debugger, which is essential for learning such a complex stuff like ARM. Just reminding, that the STLINK on the DISCOVERY board is usable without any restrictions for programinng the onboard or offboard chips. So for $10, you have a board with a chip to learn and HW debugger, easily usable to program offboard chips. No external programmers are needed.The NXP armuino board doesn't offer anything better, doesn't have debugger and with an external debugger the price is more than two times bigger, that the cost of single F0-discovery.Thats all what I wanted to say, now it rwgast's turn to make a decision.Offer him better board with a HW debugger for the same price and I have no problem with it.Here's the datasheet for a comparison, for those curious:Datasheet STM32F051R8T6

author: Mechanical Menace
author_rank: Super Contributor
timestamp: January 27, 2015, 02:17:57 am
content: Quote from: Yansi on January 26, 2015, 06:55:51 pmComing at this purely from a software view I'd say a fully fledged debugger of any type can really make you miss the forest for the trees. For most debugging a few well placed "printf"s are generally much more use for learning or even most serious problem solving than firing up gdb for everything.

author: zapta
author_rank: Super Contributor
timestamp: January 27, 2015, 03:01:49 am
content: Quote from: Mechanical Menace on January 27, 2015, 02:17:57 am+1I have a hardware debugger and it sits in the drawer. There are better way to debug code including working directly with the hardware.That 'my way is the only way' approach is not serious.

author: Jeroen3
author_rank: Super Contributor
timestamp: January 27, 2015, 06:35:04 am
content: Quote from: westfw on January 26, 2015, 01:52:16 amThe original mbed does not force you to use mbed libraries.It is a LPC176x with a co-processor, some LPC21xx, doing the USB MSC and USB-VSC, and the programming.The LPC21xx runs CMSIS-DAP since recently, becoming a full featured debugger.Making it competitive with STM's Discovery boards.Their mbed lib stuff is a bonus for when you want to do some rapid prototyping. But you're still able to run your own binary on the thing.A debugger is always worth it. You can learn to understand the compiler assembler much better by running it on actual hardware than the never-complete simulators.

author: rwgast_lowlevellogicdesin
author_rank: Frequent Contributor
timestamp: January 27, 2015, 07:22:48 am
content: Ok let me clear some things up! I am interested in using things like HAL, RTOS, and maybe EMBED (if like arduino you can use the librarys for RAD, but manipulate the bare metal easily when speed and flexibility are needed) but I refuse to use any of that stuff until I have learned how whatever ARM series I pick works. Right now I am learning ASM for the 8 core 32 bit Parallax Propeller, and the original z80 cpu. Im working on a hardware project to use the propeller as an eeprom, and peripheral emulator for the z80. I am doing this because I want to learn how computers work, and learn it well on an easy platform. I love the Propeller MCU (and soon the 200mhz Propeller 2) the problem is there 8 bucks a pop!I would like to start building some project I could possibly put on kickstarter or use as a portfolio for consulting in the next few years. Im currently an industrial (mostly power plant) electrician , and I would like to grow a small electronics die business that may take off in to a career change one day! Looking down that road I realize to be viable in the market I need to know ARM chips, there cheaper than Atmegas in bulk, and there much more powerful.I ordered the STM32VL Discovery board the book I linked to in my first post uses, as I mentioned I also own the f0, l1, and f3 boards, so I figure I can learn on and f1 and port to the other chips when I know more about whats going on. Im not stuck on ST, its just that they seem to be ahead of the pack most of the time and theres a great e-book about them. I also own a cortex m3 asm book, and he definitive guide to the arm, but those books will get me no where as an ARM beginner. I just dont see any books out there for NXP, Stellaris, or LPC that are geared twords teaching an ARM newb the basics of there peripheral set, without using some abstracted library like EMBED. After I have learned more about ARM micros, I would live to use some of my PSoC 4 stuff to tell you the truth.. in the long run its the only arm based chips I think are more innovative than ST's. But once again that's a whole other experience to learn correctly, which includes some VHDL.I am a firm believer in OSH, I use linux and windows. CoIDE and ARM GCC will work on both. Im an android kernel junkie so I already know whats involved in setting up a gcc based tool chain for a new platform. Yes its a headache but once it works, it takes five minutes to set up again, later! On the other hand I have a full copy of IAR for arm too, and will most likely use that to get off the ground at very first since it comes with tons of examples and it just works without any tinkering, unlike a GCC/CoIDE or Eclipse set up.

author: dannyf
author_rank: Super Contributor
timestamp: January 27, 2015, 12:04:22 pm
content: QuoteBecause such a book would have very limited value, especially to a newbie - just think about your case: in spite of the fact that you have F0, F3/F4, you had to buy a F1 to just use the book. The portability between those chips is actually very good and the F1 examples can be easily changed to run on F0/F3/F4. But for a newbie, that can be almost in-surmountable.So a book on LPC17xx series is only attractive to a newbie learning LPC17xx series -> very limited value, both to the buyer and to the writer.QuoteYou should take a look at the datasheets to get a sense as to how doable such an approach is to you.

author: Kjelt
author_rank: Super Contributor
timestamp: January 27, 2015, 01:06:39 pm
content: Quote from: Yansi on January 25, 2015, 03:14:32 amSo you are related or work for ST, might have been nice to share that information upfront.Not that I have anything against ST, they make great chips (except the I2C peripheral which caused me so much headaches i want to forget about it) and from F2 upwards the libraries are pretty standard, the F1 being the great exception or are those rewritten in the mean time to have a compatible API?

author: dannyf
author_rank: Super Contributor
timestamp: January 27, 2015, 01:17:11 pm
content: QuoteYeah. Well known and well documented. Someone at ST should be canned for that.The other exception is their approach to libraries -> first the standard peripheral libraries and then HAL: incomplete and wacky. ST doesn't understand why people use libraries. In that department, they should take a lesson from TI.One more, as I am on a roll here: ST's website. I have not seen a more retarded website, of all electronics companies. ST's website must have been designed by NXP,

author: zapta
author_rank: Super Contributor
timestamp: January 27, 2015, 01:25:17 pm
content: Quote from: Kjelt on January 27, 2015, 01:06:39 pmOK, this explains that narrow view.

author: Kjelt
author_rank: Super Contributor
timestamp: January 27, 2015, 01:29:22 pm
content: Quote from: dannyf on January 27, 2015, 01:17:11 pmOk mistakes do happen but to keep the *(&^*&^*& peripheral with all the bugs as is in all newer releases is ... is .... (I have no words for it)ST: FIX IT! or buy the I2C peripheral from NXP.

author: Yansi
author_rank: Super Contributor
timestamp: January 27, 2015, 01:45:27 pm
content: Some people have mentioned here debugging with "well placed printf...".. Oh boys, come on... have you ever debugged any serious stuff?Printf debugging (via SWO or UART or anything) is indeed helpful, but that only helps with software algoritmization issues. When it comes to fiddling with peripherals, printf becomes useless.One nice and easy way for learnig how peripherals work, is just to take the debugger and play with the bits. Most peripherals can be learnt that way.. like RTC, ADC, USART, SPI, I2C (on the above mentioned F0 it should work fine)... And learning ARMs is mostly about the complex peripherals (NXP fanboys doesn't understand that, their peripherals are pretty straight)dannyf: That's all about the ST's marketing people. StdPeriph was good, but the headquarters decided to abanon that, just because it is old (and maybe to much hard to use for arduino whiners - so more arduinistic library must have been made). Simply, marketing and engineering do not mix.:-)

author: dannyf
author_rank: Super Contributor
timestamp: January 27, 2015, 01:53:57 pm
content: QuoteSWO is infinitely better than printf.RTT is infinitely better than SWO.J-Scope is infinitely better than RTT.As is FreeMaster.That should give you some sense how last-millennium "printf() debugging" is.

author: zapta
author_rank: Super Contributor
timestamp: January 27, 2015, 02:10:40 pm
content: Quote from: dannyf on January 27, 2015, 12:04:22 pm+1OP, being able to interpret vendor's documentation and examples is a very valuable skill and is doable. Start with a canned hello world and start digging one peripheral at a time. I did it recently switching from atmega328p to lpc11u35 and it's just the same, a bunch of registers that you need to manipulate based on vendor's documentation. If you hit a snag, search the internet or ask. Time and patience are your friends.

author: Mechanical Menace
author_rank: Super Contributor
timestamp: January 27, 2015, 04:44:00 pm
content: Quote from: dannyf on January 27, 2015, 01:53:57 pmAnd for a lot of things they are overkill and printf or printk or whatever equivalent you have available works great , especially over a serial connection. Yes there are plenty of cases where you want a fully fledged debugger but for begginers if they NEED one they don't understand their code good enough to be able to use one.And if you think printf is sooo last millennium you wouldn't like my use of command monitors, and I guess we should give up on fire no matter how well it works because that's so mesolithic

author: Yansi
author_rank: Super Contributor
timestamp: January 27, 2015, 06:30:20 pm
content: QuoteThis is utter garbagge nonsense.

author: zapta
author_rank: Super Contributor
timestamp: January 27, 2015, 06:37:19 pm
content: Quote from: Yansi on January 27, 2015, 06:30:20 pmIt's OK to disagree but no need to be rude. It doesn't reflect well on you and you cause.

author: Yansi
author_rank: Super Contributor
timestamp: January 27, 2015, 07:03:35 pm
content: That wasn't meant to be rude. But after a few pages of this thread, talking about the complexity of ARM peripherals, someone suggests using printf-style debugging, for a beginner?! With the excuse of "otherwise he doesn't understand his code"?Sorry, but that really is a pure nonsense.Beginner should just have resources to get that insight, what he's doing. With a printf, he get's nothing, because beginner even couldn't know how to redirect the putchar to UART or somewhere else.Or why do you think, almost every average university teaches MCU programming with a simulator and/or debugger instead of "printf"?

author: Brutte
author_rank: Frequent Contributor
timestamp: January 27, 2015, 07:32:24 pm
content: Quote from: Yansi on January 27, 2015, 07:03:35 pm+1The printf..ing and programmer are of little use when you have a debugger.. Nowadays, (unless you pick Atmel who still charges >$50 for that), the full-featured debuggers are give-aways.Printf..ing could be used for some tasks like logging or when your target is at remote location and you simply cannot connect JTAG with 100m usb wire to it. Of course programmers also have their niche on a production lines where you just need to flash zillions of uC one by one.But during the development the ability to stop the target on selected trigger, to sniff the ram content, analzyze the stack, step through the code, dump some array and substitute with another one is invaluable..

author: hydrabus
author_rank: Contributor
timestamp: January 27, 2015, 07:38:07 pm
content: Quote from: Yansi on January 27, 2015, 07:03:35 pmPrintf is not always the best for embedded debugging especially for problems with timing and can even be the cause of crash in some cases.So I recommend to use a debugger with SWD/JTAG and Em::Blocks which support it natively which can be used to checks peripherals too ...Also for critical routines debugging (like hw protocol spi/i2c/uart/gpio...) an oscilloscope and/or a logic analyzer is a must have (to check timing of part of the code switching a GPIO ON/OFF is very good practice too).Before to debug with JTAG/SWD build the code in "Debug" mode (-O0 -g3) else it's very hard to execute code step by step with optimized code as it does not correponds to C code in lot of cases.Best RegardsBenjamin

author: zapta
author_rank: Super Contributor
timestamp: January 27, 2015, 07:39:38 pm
content: Quote from: Yansi on January 27, 2015, 07:03:35 pmIt's not 'really', it's your opinion.I have a debugger in the drawer and didn't touch it for example when writing recently a SPI driver.There is more than one way to skin a cat.

author: Yansi
author_rank: Super Contributor
timestamp: January 27, 2015, 08:10:37 pm
content: Sure, every beginner can write SPI driver on STM32, without debugger and without previsous experience with such thing...Am I in some parallel universe? Or dumb enough that I spend my time talking with people, who think debugger is not necessary piece of equipment for a beginner? Maybe both...I think I'm done here.

author: Jeroen3
author_rank: Super Contributor
timestamp: January 27, 2015, 09:52:18 pm
content: The discussion to debugger to not to debugger has already been conducted on this forum. Somewhere...A debugger gives you:- Data snapshots.- Live assembler.- Access breakpoints!( when your pointer kung-fu is failing )- Tracepoints (if you pay)- Logic analyzer (if you pay)A well placed printf gives you:- Real time,non-invasivestatus display of the program(s)- An indication on where to throw your breakpoints.- Fault handler data in a human readable form.- Asserts (aka, your mistakes)More helpful with proper tooling,https://github.com/Jeroen6/MultiTerminalPeople should figure out if the debugger is helpful for themselves.It's not worth a discussion imho.

author: paulie
author_rank: Frequent Contributor
timestamp: January 28, 2015, 01:07:40 am
content: Quote from: Yansi on January 27, 2015, 08:10:37 pmProbably neither. Maybe just dumb enough to think a beginner can benefit at all from the complexity of a debugger let alone need one to learn. Or more likely too smart to see the truth.Internet hotshots fall into two categories: those who honestly forgot what starting out is really like. And then there's those who generally just want to show off how smart they are and not so much out to help noobs. They do pretend though.

author: Kjelt
author_rank: Super Contributor
timestamp: January 28, 2015, 10:25:06 am
content: Yep personally I use them both whenever they are most suited and I do use another one: a PC.The PC with c compiler I use for debugging / rigorously testing algorithms or complex c routines (KAT testing), all above the HAL ofcourse, below the HAL the PC is useless.