January 10, 2006 (1 hour):
We were able to quickly form our team today. We spoke briefly
about different project ideas.
January 13, 2006 (1.5 hours):
Our team had a brain-storming session to complete our initial
project proposal. We came up with a hand-held text reader, a gyroscopic 3d input device, a synthesizer using guitar input,
and a hand-held gaming device. For the text reader, I mentioned the possibility of using a bi-stable display, like Sony's
eReader. I have experience working with NTERA's NCD display technology, so we just need to make sure the idea is
economically feasable.
WEEK 01 SUMMARY
Accomplishments: Built team, came up with initial ideas.
Weekly Work Total: 2 hours
Project Work Total: 2 hours
January 18, 2006 (2 hours):
I contacted my supervisor, Rob, from Honeywell to look into the
bistable displays that NTERA has to offer. Unfortunately, they only have production models of their segmented displays, so
they don't have a graphical option to offer us. Rob suggested I look into Eink, the brand that Sony is using for their
eReader. I did some research into Eink and other bistable displays. It looks like Eink is the only route at this time, and
dev kits cost ~$3000.
January 19, 2006 (0.5 hours):
After getting class feedback, we had another round of
brainstorming. I proposed a modular design for the reader, where the USB interface and UI are seperated from the display
functionality. This will require an additional micro, but will allow our design to be upward compatable with a future
bistable display. Technically, it would be possible to interface with any display, given that a micro was designed to work
with our protocol. To verify the economic and technical feasability of the iReader, we need to do some research on LCD
screen + controller costs and make sure we have a micro capable of running a USB host.
January 22, 2006 (2 hours):
We held another meeting to discuss what we came up with in
researching parts. Digikey seems to be a good resource for LCDs with simple controllers, although we're probably going to
be limited to a 4" display. A smaller display will be good for power consumption reasons, but the resolution is a little
too low to display a full page of text. We discussed the possibility of a scroll wheel, and will probably go that route,
although scrolling text will slightly complicate the communications between what we have dubbed the
"Display Unit" (DU) and the "External Interface Unit" (EIU). In the process of completing the project proposal homework,
we split up homework responsibilities as well as project focuses. I will be doing the packaging and social impact
homeworks and will focus my efforts on UI design for the EIU. This will be the mediator between the USB thumb-drive and
the DU. An important part of this is going to be designing a communication protocol so that the EIU can relate to the DU
what information should be displayed in a way that is not specific to any display technology.
WEEK 02 SUMMARY
Accomplishments: We decided on the iReader and nailed down project responsibilities.
Weekly Work Total: 4.5 hours
Project Work Total: 6.5 hours
January 23, 2006 (2.5 hours):
I've been brainstorming ideas centered around the
communication protocol between the EIU and the DU. I believe the most tractable approach will be to identify three major
types of communication.
1. A page of text
2. A menu
3. A scroll action
For a page of text, we will transmit ascii codes for each character. Additionally, we will have to come up with special
codes to denote bold, italic, underlined, center/left/right alignment changes, and font size changes. What is considered
"a page" of text is not defined by what the display can show. It is a pre-determined amount, and the display unit will
need to hold the whole thing in memory. Initially, the DU will just show the upper portion of a newly recieved
page.
A menu will be sent in the same manner. It must be identified as a menu, however, in order to handle scroll actions
differently than a page of text. It will also contain a special code to denote the menu item that should initially be
selected.
Scroll actions are sent when the scroll wheel is used. We want the scroll wheel to be physically
located on the EIU, and
the EIU must have administrative control over when the scroll wheel inputs are sent to the DU. If a page of text is
currently being displayed, the scroll action will cause the expected result on the display. If a menu is being shown, a
scroll action will cause the highlighted entry to change as expected. We may consider removing the scroll message from menu
situations, and just resend an updated menu description.
Another communication issue that occurred to me is populating display option menus. For example, there are display
technologies for which "font size" (segmented LCD displays) or a backlight control (Eink's display does
not need a backlight) are meaningless. For this reason, we will need to add a capability for the EIU to poll the DU to find
out these details, so it can omit useless menu entries, and even remove tags from page descriptions (if font size is useless,
don't bother sending it).
WEEK 03 SUMMARY
Accomplishments: Begin fleshing out communications protocol.
Weekly Work Total: 2.5 hours
Project Work Total: 9 hours
Feb 1, 2006 (5 hours):
I drew up some plans for alternative packaging ideas. Since I used
pencil and paper, I will have to add a link to them after I get them scanned in. The constraining factors in the layout as far
as space is concerned are the lcd screen, the DU, the EIU, the batteries, and the thumbdrive port. My favorite design is a
notebook, where the left side consists of the lcd screen and the DU, which connects by ribbon to the right side, which holds
the EIU, batteries, and a recessed area for the thumbdrive. There is a hinge between the two halves, to allow the unit to fold
up when it is not in use. This will protect the screen during storage.
We also had a group meeting tonight to discuss component selection. The major components that we are interested in are the lcd
screen, the micro to drive the DU, the micro/USB host to drive the EIU side, and external memory.
The DU micro: The selection of this part is constrained mostly by communication requirements. We need to insure that
the DU can recieve a new page of text and compose a new framebuffer in a reasonable amount of time. This needs to be done in
at least a second. We also discussed the case where a user is rapidly scrolling through a text file. We determined that it
would make sense to just update the page number, and refrain from sending the body of the text until rapid scrolling has
ceased. The reasoning behind this decision is so we can eliminate both the communication time between the EIU and DU and the
time it takes to compose an entire screen. We are thinking of using a chip in the PIC18f family, but also want to
spend the rest of this week trying to find an acceptable 16f variant, due to lower power consumption.
EIU micro/USB Host: We had 2 choices here. We could either go for the combined USB Host and micro from Cypress, or
interface a standalone USB Host with another micro. The benefit to this is that much of the interaction with the USB Host
is handled for us. The downside is that the Cypress product doesnt have any internal non-volitile memory, so we need to by
some EEPROM. It also only has 16K of programmer visible memory, so we will need to add SRAM to be able to hold both the parts
of text file fetched from the USB thumbdrive and the translated, word wrapped, pages ready to be sent to the DU. We
decided the simplicity of working with the USB host was the more important feature, and opted to use the cypress
chip.
LCD screen: We want at least a 360X240 resolution screen, and have been eyeing a number of options. We found one
that can operate at 5V. Most screens require an LCD drive voltage of 30V. We are still researching our options here, since
this is the most costly component. Another factor we are considering is the backlight. To drive it, we need a chip that
will turn 5V DC into a high AC voltage.
Memory: Since we decided to use the cypress chip, we need to buy EEPROM and SRAM. As far as the SRAM goes, we have
found 64K (8K X 8) for ~$15. We are contemplating using NVSRAM, to enable the device to power down and turn back on with
the last viewed page on the screen. Also, it will allow us to add bookmarks to files.
February, 2006 (4 hours):
I have drawn up a flow chart for the operation of the EIU. I also did some quick calculations to determine the memory
needs of the DU. In order to store fonts, we need ~20kB for 3 sizes X 3 faces. A framebuffer willl take ~8kB. The only
dark horse is actual program memory. To be save, we will budget 20kB for this.
I have also spent time looking at PIC 16F/18F and ATMEGA microcontrollers. Out of those I found a few candidates
PIC16F916: 4 kB program memory, 256 kB data EEPROM,
SPI support, max speed 20 MHz, on-chip oscillator 8 MHz.
ATMEGA32: 32 kB program memory, 2kB SRAM, 1 kB
EEPROM, SPI support, max speed 8 MHz (16 MHz for ATMEGA32L)
ATMEGA64: same as above, but double the
memory.
ATMEGA162: 16 kB program memory, 1 kB NVSRAM,
512 kB EEPROM, SPI support, max clock 16MHz (8 MHz for 162V), NO USELESS ATOD.
ATtiny84: 8 kB program memory, 512 kB SRAM, 512
kB EEPROM, USI support (SPI compatible), 20 MHz max speed.
I think 20kB is a very high estimate for program memory, if we use the ATMEGA32 we will have 4-12 kB program memory. If
this is suitable, there are a number of smaller PIC and ATMEL devices to look at, most notably the ATtiny chips, of
which I included a description of one above.
PIC Advantages- smaller, lower power.
ATMEL advantages- Better debug environment.
February 5, 2006 (1.5 hours):
The team met to finalize component choices.
WEEK 04 SUMMARY
Accomplishments: Worked towards finalizing component selection. Drew up form factor ideas.
Weekly Work Total: 10.5 hours
Project Work Total: 19.5 hours
February 6, 2006 (9 hours):
I did a lot of work for the packaging homework. First, I had to figure out
how to make a PCB footprint for both the DU and the EIU. In order to do this, I first had to make a schematic with all the important parts on
it for each unit. To make the schematic, I first had to make the parts and associate them with a package. I made parts for the lt1980, sed1335, and
mc9s08gt32. I was able to find a premade cy7c67300, and lt1108 DC/DC converter. I then created netlists for both boards, and placed the parts using
the PCB Designer utility. Adding extra room for more discrete parts and headers, I found that the boards would be 4" X 4" for the DU and 4.5" X 2" for
the EIU. The DU ended up having a larger area because it has 64 and 60 pin chips.
Packaging- top view
Packaging- perspective view
DU PCB Footprint
EIU PCB Footprint
Key for the packaging images:
Green = PCB
Yellow = Battery
Blue = LCD Module
Red = Button
Aqua = Connector (ribbon and header)
White = Plastic/USB thumbdrive
February 7, 2006 (6 hours):
I did more work on the packaging homework. I re-did the footprints with more accurate
packages. I also moved some items on the cad drawing. I added a magnetic switch (for putting the unit to sleep when it is closed) and a reset button.
I also added dimensions to the cad drawing. I got a lot of work done on the actual homework document. My updated images are linked below.
Packaging- top view
Packaging- perspective view
DU PCB Footprint
EIU PCB Footprint
Key for the packaging images:
Green = PCB
Yellow = Battery
Blue = LCD Module
Red = Button/magnetic switch
Aqua = Connector (ribbon and header)
White = Plastic
Pink = USB thumbdrive
February 8, 2006 (6 hours):
I finished up the
packaging homework tonight, except for formatting the refrences.
WEEK 05 SUMMARY
Accomplishments: Packaging homework
Weekly Work Total: 21 hours
Project Work Total: 40.5 hours
February 13, 2006 (2 hours):
I have been
researching the PDF file format in the hopes that we could include
partial support for it. Unfortunately, I learned that, while the file
structure would be simple enough to parse, the data streams are
encrypted using a proprietary scheme. The specification for PDF can be
found here
.
February 16, 2006 (2 hours):
I spent time getting ready to set up a prototype interface
with our LCD. Tomorrow we will be programming an HC12 to communicate with a SED1335 to drive our LCD. I looked into the
details for programming the 9S12s FLASH memory, and acquired a BDM that will be compatible with both the 9S12 we will use
for prototyping and the 9S08 that will be on our actual board. I also discussed issues relating to the LCD power with Thomas.
February 17, 2006 (8 hours):
Set up CodeWarrior and successfully programmed the HC12. I wrote an interface for
sending commands and the related parameters to the SED1335. The function run_command will accept a command and an array of parameters. First it
checks that the command is valid. It then checks to see that the number of parameters supplied matches the number expected. It will then put the
command on the data bus and latch it. It will then do the same for each parameter.
WEEK 06 SUMMARY
Accomplishments: File format research, LCD prototyping
Weekly Work Total: 12 hours
Project Work Total: 52.5 hours
February 22, 2006 (6 hours):
I think I finally got the SED1335 initialized right. I've checked all the signals on the scope,
and they appear correct. Data also now appears on the data lines. All that hopefully remains is to hook up the LCD. I think the connector is correct
up to PIN 11 on the LCD side. I think if we get the last 3 pins wired correctly, we have a winner.
WEEK 07 SUMMARY
Accomplishments: More LCD prototyping
Weekly Work Total: 6 hours
Project Work Total: 58.5 hours
February 28, 2006 (9 hours):
Met with the group to prepare our design review presentation.
WEEK 08 SUMMARY
Accomplishments: Midterm Review
Weekly Work Total: 9 hours
Project Work Total: 67.5 hours
March 7, 2006 (2 hours):
Met with the group for the proof of parts demonstration. I also contacted Mouser to clear up
an issue with our last delivery. We did not receive all of the parts for our magnetic switch. New parts should be shipped by tomorrow.
March 8, 2006 (2.5 hours):
I began work on an EIU simulator, since I can't begin developing code on the actual target until we
either get our hands on a dev kit or have a populated PCB. The goals of this simulator are twofold:
1) Outline the messages to be sent between the DU and the EIU
2) Develop code for a page scanning and caching system
Today, I made headway on number 1. The relevant code can be found in messages.c. In summary, there will be four message
classes:
1) Startup Message: the EIU will send its 1 byte startup message to the DU until it receives the expected response
2) Menu Message: The EIU will send a multi-byte message describing a menu. Additionally, one byte MENU_UP and MENU_DOWN messages will be sent to the DU
to instruct it to change the focus of the menu that is currently in memory. Refer to messages.c for more notes.
3) Page Message: The EIU will send a multi-byte message describing a page of text. The current page number will be included. Refer to
messages.c for more notes.
4) Option Change Message: The EIU will utilize this message type to change the DU's display settings. Examples of such settings are text size, backlight
brightness, and possibly screen orientation.
Additionally, I ordered the plastic for our case today. The total cost ended up being $37, which, though it seems high, was brought down from $150.
The plastic will be pre-cut to our desired dimensions and should be shipped tomorrow.
WEEK 09 SUMMARY
Accomplishments: Began EIU simulator, began characterizing messaging system, ordered packaging materials
Weekly Work Total: 4.5 hours
Project Work Total: 72 hours
March 13 - 19, 2006 (0 hours):
Spring break, I am in Ft Lauderdale, FL.
WEEK 10 SUMMARY
Accomplishments: Got a tan
Weekly Work Total: 0 hours
Project Work Total: 72 hours
March 20, 2006 (3 hours):
I checked up on the delivery of plastic from Harbor Sales. There
was a problem with the address so it had to be rerouted. It was supposed to arrive today, but did not. I will have to
check up on it tomorrow. I also did more work on the EIU simulation/skeleton code. I now have the various button input
interrupt routines outlined, and the message protocol has been slightly modified.
Update: The plastic was delivered to the billing address... my home in Indianapolis. I'll have to drive down to get it
this week.
March 21, 2006 (2.5 hours):
I have started reading through the documentation for the GNUPro toolkit. We will be using this
package to write and compile code for the Cypress EZ-Host. I was able to compile and run a sample program using BASH. I was unable to get the simulator
to operate correctly. As I was trying to figure out what was wrong, I got sidetracked and began reading up on programming and debugging the target.
Unfortunately, it looks like we failed to run the debug pins to any sort of header... hopefully I'm wrong about this. Otherwise, we will be forced to
attach some wires so we can read the debug info.
March 22, 2006 (4 hours):
I spent an hour becoming more familiar with the code provided to us by Cypress. I believe
everything we will use is located at the paths C:\Cypress\USB\OTG-Host\Source\stand-alone\fwx2 (framework x2?)
and C:\Cypress\USB\OTG-Host\Source\stand-alone\msc (mass storage c?).
The first folder contains all of the code for working with a FAT filesystem, and msc provides an example implementation. Of course, all of this code will
need to be heavily edited for use with our board.
Additionally, I looked into what it will take to actually program and debug the Cypress chip. The two processes for compiling, loading, and running the
code are different. First, debug mode is run through the UART using pins 42 and 43. A debug program must be used to both program and run this mode.
We still need to figure out how this is going to connect to the computer (serial port, I assume, but the details need to be fleshed out).
To program the EEPROM, we will use pins 39 and 40 using the I2C protocol. This will need to be done through Dataman. Again, we need to flesh out the
details- ideally before the end of the weekend.
I then spent 2 hours going to Indy and back to pick up our plastic. It looks like it will work perfectly! There is a huge amount of extra plastic though,
so if any other teams are in need of some cheap plastic, Team 3 is in business.
Tonight in the lab I was able to inventory and organize the plastic shipment. I also did a visual inspection of the PCB and a cursory trace check. At least
there don't appear to be any ground/power shorts. Also, to this novice eye, the connections seem to be correct.
March 23/24, 2006 (12.5 hours):
It took a really long time, but I was able to put all the power circuit parts on the board. There
are a few reasons why I have decided to not hook power up to it before going home:
1) It's 5:30 am, and I can't see straight
2) We don't have any 5.1 Ohm resistors for R7 and R8- I put some leaded
resistors on there for testing, but we need to get our hands on some surface
mount. Maybe the HKN lab?
3) I have a 330K resistor in for R32 (should be 300K)
4) I have a 15 Ohm resistor in for R27 (should be 10 Ohms)
5) I don't know what should be going in the J34 header (the signals are labeled
VBIAS2 and BATT_SEL)
After I get some rest, I will come back in to the lab and do a sanity check before applying any power.
A point to keep in mind when looking at the board:
- a stripe on a capacitor marks the positive terminal
- a stripe on a diode marks the negative terminal
March 24, 2006 (7 hours):
Thomas, Danny, and I finally applied power to our board. It did
not work as expected. It wasn't until we set a bypass capacitor on fire that we realized we had been applying far too
high a voltage, due to incorrectly using our power supply. Luckily, damage was limited to the capacitor and can be fixed
with minimal flywiring. We decided to focus on making sure our secondary DC/DC converter was working (it turns 3.3 V into
5V and -22V). After much continuity checking, we determined that that IC was ruined as well. I replaced it (I am getting
much better at soldering), but we still did not see the correct operation. Ultimately, Thomas determined that the
circuit is set up incorrectly. After examining the PCB, it will take some ugly hacking to get it to working order. With
all that sad news, the plan going forward is this:
Saturday: Get the power circuit working correctly, using any means possible. This will likely render our board an
unsightly Frankenstein.
Sunday: Update the layout to include everything we learned about the power circuit. This will also give us an opportunity
to bring the UART ports from the Cypress out to headers. This will make life easier when we are busting our humps to try
and finish the code.
Monday: Place an order for a new EIU board and a number of spare parts.
In parallel, Danny will be working on getting the DU end up and running. Being able to write to our LCD will be a
significant step, and will allow us to salvage some semblance of functionality in the worst case scenario. Also, once we
have ironed out the power circuit on the EIU, we will be able to put the Cypress on and begin implementing code. The
outlines are already done, but it will be a significant step to see it working on the chip.
Hopefully, this schedule will allow us to have a new board in hand by April 3 that we know works. By that time the
DU should be fully functional (including code), allowing us to focus all our efforts on finishing the EIU by the end of
the semester.
March 25, 2006 (9 hours):
Thomas and I spend the day debugging the power circuit. We
identified a problem with a voltage divider on the LTC1980. It was fixed by changing the value of a resistor. We finally
succeeded in getting our regulated 3.12 V signal out of the LTC. Tomorrow I plan to focus on getting the Cypress on the
board, because I think the development process is going to be painful and I want to get going ASAP.
March 26, 2006 (7 hours):
Thomas and I continued to debug the power
circuit. We were able to get switching signals out of the battery charging circuit, but it is still not
operating correctly. I also wrote a test program to put on the cypress when we get it on the board.
WEEK 11 SUMMARY
Accomplishments: Added interrupt outlines to EIU simulator. Investigated GNUPro toolkit.
Began to familiarize myself with the EZ-Host framework. Picked up and inventoried plastic. Visually inspected PCB.
Put power circuit on PCB. Began power circuit debugging process.
Weekly Work Total: 45 hours
Project Work Total: 117 hours
March 27, 2006 (11 hours):
Thomas and I continued to debug the power circuit. After discovering a cold solder joint on the
transformer, we were able to observe the charging circuit in action. After more debugging, we noticed that the timer signal was now off. We believe the
pin may have been shorted to VBAT while scoping signals.
March 28, 2006 (8 hours):
I worked on the DU software. I was able to get the 9S08 communicating with the S1D. The signals seem
to be right, since the frames are being written at 60Hz, as is expected. Tomorrow I will do a more exhaustive check on the signals.
March 29, 2006 (3 hours):
I did a final check of the LCD signals. Everything appears correct. I populated everything except the
MOSFET for the backlight circuit. The LCD is ready to hook up.
April 1, 2006 (5.5 hours):
I tried to work on the software for the EIU. We cannot have interrupt driven button presses, since
the pins the buttons were connected to do not have interrupt capability. We will have to poll the buttons to notice changes. While developing the code, I
found a strange problem with the EEPROM. It is impossible to write the first bit of a 64 byte block as a 0. I tried changing the timing the dataman
uses to write to the chip to no avail. I also soldered wires to our old memory chip to test it. It produces exactly the same behavior.
April 2, 2006 (7 hours):
The memory issues I discussed yesterday were resolved by
retouching the solder on the chip. This way Mat and I were able to render both EEPROMs functional. Most of the day was
spent debugging a problem that made programs calling functions outside of main operate erratically. It turned out to be an
error in memory mapping during compile time. Once that hurdle was cleared, I was able to imlpement button press detection
and make the SPI peripheral put data on the transmit line correctly. Currently, the SPI is set up to be only a transmitter. I
will have to implement SPI interrupts to allow it to receive from the DU.
WEEK 12 SUMMARY
Accomplishments: Got the power circuit to display battery charging behavior. Got the 9S08 successfully communicating with
the S1D. Implemented button press polling and initialized the SPI peripheral.
Weekly Work Total: 34.5 hours
Project Work Total: 151.5 hours
April 3, 2006 (15 hours):
I wrote some code for the Cypress to respond accept button input and output SPI signals for rendering
a menu on the DU. Danny and I spend a long time trying to debug the DU. It turns out the 9S08 has problems with large arrays. The solution was to simply make
it a smaller array. I built a connector for hooking up the EIU and DU and applying power and a button console for testing the EIU.
April 5, 2006 (10 hours):
I started looking at the USB framework today. I tried to get some code running with the USB overhead
and my button handler. I attempted two different approaches: 1)start with the full MSC example program and remove code to try and get it working and 2) start with
a smaller program and build up to the full USB framework. 1) was a resounding failure. I was unable to observe code running on the micro. I was able to use approach 2
to recreate the same program I made on Monday. Unfortunately, this is far from the code we will need for USB (compare 4K to ~40K).
April 6, 2006 (13 hours):
I attaked the full MSC code again today. Danny was with me for the beginning of the night.
This time I was able to get code running, but we ran into issues when trying to clear the bss memory segment. We spent a lot of time in vain, as it was
until late at night that I was able to find some useful documentation on the memory structure of the example design. It turns out that 1) the SRAM has to be hooked up
since the code is loaded into main memory from the EEPROM at startup and 2) the design assumes an extra 8K of external memory that we do not have.
After attaching the SRAM, I was able to get the program to continue further into its execution, but it still stalls during initialization.
April 7, 2006 (6 hours):
I continued to look at the MSC code. I am observing erratic program behavior. For example, the same code,
when recompiled, will execute differently. I was able to get the program farther through initialization, but I am not enthusiastic about this approach. I spent most
of today trying to get back to where I started, since an edit early in the day caused the program to reset the micro early in its execution. I have a feeling I am missing
something basic.
April 8, 2006 (6 hours):
Today went much like yesterday. I spent a long time debugging the code, without making much progress.
main gain today is that I am becoming very familiar with what the program should be doing. I have been reading up on the framework and the memory structure.
I tried multiple linker scripts, with the hypothesis that I am still not mapping the program into SRAM correctly. These experiments only succeeded in teaching me how
linker scripts and makefiles are written.
April 9, 2006 (14 hours):
I finally made some real progress today! After reflecting on the problems with the micro, I concluded that
what was happening was that illegal memory refrences were causing the micro to reset. This could have one of three causes.
1) the code is written badly and is accessing bad memory
2) the code is mapped into SRAM incorrectly, causing it to refrence locations outside of our space
3) there is a hardware problem causing certain address refrences to behave erratically
Since I already spent 3 full days pursuing 1 and 2, I decided to finally check the third option. Lo and behold I discovered a loose pin and 2 address pins tied together.
Soon after fixing these problems, I had the example code up and running. The initialization performs correctly, and the application task runs periodically
(as is expected). I tried to add my menu code on top, but I have run in to yet more obstacles. It appears the global variables are not handled the way I
think they should be. If I force the micro to stay in my application task, I can get it to correctly register button presses. If I allow the micro to run its interrupts,
however, I lose my global data.
Here are the most important source files:
UPDATE: Links removed for legal reasons
app.h These first two are our application specific code
app.c
fwxmain.c This holds the main() function, runs framework initialization and support
fwxcfg.h This file is used to choose what code to include and sets up important constants
msc.ld This file is used to map the code segments to SRAM locations
makefile
WEEK 13 SUMMARY
Accomplishments: Got the EIU responding to button input. Got the EIU and the DU communicating, and the DU displaying text.
FINALLY got the mass storage code running on the micro. Started porting button input and communication code to MSC code.
Weekly Work Total: 64 hours
Project Work Total: 215.5 hours
April 10, 2006 (8 hours):
I wrote the introduction and ethics sections of the report. I also helped Mat test the power
circuit on the new board. It seems to work correctly with a small load on it. We will need to do more testing to know for sure though.
April 11, 2006 (4 hours):
I spent today working on homework 12. I finished the rough draft and just need to proof read and
finish my citations.
April 13, 2006 (9 hours):
I decided to take a break from working on the memory issues for a little bit. Today I worked
on getting the code needed to handle the battery gague interrupts. Currently, it is treating button signals as both the interrupt and polarity signals.
I developed the necessary code for both the DU and EIU, so it will print out messages when the battery is charging, and will update the fuel gague
accordingly. I also put the final touches on my report.
April 14, 2006 (9 hours):
I finally figured out what the problem with the Cypress has been the whole time. I found which
arguments in the linker script told the chip what type of external memory it is connected to. Now, the chip actually interfaces with the external memory
correctly. I got the chip to recognize when a USB thumbdrive is plugged in. It prints the CHARGING message I developed yesterday to the screen when it
detects a drive. It then clears that message if the drive is removed.
April 15, 2006 (4 hours):
I was able to get the EIU to read the directories off the USB. I coded up the menu system for
traversing the directories. This part went much smoother than I had anticipated.
April 16, 2006 (11 hours):
When I got to the lab, the programs I had written yesterday were no longer working. After swapping
out the SRAM, I eventually tracked the problem down to the data lines going from the Cypress to the SRAM. I don't know why, but the signals had become
incredibly noisy. I retouched the solder on those pins, and the code ran correctly again. I spent most of the night trying to open files and print
a page of text to the screen. I am able to open files, but I am still working on communicating the page to the DU.
WEEK 14 SUMMARY
Accomplishments: I got USB and FAT code up and running! The EIU can now traverse a directory system. I started getting
the page viewing code written. I also wrote code to work with the battery fuel gague. I debugged a problem with noise on the
data lines.
Weekly Work Total: 45 hours
Project Work Total: 260.5 hours
April 17, 2006 (6 hours):
I got wordwrapping and changing pages working on the EIU.
April 18, 2006 (4 hours):
I added functionality to the Options menu. The backlight can now
be toggled and spacing can be changed.
April 19, 2006 (4 hours):
I added another option to the Options menu. Invert will now
switch if the screen is black text on a white background or white text on a black background.
April 20, 2006 (4 hours):
I worked more on the packaging. I had to rebuild the front for
the EIU because the previous button placement was not going to work. Thomas pointed out that we need room on the DU side
for a recessed area so the buttons don't prevent the unit from folding up all the way. I also found the bug in Danny's
menu border code, so the borders are now done in graphics mode and not in text.
April 21, 2006 (6 hours):
I intended on adding the magnetic switch code today.
Unfortunately, while debugging the code, something happened that made the LCD stop working. It appeared that the S1D was
no longer functioning. It turned out to be a problem with the programmer. After a reboot and a reflash of the program, the
LCD worked again. I also filmed a video with Mat and Thomas showing our project in action.
WEEK 15 SUMMARY
Accomplishments: I got files to open and wordwrapped pages to display. I added functionality to
the Options menu. I began the packaging. I started the magnetic switch code.
Weekly Work Total: 24 hours
Project Work Total: 284.5 hours
April 24, 2006 (8 hours):
Thomas was able to get the battery charging circuit to start working,
so I decided to start writing code. A capacitor that Mat and Thomas had removed turned out to be critical in the operation of
the battery gauge chip. After replacing the cap, the battery gauge began producing the interrupt behavior expected. I was able
to implement the code I had already written, and send messages to the DU. Instead of only showing 4 battery levels, I decided to
make the gauge 161 pixels wide, which will allow a much higher resolution. The reason for this decision was to make a video
proving the gauge operation more feasible. Initially, I had the gauge always display, but the constant messaging appears to interfere
with the previous menu and button press messages. After trying a number of handshaking protocols (which help the problem but do no
get rid of it), I decided to make the battery gauge available through the options menu.
April 27, 2006 (3 hours):
Mat and I finished the packaging except for the hinges today. The PCBs
and LCD are now in the case
April 28, 2006 (0 hours):
I did the bonus presentation for EE270 today.
April 29, 2006 (2.5 hours):
Met with the group today and made our poster. We also determined our
responsibilities for finishing up the rest of the project. I redid the hinges to make the unit more stable.
April 30, 2006 (2.5 hours):
I edited my previous homeworks (4 and 12) down to 3 pages. I wrote my
individual contributions.
WEEK 16 SUMMARY
Accomplishments: Got the battery gauge software written and operational. Finished the packaging.
Weekly Work Total: 16 hours
Project Work Total: 300.5 hours
