Author Topic: ARM Toolchain General Discussion  (Read 19117 times)

0 Members and 1 Guest are viewing this topic.

Offline jakeypoo

  • Regular Contributor
  • *
  • Posts: 56
  • Country: ca
ARM Toolchain General Discussion
« on: July 29, 2014, 09:49:38 pm »
Some interest about this in the other thread.

Discuss your preferred toolchain, compiler, debugger. Also post which cores you are compiling for and whether you use an OS/RTOS or any other sort of middleware.

I'm moving to Cortex M0 in the hope it's an 8-bit micro replacement. There are a bunch of M0 chips out there that are more powerful and have more peripherals than the average 8-bit microcontroller and they fall in the same price range or cheaper!

I'm used to developing on AVRs using avr-gcc, avrdude and avr-gdb from the command line. As I'm just looking to move to more capable cortex-M without any of the overhead of an OS, I'm currently building a toolchain based on the GNU ARM compiler (arm-none-eabi). Target is a NXP LPC11Uxx board, but hoping to move to atmel if they release some cheapo development boards for M0/M3/M0+

Getting through the startup and linker files has been painful. Next onto device files and peripheral files!

Personally I'm not a fan of any Windows only, Lite/Limited toolchains; but feel free to post about your experiences with them.
 

Offline jancumps

  • Supporter
  • ****
  • Posts: 1216
  • Country: be
  • New Low
Re: ARM Toolchain General Discussion
« Reply #1 on: July 29, 2014, 10:00:49 pm »
TI proprietary IDE (code composer studio v6, eclipse based) and TI compiler/linker/jtag emulator, targeting TMS570 ARM R4.
On linux and windows.
Sometimes with freertos, mostly without.
 

Offline andyturk

  • Frequent Contributor
  • **
  • Posts: 892
  • Country: us
Re: ARM Toolchain General Discussion
« Reply #2 on: July 29, 2014, 10:31:19 pm »
What does "8-bit micro replacement" mean? I guess it makes sense from a cost point of view... some of the Cortex M0s are really cheap. E.g., I've got a Cypress CY8C4013 on my desk at the moment. Those things are $0.29 in a SOIC-8 package and have 8K flash and 2K RAM. Right next to the tiny guy is the biggest PSoC from Cypress, an M3 with 256K of flash and 64K of RAM. On my other desk are various projects using STM32 M4 beasts with floating point, 1Mb of flash and 200K of RAM.

The cool thing is that I can use the same (free, open source) toolchain for any ARM Cortex mcu and I'm not stuck with some crippled, half-assed OEM development environment. Emacs for the win! 8)

That startup/linker pain you feel is a good pain. It's probably a little more complicated than the 8-bit world (of which I have no experience), but once you can write your own reset code and craft a .ld file, you basically own the mcu and are free to make it do what you want. You'll probably want to make friends with openocd too, which has it's own learning curve.

Re startup code, here's some reset vector code I've been using:

Code: [Select]
#include "ptk/ptk.h"

#include "stm32f4xx.h"
#include <cstdint>

/*
 * This file contains ARM Cortex exeption handlers that are specific to the
 * application.
 *
 * The Reset_Handler() doesn't have any application specific code, but it
 * has to be in a different compilation unit than the "weak" default definition
 * in cortex_handlers.cc. For that reason, Reset_Handler() is defined here.
 *
 * Every exception handler is a void function without arguments. Furthermore,
 * since the vector table mechanism used here depends on GCC's implementation
 * of weak references, these functions must not be name-mangled by C++. That's
 * why they're in an extern "C" block.
 */
int main();

extern "C" {
  void _init(void) {
  }

  extern uint32_t SystemCoreClock;
  extern void SystemInit(void);
  extern void SystemCoreClockUpdate(void);

  // This function is generated by the linker
  void __libc_init_array();

  // These locations are provided by the linker file
  extern unsigned long _etext;
  extern unsigned long _data;
  extern unsigned long _edata;
  extern unsigned long _bss_start;
  extern unsigned long _bss_end;

  void Reset_Handler(void) {
    unsigned long *src = &_etext;
    unsigned long *dest = &_data;
    unsigned long *limit = &_edata;

    // initialize .data
    while (dest < limit) *dest++ = *src++;

    dest = &_bss_start;
    limit = &_bss_end;

    // initialize .bss
    while (dest < limit) *dest++ = 0;

    // GNU libc initialization
    __libc_init_array();

    // ARM CMSIS initialization
    SystemInit();

    // run the app
    main();

    while (1);
  }

  void HardFault_Handler(void)  {ptk_halt("hard fault"); }
  void MemManage_Handler(void)  {ptk_halt("memory management fault"); }
  void BusFault_Handler(void)   {ptk_halt("bus fault"); }
  void UsageFault_Handler(void) {ptk_halt("usage fault"); }

  void SysTick_Handler(void) {
    ptk::enter_isr();
    ptk::expire_timers(1);
    ptk::leave_isr();
  }
};
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8229
  • Country: 00
Re: ARM Toolchain General Discussion
« Reply #3 on: July 29, 2014, 10:40:02 pm »
CoIDE (for myself) and Keil / Iar for work. CCS for TI chips.

jlink generally and st-link for st chips.
================================
https://dannyelectronics.wordpress.com/
 

Offline andyturk

  • Frequent Contributor
  • **
  • Posts: 892
  • Country: us
Re: ARM Toolchain General Discussion
« Reply #4 on: July 29, 2014, 11:05:52 pm »
On the topic of Cortex reset vectors, here's an approach I've been playing with:

First, define an X Macro with one entry for each element of the vector table. Here's one for a STM32F4. Apologies in advance for tabs not lining up nicely in forum posts.

cortex_handlers.h
Code: [Select]
#pragma once

/*
 * This macro defines the names and order of the interrupt handlers for the
 * a STM32F4xx mcu. The macro is defined once and expanded multiple times as an
 * X Macro (ref http://en.wikipedia.org/wiki/X_Macro).
 * In this case, the first expansion generates forward declarations for the
 * interrupt entry points. The second expansion fills the vector table.
 *
 * Note that the forward declarations are weakly bound to the Unused_Handler.
 * This allows the linker to use that function for any interrupt handler that
 * hasn't been defined. To implement an interrupt handler, simply define a
 * function of the correct name in another file (e.g., void Reset_Handler())
 *
 * These interrupts are defined in RM0090, Section 9.1.3
 */

