Communicate with an unknown usb serial device in linux

Hi all,
Recently I was trying to work with a 2D barcode scanner which was told to work as serial data device. When I inserted it in my linux system, there was nothing like a serial port or something in my "/dev" list. When I searched with the model number, I found nothing relevant to make it work. Usually it is suspected that the driver is not present in the system. I was really frustrated at that time since there was no lead and it had to be done soon. The material came with no driver. When I saw the syslog, it showed some path related to the device inserted. There I found information about the manufacturer and googled it which led me to a website where I found windows7 driver of this device. It felt like I was halfway there. I quickly downloaded the driver, installed and run it. And yes, I was able to view serial data after scanning 2D barcodes. But this wasn't it. It had to work on a linux system too.

As I tried to know more about the problem, I learned that there is a way. Writing a udev rule to control the usb device sounded like a cool thing to do. But the thing is, I had never written a udev rule and I was anxious to make the device work. So I kept searching around a bit and found something that said an unknown usb serial device can be recognized by the system if we load the kernel device driver with the product id and vendor id of the device. Finding product id and vendor id was easy. It is printed by "lsusb" command. So I gave it a try.

modprobe usbserial vendor=0x1eab product=0x0d02

I saw "dmesg" and there it was. the device was recognized as a serial device and found as /dev/ttyUSB0 .

Lesson: An unknown serial usb device doesn't need any extra driver but the usual usbserial driver can be used to register it in the linux kernel.

multicast in lwip using LM3S6965 micro-controller

Hi all,

recently I was working on sending multicast packets to multiple LM3S6965 micro-controllers. I was using lwip library and my experience with lwip is not much.
So, naturally I googled for some examples to get the start. But unfortunately I could not find any complete working example. So, I did a bit of trial and error.
After struggling a while, I was able to send and receive multicast packets. So, I thought I would write a working example for this. I did this using raw sockets and without RTOS.

A few things to do first:-
1. enable igmp in lwipopts.h file by adding this line :-
#define LWIP_IGMP 1
2. enable udp options and disable NETCONN and SOCKET options from lwipopts.h file
#define LWIP_UDP 1
#define LWIP_NETCONN 0
#define LWIP_SOCKET 0

3.if you are using DHCP options then set netif flags in dhcp.c file.
Replace line: netif->flags |= NETIF_FLAG_DHCP;
With line: netif->flags = NETIF_FLAG_DHCP | NETIF_FLAG_BROADCAST | NETIF_FLAG_ETHARP | NETIF_FLAG_LINK_UP | NETIF_FLAG_IGMP;

Now you are all set. Write the code to start receiving and send a sample packet.


void UDP_Multicast_init(void)
{
struct ip_addr ipgroup,test_ip;
struct udp_pcb *g_udppcb;
char msg[] = "gaurav";
struct pbuf* p;
p = pbuf_alloc(PBUF_TRANSPORT,sizeof(msg),PBUF_RAM);
memcpy (p->payload, msg, sizeof(msg));

IP4_ADDR(&ipgroup, 238, 0, 0, 3 ); //MultiCasting Ipaddress.
#if LWIP_IGMP
iret = igmp_joingroup(IP_ADDR_ANY,(struct ip_addr *)(&ipgroup));
UARTprintf("ret of igmp_joingroup: %d \n\r",iret);
#endif
g_udppcb =( struct udp_pcb*) udp_new();
udp_bind(g_udppcb, IP_ADDR_ANY, LOCAL_PORT); //to receive multicast
udp_recv(g_udppcb, NET_UDP_rec,NULL);// (void *)0); //NET_UDP_rec is the callback function that will be called every time you receive multicast
udp_sendto(g_udppcb,p,&ipgroup,LOCAL_PORT); //send a multicast packet
}

Note that you don't need udp_connect to send or receive multicast.

It worked for me. I use lwip 1.3.2

Rename multiple files with bash script

Hi there,
Recently I came up with a problem related to filename of downloaded files.In my college I use DC(Direct Connect) client to download files from other peers.Recently I downloaded a large number of music videos which remained in temporary directory and did not move to music directory.Although It downloaded completely, It remained in temporary directory and hence name of files was in the format "filename.(avi/mpg/flv etc.).(some chars).dctmp". So I had to rename them.Definitely, I couldn't do it manually as there were more than 1000 files.Hence I tried to write a bash script for renaming all of them at once.
Initially I tried to store the filename as "*.*.dctmp" in which I would trim the "*.dctmp" part.Hence the remaining part would the desired filename(with proper externsion).But storing the filename like that did not work out.
Then I saw that in temp files, there is a common pattern that before "dctmp" extension, there are exactly 39 chars. Then I tried a different method of trimming filename which is explained below with code.


code :

for i in *.dctmp
do
len="${#i}" ;
let len-=46
#echo "$len";
name="${i:0:len}" ;
#echo "$name"
mv "$i" "$name" ;
done

save it with name.sh and run "bash name.sh" on terminal.The script should be run in the same directory in which temp files are present.

e.g. Guns N' Roses - Welcome To The
jungle.mpg.47IMRQGAGFWOA7GMLZTK3X6QFIGR4P4EKHDRHKI.dctmp became Guns N' Roses - Welcome To The Jungle.mpg

Worked on ubuntu 10.10

Microkernel approach in minix3

