Thursday, August 2, 2007

DSP Chip Market rises by 8% in 2007

The DSP chip market is forecast grow a moderate 8% in 2007
The market for general-purpose digital signal processor (DSP) chips is forecast to grow 8% in 2007 to the $9 billion level according to a new market study from Forward Concepts, here. The new study, "DSP Chip Strategies '07" predicts a more typical growth of 15% in 2008 driven by communications and multimedia applications. But the new study also emphasizes the even bigger embedded DSP market that will grow to $17.6 billion in 2007, to almost twice the size of the general-purpose DSP chip market. The new in-depth study is believed to be the most comprehensive study available of markets driven by DSP technology, and includes the results of a new survey of DSP professionals in over 30 countries.
Forward Concepts’ President and Principal Analyst, Will Strauss, is the author of the study and he is considered the foremost authority on DSP market trends. According to Mr. Strauss, “The general-purpose DSP market is the best known and is dominated by Analog Devices, Freescale, Agere/LSI and Texas Instruments. The embedded DSP market, on the other hand, is where most new opportunities for emerging companies are because of lower barriers to entry. For example, a number of new companies identified in the study are introducing parallel array processor chips for unprecedented DSP horsepower on a single chip at relatively low clock frequencies and reduced power consumption."
The embedded DSP market is dominated by companies like Qualcomm, Broadcom, Marvell and Infineon, with most of their DSP products offered as Systems on Chip (SoC). Because of the heavy SoC emphasis, the major RISC vendors have added DSP capability to their product offerings. The report profiles the DSP market stance of these and over 100 other chip and core vendors.
The study points out that the general-purpose DSP market is dominated by communications applications, with cellular being the biggest. The embedded DSP market, however, is more closely identified with multimedia applications. But, that market segment also includes communications chips for Wi-Fi, WiMAX and Bluetooth as well as DSL and cable modems. All of these and new DSP-centric markets like DAB and HDTV are also forecast in the report through 2011.
This is the only study available that provides worldwide equipment production forecasts by major application and geography with IC and DSP penetration for each. This is a valuable resource for business planning by both chip vendors and their customers.

Wednesday, August 1, 2007

Writing a Linux device driver

from : http://www.freeos.com/articles/2677/

Does the idea of writing a Linux device driver sound difficult? If
you have some basic programming experience, the task is
simpler than you think. Get started with this quick primer on
device driver programming.

What do I need to know about writing drivers?

Basic knowledge of kernel compilation, a good deal of programming
experience in C under Linux and lastly, the right techniques of data
structures, like linked list is essential along with their data types.

The first thing a programmer must know before attempting to write a
driver, is to know how the Linux kernel source compiles, paying attention
to the compilation process (the gcc compiler flags).

Choosing the device type

a) Block drivers

A block device is something that can host a filesystem such as a disk. A
block device can only be accessed as multiples of a block, where a block
is usually one kilobyte of data .

b) Character drivers

A character device is one that can be accessed like a file, and a char
driver is in charge of implementing this behaviour. This driver implements
the open, close, read and write system calls. The console and parallel
ports are examples of char devices.

Device drivers in Linux are known as modules and can be loaded dynamically
into the kernel using the insmod command.

A single module can be compiled alone, and also can be linked to the
kernel (here, care has to be taken on the type of driver).

eg: A simple module

#define MODULE
#include

int init_module (void) /* Loads a module in the kernel */
{
printk("Hello kernel n");
return 0;
}

void cleanup_module(void) /* Removes module from kernel */
{
printk("GoodBye Kerneln");
}

Compiling the module

# gcc -c hello.c
# insmod hello.o

The output is

Hello kernel

# rmmod hello.o

GoodBye Kernel

How init_module works?

init_module loads the relocated module image into kernel space and runs
the module's init function.

The module image begins with a module structure and is followed by code
and data as appropriate.

The module structure is defined as follows:

