Log
This is our near daily log
Week 1
Day 1: We got a first look at our device, Dr.Baker also provided us with all its documentation and gave us a few instructions. He also provided us two windows programs to test the device.
Day 1: We got a first look at our device, Dr.Baker also provided us with all its documentation and gave us a few instructions. He also provided us two windows programs to test the device.
Our course lab did not have any windows machines to we needed to go to another lab to test the device. Unfortunately those machines did not have molex power cables which were needed for our device, all the windows machines had SATA drives. There were machines that had molex power cables but they ran linux, so we ended up using power from the linux machines and testing on a windows machine.
First we tried to run the 2 test programs but both failed as we did not have admin access on the windows box. Thus we decided to install windows on a box in our lab. We did power up the device and it smoked. Worried and optimistic we assumed it was leftover soldering that smoked.
Day 2:
We Started by installing windows on a box. We also download a few more test programs. Unfortunately none of them did anything to the device. Only the CFAH software came close to varying the back light of the device but not after googling around downloading another program and making a registry entry. We rechecked all the wiring and nothing seemed to be wrong. Thus we gave up and went back to Dr.Baker. After a lot of discussion Dr.Baker told us since it smoked we would have given the device more power than it needed. On rechecking we did find that our device got 12 volts instead of 5.
We Started by installing windows on a box. We also download a few more test programs. Unfortunately none of them did anything to the device. Only the CFAH software came close to varying the back light of the device but not after googling around downloading another program and making a registry entry. We rechecked all the wiring and nothing seemed to be wrong. Thus we gave up and went back to Dr.Baker. After a lot of discussion Dr.Baker told us since it smoked we would have given the device more power than it needed. On rechecking we did find that our device got 12 volts instead of 5.
Dr Baker decided to provided us with the other device he had but we would have to wait for a day (a man of his knowledge and caliber is a very busy man)
Day 3:
Created this project on Google Code.
Created this project on Google Code.
Week 2
We spent the first day reading through the all the documentation on the device and came back the second day to attack the device , but were not able to display a single character on to the device. We read the documentation again , went through a lot of user level programs to code other devices and still could not figure out why we were not able to display the a character on the device. So we went back to the windows machine ( irony? ) and tried the test program which worked before , and the result , nothing , the device refused to display anything . Worried some of us tried to figure out the problem while the rest started to ponder on Plan B for our course project. But by nudging around a little we found out we had a anti social pot-resistor which needed to be pushed to one side for the display to work.
After reading through the device manuals until our eyes were bleeding, we finally had a measure of success. We realized that the enable line of the parallel port is inverted. With this device, it is capable of being written to after the enable bit goes low. Since this bit was inverted we were testing it after it was going high. In order to resolve the problem we used an exclusive or to mask data going to the control port (with the exception of pin 16).
Our driver is now able to display characters. We are now working on some addressing issues. DDRAM of the device is sequentially incremented, but unfortunately that increments from line 1 to line 3 than from line 2 to line 4.
The next hurdle is to be able to write special defined characters to the device.
Our driver is now able to display characters. We are now working on some addressing issues. DDRAM of the device is sequentially incremented, but unfortunately that increments from line 1 to line 3 than from line 2 to line 4.
The next hurdle is to be able to write special defined characters to the device.
We are also thinking through what would be needed in order to implement the motion sensor with the device. This is trickier than initially expected, because the interrupt needs to be set until it is acknowledged. We will likely have to build a custom flip-flop circuit to accommodate the motion sensor.
Week 3
We made steady progress but at a slow rate as we still had a hardware issue. The anti social pot completely went bad and we had to connect a new pot. The display now looks better and the pot actually works. We managed to provide a few features which include writing , clear , jumping to the start of the line by specifying the line number , moving the cursor left or right based on the given number. All the features have been written in such a way that the user can program the device using the echo command itself or can write a script for the same. As we move further into the project we are going to start developing the required documentation for an application programmer. On Saturday the device decided to give us a break early and the potentiometer completely gave up on us. We replaced it on Sunday and the device was working better than ever.
We finally have nearly all the functionality we had planned to provide and are currently working on memory mapping the device (Target date of completion Sunday). Last few days have been spent providing the scrolling functionality and removing other minor bugs we came across as we were testing all the functions.
Week 4
Fix major bugs we came across related to printing to device whenever there were exactly 80 characters. Also, scrolling was finally finished and bug free. Started on memory mapping and it didn't go so well. System will crash every time, sometimes at reboot and sometimes at module removal.
Week 5
BREAK
Week 6
Continued on memory mapping and again it crashed on us a couple of times but after countless reboots and visits NUMEROUS visits to Dr. Baker, we figure out what was wrong with the implementation. Cleaned up all the messy left over comments and printks. Also, we wrote the read function after realizing we have forgotten. A sample program to read from devices (toread.c) and the memory mapping test (testmm.c). Added locking mechanism.