#define STM32F4XX_INTERRUPTS              \
  STM32_INTERRUPT(-3, Reset)              \
  STM32_INTERRUPT(-2, NMI)                \
  STM32_INTERRUPT(-1, HardFault)          \
  STM32_INTERRUPT( 0, MemManage)          \
  STM32_INTERRUPT( 1, BusFault)           \
  STM32_INTERRUPT( 2, UsageFault)         \
  STM32_INTERRUPT( 0, Reserved1)          \
  STM32_INTERRUPT( 0, Reserved2)          \
  STM32_INTERRUPT( 0, Reserved3)          \
  STM32_INTERRUPT( 0, Reserved4)          \
  STM32_INTERRUPT( 3, SVCall)             \
  STM32_INTERRUPT( 4, DebugMonitor)       \
  STM32_INTERRUPT( 0, Reserved5)          \
  STM32_INTERRUPT( 5, PendSV)             \
  STM32_INTERRUPT( 6, SysTick)            \
  STM32_INTERRUPT( 7, WWDG)               \
  STM32_INTERRUPT( 8, PVD)                \
  STM32_INTERRUPT( 9, TAMP_STAMP)         \
  STM32_INTERRUPT(10, RTC_WKUP)           \
  STM32_INTERRUPT(11, FLASH)              \
  STM32_INTERRUPT(12, RCC)                \
  STM32_INTERRUPT(13, EXTI0)              \
  STM32_INTERRUPT(14, EXTI1)              \
  STM32_INTERRUPT(15, EXTI2)              \
  STM32_INTERRUPT(16, EXTI3)              \
  STM32_INTERRUPT(17, EXTI4)              \
  STM32_INTERRUPT(18, DMA1_Stream0)       \
  STM32_INTERRUPT(19, DMA1_Stream1)       \
  STM32_INTERRUPT(20, DMA1_Stream2)       \
  STM32_INTERRUPT(21, DMA1_Stream3)       \
  STM32_INTERRUPT(22, DMA1_Stream4)       \
  STM32_INTERRUPT(23, DMA1_Stream5)       \
  STM32_INTERRUPT(24, DMA1_Stream6)       \
  STM32_INTERRUPT(26, ADC)                \
  STM32_INTERRUPT(27, CAN1_TX)            \
  STM32_INTERRUPT(28, CAN1_RX0)           \
  STM32_INTERRUPT(29, CAN1_RX1)           \
  STM32_INTERRUPT(30, CAN1_SCE)           \
  STM32_INTERRUPT(31, TIM1_BRK_TIM9)      \
  STM32_INTERRUPT(32, TIM1_UP_TIM10)      \
  STM32_INTERRUPT(33, TIM1_TRG_COM_TIM11) \
  STM32_INTERRUPT(34, TIM1_CC)            \
  STM32_INTERRUPT(35, TIM2)               \
  STM32_INTERRUPT(36, TIM3)               \
  STM32_INTERRUPT(37, TIM4)               \
  STM32_INTERRUPT(38, I2C1_EV)            \
  STM32_INTERRUPT(39, I2C1_ER)            \
  STM32_INTERRUPT(40, I2C2_EV)            \
  STM32_INTERRUPT(41, I2C2_ER)            \
  STM32_INTERRUPT(42, SPI1)               \
  STM32_INTERRUPT(43, SPI2)               \
  STM32_INTERRUPT(44, USART1)             \
  STM32_INTERRUPT(45, USART2)             \
  STM32_INTERRUPT(46, USART3)             \
  STM32_INTERRUPT(47, EXTI15_10)          \
  STM32_INTERRUPT(48, RTC_Alarm)          \
  STM32_INTERRUPT(49, OTG_FS_WKUP)        \
  STM32_INTERRUPT(50, TIM8_BRK_TIM12)     \
  STM32_INTERRUPT(51, TIM8_UP_TIM13)      \
  STM32_INTERRUPT(52, TIM8_TRG_COM_TIM14) \
  STM32_INTERRUPT(53, TIM8_CC)            \
  STM32_INTERRUPT(54, DMA1_Stream7)       \
  STM32_INTERRUPT(55, FSMC)               \
  STM32_INTERRUPT(56, SDIO)               \
  STM32_INTERRUPT(57, TIM5)               \
  STM32_INTERRUPT(58, SPI3)               \
  STM32_INTERRUPT(59, UART4)              \
  STM32_INTERRUPT(60, UART5)              \
  STM32_INTERRUPT(61, TIM6_DAC)           \
  STM32_INTERRUPT(62, TIM7)               \
  STM32_INTERRUPT(63, DMA2_Stream0)       \
  STM32_INTERRUPT(64, DMA2_Stream1)       \
  STM32_INTERRUPT(65, DMA2_Stream2)       \
  STM32_INTERRUPT(66, DMA2_Stream3)       \
  STM32_INTERRUPT(67, DMA2_Stream4)       \
  STM32_INTERRUPT(68, ETH)                \
  STM32_INTERRUPT(69, ETH_WKUP)           \
  STM32_INTERRUPT(70, CAN2_TX)            \
  STM32_INTERRUPT(71, CAN2_RX0)           \
  STM32_INTERRUPT(72, CAN2_RX1)           \
  STM32_INTERRUPT(73, CAN2_SCE)           \
  STM32_INTERRUPT(74, OTG_FS)             \
  STM32_INTERRUPT(75, DMA2_Stream5)       \
  STM32_INTERRUPT(76, DMA2_Stream6)       \
  STM32_INTERRUPT(77, DMA2_Stream7)       \
  STM32_INTERRUPT(78, USART6)             \
  STM32_INTERRUPT(79, I2C3_EV)            \
  STM32_INTERRUPT(80, I2C3_ER)            \
  STM32_INTERRUPT(81, OTG_HS_EP1_OUT)     \
  STM32_INTERRUPT(82, OTG_HS_EP1_IN)      \
  STM32_INTERRUPT(83, OTG_HS_WKUP)        \
  STM32_INTERRUPT(84, OTG_HS)             \
  STM32_INTERRUPT(85, DCMI)               \
  STM32_INTERRUPT(86, CRYP)               \
  STM32_INTERRUPT(87, HASH_RNG)           \
  STM32_INTERRUPT(88, FPU)                \

Here's how the table is actually defined:

cortex_handlers.cc:
Code: [Select]
#include "cortex_handlers.h"

// provided by the linker file
extern "C" unsigned long __stack_top__;

// To be called for an interrupt handler that isn't otherwise defined
// This is extern "C" because GCC's alias attribute can't deal with
// a mangled name.
extern "C" void Unused_Handler(void) {
  while (1);
}

#define STM32_INTERRUPT(prio,name) extern "C" void name ## _Handler(void) __attribute__ ((weak, alias("Unused_Handler")));
  STM32F4XX_INTERRUPTS
#undef STM32_INTERRUPT

// Expand the interrupt defnitions a second time to fill out the vector table
#define STM32_INTERRUPT(prio,name) name ## _Handler,
__attribute__ ((section(".vectors"), used))
void (*const cortex_interrupt_vectors[])() = {
  (void (*)(void)) &__stack_top__,
    STM32F4XX_INTERRUPTS
  };

#undef STM32_INTERRUPT
 

Offline CC58

  • Contributor
  • Posts: 7
Re: ARM Toolchain General Discussion
« Reply #5 on: July 29, 2014, 11:08:32 pm »
NXP makes toolchain easy.  LPCexpresso is based on GNU port by Code Red.  Get it here. Been a while since I used it, but is was super easy.  Much better than trying to cobble together stuff. 
http://www.lpcware.com/lpcxpresso/download

 

Offline andyturk

  • Frequent Contributor
  • **
  • Posts: 892
  • Country: us
Re: ARM Toolchain General Discussion
« Reply #6 on: July 29, 2014, 11:28:33 pm »
NXP makes toolchain easy.  LPCexpresso is based on GNU port by Code Red.  Get it here. Been a while since I used it, but is was super easy.  Much better than trying to cobble together stuff. 
http://www.lpcware.com/lpcxpresso/download
Fine if you want a crippled GNU toolchain with a paid upgrade path for full functionality.  :--

Go here for the real deal.

Quote
As part of its ongoing commitment to maintaining and enhancing GCC compiler support for the ARM architecture, ARM is maintaining a GNU toolchain with a GCC source branch targeted at Embedded ARM Processors, namely Cortex-R/Cortex-M processor families, covering Cortex-R4, Cortex-R5, Cortex-M0, Cortex-M3, Cortex-M4, and Cortex-M0+. As part of this, ARM will, at regular intervals, release binaries pre-built and tested from the ARM embedded branch. The improvements will be freely available for integration into 3rd party toolchains, and for direct download by end-users.
 

Offline jakeypoo

  • Regular Contributor
  • *
  • Posts: 56
  • Country: ca
Re: ARM Toolchain General Discussion
« Reply #7 on: July 30, 2014, 12:08:02 am »
Andy, I'm totally on board with what you're preaching.

As for 8-bit micro replacement, I mean something that can replace your average ATmega or PIC16 device. That's just what a lot of people know, so you see them all over the place. For equal cost, Cortex-M seems to give you more memory, clock speed and peripherals.
The only place I could still see using an 8-bit is when you only need one of those 8 or 10 pin devices for some dead simple application. An ATiny or PIC10 still comes in cheaper than any cortex equivalents, and if it gets the job done...

Did you find any useful resources for building your own toolchain? I'm mostly using the CMSIS documentation and some app notes by Miro Samek.
 