struct module
{
unsigned long size_of_struct;
struct module *next;
const char *name;
unsigned long size;
long usecount;
unsigned long flags;
unsigned int nsyms;
unsigned int ndeps;
struct module_symbol *syms;
struct module_ref *deps;
struct module_ref *refs;
int (*init)(void);
void (*cleanup)(void);
const struct exception_table_entry *ex_table_start;
const struct exception_table_entry *ex_table_end;
#ifdef __alpha__
unsigned long gp;
#endif
};


All of the pointer fields, with the exception of next and refs, are
expected to point within the module body and be initialized as appropriate
for kernel space, i.e. relocated with the rest of the module.

Return Values

On success, zero is returned. On error, -1 is returned
and errno is set appropriately.

Errors

EPERM The user is not the superuser.

ENOENT No module by that name exists.

EINVAL Some image slot filled in incorrectly, image->name
does not correspond to the original module name,
some image->deps entry does not correspond to a
loaded module, or some other similar inconsistency.

EBUSY The module's initialization routine failed.

EFAULT name or image is outside the program's accessible
address space.

How cleanup_module works?


cleanup_module attempts to remove an unused loadable module entry. If
name is NULL, all unused modules marked auto clean will be removed.

Return Values

On success, zero is returned. On error, -1 is returned and errno is
set appropriately.

Errors

EPERM The user is not the superuser.

ENOENT No module by that name exists.

EINVAL name was the empty string.

EBUSY The module is in use.

EFAULT name is outside the program's accessible address
space.

This simple module is called skull, short for Simple Kernel Utility For
Loading Localities.

General flags used for compiling any driver are

-D__KERNEL__ _DMODULE -O -Wall -I$(INCLUDEDIR)

Note: The INCLUDEDIR should contain the header files of the kernel source.

Module code has to be recompiled for each version of the kernel that it
will be linked to. Each module defines a symbol called kernel_version
which is defined in . In case of a version mismatch, use
the insmod -f (force) option to load the module.


Sunday, July 29, 2007

Makefile continued..

After reading my previous post you guys might have got a good understaning of makefile.

Let met put my understanding in this way.

Makefile has mainly 3 parts.
(1)target
(2)dependencies and
(3)rules

and format is like this
target: dependencies
rules

each dependency can be another target :)
for example say our final target is linux and we have two librarries lib1.o and lib2.o as dependencies for linux


makefile looks like this

linux: lib1.o lib2.o
gcc -g lib1.o lib2.o #(this is a comment) A tab is required before gcc
lib1.o: lib1.c
gcc -g -c lib1.c
lib2.o: lib2.c
gcc -g -c lib2.c



tryout this guys..lemme do a char device driver in da mean time.

Saturday, July 28, 2007

The Makefile..

I used to refer this article while studying the Make system
link : http://oucsace.cs.ohiou.edu/~bhumphre/makefile.html

Makefile Getting Started

What is Make?

Make is a program that looks for a file called "makefile" or "Makefile", within the makefile are variables and things called dependencies. There are many things you can do with makefiles, if all you've ever done with makefiles is compile C or C++ then you are missing out. Pretty much anything that needs to be compiled (postscript, java, Fortran), can utilize makefiles.

Format of Makefiles -- Variables

First, lets talk about the simpler of the two ideas in makefiles, variables. Variable definitions are in the following format:
VARNAME = Value
So lets say i want to use a variable to set what compiler i'm going to use. This is helpful b/c you may want to switch from cc to gcc or to g++. We would have the following line in our makefile
CC = gcc
this assigns the variable CC to the string "gcc". To expand variables, use the following form:
${VARNAME}
So to expand our CC variable we would say:
${CC}

Format of Makefiles -- Dependencies

Dependencies are the heart of makefiles. Without them nothing would work. Dependencies have the following form:
dependecy1: dependencyA dependencyB ... dependencyN
command for dependency1

Very Important:

The commands underneath the dependencies must have a tab before them. This lets make know it is a command and not some kind of crazy dependency.

