Another look into ARM

[denizcan]

I've used/been using PIC (not for 6 years) AVR, LPC21, LPC23, LPC17, LPC13 chips. And nowadays CC430, STR32F0 and STR32F4.. However, for 2 years I've been using Cortex M3 and M0's for most of the time. CC430 series for it's integrated wireless.. For different projects, different chips offer different peripherals and different prices.. I also help people on their migration to ARM processors..

What I see is, ARM chips have a lot to configure to do simple tasks. IDE's are garbage and frustrating for newcomers. CMSIS, is really ugly code to deal with.. All other Keil's library are garbage.. Even the IDE's are not just plug and play. If you download Code Red's IDE, you just can't get flash a led easyly..  ARM is a little difficult to grasp for people.. Just think of GPIO on AVR/PIC and in STR32F4 series.. Look at the number of pages you have to read to work on.. AHB clocks, Mode registers, SET/CLEAR registers, alternate function  registers.. You have to do a lot of bit shift, and, or, not's.. It is really difficult for a starter.. And look at an AVR. Just a few easy to understand registers, and you're ready..

Another example is the timers.. LPC series have really bad designed 16/32 bit timers, however they are still powerfull and more complex than PICS and AVR's. STR32's??? They are really but really nice, loved them, but not for starters.. What about UARTS, SPI's, I2C's..

People just hate reading manuals, and big companies are good at creating junk.. The common problem across the new starters of LPC is the IAP pin.. You have to pull up the P2.10 in reset to let MCU run the user code.. This information is somewhere in the manual, not obvious to the one who just jumped in.. etc. etc.

To sum up, ARM is difficult for starters, there are a lot of walls the starter is going to hit until just run his first code.. However, if you get it going, you won't look back to 8 or 16 bits, unless they offer something different. For instance some PIC's have CLCs. If you need a few and's and OR's and CPLD's are a little big for your application, why not use 10F32 instead of descrete logic chips?

BTW, the worst chip and documentation I have ever had is MSP430 series. (I know it is not ARM) It's hardware is nice. Having DMA on a small chip is fantastic. The pleasure of being able to connect any pin to any peripheral cannot be described.. But API and documentation is really really bad. Even there isn't a naming consistency in the macros. What I see is big companies have the ability to create hardware but not software..

[denizcan]

Someone said audio is slow for MCU's.. Not for 8 bit, event 16 bit though.. I've been designing an emergency system that user carries. Something like medallion.. It detects the movements of the person. In an event, it also enables the person to communicate with the base.. There are band pass filters and very simple ADPCM encoding/decoding. I used CC430 on pendant as it has wireless and 16 bit computing in a small package. I had to make encoding distrubuted across time to overcome induced large delay before transmit.. I mean CC430 encodes when it samples the audio. This way encoding is distributed over time.. When there is an incoming frame that request the audio back to base station, it just sends the encoded buffer.. However, in base station there is and ARM MCU, it takes microseconds to encode the whole same frame.. This makes coding a lot easier.. If I need to add some other filtering etc on CC430, there is nearly CPU time to do that..

Main problem with audio is multiplication, the worst problem is the division.. And you need both..

On second prototype I am using two chip solution on pendant: 4mm x 4mm ARM and CC1101.. This will also enable me using I2S audio chip, 16 bit at 32KHz sampling (after bandpass and some other filtering, it will be sampled to 8KHz) instead of 12 bit at 8KHz. I am guessing it will generate far better audio quality..

[dannyf]

you just can't get flash a led easyly.

An operator issue?

[denizcan]

An operator issue?

I mean you have to deal with a lot to just blink a led.. This is what "hello world" application of MCU is. Isn't it?

[Kjelt]

Just think of GPIO on AVR/PIC and in STR32F4 series.. Look at the number of pages you have to read to work on..

