Phillip’s ECE477 Web
Journal
May 3, 2004: I met with Jegede and
Bill to work on the final report. I touched up my homeworks and added them
into the final paper. I wrote the Version 2 Changes and individual contributions
sections. I also fixed up all of the software code, and added the proper
comments.
(Duration: 6 hours)
April 29, 2004: We fixed up the final
lecture slides. I worked on getting the picture box ready for a live demonstration.
I made a crossover cable so that we could connect the box directly to Jeff's
laptop. He decided later that he didn't want to do that, so I brought in
my router. I installed the client on Bills laptop, and had the whole thing
ready for a live demonstration. However, during the presentation we didn't
have time to show it off anyhow.
(Duration: 3 hours)
April 28, 2004: I figured that we should
try and perform a live demonstration of our project for the bonus presentation.
I tried to optimize the picture transfer by eliminating some useless information
that was sent over the network in our previous verison. I had problems
getting the Epson to work, so I called Bill. We figured out that once again
the clock was acting up. I fixed the PC client and Rabbit software to successfully
send a picture in 5 minutes 30 seconds instead of about 11 minutes before.
I tried to also send the pixel data in large chunks of data to further
optimize transimission, but apparently the TCP/IP Unix stack already does
this because no further performance was gained.
(Duration: 4 hours 15 minutes)
April 27, 2004: I recorded the final
version of our outcome video. We went to Jeff's place to digitize the video,
and we practiced our speech once there. I went home and practiced my individual
part alone. I had to cut out several slides due to time constraints.
(Duration: 2 hours)
April 26, 2004: I met with the group
and figured out what was to be done for the final presentation. I created
all of my slides for the presentation at home.
(Duration: 4 hours 30 minutes)
April 25, 2004: I measured out the plexiglass
pieces to our casing, and cut them using a hack saw. I glued the individual
pieces together with our board using a combination of epoxy and hot glue.
We had to correct some of the pieces cut so that they fit properly. We
made sure the board worked after we had all the sides securely connected
together. The voltage regulator seemed to overheat alot when we tested
it with the AC adapter/so we decided to put a little heat sink compound
and a heat sink on top of it. Finally, Bill, Jegede and I put glue all
along the bottom side quickly before it dried, and held it until the glue
dried.
(Duration: 4 hours 45 minutes)
April 24, 2004:
I helped Jeff debug the
circuit. We figured out that the clock pin lost connection, so we just soldered
that on and it worked. We verified that Jeff's color program worked. I
used the final test software I put together, and we saw a picture on the screen!
At first there were 4 copies of the picture/the colors were all messed up.
I talked with Jeff about the addressing, and I realized that the Epson is
byte addressable. I was clocking in a 2 byte word every address with my
software. The 16 bit color values were also backwards. I had it sending
a 16 bit color starting with the most significant values: 0 unused bit, 5-bit
Red, 5-bit Blue, and 5-bit Green. Jeff notified me that the Epson takes
16 bit color instead like: 0 unused bit, 5-bit Blue, 5-bit Green, and then
5-bit Red. I changed around my bit masking scheme to accomodate this, and
then incremented the address one extra time per pixel(Jeff's function that
clocks in data to the Epson takes Address, 16-bit color). After I loaded
this code up the picture started loading absolutely perfect. However, there
were some minor problems with the display. First, it was terribly slow.
It took about 10 minutes to load up one picture. A tiny chunk of the picture
at the top started to display at the very bottom of the screen. Once the
display reached this tiny chunk of picture at the bottom, it skipped back
to the top and placed the bottom portion of the picture that was supposed
to be in that tiny chunk to the top of the screen. This is due to the fact
that we are using a 4 meg EDO DRAM chip, when the Epson only is supposed
to support a 2 meg chip.
We recorded everything on video, and I went with Jeff to his place
to digitize the video.
(Duration: 4 hours 30 minutes)
April 23, 2004: I received the new Rabbit
core module 3010, and tried to get my web server code burnt in at home because
it only works with the most updated software. I had issues with memory,
because our old 3000 has 512kb of static RAM while the 3010 only has 128kb.
The web server now could only hold 75kb of picture data after all the overhead.
I setup the camera so that it was ready to videotape the new outcome. At
lab, I setup the Rabbit on the evaluation board, and I had to tie the floating
infrared inputs to ground because they would constantly send pictures randomly.
Bill filmed Jegede and I demostrating our code/how we can send it data
using the PC client, and then view the change remotely via an HTTP server.
I updated the web page from the generic Rabbit sample version to one that
more suits our group. We hooked up the new rabbit module on the board,
and tried to display something to the screen. However, the Epson was not
properly receiving the startup register information.
(Duration: 4 hours)
April 21, 2004: I wrote the .ppm decoder
and set it up so that it scaled each 8 bit RGB color values down to 5 bits.
It then combined these 3 values into a single 16 bit unsigned integer.
I had an unsigned integer keep track of the address starting from 0. I
had it enter a while loop and print up each individual pixel value, and
checked by hand to make sure all of the values were correct for a few pixels.
I copied over Jeff's code to clock in RGB values into the Epson, and I setup
the Rabbit/PC to send/recieve pixel packets that consist of a 10 byte header("sendpixel"),
a 4 byte address integer, and 16 bits for the color data. I sent a .ppm
file to the Rabbit and verified that the debug statements on Rabbit/PC agreed.
I then setup Jeff's code to send the pixel/address data to the Epson whenever
a pixel packet came to the Rabbit. Bill, Jegede and I were just about to
hook up the Rabbit to our board, when a pin broke on the Rabbit. We soldered
it on and verified that we could program the Rabbit on the evaluation board.
However, when we installed it onto our board it didnt work. When we tried
to reconnect it to the evaluation board it still did not work. Looks like
we fried yet another Rabbit...
(Duration: 4 hours 30 minutes)
April 20, 2004: Jegede and I tried to
debug the new web server code that included all of the FTP server code.
The Rabbit was acting up, and constantly had to be replugged after every
compile. The Rabbit kept freezing up on us, so we inserted debug statements
everywhere until we isolated the problem. It seemed that every time that
we wrote anything to the file on the HTTP server, it would corrupt another
piece of data. We finally figured out that when the fwrite function was
called, it would always cause the yield function to return in unpredictable
ways. We came to the solution that we could try to either: update the Dynamic
C libraries hoping the bug was fixed in a later version, or rewrite all of
the code in a simple brute force while loop. I started writing my part to
the User's Manual homework.
I brought the Rabbit home with me so that I could update the Dynamic
C libraries, since I don't have permission to do so on the design lab computers.
I had to setup my router to support the rabbit, but eventually I had it
working. After updating Dynamic C from 8.10 to 8.51, our code compiled
and ran exactly how we expected it should have in the first place. I altered
the sample code to share a .jpg picture file, and tested sending various
.jpg files to the Rabbit. After sending the files, I simply hit refresh
on the browser and the new picture appeared! Woo hoo!
I then finished writing my part of the User's Manual.
(Duration: 7 hours 45 mintues)
April 19, 2004: Jegede
and I rewrote the code for the web server to try and eliminate the strange
bugs that we had. I used the original sample file that has an FTP/HTTP
server where it is possible to overwrite a text file via FTP, and see the
changes via HTTP. This time we took the file exactly how it is, and added
our code around it. I tried to eliminate the FTP code last time, but I
think I might have deleted code that was necessary. We got to the point
where we were able to get a simple string updated on the sample text file.
We also were able to see chunks of a text file on the PC to display via
the web server. Finally, we tried to use a simple protocol to get the entire
picture from the PC to the rabbit. The PC will send the rabbit the string
"sendnewpic", followed by a 4 byte length, followed by the binary data.
We successfully got the Rabbit to display the length of the file, but could
not get any data yet.
(Duration:
7 hours)
April 18, 2004: Jegede
and I tried to debug the code to setup a web server with a dynamically changing
picture file, but after a few hours we could not get it to work. The rabbit
would just reset with very frustrating and odd errors. I think it's probably
due to the fact that I used a sample file and cut and pasted what I thought
would work. We are gonna try using the exact setup in the sample file next
time, and then setup our code around it leaving the FTP server code alone.
We setup the PC client software to work with .jpg files instead of
.txt files. It seemed to work fine unless the picture file was over 10kb.
We fixed the size constraint, but still had a few flaws. Enough for today...
(Duration: 5 hours)
April 17, 2004: I debugged my alternate file server so that I successfully could send a file from the PC into the rabbit, and then later download the file from a different computer. I setup so a NULL terminated name is sent to the Rabbit followed by a length 4 byte integer, followed by binary data. I had the file names saved as the actual filename with a .rab appended to it. I then compared the file to it's downloaded .rab file, and verified that they were idential using the unix diff command.
I started an http project also that is very similar to the
above program, except that instead of downloading with a command line program,
the file could be seen on a web server on the rabbit. I used a sample file
that had an http server that could upload files using ftp, and tried to
modify it so that instead of ftp, the PC rabbit client could send the picture
files.
(Duration: 6 hour 15 minutes)
April 16, 2004: Jeff and
Bill are having troubles and doubt that the Epson is going to work, so I
worked on alternative software in case it doesn't work. I started a menu
system for the PC, that you can navigate through using the push buttons/remote.
I setup the PC software so that when you hit the function key, it displays
"entering the rabbit menu." You can only exit by hitting power, and cycle
through options using the "Next Picture"/"Previous Picture" control buttons.
I did not actually create a menu yet with any options, I just set it up
kind of a state machine.
Another suggestion that we talked about in case the Epson doesnt work
is to have the Rabbit store an image so that it can be retrieved later,
sort of like a small file server. I setup a new project directly with some
modifications to my code so that the Rabbit will act as a file server.
I changed the "Next Picture"/"Previous Picture" commands to just change
the current picture pointer. When the "Function" key is pressed, the PC
will send the current file to the Rabbit where it is stored in a buffer.
The PC then can disconnect, and later reconnect and download the file that
was sent when the "Power" button is pressed. I had troubles recieving the
file back correctly. I also could not get a temporary buffer size of more
than 32kb due to some kind of addressing limitation on the Rabbit, even though
the module is supposed to have 512kb of Flash and 512kb of Static RAM.
(Duration: 3 hour 30 minutes)
April 14, 2004: I setup
the PC client so that whenever it recieves a Next Picture command, it updates
the file pointer index to the next picture. I also implemented the Previous
Picture command. Once the PC recieves these commands, it then sends the
contents of the corresponding file to the Rabbit. I verified that the rabbit
properly prints up the contents of the file, and cycles through the picture
files(text for now). I setup the PC client so it has 2 processes: 1 to
monitor incoming Rabbit data, and 1 to send the Rabbit data. They communicate
using a Unix pipe. I also soldered on the rest of the push
buttons, had to change the input pins for the push buttons because they were
changed in the final layout, and I tested the button to make sure it worked.
(Duration: 4 hour 30 minutes)
April 13, 2004: I showed
Bill how to burn the Rabbit program to the Rabbit. I added code for the
PC client to fail if it cannot connect. I soldered the pushbutton on, and
helped Bill solder on the 15k ohm resistors and debug the circuit. We tested
out the IR buttons while the Rabbit was on the board, and tried to get the
pushbuttons to work, but somehow the 5V power supply for the switch inputs
was changed to the 3.3V supply. It didnt work, so I guess we'll have to figure
out different resistance values.
(Duration: 1 hour 30 minutes)
April 9, 2004: I met
with Jegede and discussed how to implement the .ppm decoding/breaking up
the pixels and how to send the pixel packets to the rabbit. I explained
my code so far block by block, and discussed where to put the consumer code
for the rabbit, as well as where to put the PC code to send the pixel data.
(Duration: 1 hour)
- Week 13 (10 hours 30 minutes) -
April 3, 2004: I finished
and debugged the Rabbit code for switch debouncing for pins PA2-5. I setup
each pin to send the appropriate command via the network to the PC. I added
a circular buffer on the rabbit so that the module incoming_tcp places the
incoming tcp data into the circular buffer. I created the module decodePCdata
which consumes the data placed in the circular buffer a character at a time
by printing the output to the screen(for now). Both modules yield control
if the buffer is full/empty. I updated the PC module so that it just opens
the first .ppm file, and sends all of that data to the Rabbit. I successfully
debugged all code written today with the rabbit/pc interfaced over ethernet.
(Duration: 3 hours 15 minutes)
March 31, 2004: I worked
on the Rabbit code for switch debouncing for pins PA2-5. I setup the IR
decoder to the Rabbit pins PE0, PE1, PE3, and PE4. Bill and I successfully
had the rabbit display output to the screen via the debug port when an IR
button is pressed. I also set the Rabbit to decode the depressed IR button,
and send the corresponding command via ethernet to the connected PC. I programmed
a generic dummy terminal on the PC so I could type in any data that I wanted
sent to the rabbit, and it would display anything received.
(Duration: 5 hours)
March 30, 2004: I debugged
the rabbit code that monitors the TCP/IP port. I read up on the Dynamic
C TCP/IP commands: sock_established, sock_tick, tcp_listen, sock_tbleft, sock_fastread,
sock_fastwrite, and sock_bytesready. I drew out a diagram of all the necessary
software modules for the rabbit software, as well as the PC software. I
drew out a simple TCP/IP protocol necessary to send packets, including a
packet length and command header length. I figured out the commands the
PC/Rabbit will use and the various states they will use.
(Duration: 2 hours 15 minutes)
March 28, 2004: We found
that the Epson controller requires the picture data to 8 bpp or 16 bpp,
but the .ppm format only supports 24 bpp. We now have to change our client
decoder to the .bmp format now. We downloaded seeral specification sheets
on .bmp, and tried to figure out how it works. Jeff told us that our headers
were layed out wrong, so we are probably going to have to get an all new
board. It was such a nice day out we should have just stayed outside.
(Duration: 4 hours)
March 27, 2004: I worked
on the PC TCP/IP client program. I finished the code that stores the list
of .ppm files in the current directory, and setup the client to connect,
wait for packets that have a 2 byte length field, and variable size data segments.
Once the length is received, the client scans in the rest of the data into
a temporary character buffer.
(Duration: 2 hours)
March 22, 2004: I updated
my lab notebook from my apartment.
(Duration: 30 minutes)
Spring Break!
Woo hoo. I was unable to aquire the motivation to do anything school related.
(Duration: 0 hours)
March 11, 2004: Once
again I met in the design lab with Jeff to help with the layout homework.
We apparently had the wrong footprints for the beads and clock crystal.
I found spec sheets for the crystal, and printed it up. I checked to make
sure all of the components fit onto the layout printout.
(Duration: 2 hours)
March 10, 2004: I met
in the design lab with Jeff, and I tried to help him out with the layout
homework. I routed part of the Epson controller, the PLD's, and a header.
Jegede took over after I left.
(Duration: 5 hours 30 min)
March 6, 2004: I updated
the TCP client program on the PC so that it has the ability to connect, and
send any data typed in on the keyboard to the Rabbit TCP server. I also
updated the Rabbit server code so that it is able to take all data received
in the buffer and display it on the debugging window to make sure that we
are able to properly transfer data between the PC and Rabbit. I discussed
with Jegede what exactly we are going to need to implement in our custom TCP/IP
protocol. We drew out the basic functionality of the client and server. Jegede
worked on decoding image data of the .ppm format.
(Duration: 3 hours)
March 2, 2004: I practiced
my speech several times, and helped print up all the necessary documents
for the presentation.
(Duration: 2 hours)
March 1, 2004: We discussed
the presentation for tomorrow. I finished up writing up my speech on notecards.
I checked over and printed up a copy of my powerpoint slides. We practiced
the speech for the first time, and completed it in about 29 minutes. I
went over the schematic with Jeff to figure out all the details and make
sure it is right. We decided to practice our individual parts at home, and
then try to practice again tomorrow.
(Duration: 4 hours)
February 29, 2004: I
finished up the PowerPoint presentation, and discussed several schematic
issues with Bill via instant messenger. We want to
connect both chips to the same clock, so that I/O transfers are synchronous;
however, we are having troubles with finding a CLK input for the Rabbit or
a Rabbit clock output. I found the clock input from
the Rabbit 3000 manual, but the Rabbit core 3010 has an integrated clock with
no flexibility. I looked for a way to configure a
clock output for one of the Rabbit I/O pins.
Everyone
met in labs in the evening to work on the presentation.
I tried to figure a way to output the Rabbit system clock, or something
close to it, to one of the pins on the core module. Jeff
helped me a bit, but we could not get any output on the oscilloscope.
(Duration: 6 hours 30 min)
February 28, 2004: Jegede, Bill, and I discussed
everything needed to be done for the presentation. We
agreed to make separate PowerPoint presentations over the homework that
each individual completed. I studied the Dynamic
TCP/IP manual, and successfully implemented cooperative multitasking in
a simple TCP/IP server. The server takes all the
information received by the Ethernet port, and drops it into a temporary
buffer. The consumer thread that is to forward the
packet data still needs to be written. I designated
port 40 as a listen server for the Picture Frame Protocol (PFP 1.0). I also wrote a command line C program for Linux that
can connect to the Rabbit controller. I tested out
both programs, and I have successfully established a TCP/IP connection between
the two.
When I returned home, I started working on the PowerPoint presentation. I nearly finished the presentation, which included a couple of pictures of the compared chips from the Internet.
(Duration: 7 hours 15 minutes)
February 25, 2004: I installed Dynamic C
on my home PC, hooked up the evaluation board, and tried to setup a couple
sample programs as I did in lab. I looked over the
lattice GAL manual to make sure that it is compatible with our design. Finally, I read part of the Dynamic C manual, the Dynamic
C TCP/IP manual, and the Rabbit 3000 user’s manual. I
also helped out Bill with the schematic homework a little bit. I looked over a draft of his paper, talked about the Rabbit’s
functionality in our project, and read over the Epson/PLD data sheets.
(Duration: 4 hours 45 minutes)
(Duration: 4 hours)
(Duration: 5 hours 30 minutes)
(Duration: 45 minutes)
(Duration: 30 minutes)
(Duration: 2 hours)
(Duration: 30 minutes)
(Duration: 2 hours 15 minutes)
(Duration: 3 hours)
(Duration: 1 hour)
(Duration: 2 hours)
(Duration: 1 hour 30 minutes)
(Duration: 2 hours)
(Duration: 8 hours)
(Duration: 45 minutes)
(Duration: 1 hour)
(Duration: 10 minutes)
(Duration: 10 minutes)