Daniel Wilhelm's Lab Notebook

Week 01

January 11, 2006 (3 hours):
Today I researched the feasibility of a project idea I had -- using a simple one- or two-electrode EEG (ElectroEncephaloGram) as a wireless input device for, say, controlling Powerpoint presentations. I found several research papers on the subject. Interestingly, things that one would consider artifacts in EEG recordings such as blinking or (teeth) grinding turn out to be consistently recognizable features (perhaps perfect for DSPs)! Of course, what all of the glowing research reports don't tell you is that unless the subject is completely immobile (e.g. paralyzed on a wheelchair), the EEG picks up myriad signals from even the most rudimentary muscles or movements, likely making signal identification impossible! So, scrap that idea.

A better alternative would be to use perhaps an MEG (MyoElectroGram) which measures muscle contractions. Then, the user would train a seldom-used muscle contraction (or perhaps a pattern of them) to activate a slide transition. Of course, the underlying wireless architecture and signal processing routines would be virtually identical to an EEG. For some reason though, measuring brain waves just sounds much cooler! ;-)

FILES:
[1] TXT EEG/MEG Notes

January 12, 2006 (1.5 hours):
We had a team meeting today where we narrowed down our ideas. We selected the four we were most interested in hoping for some comments from course staff. Summarized: (1) Handheld Text Reader, (2) Synthesizer (e.g. converts Guitar to Piano), (3) 3D Input Device, (4) Handheld Video Game Device.

January 13, 2006 (2.5 hours):
Having met with the team, we have decided to look into the feasibility of developing a handheld text reader product, much like Sony's upcoming Reader. My objectives were to research possible bistable display technologies then to see if any products may be readily available for our use. This PPT compares many different bistable technologies at its conclusion. Based on this comparison, it seems that "Cholesteric" displays would be best for our purposes due to the low cost and low power consumption.

So, I began researching possible companies which offered this type of bistable display. Based on Jeremy's work with NTERA products, I investigated them first. Unfortunately, he must have been working with an in-development product since NTERA only offers segmented displays for sale at the moment (high-resolution displays are on their Future Products list). After examining several other companies' websites, E Ink was the only one which offered a product available to the public -- a 6" display prototyping kit -- but for $3,000. Nevertheless, I called a receptionist who recommended I send their sales staff a sales request, which I then did, asking whether a donation or student discount could be offered.

FILES:
[1] TXT Bistable Display Notes
[2] TXT Letter to E Ink Sales Dept

WEEK 01 SUMMARY
Accomplishments: Formed team, narrowed ideas to four. Thoroughly investigated the EEG and iReader project ideas. Contacted E Ink regarding a donation or discount.
Weekly Work Total: 7 hours
Project Work Total: 7 hours

Week 02

January 19, 2006 (1.5 hours):
We discovered yesterday in-class that only our iReader and Synthesizer ideas were tangible. Today, I still did not receive a reply from E Ink from my sales request made a week prior, so I decided to PM a very active E Ink support forum engineer as well. Sales contacted me shortly afterward, relating that no opportunities for students currently existed. Later that afternoon, however, I was notified by the support forum engineer that they were considering offering a student discount of 50%; however, their orders were backlogged and it may take some time to obtain a kit. $1500 was still a bit over our budget, so we decided to pass. I was asked to post the results of our project on E Ink's forums, however, so I'll have to remember to do that!

After hearing this news, we still decided to pursue the iReader project. Jeremy came up with an interesting idea to decouple the display interfacing/bitmap generation from the core logic, allowing for minimal redesign with future display technologies.

FILES:
[1] TXT E Ink Sales Reply
[2] TXT E Ink Engineer Conversation

January 21, 2006 (4.5 hours):
Today, dismissing the possibility of obtaining a bistable display, I researched LCD displays. I'll just post the main conclusions here -- for full details/resources/sources/conclusions, please see the files. First, the typical LCD backlight makes up ~50% of the power consumption for AN ENTIRE PDA. Further, the LCD display itself only typically requires ~5V, but the backlight typically requires ~12V. Hence, we may want to consider not supporting a backlight at all. What about LED backlighting? One source said this reduces power consumption by ~60%, but requires ~22V. Second, I only looked at displays with a 6" or higher diagonal. I figured that we wanted a display larger than a PDA's since those are hard to read text files on.

OK, now for some "empirical" findings. It seems that most high-resolution LCD manufacturers do not sell to the average individual. Some offer samples, but at outrageous prices for basic models (> $200). One step down from this are hobbyist stores. These offer graphical LCDs, but they tend to be 4" or smaller. Yet another step down is bulk/surplus stores, which offer "miscellaneous" displays, many without data sheets and also without (I suspect) controllers either. Both of which could be a problem. 1.5" cell-phone displays on the other hand are very cheap, ~$8. So, it may be possible to patch displays together (at the expense of more logic/wires) or to even rip a display out of a product. There are a few on-line accounts of this being done, but in many products the display is connected to a controller soldered onto the main PCB, making this infeasible. See the files for recommended models (note -- some of this was done Jan 22, but included here for clarity):

FILES:
[1] TXT Potential LCD Supplier/Model Notes
[2] TXT PDA Power Notes/Sources

January 22, 2006 (2 hours):
We held a group meeting today where we finished Homework 2 and decided on individual responsibilities. Jeremy's modular design for the iReader was decided upon, with the "Display Unit" (DU) interfacing with the display and the "External Interfacing Unit" (EIU) interfacing with everything else, with one micro per unit. We shared our findings on LCD displays and USB modules. DigiKey, a distributor I didn't check yesterday, actually had some good LCD deals for reasonable prices. My primary responsibilities are the low-level graphics routines (i.e. the DU), the Software Narrative/Listing, and the Patent Policy Analysis.

WEEK 02 SUMMARY
Accomplishments: Massive LCD Research, E Ink Resolution, Project Decided, Responsibilities Determined
Weekly Work Total: 8.0 hours
Project Work Total: 15.0 hours

Week 03

January 24, 2006 (1.0 hours):
In response to lecture, I initiated an email discussion on refining our Project-Specific Success Criteria for a class presentation tomorrow. You can see the results in the file attachment. I also created a Powerpoint slide for the class presentation and updated the main site with all documents to date! Thomas also gave us great news today that the course staff has an LCD sample which we may be able to use for prototyping. Whether we'll purchase our own is still in the air.

In lieu of any other more necessary activity, I've decided to do a study on raster vs vector text rasterization over the next few days. I've had some experience with both, so I'll be focusing on the particular effects of both on a small (4-6") LCD screen with regard to font scaling, memory requirements, processing requirements, and clarity.

FILES:
[1] TXT Project-Specific Success Criteria

January 28, 2006 (1.5 hours):
  

This is just a quick preview of my text rasterization investigation. The images in this post simulate Thomas's LCD recommendation, which has a 4.7" diagonal (~3.8"x2.8") at 320x240 (not to mention a sample is only $50!). Hence, these images should be 3.8"x2.8" on your monitor and they contain exactly 320x240 pixels! The left image has a ruler along the edges, so put a ruler up to it to verify an inch is an inch on your monitor. The clearest font I could find is Georgia 8pt (a variable character-width font), no anti-aliasing (the top test fonts are all fixed-width). Actually, on the ruler image, the uppermost of the three a..z text lines IS antialiased -- in my opinion, it's a bit harder to read when viewed more up close due to blurriness (see for yourself if you want). Also, each character seems to be rendered from 4-7 pixels wide on a variable-sized font, and 6 pixels wide on a fixed-width. Also, given the current display, I estimated that the first chapter of Ulysses alone would take 146 screen-fulls! Is this too many?

I should also mention that the above use a very crude word-wrapping system -- the wrapped word is actually moved to the next line, leaving a (sometimes) huge gap. We discussed actually justifying the text instead of leaving the gap, which we won't able to test until I'm finished with my simulator. I'm going to do the mentioned estimates Monday then use them to select a sufficient microcontroller, so I'll update this upon completion.

WEEK 03 SUMMARY
Accomplishments: Project specified in more detail, text rendering/DU micro selection work underway.
Weekly Work Total: 2.5 hours
Project Work Total: 17.5 hours

Week 04

January 31, 2006 (4.5 hours):
 

Font Storage: There are 95 viewable characters in ASCII (0x20-0x7F, limiting to primarily English but allows two characters/byte). Maximum size of a normal font is 8x8; for a monochrome display this takes up 64 bits or two bytes. Hence, one fixed font face will take up 190 bytes (512 bytes max if a graphic is specified per character). A full-screen graphic (e.g. bootup screen) will take 320x240/32 = 2400 bytes. Line/vector graphics will be drawn procedurally, requiring only memory for code. An average large font character may take 40x40 while a medium character around 15x15 (see the second image). If we support bold and italics, this is in essence three additional fonts. So, total, to support 95 characters, three font sizes, and three font types/size, a bitmap fonts will require (3 styles)(95 chars)((64 bits/char) + 225 + 1600)/32/1024 = 16.43 KB. This is probably more of an upper limit.

Code Size: The DU must be capable of (1) Writing to the LCD display, (2) Interpreting/Generating EIU protocol signals, and (3) Rendering a screen bitmap. Going by some average code size statistics, in 1992 it was between 16K-64KB; in 1996 it was 64K-512KB. Since most of this unit's processing will be done on the EIU micro, 64KB should be PLENTY of room for the rasterization code.

Processor Speed: First, we'll address the LCD update rate. On the timing chart, T=0.0595ms typ. for sending a ROW serially (in 4 pixel blocks). Since there are 240 rows, then 1/(240*T) ~= 70 Hz. The shift clock period is 71 ns, and at each clock rise a new 4 pixels must be loaded into the serial buffer for display, coming to a 14.1 MHz update rate required. Hence, the processor probably needs to run at this rate at a minimum. Basically, an interrupt will just send the next bits from the framebuffer to the display while we render the display. Luckily, in all cases text is rendered top to bottom, left to right, so there is a chance we can render faster than the screen refreshes.

Team Meeting: The team also met today for 2 hours, and we had quite a bit to discuss. I'll briefly recap some of the major issues. First, it seems we can either get a prepackaged USB interface OR plentiful SRAM/non-volatile RAM with the EIU micro, but not both. Second, it would be somewhat easy to get a non-volatile RAM where we store the page caches so that upon bootup the last thing read is immediately available (including various variables such as bookmarks). Third, how in the world will we keep track of what page the reader is on?! We'd actually have to scan through the entire text file and analyze the lines to see how many fit on our screen! So, we split up component research amongst us and we'll get back together Sunday.

FILES:
[1] PSP Vert LCD Template/Layers (Paint Shop Pro v7+)
[2] PSP Horiz LCD Template/Layers (Paint Shop Pro v7+)

February 4, 2006 (6.0 hours): I have recently realized that the 320*240/8 = 9600 byte framebuffer should be stored in SRAM instead of Flash due to excessively long erase/write times and a limited number of updates (see link1 link2). This presents a problem since the low-power micros we were interested in for the DU generally don't have much on-chip SRAM (the ATMEGA64, which is one of the largest chips we are considering, only has 4KB). So, there are a few alternatives: (1) Render 1/3 of the screen at a time in a circular buffer (can it keep up?), (2) Store the framebuffer in the plentiful EIU external RAM (breaking modularity), or (3) Get a sufficient micro which is too powerful or an external SRAM (equally bad options imo). UPDATE: The problem is resolved! The LCD Controller that Thomas proposed has 32KB on-board SRAM which we can use for the framebuffer.

I also created a requirements list and compared PIC, Atmel, and Freescale microcontrollers to see which ones best fit our needs. I began with the results of Jeremy's search. Here are my top choices (see the attached file for detailed rationale) -- all are 8-bit, 32KB Flash ('?' indicates we need to discuss this):
1. PIC18LF45J10 (2 SPIs, 28 pins, VERY cheap, no oscillator?)
2. MC9S08GT32A (2 SCI?, 1 SPI, 2KB SRAM, 1.8-3.6V)
3. PIC18LF2510 (28 pins, 1.5KB SRAM, 2-5.5V)
4. ATMEGA32L (2KB SRAM, great debugging tools, 2.7-5.5V)
5. MC9S08RG32 (1.8-3.6V)

FILES:
1. DOC DU Rationale

February 4, 2006 (1.5 hours): Today the team met to discuss the component selections. We divided the workload for the presentation on Wednesday and decided to use the Motorola MC9S08GT32A microcontroller for the DU.

WEEK 04 SUMMARY
Accomplishments: Decided on component requirements then selected them, including DU micro. Made mockups of LCD.
Weekly Work Total: 12.0 hours
Project Work Total: 29.5 hours

Week 05

February 9, 2006 (2 hours): Today I read Jeremy's and Mat's HW3/4 papers and replied with comments. I also met today with teammates so that Jeremy could show us some OrCAD basics from his experience with the homework.

February 11, 2006 (6 hours):
 

I got an LCD simulator and text rasterizer engine working today. The procedure is: (1) Generate a RAW bitmap of the desired characters, (2) My software converts this into a C/H file pair by extracting each character individually and storing it as a compressed bit-per-pixel sequence in a character array, then (3) My DU software renders a given string using this newly generated C file, onto the simulated LCD for now. Coming soon will be support for variable-width fonts, analysis of the input bitmap to extract necessary font data, proper bit-per-pixel compression in the generated C file, and use of a graphical interface for the simulated LCD display (such as xv). My code is stored in the ~/lcd_code directory (for now, execute ~/lcd_code/du and ~/lcd_code/gen_font).

WEEK 05 SUMMARY
Accomplishments: Developed C software to render text on a simulated LCD.
Weekly Work Total: 8 hours
Project Work Total: 37.5 hours

Week 06

February 17, 2006 (6 hours): Jeremy and I met to begin writing software for an MC9S12 which controls an LCD display. We currently have a 240x160 monochrome LCD display and SED1335 LCD controller loaned to us by the course staff for prototyping. We have decided to purchase an MC9S08 (HCS08 Instruction Reference) and other LCD controller and display for the final product, but these have not come in yet. Today, we decided to use
FreeScale's CodeWarrior for the compiler and programmer. However, this product is only free for 16KB of code. We believe we may be able to store our font in a fixed memory location as static data not requiring compilation. Other alternatives are quite expensive and do not include such powerful debugging capabilities. We were successful in writing software to output to the MC9S12's M port and lighting an LCD. Our task is to now write data in an acceptable manner for communications with the SED1335 LCD controller.

February 18, 2006 (6.5 hours): I moved 6 control lines from Port M to Port AD (disabled ATD) since several of the Port M lines seemed to not be configurable for general-purpose I/O. I made/soldered a 16-bit bus and connected/labeled pins from the MC9S12 to the bus. I tested several of the output signals from the microcontroller to ensure proper operation using LEDs, and I studied/verified our code for what must be done to ensure proper SED1335 operation.

February 19, 2006 (8 hours): I timed the output signals from the microcontroller using an oscilloscope. A 100 ns hump was formed when writing three instructions to PORTE (0-1-0) -- this timing must be at least 120 ns, so in some cases two statements should be made. I got the SED1335 reset signal working, calculated all startup signals for the loaned LCD (using fOSC = 8 MHz, fFR = 70 Hz), and coded the rather lengthy start-up sequence to output "iReader" (NOTE: Code is still needed to clear the display upon startup). For more info on these calculations, please see my comprehensive notes in the SED1335 datasheet printout (16.1.3 (p72) and p21). Also, note that power to the LCD should be DISABLED while resetting SED1335.

Next, I connected power lines to the controller, which requires three separate lines: V0, VLCD, VDD (and VSS=0V). I made/soldered a new 15-bit bus and connected it from the LCD controller to the LCD. For testing, I am only connecting the VDD = 5V, VSS = 0V since the others are really only needed to drive the display. Unfortunately, most of my time was spent debugging -- only three pins to the LCD output periodic signals, but these have very large periods (see the circled signals on the printed LCD input specs). Hence, I suspect that I'm not initializing it properly. Up next is to connect the circuit to a logic analyzer to precisely view the timings -- the oscilloscope alone is somewhat inadequate for this. Something else to check is the SEL1/SEL2 lines going to the external 8MHz oscillator, or other input lines to the controller which may not have been set correctly. I am very confident the input sequence I selected is correct. Once these signals are verified, all we need to do is snap in the LCD and it should all work!

One more thing -- it appears that the SED1335 controller PCB's schematic is incorrect for the CL2 headers -- you'll have to flip the pin ordering left to right for the correct orientation (see the solderings on the PCB backside).

WEEK 06 SUMMARY
Accomplishments: VERY close to outputting text to LCD, wrote MC9S12 LCD startup/command code, fully connected LCD display/controller/MC9S12.
Weekly Work Total: 20.5 hours
Project Work Total: 58.0 hours

Week 07

February 19, 2006 (6.5 hours): I first tried hooking it up to a logic analyzer, but then in class Thomas told me about a triggering trick for an oscilloscope. Afterward, I used a 4-input oscilloscope to view the A0, E, D0, D1 pins. I found two errors in the software -- one was a simple parameter count problem and to solve the second I had to exchange two (crucial) lines (I had been placing/removing data on/from the bus AFTER the write signal was high). I then hooked the newly programmed microcontroller to the SED board and measured those output signals with the oscilloscope. Four out of five of the pins which should have been outputting periodic signals were (after I pruned my bus cable of stray wire strands). However, their period was too long again. Even worse, CL2 was completely erratic despite my best efforts to soothe it -- the signal jumped to +5V or +2V on a whim. The SEL1/SEL2 jumper was also a new development -- I disconnected the jumper, indicating that we use 6800 timings. This is all hampered, of course, because we don't have an updated datasheet for this SED board -- hence, we have no idea what connectors such as CN3 do!

Februrary 22, 2006 (2.5 hours): Jeremy and I worked on the LCD again today. We discovered that (1) The seemingly-"random" signal from yesterday was not random at all, but it just had a very fast period and occurred in bursts, (2) jumpers on the SED should probably be DISCONNECTED for proper 6800 operation, and (3) changes to our initialization sequence DID affect the output! Jeremy actually got the signals to look correct once I left, so we'll hook up the LCD display soon then I'll try implementing my text renderer from above if all goes well

Februrary 22, 2006 (2.5 hours):
 

Today I verfied the signals coming from the SED were correct then resoldered a bus to reroute power pins to a separate connector. We connected the LCD to power, ran the startup sequence on our microcontroller, enabled DISP_OFF_L, and lo and behold the display worked perfectly and we celebrated! Our glee was short-lived, however, because our jubilation led us to be less careful with the power lines as we should have been. Unfortunately, we believe the programming of the microcontroller while high power levels required by the display were still applied drew too much current across the microcontroller, damaging it. We believe that the programmer is still functioning correctly because it appears to communicate with the computer. We don't think the SED and LED display were harmed either, but this cannot be successfully verified until we attempt the startup sequence with another microcontroller.

I should also mention the damaged 9S12, controller, and display are NOT the versions we will use for our final product, but we were hoping to get some software finished prematurely. We shall still pusue this goal by prototyping the software with a simulated LCD in UNIX. In the above photos, the BDM is connected to the microcontroller which is connected to the LCD controller which is connected to the LCD display. The part we fried is perfectly in focus on the right.

February 26, 2006 (4 hours): Today I designed a logo for the iReader and updated our website! I don't have any fancy website authoring tools, so I wrote it in WordPad. I grabbed the images from our previous presentations and from my web journal then edited them and designed the logo using Paint Shop Pro v7.02. The documents and web journals still occupy the front page since we refer to these often. The remaining sections will be updated once we get our files organized!

FILES:
[1] PSP iReader Logo (Paint Shop Pro v7+)

WEEK 07 SUMMARY
Accomplishments: The micro, LCD display, and LCD controller interacted correctly to produce text and graphics. The micro was damaged. I designed a new website and logo!
Weekly Work Total: 15 hours
Project Work Total: 73 hours

Week 08

February 28, 2006 (8 hours): We met today to finalize our design review presentation. I updated the block diagram to reflect changes in our original conceptual diagram. This meeting took longer than expected, but in the end we corrected some flaws in our PCB and schematic and were able to give a sound presentation Wednesday morning.

March 2-6, 2006 (0 hours): I will be visiting CalTech this week interviewing for their Computation and Neural Systems graduate option and will be unable to contribute to the project.

March 9, 2006 (2 hours): Today, I contacted Freescale regarding a donation of their 32K HC08 CodeWarrior compiler and DEMO908GZ60 demonstration board. The demo board isn't the EXACT same microcontroller we're using (specifically 60K of code and a GZ vs. our 32K GT), but it was the closest of their demo board offerings.

Also this week, we had a successful design review. I helped sort the parts we have received while Brian ensured they matched the footprints. Matt and Thomas volunteered to submit the PCB design, so Jeremy and I will play a much larger role in the next few weeks during board assembly and software testing, allowing Matt and Thomas some time off. Since we fried our only microcontroller, we're now waiting for either the demo board or the PCB to continue prototyping.

FILES:
[1] Motorola Donation Request and Reply

WEEK 08 SUMMARY
Accomplishments: The design review was successful!
Weekly Work Total: 10.0 hours
Project Work Total: 83.0 hours

Week 09

March 13-19, 2006 (0 hours): Spring Break.

WEEK 09 SUMMARY
Accomplishments: Took some needed relaxation time from the project (spring break).
Weekly Work Total: 0.0 hours
Project Work Total: 83.0 hours

Week 10

March 23, 2006 (7.5 hours):

 

The PCBs (above) came in yesterday. So, today was spent learning how to solder, then making a colossal soldering mistake and having to correct it. Brian showed me some basic soldering techniques which I practiced on a sample chip and small PCB. My team then met to assemble the power supply portion of the board. I volunteered to solder a surface mount power chip, but ultimately several pads became misaligned and we were afraid of losing the board entirely. Luckily, Jeremy and another experienced classmate helped us remove and replace the chip without sacrificing pads.

Secondly, I finished Jeremy's work soldering the bypass capacitors to the DU chip (which has no power circuit). We believed at the time that the black stripe on a surface mount capacitor indicates the (-) terminal, but this was incorrect. So, I used the heat gun to remove many capacitors (flawlessly) and then resoldered them in the correct orientation. I volunteered to see whether a Dataman (X or XP) or other programmer is available which can program the 64K EEPROM (24AA512). I found a website today where a Dataman support technician said that we can use it to program our EEPROM in-circuit by tricking it that a chip exists in the slots. This partially alleviated some worries that we would not be able to program the EEPROM in-circuit (Mat verified that tricking it worked.). The Datamans we have in lab can program the 32K, but not the 64K, even though we upgraded the Dataman software. The software seems to have a software-set limit for downloading more than 32K to the chip.

FILES:
[1] High-res front/back of DU and EIU PCBs

March 24, 2006 (10.0 hours): We have code intended for the EIU Cypress microcontroller which reads and writes from a USB FAT filesystem, provided by Cypress. However, we only purchased an 32K external EEPROM and the initial code build including Cypress's libraries was 58K. So, I made progress cutting the code size down to fit in our chip. Several areas can be optimized. First, their main libraries are broken into modules which can be included in the library by a header of #defines (unfortunately, we need most all of these modules, at least the most lengthy ones). Second, their sample app alone takes up a lot of space (saving 10K by removing it and references to it). Third, several of their files require libgcc (by commenting these lines out, primarily arithmetic operations on two 32-bit ints, 10K was saved, but I'll have to write functional equivalents if I really want to save that space). Fourth, the most intense optimization to make would be to edit their libraries ourselves to take out somewhat obscure functions (which would save some, but likely not a lot). Total, I would be able to reduce its size to 38K if I wrote the libgcc-equivalent functions.

Today, I met with Thomas and Jeremy to continue our board population. First, we smelled smoke and immediately cut power, only able to note the general board region. We applied power a second time to determine the part, but heat likely built up and damaged a transistor. Third, again applying some power to determine the original burnt chip (which ended up our MAX after later testing), a capacitor erupted in a fireball, leaving a scorch mark in a corner. We determined that this was all possibly salvagable (we could at least continue developing/testing other portions of the board). We will likely order another board.

March 25, 2006 (1.5 hours): Today, I continued with the FAT paring down and started work on the HC08GZ60 demo board which recently arrived in the mail. I tried removing some more modules from the FAT software to decrease its size additionally, but I likely removed too many and it won't compile any longer. Knowing the demo board was more important, I started working on it instead. The idea behind using the demo board is to perform prototyping before we can get our damaged board in working order. The processor is slightly different from our HC08GT32 which will be used in our design, but it was the closest demo/dev board they had. We are also prototyping with the SED board and LCD provided by the course staff, which are rather similar to our in-circuit ones.

March 26, 2006 (15.5 hours):

 

I successfully installed HC08 CodeWarrior software that came with the DEMO board. I ran the manufacturer-installed LED test program on the demo board. I successfully downloaded their second test program onto the board through the serial MOD6 cable. I made a new code project with a simple test of my own and ran it on the board. There seems to be a small problem with writing to FLASH -- only 1/2 of trials succeed, with it often asking me to restart the board and simply failing, saying it can't read from the device (perhaps the voltage in should be increased (says > 9V for the serial download) or the baud rate decreased?). I had to split the old bus connectors to get the 8-bit data bus subset contiguous on port B (to vastly simplify coding) -- see the right-hand photo above.

I ported our code from the old HC12 prototype which drove the SED and LCD a month ago, mapped everything to new pins on the HC08, then redid the connectors to fit these pins. All the connectors we have are confusing, so I made a summary of them (hi-res). We need to come up with a better scheme for attaching the connectors to the pins on the demo board, as they fall off easily. I tested some output voltages, and they seem a bit off, but debugging this will wait until later in the day.

My entire team was in the lab for most of today. I continued work on the above once the other teammembers arrived. Since we decided to order a 64K RAM (after determining it was programmable by lab Datamans), the FAT issue was no longer as important. So, I continued developing the above. Mat soldered on the DU 8-bit microprocessor, and I wrote a short test program for it since I was frustrated that the DEMO board for some reason stopped lighting the +5V LCD like it had in the past, indicating something was wrong (the LED quickly brightens then dies now, I was properly grounded and don't know why!)? The debugging on the DEMO is also VERY slow, taking several seconds per single step. Hence, since my sample program immediately downloaded and ran on the new DU board (one of our few successes recently), we decided to move DU development to the actual PCB.

I meticulously updated the old prototyping code for controlling the SED for (1) the S1D (the SED with new features and completely integrated on a QFP), and (2) the 8-bit HCS08. I also wrote a test program based on this to more precisely test the DU micro. Using this (outputs to a header), Mat and I found an error in my code and an incompletely-soldered pin (an open trace). In updating the code, I noticed that the schematic was accidentally written to put the S1D in 8080 mode rather than 6800 mode, the main differences being the use of a tristate WAIT_L input intended for the 8080 which results in our micro waiting for a singal change from the S1D to latch data as opposed to the easier us providing that singal change for the 6800 version. A minor bug. Once the DU was working, Mat decided to continue by soldering on the S1D which I will test for proper output signals (and perhaps even put in the LCD) tomorrow.

Tonight I found three patents which we violated. (1) "Portable electronic apparatus", (2) " Transferring outline fonts to devices requiring raster fonts ", and (3) " Methods and system for browsing large text files". I will write my patent liability analysis on these tomorrow, and also prepare for the presentation Wednesday by making those diagrams and testing the S1D.

FILES:
[1] LCD Pins/Connectors summary (gif)

WEEK 10 SUMMARY
Accomplishments: FAT file paring down, continued LCD prototyping with HC08GZ60, soldering experience, damaged a PCB, ported LCD code to HCS08/S1D, DU micro works!, patent analysis started, DEMO board working.
Weekly Work Total: 34.5 hours
Project Work Total: 117.5 hours

Week 11

March 27, 2006 (7.5 hours):
 



I started probing the DU micro output today, trying to establish that it was functional and that it could successfully communicate with the S1D. Once the S1D outputs the appropriate signals, we can connect it to the LCD. I changed the code to make WAIT_L an input pin, and I connected an internal pull up to the pin so the micro would register its Hi-Z as high. Now when the S1D is connected, if we attach the BDM connector THEN connect power, current overflow is registered. I asked Chuck who was as bewildered as I, who recommended that we only connect the BDM after power is presented (which it then uses ~150 mA @ 3.3V). I was not able to get the S1D working. The WAIT_L signal did not seem to be controlled by the S1D (rather, it is initially Hi-Z then goes high and stays there almost immediately once code is run). Tonight, I developed our presentation for this Wednesday (see images above, hi-res). I wasn't sure what exactly should be in the hierarchical code organization diagram.

FILES:
[1] Hi-res Flowchart (gif)
[2] Hi-res Hierarchy (gif)

March 28, 2006 (6.0 hours): I spent three hours this morning making the final revisions to the homeworks then submitting them. For instance, I made the software flowchart mirror typical conventions, and I proofread both documents for a second time. I made some corrections, updates, and included references to the datasheets. Find the final files below. The second three hours were in the lab working with Jeremy on getting communication between the DU Freescale processor and the S1D. We verified that the external S1D oscillator was functioning properly by first trying to put a probe above a trace, but this yielded no signal (even no minor one). Since this result was similar for the DU microprocessor's oscillator, we risked putting the probe directly to a capacitor pin right off the oscillator, and this showed us that it was oscillating. Jeremy determined some puzzling experimental data that indicated that the oscillator was only functioning at odd times and in response to certain signals, indicating that something was getting through to the S1D at least. Much of my time was spent converting the WAIT_L pin to an input, but I believe that this pin was damaged by making it a microcontroller output since it should have actually been driven by the S1D.

FILES:
[1] HW 9: Software Architecture (doc)
[2] HW 10: Patent Liability Analysis (doc)

March 29, 2006 (4.5 hours): Jeremy got the DU microcontroller talking to the S1D yesterday, so today I tried hooking up the LCD which requires an additional -22V line. I very carefully verified the signals leaving the S1D, then I attached the LCD ribbon cable to our zero-force connector on the bottom of our board. After verifying -20V (the max our current supply can produce), I connected this to the proper pin. The display very briefly only flickered on, and the signals going to the LCD were still OK. I then tested the direct pins on the LCD itself and verified them, except that the -22V line was actually only -12V. A contrast circuit involving a potentiometer controlled the voltage to the LCD. I adjusted this a bit, and a transistor smoked (but the display turned on showing garbage, which it should!). I soldered a new one on.

WEEK 11 SUMMARY
Accomplishments: LCD appears to work! Completed homeworks 9 and 10. Can now program the DU microcontroller (in fact, the entire DU board appears functional).
Weekly Work Total: 18.0 hours
Project Work Total: 135.5 hours

Week 12

April 3, 2006 (11.5 hours):


The major accomplishments of today were getting the LCD displaying graphics and text, precisely positioning graphics and text, getting SPI to work (between the EIU and DU), and rendering a menu system which reacts to button press messages from the EIU. Regarding the contrast control transistor which smoked a few days ago, we determined there was a problem with the circuit design and that the transistor essentially shorted after the burn out. Hence, after looking at the schematic we noted the correct voltage was being applied to the LCD and that we didn't really need a contrast control at the moment (we don't believe the current is harmful either since we limit it). So, we're leaving the broken part on the board at the moment.

We currently operate in a combined graphics and text mode. The text memory begins at 0x0000 (1200 bytes) and the gfx memory begins at 0x1000 (9600 bytes). It's one bit per pixel (one byte per char) and one byte is shifted in at once (8 pixels). The two displays are ORed together. I wrote graphics code which can precisely render to the screen, for instance which writes an 8-pixel by 8-pixel border around the display. To test the arbitrary text string renderer, I made a string bounce around the screen. Tonight's work goes a long way toward satisfying our PSSCs.

We believe the external oscillator should be connected to the DU, and that this is affecting the display update rate (~6-7 seconds per graphics mode screen refresh, ~1 second for a text screen refresh). The DU is currently polling (as is the EIU), so this will need to be updated to an interrupt-driven architecture. The LED backlighting needs to be figured out which will require Thomas's and Mat's help since they designed the circuit -- the LCD display is currently a bit hard to read, as you can see above. A new development environment was created (picture in next post to come) since it was very error-prone which power supply to connect to which wire.

April 3, 2006 (2.5 hours): I put some final touches on the menu/SPI interfacing demo today. It appears that in CodeWarrior I can't compile a program with arrays declared with more than around 50 bytes. This could be very problematic should we decide to render the text characters ourselves. It also appears that if we store lots of memory statically (even if subdivided amongst several compliant arrays), the microprocessor doesn't respond correctly. The exact reason for this is still unclear, but the only way I was able to store a full screenful of text in the HC08 was to manually make calls to my disp_string routine with the strings inside the functions, not merely POINTERS to the strings in the functions (since this requires the memory declared statically). Today I displayed a screen of text initially, modified the menu display to only clear half of the screen per refresh, and fixed a bug where the menu selected stars are displayed initially the first time the menu is drawn. Tomorrow is the design review.

April 6, 2006 (4.5 hours): Jeremy and I tried to get USB code running properly on the Cypress microcontroller. Unfortunately, the code appeared to hang in several places, and we do not have a development board for the Cypress. So, we toggled port pins at various places and commented out portions of the code to see what the effect would be. The programming process involves disconnecting the new 64K RAM, plugging it into our Dataman, programming it, then putting it back in-circuit. We realized that function calls were not working (specifically, returning from them) so we hypothesized the stack was damaged. We discovered it was not damaged at the very beginning (indicating the loader is likely OK), but that something in-between hinders it. We are currently trying to run their 50K sample code, so it is a bit odd that it isn't working correctly. A lot of trial-and-error is ahead. I'll be gone this weekend on a trip, so this is my last entry for the week.

WEEK 12 SUMMARY
Accomplishments: Some headway on the USB Cypress software (though minimal), SPI interfacing works, LCD text and graphics rendering works. One of the most successful weeks yet!
Weekly Work Total: 18.5 hours
Project Work Total: 154.0 hours

Week 13

April 11, 2006 (4.0 hours): I updated the DU firmware to facilitate debugging and helped Jeremy get the USB and SPI code running on the Cypress. For the DU, I disabled the graphics layer so we wouldn't have to waste time clearing it (this unfortunately didn't seem to work). I also sent a logic 1 to the LED backlighting LED_ENABLE instead of the prior floating value. Further, I displayed the number of menu items on the LCD now so we can see whether the correct number is being sent via SPI. For the Cypress, calling some functions resulted in it going into reset (making it restart uselessly). These appear to involve setting memory at invalid addresses, but we tried commenting out various combinations of code to see how far it gets. More work will be done on this tomorrow, as it is a very slow debugging process since we can only set port pins. Tomorrow I'll continue these efforts. The LCD also emitted orange light and hummed after a while, and we discovered that the FRAME trace on the zero-force connector had been torn simply because the connector is unavoidably contorted in unsafe ways (this is how it came packaged). So, Mat soldered a wire directly from our LCD viewing header to the LCD, bypassing the connector.

April 12, 2006 (11.5 hours): I began by fixing a bug on the DU which did not disable the LCD graphics screen -- I changed the comment the other day but not the actual code, resulting in the screen not being cleared! I spent the rest of the time debugging the EIU ... we think there's an issue with the external SRAM. We reinforced some connections and it appears connected correctly, but we are having memory problems which are not predicted through software. To debug this, I wrote a program which resides in the 16K of RAM on the Cypress chip. It then attempts to write to the SRAM memory either by: (1) declaring an array which would force the memory to extend into the SRAM, and (2) by direct pointer access. The direct access only works if I write a value then immediately read it (perhaps due to a write-back cache?!) but not if I write all values then read them all. (1) works for small arrays (<= ~200 elements?). For larger ones, it always exits at the first element -- again, due to a cache perhaps, or maybe because we actually transition to the SRAM from the internal RAM once the array gets to a certain size. I was stuck for a few hours not being able to write a program to the Cypress which executed properly (in fact it seemed to execute old code). This was because the starting address must be 0x00001000 in the wrap command line program (but perhaps this is different in the msc example?).

There were some interesting effects from the memory program. First, if I write to a location in SRAM via a direct pointer then immediately afterward read from it, it works. However, if I write many values then read them, the very first value is incorrectly read. Second, if I declare an array of large size, we assume it's placed in the SRAM since the 16K internal wouldn't have room for it. I print out a counter value i when reading it to the oscilloscope in binary. It seems that if my array is large enough, the upper eight bits of i stick at one, even if I do no memory checking! If the array allocated is small enough, this stickiness never occurs. If it is of moderate size, I actually obtained three different results. First, it is displayed normally, then as stuck, then as nothing, altering between the three with each reset (cyclically). In short, this is very confusing data which I will resume obtaining tomorrow.

April 15, 2006 (4.0 hours): I decided to convert the DU to an interrupt-driven architecture tonight. This is primarily useful due to the need for detecting SPI signals from the EIU quickly. Previous tests have indicated that even *function calls* can take too long to respond to an SPI request (since the EIU sends them so quickly/blindly). Another possible approach to mitigate this is to have the DU respond to each EIU byte-request.

Jeremy made important progress on the EIU earlier today, but unfortunately SPI did not appear to work any longer once I started. Frustrated, I tried jostling the boards to no avail. Knowing that Jeremy had left with his code working, I tried reprogramming the EIU EEPROM to the same effect -- button presses did not result in EIU messages. Since SPI was integral to my interrupt testing, I tried to debug the EIU. Only having general-purpose output pins for debugging, I slowly determined that the cause of the problem was the first memset statement. From prior troubles, we found that this indicates the SRAM is improperly working. Hence, the same problem of before that Jeremy said he fixed was back! I prettied up the DU code, but could do little else.

April 16, 2006 (11.0 hours): This morning, I again tried to get the EIU running as it had just yesterday. Unfortunately, this resulted in me blowing an EIU logic fuse, probably because I switched power on quickly, resulting in a current spike (although this effect has not happened in the past). Not wanting to cause further damage, I set the board aside and set up the DU code for interrupts. I also started improving the menu system to have menus appear centered in the screen with a border and inverse text for the current selection. Further, I determined that a PWM for the backlights is not available since we accidentally assigned the LCD ENABLE pin to port E instead of port D. I also added another message handler to the DU and revised the code architecture substantially to make it easier to read (i.e. put all SED routines in a similar location with the SED prefix).

Next, I verified resistor values and connections on the power circuit. Jeremy came in and repaired the fuse (I had originally thought it was a nearby capacitor but this was not the case). Thomas came in, briefed me further on the power circuit, then we both verified that the regulator was working correctly, producing a 3.3V line. The other half of the LTC chip in charge of battery recharging, however, did not provide current to spec for a proper recharge. Thomas hypothesized this may have been due to the LTC, so since the chip was small we asked Jeremy to replace it.

Jeremy tried the EIU circuit and it worked fine, to my surprise. He got a directory listing from the USB thumbdrive (a PSSC)! Determined to complete the SPI interrupts, I stayed once he left since it now worked. Unfortunately as before, when I attempted to run it, it again did not work at all! The code loaded from the chip but no SPI messages were sent. This time, I left, suspecting the same cause.

WEEK 13 SUMMARY
Accomplishments: New DU code fixes memory bound problems and SPI and menus, EIU diagnoses, as a group we completed 4/5 PSSCs!
Weekly Work Total: 30.5 hours
Project Work Total: 184.5 hours

Week 14

April 17, 2006 (12.0 hours): During the morning I again revised the DU code and enhanced the new menu functionality. Before, we encountered a problem with declaring arrays larger than ~60 bytes in that no code would run if this occurred. So, this time I tried making them global variables, but for a while many of my globals became oddly corrupted in program areas which do not modify memory. After several hours, I found that the stack was colliding with poorly-placed by the linker single byte global variables. I only allocated 1400 bytes, but we had 2K of SRAM. Poking around, I found that the stack only took up ~140 bytes max, so I increased this since it was overflowing. The code then worked, enabling us to store an entire screenful in the DU's SRAM.

In addition, I got code running today which formats this text in raw form to fit nicely on the display. Today when Jeremy came in, the SPI again was not working from last night. So, the previous night I turned on the power supply and then inserted each cable individually, being very careful not to disturb anything from the setup which just worked less than an hour prior. After much testing, Jeremy determined the SRAM lines were bad (it was most likely hardware problems), so he replaced the SRAM, cleaned it up, and it appeared to work fine after that. This was our last SRAM, however, and we needed it for our new board. The LTC was replaced as well, and unfortunately it did not help the power circuit.

Since the EIU was now sending signals, Jeremy and I used my new code to receive signals from it. A bug which took a while to find was simply my code left over from trying to enable interrupts. I tried many things -- using start-up code generated by the IDE, inserting my own interrupt vectors, and using mnemonics in the PGM file -- but none ran a simple interrupt I was testing. So, a bug preventing us from polling interrupts was that I had simply enabled them earlier, disallowing polling. After getting my code running, I retired for the night.

April 18, 2006 (5.0 hours):



Tonight I modified the DU code to ready for a demo tomorrow featuring virtually all of our iReader functionality (except for the power circuit). My main goals for tonight were to render a splash screen at startup and to render real lines instead of text characters around menus. I worked with Mat to get the splash screen ready. He wrote a script which converted a 320x240 RAW bitmap into an C array of bytes. I originally thought the "Special Edition" Codewarrior compiler we were given only supported software up to 16K -- at 9600 bytes per screen, our splash would overtake this. I also designed a logo based on Jeremy's text splash screen. I generated it in Paint Shop Pro, using the program's 1-bit color converter with dithering in addition to its ability to export to RAW (uncompressed, no header). We got the splash screen working. I worked for a while trying to turn off the graphics layer since that is immediate as opposed to waiting for a screen refresh, but it didn't work correctly with the OR/XOR ops the LCD Controller supported with the text layer. Finally, I got pretty far on the line rendering code, but was unable to finish at a reasonable hour (Jeremy got them working later, saying the only problem was naming a global variable incorrectly).

FILES: [1] iReader source logo (psp)

April 20, 2006 (4.0 hours): Tonight I worked with Thomas on the power circuit. I had some great insights and ideas tonight, and we actually managed to discover a subtle miswiring on the PCB board, possibly resolving the problems we've been having for the last week with the battery recharging. Thomas and Mat were the main teammates working on the circuit, but tonight I was able to provide some new ideas which Thomas hadn't thought of. For instance, I indicated some tests we could perform to test whether the malfunctioning charging circuit was in trickle charge mode and a second test which would determine whether it was triggering a voltage underflow. It turned out we were triggering a periodic voltage underflow signal which was resetting the charging circuit! From this, Thomas discovered that the MOSFET drivers were suddenly stopping periodically, causing a dip in the incoming voltage, triggering the voltage underflow signal. This was caused by a dip in the voltage across the Isense resistor which controls the MOSFET drivers. I found two places in the datasheet indicating that two pins should be tied to the same ground. After looking at the PCB, Thomas determined they were not, and that he in fact accidentally swapped two leads on the Isense resistor. It was getting late and some difficult flywiring had to be done, so we're waiting until tomorrow to test it. We have high hopes that this is the source of the battery recharging dilemma!

April 21, 2006 (3.5 hours): Jeremy called me announcing that the BDM programmer didn't seem to work and that he suspected the S1D3700 chip was bad. We looked into ordering a replacement which would cost us ~$60.00 due to overnight shipping. Seeing that we could order it by 9:00pm to have it arrive the next day, we began debugging the problem. We found that if we rebooted the computer, the BDM Multilink would work again, magically. Thomas and Mat were in today as well, and they assembled our power circuit after we discovered the problem last night. They verified that it worked correctly, meaning that we have now met all of our success criteria! I had to leave early, but my partners continued to record a video for our PSSC demonstration.

WEEK 14 SUMMARY
Accomplishments: All PSSCs working + a video of them! Aesthetic improvements to the DU code, power circuit problem remedied, created new graphical 1-bit iReader logo.
Weekly Work Total: 24.5 hours
Project Work Total: 209.0 hours

Week 15

April 24, 2006 (5.5 hours): Today I mostly spent writing half of the user manual and also helping Jeremy with the EIU code. Jeremy was trying to get the battery gauge messages to stop interfering with other messages sent. This led to problems with the iReader not recognizing some button presses and also misreading some battery guage messages, despite handshaking (or perhaps due to a faulty implementation). I plugged in the chip for programming each time (a rather involved procedure now that it's in-circuit) and tried to give some useful ideas. Jeremy ended up making a menu option for the fuel gauge instead of an always-on philosophy.

April 26, 2006 (3.0 hours): Thomas accidentally plugged in the power lines backward (they are labeled with red and black wires, in addition to the PCB labeled with + and -). It appeared that voltages and currents were too high, so we replaced several of the components -- including a transistor and the LTC. We then realized that the voltmeter we were using was low on batteries and reading 10% higher than it should so everything was in fact normal. With the chip replacements, however, we found that our signals were not as noisy as before!

April 27, 2006 (3.5 hours): I came in this afternoon to install the hinges. I tried several designs, including the double hinge (two hinges with a common half-hinge glued together). I also tried using solid corner brackets. In the end, the iReader is so tall that the hinge cannot properly span it -- hence, the best design possible with those hinges seems to be one where the unit does not open or close all the way. But, this is rather minor since the gap is not too large. Thomas and Mat came in tonight with me and we finished the packaging for tomorrow's 270 presentation. We'll retape the PSSCs with this new packaging later, but for now we only verified that the display would be visible with the "digital imaging" camera used for the presentation. I also created the 270 bonus presentation tonight.

FILES:
(1) ECE 270 Bonus Presentation

April 28, 2006 (3.0 hours): I finished the User Manual today (or it is at least in an almost-finished form). I also presented our 270 Bonus Presentation today.

FILES:
(1) Homework 13 (doc)

WEEK 15 SUMMARY
Accomplishments: Worked on packaging, the final documentation, and circuit debugging -- the end product works and looks nice.
Weekly Work Total: 15.0 hours
Project Work Total: 224.0 hours

Week 16

April 29, 2006 (6.5 hours): I met with my group in lab to shoot the final PSSC videos with our new packaging, to clean our station, and to create the poster and divy up workloads. Tonight, I finished the website, wrote the senior design semester report, and wrote my portions of the final report.

April 30, 2006 (4.5 hours): I finished up every single homework and the final report. Everyone emailed me their edited documents so I included them, changed the references, did some editing, and added the missing final report sections. I also got everything ready to be printed and submitted tomorrow.

WEEK 16 SUMMARY
Accomplishments: Documentation, and hence the project, is pretty much complete!
Weekly Work Total: 11.0 hours
Project Work Total: 235.0 hours