Atmel ARM Cortex (or NXP? or STM32?)

[theatrus]

LPGPL is still going to be troublesome. I used to be a staunch supporter of the *GPL, but recently practicality has pushed most of my code to MIT or Apache licenses. There isn't much point in the *GPL unless you are actually going to fight the license. Might as well get as many people as possible contributing to a code base with a more liberal license.

[gmb42]

What link script generator was that, I don't see any reference to one in the previous posts, can you share a link?

Check the libopemcm3 github page: https://github.com/libopencm3/libopencm3/tree/master/ld

Thanks.

[azmat.bilal]

Hi,

i am new to this forum and currently in process of selecting ARM MCU for a wearable MVP and need advice. i have to decide between Stm32F4 and atmels atsam G ( or 4L) series. both are cortex M4 while stm32F offers some extra stuffing like more memory etc. surprisingly they are in the same price range ( ~$4 @1000 pcs when checked at findchip.com and octopart). atmel has a plus that its development tool is quite well developed and free and for that reason i am inclined towards atmel. i want to know whether having a good and free development tool is a good reason to select atmel over ST, or is there a good solution i can use. also any pro's and cons for both series are welcomed as they will help me decide better. thanks.

[andyturk]

i want to know whether having a good and free development tool is a good reason to select [vendor X] over [vendor Y] ...

If you're building a hobby project or a small-run prototype, then sure, the free dev tools are a big part of the decision process. Look at the Arduino kingdom. Or, if time-to-market is the most important thing, then being able to use a development environment you already know is a big plus. That's why people love Keil and IAR.

Aside from that, no. Dev tools are only worth the effort you choose to put into them.

[poorchava]

I think STM32s have the most advanced peripherals, at the cost of larger complexity and steeper learning curve. Atmel is typically slower than ST and has completly messed up pinouts. On top of that they don't do much of IO remapping, where you can put eg. SPI of 2 different IO pins.

[pyrohaz]

I've used STM32 ARM series controllers for a year or so now with Coocox CoIDE IDE (free, http://www.coocox.org/CooCox_CoIDE.htm). I find it really easy to use, once the IDE is set up and drivers are installed, its as easy as program, build and flash. All flashing algorithms are taken care of in Coocox etc. One problem with the STM32 series is that the CS pin in the SPI peripheral has to be toggled "manually" (in code) I don't know if this is a massive problem to you because you may only need to toggle the CS pin at the start and end of your transfer to your ethernet IC. A problem to bare in mind however.

Setting up the SPI peripheral is also really easy with the ST standard peripheral libraries though some people find them clunky (I'm personally quite a fan of MOST implementations, don't get me started on STM32F0 I2C...).

If you're happy with a bit of breadboarding, the ST discovery boards are really good tools and most can fit one row of pins (usually with ample functionality) on a breadboard. Not forgetting that they're insanely cheap! In the UK, the new STM32F0 discovery board reps in at £6.19 (exc. p+p). The price of the IC's are also extremely cheap, the cheapest ST part on RS at 77p/chip, with the cheapest ARM Cortex Mx processor sold on RS at 76.2p.

[pyrohaz]

The Atmel IDE is currently unbeatable, as long as you are a Windows user. The combination of good datasheets and Atmel Studio make them hard to beat, even if the silicon doesn't have quite as many features as some of the competitors.

Oh, and their debuggers (JTAGICE3) are cheap and really good.

Thats a good shout actually, I forgot to mention that the STM32 discovery boards include an STLink V2 (both a programmer and debugger) 

[dannyf]

2nd the recommendation of CoIDE  - I am a big fan of it.

don't get me started on STM32F0 I2C

Yeah. The whole family suffers from that actually.

[gmb42]

If you're keen on STM32 also have a look at ChibiStudio.  Eclipse based IDE along with ChibiOS/RT, an interesting small scheduler that has a lot of drivers for STM32 peripherals.

[pyrohaz]

If you're keen on STM32 also have a look at ChibiStudio.  Eclipse based IDE along with ChibiOS/RT, an interesting small scheduler that has a lot of drivers for STM32 peripherals.

Hmm, that looks pretty cool, I've used CoOS a little but nothing more than learning how to toggle an LED in an RTOS. Kudos to Eclipse being so awesome for IDE's though!

[azmat.bilal]

thankyou guys for the advice. i have ordered stm32F4discovery kit as well as the atmels xplained pro kit ( both are quite cheap). ill start palying with stm32 board and IDEs you guys have mentioned and if after a week or so i find it hard to work on stm32 board, ill switch back to atmel.

[Ribster]

2nd the recommendation of CoIDE  - I am a big fan of it.

don't get me started on STM32F0 I2C

Yeah. The whole family suffers from that actually.

I'm not quite aware about the issues. A small recap please ?

[mrflibble]

don't get me started on STM32F0 I2C

Yeah. The whole family suffers from that actually.

Mmmh? An issue with the ST provided summer intern libs (don't care), or the hardware (do care)? Haven't had a reason to use I2C on stm32f0, but always handy to be prepared... A crappy hardware implementation would indeed be bad news, if that is what you mean here?

[mikerj]

2nd the recommendation of CoIDE  - I am a big fan of it.

don't get me started on STM32F0 I2C

Yeah. The whole family suffers from that actually.

It has to be one of the worst I2C slave implementations I've worked with.  Most of the STM32's peripherals are pretty reasonable though, and they offer excellent value compared to most 8 bitters.

[SirNick]

Hey, you guys know that if you turn the forum over, there's more room to write on the other side, right?

[mrflibble]

Hey, you guys know that if you turn the forum over, there's more room to write on the other side, right?

Parse error near *what you just said*. Wut?

[Psi]

I find most of the STM32 standard libraries for talking to the hardware are a bit hard to follow.
Without looking at the source i'm not sure what hardware registers each library call is changing.
For a standard library to work it needs really good documentation with lots of examples of how to set up the hardware for all the common tasks.
But all ya seem to get is a short sentence or paragraph describing the basics which were obvious from the start.

So I end up calling the registers myself, like with AVRs.

[andersm]

It has to be one of the worst I2C slave implementations I've worked with.  Most of the STM32's peripherals are pretty reasonable though, and they offer excellent value compared to most 8 bitters.

The early STM32 series (STM32F1, maybe others) had a really bad I2C peripheral, which AFAIK was inherited from the STM8 series. Newer series have a redesigned peripheral that at least based on a skim through the manuals fixed most of the problems of the old one. Are there still noteworthy issues with the new one?

[SirNick]

Parse error near *what you just said*. Wut?

I feel like we're playing microcontroller Mad Libs.

"I don't like this microcontroller because ________'s (vendor) __________ (product line) has a terrible _________ (feature) implementation!  For example it, always _________ (negative trait), AND, if you try and compile with ___________ (compiler or compiler option), the code will always ___________! (phrase describing an undesirable state)

Instead, I recommend everyone use __________ (competing product) which at the very least mentions its braindead ___________ (poorly-implemented peripheral or library) in the datasheet errata!"

I might consider buying someone an STM32 development board if they'll learn enough about its apparently well-known i2c flaws to fill in the blanks for the rest of us.

So far, all we know is it's really bad, has been bad for a while, and seems to be equally bad across the product portfolio.  Does it spontaneously catch fire?  Get stuck in infinite clock stretching?  Only communicate with peripherals whose addresses are prime numbers?  Nooooobodyyyyy knoooowwwwsss...

[andyturk]

So far, all we know is it's really bad, has been bad for a while, and seems to be equally bad across the product portfolio.  Does it spontaneously catch fire?  Get stuck in infinite clock stretching?  Only communicate with peripherals whose addresses are prime numbers?  Nooooobodyyyyy knoooowwwwsss...

I've seen a problem where the (STM32) I2C bus would become locked under certain conditions. For me, it usually happened while I was debugging and/or single stepping through driver code. As this never occurred in normal operation, it wasn't a big deal and I never fixed it. Brief research via google suggested that there was a "fix". To reset the other devices on the I2C bus, you take over the GPIO pins and bitbang a 100kHz clock on SCL for at least 50 cycles, or until SDA goes back high. At that point, you can reset the mcu's I2C peripheral and get going again.

[mrflibble]

I feel like we're playing microcontroller Mad Libs.

Ah, that. Yeah, I noticed component here as well. But best of all, if you get bored with this thread there are plenty more threads with Microcontroller Mad Libs going on.

I might consider buying someone an STM32 development board if they'll learn enough about its apparently well-known i2c flaws to fill in the blanks for the rest of us.

So far, all we know is it's really bad, has been bad for a while, and seems to be equally bad across the product portfolio.  Does it spontaneously catch fire?  Get stuck in infinite clock stretching?  Only communicate with peripherals whose addresses are prime numbers?  Nooooobodyyyyy knoooowwwwsss...

Yup. I'm still hoping that one the several posters that are in the know about the I2C suckiness will fill in the blanks for us.

I've only used stm32 as I2C master, and in every instance with only a single slave on the wire. And using chibios (as in no ST libs). I believe that all was at 100 kHz. So far everything's still working. But maybe it's something slave related, who knows.

And seeing the new reply ...

@andyturk:
Was that with the stm32 as i2c master or slave?

[andyturk]

Was that with the stm32 as i2c master or slave?

master

PS. Using the ChibiOS HAL too.

[mikerj]

It has to be one of the worst I2C slave implementations I've worked with.  Most of the STM32's peripherals are pretty reasonable though, and they offer excellent value compared to most 8 bitters.

The early STM32 series (STM32F1, maybe others) had a really bad I2C peripheral, which AFAIK was inherited from the STM8 series. Newer series have a redesigned peripheral that at least based on a skim through the manuals fixed most of the problems of the old one. Are there still noteworthy issues with the new one?

The device I lost a considerable amount of hair over was the STM32F103RE.  It appeared to be designed around a collection of poorly documented race conditions enclosed in a box marked "I2C".  It was slave operation that caused the most issues.

[Kjelt]

Yeah even st acknowledges the crappy i2c peripheral BUT has written a solution.
It is called something like I2CPAL and can be downloaded from their site, it is the only way of getting it to work properly.

[andersm]

The device I lost a considerable amount of hair over was the STM32F103RE.  It appeared to be designed around a collection of poorly documented race conditions enclosed in a box marked "I2C".  It was slave operation that caused the most issues.

I used a sibling device, the STM32F101. IIRC you had to follow different steps if you wanted to receive 1, 2 or three or more bytes. Since we could design the protocol in our application as we saw fit, we ensured we always transferred at least three bytes, which was the simplest case. The recommendation was also to use DMA or to reserve the highest priority interrupt for I2C and never disable it. Most of this nonsense seems to be gone in the "new" I2C peripheral.