Atmel ARM Cortex (or NXP? or STM32?) - Page 1
Forum section: electronics / general

author: msr
author_rank: Regular Contributor
timestamp: June 04, 2014, 10:04:10 am
content: 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?

author: nctnico
author_rank: Super Contributor
timestamp: June 04, 2014, 10:44:02 am
content: NXP's ARM controllers have a bootloader which allow programming over the serial port. There is also a Linux tool to program them.

author: dannyf
author_rank: Super Contributor
timestamp: June 04, 2014, 11:25:30 am
content: 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.QuoteMany of them do, like STM32's for example. All you need is a serial program (HyperTerminal for example) and you are done.

author: Psi
author_rank: Super Contributor
timestamp: June 04, 2014, 11:37:48 am
content: 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 codingF0 has more power/features than a high spec $12 ATMega but with a $1.20 pricetag.(except no built in eeprom)

author: zapta
author_rank: Super Contributor
timestamp: June 04, 2014, 02:38:03 pm
content: Quote from: Psi on June 04, 2014, 11:37:48 amI couldn't find on EmBlocks site what OSs it runs on (ideally Mac, Linux and Windows).

author: SirNick
author_rank: Frequent Contributor
timestamp: June 04, 2014, 07:34:56 pm
content: 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.

author: dannyf
author_rank: Super Contributor
timestamp: June 04, 2014, 09:19:53 pm
content: 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.

author: nctnico
author_rank: Super Contributor
timestamp: June 04, 2014, 11:21:45 pm
content: 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.

author: msr
author_rank: Regular Contributor
timestamp: June 05, 2014, 12:40:32 am
content: Ok, so I changed my mind and now Im trying to choose between NXP and STM32In 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 ?

author: dannyf
author_rank: Super Contributor
timestamp: June 05, 2014, 12:52:32 am
content: STM32 has more features.LPC has less bugs.

author: ve7xen
author_rank: Super Contributor
timestamp: June 05, 2014, 12:58:41 am
content: 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.

author: SirNick
author_rank: Frequent Contributor
timestamp: June 05, 2014, 01:15:23 am
content: 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.

author: andersm
author_rank: Super Contributor
timestamp: June 05, 2014, 04:33:35 am
content: Quote from: msr on June 05, 2014, 12:40:32 amThis is not true at all. Most modern mainstream parts probably have one, but you definitely need to check the documentation to make sure.

author: theatrus
author_rank: Frequent Contributor
timestamp: June 05, 2014, 04:41:19 am
content: 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.

author: Psi
author_rank: Super Contributor
timestamp: June 05, 2014, 05:47:22 am
content: Pretty sure EmBlocks also works with LPC, PIC, AVR, but ive not tried thatI really didn't like the toolchain/IDE that came bundled with the LPC dev board i got, cant remember what its called.Quote from: zapta on June 04, 2014, 02:38:03 pmI 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.

author: ctz
author_rank: Contributor
timestamp: June 05, 2014, 09:10:37 am
content: Quote from: msr on June 05, 2014, 12:40:32 amI've had good results with plain arm-gcc andhttp://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.

author: nctnico
author_rank: Super Contributor
timestamp: June 05, 2014, 02:39:18 pm
content: Quote from: dannyf on June 05, 2014, 12:52:32 amThen 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.

author: theatrus
author_rank: Frequent Contributor
timestamp: June 05, 2014, 03:11:39 pm
content: 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)

author: msr
author_rank: Regular Contributor
timestamp: June 05, 2014, 06:19:34 pm
content: Thanks everyone for sharing your ideas and experience.Quote from: ctz on June 05, 2014, 09:10:37 amI recognize the effort of libopencm3 but unfortunately I can't trust it for the time being.QuoteHowever I was not aware of the linker generator for ARM GCC. That seems awesome, i'll give it a try!Quote from: ve7xen on June 05, 2014, 12:58:41 amThat 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-hardwareThe 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 buggyI'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.

author: andersm
author_rank: Super Contributor
timestamp: June 05, 2014, 06:51:59 pm
content: Quote from: ctz on June 05, 2014, 09:10:37 amThe LGPL license is troublesome for embedded software. Of course, if you're only going to release open-source software there's no problems.

author: nctnico
author_rank: Super Contributor
timestamp: June 05, 2014, 09:10:53 pm
content: Buzzz. Wrong. LGPL may be used in closed source applications.

author: gmb42
author_rank: Frequent Contributor
timestamp: June 05, 2014, 09:55:18 pm
content: Quote from: msr on June 05, 2014, 06:19:34 pmWhat link script generator was that, I don't see any reference to one in the previous posts, can you share a link?

author: msr
author_rank: Regular Contributor
timestamp: June 05, 2014, 11:37:30 pm
content: Quote from: gmb42 on June 05, 2014, 09:55:18 pmCheck the libopemcm3 github page:https://github.com/libopencm3/libopencm3/tree/master/ld

