Author Topic: Atmel ARM Cortex (or NXP? or STM32?)  (Read 49628 times)

0 Members and 1 Guest are viewing this topic.

Offline msrTopic starter

  • Regular Contributor
  • *
  • Posts: 73
  • Country: pt
    • rasgo.cc
Atmel ARM Cortex (or NXP? or STM32?)
« on: June 04, 2014, 10:04:10 am »
Hi,

Have anyone tried the Atmel ARM Cortex-based microcontrollers?
Im looking for a microcontroller with good performance and SAM4L seemed very interesting (AES and low power are nice additional features). I also need a bootloader and this series have SAM-BA pre-programmed but I would prefer something compatible with STK500v2 or more open-source (ie. some comand-line tool, cross platform and that can be freely distributable).

What's your opinion?
« Last Edit: June 05, 2014, 12:40:58 am by msr »
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 26755
  • Country: nl
    • NCT Developments
Re: Atmel ARM Cortex
« Reply #1 on: June 04, 2014, 10:44:02 am »
NXP's ARM controllers have a bootloader which allow programming over the serial port. There is also a Linux tool to program them.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8221
  • Country: 00
Re: Atmel ARM Cortex
« Reply #2 on: June 04, 2014, 11:25:30 am »
There are Atmel ARM powered arduinos out there so I am sure others have done it, if not that particular chip or family of chips.

Quote
I also need a bootloader

Many of them do, like STM32's for example. All you need is a serial program (HyperTerminal for example) and you are done.
================================
https://dannyelectronics.wordpress.com/
 

Offline Psi

  • Super Contributor
  • ***
  • Posts: 9889
  • Country: nz
Re: Atmel ARM Cortex
« Reply #3 on: June 04, 2014, 11:37:48 am »
STM32 seem to work well in opensource EmBlocks IDE out of the box, debugging works too.

Ive only used the one STM32F0 dev board but it was a simple matter of creating a project, selecting the STM chip and start coding :)

F0 has more power/features than a high spec $12 ATMega but with a $1.20 pricetag.
(except no built in eeprom)
« Last Edit: June 04, 2014, 11:43:39 am by Psi »
Greek letter 'Psi' (not Pounds per Square Inch)
 

Offline zapta

  • Super Contributor
  • ***
  • Posts: 6189
  • Country: us
Re: Atmel ARM Cortex
« Reply #4 on: June 04, 2014, 02:38:03 pm »
STM32 seem to work well in opensource EmBlocks IDE out of the box, debugging works too.

I couldn't find on EmBlocks site what OSs it runs on (ideally Mac, Linux and Windows).
 

Offline SirNick

  • Frequent Contributor
  • **
  • Posts: 589
Re: Atmel ARM Cortex
« Reply #5 on: June 04, 2014, 07:34:56 pm »
IMO, Atmel's data sheets are top notch, but the hardware lags behind NXP's equivalents.  NXP seems to have a better feature set, and at least from what I've seen, at a lower cost too.

OTOH, NXP's data sheets are not that great.  So it might be good to learn on a SAM, and continue using them were cost and peripheral selection are not prime concerns, then switch over to NXP when you really want to drive the thing hard, or to scale up for production.
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8221
  • Country: 00
Re: Atmel ARM Cortex
« Reply #6 on: June 04, 2014, 09:19:53 pm »
They both do a decent job there. NXP assumes that you have prior knowledge about the (kind of) devices so their datasheet may seem skimpy / cryptic to a newbie.
================================
https://dannyelectronics.wordpress.com/
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 26755
  • Country: nl
    • NCT Developments
Re: Atmel ARM Cortex
« Reply #7 on: June 04, 2014, 11:21:45 pm »
When looking at NXP devices make sure to read the user manual as well. The datasheet only contains a short description about the functionality and contains the electrical specifications. If you want to know what a device does and how it works you really need the user manual. Most of the user manuals for NXP's cortex devices also contain an extensive section about the ARM Cortex core.

I know needing two documents for a chip takes some getting used to but it makes sense to have the electrical specification seperated from the 'software' specification.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline msrTopic starter

  • Regular Contributor
  • *
  • Posts: 73
  • Country: pt
    • rasgo.cc
