|Languages for Embedded System Design:
|* indicates a CVN student|
|VxWorks and Real Time Linux|
Most existing real-time operating system such as VxWorks, is
based on proprietary technologies and that are designed to run on
processors tailored to specific applications. This often means that
they are quite expensive because of licensing fees and there is
usually a large investment of time and capital involved in designing
application specific hardware. Real time Linux provides a large cost
savings over proprietary real-time operating systems since it is free
and fully featured. Besides general operating system functions, both
commercial and real-time Linux provide modern real-time multi-media
applications such as graphics, sound and network drivers. This project
will focus on performance measurement of kernel functions provided by
the two operating systems. The project, in particular, will evaluate
In order to accurately measure these entities, the hardware platform will be chosen such that both of these operating system will support. The results of the experiment will be used to demonstrate and analyze the efficiency of commercially and publicly-available operating systems.
|Study of performance of two RTOS|
|Shahmil Merchant, Kalpen Dedhia|
Implementation -------------- Install 2 RTOS RTLinux and Ucos-ii as a dual boot on a machine. Run certain benchmark applications to test OS performance. Challenges ---------- - To get RTLinux and Ucos-ii as a working RTOS. - Getting a group of applications capable of running on both the OS. - Techniques of setting benchmarks. Requirements ------------ - A stand alone dedicated machine(We are hoping you could get us one). - Access to computer science account. - Ucos software
|Language and Operating System Performance|
|Ambika Pajjuri*, Haseeb Ahmed*|
We propose in the time frame of the semester to do a performance analysis for a choice of select algorithms varied over multiple systems running on different CPU and Memory models. Our proposed languages for comparison are Java and C/C++. These languages have emerged from a "close to assembly" paradigm (the C language) to a high level object oriented model adopted for Java. Our main objective is to study the strengths and weakness of these languages through the analysis of some traditional and some specially geared algorithm implementations. Our metrics will be based on (in no particular order):  Speed of execution.  Memory usage: [2.1] Algorithm static memory (compiled size) [2.2] Operation memory (during code execution)  Overheads imposed by choice of language.  Selective features offered by each of the above languages and their impacts to algorithms (i.e. are the features more Hype or a Reality?) Our initial plan consists of using the Linux and Windows Operating systems. We intend to add some variety by experimenting with *nix-flavors on different CPU and memory models. (This will vary based on machines the project team has access to individually as well as shared computer resources at Columbia University).
|A Domain-Specific Language for Network Interface Cards|
|The purpose of this project is to propose a specific domain language (SDL) for the implementation of device drivers for network interfaces cards (NIC). The idea is based on the GAL language proposed by Thibault Scott. The spotlight of the project will be the studying of current implementation of NIC device drivers and it will follow an attempt to patronize common components that consist each driver. The ultimate objective will be the proposal of a language that will follow the philosophy of specific domain languages. Of course an introductive literature survey will set the proper base.|
NIC drivers for Linux
TULIPsource code: Linux/drivers/net/tulip
DP83840A for the MII
|An ARM Simulator|
What is a simulator for assembly languages? : A Simulator is a simple virtual machine that can directly execute compiled files normally loaded onto processors. It provides a way for people to learn the essential lessons of computer architecture and assembly languages without getting bogged down in the confusing details and idiosyncrasies that plague real architectures. Which Assembly Language : I am interested in working with RISC architectures and would like to build a simulator of the ARM processor. ARM [Advanced RISC Machines] processor: The ARM is a general-purpose 32-bit microprocessor based on RISC principles. Its instruction set and related decode mechanism are much simpler that those of Complex Instruction Set Computers [CISC] machines. It has two instruction sets: - The standard 32-bit ARM set - A 16-bit THUMB set Feature List : Of the two instruction sets, I am going to concentrate on the 32-bit ARM set. One objective of this simulator would be to enable developers to test out their new hardware. The system must be extensible so that it is possible to add hardware modules in order to test the new hardware. The features of an ARM architecture that I would like simulate are: - assembler: to generate exact binary/machine code corresponding to real compiled ARM machine code for my simulator to execute - support a smaller number of registers (general purpose and dedicated, e.g. stack pointer, frame pointer) - correct emulation of arithmetic, logical, memory-data transfer and branch instructions - use external compiler to generate ARM assembly from C-code [http://celab21.pc.elec.uq.edu.au/~tina/arm-gcc.html] - test simulator against various real-world programs - have a configurable way of modeling the Instruction set and/or architecture so that newer instructions and registers, etc can be incorporated into the simulation Optional Features : If I have enough time, I will incorporate some of the following into the simulator - a debugger: with the ability to insert special breakpoint instructions in the machine code, and instruction step features - an integrated development environment that provides a graphical user interface Really optional Features : - Develop a tiny interactive shell program/OS for the simulator that can accept program names, and load [from host file system] and execute them on the simulator
As the complexity of products increases
and the market pressure in the technology industry
climbs, the importance of reusing complex building
blocks also increases. Interface synthesis, which
attempts to determine an interface between two
incompatible protocols that are trying to
communicate with each other so that data transfer
can occur, attempts to solve the problem of
reusing building blocks. This results in the
ability to reuse two complex blocks that may have
not been able to communicate without interface
synthesis. Since I have been doing research on
this topic for only a few weeks, I propose the
following for my research project:
|Modeling a Simple Wristwatch using Esterel Studio|
|Minsuk Lee, Cheryl Koesdjojo, Dixon Koesdjojo, Harish Peri|
The purpose of this project is to model a simple digital wristwatch
using the Esterel Studio software and explore its limitations and
abilities. The wristwatch we propose to model will conform to the
following list of features:
|SystemC and Verilog Comparison|
|I would like to implement a simulation of an alarm clock in both Verilog and SystemC. The point of this project would be to compare the two implementations as well as learning the two languages and their respective simulation tools. The comparison will expose advantages and disadvantages of both languages, concluding in which of the two is more appropriate for such a project. The design itself will include a way to load a new time, as if a person was to manually reset it. The device will also have a way to set the actual alarm time and a timed comparator to set the alarm on, when it matches the current time. If time permits it, I would like to add features such as a "snooze" button. This could be implemented by an AND gate which has as inputs the snooze button itself, and output of the comparator mentioned earlier. When the output of this AND gate becomes asserted, an adder could be triggered to add, say 20 minutes to the preset alarm time, hence having the device ring again in 20 minutes. I am not too sure as to how challenging this idea is, since I need to figure out which software tools I will be using, and how long it will take me to familiarize myself to them and to the languages. In light of this, I may need to add or subtract features in order to meet deadlines.|
|Study of Different Real Time Kernels for Linux|
In our everyday life we are surrounded by embedded
systems. In order for these systems to work, they are equipped with an
operative system, compact in the sense that there is not so much
space, but having as many functions as possible. And, since the
development of embedded systems, Linux has existed to fulfill the
necessities of those devices. Nowadays, several Linux distributions
are being installed in embedded systems with total success.
At this point, we may ask ourselves, could we go even farther? Of course we can. Once we have the service guaranteed, we work on making improvements. Up to now, since operatives systems have fit perfectly l in embedded systems, we look for quick responses. In that sense, real time operating systems began to be transported onto embedded platforms.
And, again, Linux was there to offer those improvements but with the lively open-source philosophy that makes us free. It is amazing the huge quantity of people that are actually working in the development of real-time Linux kernels (both for embedded or non-embedded systems).
Since I am interested in the Linux world and philosophy, I have thought that this is a good chance to dig deeper into the interesting topic of real time kernels in Linux.
The following describes a rough outline of my project proposal. First, I propose to study the differences between already developed kernels (including both open-source and commercial versions), and see how they are implemented. I will focus on the open-source versions, especially in those developed by Kansas University, Berkeley, Carnegie Mellon, and the Politecnico di Milano. The first step will involve the study of these kernels, their implementation, their ways of dealing with interruptions, their handlers, schedules, etc. As a second step, some testing will be done in order to observe the concordance between the theoretic development of the kernels and their practical performance. Finally, having understood the system, some modifications on the code in order to see different behaviors will be implemented.
|Comparison of Real-Time and Non-Real-Time Operating Systems|
|Dirk Bridwell* and Jan Miller*|
We propose to do the following:
Compare real-time and non real-time operating systems. We intend to make comparisons in three ways. First, we will compare the available facilities to support real-time operations. We will look at the types of synchronization mechanisms, task mechanism, and timers. Second, we will measure the times these mechanisms take. We will look at how deterministic the execution times are. Third, we will attempt to show that a program proven to meet its deadlines using Rate Monotonic Analysis will do so on all platforms. Or failing that attempt to explain why it did not.
We will be considering the following operating systems: Windows NT, Linux, RTLinux, and pSOS. The first two are well known non real-time operating systems. The second two are real-time operating systems. pSOS is a tradition RTOS, while RTLinux is a hybrid between an RTOS and a non real-time operating system.
In order to produce our Rate Monotonic Analysis we hope to use a piece of independently developed software. We are still trying to get a copy. This software also produces prototype code that we would then be able to execute on a given platform.
|Feasibility of an Embedded Network Real-Time Data Compression Protocol on the Rabbit 200 Microprocessor|
|Stephen Jan and Paolo de Dios|
|The great advantage of embedded systems is the ability they have to focus on few, specific tasks. The specificity allows the system to skip computational overhead that is typically associated with general purpose systems (i/o, interprocesses communication, compatability issues, etc...). This specificity comes with the price of resources. We are investigating the feasibility of taking an application that is typically associated with general purpose computing, and applying it to a embedded system. We are primarily interested in seeing how these tradeoffs manifest themselves in development and performance. The embedded system that we are targeting is the Rabbit TCP/IP development enviorment. This system uses a subset of C (Dynamic C), has very limited RAM (256K), and its processing power is minimal (18 MHz). The specifc application that we are targeting is data compression. We intend to port a data compression algorithim (possibly LZO) to Dynamic C, and benchmark its performance w/ a C implementation of the same application.|
|Connect via Embedded Linux and Java|
|This is a survey about the networking related features provided by embedded Linux. In this survey, we will summarize the major reasons why Linux is increasingly pervasive in embedded systems market. Seeing the trend that `everything to be connected', we will focus on the networking related features provided in embedded Linux, and compare several distributions. We will also put an eye on the use of Java in embedded systems version as long as the footprint is acceptable.|
|Copyright © 2001 Stephen A. Edwards||Updated Wed Dec 19 20:19:35 EST 2001||All Rights reserved|