author: vvanders
author_rank: Regular Contributor
timestamp: June 06, 2014, 01:36:53 am
content: Quote from: nctnico on June 05, 2014, 09:10:53 pmUnless you are using a system that allows dynamic linking you're still required to distribute something that can link with the lgpl code.Seehttp://stackoverflow.com/questions/10130143/gpl-lgpl-and-static-linking

author: andersm
author_rank: Super Contributor
timestamp: June 06, 2014, 03:17:38 am
content: Quote from: nctnico on June 05, 2014, 09:10:53 pmYou 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.

author: theatrus
author_rank: Frequent Contributor
timestamp: June 06, 2014, 04:31:30 am
content: 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.

author: gmb42
author_rank: Frequent Contributor
timestamp: June 06, 2014, 11:15:44 am
content: Quote from: msr on June 05, 2014, 11:37:30 pmThanks.

author: azmat.bilal
author_rank: Newbie
timestamp: July 09, 2014, 01:53:47 am
content: 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.

author: andyturk
author_rank: Frequent Contributor
timestamp: July 09, 2014, 02:19:09 am
content: Quote from: azmat.bilal on July 09, 2014, 01:53:47 amIf 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.

author: poorchava
author_rank: Super Contributor
timestamp: July 09, 2014, 05:47:21 am
content: 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.

author: pyrohaz
author_rank: Regular Contributor
timestamp: July 09, 2014, 08:40:11 am
content: 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.

author: pyrohaz
author_rank: Regular Contributor
timestamp: July 09, 2014, 09:12:34 am
content: Quote from: mojo-chan on July 09, 2014, 09:05:06 amThats a good shout actually, I forgot to mention that the STM32 discovery boards include an STLink V2 (both a programmer and debugger)

author: dannyf
author_rank: Super Contributor
timestamp: July 09, 2014, 09:55:57 am
content: 2nd the recommendation of CoIDE - I am a big fan of it.QuoteYeah. The whole family suffers from that actually.

author: gmb42
author_rank: Frequent Contributor
timestamp: July 09, 2014, 11:20:51 am
content: If you're keen on STM32 also have a look atChibiStudio. Eclipse based IDE along with ChibiOS/RT, an interesting small scheduler that has a lot of drivers for STM32 peripherals.

author: pyrohaz
author_rank: Regular Contributor
timestamp: July 09, 2014, 03:50:14 pm
content: Quote from: gmb42 on July 09, 2014, 11:20:51 amHmm, 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!

author: azmat.bilal
author_rank: Newbie
timestamp: July 09, 2014, 06:18:10 pm
content: 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.

author: Ribster
author_rank: Frequent Contributor
timestamp: July 25, 2014, 03:05:56 pm
content: Quote from: dannyf on July 09, 2014, 09:55:57 amI'm not quite aware about the issues. A small recap please?

author: mrflibble
author_rank: Super Contributor
timestamp: July 25, 2014, 06:19:24 pm
content: Quote from: dannyf on July 09, 2014, 09:55:57 amMmmh? 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?

author: mikerj
author_rank: Super Contributor
timestamp: July 25, 2014, 09:00:12 pm
content: Quote from: dannyf on July 09, 2014, 09:55:57 amIt 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.

author: SirNick
author_rank: Frequent Contributor
timestamp: July 25, 2014, 11:09:26 pm
content: Hey, you guys know that if you turn the forum over, there's more room to write on the other side, right?

author: mrflibble
author_rank: Super Contributor
timestamp: July 25, 2014, 11:30:24 pm
content: Quote from: SirNick on July 25, 2014, 11:09:26 pmParse error near *what you just said*. Wut?

author: Psi
author_rank: Super Contributor
timestamp: July 26, 2014, 12:33:03 am
content: 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.

author: andersm
author_rank: Super Contributor
timestamp: July 26, 2014, 12:37:29 am
content: Quote from: mikerj on July 25, 2014, 09:00:12 pmThe 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?

author: SirNick
author_rank: Frequent Contributor
timestamp: July 26, 2014, 12:42:08 am
content: Quote from: mrflibble on July 25, 2014, 11:30:24 pmI 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...

author: andyturk
author_rank: Frequent Contributor
timestamp: July 26, 2014, 12:55:39 am
content: Quote from: SirNick on July 26, 2014, 12:42:08 amI'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.

author: mrflibble
author_rank: Super Contributor
timestamp: July 26, 2014, 01:00:30 am
content: Quote from: SirNick on July 26, 2014, 12:42:08 amAh, 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.QuoteYup. 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?

author: andyturk
author_rank: Frequent Contributor
timestamp: July 26, 2014, 02:56:49 am
content: Quote from: mrflibble on July 26, 2014, 01:00:30 ammasterPS. Using the ChibiOS HAL too.

