Difference beteween B and BL instruction in ARM

 

The B instruction will branch. It jumps to another instruction, and there is no return expected. The Link Register (LR) is not touched.

The BL instruction will branch, but also link. LR will be loaded with the address of the instruction after BL in memory, not the instruction executed after BL. It will then be possible to return from the branch using LR.

Example :

start:
01:  MOV r0, r2     ; some instruction
02:  B there        ; go there and never return !

there:
11:  MOV r1, r0         ; some instruction
12:  BL some_function   ; go to some_function, but hope to return !
                        ; this BL will load 13 into LR
13:  MOV r5, r0
14:  BL some_function   ; this BL will load 15 into LR
15:  MOV r6, r0


some_function:
     MOV r0, #3
     B LR               ; here, we go back to where we were before

If you want to call another function inside a function, LR will be overwritten, so you won’t be able to return. The common solution is to save LR on the stack with PUSH {LR}, and restore it before returning with POP {LR}. You can even restore and return in a single POP {PC} : this will restore the value of LR, but in the program counter, effectively returning of the function.

Courtesy: https://stackoverflow.com/questions/34091898/bl-instruction-arm-how-does-it-work

 

Read Full Post »

Virtual box – Sharing – How to make it

For the error message “unknown filesystem type vboxsf”  while I was trying to share a directory from my Windows 7 host to Ubuntu 12.04.

Step 1: Install host additions (usually you install them when you install virualbox).

Step 2: If you have created a new machine, then create a shared directory/folder. (From the machine’s Devices menu)

Step 3: From machine’s Devices menu, select “Install guest additions”

It should install the additions.

Step 4: Now create a directory where you want to mount your shared drive. For example I have created shared directory under mount using following:

#cd /media #sudo mkdir shared

Step 5: Mount using following command:

sudo mount -t vboxsf shared /media/shared

Note that shared was the name of the directory I shared from virtual box and /media/shared is the directory where I wanted to mount my shared directory.

Now you should be able to see the files under shared directory in both system.

Read Full Post »

Mastering stack and heap for system reliability: Part 1 – Calculating stack size

Editor’s note: In this three part series, Anders Lundgren and Lotta Frimanson take you step by step through the techniques for allocating stack and heap in embedded systems for a robust design that optimizes use of memory resources. In part 1, they describe methods for reliable calculation of the required stack size and detection of stack-related problems.

The stack and the heap are random access memory (RAM) allocations that are fundamental to an embedded system. Setting them up properly is essential to system stability and reliability. Incorrectly used, they may cause your system to wreak havoc in strange ways. Stack and heap memory must be allocated statically by the programmer, but calculating the space required for the stack space is notoriously difficult for all but the smallest embedded systems.

Underestimating stack usage can lead to serious runtime errors that can be difficult to find, while over-estimating stack usage wastes memory resources. Heap memory overflows also can have significant an impact on system behavior, and can be notoriously difficult to debug. In this article, we’ll take a closer look at stacks and heaps for embedded systems, discussing principles and methods for reliable stack and heap design and some special issues that arise in small embedded systems.

Desktop systems and embedded systems share some common stack and heap design errors and considerations, but differ completely in many other aspects. One example of a difference between these environments is the available memory. Windows and Linux default to 1 and 8 Mbytes of stack space; a number that can be increased even more. Heap space is only limited by the available physical memory and/or page file size.

Embedded systems, on the other hand, have very limited memory resources, especially when it comes to RAM space. There is clearly a need to minimize stack and heap in this restricted memory environment. A common issue for small embedded systems is that there is no virtual memory mechanism; allocation of stack, heap and global data (i.e. variables, TCP/IP, USB buffers, etc.) is static and performed at the time the application is built.

The stack
The stack is an area of RAM where a program stores temporary data during the execution of code blocks. The stack is statically allocated and operates on a “last in first out” basis. The life span of variables on the stack is limited to the duration of the function. As soon as the function returns, the used stack memory will be free for use by subsequent function calls.

The types of data stored in the stack include:

• local variables
• return addresses
• function arguments
• compiler temporaries
• interrupt contexts

Stack memory has to be allocated statically by the developer. The stack usually grows downward in memory. If the memory area allocated for the stack isn’t large enough, the executing code writes to the area allocated below the stack and an overflow situation occurs. The area written to is usually the area where global and static variables are stored (see Figure 1). As a result, underestimating stack usage can lead to serious runtime errors such as overwritten variables, wild pointers, and corrupted return addresses. All of these errors can be difficult to find. At the same time, overestimating stack usage wastes memory resources, which increases cost.

 

Figure 1: When the data to be stored is larger than stack capacity, it typically gets written to the memory area allocated for global and static variables.

Determining worst-case maximum stack depth is useful in most embedded projects, as it allows you to allocate only as much RAM as needed for the stack while leaving the rest free for the developer to use in their application. We will highlight some methods that can be used to reliably calculate the required stack size and detect stack related problems.

