ARM in a nutshell.

What is ARM ?

ARM is an Advanced RISC Machine,. 

It is a RISC not CISC processor.  It is basically a LOAD-STORE architecture, where data processing operations are only between registers and does not involve any memory operations. 

It is a 32 bit processor and also has variants of 16 bit and 8 bit architecture, so a word is 32 bits, not 16 bits.

It got auto-increment and auto decremented addressing modes to optimize program loops, which is not very common with RISC processors.

It has a very good speed vs power consumption ratio which makes it suitable for embedded system.

It has 3 stages pipe-line: Fetch, Decode and Execute. 

7 sounds a lucky number for ARM: 

It has 7 operating modes:  Supervisor mode;  User Mode, System Mode, Fast Interrupt Mode, Interrupt Mode, Undefined mode and abort Mode. 

It has 7 interrupts/exceptions, Reset, Undefined, Pre-fetch abort, data abort, software interrupt, FIQ and IRQ, make ARM enter 5 modes, User Mode and System Mode do not need interrupt to enter,

It has 7 addressing modes: immediate mode, index mode, indirect mode, absolute (Direct) mode register mode, displacement mode and Auto-increment/Auto'decrement mode. 

 

Why Embedded

Linux now spans the spectrum of computing applications for embedded world and there are endless articles on internet about embedded Linux. This article is the collection of some thoughts while teaching embedded Linux at Beijing University and lead related project. Hope it could be helpful for people with some computing background to ramp up on this domain.

Why Embedded?

The computers used to control equipment, otherwise known as embedded systems, have been around for about as long as computers themselves. They were first used back in the late 1960s in communications to control electromechanical telephone switches. Thousands Chinese engineers was working on digital exchange development in early 1990s, I was fresh at the time and lucky to be one of them. I was writing some boot code for 8086 board and play around with Logical analyzer everyday, but did not know the word “Embedded”. Only after several years working, I suddenly aware: this is embedded.

As the computer industry has moved toward ever smaller systems over the past decade or so, embedded systems have moved along with it, providing more capabilities for these tiny machines. Increasingly, these embedded systems need to be connected to some sort of network, and thus require a networking stack, which increases the complexity level and requires more memory and interfaces, as well as, you guessed it, the services of an operating system.

Off-the-shelf operating systems for embedded systems began to appear in the late 1970s, and today several dozen viable options are available. Out of these, a few major players have emerged, such as VxWorks, pSOS, Neculeus, and Windows CE.

How to evaluate your firmware debugging environment?

It is quite common that embedded system developers spent more time figuring out their environment before they can actually test-out their code. Therefore, it is vital to select the right tool in all stages of the entire life cycle. This article tries to summarize the experienced gained on embedded system development environment.

1. Get a good external/internal debugger.

2. You may not have the luxury to connect to an external debugger (for example, it is at factory production, no space to sold a JTAG connector), then use the ancient time method: print out to serial port;

3. You may not have the luxury to print out due to performance reason, but at least keep an UART connector, intrude the code to dump trace to flash or even DRAM, and find a way to extract later. If it is flash, you are so lucky that you can take out the equipment and analyzer somewhere else. I like it.

4. Logical Analyzer can be used to debug CPU execution indeed, provided that you have the corresponding Pod and software package. The distinct advantage is it can trigger/capture with external signals. JTAG can help but not as comprehensive as Logical Analyzer.

What else?

How to design a internal debug environment and exception handling system is a big topic? You are welcome to discuss the general rule of "good" debug-ability?

An ARM CPU mode diagram

I had several rounds of discussion with ARM support Engineers and have created a PPT slide on ARM mode. Thought it will be very helpful to understand the difference between various ARM CPU modes, and how to switch from each other.

Can you figure out the difference betweem ARM IRQ and FIQ from next diagram?

A metaphor for distributed system

There are many official, or rather impenetrable explanation of distributed system. When I was studying it in NUS, it really took me sometime to understand it.

Actually, I think the distributed system can be easily explained by comparing to our traffic system. Every vehicle is a self-controlled system, with its own thinking and follow certain rules, and the entire system works well. A traffic accident is either because the law is not good (very unlikely), or because some unit break the law, then the entire system has someway to recover.

WYSWYG Embedded Programming

WYSIWYG programming is a popular term used in PC software world, such as web design or PC object oriented programming. I am a big fan of tool aided code generation for embedded world, more specifically, use actor incarnation and Finite-State Diagram as the example below.

BTW: Please note Object Oriented style of programming does NOT mean Object Oriented Language. I could not find a suitable term for it, so I call it “WYSIWYG Embedded Programming”. 

An example of Actor diagram (instance of Object).

Protocol (structure definition) and FSM (dynamic behavior) example.

The question here is about reliability. You are comfortable to browse a web page generated through WYSWYG. If you are driving a car with auto collision-avoidance controlled by auto-generated code, do you trust the firmware or the human?

My answer is WYSIWYG tool is more trust worthy. Same as in PC world, our embedded team is usually composed of Engineers from all levels and various backgrounds. The great advantage of WYSIWYG is that WYSIWYG allows the user to visualize the target break down static and dynamic behavior, and even step/debug graphically. It not only helps the developers to gain better understanding of the architect, but also enables the team members to collaborate more efficiently based on their better understanding. Especially if there are many new team members.

With the structure breakdown, it is easier for developers to design the code to cover more comprehensive cases, and find out more corner cases for testing. There are cases that non-scalable architecture eventually makes the project next to impossible to have one human to oversee all logical paths,  and costs enormous amount of effort to do repeat but not efficient testing.

WYSIWYG may have impact on Performance and code footprint overhead. This is another solvable issue. There are various efforts in industry tackling this, which worth to discuss separately.  In fact, my experience shows human factor may pose more overhead.