Monday, 31 December 2007

Document Drop API - Now Added

Visitors to this site's previous manifestation at http://users.ecs.soton.ac.uk/cc1206 (my university hosted site) will recall Document Drop. Now in its second version, DocDrop has been improved to allow for folder-based organisation, commenting on individual projects and provision for a plethora of file types. Due to all-to-common occurances of illegal file uploading as well as the obvious security risks, only a limited number of users (tursted friends) have complete access to all its features. Notwithstanding, the uploaded files are availible for anyone to view and download, which brings me to the purpose of this post.

All personally created files referenced on this blog were/are stored in a relevant folders on DocDrop, therefore allowing readers to explore, edit and re-circulate code, information and programs. Since migrating this site to a more professional looking Blogger account, the DocDrop facillity has been removed (Blogger doesn't provide support for user-created PHP scripts - for obvious reasons).

Faced with the following options:
  1. Abandon DocDrop and provide permenant links to the necessary files hosted on my previous site
  2. Re-script DocDrop so that all the features previously offered can be accessed through the limited Blogger interface.
  3. Create an API (go-between) to offer only key features of DocDrop on this Blogger site

I chose option 3. The API takes the form of a static, but dynamically created JavaScript file which contains a 'light' copy of the database of all the files stored on DocDrop. The entries are stored in Arrays and sorted into folders to minimize the amount of JS code necessary to format and display the data. I wrote a short(-ish) PHP script which extracts most of the full txt database used by DocDrop and creates the aforementioned JS file.

The whole operation took just under three hours to write, test, rewrite and upload.

The Result

Blogger allows its users to add 'Page Elements' which can be of a variety of types; the one of interest being '3rd Party Scripts'. This allows JavaScript/HTML to be directly inserted into the element however a word of warning Blogger does not always insert the code you write exactly as you wrote it. In my experience the formatting (which is important for most code) was altered and prevented the scripts from running at all. The solution is to place all the code into a separate .JS file and link to it using the 'script' tag.

The DocDrop Blogger Interface now loads at the top of the sidebar on every page and consists of a drop-down box listing all the available folders currently uploaded. To view the contents of any of these folders, simply select a folder name and the list of files will be shown below. An image indicating the file-type, file namel, short description and 'date uploaded' are displayed for every file.

More Features

In the future I will gradually add more features and eventually the ability to upload files directly from this site. The code for DocDrop will be uploaded shortly (after third semester exams, so February) and the API code will follow. Hopefully other users of Blogger will find this helpful.

Try it out now!>>

Thursday, 27 December 2007

Conclusion To LCD PIC Project

This is the final post in this series of articles documenting the process of designing and developing a PIC controlled LCD module. I will outline the process of using the PC to dynamically display text on the Screen. This includes illustrating how to display the ?Now Playing? data from Windows Media Player as well as the drive capacities of all available drives.

Programming the Serial Port in Microsoft Visual Studio 2005

In the previous article in this series I used Windows HyperTerminal to send ASCI characters to the PIC which in turn sends them on to the LCD. HyperTerminal, although useful is limited in its operation. You may either enter data via the keyboard, or by selecting a pre-prepared text file to send. Therefore it is not possible to send dynamic (changing) information to the screen using this program. I chose to use C# as my programming language, which is part of Microsoft?s .NET 2.0. My reasons were that C# has a very comprehensive library for the serial port, more than necessary for this project. Added to this, I am currently learning C# for my university degree.

A Reminder about the PIC Buffer

The PIC program, once it has initialised the LCD, listens out for 8bits of RS232 (Serial Communication Protocol) at a time and stores each in its memory until it has 32 bytes of data. As soon as this happens, it prepares the data for sending to the LCD using its 4-bit wide bus and prints it onto the LCD. It then clears the buffer and listens out for the next 32 bytes. If the byte 0x10 is sent this is interpreted by the PIC as an instruction to clear the LCD by sending a special series of bits to the screen.

An Outline of the necessary Program

A successful program for sending text to the LCD in C# should:




  • Safely attempt to open a connection on the serial port (COM1 on my computer)

  • Send byte 0x10 to clear the screen

  • Wait for 70ms to allow LCD to clear screen

  • Print a test message to the screen to show the user that connection is established

  • Close the port safely

  • End with a message in the console window to show user that program terminated successfully


In addition to the above which only sends a static message to the screen the program must provide classes and methods to:




  • Accept a string of user entered text, shorten it to the maximum number of characters for the display, or if the string is shorter it should be padded with extra ?spaces? to fill up all the characters on the screen

  • Produces a variable length delay in program flow for use when clearing screen, and in between changing the display to give user long enough to read display

  • Get the current now playing information from Windows Media Player via the registry.

  • Format the Artist, Title, Album information so suitable for sending to the LCD. This means scrolling longer strings so that the user can view the whole of the string even if display is only 16 characters wide

  • Check the registry repeatedly to see if the song has changed and if display needs updating.

  • Get the drive information of all available drives on the computer and display the free space remaining.


A Word About The Code

The program is built up of four classes. The first is the Program class which contains the static method 'Main' which is the point at which the program starts executing. Secondly the class 'Connection' deals with establishing a connection and sending raw strings of text. It also formats the array of media information and sends/scrolls it where necessary. Strictly speaking this should be in another class if this program were to be a stunning example of encapsulation, which fortunately it isn't. The third class is 'Display' and handles the formatting of general strings of text (not media info) so that they are suitable for display on just two lines. It also stores the formatted text (both media info and general) in some object variables which can be accessed by other parts of the program. Finally the 'Now Playing' class deals with opening a connection to the registry and extracting the current Artist, Title, Album and Duration info. It also provides methods for checking if the registry has changed (i.e. the song has ended/changed).

Result

The result is very pleasant to watch. If the correct WMP plug-in is installed (WMP Blogging Plug-in available from the official WMP site http://www.wmplugins.com/ItemDetail.aspx?ItemID=287), and a song is being played the display cycles through all the available info showing the type of info on the top line (Artist, Album etc.) and the actual info on the bottom line, scrolling it neatly when necessary. As soon as the user closes WMP or disables the plug-in, the program switches to 'Drive Info' mode, displaying the free space available on all recognised drives. The program and screen then shut down.



Last Words

The code at first looks very long, but most of it is comments and half of what?s left is for formatting the Now Playing information and dealing with the registry. Of the remaining half, a quarter is the try{} catch{} statements for dealing with Exceptions. What?s left is the code that actually sends data to the port which I will summarise here: All code used in this project series is available in the DocDrop section of this site in the folder LCD Project.


Using System.IO.Ports;
...

SerialPort lcd =
new SerialPort("COM1", 4800,
Parity.None, 8, StopBits.One);
lcd.Open(); //open port
lcd.Write(new byte[] { 0x10 }, 0, 1);
//send hex instruction to return cursor to home
Delay(70); //allow LCD time to refresh
lcd.Write(message); //send string to LCD
lcd.Close(); //close port



Obviously it would be nice to build a visual Windows forms based interface, however that's a little beyond my reach at present and distracts from the job in hand which is PC->PIC interface. If in the future I create one I will of course upload it. Please comment on this app and offer suggestions in the comments section below.




The Next Project



After the success of the LCD project, I have set myself a bigger challenge - to make a robot.

After clearing out my old toy room at home I found a cheap radio controlled car which still worked. After regressing a couple of years and playing with it I decided to take the screwdriver to it and salvage it. Hoping to find a self-contained RF transmitter which I could just google for a datasheet and use in my own projects, unfortunately since the toy is over ten years old, inside all I found was a tightly packed circuit board populated entirely by discrete, dated, components. Over the next few weeks I will document the process of converting it into a PIC controlled car complete with sensors of some sort or other. Suggestions, however radical are welcommed on the comments section below.




Improving the PC-> PIC Interface

The first assembler program simply checked continually for data over the RS232 line and stored the information in a byte of memory. It then shunted the raw ASCII data to the LCD. However the LCD requires a time delay of 40us after each character is written before it can accept the next one. This means that the PIC then falls behind in receiving the next ASCII character from the PC.

To get around this, it was necessary to add a delay in the HyperTerminal program between sending each byte of data. This resulted in a tedious process of seeing the text appear one character at a time on the screen.

Therefore, I decided it would be best to send a complete 'screen' of data before attempting to write it. To achieve this it was necessary to create a buffer in the PIC memory, large enough to store 32 characters (bytes). This is easier said than done, since assembler provides no support for arrays and all memory storage must be preceded by a memory address. So I created a special subroutine to do this. Firstly I initialised 32 variables at the start of the program, then in the subroutine I used the provision of the PIC to manually advance the program counter so that with each new byte to be stored, the program jumps to the appropriate line of code and the next free variable. It is best understood by looking at a pseudo code example:



int byte1;
int byte2;
... ;32byte buffer
int byte32;

int current_count = 0;

function add_to_buffer(rs232_byte){
program_counter = program_counter + 2*current_count
byte1 = rs232_byte;
goto FINISH;
byte2 = rs232_byte;
goto FINISH;
......
byte31 = rs232_byte;
goto FINISH;

byte32 = rs232_byte;
goto FINISH;

FINSIH

if(current_count = 32){
current_count = 0;
write_data_to_lcd();
return;
}
else{
current_count++;
return;
}
}

The Result

With the buffer there is no need for a delay between each character since the time it takes to write to the buffer is much less than the interval between bytes sent over the serial connection. Now, once the buffer is full, the contents of the buffer is written immediately to the screen in one go, and the LCD appears to have changed 'all at once' instead of character by character. The end result is much more professional and enjoyable to read.

Also...

Another source of delay and annoyance was having to write 32 blank characters to the display in order to remove the previous text and clear the screen. To get around this I chose to use one of the un-used ASCII codes to act as a 'clear the screen' command which the PIC listens out for.

What Next.. C#!

HyperTerminal is good to prove a principle and for testing hardware but isn't very interesting, flexible or elegant to use. Therefore I chose to use Visual C# to write anything I want, including dynamic data such as emails, now playing info, and rss feeds. It turns out this isn't as difficult as you'd imagine, and in the next blog I will show you how I did it.

The Code

The PIC assembly code for this and previous versions will be available for download from the new DocDrop pages under the folder PIC Project.

(This post was originally available at http://users.ecs.soton.ac.uk/cc1206 and refers to DocDrop which is still availble at http://users.ecs.soton.ac.uk/cc1206/docdrop2.php. DocDrop will soon be 'ported' to this site)

DocDrop Version 2

Six months on from the first versions of DocDrop with the dodgy javascript coding and questionable colour scheme, version 2.0 is finally ready. The major issues with the first version were:

  • All the files were shown on the one page. As more were added the page became long and irritating to navigate.

  • The Descriptions and versions were not immediately visible and sometimes hard to find.

  • There was a limited range of file types accepted.

  • Once a file was uploaded it could not be moved, renamed or ammended without re-uploading.

New And Improved

Version 2.0 offers the following improvements

  • Documents are now arranged in 'Folders' like on windows systems. Documents can be moved between folders and uploaded to new or specific folders. Files can then be grouped appropriately and only folder names are shown on the main page.
  • There is a greater range of allowable file types which can be uploaded to the server. These include zip and iso as well as msi files.
  • There is better error reporting and feedback when uplaoding and deleting files.
  • I, the administrator now have the privilage to delete any file uploaded by any user. This was foolishly ommited until now.
  • The user interface has been radically changed. You can now navigate through folders effortlessly and file information is presented clearly. There is no more javascript used to control elements on the page and only the required form elements are shown.

The Backend

The code has been greatly improved and most of the major holes have been repaired. These were mainly in the data entry parts where user entered text was unmoderated. Secondly the error feedback and message reporting has been improved so that clearer more relevant messages are generated. Finally if for some reason a file becomes deleted from the docs/ folder but remains in the database, the database entry is automatically removed. This didn't happen in the first version and caused some problems.


Please write any feedback about the new version in the comments section below. Suggestions and criticism are welcomed. Thanks.

(This post was originally available at http://users.ecs.soton.ac.uk/cc1206 and refers to a feature only available at the previous address. DocDrop 2.0 is still availble at http://users.ecs.soton.ac.uk/cc1206/docdrop2.php but only registered users may upload files)

Serial Port Communications With The PIC

A Word about computer interfaces

Although the current interface of choice is the USB Port, it is much harder to program for than its predecessors. The Parallel port is very convenient as it is possible to send byte-wide data with just one clock pulse. It is also simple to program with on the PC side using C# or Visual Basic, and requires no extra processing on the PIC’s part since the raw bytes can be simply shunted from the parallel port straight to the LCD, it would even be possible to do away with the PIC altogether. So far so good, however Parallel port cables and connectors are large, expensive and power-hungry. Also they are becoming rarer on computers especially on laptops. To top all of this, Parallel ports, put plainly, are boring. Serial ports on the other hand are much smaller, efficient and elegant, not to mention more interesting to study.

A word about the Serial Port

A serial port has 9pins, however only three of them actually do anything interesting. These are the Transmit Data (TD), Receive Data (RD) and Ground (GND). The Ground pin must be connected to the ground on the device so that it is common to both. This is a full duplex system whereby each communication direction has a dedicated cable. The other pins are for ‘Digital Handshaking’ which I will mention later. Because there is only one cable for all the transmitted data to be sent down, a protocol is necessary to ensure that both devices know when to expect / send data. This protocol is RS232 and it is a simple, yet widely used one, which is straight forward to program (in a PIC at least).

A Word About The RS232 Protocol

The data to be sent is split into words of 8 or 7 bits (more on this later) and is sent one bit at a time. A digital high is signified by a negative voltage (-15V) and a digital low is signified by a positive voltage (+15V). In practice, these voltages vary and are generally lower, but this is not significant. The data line is normally low (+15V). Just before a byte is sent, the line goes low for one clock period (the Start Bit), the data bits are then sent sequentially with least significant bit sent first. Finally after the last data bit the line goes (digitally) low for two clock periods (the Stop Bits) to signify the end of the word. In this project, only the PC sends data, the PIC only receives data and doesn’t send anything back to the computer.

A Word About Line Levels

Since we have to use a PIC to interpret the stream of bits, we cannot make a direct connection from Transmit Data line to an input pin on the microcontroller, since the PIC uses CMOS positive 5V signals and the serial line uses ±15V. To get around this I used a dedicated chip which converts 15V to 0V and -15V to +5V, and vice versa, allowing both PIC and Serial to work in harmony. I used the MAX202 as it offers two CMOS to RS232 and two R3232 to CMOS channels, thus allowing further expansion of the project. The chip requires 5 capacitors of equal 10uF value to act as charge pumps, this means it only requires a standard 5V supply and does away with the need for a dual rail power supply. Here is a circuit diagram of the setup I used.

The PIC Program

In my previous blog entry I published the assembler code for a PIC16F84 which initialised an LCD screen and provided a subroutine to display ASCII characters on the screen. I have now modified the code to include another subroutine which converts the incoming serial RS232 data into a single byte, stores it in a register and then displays it on the screen. The code is set up for a data rate of 4800 Baud, which means that the PIC requires a crystal of at least 4MHz to work. The program for extracting information from serial port signal is essentially a complicated shift register which listens for the start bit, then shifts the value at the input pin into a register every 200us (approximately) until the all eight bits have been received (i.e. the register is full). I adapted the code from a website I found a while ago at http://www.boondog.com/tutorials/pic16F84/pic16f84.html which has many other interesting project ideas and resources.

The Assembler code is provided here.

(This program will continually listen out for new ASCII characters on the RS232 input and display them on the LCD. The cursor is automatically repositioned at the end of each line)

Testing The Program And HyperTerminal

In order to test the program you will need to send RS232 data down the serial port on your computer. The easiest way to do this is to use a windows program called Hyper Terminal to make a connection to the PIC. If you have never used Terminal before, you need to select a new connection, and tell it about the device you’re trying to connect to. The necessary settings are shown in this screenshot of HyperTerminal running on my computer (Windows XP). It is then a matter of simply typing on the keyboard to send ASCII coded characters to the device, which should then relay them to the display.


FAQs:

When I type I get random characters displaying on the LCD:

This is because there is too much noise in the signal and ASCII characters are confused. I found the easiest way to improve the accuracy is to increase the power supply to the MAX202 chip to greater than 6V.


Only the first character I type is displayed correctly the others are wrong or missing:

It may be that you are typing too quickly and the PIC has not finished displaying the last character yet. In the Properties option under ASCII Setup increase the line delay until the error is no longer present.

The ‘Enter key’ does not move the cursor to the next line:

It’s not supposed to. The enter key’s ASCII code is not recognised by the LCD as an instruction to move the cursor. Instead the PIC must listen out for the new line character and generate the required code to change lines. This feature will be included and uploaded in future posts.


Problems with contrast on the LCD:

I experienced shadows behind each of the characters on the LCD at one stage which I later found out to be the result of too high a power supply to the LCD module. To correct this I added a standard junction diode in series between the 5V supply and the +Ve pin of the LCD module. This reduced the supply by ~1V and the contrast was much stronger as a result.

Controlling LCD With PIC Microcontroller

Getting The PIC to talk to the LCD


As mentioned in my last post, I have succeeded in getting the PIC to talk successfully with the LCD and write sensible characters on to the screen. And as promised here is how to do it, and more importantly how not to do it.



My first attempt


When I first bought the LCD I spent quite a while reading message boards, hobbyist sites and ‘tutorials’ in hope of learning how to interface it. This helped up to a point but I was unable to find a single site that showed how to put everything together, so I went back to the data sheet. Fortunately the data sheet for the display I bought was very comprehensive, if a little daunting. This is why I will now proceed to put together a series of pages explaining in steps how to go about connecting a PC via the serial port to an LCD screen, via a programmable chip.



About LCDs


There are two broad categories of LCD, the first are those without a controller. These are little more than a plate of the LCD material with a mass of connections around the outside. These give pixel perfect control over the displayed image/characters and allow the user to alter individual pixels independently. These as you can imagine, from the number of pixels present, require complex control logic to achieve such custom displays and are therefore much harder to work with. The second group of LCDs are those with a built in controller or MPU. These have an inbuilt processor which handles the difficult process of constructing characters from individual pixels, and allows you to simply present the ASCII code for the desired characters at the pins. This second type of LCD is by far the best choice.

Having chosen an LCD with a controller, you need to ensure that the controller is of the type HD44780 (Hitachi), as this is the most common and straightforward to use.


Connecting the LCD to other stuff


On the front of most LCDs is a strip of solder pads contacts, onto which wire connections must be soldered. It is important to be careful when placing the soldering iron near to the thin polymer coating on the surface of the screen, as it is very easily scratched and warped. Although there are many makes of LCD the interface, providing it is HD44780 will be similar. The pins available are:

  • Vss is the ground terminal for the module


  • Vdd is the positive supply for terminal (2.7V to 5.5V)


  • Vo is the power supply for the liquid crystal drive but should be grounded


  • RS is Register select; it should be logic 0 for sending instructions, but 1 for sending data


  • R/W is Read / Write; it should be logic 1 for reading data, and 0 for writing data


  • E is the Enable pin; when this pin goes from logic 1 to 0 the data is read from the data pins DB0..DB7 these are the 8 pins for data transfer; ACSI codes are presented one byte at a time



4-Bit or 8-Bit


Because of the ‘byte-wide’ data bus on the LCD module, a whole ASCI code can be sent to the device with just one clock cycle of the enable pin. However in the real world we use microcontrollers to control such devices, and these have a finite and often small number of IO pins to play with. Using the 8 Bit interface to control the screen would require 8 pins for the data line alone, and a further 3 pins for the control lines (enable, RS, RW). Taking the ubiquitous PIC16F84, we have 8 IO pins on PORTB and a further 5 on PORTA. This leaves just two spare pins on the microcontroller. It is likely that we will need the display to be dynamic and depend on other stimuli, perhaps a keypad, for which we will need more spare inputs. The solution is to use only half the available data lines in what is known as a 4-Bit interface. DB3..DB0 are grounded and only DB7..DB4 are used to send data. Instead of sending a whole byte at once, we send the upper nibble first and then the lower nibble, this obviously requires twice as many clock cycles to achieve but means only 7 pins are required to control the screen. I will use the 4-Bit interface in this project.



Don’t do this!


I read somewhere that it was possible to test a LCD by hard wiring it on prototype board and then using a push switch on the ENABLE input to latch the data/instruction. I tried to do this using a bank of switches but had no success. Looking back on it, its hardly surprising since the electrical bounce must have been tremendous. However it’s always worth proving the principle before introducing something as complex as a microcontroller into the equation.


Microcontroller – LCD communication


Before you can begin writing characters to an LCD, you must initialise it correctly. On power-up the device ‘self-initialises’ and takes all the default settings, therefore it is necessary to manually initialise it the way you want it. The default configuration is 8-Bit mode and must be changed before sending any other instructions as the device must be told to ignore the pins DB4..DB3. Once this is done there are many options which can be selected, such as whether the on screen cursor should be visible or blink, how the cursor should increment or decrement after each character and also the screen must be cleared and the cursor returned to the home position. There are special binary codes for each of there instructions which are given in the data sheet for the device. The circuit I used for this project was:




The capacitors shown were standard ceramic ones with the same value. The exact value is not important.





To achieve the 5V supply, use a household transformer such as a phone charger with variable voltage output. These are ideal for bench work as they supply sufficient current and a constant voltage. I began by using batteries which required an additional voltage regulator to achieve the 5V however the performance of the regulator was far from satisfactory for this project. Unfortunately the only transformer I could find around the house was a very old one which offered 4.5V or 6V. Being too lazy to go out and buy a 5V one I made do with the 4.5V which for the first part of the project worked just fine.





The assembler code for the PIC didn’t take too long to write and can be split up into just a few sections. Firstly it runs through an ‘INIT’ subroutine which writes to the display, the instructions to: 1) use the 4-bit interface 2) display the cursor and make it blink 3) clear the display 4) increment cursor position automatically 5) return the cursor to the home position. The next stage in the program is to load into the work register the ASCII value of the desired character, then the ‘WRITE’ subroutine is called. This splits the 8 bit binary value into its upper and lower nibbles so that it can be sent to the LCD using the 4-bit interface. Finally a ‘WAIT’ subroutine is called which prevents the microcontroller from attempting to write more data, until the display has had time to read/load the character into its memory.


Get the Assembler Source Code

Memory organisation


It is convenient to think of the LCD as a RAM chip which has a screen showing you the value of each data cell (or its ASCII equivalent). When writing to it you must specify the address (the position of the character on the display) as well as the actual data (the character to display). If, as suggested, you enable the auto-increment option, the RAM address (cursor position) is increased by one after each write instruction. This saves the need for repositioning the cursor with every write instruction. However, there are more data addresses than character spaces on the screen. The address of the top left character is h’00’, and that of the top right character is h’0F’ (for a 16x2 display). Unfortunately the bottom left character (the next logical position for text) is at address h’40’ and the bottom right is h’4F’. This means in the PIC program, it is necessary to realign the cursor to the next line when you reach the end of the first, else the next characters won’t be displayed.



Other Points:

The current consumption of the LCD and PIC was 1.7mA when the display was static and rose to 1.9mA when the display was changing. When using the MOVF operation in assembler it is necessary to specify after the operand that the result is to be stored in the W register, by writing a ‘,0’ after it. Since the function of MOVF is to copy a file to the work register I assumed this extra operand was unnecessary and therefore wasted a lot of time changing/breaking other stuff before realising my mistake.

If your supply the display with a voltage above 5V the display will go completely black, i.e. all the pixels are turned on. Don’t do this, its not good for the device, I did it by mistake.
The display needs at least 40uS in between each instruction in order for it to register properly. After an instruction to clear the whole screen, it requires 1.53ms. I created two subroutines called WAIT (~30ms) and PAUSE (~0.5s).

Success With LCD

I have finally figured out how to control an LCD screen. Today I have managed to get a PIC16F84 talking to a standard LCD screen previously described on this site. I will shortly (tomorrow) upload the schematics and assembly code to enable others to incorporate LCDs into their projects. The next stage is the PC->PIC interface for which I already have an assembly script prepared. Now just to build and test it....

PIC Project Components

The easiest way to develop PIC projects is with a purpose built development board like the one pictured to the right. This particular board was a kit purchased from Maplin Electronics for under £30. Its main features are its ability to program multiple size PIC chips through the serial port of a computer, simulation of outputs using LEDs connected to PORTB, simulation of inputs using de-bounced momentarily on switches.

I chose to use a cheap LCD display for this project for two reasons, firstly because I don't really know what I'm doing and don't want to break an expensive one, and secondly I'm hoping cheap = simplicity to interface. The model I chose to use was a N25AZ Alphanumeric Module.

Unfortunately most LCDs do not come with PCB friendly connectors which means that it is necessary to hand solder some form of connector onto the front. This is simple but care must be taken not to melt any of the near by plastic when soldering as the pads are very close to the bezel.

The underside of the module is impressive to look at but the main reason for showing it is to illustrate the soldering of the connectors to the panel.
(This post was originally available at http://users.ecs.soton.ac.uk/cc1206 and was posted in March 2007)

Wednesday, 26 December 2007

Post Exam Projects

Once the second semester exams are over in approximately three weeks, and after the deserved celebrations I intend to actually finish/start some of the projects I have previously attempted. Starting with the PIC Controlled LCD Serial Interface project. Over the coming weeks I will post updates with pictures, code, schematics and a large list of my mistakes and learnings to document my work. The general aim of the project is outlined below.


PIC Controlled LCD Serial Interface Project

The aim is simple but ambitious. To control a two line LCD screen with a windows PC via a serial RS232 port. The project is broken up into the following tasks:


  • To control an LCD screen using a PIC microcontroller programmed in assembler

  • To pass bytes of data along the serial port to the PIC and store them in the internal registers

  • To write a C# or C program to pass characters (in ASCI coded binary) to the PIC which then relays them to the LCD

  • To learn more about digital communication, assembler, interfacing hardware and debugging.



The end goal is ultimately to add an additional screen to my computer which can scroll through my email messages, 'now playing' list in WMP, BBC news headlines, and flash up messages, alerts and anything i program it to do. Ambitious but potentially amazing.

WZ Grapher

For those who can't get their hands on MATLAB, I've found WZGrapher which. For anyone who just wants to be able to plot [any] function quickly and accurately without having to fill a spreadsheat in Excel I suggest WZGrapher. I found it essential to be able to view the functions for a Communications assignment in order to verify my answers and convince myself I knew what I was doing. There is even a [minimal] version of WZGrapher online which is free to use and can handle up to five functions as well as compute Fourier Series.

The program is exceptionally light, requires no installation and is as intuitive as you'd expect for a maths program. The website also promises a Linux version to come in the [near] future.

The latest version of WZGrapher can be downloaded from http://www.walterzorn.com/grapher/grapher_app.htm#download or you can use the online javascript version at http://www.walterzorn.com/grapher/grapher_e.htm.

(This post was originally hosted at http://users.ecs.soton.ac.uk/cc1206 in November 2006)

Linked List Success

After a good couple of hours spent trying to understand linked lists and pointers in 'C i've finally managed to bash out a small program which demonstrates initialising such a list, pushing and popping elements to and from the list and also the principle behind 'malloc()' and 'free()'. Hopefully this will be as usefull to others on the ELEC1010 course as it was for me in trying to get to grips with structures and pointers.

The file is currently sitting in the DocDrop pages and can be downloaded and compiled on any ANSI C compiler. It chucks up a warning about implicitly defining 'malloc' but it doesn't seem to affect the program. Code is free to distribute and use, but a link back would be appreciated.

(This post was originally hosted at http://users.ecs.soton.ac.uk/cc1206 in November 2006)

The Gimp 2.0 Image Manipulation

After what seems like a lifetime battle against Paint Shop Pro to create decent web graphics I have discovered The GIMP. The GIMP is an open source free image manipulation package which is as powerful if not more so than most paid for graphics software. After just one hours reading of a tutorial on the GIMP web site, I was able to create the new banner for this site. Although most of the concepts of layers and masks and filters were foreign to me at first, due to the intuitive nature of the program and its excellent documentation I was soon able to do things that would previously have been inconceivable within the confines of Paint Shop Pro's daunting interface.

On first installing the program its clear that it is extremely powerful, not least because it takes an age to load. Secondly you are confronted with a conservatory of windows each awash with tempting colourful buttons and the friendly fox logo. Once you delve into the guts of the software and begin working through some tutorials (which is highly recommended) you soon realise that you have pretty much unlimited control over every aspect of the image including transparency, text, 3D effects and many more obscure properties you probably won't have encountered before.

The latest version of The GIMP can be found at http://www.gimp.org/ and is available for use on Windows, Mac and Linux.

(This post was originally hosted at http://users.ecs.soton.ac.uk/cc1206 in November 2006)

The New Home For 'Chris Cross'

My website is moving! This will be the new home of 'Chris Cross': my personal, educational and social commentary site. All material previously hosted at http://users.ecs.soton.ac.uk/cc1206 will continue to be availible both at the old site and eventually here.