Offline andersm

  • Super Contributor
  • ***
  • Posts: 1095
  • Country: fi
Re: ARM Toolchain General Discussion
« Reply #8 on: July 30, 2014, 12:36:46 am »
Did you find any useful resources for building your own toolchain? I'm mostly using the CMSIS documentation and some app notes by Miro Samek.
See eg. crosstool-NG. There's also a ton of different build scripts floating around.

Offline SirNick

  • Frequent Contributor
  • **
  • Posts: 589
Re: ARM Toolchain General Discussion
« Reply #9 on: July 30, 2014, 01:39:18 am »
Would just like to say:   :clap: Andy!
 

Offline andyturk

  • Frequent Contributor
  • **
  • Posts: 892
  • Country: us
Re: ARM Toolchain General Discussion
« Reply #10 on: July 30, 2014, 04:21:18 am »
Did you find any useful resources for building your own toolchain? I'm mostly using the CMSIS documentation and some app notes by Miro Samek.
Yeah, Miro has some nice examples for bare metal builds. I never really got my head around QP though.

Another good resource for this area is ChibiOS. Even if you don't want to use the RTOS itself, the distribution contains dozens of examples built with various toolchains. So if you're familiar with AVR you can look at the linker scripts and makefiles to see how he does it on a platform you know ("he" being Giovanni), and then use that to decipher a less familiar platform like ARM. Think of it as a sort of Rosetta Stone. Plus, Giovanni's code is very nice and worthy of study.

BTW, what do you mean by "building your own toolchain"? You shouldn't really need to compile GCC and the binutils, since launchpad.net has binary distributions ready to go. The only thing I've had to compile is openocd back when it was at a 0.5 or 0.6 release, and that was mostly due to my needing to run it on OS X. These days openocd seems much more stable (although I *do* still compile it from source).

Someday I'd like to try out Clang/LLVM, which should support ARM Cortex-M builds. Haven't gotten around to that yet, however.
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8229
  • Country: 00
Re: ARM Toolchain General Discussion
« Reply #11 on: July 30, 2014, 11:28:15 am »
DS-5 is also just introduced (over the last 6 months). I have seen people experimenting with it but no personal experience.

One's choice of toolchains depends on many factors, some of them are highly personal. For example:

1) what are you using them for? If I make a living on the toolchains, I want reliability and good support. If I am just playing it for fun, I want something that's weird and interesting;

2) support for your chips;

3) support for your applications;

4) code base / examples.

...
================================
https://dannyelectronics.wordpress.com/
 

Offline jakeypoo

  • Regular Contributor
  • *
  • Posts: 56
  • Country: ca
Re: ARM Toolchain General Discussion
« Reply #12 on: July 30, 2014, 12:15:36 pm »

Another good resource for this area is ChibiOS.
...
BTW, what do you mean by "building your own toolchain"?
...

The ChibiOS stuff looks great. Thanks.

I just meant putting together all your development/debug tools. Not nessecairly compiling them. I'm a fan of "do one thing well" command line tools over something like eclipse and it's integrated tools. It takes some time and looking around at other people's tools before you get your own debug tools and template files set up so that you don't have to re-learn everything once you start a new project.
 

Offline AndyC_772

  • Super Contributor
  • ***
  • Posts: 3502
  • Country: gb
  • Professional design engineer
    • Cawte Engineering | Reliable Electronics
Re: ARM Toolchain General Discussion
« Reply #13 on: July 30, 2014, 12:46:51 pm »
I still use PICs for a good many projects because they run from 5V and have a good range of analogue peripherals integrated. If you need something with a 0-5V analogue output and a built-in op-amp or two, you could do a lot worse.

I totally agree that in terms of price/performance, or even on price alone, some of the ARM based devices look dramatically better than any 8 bit parts.

I first started looking at them seriously about a year ago, and wasted a lot of time on CoIDE (buggy, poor device support, even worse tech support), and even more time trying to install and get 'straight' Eclipse to compile and download code. Manufacturers' own free tools inevitably are limited to only that manufacturer's parts and have code size limitations that are easily used up by peripheral libs or lookup tables.

I ended up with CrossWorks, which with hindsight is what I should have simply bought on day one an saved myself a lot of hassle. It has excellent device support across a wide range of manufacturers, it 'just worked' out of the box when I came to compile, download and run my first project, and its price has been recently cut too. It's US$1500 for commercial use - unquestionably a better use of the money than several days wasted on free software IMHO - and for non-commercial hobby use it's just $150. For that amount it's a no-brainer.

Offline andyturk

  • Frequent Contributor
  • **
  • Posts: 892
  • Country: us
Re: ARM Toolchain General Discussion
« Reply #14 on: July 30, 2014, 03:02:11 pm »
I just meant putting together all your development/debug tools. Not nessecairly compiling them. I'm a fan of "do one thing well" command line tools over something like eclipse and it's integrated tools. It takes some time and looking around at other people's tools before you get your own debug tools and template files set up so that you don't have to re-learn everything once you start a new project.
My bag of tricks is made up from:


The least defensible tool in the list is Emacs, but it's also the one I'm most attached to. Been using it for more than 30 years. I swear, the nerve impulses for typing obscure commands like esc-minus-1-ctrl-x-o never make it to my head and are handled somewhere in the elbow region. Sorry.  :P

Modern mcu development environments always seem to come packaged with some kind of IDE. Aside from getting in the way of my emacs addiction, the other thing I don't like about IDEs is that the build systems tend to be non-searchable. E.g., I know I want to turn on -O3 optimization, but figuring out which dialog to open, and which nested list of little triangle thingies to drill into to is entirely non-obvious. If you look at the documentation for these things, they're filled with pages upon pages of screen shots interspersed with "click this", "press Continue", etc. Very annoying! I'll admit emacs is worse, but at least you only have to learn it once. Every new IDE is a fresh helping of GUI pain.  |O

In contrast, you can open up a Makefile in your text editor and search for stuff. Plus, with a little bit of effort your Makefiles will run equally well on Windows/Linux/OS X without modification. You can even bury setup commands for your debug probe and gdb inside a Makefile, so it becomes the first place to look at for configuration information. Here's an example. In most of my repos (but not that last one), "make flashit" compiles, links, and programs the mcu assuming the hardware bits are plugged in. Fortunately, all of the hardware/firmware teams I've worked with have been open to using Makefiles, and all the IDEs I've touched are able to run Make directly.
 

Offline jakeypoo

  • Regular Contributor
  • *
  • Posts: 56
  • Country: ca
Re: ARM Toolchain General Discussion
« Reply #15 on: July 30, 2014, 05:46:19 pm »
vim, source files and datasheets is all I need.