Yeah I know what you mean, when I got bit banding in my course I was laughing my ass off, using 1MB codespace so with writing directly one word you can toggle 1 bit. Then ofcourse with a memoryspace of 4GB you have some room to spare, but what a waste if you look at it from an 8 bit POV.
Anyway you can see it in the size and numbers of datasheet/familymanuals, with an 8 bitter you have the datasheet of the particul chip and a microcontroller family reference manual and some errata sheets, finished. With an ARM chip you have those (which are much bigger also) for the peripherals but then you go to the ARM website to look up the documentation of for instance the M3 Cortex core and you are flooded with MB's of documents. And then there are also errata sheets on different versions of this core and you have to find out which version is in your controller, anyway yeah a lot of work but when you take the effort and time to wrestle through it all sure is worth while.

[dannyf]

you have to deal with a lot to just blink a led

Not really sure what you meant here. To blink an led, a few things are involved, regradless of which chips you are on:

1) start-up: for most 8-bit chips, it is fairly simple and transparent to the programmer; for most CMx chips, it is done by CMSIS and transparent to the programmer as well;

2) setting up the pins: for most 8-bit chips, you need to control the direction register; for most CMx chips, you need to enable the clock to the port and configure the pins; This can be easily packaged into a functional call similar to the 8-bit world;

3) flip a pin: roughly the same for the 8-bit/CMx chips;

4) delay: simply a software delay will do. identical for the 8-bit/CMx chips.

So not much more is involved - as a matter of fact, I can write a same blinky that will compile on a CMx chip and a 8-bit chip without a single change (aside from the chip header files).

[denizcan]

Not really sure what you meant here. To blink an led, a few things are involved, regradless of which chips you are on

dannyf, I agree with you. however, for starters why the compiler adds "startupxxx.s" is a problem, to access a port it is easier to use CMSIS, however you have to add this to your workspace if you are using Code Red. uVision adds header automatically..

You know what registers to work on, however a newbie has to read all related stuff to blink a led. Talking on NXP, there is no organization in documentation that "for starters use LPC_GPIO0->FIODIR reg to set it direction as output, and LPC_GPIO0->FIOSET register to set, LPC_GPIO0->FIOCLR to clear"..

In documentation it says FIO0SET, however in CMSIS there is no FIO0SET definition. You have to use LPC_GPIO0->FIOSET.. This is another headache.. While reading you delve into the lots of registers. In practice, you just needed the above.. But after filtering you may have this knowledge.. Just think how a starter sees the documentation..

Talking about the "same blinky", you can do single code, multiple platform I know.. I know because I did.. This code runs in any platform, ST, LPC, MSP430, ATMEGA as same:

Code: [Select]

#include <hal>

int main()
{
  core.init();
  Pin led(P1_0, OUTPUT); // depending on MCU, for ST PA_0 for intance
  while (1)
  {
    led = !led;
    wait(500);
  }
}

only platform depended part is the enumaration P1_0, on ST it they name it PA, PB etc.. Look at include, you even don't need MCU header, library automaticaly chooses corresponding header..

this is two leds, two loops:

Code: [Select]

#include <hal.h>

Pin led1;
Pin led2;
Task<128> task1; // task with 128 byte stack

void handleLed1Task()
{
  while (1)
  {
    led1 = !led1;
    wait(250);
  }
}

int main()
{
  core.init();
  led1.init(P1_0, OUTPUT);
  led2.init(P1_1, OUTPUT);

  task1.start(handleLed1Task);
  while (1)
  {
    led2 = !led2;
    wait(500);
  }
}

Those two loops runs parallel in any mentioned platform.. Unless something like this, and install & just use IDE, I think it is hard for ARM to embrace the hobbiests..

[denizcan]

The code above is not C, but CPP btw. I also don't understant why embedded community does not use C++.. Using virtual methods, templates it openned a lot of oportunities..

[alm]

Wouldn't a beginner just grab a code sample and go from there? Last time I checked NXP provided example projects, at least for their LPCXpresso devboards, that included a blinky program. From this you can easily modify the program to change the frequency / duty cycle, blink multiple LEDs, wait for a button, etc. All the complex stuff like GPIO setup is handled by the provided project, although eventually one has to figure out what those mysterious lines that you copy-pasted mean.

