Which ARM development board I should buy?

Hi babuddin1 and welcome tot he Community!

I've moved your question to Embedded where I think you will get the answer you seek.

In terms of learning, you can get started here: Important ARM Technical Learning Resources

If you are able to give some more detail about your intended project or application, it will give members a better idea of what you would like to achieve.

Hello,

Welcome to the Community.

Before giving you any suggestions about which to buy, could you pls describe your detailed requirements?

As you know there are so many boards in different architecture, ARM9, ARM11, Cortex-A7, Cortex-A8, Cortex-A9, etc.

for more product information, you can have a look at our home page www.forlinx.net

Rgds,

Grace

Hi babuddin1

Welcome to the wonderful world of ARM.

Choosing a CPU really depends what you want to do.

You can start with a Raspberry Pi to get a good device with good documentation.

If you targeting more the Embedded area and want to have a CPU you can use also later at work maybe a NXP i.MX6 based board would be nice.

The i.MX6 CPU from NXP (former Freescale) is really widely used in embedded areas. It can be found in Machine Automation, Digital Signage but also in Home Automation.

There are plenty boards out on the market to get started. The Company I working for is also offering a development kit.

but there also open source projects available where you can find communities helping you to get started or books in various languages.

On of this community projects is http://wandboard.org/ they also have forum with good interaction and help.

No matter what you are going for: wish you always success and stable development

There are quite a few starter and hobby development kits to start from.  Almost too many choices as this may be your question.  The Beaglebone boards and Raspberry PI boards also seem to be inexpensive and good places to start.

The real question may be what OS you're planning to run, which will lead you to select a development board that has the BSP you will need for some of these too.

Managed to write a bare metal gdb agent for Raspberry Pi 2B, though. https://github.com/turboscrew/rpi_stub

Or maybe some board with a 64-bit ARM?

If you are looking at Cortex M (Embedded) family then you have plenty of manufacturers to choose from.

ST-Microelectronics (STM32), NXP (LPC or Kinetis), Atmel (SAM), Cypress (PSoC4/5) etc.

These manufacturers also offer their own free software development tools.

If its cortex A (Applications Processor for Linux/Android) then NXP or Atmel have interesting products but you may also want to consider a System on Module.

To be a professional in ARM processor programming, do I need to learn ARM assembly language?

Whether ARM assembly is needed is an interesting question.  I'm sure many people would argue it's almost never needed.

My own experience, especially writing & optimizing audio library code leveraging the Cortex-M4 DSP extensions, is I almost never need to write assembly, but I frequently end up reading the C compiler's generated assembly when optimizing my C code.

While C compilers have become pretty good, you can still very easily compose complex code that forces the compiler to spill lots of local variables on the stack.  You can also write simple code that processes 1 item per loop iteration, which leaves most of the ARM registers unused and spends nearly all the CPU time on looping overhead, rather than doing the task you intended.  Often the compiler is able to optimize fairly complex code to very efficient use of ARM instructions, but sometimes subtle issues cause the compiler to generate horribly inefficient code even when the C source visually appears to be simple.

But often such code optimization isn't necessary at all.  Many embedded applications are I/O limited, or limited by worst case interrupt response latency, or other timing issues far removed from the execution speed of the code.  Usually making better use of peripheral features and designing C-only code to avoid blocking I/O functions or disabling interrupts turns out to be far more important than optimizing code.