It's good to know I'm not crazy (or maybe we're both crazy, but at least not alone) in not using any IDEs. 
 

Offline bingo600

  • Super Contributor
  • ***
  • Posts: 1409
  • Country: dk
Re: ARM Toolchain General Discussion
« Reply #16 on: July 30, 2014, 05:58:30 pm »
+1 for the launchpad arm-gcc

I'm using linux and:

launchpad arm-gcc
code::blocks (but only external makefiles) , no clicky..clicky setup.
segger, st , blackmagic or versaloon debuggers w. oocd.

/Bingo


 

Offline andyturk

  • Frequent Contributor
  • **
  • Posts: 892
  • Country: us
Re: ARM Toolchain General Discussion
« Reply #17 on: July 30, 2014, 06:01:43 pm »
segger, st , blackmagic or versaloon debuggers w. oocd.
How well does blackmagic work in practice? I always thought it was a fascinating idea: put the gdb protocol handler in the JTAG/SWD hardware.
 

Offline bwat

  • Frequent Contributor
  • **
  • Posts: 278
  • Country: se
    • My website
Re: ARM Toolchain General Discussion
« Reply #18 on: July 30, 2014, 06:05:54 pm »
vim, source files and datasheets is all I need.

It's good to know I'm not crazy (or maybe we're both crazy, but at least not alone) in not using any IDEs.

The only time you'll find me using a graphical IDE is if I'm messing around with Smalltalk (and that's not often). Otherwise, I'm all Emacs. My revision control is exclusively git.
"Who said that you should improve programming skills only at the workplace? Is the workplace even suitable for cultural improvement of any kind?" - Christophe Thibaut

"People who are really serious about software should make their own hardware." - Alan Kay
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8229
  • Country: 00
Re: ARM Toolchain General Discussion
« Reply #19 on: July 30, 2014, 06:20:22 pm »
Quote
vim, source files and datasheets is all I need.

Really? How do the source files turn to the binary? Automagically?

As to vim, you guys are just whim, unless you can one day code in binary directly. Or at least code over a punch hole tape machine.

Quote
maybe we're both crazy... in not using any IDEs.

That's more like it, :)

I tend to think that you see IDEs in wide spread use today for a (good) reason.
================================
https://dannyelectronics.wordpress.com/
 

Offline bwat

  • Frequent Contributor
  • **
  • Posts: 278
  • Country: se
    • My website
Re: ARM Toolchain General Discussion
« Reply #20 on: July 30, 2014, 06:28:56 pm »
I tend to think that you see IDEs in wide spread use today for a (good) reason.

What is that good reason?
"Who said that you should improve programming skills only at the workplace? Is the workplace even suitable for cultural improvement of any kind?" - Christophe Thibaut

"People who are really serious about software should make their own hardware." - Alan Kay
 

Offline andyturk

  • Frequent Contributor
  • **
  • Posts: 892
  • Country: us
Re: ARM Toolchain General Discussion
« Reply #21 on: July 30, 2014, 07:05:01 pm »
I tend to think that you see IDEs in wide spread use today for a (good) reason.
:box:

Yep. An IDE is a chip vendor's way to convince all the bored, lazy, least-qualified, can't-code-their-way-out-of-a-paper-bag "engineers" to use that vendor's products.

 >:D
 

Offline SirNick

  • Frequent Contributor
  • **
  • Posts: 589
Re: ARM Toolchain General Discussion
« Reply #22 on: July 30, 2014, 07:21:51 pm »
I don't get how any coder can install an IDE and blindly accept whatever is going on behind the "Send to dev board" button.  I feel like I don't understand the thing at all until I know how to compile and upload as distinct steps.  This has already been argued a few times even since I got here though.  Seems like people would more willingly trade in their daily driver for a different car than change development environments.  Me too.
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8229
  • Country: 00
Re: ARM Toolchain General Discussion
« Reply #23 on: July 30, 2014, 07:27:50 pm »
Quote
accept whatever is going on behind the "Send to dev board" button.

The same way you rely on unfamiliar devices / things to run far more important things for you: not all of us have a clue of how the monetary systems work, yet we use paper money; not all of us have a clue of how the banking systems work, yet we put our money in the banks, trade over them and let them hold our securities for us; not all of us have a clue of how a car works, yet we drive our loved ones in them; ...

To insist on using only things you understand is to limit your life to a primitive state.
================================
https://dannyelectronics.wordpress.com/
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8229
  • Country: 00
Re: ARM Toolchain General Discussion
« Reply #24 on: July 30, 2014, 07:38:50 pm »
Quote
What is that good reason?

Efficiency, productivity, team work, ....

================================
https://dannyelectronics.wordpress.com/
 

Offline jakeypoo

  • Regular Contributor
  • *
  • Posts: 56
  • Country: ca
Re: ARM Toolchain General Discussion
« Reply #25 on: July 30, 2014, 07:45:34 pm »
To insist on using only things you understand is to limit your life to a primitive state.

But it is the hacker way.

For business, if it's not a critical system, you sometimes blindly accept a vendor's tools or an outside code library to get a job done quickly. However, if it's a critical system this is where dangerous bugs or security issues can pop up.

And if it's your own project, it's your choice. But I like to build things from the ground up.
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8229
  • Country: 00
Re: ARM Toolchain General Discussion
« Reply #26 on: July 30, 2014, 07:49:51 pm »
Quote
But it is the hacker way.

Maybe. But not all of us are hackers, right?

Quote
For business, if it's not a critical system, you sometimes blindly accept a vendor's tools or an outside code library to get a job done quickly.

And efficiently or correctly.

Quote
However, if it's a critical system this is where dangerous bugs or security issues can pop up.

But how often does a hacker get to design a critical system?
================================
https://dannyelectronics.wordpress.com/
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 3098
  • Country: us
Re: ARM Toolchain General Discussion
« Reply #27 on: July 30, 2014, 07:57:12 pm »
   
Quote
accept whatever is going on behind the "Send to dev board" button.
It's rather like accepting whatever goes on behind the scenes of the incomprehensible "standard Makefiles" that come with some projects, or are "generated" by tools like automake.  (Sigh.)

Are y'all generating your own defines (shudder!) for chip constants/etc, or is there some table somewhere that describes how to get the manufacturer .h files without downloading the "whole IDE" that they tend to wrap around them?
 

Offline andyturk

  • Frequent Contributor
  • **
  • Posts: 892
  • Country: us
Re: ARM Toolchain General Discussion
« Reply #28 on: July 30, 2014, 08:02:22 pm »
But how often does a hacker get to design a critical system?
Tweeet! Yellow flag on the play. Illegal diversion of the thread. Ten yards.

How often does *anyone* get to design a critical system? The likelihood of those events cannot be used to support your premise.
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8229
  • Country: 00
Re: ARM Toolchain General Discussion
« Reply #29 on: July 30, 2014, 08:27:40 pm »
Quote
blindly accept

I would take that in a different direction: you cannot afford to NOT blindly accept others' work.

For example, do you know every single step the preprocessor / compiler / linker / libraries go through to turn your code into binary code? do you know every single step the OS go through to execute those instructions in the preprocessor / compiler / linker? do you know every single step the PC's cpu go through to execute those instructions? ...

In a modern world, you have to rely on other people's work; and many times, we have to blindly rely on other people's work. That's where I think open source software poses the biggest risks.
================================
https://dannyelectronics.wordpress.com/
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 3098
  • Country: us
Re: ARM Toolchain General Discussion
« Reply #30 on: July 30, 2014, 08:42:12 pm »
Quote
you cannot afford to NOT blindly accept others' work.
Agreed.  Although it gives one a particularly "nervous" sensation to start blindly accepting something that they previously carefully handled on their own.  (Thus, a lot of the anti-HLL feelings of long-time assembly programmers.)  And every time you get burned by something that you were assured that you could "blindly accept"...  Grr.
 

Offline andyturk

  • Frequent Contributor
  • **
  • Posts: 892
  • Country: us
Re: ARM Toolchain General Discussion
« Reply #31 on: July 30, 2014, 08:55:50 pm »
[...] That's where I think open source software poses the biggest risks.
Interesting. Have you been burned by trusting an open source program in the past?
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 18271
  • Country: nl
    • NCT Developments
Re: ARM Toolchain General Discussion
« Reply #32 on: July 30, 2014, 09:03:08 pm »
Some interest about this in the other thread.

Discuss your preferred toolchain, compiler, debugger. Also post which cores you are compiling for and whether you use an OS/RTOS or any other sort of middleware.
About a decade ago I have become a big fan of Eclipse. The main reason is that it supports many programming languages (including VHDL) so I have one environment to work in no matter what I'm programming. Another plus is that it can handle huge projects (like the Linux kernel) and make them manageble. Sure it takes some getting used to the workflow in Eclipse because it is intended to make working on big projects easy. The more recent versions have support for selecting a cross compiler so getting code for a microcontroller compiled is very easy.

In the past I have used vendor provided tools from Analog devices, TI, Keil, IAR, Xilinx ISE, etc but they always feel like some fifth wheel on the wagon. Often buggy and not very productive.

About using other people's work: if you want to reach high you have to stand on the shoulders of a giant. Most libraries take some time to learn how to work around their quirks. Usually that takes much less time than coding from scratch. A lot of time goes into testing of software. Using a library reduces that time.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline bwat

  • Frequent Contributor
  • **
  • Posts: 278
  • Country: se
    • My website
Re: ARM Toolchain General Discussion
« Reply #33 on: July 30, 2014, 09:12:59 pm »
There's a type of programming that is difficult to do with IDEs as the IDEs assume that they're the centre of the development universe.  Here's Bowles and Wilkes describing this type of programming:
Quote
A programming methodology often used in AI, as well as in other fields, is stratified or layered design. When faced with a problem, rather than implementing a solution directly in some base language, a new, more appropriate, higher level language is designed in which to express a solution, and this is implemented in the base language. This methodology can have several iterations yielding as a final solution a hierarchy of different languages each more appropriate to expressing the solution than the language below.

Continuing on this theme, here's Hal Abelson's introduction to Essentials of Programming Languages:
Quote
If you do this, you will change your view of your programming, and your view of yourself as a programmer. You'll come to see yourself as a designer of languages rather than only a user of languages, as a person who chooses the rules by which languages are put together, rather than only a follower of rules that other people have chosen.

This type of programming can be done quite easily with scripts and makefiles combining different tools (compilers/interpreters).

Emacs is an example of this type of design. The language Erlang seems to be a good example of this as well. See this document for the story: http://www.sics.se/~joe/pubs/prac_appl_prolog.ps. The last time I did this myself was when I wrote a little interpreter to execute the relational semantics definitions of programming languages. You can see this in action here. I've also built small translators for the automatic configuration of hard real-time kernels. See an example of this here:http://barrywatson.se/download/Everyman.tar.gz (see the code for the SDL compiler).
« Last Edit: July 30, 2014, 09:36:18 pm by bwat »
"Who said that you should improve programming skills only at the workplace? Is the workplace even suitable for cultural improvement of any kind?" - Christophe Thibaut

"People who are really serious about software should make their own hardware." - Alan Kay
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8229
  • Country: 00
Re: ARM Toolchain General Discussion
« Reply #34 on: July 30, 2014, 09:47:42 pm »
It is really non-sensible to insist understanding every single element of something before you can use it. Which one of your guys understands every single element of your brain?

If not, should you stop using your brain?
================================
https://dannyelectronics.wordpress.com/
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 18271
  • Country: nl
    • NCT Developments
Re: ARM Toolchain General Discussion
« Reply #35 on: July 30, 2014, 10:29:25 pm »
There's a type of programming that is difficult to do with IDEs as the IDEs assume that they're the centre of the development universe.  Here's Bowles and Wilkes describing this type of programming:
Quote
A programming methodology often used in AI, as well as in other fields, is stratified or layered design. When different languages each more appropriate to expressing the solution than the language below.

Continuing on this theme, here's Hal Abelson's introduction to Essentials of Programming Languages:
Quote
If you do this, you will change your view of your programming, and your view of yourself as a programmer. You'll come to see yourself as a designer of languages rather than only a user of languages, as a person who chooses the rules by which languages are put together, rather than only a follower of rules that other people have chosen.

This type of programming can be done quite easily with scripts and makefiles combining different tools (compilers/interpreters).

Emacs is an example of this type of design. The language Erlang seems to be a good example of this as well. See this document for the story: http://www.sics.se/~joe/pubs/prac_appl_prolog.ps. The last time I did this myself was when I wrote a little interpreter to execute the relational semantics definitions of programming languages. You can see this in action here. I've also built small translators for the automatic configuration of hard real-time kernels. See an example of this here:http://barrywatson.se/download/Everyman.tar.gz (see the code for the SDL compiler).
Eclipse is perfectly suitable for this approach because it supports having multiple projects with different languages in one workspace. In some cases I have VHDL, C and C++ projects living together. In Eclipse you can have projects depend on eachother. A change in project A which could perform some script based conversions would trigger a rebuild of project B (written in C++ for example).
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline SirNick

  • Frequent Contributor
  • **
  • Posts: 589
Re: ARM Toolchain General Discussion
« Reply #36 on: July 30, 2014, 10:58:17 pm »
It is really non-sensible to insist understanding every single element of something before you can use it. Which one of your guys understands every single element of your brain?

If not, should you stop using your brain?

You're being ridiculous now for the sake of argument.  I know you actually understand that your level of trust is variable.

Re: an IDE, it's acceptable to doubt that the automatic build process is well-suited to your needs because it is a small, highly-specific part of your work.  That kind of thing, that will affect literally every line of code you produce, is something worth scrutiny.

Re: Libraries and standing on the shoulder of giants, of course.  You will use libraries without combing over every line of code within, but you will not be blindly trusting them either. You will read the API documentation so you do understand what goes in and what's supposed to come out.  You will read examples to make sure you interpreted the documentation correctly, and your anticipated approach is reasonable.  Finally, you will prototype your solution and make sure that the thing works the way you expect.

You don't have to understand information theory or electronics to use the computer.  That is, unless we're talking about someone who is designing a motherboard or an OS, then I think it's perfectly reasonable not to take scraps of code or circuit fragments, stuff them together, and pray it works because -- hey -- giants and all.  Why reinvent the wheel?

There's an obvious difference.
 

Offline TheDirty

  • Frequent Contributor
  • **
  • Posts: 440
  • Country: ca
Re: ARM Toolchain General Discussion
« Reply #37 on: July 31, 2014, 02:03:35 am »
I use Rowley Crossworks.  I am strictly a hobbiest though.  Screwing around with make files, command line editors and the details of managing source files myself I gave up in the early 90's.
Mark Higgins
 

Offline jakeypoo

  • Regular Contributor
  • *
  • Posts: 56
  • Country: ca
Re: ARM Toolchain General Discussion
« Reply #38 on: July 31, 2014, 03:29:55 am »
Dannyf has derailed the thread a little with his straw man argument. Suffice to say that if you're familiar with how your code gets compiled, and what happens when you call a library function you're better suited to optimize your code when you hit a constraint (size or speed) before you move on to buying the next fastest micro.

Do you all try to use the CMSIS standard? ( or CMSIS equivalent for non cortex cores)
Looking at example projects from other people, everyone seems to have their own take on it. Makes you wonder how effective it actually is at letting you port code b/w cores or devices.
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 18271
  • Country: nl
    • NCT Developments
Re: ARM Toolchain General Discussion
« Reply #39 on: July 31, 2014, 05:49:59 am »
The only part I'm using from CMSIS (provided by NXP) are the clock setup routines and interrupts macros.  In many cases I modify the header file with the peripheral macros as well to allow access to registers without structs. I have lots of code which doesn't use structs to control peripherals. Most peripherals from the older ARM7TDMI and Cortex Mx controllers from NXP are the same so it is easier to copy&paste the macros from the older controllers into the header file of the new controllers. CMSIS doesn't add any value to me and I wonder what the added value is for semiconductor vendors. After all they don't want source to be portable between devices because that would make it easier to use a chip from their competitors.

ARM has this nice overview of CMSIS on their website:
http://www.arm.com/products/processors/cortex-m/cortex-microcontroller-software-interface-standard.php
'Other peripherals' is just a small block but it is also where the biggest challenge lies if CMSIS wants to make software truly portable between devices from different vendors.

I'm also worried about the extra overhead of an abstraction layer versus complexity of some peripherals. Starting an SPI transaction can be done by writing data into a register. I didn't look at the CMSIS specification but I bet the function to start an SPI transaction has a port number and some validity checks. It would be useful though to have a standard software interface for more complex devices like USB (it seems LUFA is pretty much the standard nowadays) and ethernet.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8229
  • Country: 00
Re: ARM Toolchain General Discussion
« Reply #40 on: July 31, 2014, 08:56:51 am »
Quote
I didn't look at the CMSIS specification but I bet the function to start an SPI transaction has a port number and some validity checks.

For you own good, don't bet on that as you will lose.
================================
https://dannyelectronics.wordpress.com/
 

Offline bwat

  • Frequent Contributor
  • **
  • Posts: 278
  • Country: se
    • My website
Re: ARM Toolchain General Discussion
« Reply #41 on: July 31, 2014, 09:17:50 am »
What's everyone using for revision control. I think only two of us have mentioned that and we're both using git.
"Who said that you should improve programming skills only at the workplace? Is the workplace even suitable for cultural improvement of any kind?" - Christophe Thibaut

"People who are really serious about software should make their own hardware." - Alan Kay
 

Offline BloodyCactus

  • Frequent Contributor
  • **
  • Posts: 477
  • Country: us
    • Kråketær
Re: ARM Toolchain General Discussion
« Reply #42 on: July 31, 2014, 02:46:18 pm »
git. i have my own git server attached to redmine on one of my hosts, as well as pushing some of my stuff to github
-- Aussie living in the USA --
 

Offline mrflibble

  • Super Contributor
  • ***
  • Posts: 1947
  • Country: nl
Re: ARM Toolchain General Discussion
« Reply #43 on: July 31, 2014, 03:05:05 pm »
Launchpad gcc-arm-embedded over here as well. C++11 works fine with this one. I enabled that (-std=c++11) mainly to get more pleasant to maintain enums.
Eclipse with EmbSys Registers plugin.
Mostly makefiles, but a smattering of old projects using eclipse builtin build system (with all the fun that entails :P )
openocd for flash + debug, with st-util on standby for sanity checks
git/svn for version control. Git for new stuff.
Chibios for practically every stm32 project. Lightweight, and darn convenient. And highly readable. :)
Last toolchain "experiment" was to add Boost into the mix, just to see if it's feasible for mcu. And so far it seems to work without crazy binary size penalties. That said, I also tried a simple state machine and that used a weeeee bit too much for my liking. I recall something like +8kB for each new state, which is a big nono. Could be I did something wrong though. :-// Anyway, more experimentation required in that regard...
 

Offline andyturk

  • Frequent Contributor
  • **
  • Posts: 892
  • Country: us
Re: ARM Toolchain General Discussion
« Reply #44 on: July 31, 2014, 03:27:54 pm »
What's everyone using for revision control. I think only two of us have mentioned that and we're both using git.
And since you're using emacs, which "git mode" package are you using? I use git.el that's been hacked slightly to handle submodules.

Always interested in new emacs-fu.
 

Offline bwat

  • Frequent Contributor
  • **
  • Posts: 278
  • Country: se
    • My website
Re: ARM Toolchain General Discussion
« Reply #45 on: July 31, 2014, 04:18:56 pm »
What's everyone using for revision control. I think only two of us have mentioned that and we're both using git.
And since you're using emacs, which "git mode" package are you using? I use git.el that's been hacked slightly to handle submodules.

Always interested in new emacs-fu.

All my giting is done via the command line.
"Who said that you should improve programming skills only at the workplace? Is the workplace even suitable for cultural improvement of any kind?" - Christophe Thibaut

"People who are really serious about software should make their own hardware." - Alan Kay
 

Offline BloodyCactus

  • Frequent Contributor
  • **
  • Posts: 477
  • Country: us
    • Kråketær
Re: ARM Toolchain General Discussion
« Reply #46 on: July 31, 2014, 05:02:16 pm »
i do my git 99% from command line but I have been using  SmartGit a lot lately. its very nice.

http://www.syntevo.com/smartgit/
-- Aussie living in the USA --
 

Offline andersm

  • Super Contributor
  • ***
  • Posts: 1095
  • Country: fi
Re: ARM Toolchain General Discussion
« Reply #47 on: July 31, 2014, 05:16:27 pm »
My git client of choice is SourceTree.

Offline Bassman59

  • Super Contributor
  • ***
  • Posts: 1291
  • Country: us
  • Yes, I do this for a living
Re: ARM Toolchain General Discussion
« Reply #48 on: July 31, 2014, 05:36:38 pm »
What's everyone using for revision control. I think only two of us have mentioned that and we're both using git.

Subversion.
 

Offline BloodyCactus

  • Frequent Contributor
  • **
  • Posts: 477
  • Country: us
    • Kråketær
Re: ARM Toolchain General Discussion
« Reply #49 on: July 31, 2014, 05:42:11 pm »
My git client of choice is SourceTree.

looks interesting but no linux version like smartgit. otherwise I'd want to try it :(
-- Aussie living in the USA --
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 18271
  • Country: nl
    • NCT Developments
Re: ARM Toolchain General Discussion
« Reply #50 on: July 31, 2014, 11:20:47 pm »
Quote
I didn't look at the CMSIS specification but I bet the function to start an SPI transaction has a port number and some validity checks.

For you own good, don't bet on that as you will lose.
I win: http://www.keil.com/pack/doc/CMSIS/Driver/html/group__spi__interface__gr.html
It is even worse: C++ emulated in C . And didn't MISRA outlaw function pointers? Especially when they are in RAM? :palm: There goes automotive down the drain.
« Last Edit: July 31, 2014, 11:22:27 pm by nctnico »
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline andyturk

  • Frequent Contributor
  • **
  • Posts: 892
  • Country: us
Re: ARM Toolchain General Discussion
« Reply #51 on: August 01, 2014, 12:40:34 am »
It is even worse: C++ emulated in C . And didn't MISRA outlaw function pointers? Especially when they are in RAM? :palm: There goes automotive down the drain.
Yeah, the peripheral driver part of CMSIS looks pretty thin. Not sure why anyone would be motivated to use it. The CMSIS-DSP looks genuinely useful though, and it comes with actual implementations.
 

Offline zapta

  • Super Contributor
  • ***
  • Posts: 6004
  • Country: us
Re: ARM Toolchain General Discussion
« Reply #52 on: August 01, 2014, 05:39:19 am »
Fine if you want a crippled GNU toolchain with a paid upgrade path for full functionality.  :--
Go here for the real deal.

Can you explain? How is it crippled?

I just installed it on the Mac OSX and installation was a breeze. Very tempting.  This is for hobby use, replacing AVR/Arduino. 

Having a simple to install tool chain makes open source projects more open IMO.
Drain the swamp.
 

Offline andyturk

  • Frequent Contributor
  • **
  • Posts: 892
  • Country: us
Re: ARM Toolchain General Discussion
« Reply #53 on: August 01, 2014, 11:35:21 am »
Can you explain? How is it crippled?

I just installed it on the Mac OSX and installation was a breeze. Very tempting.  This is for hobby use, replacing AVR/Arduino. 

Having a simple to install tool chain makes open source projects more open IMO.
Well, saying "crippled" was mostly trash-talk because I've never used LPCXpresso. But I'm biased against solutions where a vendor takes an open source project, wraps it in proprietary features of dubious value, and sells the combination as the greatest thing since sliced bread. When said vendor puts code size limitations into the product as a way to squeeze revenue out of users, I get more snarky.

Sadly, this seems to be the blueprint for chip vendor IDEs.

In the case of LPCXpresso, a 256K code size limitation probably isn't that bad in practice, but I'll object on principle.
« Last Edit: August 01, 2014, 11:49:11 am by andyturk »
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 18271
  • Country: nl
    • NCT Developments
Re: ARM Toolchain General Discussion
« Reply #54 on: August 01, 2014, 11:45:45 am »
IMHO chip vendors put limits on their free development tools in order not to upset the other compiler vendors.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline zapta

  • Super Contributor
  • ***
  • Posts: 6004
  • Country: us
Re: ARM Toolchain General Discussion
« Reply #55 on: August 01, 2014, 04:24:01 pm »
Well, saying "crippled" was mostly trash-talk because I've never used LPCXpresso. But I'm biased against solutions where a vendor takes an open source project, wraps it in proprietary features of dubious value, and sells the combination as the greatest thing since sliced bread. When said vendor puts code size limitations into the product as a way to squeeze revenue out of users, I get more snarky.

Sadly, this seems to be the blueprint for chip vendor IDEs.

In the case of LPCXpresso, a 256K code size limitation probably isn't that bad in practice, but I'll object on principle.

The more I play with it, the more I like it. Single package installation of IDE and tool chain, familiar eclipse experience, plenty of examples and support forums, life is good. I just ordered this board and will see how goes

http://www.digikey.com/product-detail/en/OM13014,598/568-7517-ND/2700004

The examples had a few minor compilation errors (#include path uses windows '\' instead of the standard '/') but all examples are built now. Once I will get familiar with the basic stuff I will start trimming down the stuff I don't need and will design my own custom boards. My goal is to standardize on a single ARM MCU instead of the atmega328p I am using now.

This is a great thread. I was trashing between ARM options for some time.
Drain the swamp.
 

Offline CC58

  • Contributor
  • Posts: 7
Re: ARM Toolchain General Discussion
« Reply #56 on: August 05, 2014, 09:05:04 pm »
Well, saying "crippled" was mostly trash-talk because I've never used LPCXpresso. But I'm biased against solutions where a vendor takes an open source project, wraps it in proprietary features of dubious value, and sells the combination as the greatest thing since sliced bread. When said vendor puts code size limitations into the product as a way to squeeze revenue out of users, I get more snarky.

Sadly, this seems to be the blueprint for chip vendor IDEs.

In the case of LPCXpresso, a 256K code size limitation probably isn't that bad in practice, but I'll object on principle.

The more I play with it, the more I like it. Single package installation of IDE and tool chain, familiar eclipse experience, plenty of examples and support forums, life is good. I just ordered this board and will see how goes

http://www.digikey.com/product-detail/en/OM13014,598/568-7517-ND/2700004

The examples had a few minor compilation errors (#include path uses windows '\' instead of the standard '/') but all examples are built now. Once I will get familiar with the basic stuff I will start trimming down the stuff I don't need and will design my own custom boards. My goal is to standardize on a single ARM MCU instead of the atmega328p I am using now.

This is a great thread. I was trashing between ARM options for some time.

After researching Cortex M0/M3 makers and their tools, my choice was hands down NXP with free LPCExpresso .   You can get up and running quickly and with very little expense.  They have debugger on every demo board that costs $20 instead of JLINK for $$$$. Demo board is perforated and allows you to snap off the debugger board and use it on your own PCBs. Since LPCExpresso works out of the box with integrated Eclipse, GCC, debugger, and extensive working libraries specific to M0/M3 it was extremely fast to get something working and almost entirely free. They have a great forum to ask questions too.  NXP Cortex M0/M3 have nice built in bootloaders that allow you to drag and drop source files on your target as if it were a USB stick.  Their bootloaders even have USB libraries built in making it very easy for your code to use USB.
« Last Edit: August 05, 2014, 09:11:57 pm by CC58 »
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8229
  • Country: 00
Re: ARM Toolchain General Discussion
« Reply #57 on: August 05, 2014, 09:24:43 pm »
Quote
my choice was hands down NXP with free LPCExpresso .

Most of what you said is also true for other arm chips. TI's went one step further by placing the "library" in the rom so it saves flash space.
================================
https://dannyelectronics.wordpress.com/
 

Offline rsjsouza

  • Super Contributor
  • ***
  • Posts: 3568
  • Country: us
  • Eternally curious
    • Vbe - vídeo blog eletrônico
Re: ARM Toolchain General Discussion
« Reply #58 on: August 06, 2014, 11:10:53 am »
Sadly, this seems to be the blueprint for chip vendor IDEs.
Perhaps you need to update yourself on what is out there. At least for TI, their IDE only has code-size limitation on their MSP430 compiler (but the optimizer is fully enabled), but they also offer the MSP430GCC with no limitations for free.

For ARM it is even more open: they ship with two compilers with absolutely no limitation: their compiler (armcl) and Linaro's GCC (100% Launchpad GCC based).

Back to the original topic, my usual setup for development in baremetal is Eclipse-based (Code Composer Studio from TI) and for embedded linux is the old combination of vim/makefiles/gcc from the command line.
Vbe - vídeo blog eletrônico http://videos.vbeletronico.com

Oh, the "whys" of the datasheets... The information is there not to be an axiomatic truth, but instead each speck of data must be slowly inhaled while carefully performing a deep search inside oneself to find the true metaphysical sense...
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8229
  • Country: 00
Re: ARM Toolchain General Discussion
« Reply #59 on: August 06, 2014, 11:21:05 am »
Quote
they ship with two compilers with absolutely no limitation

It is tied to their board.
================================
https://dannyelectronics.wordpress.com/
 

Offline rsjsouza

  • Super Contributor
  • ***
  • Posts: 3568
  • Country: us
  • Eternally curious
    • Vbe - vídeo blog eletrônico
Re: ARM Toolchain General Discussion
« Reply #60 on: August 06, 2014, 11:29:20 am »
It is tied to their board.
Not the compiler. The debugger is free for their dev boards but you can use their cheaper XDS100 JTAG with any of their ARM devices. One of  the releases had support for Jlink as well.
Vbe - vídeo blog eletrônico http://videos.vbeletronico.com

Oh, the "whys" of the datasheets... The information is there not to be an axiomatic truth, but instead each speck of data must be slowly inhaled while carefully performing a deep search inside oneself to find the true metaphysical sense...
 

Offline zapta

  • Super Contributor
  • ***
  • Posts: 6004
  • Country: us
Re: ARM Toolchain General Discussion
« Reply #61 on: August 06, 2014, 02:55:25 pm »
Quote
my choice was hands down NXP with free LPCExpresso .

Most of what you said is also true for other arm chips. TI's went one step further by placing the "library" in the rom so it saves flash space.

Does it run on Mac OSX?  That's what I use with the lpcxpresso IDE.
Drain the swamp.
 

Offline Bassman59

  • Super Contributor
  • ***
  • Posts: 1291
  • Country: us
  • Yes, I do this for a living
Re: ARM Toolchain General Discussion
« Reply #62 on: August 08, 2014, 04:58:49 am »
Quote
my choice was hands down NXP with free LPCExpresso .

Most of what you said is also true for other arm chips. TI's went one step further by placing the "library" in the rom so it saves flash space.

Does it run on Mac OSX?  That's what I use with the lpcxpresso IDE.

That was one real good reason why I first thought about NXP's ARMs for a High Speed USB design. I prefer the Silicon Labs parts -- the tools work and are easy to deal with, the parts work as documented (and the documentation is rather good), and their programming dongles are $40 and a dev board is usually less than $100. And oh, wait, now their tools have an OS X version (albeit under WINE). But they don't have a device which handles High Speed USB.

Unfortunately, the part I wanted to use wouldn't do I2S and SPIFI at the same time due to pin conflicts, and next up is Atmel.
 

Offline Sal Ammoniac

  • Frequent Contributor
  • **
  • Posts: 940
  • Country: us
    • Embedded Tales Blog
Re: ARM Toolchain General Discussion
« Reply #63 on: September 26, 2014, 02:03:59 am »
Put me down as another vote for Rowley CrossWorks. I use it because it "just works" without any messing around. It's the best $150 I've ever spent on a development tool. I applaud Rowley for making it available to hobbyists for this price.

I use it with an LPC-Link 2, which is a $20 JTAG board that can be downloaded with (legal) FW that makes it look like a Segger J-Link to CrossWorks. It's fast and cheap.

I wanted to like LPCXpresso, but I found so many serious bugs in it that I was spending so much time putting together minimal programs that would replicate these bugs (so I wouldn't have to send them my 15,000 line RTOS) so that the developers could reproduce them that I didn't have any time to spend on my own code.
 

Offline zapta

  • Super Contributor
  • ***
  • Posts: 6004
  • Country: us
Re: ARM Toolchain General Discussion
« Reply #64 on: September 26, 2014, 02:37:07 am »
Put me down as another vote for Rowley CrossWorks. I use it because it "just works" without any messing around. It's the best $150 I've ever spent on a development tool. I applaud Rowley for making it available to hobbyists for this price.

If I use code works for open source projects, is it easy to release the source code with make files such that people can *easily* build the with free tools?  Are there dependency that cannot be open sourced?
Drain the swamp.
 

Offline Sal Ammoniac

  • Frequent Contributor
  • **
  • Posts: 940
  • Country: us
    • Embedded Tales Blog
Re: ARM Toolchain General Discussion
« Reply #65 on: September 26, 2014, 03:08:03 am »
Put me down as another vote for Rowley CrossWorks. I use it because it "just works" without any messing around. It's the best $150 I've ever spent on a development tool. I applaud Rowley for making it available to hobbyists for this price.

If I use code works for open source projects, is it easy to release the source code with make files such that people can *easily* build the with free tools?  Are there dependency that cannot be open sourced?

I have no idea. That question is probably best addressed to Rowley.
 

Offline zapta

  • Super Contributor
  • ***
  • Posts: 6004
  • Country: us
Re: ARM Toolchain General Discussion
« Reply #66 on: September 26, 2014, 03:35:07 am »
I have no idea. That question is probably best addressed to Rowley.

Done ;-)
Drain the swamp.
 

Offline zapta

  • Super Contributor
  • ***
  • Posts: 6004
  • Country: us
Re: ARM Toolchain General Discussion
« Reply #67 on: September 26, 2014, 04:05:13 am »
Yes, its very restrictive indeed. Not a good fit as an editor for open source projects.  I think I will stick with expresso since everyone can download it for free.

According to this site
http://www.rowley.co.uk/crossworks/info_commercial_license.htm
You cannot redistribute source code.

Quote
All Rowley Associates libraries, source code, Redistributables and other files remain Rowley Associates' exclusive property. Regardless of any modifications that you make, you may not distribute any files (particularly Rowley Associates source code and other non-executable files) except those that Rowley Associates has expressly designated as Redistributables. Nothing in the License Agreement permits you to derive the source code of files that Rowley Associates has provided to you in executable form only, or to reproduce, modify, use, or distribute the source code of such files. You are not, of course, restricted from distributing source code or byte code that is entirely your own.
Drain the swamp.
 

Offline Brutte

  • Frequent Contributor
  • **
  • Posts: 608
Re: ARM Toolchain General Discussion
« Reply #68 on: September 26, 2014, 10:16:31 am »
Launchpad (..)Eclipse with EmbSys Registers plugin. Mostly makefiles (..) openocd for flash + debug, with st-util on standby for sanity checks git/svn for version control. Git for new stuff.
+1.
That is my setup!
I would add egit plugin + terminal plugin + gnu-arm plugin + ada plugin.
I am "maintaining" STM32L1 xml files for embsys, bug reports always welcome.

If you are familiar with Eclipse then you can try my SplitCode (alpha).
 

Offline zapta

  • Super Contributor
  • ***
  • Posts: 6004
  • Country: us
Re: ARM Toolchain General Discussion
« Reply #69 on: September 26, 2014, 03:09:22 pm »
According to this site
http://www.rowley.co.uk/crossworks/info_commercial_license.htm
You cannot redistribute source code.

Rowley answered in less than 12 hours.

"You can start crossstudio with a -gcc option in which case it uses an external GCC toolchain - there are some words on this in the help. This is the way to go if you are developing open source software i.e. it won't use any of the CrossWorks library."

Is this a reasonable choice over let's say LPCXpresso?
Drain the swamp.
 

Offline Sal Ammoniac

  • Frequent Contributor
  • **
  • Posts: 940
  • Country: us
    • Embedded Tales Blog
Re: ARM Toolchain General Discussion
« Reply #70 on: September 26, 2014, 09:05:37 pm »
Is this a reasonable choice over let's say LPCXpresso?

In my opinion, yes. CrossWorks is much faster than LPCXpresso (it's not based on Eclipse or Net Beans) and has fewer bugs. Although Rowley is a small company, they offer excellent support and have always answered my questions and responded to my bug reports within hours.

CrossWorks is so fast in my setup that it's almost like working in an interpreted environment.
 

Offline zapta

  • Super Contributor
  • ***
  • Posts: 6004
  • Country: us
Re: ARM Toolchain General Discussion
« Reply #71 on: September 26, 2014, 11:15:39 pm »
Is this a reasonable choice over let's say LPCXpresso?

In my opinion, yes. CrossWorks is much faster than LPCXpresso (it's not based on Eclipse or Net Beans) and has fewer bugs. Although Rowley is a small company, they offer excellent support and have always answered my questions and responded to my bug reports within hours.

CrossWorks is so fast in my setup that it's almost like working in an interpreted environment.

I installed on my notebook and asked for 30 days license.

It seems that the 30 days license is tied to a specific mac address. What about the paid license, is it tight to a specific machine? Do I need to get the vendor in the loop when installing on other machines?
Drain the swamp.
 

Offline zapta

  • Super Contributor
  • ***
  • Posts: 6004
  • Country: us
Re: ARM Toolchain General Discussion
« Reply #72 on: September 26, 2014, 11:26:19 pm »
I tried to create a new project in Rowley CrossStudio but could not find anything for NXP LPC11U35 (or this board http://www.embeddedartists.com/products/boards/lpc11u35_qsb.php ).  Is this CPU supported?
Drain the swamp.
 

Offline sca

  • Regular Contributor
  • *
  • Posts: 68
Re: ARM Toolchain General Discussion
« Reply #73 on: September 26, 2014, 11:48:05 pm »
 

Offline ehughes

  • Frequent Contributor
  • **
  • Posts: 369
  • Country: us
Re: ARM Toolchain General Discussion
« Reply #74 on: September 27, 2014, 02:17:22 am »
Quote
Real programmers don't use IDEs

Tell me about it!   I mean I write my C code out on papyrus using a custom make ink,   hand compile to the ARMv7 assembly and then translate every line to binary from the manual.  Once that is done use a custom SWD interface that involves me manually bit banging the interface by flipping switches.   It takes a week to get an LED to blink but It is the only true way to show how well endowed I am and that I am Open Source!   I will never be fooled into paying money for a dev tool.  After all,  that makes me look like I am not a "real coder".  It only took me a 1000 hours to come up with that tool chain.

After all,  not invented here, right?  If I didn't do it, it must be crap!

By the way, I make my own papyrus from plants I grow in my back yard.  They are right next to good drugs I have been smoking.

I did try LPCxpresso.   It had such crazy features such as C startup code ,   header files with periperahal access macros, linker files and a debugger that actually showed me register values.   I mean I didn't even did even spend 2 days dicking around with open ocd.    That lazy guy who showed it to me even had stuff working in a few minutes.   I mean,  come one,   he can't be a real programmer. lulz!




 

Offline zapta

  • Super Contributor
  • ***
  • Posts: 6004
  • Country: us
Re: ARM Toolchain General Discussion
« Reply #75 on: September 27, 2014, 02:36:51 am »
Have you got the LPC1000 BSP installed? It's listed in that package.

http://cdn.rowleydownload.co.uk/arm/packages/index.htm?http://www.rowleydownload.co.uk/arm/packages/LPC1000.htm
sca

That solved it, thanks.  Still waiting for the activation code but was able to play with it. I expected something lean and mean but it seems to be more complex than Eclipse. I will play with it more once the activation code will arrive.
Drain the swamp.
 

Offline Sal Ammoniac

  • Frequent Contributor
  • **
  • Posts: 940
  • Country: us
    • Embedded Tales Blog
Re: ARM Toolchain General Discussion
« Reply #76 on: September 27, 2014, 06:46:36 am »
It seems that the 30 days license is tied to a specific mac address. What about the paid license, is it tight to a specific machine? Do I need to get the vendor in the loop when installing on other machines?

The paid license is tied to a specific machine as well, but Rowley has no problems with sending you license keys for multiple machines, if you need them, even with the personal license. I have CrossWorks installed on my main development machine in my lab, the laptop I use on-the-go, and on the PC in my home office, all with keys sent by Rowley.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf