2009-12-27: Implemented i2c with bit banging.
            Got an ACK from the M24C04 EEPROM chip, yay.

2009-12-20->26: Spent lots of time with the saleae-logic-libusb project.

2009-12-19: I hate the PIC's bank selection 'feature'.

            Todo items:
              - Time the delay loops using the Logic

2009-12-18/19: Found a nice i2c temperatur sensor device [1] which seemed like
            a nice complete solution for the temperature sensor. Ran into a few
            issues though:

              - The PIC cpu I have does not have the hardware to implement i2c
                master, only slave. This was a real surprise as I didn't think
                any vendor would differenciate between slave and master
                implementations.
              - The i2c device is a 5V part while the rest of the system is
                3.3V. As I also got a 5V regulator that might be fixable.
              - The i2c devicse is also in a SOP-8 package which is a SMD
                package and I have no SMD solder tip nor a proper board to
                solder it on. Made a nasty hack with some tape and soldered
                the wrires directly onto the device. I have no idea if I've
                burned the device or if it'll work at all.

            I found an application node from Microchip which implement the bus
            master in software [2], and I've gotten it all to build. Turns out
            to be a very useful problem for my new logic analyzer.

            [1]: LM75 Digital Temperature Sensor and Thermal Watchdog with
                 Two-Wire Interface 
            [2]: Microchip AN554: "Software Implementation of I2C Bus Master"

2009-12-11: Finally got the "Logic" logic analyzer and got it working on my Mac
            with the beta software. No protocol analyzers yet, but I've become
            a human protocol analyzer :) I'm baffeled by the simplicity and
            elegance of the hardware and software. Technology has definitely
            improved since I last used a logic analyzer 15 years ago.

            I tried to build the SDK that's included so I could 1) dump the
            output to a GTKWave file for analysis and 2) write my own small
            protocol analyzer, but I was unable to compile it. I think I need
            to install XCode again.

2009-12-09/12: Worked on a bug in the checksum, implemented SLIP.
            Had to implement lots of C code to fully understand how the 8 bit
            additions has to be done with carries and all. A major pain in the
            ass, and I'm still not sure if it covers all cases or not.

            Split out the chksum method into checksum.h/c and created a
            chksum_test.c to run it through a set of test cases.

            Properly implementing a function to write out SLIP-encoded bytes
            which seems to work. Implemented read_slip.c to decode the SLIP
            stream. Should perhaps split out the generic SLIP stuff from the
            IP/ICMP specific parts, but I really don't care now.

2009-12-07: Managed to create a working ICMP ECHO request:

$ tcpdump -n -vvv -xx -XX -e -r serial.pcap
reading from file serial.pcap, link-type SLIP (SLIP)
22:28:02.879307 O 40.00.00.00.00.00.00.00.00.00.00.00.00.00.00: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 28) 10.1.1.76 > 10.1.1.1: ICMP echo request, id 1, seq 2, length 8
        0x0000:  0140 0000 0000 0000 0000 0000 0000 0000  .@..............
        0x0010:  4500 001c 0000 4000 4001 2493 0a01 014c  E.....@.@.$....L
        0x0020:  0a01 0101 0800 f7fc 0001 0002            ............

            Starting to use more macros, created a few useful shortcuts: MOVFF,
            MOVLF which definitely make the code more readable.

            I should probably wrap some of the debug output in pre-processor
            #ifdefs or something smart. There's a few bits of debug serial
            output which would be nice to be able to turn on/off while
            assembling instead of commenting stuff in and out.

            As a side note, I wonder if IPMI is just too big to bother to
            implement on the PIC16. I've scanned through the IPMI specification
            document and it seems quite doable if you have enough time on your
            hands. I think I'll go with a custom UDP message, perhaps
            SNMP-style. For future reference, here are the IPMI spec
            documents:

             - http://www.intel.com/design/servers/ipmi/spec.htm
             - http://download.intel.com/design/servers/ipmi/IPMIv2_0rev1_0.pdf

            Another side note, perhaps I should read the older but much simpler
            IPMI 1.5 specs to see if they're sufficient.

            I should move on to the SLIP interface now by properly escaping
            outgoing bytes. I think I'll have to implement CTS/RTS support in
            the serial interface too. I wonder how I should integrate all of
            this with the reading of the packets. I guess a read-answer loop
            should be sufficient.