In computer science, a microkernel is the near-minimum amount of software that can provide the mechanisms needed to implement an operating system. These mechanisms include low-level address space management, thread management, and inter-process communication (IPC).As an operating system design approach, microkernels permit typical operating system services, such as device drivers, protocol stacks, file systems code, to run in user space.MINIX3 has around 4,000 lines of code. Kernels larger than 20,000 lines are generally not considered microkernels.


Reflecting on the nature of monolithic kernel based systems, where a driver (which has approximately 3-7 times as many bugs as a usual program) can bring down the whole system,MINIX3 aims to create an operating system that is a "reliable, self-healing, multiserver UNIX clone".In order to achieve that, the code running in kernel must be minimal, with the file server, process server, and each device driver running as separate user-mode processes. Each driver is carefully monitored by a part of the system known as the reincarnation server. If a driver fails to respond to pings from the reincarnation server, it is shut down and replaced by a fresh copy of the driver.In a monolithic system, a bug in a driver can easily crash the whole kernel, something that is much less likely to occur in MINIX3.



Reliability factors in MINIX3 :-

Reduce kernel size
Cage the bugs
Limit drivers' memory access
Survive bad pointers
Tame infinite loops
Limit damage from buffer overruns
Restrict access to kernel functions
Restrict access to I/O ports
Reincarnate dead or sick drivers
Integrate interrupts and messages

Architecture :


The approach that MINIX 3 uses to achieve high reliability is fault isolation. In particular, unlike traditional OSes, where all the code is linked into a single huge binary running in kernel mode, in MINIX3, only a tiny bit of code runs in kernel mode about 4000 lines in all. This code handles interrupts, process scheduling, and interprocess communication. The rest of the operating system runs as a collection of user-mode processes, each one encapsulated by the MMU hardware and none of them running as superuser. One of these processes, dubbed the reincarnation server, keeps tabs on all the others and when one of them begins acting sick or crashes, it automatically replaces it by a fresh version. Since many bugs are transient, triggered by unusual timing, in most cases, restarting the faulty component solves the problem and allows the system to repair itself without a reboot and without the user even noticing it. This property is called self healing, and traditional systems do not have it.

An Approach to core dump in minix3

Hey people,
I have been trying to work around implementing core dump in minix3.A clear understanding of what core dump is necessary for its design. I will start with what a core file is.

The core file contains the memory image of the process, which can be used for debugging purposes.A core file is created when various errors(depends on how dumping is implemented) occur. Errors such as memory-address violations, illegal instructions, bus errors, and user-generated quit signals, commonly cause this core dump. The core file that is created contains a memory image of the terminated process.

The contents of a core dump are organized sequentially in the core file.It may follow any data structure to produce dump.Below is a rough idea of what things can be included.

Core header -> Defines basic information about the core dump, and contains offsets that locate the remainder of the core dump information.
User stack -> Contains a copy of the user stack at the time of the core dump.
Data area -> Contains the user data section.
Memory mapped regions -> Contains the anonymously mapped regions.

Process Control Blocks :

A process control block (PCB) exists for each process, describing the state of that process by maintaining the LDT, as well as saved register values, used to save the process state while a process is waiting to be scheduled. The PCB is a struct proc, containing important information about one process, including the process number and status. Also accessible through the PCB, via the p_map memory map, are the base addresses and physical and virtual sizes of the three segments of each process: (1)the text, (2)data, and (3)stack segments.

In minix architecture the microkernel, file system, and memory manager all maintain their own process tables but keep strict correspondence between these entries.The complete state of a process is defined by the process' data in memory, plus the information in its process table slot.

Some Merits of GDB

There are some impressive features of GDB which I would like to point out :

1. GDB targets a good range of processors which includes Alpha, ARM, AVR, H8/300, System/370, System 390, X86 and its 64-bit extension X86-64, IA-64 "Itanium", Motorola 68000, MIPS, PA-RISC, PowerPC, SuperH, SPARC, and VAX.

2.GDB offers a remote mode.gdbserver can be used to remotely debug the program

3.The file caching mechanism is embedded within BFD and allows the application to open as many BFDs as it wants without regard to the underlying operating system's file descriptor limit.

Some features which I would like to have :

Display of variable values in a tree structure by a single command.

Various Aspects of a GNU Debugger

This blog is intended to give a brief overview of GDB and some internal features. GDB is an interactive tool. GDB should be responsive to the user.

GDB can do four main kinds of things (plus other things in support of these) to help you catch bugs in the act:

* Start your program, specifying anything that might affect its behavior.
* Make your program stop on specified conditions.
* Examine what has happened, when your program has stopped.
* Change things in your program, so you can experiment with correcting the effects of one bug and go on to learn about another.


GDB consists of three major subsystems:

1. User interface: The user interface consists of several actual interfaces, plus supporting code.

2. Symbol handling (the symbol side): The symbol side consists of object file readers, debugging info interpreters, symbol table management, source language expression parsing, type and value printing.

3.Target system handling (the target side): The target side consists of execution control, stack frame analysis, and physical target manipulation.


GDB uses a technique called prologue analysis to find frame sizes and saved registers. A prologue analyzer disassembles the function's machine code starting from its entry point, and looks for instructions that allocate frame space, save the stack pointer in a frame pointer register, save registers, and so on.

Breakpoint Handling:
Hardware breakpoints are sometimes available as a builtin debugging features with some chips. Typically these work by having dedicated register into which the breakpoint address may be stored. If the program counter ever matches a value in a breakpoint registers, the CPU raises an exception and reports it to gdb.