Re: Atmel ARM Cortex
« Reply #8 on: June 05, 2014, 12:40:32 am »
Ok, so I changed my mind and now Im trying to choose between NXP and STM32  ;D

In a first application I'll be using it to interface with a W5200 (ethernet chip from Wiznet) so one of the features Im favoring is SPI maximum speed. CPU max frequency is also important of couse so transfered data can be processed "fast". Other important parameters: low pin count (~48 pins), flash size (minimum 64KB), price and availability.
So taking these parameters into consideration I sumbled upon these parts:
- LPC1115 (64KB, 50MHz, SPI @25Mbit/s)
- STM32F051K8T6 (64KB, 48MHz, SPI @18Mbits/s)

Regarding the bootloaders. I know every ARM microcontroller has a preprogramed serial bootloader but as far as I know not all of them have cross-platform, open-source loader applications. I developed myself a loader for EFM32 some time ago and since it uses XMODEM protocol it was fairly easy to implement. LPC and STM32 use their own protocols which I suppose are well documented, but unfortunately I don't have the time to develop such application so I have to rely on what's already done and freely availabe. Thus, I found FlashMagic for NXP (closed, windows only) and stm32flash for STM32 (https://code.google.com/p/stm32flash/, not sure if it supports STM32F0x series).

Another very important thing: the toolchain! NXP has the LPCXpresso "platform" based on GCC, everything seems to be included and to work "out of the box". For STM32F Im not sure about the GCC support (linker files, startup code?).

Well... Can you help me deciding what mcu should I pick once again ? :)


« Last Edit: June 05, 2014, 12:42:46 am by msr »
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8221
  • Country: 00
Re: Atmel ARM Cortex (or NXP? or STM32?)
« Reply #9 on: June 05, 2014, 12:52:32 am »
STM32 has more features.

LPC has less bugs.
================================
https://dannyelectronics.wordpress.com/
 

Offline ve7xen

  • Super Contributor
  • ***
  • Posts: 1192
  • Country: ca
    • VE7XEN Blog
Re: Atmel ARM Cortex (or NXP? or STM32?)
« Reply #10 on: June 05, 2014, 12:58:41 am »
If you need Ethernet, why not choose an ARM with an Ethernet peripheral? Like STM32F107 (64/128/256KB, 72MHz, 100mbit Ethernet MAC, SPI @ 18Mbps, LQFP64).

stm32flash worked for me on a STM32F105 project, so should work with the rest of the series, and I believe the protocol is consistent across the F0 and F2/3/4 products as well, so should work.

Toolchain was a big challenge for me. Development files (linker scripts and startup files etc.) are included for two different GCC-based commercial products, as well as a proprietary one, but it still took me some steep learning curve to get it running. Now every time I go to work with these I have to wonder if my toolchain still works or if I'll have to go through that again... I think this is pretty much the case with any of them though if you're not going to use the provided tooling directly.

+1 on bugs, at least in the provided peripheral library for STM32.
73 de VE7XEN
He/Him
 

Offline SirNick

  • Frequent Contributor
  • **
  • Posts: 589
Re: Atmel ARM Cortex (or NXP? or STM32?)
« Reply #11 on: June 05, 2014, 01:15:23 am »
I agree with ve7xen.  Unless you have a legacy codebase using the WizNet, drop that puppy and go with onboard Ethernet.  Example NXP parts: LPC1768 (Cortex M3) or LPC4078 (Cortex M4).  BYO Ethernet PHY though.  I'm using the Micrel KSZ8041RNLTR (10/100 RMII-based) for a project in the works now.
 

Offline andersm

  • Super Contributor
  • ***
  • Posts: 1198
  • Country: fi
Re: Atmel ARM Cortex
« Reply #12 on: June 05, 2014, 04:33:35 am »
I know every ARM microcontroller has a preprogramed serial bootloader
This is not true at all. Most modern mainstream parts probably have one, but you definitely need to check the documentation to make sure.

Offline theatrus

  • Frequent Contributor
  • **
  • Posts: 352
  • Country: us
Re: Atmel ARM Cortex (or NXP? or STM32?)
« Reply #13 on: June 05, 2014, 04:41:19 am »
Certain LPC parts actually have a USB Mass Storage firmware update mode. It shows up as a tiny 32KiB FAT16 flash drive, and you can delete and write a new firmware image via Windows explorer.

