Welcome to DrDAQ Linux Programming Lesson #1: introduction

JUST A REMINDER:  for those of you who have not yet received your confirmation that you have been
subscribed to the mailing list please contact us by email immediately.

In memory of Linda.  Worldwide Cancer sites here.    Canadian Cancer donations here.
 
 

Hint: All of these lessons  are designed to be worked on offline.  For those of you with dialup Internet access  you might find it helpful to print off the page for each lesson and work from the printout.

At this point we are making the assumption that you have purchased the DrDAQ unit that we will be using throughout this course.

We are making the assumption that you already have a  working knowledge of Linux SIMPL programming.

Perhaps you have just completed the iCanProgram: Linux Programming the SIMPL Way or Extreme Linux Programming courses for example.
 
 

Our plans

This course is about programming under Linux for the DrDAQ.

This is not a course about C programming under Linux although we make the assumption that you can find your way around the C language.

This is not a course about Tcl/Tk GUI programming under Linux although we will be using this very capable toolkit and language to build up our GUI's.

The DrDAQ is a sophisticated device with several sensors for which data can be acquired.     This course will focus on some basics rather than all the sensors.

This course will be as much about code organization and techniques associated with evolving existing Open Source code to suit our needs.

Most of all we hope you enjoy learning with us.
 
 

Getting organized

We are going to need to create a few directories to keep ourselves organized in this course.

I'm going to suggest that you create a set of subdirectories called

icanprogram/picodriver/
icanprogram/picoMgr/
icanprogram/picoGUI

We will be wanting to use the Linux driver for our project.
 
 

Installing the Linux driver for the DrDAQ

The source code for the DrDAQ Linux driver can be downloaded from here.

The file in question is called

picopar.tar

tar -xvf picopar.tar

README.TXT

If you are having driver compilation problems: This driver is known to compile under Redhat's gcc version 2.96.      Under gcc version 3.2 (which is used by SuSE 8.1 for example) the compilation complains about <asm/*> and <linux/*> include paths.     If you add a "-I/lib/modules/`uname -r`/build/include" to the compile line you can make this compilation work. Don't hesitate to use the mailing list to ask for assistance.

We are now ready to give our newly installed driver a test run.
 
 

Test run on the DrDAQ Linux driver

In the picodriver directory the "make" command should have resulted in a file called:

ddtest

All you have to do is type ddtest and the program should prompt you for a parallel port number between 0 and 2.

On my system it is "0".      You may have to experiment on your system.

The ddtest program will then prompt you with a menu of options which are designed to stimulate all the features on the DrDAQ unit.

Hit "L" to toggle the LED.

You should observe that the LED on the board toggles between on and off.
 

Congratulations!  You have successfully installed the Linux DrDAQ driver on your system!

 
 
 

Our project for this course

If you recall the SIMPL paradigm talks about processes which are either "senders" or "receivers".

We will be wanting to create a "receiver" process which can accept messages, interact with the driver in exactly the same manner as the ddtest program is and Reply() back any data.

We will want to write some GUI programs (similar to those which come with the Windows software) to exercise our DrDAQ unit.

All together our software picture might look something like:

As with our previous work with SIMPL we will want our design to utilize tokenized messages so that we can make out work fully extendable and readily testable.
 
 

picoMgr

The picoMgr will be the heart of our project.

A tokenized message will be received indicating that we want to interact in some fashion with the DrDAQ driver.  (toggle LED, read sound, etc.)

The appropriate ioctl() call will be made to the driver in exactly the same manner as the ddtest sample code above.

Depending on the circumstance data may be returned.      In that case this data  would be packaged into the Reply() and forwarded back to the message originator.
 
 

GUI

It is always best to try to design a GUI as a  message receiver only.

A GUI which is a "sender" will be forced to block for the time it takes to gather the information from the DrDAQ.      In some cases this stall might result in an acceptable "feel" but in many cases the users will not like it.

Fortunately with SIMPL we can convey information in messages both in the Send() branch and in the Reply() branch.        The Reply() branch by definition unblocks the original sender and thus is non blocking.

We will utilize the Reply() branch to carry our messages from the GUI to the DrDAQ.

The conduit process between the two SIMPL receivers will be the picoCourier.
 
 

picoCourier

The picoCourier is a SIMPL sender.

It will spend most of its time blocked waiting for a Reply() from the GUI.

When the user selects an action on the GUI which requires info from the DrDAQ,   a Reply() message will be composed and relayed back to the picoCourier process.

The picoCourier process will then turn around and Send() this message to the picoMgr and wait for the reply containing the data.

When this reply is received the picoCourier will turn it around and Send() it back to the GUI and the cycle will repeat.
 
 

Exercises

In the next lesson we will be building the picoMgr with enough smarts to toggle the LED.

Go ahead and develop the tokenized messages and the skeleton of this process.
 
 

Summary

Let's summarize what you have learned in Lesson1

• you  have  installed your DrDAQ Linux driver
• you have been exposed to the project design