So how do we read what was just written above? Dependency1 is dependent upon dependencyA, and dependencyB, up to however many dependencies you have. The program make, looks at dependency1 and sees it is dependent upon dependencyA, so then it looks later in the makefile for how dependencyA is defined. Lets make a sample makefile:
myprogram: mainprog.cc myclass.cc
gcc mainprog.cc myclass.cc
That is probably one of the simplest makefiles that could be made. When you type make, it automatically knows you want to compile the 'myprogram' dependency (because it is the first dependency it found in the makefile). It then looks at mainprog.cc and sees when the last time you changed it, if it has been updated since last you typed 'make' then it will run the 'gcc mainprog.cc ..." line. If not, then it will look at myclass.cc, if it has been edited then it will execute the 'gcc mainprog.cc ..." line, otherwise it will not do anything for this rule.

Another example might be easier to see for dependencies, lets say you have a class, and more than one file depends upon objects of that class type. Then it makes sense to create a .o file of that class and compile it in with the file. Here is a sample of what I'm talking about

myprogram: mainprog.cc subfile1.o myclass.o
gcc mainprog.cc subfile1.o myclass.o

subfile1.o: subfile1.cc myclass.o
gcc -c mainprog.cc subfile1.o myclass.o

myclass.o: myclass.cc
gcc -c myclass.cc
Notice the dependencies here, when 'make' is run, the dependency called "myprogram" is run first, and then the dependency subfile1.o is found, and then the myclass.o dependency is foudn withint subfile1.o. So myclass.cc is compiled, then subfile1.o is compiled, then we are finally back up to the myprogram dependency. Finally all three dependencies are compiled in to create a.out.

Tying variables and dependencies together

You can use variables within your dependencies very easily. Lets take that last example, and use two variables, one for the compiler we are going to use, and another for the options to that compiler. This makes life a lot simpler if say we want to turn off debugging for all the code, or turn it on, whichever is preferred. Here is an example tying it together.
COMPILER = gcc
CCFLAGS = -g
myprogram: mainprog.cc subfile1.o myclass.o
${COMPILER} ${CCFLAGS} mainprog.cc subfile1.o myclass.o

subfile1.o: subfile1.cc myclass.o
${COMPILER} ${CCFLAGS} -c mainprog.cc subfile1.o myclass.o

myclass.o: myclass.cc
${COMPILER} ${CCFLAGS} -c myclass.cc
notice how clean this is? It is easy to add extra options and libraries to your compiler if need be. Life is a whole lot simpler with makefiles, for a final addition to our makefile lets make something that cleans out all our code, starting with what we had before, we simply add a new dependency, named "clean". The addition goes as follows:
COMPILER = gcc
CCFLAGS = -g
myprogram: mainprog.cc subfile1.o myclass.o
${COMPILER} ${CCFLAGS} mainprog.cc subfile1.o myclass.o

subfile1.o: subfile1.cc myclass.o
${COMPILER} ${CCFLAGS} -c mainprog.cc subfile1.o myclass.o

myclass.o: myclass.cc
${COMPILER} ${CCFLAGS} -c myclass.cc

clean:
rm -rf *.o a.out
So when we type 'make clean' at the command line, it will remove all our .o files and the executable that we have.

Conclusions

Makefiles are very very helpful when dealing with projects. The first thing you should do when making a project is create a makefile, it makes your life a lot easier. They are very powerful things, if you have any questions feel free to email me at bhumphre@cs.ohiou.edu have fun!

Last modified: Mon Oct 16 13:21:58 EDT 2000

s abt a char device..which takes data char by char...

.....This is a very good article..try your programmes with makefile..

Take a Jump....

Writing C programmes in linux is my current hobby. Yes its somewhat interesting ..much much than writing programmes on windows. Think of creating your on file and use your own open/read/write/close on that file...yes..its amazing.
I am gonna update this blog with whatever small work am doing on my linux laptop. I will try to explain basic device driver examples, makefiles etc etc so that beginners can get a good feel of the beauty of linux
and the extra knowledge it provides abt how stuffs work.