Since it's kinda a hack, it's dodgy in Linux and OS X, but there is the "mtools" package which you can use to workaround the differences.

As for tool chains, it's somewhat of a pain since not everyone even ships linker files for all of the big three (plain GCC, IAR, Keil). IAR and Keil both have free 32KiB versions available.
Software by day, hardware by night; blueAcro.com
 

Offline Psi

  • Super Contributor
  • ***
  • Posts: 9889
  • Country: nz
Re: Atmel ARM Cortex (or NXP? or STM32?)
« Reply #14 on: June 05, 2014, 05:47:22 am »
Pretty sure EmBlocks also works with LPC, PIC, AVR, but ive not tried that

I really didn't like the toolchain/IDE that came bundled with the LPC dev board i got, cant remember what its called.

STM32 seem to work well in opensource EmBlocks IDE out of the box, debugging works too.

I couldn't find on EmBlocks site what OSs it runs on (ideally Mac, Linux and Windows).

I use it in windows, no idea if it can be run in linux. It's open source though, so it wouldn't surprise me at all.
« Last Edit: June 05, 2014, 05:54:08 am by Psi »
Greek letter 'Psi' (not Pounds per Square Inch)
 

Offline ctz

  • Contributor
  • Posts: 26
  • Country: gb
Re: Atmel ARM Cortex
« Reply #15 on: June 05, 2014, 09:10:37 am »
Another very important thing: the toolchain! NXP has the LPCXpresso "platform" based on GCC, everything seems to be included and to work "out of the box". For STM32F Im not sure about the GCC support (linker files, startup code?).

I've had good results with plain arm-gcc and http://libopencm3.org/ with STM32F4xx. libopencm3 gives you a measure of portability over lots of Cortex parts (though obviously lots of peripherals vary), a lot like CMSIS except with a sensible open source license.
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 26755
  • Country: nl
    • NCT Developments
Re: Atmel ARM Cortex (or NXP? or STM32?)
« Reply #16 on: June 05, 2014, 02:39:18 pm »
STM32 has more features.

LPC has less bugs.
Then they must have added more features to the STM32 recently. About 7 years ago I evaluated several ARM controllers. The offering from ST and Luminary where not a good fit. I tried to make something with the STR710 (ARM7TDMI core) but that controller is a complete joke. It is by far the worst microcontroller I have ever had to deal with. I also didn't like the flash speed was limited to much less than the CPU speed. What is the point of having a fast CPU? A couple of years later I looked at ST's ARMs again but still wasn't impressed. IMHO ST is trying to create cheap parts but they cut too many corners so the end result is just an incoherent kludge.

Back then I choose for NXP which turned out to be a good choice for me. Many of the peripherals found on the ARM7TDMI devices migrated to the ARM Cortex devices without much changes (mostly extra features) so I can reuse 99% of the hardware drivers I wrote.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline theatrus

  • Frequent Contributor
  • **
  • Posts: 352
  • Country: us
Re: Atmel ARM Cortex (or NXP? or STM32?)
« Reply #17 on: June 05, 2014, 03:11:39 pm »
If we wanted to talk about bugs we shouldn't forget the Luminary LM3 line (which TI bought). The fact that all references to these parts are gone from TIs website (unless you search by part number) should be a clue.

(Before that many parts were in eternal preview status for years. I wonder if my dev boards will become collectibles)
Software by day, hardware by night; blueAcro.com
 

Offline msrTopic starter

  • Regular Contributor
  • *
  • Posts: 73
  • Country: pt
    • rasgo.cc
Re: Atmel ARM Cortex (or NXP? or STM32?)
« Reply #18 on: June 05, 2014, 06:19:34 pm »
Thanks everyone for sharing your ideas and experience.

I've had good results with plain arm-gcc and http://libopencm3.org/ with STM32F4xx. libopencm3 gives you a measure of portability over lots of Cortex parts (though obviously lots of peripherals vary), a lot like CMSIS except with a sensible open source license.

I recognize the effort of libopencm3 but unfortunately I can't trust it for the time being.

Quote
The API of the library is NOT yet considered stable! Please do
           not rely on it, yet! Changes to function names, macro names etc.
           can happen at any time without prior notice!

However I was not aware of the linker generator for ARM GCC. That seems awesome, i'll give it a try!

If you need Ethernet, why not choose an ARM with an Ethernet peripheral? Like STM32F107 (64/128/256KB, 72MHz, 100mbit Ethernet MAC, SPI @ 18Mbps, LQFP64).

That was my first thought but its a matter of (lack of free) time. I want to build a "minimum viable prototype" and the time is running fast so the idea of having all the TCP/IP stuff done, by using the W5200, was appealing. I "just" want to send some TCP/UDP packets. In case I didn't find an appropriate ARM mcu to work with I was planning to use an EFM32LG for which I already have some code base.

But now Im considering it again.
Im planning to buy this board from Olimex: https://www.olimex.com/Products/ARM/ST/STM32-E407/open-source-hardware
The challenge: get a working toolchain for STM32F with arm gcc (not IAR), port the lwIP (olimex only provides some a very simple uIP example, but ST has an appnote for lwIP running on STM32F2x7xx), hope the ST Ethernet MAC library isn't buggy :P

I'll give it a try and let you know about how the things are going. If it takes too much time and hair and neurons, I'll get back to W5200 as a not-optimal but working solution.
 

Offline andersm

  • Super Contributor
  • ***
  • Posts: 1198
  • Country: fi
Re: Atmel ARM Cortex
« Reply #19 on: June 05, 2014, 06:51:59 pm »
I've had good results with plain arm-gcc and http://libopencm3.org/ with STM32F4xx. libopencm3 gives you a measure of portability over lots of Cortex parts (though obviously lots of peripherals vary), a lot like CMSIS except with a sensible open source license.
The LGPL license is troublesome for embedded software. Of course, if you're only going to release open-source software there's no problems.

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 26755
  • Country: nl
    • NCT Developments
Re: Atmel ARM Cortex (or NXP? or STM32?)
« Reply #20 on: June 05, 2014, 09:10:53 pm »
Buzzz. Wrong. LGPL may be used in closed source applications.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline gmb42

  • Frequent Contributor
  • **
  • Posts: 294
  • Country: gb
Re: Atmel ARM Cortex (or NXP? or STM32?)
« Reply #21 on: June 05, 2014, 09:55:18 pm »
Thanks everyone for sharing your ideas and experience.

However I was not aware of the linker generator for ARM GCC. That seems awesome, i'll give it a try!

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

Offline msrTopic starter

  • Regular Contributor
  • *
  • Posts: 73
  • Country: pt
    • rasgo.cc
Re: Atmel ARM Cortex (or NXP? or STM32?)
« Reply #22 on: June 05, 2014, 11:37:30 pm »
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
 

Offline vvanders

  • Regular Contributor
  • *
  • Posts: 124
Re: Atmel ARM Cortex (or NXP? or STM32?)
« Reply #23 on: June 06, 2014, 01:36:53 am »
Buzzz. Wrong. LGPL may be used in closed source applications.
Unless you are using a system that allows dynamic linking you're still required to distribute something that can link with the lgpl code.

See http://stackoverflow.com/questions/10130143/gpl-lgpl-and-static-linking
 

Offline andersm

  • Super Contributor
  • ***
  • Posts: 1198
  • Country: fi
Re: Atmel ARM Cortex (or NXP? or STM32?)
« Reply #24 on: June 06, 2014, 03:17:38 am »
Buzzz. Wrong. LGPL may be used in closed source applications.
You can, as long as you satisfy the license requirements. For a microcontroller-based application that means either distributing the source code or linkable objects. Even if using dynamic linking, the anti-Tivoizaition clause of the LGPLv3 means the system must still work if the LGPL-licensed components are replaced.

Offline theatrus

  • Frequent Contributor
  • **
  • Posts: 352
  • Country: us
Re: Atmel ARM Cortex (or NXP? or STM32?)
« Reply #25 on: June 06, 2014, 04:31:30 am »
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.
Software by day, hardware by night; blueAcro.com
 

Offline gmb42

  • Frequent Contributor
  • **
  • Posts: 294
  • Country: gb
Re: Atmel ARM Cortex (or NXP? or STM32?)
« Reply #26 on: June 06, 2014, 11:15:44 am »
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.
 

Offline azmat.bilal

  • Newbie
  • Posts: 2
Re: Atmel ARM Cortex (or NXP? or STM32?)
« Reply #27 on: July 09, 2014, 01:53:47 am »
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.
 

Offline andyturk

  • Frequent Contributor
  • **
  • Posts: 895
  • Country: us
Re: Atmel ARM Cortex (or NXP? or STM32?)
« Reply #28 on: July 09, 2014, 02:19:09 am »
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.
 

Offline poorchava

  • Super Contributor
  • ***
  • Posts: 1672
  • Country: pl
  • Troll Cave Electronics!
Re: Atmel ARM Cortex (or NXP? or STM32?)
« Reply #29 on: July 09, 2014, 05:47:21 am »
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.
I love the smell of FR4 in the morning!
 

Offline pyrohaz

  • Regular Contributor
  • *
  • Posts: 186
  • Country: gb
    • Harris' Electronics!
Re: Atmel ARM Cortex (or NXP? or STM32?)
« Reply #30 on: July 09, 2014, 08:40:11 am »
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.
 

Offline pyrohaz

  • Regular Contributor
  • *
  • Posts: 186
  • Country: gb
    • Harris' Electronics!
Re: Atmel ARM Cortex (or NXP? or STM32?)
« Reply #31 on: July 09, 2014, 09:12:34 am »
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)  ;)
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8221
  • Country: 00
Re: Atmel ARM Cortex (or NXP? or STM32?)
« Reply #32 on: July 09, 2014, 09:55:57 am »
2nd the recommendation of CoIDE  - I am a big fan of it.

Quote
don't get me started on STM32F0 I2C

Yeah. The whole family suffers from that actually.
================================
https://dannyelectronics.wordpress.com/
 

Offline gmb42

  • Frequent Contributor
  • **
  • Posts: 294
  • Country: gb
Re: Atmel ARM Cortex (or NXP? or STM32?)
« Reply #33 on: July 09, 2014, 11:20:51 am »
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.
 

Offline pyrohaz

  • Regular Contributor
  • *
  • Posts: 186
  • Country: gb
    • Harris' Electronics!
Re: Atmel ARM Cortex (or NXP? or STM32?)
« Reply #34 on: July 09, 2014, 03:50:14 pm »
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!
 

Offline azmat.bilal

  • Newbie
  • Posts: 2
Re: Atmel ARM Cortex (or NXP? or STM32?)
« Reply #35 on: July 09, 2014, 06:18:10 pm »
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.
 

Offline Ribster

  • Frequent Contributor
  • **
  • Posts: 250
  • Country: be
  • Electronics prototyper. Design. Prototype. Consult
    • Ash Labs
Re: Atmel ARM Cortex (or NXP? or STM32?)
« Reply #36 on: July 25, 2014, 03:05:56 pm »
2nd the recommendation of CoIDE  - I am a big fan of it.

Quote
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 ;)?
www.ashlabs.be
Design and manufacturing of embedded hard- and software
 

Offline mrflibble

  • Super Contributor
  • ***
  • Posts: 2051
  • Country: nl
Re: Atmel ARM Cortex (or NXP? or STM32?)
« Reply #37 on: July 25, 2014, 06:19:24 pm »
Quote
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?
 

Offline mikerj

  • Super Contributor
  • ***
  • Posts: 3233
  • Country: gb
Re: Atmel ARM Cortex (or NXP? or STM32?)
« Reply #38 on: July 25, 2014, 09:00:12 pm »
2nd the recommendation of CoIDE  - I am a big fan of it.

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

Offline SirNick

  • Frequent Contributor
  • **
  • Posts: 589
Re: Atmel ARM Cortex (or NXP? or STM32?)
« Reply #39 on: July 25, 2014, 11:09:26 pm »
Hey, you guys know that if you turn the forum over, there's more room to write on the other side, right?
 

Offline mrflibble

  • Super Contributor
  • ***
  • Posts: 2051
  • Country: nl
Re: Atmel ARM Cortex (or NXP? or STM32?)
« Reply #40 on: July 25, 2014, 11:30:24 pm »
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?
 

Offline Psi

  • Super Contributor
  • ***
  • Posts: 9889
  • Country: nz
Re: Atmel ARM Cortex (or NXP? or STM32?)
« Reply #41 on: July 26, 2014, 12:33:03 am »
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.

Greek letter 'Psi' (not Pounds per Square Inch)
 

