Showing posts with label Self learning kit project. Show all posts
Showing posts with label Self learning kit project. Show all posts

Tuesday, May 6, 2014

void pointers : Its Genericness

 



Void Pointers : Definition

Void pointers are the pointer variables which has no specific data type. These are also called as Generic pointers because it can point to any data type. In General, the compiler has no idea what type of object a void Pointer really points to.

Void Pointers : Declaration

A void pointer is declared like a normal pointer, using the keyword “void” as the pointer’s type as shown below,

Referencing & De-referencing the void pointers

In order to explain, how void pointers can be referenced & De-reference, let we take a small sample code as shown below in Fig 1,

 Fig 1: Referencing & De-referencing of the void pointers

From the above Fig 1, it is clear that while referencing the void * no need to typecast, only when De-referencing the void *, it need to be type-casted otherwise the gcc compiler will give warning along with error note as shown below in Fig 2,
Fig 2: Result obtained while de-referencing the void pointer without typecasting.
  Fig 3: Output after typecasting the void pointer while dereferencing.

Why void pointers are useful ?

One main advantage of using the void pointers is that it can be 're-usable'. Because of this feature of the void pointers 'space' & 'time' complexities can be reduced to some extent which is very critical in Embedded System designing.
They are very useful when you want a same pointer to point to data of different types at different times.
Let us consider a small simple code snippet, to show how void pointers can be re-usable which reduces the space complexity in the example as shown in the Fig 4 given below,
 

Fig 4: Void pointer reusability.

Fig 5: Output of the code shown in Fig 4.

For more clarity let us understand the above code through pictorial representation.
Line No.14 : The vptr is pointing to the address of the integer variable 'i', as shown below in Fig 6.1
Line No.18 : The vptr is pointing to the address of the character variable 'c', as shown below in Fig 6.2
Line No.22 : The vptr is pointing to the address of the float variable 'f', as shown below in Fig 6.3
Line No.26 : The vptr is pointing to the address of the double variable 'd', as shown below in Fig 6.4

Note : xxxx, yyyy, zzzz, aaaa, bbbb are all some arbitrary addresses shown in the above figures from 6.1 to 6.4.
From the figures 6.1 to 6.4 , it is very clear that we have used only one pointer i.e vptr , instead of four different pointers to point to four different variable of different data types, where space complexity is more. Only one thing that the programmer should keep in the mind while coding is that proper typecasting should be done depending on the different data types.
Void pointers are used in places where you need to work with different pointer types in the same code. One commonly used example is the library function qsort:
base is the address of an array, nmemb is the number of elements in the array, size is the size of each element, and compar is a pointer to a function that compares two elements of the array.

Pointer Arithmetic on Void*

Let us learn how to apply pointer arithmetic on the void pointers through the bug code as shown in the Fig 7 given below.
 

Fig 7: Bug code

Fig 8: Output of the bug code shown in Fig 7

From the above result, one can see that we are not getting the expected output. Surprisingly what went wrong ? Let us analyze the above code & output we got.
1. From the output it is very clear that addresses are incremented by one one byte, this is because the gcc compiler assumes sizeof(void) is 1 byte long.
2. So, when we increment void pointer by one, it is incremented by one byte long as one can observe this from the Fig 8(address part).
3. Now coming to the value part, the first value i.e arr[0] is getting printed correct, but after that all the values are wrong, this I am explaining through the pictorial representation as shown in the Fig 9
to Fig 13 below.
Note : The output depends on the endianness of the architecture.
Fig 9
Fig 10
Fig 11
Fig 12
Fig 13
From the above five figures, we can see why we are not getting the expected output. So the corrected code along with expected output is shown in the Fig 14 & 15 given below,

Fig 14 : Correction to the code given in Fig 7

Fig 15: Expected output for the code given in Fig 11.


void pointers can be assigned to any pointer value. One cannot dereference a void pointer without proper typecasting. Functions such as malloc, calloc, free utilize void pointers.

Sunday, February 16, 2014

Stack overflow - ‘Interrupts’ your ‘flow’

This is my first step to blogging world, where words matter and quality counts. I was befuddled while searching for my first blog topic. For last one month I was working on PIC 16F877 faced some challenges which i was not aware of. So finalized that I'm going to write on issues I faced.

In this blog would like to start with stack-overflow in embedded-systems. First of all, I gone through Wikipedia description of stack overflow. There’s nothing wrong with the description – it’s just incomplete from an embedded systems perspective. So decided to investigate on that and start a blog.

What’s your stack size set to?

Most embedded systems compilers are designed to work with a particular family of processors. The low end of the family may have a tiny amount of memory (e.g. 128 bytes). For example 8 bit PIC architecture is that the stack size is fixed. It varies from a depth of 2 for the really low end devices to 31 for the high end 8 bit devices. The most popular parts (such as the 16F877) have a stack size of 8.

Which stack is overflowing?

Many processors implement multiple stacks. A typical separation is a call stack (upon which the return addresses of functions are stored) and a data or parameter stack (upon which automatic variables are stored). Once you’ve made the determination which stack is overflowing then finding out exactly what gets placed on that stack will help lead you to the solution to your problem. If you can see no high level language construct that is causing the problem, then the single most likely cause of your misery is an interrupt service routine. 

Reasons
  1.  An interrupt service routine can use up a huge amount of space on the stack. This problem is arise if your system allows interrupts to be nested (that is, it allows an ISR to itself be interrupted).
  2. Certain library functions (like printf and companions) can use an enormous amount of stack space.
  3. Calling functions in nested manner, going beyond your stack size.
  4. If you are writing partially in assembly language, and you failing to pop every register that you pushed? This often occurs if you have more than one exit point from a function or ISR.
  5. If you are writing entirely in assembly language, and you are not setting up the stack pointer correctly, and you don't know which way the stack grows?
  6. Have you made the mistake of programming a micro-controller that you don’t understand? For example, low end PIC processors have a tiny call stack which is easily overflowed. If you are programming a PIC and don’t know about this limitation, then I’m not surprised you are having problems.
If none of the above solve your problem, then you are most likely in to a stack over-write problem. That is, a pointer is being de-referenced that results in the stack being overwritten. This can often arise when you allocate an array on the stack and then access an element beyond the end of the array.

Next blog we will see how to compute your stack size.

Thursday, December 12, 2013

Embedded Linux - How to use Vim Editor?

Vim is a text editor written by Bram Moolenaar and first released publicly in 1991. Based on the vi editor common to Unix-like systems, Vim is designed for use both from a command line interface and as a standalone application in a graphical user interface. Vim is free and open source software and is released under a license that includes some charity-ware clauses, encouraging users who enjoy the software to consider donating to children in Uganda.The license is compatible with the GNU General Public License.

Although Vim was originally released for the Amiga, Vim has since been developed to be cross-platform, supporting many other platforms. In 2006, it was voted the most popular editor amongst Linux Journal readers. Bram Moolenaar began working on Vim for the Amiga computer in 1988. Moolenaar first publicly released Vim (v1.14) in 1991.

The name "Vim" is an acronym for "Vi IMproved" because Vim is an extended version of the vi editor, with many additional features designed to be helpful in editing program source code. Originally, the acronym stood for "Vi IMitation", but that was changed with the release of Vim 2.0 in December 1993.A later comment states that the reason for changing the name was that Vim's feature set surpassed that of vi.