The code above is not C, but CPP btw. I also don't understant why embedded community does not use C++.. Using virtual methods, templates it openned a lot of oportunities..

Some C++ features add overhead. Virtual methods add an extra layer of indirection to every method call, for example. Many embedded applications are sensitive to overhead, although I'll admit that a blinky program on an ARM Cortex is not one of those. Historically compiler support for C++ has also been weak for embedded targets. The free version of the Code Red IDE does not support C++.

[denizcan]

Wouldn't a beginner just grab a code sample and go from there?

Sure, wise man does that.. But I don't think Nxp is the correct company that knows how to write documentation, teach their platform, even write usuable libraries.. Guys, it is not problem for an experienced developer. Think like novice..

Some C++ features add overhead

I think this is also historic and a little biased.. A virtual method call just adds a VMT lookup load.. But if you want to do the same with C, you usually use switch states, wise man use function pointers, which adds a lot more instructions.. I've been using C++ for over 3 years in my applications. My OS, Timers, UART and related protocols (such LINBUS), I2C, I2S, UI is handled by CPP code.. Even in time critical applications I've never came across a performance issue.. Additionally I think, most of the time, code re-useability is much more important than performance.. Development time cost is incomparable to high performance chip cost..

[dannyf]

In documentation it says FIO0SET, however in CMSIS there is no FIO0SET definition. You have to use LPC_GPIO0->FIOSET.. This is another headache..

I am not sure which chips you are specifically talking but it is not unique to CMx chips that you need to read the compiler manual + header files in addition to the datasheet. Those structs are well documented in there. In my view, they are far better than the Luminary / TI / typical 8-bit approach of using discrete memory addresses for such names.

BTW, the CMx chips have fairly standard naming convention (of using FIOSET/DIR/CLR...). Where did NXP use the FIOxSET/DIR/CLR convention?

[nctnico]

Well you can always define your own macros...

[andersm]

Yeah I know what you mean, when I got bit banding in my course I was laughing my ass off, using 1MB codespace so with writing directly one word you can toggle 1 bit. Then ofcourse with a memoryspace of 4GB you have some room to spare, but what a waste if you look at it from an 8 bit POV.

It's an unusual feature (maybe added so 8051 programmers would feel more at home?) but it can sometimes be useful. In one application I had to control a bunch of LEDs, and using bit-banding each could be represented by a single bit in memory without having to do a lot of masking and shifting.

[blewisjr]

Wouldn't a beginner just grab a code sample and go from there? Last time I checked NXP provided example projects, at least for their LPCXpresso devboards, that included a blinky program. From this you can easily modify the program to change the frequency / duty cycle, blink multiple LEDs, wait for a button, etc. All the complex stuff like GPIO setup is handled by the provided project, although eventually one has to figure out what those mysterious lines that you copy-pasted mean.

The code above is not C, but CPP btw. I also don't understant why embedded community does not use C++.. Using virtual methods, templates it openned a lot of oportunities..

Some C++ features add overhead. Virtual methods add an extra layer of indirection to every method call, for example. Many embedded applications are sensitive to overhead, although I'll admit that a blinky program on an ARM Cortex is not one of those. Historically compiler support for C++ has also been weak for embedded targets. The free version of the Code Red IDE does not support C++.

Great discussion and all guys.  Just one new tidbit here.  The new code red ide LPCXpresso 6 had the restriction upped to 256kb and they now allow C++ support in the free version.

[dannyf]

using bit-banding each could be represented by a single bit in memory without having to do a lot of masking and shifting.

Bit-banding is the opposite: by writing to a memory location (could be a byte / half-word / word, depending on the setup) you could change a bit.

What you are talking about is masked read / write: one write to a memory location could impact multiple bits if they are masked.

[AlfBaz]

Arghh. I have to be missing something.
At a quick glance bit-banding seems as useful as an ashtray on a motorbike
It appears that for a bit to indicate anything the LSB has to be set in the value you are writing/modifying in the alias region. Wouldn't this mean storing data in bits 31..1, setting bit 0 a bit of ORing and shifting etc... If that is indeed the case, there's not much atomic about that process