The heap
The heap is an area of RAM that represents the dynamic memory of the system. When one module does not need its allocated memory anymore, the developer should return it to the memory allocator to be reused by some other module. Dynamic memory makes memory sharing possible between different pieces of a program. As with the stack allocation, it is important to minimize heap usage in small embedded systems; indeed, dynamic memory and the heap can in many cases be considered optional in small embedded systems.

Some examples of data that is placed on the heap include:

• Transient data objects
• C++ new/delete
• C++ STL containers
• C++ exceptions

Because of the dynamic behavior of the application, calculating heap space in larger systems ranges from difficult to impossible. Moreover, there is not much tool support in the embedded world for measuring heap utilization, but we will discuss some methods to approximate and measure the heap usage of an application.

It is important to maintain heap integrity. Allocated data space is typically interspersed with critical memory allocator housekeeping data. Inefficient use of the allocated data space will corrupt the entire heap memory area and most likely result in an application crash with few traces of how the crash happened. We will discuss some methods to aid in checking for heap integrity.

Another aspect to consider is that the real-time performance of the heap is not deterministic. Memory allocation depends on such factors as previous use and the requested data space size. This ad hoc behavior makes testing and debugging heap-related problems exceedingly difficult.

Managing stacks and heaps
Stretching the limits in everyday life can be rewarding but can sometimes cause you trouble. Stretching the limits in programming when it comes to allocated data will definitely cause you trouble. If you’re lucky, that trouble will arise during system testing, but it might also manifest itself only when the product has already been delivered to thousands or millions of customers, thus necessitating an expensive recall or an embarrassing need for a software patch.

Overflowing allocated data can occur in all three storage areas: global memory, the stack, and the heap. Writing to arrays or pointer references can cause accesses outside of the memory allocated to the object. Some array accesses can be validated by static analysis, for example by the compiler issuing a warning message, a MISRA C checker, or by standalone static analysis tools) as follows:

int array[32];
array[35] = 0x1234;

When the array index is a variable expression, it is difficult for static analysis to find all problems. Pointer references are also hard to trace by static analysis, as this example shows:

int* p = malloc(32 * sizeof(int));
p += 35;
*p = 0x1234;

Runtime methods to catch object overflow errors have been available for desktop systems for a long time, e.g. Purify, Insure++, and Valgrind, to name a few. These tools work by instrumenting the application code to validate memory references at runtime. This comes at the price of slowing down application execution speed, dramatically increasing code size, and has thus not become a viable method for small embedded systems.

Small embedded systems require a more streamlined approach to detecting overflow errors, but a better strategy is to avoid overflow entirely by properly allocating the stack and the heap. In Part 2 of this article, we take a closer look at stack challenges and tools for addressing them. In Part 3, we focus on heaps.

References

1. Nigel Jones, “Computing Your Stack Size: Stack Overflow”
2. John Regehr, “Say no to stack overflow,” EE Times Design, 2004.
3. Carnegie Mellon University, “Secure Coding in C and C++, Module 4, Dynamic Memory Management,” 2010.

Anders Lundgren has been with IAR Systems since 1997. He currently works as product manager for the IAR Embedded Workbench for ARM. During the first years with IAR Systems he worked with compiler development and as project manager for compiler and debugger projects. Prior to joining IAR Systems, Lundgren worked with space science instruments at the European Space Agency and spent one year at the space science laboratory at the University of California, Berkeley. He received a M.Sc. in Computer Science from the University of Uppsala, Sweden in 1986.

Lotta Frimanson has been with IAR Systems since 1999. She currently works as product manager for IAR Embedded Workbench for ARM and MSP430, and is also responsible for the IAR RTOS partner program. Prior to joining IAR Systems, Frimanson worked with embedded systems development both at the bioscience company Biacore and at the consultant company Styrex. She received a M.Sc. in Engineering Physics from the University of Uppsala, Sweden in 1989.

 

Courtesy: http://www.embedded.com/design/debug-and-optimization/4394132/Mastering-stack-and-heap-for-system-reliability–Part-1—Calculating-stack-size?_mc=SM_EMB

Read Full Post »

Sequence of events when an interrupt hits?

• Foreground code is running, interrupts are enabled
• Interrupt event sends an interrupt request to the CPU
• After completing the current instruction(s), the CPU begins the interrupt response
  • automatically saves current program counter
  • automatically saves some status (depending on CPU)
  • jump to correct interrupt service routine for this request
  • ISR code saves any registers and flags it will modify
  • ISR services the interrupt and re-arms it if necessary
  • ISR code restores any saved registers and flags
  • ISR executes a return-from-interrupt instruction or sequence
  • return-from-interrupt instruction restores automatically-saved status
  • return-from-interrupt instruction recovers saved program counter
• Foreground code continues to run from the point it responded to the interrupt

Courtesy: http://www.scriptoriumdesigns.com/embedded/interrupts.php

Read Full Post »

I2S Waveform

Read Full Post »

Readying Linux for today’s embedded devices

