Want to get started with ARM stm32

[Yansi]

With most vendors, the peripherals are just bought drop-in blocks of HDL.

I smell bullshit here

I can sure you, that ST implements their own peripherals. (so is the famous I2C 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.

[KM4FER]

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

[Yansi]

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. 

[zapta]

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.

If 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-mini

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

If 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

[Yansi]

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.

[zapta]

...

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

[Yansi]

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?

Yes, it also supports HW debuggers, single stepping, breakpoints, register evaluation, expression watching, etc.

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

I prefer to have the target board separated from the debugger, this is a more realistic scenario for custom PCBs

This 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 this http://www.st.com/web/en/resource/technical/document/application_note/CD00167594.pdf

On 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_lowlevellogicdesin wants 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.

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.

Thats exact. Fits you, not rwgast_lowlevellogicdesin who 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.

[asgard20032]

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?

[zapta]

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?

Yes, it also supports HW debuggers, single stepping, breakpoints, register evaluation, expression watching, etc.

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

I prefer to have the target board separated from the debugger, this is a more realistic scenario for custom PCBs

This 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 this http://www.st.com/web/en/resource/technical/document/application_note/CD00167594.pdf

On 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_lowlevellogicdesin wants 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.

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.

Thats exact. Fits you, not rwgast_lowlevellogicdesin who 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.

OK 

[dannyf]

I currently own 3 discovery board, but no IDE to use them.

A little google would help: CoIDE, or emblocks, for example.

[dannyf]

Also, when i look at keil or iar, it look like windows 95 era

The utilitarian look is exactly why I liked them.

Plus, you can always hook an external editor in the IDE.

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.

[/quote]I doubt someone learning or a hobyist will use device with 256 kb in the near futur. [/quote]

I think all the arguments you laid out earlier against the 32KB limitations apply to the 256KB limitation as well.

[dannyf]

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.

[zapta]

What is OSH?

Open source hardware (and firmware). You want to make this kind of designs easily accessible for mixing and reuse.

[westfw]

Offering mbed rubbish to someone, who said he wants to learn low level, is  out. 
By the way, if I remember it right, we talk about STM32. Not NXPs LPC.

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

[asgard20032]

It would be nice to have a comparaison of the available free IDE. Anyone used them?

Em::Blocks VS CoIDE vs emIDE

[hydrabus]

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/hydrabus
My project firmware is available on github: https://github.com/bvernoux/hydrafw
Also 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 Regards
Benjamin

[Yansi]

I think you're implying the MBed is NXP-only.

How 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

[Mechanical Menace]

but with a HW debugger, which is essential for learning such a complex stuff like ARM.

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

[zapta]

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

+1

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

[Jeroen3]

Yeah, it's probably not a good choice if you want to learn low-level things.  But it's nice to have around.

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

[rwgast_lowlevellogicdesin]

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.

[dannyf]

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,

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

without using some abstracted library like EMBED.

You should take a look at the datasheets to get a sense as to how doable such an approach is to you.

[Kjelt]

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. 

So 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?

[dannyf]

except the I2C peripheral

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

[zapta]

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. 

So you are related or work for ST, might have been nice to share that information upfront.

OK, this explains that narrow view.