[0xdeadbeef]

Bit-banding is just a clever way to implement bit access without special opcodes or read/modify access. If you want to access the whole 32bit word, you access the real address, if you want to read/write only a bit, you access the alias address.
Also note that access to a single bit via bit-banding is atomic while a read/modify access isn't.

[dannyf]

At a quick glance bit-banding seems as useful as an ashtray on a motorbike

It is for speed as well as atomicity.

[AlfBaz]

At a quick glance bit-banding seems as useful as an ashtray on a motorbike

It is for speed as well as atomicity.

What the ashtray or bit-banding

seriously though, I'll have to so more reading it's SOP for my first impressions to be completely wrong

[andersm]

using bit-banding each could be represented by a single bit in memory without having to do a lot of masking and shifting.

Bit-banding is the opposite: by writing to a memory location (could be a byte / half-word / word, depending on the setup) you could change a bit.

That's exactly what I was talking about. Instead of having to shift and mask to set/clear or read single bits from words of memory, I used the bit-band alias to address them individually. This simplified the software a lot and didn't cost anything in terms of RAM use.

[denizcan]

In documentation it says FIO0SET, however in CMSIS there is no FIO0SET definition. You have to use LPC_GPIO0->FIOSET.. This is another headache..

I am not sure which chips you are specifically talking but it is not unique to CMx chips that you need to read the compiler manual + header files in addition to the datasheet. Those structs are well documented in there. In my view, they are far better than the Luminary / TI / typical 8-bit approach of using discrete memory addresses for such names.

BTW, the CMx chips have fairly standard naming convention (of using FIOSET/DIR/CLR...). Where did NXP use the FIOxSET/DIR/CLR convention?

You still talk like experienced developer.. I am sure you just grab a MCU, and start using it in a few hours.. Was the discussion about why ARM was a little tougher than 8 bit-ters?

I was talking about NXP's LPC17 series..

[denizcan]

Actually the problem was not shifting. On ARM shifting is nearly free of charge..

The major problem is load-modify-store architecture.. Which makes it at least 3 instructions, non atomic.. Think about an interrupt after after load instruction..

Another benefit is memory saving. You may use whole byte for 8 booleans. If you define macro or getter/setter methods it is easier than you think.

[blewisjr]

In documentation it says FIO0SET, however in CMSIS there is no FIO0SET definition. You have to use LPC_GPIO0->FIOSET.. This is another headache..

I am not sure which chips you are specifically talking but it is not unique to CMx chips that you need to read the compiler manual + header files in addition to the datasheet. Those structs are well documented in there. In my view, they are far better than the Luminary / TI / typical 8-bit approach of using discrete memory addresses for such names.

BTW, the CMx chips have fairly standard naming convention (of using FIOSET/DIR/CLR...). Where did NXP use the FIOxSET/DIR/CLR convention?

You still talk like experienced developer.. I am sure you just grab a MCU, and start using it in a few hours.. Was the discussion about why ARM was a little tougher than 8 bit-ters?

I was talking about NXP's LPC17 series..

No actually the discussion was originally about me possibly making the move to ARM or PIC32 (I do have some background on PIC 8 bit chips) because I am starting to get into interests revolving around audio and video processing with embedded chips.  Somehow it got derailed a bit along the way with discussions about ARM chip setup and peripheral access...

[dannyf]

On ARM shifting is nearly free of charge..

Twisting on ARM is another story, however.

[denizcan]

No actually the discussion was originally about me possibly making the move to ARM or PIC32 (I do have some background on PIC 8 bit chips) because I am starting to get into interests revolving around audio and video processing with embedded chips.  Somehow it got derailed a bit along the way with discussions about ARM chip setup and peripheral access...

It got there to show that learning curve of ARM is a little flatter than learning an 8 bit MCU or PIC32.. Simple example is GPIO..  You have to read and read a lot to get started.. Same for other peripherals.. But as mentioned before, if you get used to, you don't want to go back..

Am I twisting?