author: mikerj
author_rank: Super Contributor
timestamp: July 26, 2014, 11:18:02 am
content: Quote from: andersm on July 26, 2014, 12:37:29 amThe 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.

author: Kjelt
author_rank: Super Contributor
timestamp: July 26, 2014, 01:47:51 pm
content: 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.

author: andersm
author_rank: Super Contributor
timestamp: July 26, 2014, 07:32:25 pm
content: Quote from: mikerj on July 26, 2014, 11:18:02 amI 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.

author: mikerj
author_rank: Super Contributor
timestamp: July 27, 2014, 10:49:10 am
content: Quote from: andersm on July 26, 2014, 07:32:25 pmIt'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.Quote from: Kjelt on July 26, 2014, 01:47:51 pmI 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?

author: dannyf
author_rank: Super Contributor
timestamp: July 27, 2014, 11:14:42 am
content: Even that implementation is not universal: it does not work for all stm32f families.

author: paulie
author_rank: Frequent Contributor
timestamp: July 28, 2014, 03:18:50 am
content: Quote from: dannyf on June 04, 2014, 11:25:30 amTo check boot0 pin I've sent 0x7f with hyperterm and got response but beyond that??? Can you elaborate on how to flash a file?

author: mikerj
author_rank: Super Contributor
timestamp: July 28, 2014, 07:43:38 am
content: Quote from: paulie on July 28, 2014, 03:18:50 amHyperTerm is far from ideal for this as you need to send non-printing characters to request various operations. Its much easier to use theST Flash Loader Demonstrationor one of theopen source utilities.

author: Kjelt
author_rank: Super Contributor
timestamp: July 28, 2014, 11:26:02 am
content: Quote from: mikerj on July 27, 2014, 10:49:10 amSorry for the delay, was in Italy on holiday and the internet there was almost non-existing, I felt thrown back 15 years in timeAnyway, just looked it up for you, it is called CPAL and you can find/download it on thehttp://www.st.comwebsite , select STM32 32-bit ARM Cortex MCUs, select software, select STM32 Embedded Software Examples : 90and on that page search and find (CPAL) or (UM1029) see pic below.

author: sporadic
author_rank: Regular Contributor
timestamp: July 28, 2014, 11:39:00 am
content: Quote from: mojo-chan on July 09, 2014, 09:05:06 amThe newer Atmel ICE Basic comes in even cheaper at $50.

author: jakeypoo
author_rank: Regular Contributor
timestamp: July 28, 2014, 02:46:19 pm
content: Quote from: ve7xen on June 05, 2014, 12:58:41 amToolchain 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.

author: andyturk
author_rank: Frequent Contributor
timestamp: July 28, 2014, 02:59:08 pm
content: Quote from: jakeypoo on July 28, 2014, 02:46:19 pmIt's actually not that hard. Start another thread though...

author: paulie
author_rank: Frequent Contributor
timestamp: July 28, 2014, 03:38:00 pm
content: Quote from: mikerj on July 28, 2014, 07:43:38 amfar 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.

author: gmb42
author_rank: Frequent Contributor
timestamp: July 28, 2014, 10:05:17 pm
content: I found this some time ago which is a reasonable intro to the STM32:Discovering the STM32 Microcontroller

author: dannyf
author_rank: Super Contributor
timestamp: July 28, 2014, 11:53:52 pm
content: QuoteCoIDE 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.

author: CC58
author_rank: Newbie
timestamp: July 29, 2014, 04:25:41 pm
content: 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.

author: dannyf
author_rank: Super Contributor
timestamp: July 29, 2014, 05:38:11 pm
content: QuoteThe 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.

author: ve7xen
author_rank: Super Contributor
timestamp: July 29, 2014, 07:07:05 pm
content: Quote from: dannyf on July 28, 2014, 11:53:52 pmCoIDE is Windows only. If I wanted to use Windows, I would just use one of the size-limited "free" toolchains with official support.

author: jakeypoo
author_rank: Regular Contributor
timestamp: July 29, 2014, 09:28:16 pm
content: Toolchain discussion is starting to hijack this thread. I'll start a new one.

author: nctnico
author_rank: Super Contributor
timestamp: July 29, 2014, 09:45:29 pm
content: Quote from: dannyf on July 29, 2014, 05:38:11 pmWhy 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.

author: mrflibble
author_rank: Super Contributor
timestamp: July 29, 2014, 10:03:47 pm
content: Quote from: jakeypoo on July 29, 2014, 09:28:16 pmLink to other discussion.

author: mikerj
author_rank: Super Contributor
timestamp: July 29, 2014, 10:50:42 pm
content: Quote from: Kjelt on July 28, 2014, 11:26:02 amThanks, just looking through this now