Offline andersm

  • Super Contributor
  • ***
  • Posts: 1198
  • Country: fi
Re: Atmel ARM Cortex (or NXP? or STM32?)
« Reply #42 on: July 26, 2014, 12:37:29 am »
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?

Offline SirNick

  • Frequent Contributor
  • **
  • Posts: 589
Re: Atmel ARM Cortex (or NXP? or STM32?)
« Reply #43 on: July 26, 2014, 12:42:08 am »
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...
 

Offline andyturk

  • Frequent Contributor
  • **
  • Posts: 895
  • Country: us
Re: Atmel ARM Cortex (or NXP? or STM32?)
« Reply #44 on: July 26, 2014, 12:55:39 am »
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.
 

Offline mrflibble

  • Super Contributor
  • ***
  • Posts: 2051
  • Country: nl
Re: Atmel ARM Cortex (or NXP? or STM32?)
« Reply #45 on: July 26, 2014, 01:00:30 am »
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. :P

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

Offline andyturk

  • Frequent Contributor
  • **
  • Posts: 895
  • Country: us
Re: Atmel ARM Cortex (or NXP? or STM32?)
« Reply #46 on: July 26, 2014, 02:56:49 am »
Was that with the stm32 as i2c master or slave?
master

PS. Using the ChibiOS HAL too.
« Last Edit: July 26, 2014, 02:58:25 am by andyturk »
 

Offline mikerj

  • Super Contributor
  • ***
  • Posts: 3233
  • Country: gb
Re: Atmel ARM Cortex (or NXP? or STM32?)
« Reply #47 on: July 26, 2014, 11:18:02 am »
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.
 

Offline Kjelt

  • Super Contributor
  • ***
  • Posts: 6459
  • Country: nl
Re: Atmel ARM Cortex (or NXP? or STM32?)
« Reply #48 on: July 26, 2014, 01:47:51 pm »
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.
 

Offline andersm

  • Super Contributor
  • ***
  • Posts: 1198
  • Country: fi
Re: Atmel ARM Cortex (or NXP? or STM32?)
« Reply #49 on: July 26, 2014, 07:32:25 pm »
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.

Offline mikerj

  • Super Contributor
  • ***
  • Posts: 3233
  • Country: gb
Re: Atmel ARM Cortex (or NXP? or STM32?)
« Reply #50 on: July 27, 2014, 10:49:10 am »
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.

It's much more reliable with DMA, but since we are a slave to other vendors equipment we have no idea of the incoming frame length so had to go for an interrupt driven scheme.  We also don't know the exact bit rate or I2C timings being used, other than they should be compliant to I2C fast mode standards (400kHz max).  Previously we have seen reliable operation at e.g. 100kHz only for it to fail at, say 88 kHz.

It's been working reliably for a couple of years now, but it's part of the code that we have to tread very carefully around if we ever need to make changes, and spend a lot of time doing extended regression using I2C bit rates and timings that have caused trouble previously.

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.

I have hunted around for this but been unable to find it. Is it simply some updated I2C example code, or something more complex such as a code generator? I don't suppose you have a link?
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8221
  • Country: 00
Re: Atmel ARM Cortex (or NXP? or STM32?)
« Reply #51 on: July 27, 2014, 11:14:42 am »
Even that implementation is not universal: it does not work for all stm32f families.
================================
https://dannyelectronics.wordpress.com/
 

Offline paulie

  • Frequent Contributor
  • **
  • !
  • Posts: 849
  • Country: us
Re: Atmel ARM Cortex
« Reply #52 on: July 28, 2014, 03:18:50 am »
STM32's for example. All you need is a serial program (HyperTerminal for example) and you are done.

To check boot0 pin I've sent 0x7f with hyperterm and got response but beyond that??? Can you elaborate on how to flash a file?
 

Offline mikerj

  • Super Contributor
  • ***
  • Posts: 3233
  • Country: gb
Re: Atmel ARM Cortex
« Reply #53 on: July 28, 2014, 07:43:38 am »
STM32's for example. All you need is a serial program (HyperTerminal for example) and you are done.

To check boot0 pin I've sent 0x7f with hyperterm and got response but beyond that??? Can you elaborate on how to flash a file?

HyperTerm is far from ideal for this as you need to send non-printing characters to request various operations.  Its much easier to use the ST Flash Loader Demonstration or one of the open source utilities.
 

Offline Kjelt

  • Super Contributor
  • ***
  • Posts: 6459
  • Country: nl
Re: Atmel ARM Cortex (or NXP? or STM32?)
« Reply #54 on: July 28, 2014, 11:26:02 am »
I have hunted around for this but been unable to find it. Is it simply some updated I2C example code, or something more complex such as a code generator? I don't suppose you have a link?
Sorry for the delay, was in Italy on holiday and the internet there was almost non-existing, I felt thrown back 15 years in time  :(
Anyway, just looked it up for you, it is called CPAL and you can find/download it on the http://www.st.com website , select STM32 32-bit ARM Cortex MCUs, select software, select STM32 Embedded Software Examples : 90
and on that page search and find  (CPAL) or (UM1029)  see pic below.
 

Offline sporadic

  • Regular Contributor
  • *
  • Posts: 72
  • Country: us
    • forkineye.com
Re: Atmel ARM Cortex (or NXP? or STM32?)
« Reply #55 on: July 28, 2014, 11:39:00 am »
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.
The newer Atmel ICE Basic comes in even cheaper at $50.
 

Offline jakeypoo

  • Regular Contributor
  • *
  • Posts: 56
  • Country: ca
Re: Atmel ARM Cortex (or NXP? or STM32?)
« Reply #56 on: July 28, 2014, 02:46:19 pm »

Toolchain was a big challenge for me. Development files (linker scripts and startup files etc.) are included for two different GCC-based commercial products, as well as a proprietary one, but it still took me some steep learning curve to get it running. Now every time I go to work with these I have to wonder if my toolchain still works or if I'll have to go through that again... I think this is pretty much the case with any of them though if you're not going to use the provided tooling directly.


Toolchain has been a pita for me as well. Trying to get a LPC11U35 running using arm gcc baremetal compiler and little else. Looking at people's linker script examples, startup_xxx.c files, makefiles, CMIS has been confusing to say the least. I suppose you could just use one of the many easy-to-use toolchains, but I don't like paying for those kind of tools and I don't like to get locked into a toolchain.

Someone needs to write a tutorial for migrating from avr-gcc to arm-none-eabi-gcc. I mean, cortex M0[ or M3,M4] is supposed to be a replacement for 8-bit micros, right? If you look at the "Migrating from PIC..." document on the arm website, there's not much useful info there.
 

Offline andyturk

  • Frequent Contributor
  • **
  • Posts: 895
  • Country: us
Re: Atmel ARM Cortex (or NXP? or STM32?)
« Reply #57 on: July 28, 2014, 02:59:08 pm »
Someone needs to write a tutorial for migrating from avr-gcc to arm-none-eabi-gcc. I mean, cortex M0[ or M3,M4] is supposed to be a replacement for 8-bit micros, right? If you look at the "Migrating from PIC..." document on the arm website, there's not much useful info there.
It's actually not that hard. Start another thread though...
 

Offline paulie

  • Frequent Contributor
  • **
  • !
  • Posts: 849
  • Country: us
Re: Atmel ARM Cortex
« Reply #58 on: July 28, 2014, 03:38:00 pm »
HyperTerm is far from ideal for this as you need to send non-printing characters to request various operations.  Its much easier to use the ST Flash Loader Demonstration or one of the open source utilities.

far from ideal? true. but its quite easy to send non-ascii using alt-keypad or send text option. i was just interested in whether dannyf had a point or just blowing smoke.
 

Offline gmb42

  • Frequent Contributor
  • **
  • Posts: 294
  • Country: gb
Re: Atmel ARM Cortex (or NXP? or STM32?)
« Reply #59 on: July 28, 2014, 10:05:17 pm »
I found this some time ago which is a reasonable intro to the STM32: Discovering the STM32 Microcontroller
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8221
  • Country: 00
Re: Atmel ARM Cortex (or NXP? or STM32?)
« Reply #60 on: July 28, 2014, 11:53:52 pm »
Quote
Toolchain has been a pita for me as well.

CoIDE provides full support for those chips. Most of the chips you will have native support - you get to pick the chip and CoIDE will set up the project for you.

For those chips without native support (like some LPC chips), you can build your project as a regular CMx core, and manually copy in the respective start-up file and library files. Setting up such a project is fairly simple, once you know your way around. No need to play with linker script.

Debugging is supported also: for LPC, CoIDE provides support for CoLink, J-link, or older ftdi-based debuggers.
================================
https://dannyelectronics.wordpress.com/
 

Offline CC58

  • Newbie
  • Posts: 8
Re: Atmel ARM Cortex (or NXP? or STM32?)
« Reply #61 on: July 29, 2014, 04:25:41 pm »
NXP toolchain LPCexpresso has been very easy to use.  The IDE and C compiler are integrated and free.  It uses a cheap $50 JTAG debugger so you don't have to shell out $$$$ to buy a generic one.  Lots of free code on their site too.
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8221
  • Country: 00
Re: Atmel ARM Cortex (or NXP? or STM32?)
« Reply #62 on: July 29, 2014, 05:38:11 pm »
Quote
LPC11U35

The whole LPC11xx families are interesting and weird in how they arranged the port registers. On most other chips, the registers associated with a port, like output data registers, input data registers, direction registers, set registers, clear registers, and toggle registers, etc. are grouped together by port. So you can have a struct pointed to the base address of a port and everything falls into place. All other LPC chips fall to that category, other than the LPC11xx family.

For the LPC11xx family, they grouped those registers by functionality. So Port0's output data register is next to Port1's output data register, Port1's set register is next to Port2's set registers, etc. Making the programmer's life unnecessarily difficult.
================================
https://dannyelectronics.wordpress.com/
 

Offline ve7xen

  • Super Contributor
  • ***
  • Posts: 1192
  • Country: ca
    • VE7XEN Blog
Re: Atmel ARM Cortex (or NXP? or STM32?)
« Reply #63 on: July 29, 2014, 07:07:05 pm »
CoIDE provides full support for those chips. Most of the chips you will have native support - you get to pick the chip and CoIDE will set up the project for you.
CoIDE is Windows only. If I wanted to use Windows, I would just use one of the size-limited "free" toolchains with official support.
73 de VE7XEN
He/Him
 

Offline jakeypoo

  • Regular Contributor
  • *
  • Posts: 56
  • Country: ca
Re: Atmel ARM Cortex (or NXP? or STM32?)
« Reply #64 on: July 29, 2014, 09:28:16 pm »
Toolchain discussion is starting to hijack this thread. I'll start a new one.
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 26755
  • Country: nl
    • NCT Developments
Re: Atmel ARM Cortex (or NXP? or STM32?)
« Reply #65 on: July 29, 2014, 09:45:29 pm »
Quote
LPC11U35
For the LPC11xx family, they grouped those registers by functionality. So Port0's output data register is next to Port1's output data register, Port1's set register is next to Port2's set registers, etc. Making the programmer's life unnecessarily difficult.
Why would that be difficult? I just write P0DATA |= (1<<1) to set bit 1 (where P0DATA is a macro with a volatile pointer to Port 0's data port address). Using structs doesn't add much clarity for trivial things like GPIO ports.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline mrflibble

  • Super Contributor
  • ***
  • Posts: 2051
  • Country: nl
Re: Atmel ARM Cortex (or NXP? or STM32?)
« Reply #66 on: July 29, 2014, 10:03:47 pm »
Toolchain discussion is starting to hijack this thread. I'll start a new one.
Link to other discussion.
« Last Edit: July 29, 2014, 11:02:05 pm by mrflibble »
 

Offline mikerj

  • Super Contributor
  • ***
  • Posts: 3233
  • Country: gb
Re: Atmel ARM Cortex (or NXP? or STM32?)
« Reply #67 on: July 29, 2014, 10:50:42 pm »
I have hunted around for this but been unable to find it. Is it simply some updated I2C example code, or something more complex such as a code generator? I don't suppose you have a link?
Sorry for the delay, was in Italy on holiday and the internet there was almost non-existing, I felt thrown back 15 years in time  :(
Anyway, just looked it up for you, it is called CPAL and you can find/download it on the http://www.st.com website , select STM32 32-bit ARM Cortex MCUs, select software, select STM32 Embedded Software Examples : 90
and on that page search and find  (CPAL) or (UM1029)  see pic below.

Thanks, just looking through this now  :-+
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf