Current Status

• Fri Jun 11 13:57:50 PDT 2004
  We are done... for now
• Thu Jun 10 17:11:18 PDT 2004
  Working on the final draft of the paper. All hardware was done yesterday. We borrowed a nice computer for the demo from bruceh. Still to do: make example PD patch for the demo, test demo for tomorrow, print brochure, bundle code.
• Wed Jun 9 15:31:45 PDT 2004
  Finalized the Brochure.
• Wed Jun 9 12:53:16 PDT 2004
  We got the SPI code working, so we now have the buttons on a different atmega16,this atmega sends data over spi to another atmega which forwards the data to the serial port. The ADC and encoders are running on the atmega connected to the serial (RS232) and the buttons are connected to the atmega with the SPI interface. We are also working on our paper, we hope to get our full rough draft done by today, and edit it tommorow.
• Tue Jun 8 22:35:48 PDT 2004
  We have writen and tested SPI on the atmega16, but we have yet to integrate it into our final RTMC code. We tested some bugs that we found in the hardware for the buttons.
• Mon Jun 7 17:00:41 PDT 2004
  So we're having lots of problems with the TWI. As time is running out, we've decided to try to use the SPI interface and see how that works.
• Mon Jun 7 16:34:28 PDT 2004
  We have the TWI partially working, we're having problems sending stop conditions. It seems that if we send stop conditions that eventually the TWI stops working, but if we just send a lot of data, with no start/stop between data bytes, it works fine.
• Mon Jun 7 15:16:04 PDT 2004
  we have been working a lot on the TWI/I2C and the hardware of our project and we have a cool form factor constructed.
• Thu Jun 3 14:42:01 PDT 2004
  We got the buttons working, So now all we have to do is the TWI, which has been hard for us, we still don't have it working.
• Wed Jun 2 16:31:19 PDT 2004
  wrote button code and alex fixed it. buttons work.
• Wed Jun 2 09:59:08 PDT 2004
  reading about SPI/Microwire and the rtl8019as ethernet controller. added a gif to the www site. writing the button interface code.
• Mon May 31 20:41:47 PDT 2004
  Worked on paper rough draft and presentation slides.
• Sun May 30 12:32:14 PDT 2004
  Updated the todo.html page.
• Thu May 27 13:52:30 PDT 2004
  finished a good encoder interface that works with 4 encoders to a port. started building a keyboard form factor.
• Thu May 27 13:46:25 PDT 2004
  Karl got the encoders working nicely, Alex changed the program that runs on the IPS so that one can define the ip and port to send OSC messages to.
• Wed May 26 16:28:46 PDT 2004
  Added a handeler for buttons and encoders to the rtmcsendOSC code (the code that builds osc packets from information sent to it by the atmega16). I had to re-solder some sliders as the solder joints broke. I also created a .tex file for our paper and commited that to the cvs repository under the name "paper"
• Wed May 26 14:52:45 PDT 2004
  Worked on the Brochure some.
• Mon May 25 20:55:00 PDT 2004
  finished the code for the twi master. still need to test twi.
• Mon May 24 20:53:16 PDT 2004
  i read about the TWI/I2C for most of the morning. i finished writing the test code for a slave and i started writing the test code for a master.
• Mon May 24 19:03:43 PDT 2004
  I modularized the adc code and created a "final" cvs module, where we'll put alized code. I also started soldering 8 sliders to a proto board.
• Mon May 24 14:12:58 PDT 2004
  Alex got the roundtrip calcuations for atmega16--(serial)-->PC_1--(ethernet)-->PC_2--(ethernet)-->PC_1--(serial)-->atmega16 working. I have it all written down, it looks like it's around 9ms average (round trip).
• Thu May 20 16:20:05 PDT 2004
  Alex wrote a atmega16 program and a program that runs on the IPS to test the round trip latency of a byte sent from the atmega->IPS->atmega. I took a bunch of data values, seems that the average is around 6ms (round trip). I assume that this is probably similar to the time it would take to send the data atmega-(serial)->IPS--(ethernet)->PC but I am unsure. I'll attempt to calculate the round trip time of atmega->IPS->PC->IPS->atmega (serial)(ethernet)(ethernet)(serial) tommorow. While this won't give us exact values of latency, it will give us a rough estimate (and it's probably the best that we can do besides learning how the parallel port works and flopping pins there,, but we don't know anything about the latency of writing to the parallel port.
• Wed May 19 16:51:14 PDT 2004
  Wrote up a rough draft of the brochure, linked it to the webpage. We found that we can get latencies through our laptop ((266Mhz) of 40ms, this is unexceptable, but may be beyond our control as it seems like it is a problem of the OS and audio drivers, though we are still not sure. Tommorow we will test the latency of the serial connection and the ethernet connection.
• Tue May 18 20:31:51 PDT 2004
  we spent most of today scratching our heads thinking of how to test our system to figure out where the 600ms delay comes from. we tryed using the lab pc as the OSC client (running pd and listening for messages). that set-up had a 60ms delay--the same as the best case delay with the laptop as a client (is that right alex?) . Alex got a good idea toward the end of the day. that was to write some 'echo' programs that would let us measure round trip times. the results will be part of our update2.html. karl spent the morning learning more about the ps2 mouse interface and mice behaviour. tomorrow we will test our system with a powerbook as the client and we'll write some round trip time tests to get at the heart of the latency issues.
• Mon May 17 16:58:14 PDT 2004
  We did lots of tests and measurements today. From our mesurements our best case latency out of the atmel (from data on the adc) is .5 ms and our worst case (with all the other sliders moving) is 4 ms, this is awsome. We are seeing LARGE latencies through the computer (from 64ms to 604ms), but this is not due to our hardware, it is due to stuff on computer's end (ie OS, audio drivers, USB, PURE DATA.....).
• Sat May 15 16:41:38 PDT 2004
  Changed the boot sequence on our laptop such that you may reboot and not have to manually run dhclient. Also put and extra interface in /etc/network/interfaces (eth0:1 192.168.0.1) so that we can telnet to the EEAVR.
• Sat May 15 16:01:58 PDT 2004
  Wrote the beginings of a ps2 mouse driver (mouse_cmd_test.c). Right now it just receives the start-up (reset) messages from the mouse which are 0xAA and 0x00 and forwards them via serial to a computer. The next task is to _write_ a message to the mouse. The message 0xF4 (Enable Data Reporting) makes the mouse start sending updates--right now it just sits and does nothing at all.
• Sat May 15 13:55:58 PDT 2004
  wrote a (pre) rough draft brochure and posted it on our page.
• Sat May 15 12:22:53 PDT 2004
  wrote a perl script (bin/calc_baud) that, given a clock frequency and a serial device, will calculate a table of available baud rates and the UBRR for that rate. the results are congruent with those in the ATmega16 datasheet, but the script can calculate for any clock frequency and it tells you the error and whether the computer can do the baud rate.
• Fri May 14 09:55:40 PDT 2004
  added stuff about me to the "About the group members." section of this www site.
• Wed May 12 14:12:05 PDT 2004
  Karl wrote a draft encoder interface that seems to work well. researching mouse/hd ps2 interface.
• Wed May 12 10:25:01 PDT 2004
  I've written a C program that takes (serial) messages from the atmega and makes OSC packets out of them, and sends them over the network. It will be easy to extend this to allow for additional handelers (for different types of incoming data) to be written, also a table could be made that would define mappings of incoming serial messages to outgoing OSC messages.
• Mon May 10 14:11:39 PDT 2004
  looking over the easyethernet code. It is very messy. I see that it uses the usart to communicate with the ethernet adapter, so we cannot use that .
• Mon May 10 13:33:17 PDT 2004
  I'm attempting to fix up the serial_send function so that data is buffered, so that we don't block for too long when sending serial data. I'm having trouble getting the interrupts short.
• Sat May 8 18:07:15 PDT 2004
  Distressed a few hard drive platters. Changed this page to be 'newest first'.
• Fri May 7 17:00:01 PDT 2004
  We took data on all the different types of inputs, found that the mechanical encoders must be sampled at 1kHz, the sliders must be sampled at 6.4kHz, and the optical mouse interface we don't know. We found that with a 16MHz crystal and an ADC prescaler (divider) of 16, the ADC clock will run at 1MHz and that means that the ADC sample rate is about 62.6kHz, but the ADC must be shared by 8 sliders (time multiplexed) so the effective sample rate for any slider is 7.8kHz (just about right). It is also worth noting that with this ADC setup our ADC interrupt takes about 12% of the CPU time. We hope to get this number lower by rewriting the interrupt in asm.
• Fri May 7 10:57:03 PDT 2004
  Karl arrived at 9am. Three main todos: Take input constraints data, write encoder test interface, clean workbench. Also, rewrite update script. Cleaning is done.
• Thu May 6 16:44:57 PDT 2004
  We installed debian on my computer, had to install a bunch of programs again: Pure-data, OSC, some add ons to Pure Data, snd..... but it looks like everything is working very well. I've added 4 more sliders to our breadboard, connected them into our previous code, works great.
• Thu May 6 15:47:43 PDT 2004
  Alex got his laptop from home, so now we have a compiler and programmer. Karl drilled some holes in a Speak and Spell (his specialty) and now we have 4 mounted buttons and 2 mounted mechanical encoders. They all plug into the stk500 programmer with a DB-9 connector. Alex mounted 8 sliders on a proto-board, they are sweet.
• Thu May 6 10:30:01 PDT 2004
  Our laptop just crashed! The machine that we do all our programing on is now totally dead. We need a solution quick. Also, our optical mice arrived.
• Wed May 5 19:21:13 PDT 2004
  I added the new sliders we got, just put 4 on a board for now. I also tried using a different power supply for the sliders. That didn't fix the problem. It turned out that the ADMUX (mux for the ADC) was being changed too soon before a conversion was started, so I just added a tiny spin loop after the ADMUX is changed and it fixed the problem. There is probably a more elegant way to do this. I'm wondering now if I need this extra power supply or not? I also spent a long time trying to figure out these new sliders, the data sheet and the numbers on the slider itself are wrong, so we had to figure that out ourselves... I tested the sliders out, using them with some PD insturments, they work great.
• Wed May 5 15:17:44 PDT 2004
  Alex is here now. We will do stuff.
• Wed May 5 14:30:19 PDT 2004
  Some of the parts came. Good and bad. The sliders are slippery (good), but they are PCB/Solder mount type (bad; cannot be screwed down). The M-encoders are very high friction (bad), but they are nut mountable (good). The buttons are okay. Also, the multiplexors came. Still waiting for the Easy Ethernet AVR and the optical mice.
• Wed May 5 13:52:42 PDT 2004
  Changed the name of the perl script because 'update-status' was long. Now it is named 'update'. Also, did a bunch of research into optical mouse sensors. They are all made by Agilent, but many do not have "public" datasheets. Agilent will only make public the datasheet for a part that it sells to the public. If they make a part 'special' for, say, logitech, the datasheet for that part will not be made public. This means that we need an older mouse that uses a 'public' part like the H2001.
• Wed May 5 11:17:26 PDT 2004
  Wrote a perl script that lets you update this page from the command line. It is in the project directory (bin/update-status). It is *not* pretty. However, it does work. We found that the reason that we were having trouble with the Intel Personal Server is that it automatically reboots over and over--once the login prompt appears, the thing goes down. Here is a log http://www.cs.washington.edu/education/courses/477/04sp/projectwebs/cse477l/ips-boot-log.txt
• Tue May 4 18:00:39 PDT 2004
  Connected 6 sliders to the atmega16. Ran a little test that checks to see if the slider gives a value greater than 127, if so it lights a corresponding LED. Then I wrote some code so that when the atmega16 detects a change in a slider, it sends the data out over the serial port (with an index value). The setup is buggy right now. Some sliders cause values for other sliders to change, but I figure this could be due to the slider set up drawing too much power, more than the project board can give it, or more than the pin that we've connected to can. But I'm not sure.
• Tue May 4 11:10:10 PDT 2004
  Karl wrote a little perl prototype program that opens the serial device (in Linux) and reads and interrprets chars, turning them into OSC packets. Alex merged the ATmega16 code (Serial + ADC) into a program that sends the state of a fader to the linux box via the serial device. "We got a hardware slider to control a sound in pd!" --Alex
• Mon May 3 19:16:53 PDT 2004
  bruceh@cs says that all our parts are ordered and on their way. We are having alot of trouble logging into our personal server. It seems that a lot of people have this trouble--their network accessibility is very, very unreliable.
• Mon May 3 17:23:49 PDT 2004
  got serial working (just in a raw way, not using the library). Calculated that we can do 250k Baud over serial with a 16Mhz crystal and very little error. Today we also figured out that we can put a crystal onto the stk500 programmer (so we're up to 16Mhz instead of 3 Mhz or something). We're sending ascii to hyperterminal running on a windows machine. It looks like the OS or the hardware on that box doesn't support 250k serial so we cannot test to see if that works, but 57600 baud serial communication works nicely.
  One problem is that the ADC test that we did seem to break when we move up to a 16Mhz clock.
• Mon May 3 14:18:08 PDT 2004
  set up a cvs repository in the group space.
• Mon May 3 11:06:46 PDT 2004
  Had our regular Monday meeting this morning at 11am. Agenda items were: formalize the division of labor, discuss the structure and design of the ATmega16 side code, finalize and submit the parts list, and set next meeting time.
• Sun May 2 21:23:51 PDT 2004
  Added optical mouse to parts list as well as 2-4 mechanical (rotary) encoders and three types of serial interface (i2c and spi) ADCs. Did hours of research to make sure to find stuff that is in stock and not too $$$. Added link to parts list to the main page. Spoke to Alex over the phone about the project.
  Look here for parts list
• Sun May 2 18:38:05 PDT 2004
  Tried to get a serial connection working with the poorly titled library "avrlib" (not to be confused with avrlibc). I can send data but it looks like garbage on the otherside. It seems likley that this has to do with the baud rate issues that Karl told me about. Going home now.
• Sun May 2 16:58:01 PDT 2004
  Got the ADC working (with interupts). Our problem was that we weren't making our global flags "volatile". Made a test program that reads data from the ADC and displays the value on the LEDs of the stk500. I used a slider and it looks nice.
• Sun May 2 09:54:42 PDT 2004
  Worked on final parts sheet, will submit on monday. Still need to add some i2c components on there.
• Sat May 1 12:44:06 PDT 2004
  Named the above mentioned program 'serial_test.c' and moved it to the www site under 'gather/'--it is not tested yet. 'gather.c' is what I figure we'll name the final program and each significant ATmega16 component that gather.c might use we'll test with a program named [component]_test.c (right now, I am working on adc_test.c). I cannot test anything until Monday. I am reading the ATmega16 datasheet pages 202-219 on the ADC. Also changed the www site to enable indexing of 'gather/' and 'datasheet/' directories.
• Fri Apr 30 17:30:37 PDT 2004
  Finished an ATmega16 program that writes 'i' chars over the serial interface.
• Fri Apr 30 14:42:53 PDT 2004
  Programmed the ATmega16 with a simple LED blinker. Wired the ATmega16 with a slider. Hooked up the stk500 RS-232 spare to the ATmega USART. Reading pages 142-170 of the ATmega16 datasheet to learn how to transmit over serial.
• Fri Apr 30 11:35:01 PDT 2004
  Karl is just back from California. Alex appears to be gone until Saturday as was planned. Current action items are: update this page, update "update1", work on micro-controller "control state gathering" program, wire proto-board to stk500 and test. One test program to be writen for the ATmega16 will just write byte pairs out the serial port every second or so--with this we could test the serial port and the "OSCbuild" program. Next, we'll write a prog. that lights an LED when a slider moves above a preset threshold.
• Wed Apr 28 10:06:14 PDT 2004
  Yesterday Karl gave the presentation, on monday we spent all of our time preparing for the presentation, working on the slides, getting our examples ready, making sure our senerio worked well (IE we tested it on other people). We also worked on the update, which we admittedly didn't give as much time as we should have since we were working on the presentation. Today is an off day as Karl is out of town and Alex must work on his graphics project.
• Mon Apr 26 13:13:08 PDT 2004
  We are working on our presentation, making power point slides. We are also working on our final parts list for submission. Last Friday we got the stk500 (early) and hooked it up to our Linux laptop. We have successfully programmed the Atmega16 from Linux and have been writing test code in an attempt to use the ADC to get data and then send it over a serial line. We wrote some simple code that had some bug we couldn't figure out, we're still working on this. The programmer works great though. It gives us access to all the I/O of the Atmega16 so we don't even have to remove the chip from the programmer. We have the programmer attached to our development board.
• Thu Apr 22 17:12:27 PDT 2004
  We have made several failed attempts to program the Atmega16 with uisp (under Linux). Bruce H will be ordering us an stk500 programmer that we can have on our bench. He will have it for us on Monday. We are currently collating our full parts list, and investigating serial communication with a PC. Preparing for the presentation.
• Wed Apr 21 18:48:54 PDT 2004
  We have made our parts list. We got around the issue of root access on a computer by securing our own laptop and installing Debian Linux. We've gotten sound working (we had to get an external sound device), we've installed all the necessary software (pure data (PD), avr-gcc, vim, snd....) and have written some basic example PD programs that will receive our OSC messages and use those to modify musical synthesis [for use in our demonstration next Tuesday]. We have set up a bread board with an Atmega16 and an rs232 port. Right now we're trying to put sliders on the Atmega16 and have that communicate serially with our laptop. First we'll just send raw data, but after we get that working we will formalize a scheme for the Atmega16 and IPS to communicate.