2009-12-06: YEAH! I own IP checksum. This was a helpful tool even if very hard
            to understand at times: http://www.netfor2.com/checksum.html

2009-12-03: (small) VICTORY! Found the bug in the checksum calculator (missed an
            INC FSR while iterating in 16 bit increments). Made lots of test
            code for the checksum, should be easy to get the rest done now.

2009-11-30: Spent an evening on trying to get the IP checksum method to work. No
            go so far.

2009-11-29: Made big progress today:
             - Got the PIC to write me a complete IP package header, without
               checksum.

$ tcpdump -n -vvv -xx -XX -e -r tcpdump/serial.pcap
reading from file tcpdump/serial.pcap, link-type SLIP (SLIP)
16:43:47.352056 O 40.00.00.00.00.00.00.00.00.00.00.00.00.00.00: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 20, bad cksum 0 (->355)!) 193.168.90.66 > 193.168.90.1: [|icmp]
        0x0000:  0140 0000 0000 0000 0000 0000 0000 0000  .@..............
        0x0010:  4500 0014 0000 4000 4001 0000 c1a8 5a42  E.....@.@.....ZB
        0x0020:  c1a8 5a01                                ..Z.

             - Divided up the assembly file into several (more or less)
               standalone .inc files. Should make it a bit easier to naviate
               the source code.

            Found one issue with the USB serial cable. It'll buffer lots of
            bytes which may or may not be junk, but it certainly is not the
            bytes you want! I have to pull the usb cable and insert it again
            before each capture to get the latest bytes from the device. Since
            I have virtually not error checking in my capture code I've seen
            a few "bus error" messages today.

            Defined coding standards:

             - Method internal symbols starts with "_". Makes it easier to not
               get confused between public and "private" symbols.
             - The labels of methods and variables both start with a small
               letter. This makes it easier to see them in the listing.
             - Include libraries at the end of the assembly file. Each include
               file should define the variables they need in a CBLOCK.

2009-11-28: VICTORY II! Hand crafted a SLIP packet containing an ICMP ECHO 
            reply message. Now that I have all the bytes required, time to
            get the PIC to do the work!

$ tcpdump -n -vvv -xx -XX -e -r tcpdump/out.pcap 
reading from file tcpdump/out.pcap, link-type SLIP (SLIP)
22:38:09.053778 O 40.00.90.fc.f9.ff.bf.98.f9.ff.bf.38.f9.ff.bf: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 28) 192.168.90.66 > 192.168.90.1: ICMP echo request, id 20, seq 10, length 8
        0x0000:  0140 0090 fcf9 ffbf 98f9 ffbf 38f9 ffbf  .@..........8...
        0x0010:  4500 001c 0000 4000 4001 054d c0a8 5a42  E.....@.@..M..ZB
        0x0020:  c0a8 5a01 0800 f7e1 0014 000a            ..Z.........

            VICTORY! Serial communication is working. Wired up the MAX232 and
            used another usb-serial dongle that I had lying around. Noticed
            that I had bought 0.1uF capacitors instead of the 1.0uF capacitors
            the MAX232 requires, but it still worked. I'll replace the MAX232
            with a MAX232A.

            Having a well defined project statement makes it easier for me to 
            focus so here it is:

              Implement a card that will read the current temperature and
              communicate over Ethernet using IPMI.

            This is a big goal so I've broken it up a bit:

             - Learn IP by sending characters over a serial line using SLIP. 

               This requires way less hardware on the board and other 
               hardware/software components.

               Part goals:
                * Transmit characters over a serial line
                * Use interrupts to wait while transmitting the characters
                * Send a single SLIP package containing an ICMP EHCO reply

             - Control the ADC

               Part goals:
                * Read a value from the ADC
                * Adjust the read value from the ADC with the NTC's coefficients

             - Learn how to etch my own PCB cards

2009-11-25: Spend an evening trying to read the serial data through the TTL-232R
            usb-to-serial thingy but couldn't get it to work. I think my
            oscillioscope is broken.

            Tried different power sources to make sure I understand how
            everything work. Realized that my PIC part is a low-voltage part,
            but I have a 5V serial cable.

2009-11-24: First serial character written to pin, seen on oscilloscope.
            Realized that the PIC was running on 8MHz.

2009-11-23: Portet test-2 to work on the new chip