Readying Linux for today’s embedded devices
Rajagopal Nagarajan, MindTree Ltd.
5/26/2010 8:15 AM EDT
Linux is making rapid strides into the embedded world. There are several factors that are driving this trend. Many devices such as netbooks, set-top boxes, mobile devices, assorted gadgets, media players, etc, are Linux powered. Cutting down Linux’s boot time is one of the final hurdles that’s left to be conquered.Drivers for embedded Linux
Till some years ago, proprietary operating systems ruled the embedded world. Linux was popular on the server side (running the websites, enterprise applications, etc). It has been trying to compete with Microsoft for the desktop market too, but till now hasn’t seen much success on this front. It was written off as a niche player, mostly in the server market.
In the last three to four years, however, there has been a change in the market. Linux is getting adopted in embedded devices and the trend is accelerating. The reasons for the shift to Linux are many:
1. Linux as an operating system is quite mature now. The 2.6 version of the kernel is feature rich and supports kernel pre-emption and threading.
2. There’s rich support of drivers for the common devices and peripherals. It’s quite easy to find the drivers for common peripherals like WLAN, Bluetooth, infrared, I2C, GPIO, etc. This reduces the development time.
3. There’s good ecosystem support of developers, forums, mailing lists and service companies who offer porting, performance tuning and testing services.
4. Last but not the least is the fact that the OS is completely open source and is royalty free.

Rough edges in embedded Linux
When Linux is ported to an embedded or handheld device, it has to be modified to suit the low memory, low horsepower and low resource environments of the embedded world. The task of removing unwanted components, configuring the kernel to use minimal resources and reducing the size is a complex one.
There is also a legacy issue in Linux that impacts user experience: The boot and shutdown operations are carryovers of the original System V UNIX system and they were not written with short boot time or smaller memory in mind. To get Linux adopted for the embedded world, it is required to modify the sources to reduce the boot time. He user experience will be affected if devices like mobile phones take a long time to boot.
There is a dire need to change this structure to make Linux boot and shutdown faster. The rest of the article looks at different approaches, comparison between them, and the work being done in this area.

Virtualization approach
Since 2006, the x86 (as well as x86-64) breed of processors also started featuring hardware-assisted virtualisation and over the years has become quite popular on laptops and netbooks. In this approach, the hardware feature of x86 architecture (dubbed Intel VT or AMD-V) is used.
A thin hypervisor is first started. The hypervisor is typically based on Linux, and it boots in 5 to 6 seconds flat. It is a bare-metal virtualiser which brings up four or five popular applications like a browser, IM client, email client, Skype and so on. Meanwhile, the boot loader of Windows (or any other full-fledged OS) is started in the background. If the user wants to go to “Windows mode”, she can press a key and switch between Windows and fast-boot environment.
The popular products in the category include Splashtop from DeviceVM and Hyperspace from Phoenix technologies. Products that use these technologies include HP’s QuickWeb series of laptops, Asus Expressgate, Acer and so on.

Optimization approach
When the virtualization-based solution is not posible, the only other option left is to optimise the Linux boot and shutdown code to reduce the time.
In the original System V UNIX system, the boot and shutdowns are handled by user-level scripts in located in the /etc/rc/ directories. These scripts poll for devices, create nodes for the devices, start services and the code is written in shell scripts. They spawn many processes and take a big toll in memory and performance. One method is to start many of the unconnected services in parallel. The other approach is to remove the scripts and rewrite them as a single application.
Moving from gLibc to uLibc also helps as it is a leaner library. Many unwanted modules and BUS snoops can be cut down to reduce time. For example, if the embedded system does not have any IDE, the IDE probe code can be removed completely. Writing on console is avoided to save time too. All these changes involve study of the system, careful tuning of the parameters and kernel code and observing the results. Many tricks and techniques for optimization are documented here.
Beside the above mentioned techniques, some companies are coming with optimised distributions to cut the booting time.
• Montavista has announced an optimised version of embedded Linux on the Freescale platform that boots in one second.
• Moblin, promoted by Intel for MID/Netbook market based on ATOM processors, is working on a boot time of five seconds for embedded Linux.
As Linux is getting into mainstream consumer devices like netbooks, mobile phones, set-top boxes, there is need drastically speed up the boot time. And, at the end of the day, efforts that address this factor will help in improving the overall customer experience by cutting down the long waits in boot and shutdown operations.

About the author
Rajagopal Nagarajan is head of the System Software practice at MindTree Ltd. He has more than 20 years of experience in embedded and networking product development and has a strong interest in embedded linux, networking and multicore technologies . At MindTree, he has led the Networking Industry Group which was responsible for VoIP product development and the building of intellectual property on network processors. Before joining MindTree, he worked on device drivers development and networking product development at Wipro. Nagarajan holds a BE degree in Electronics and Communication engineering from The College of Engineering, Guindy, India.

http://www.eetimes.com/design/embedded/4199374/Readying-Linux-for-today-s-embedded-devices

Read Full Post »