In case you didn't notice, I found the camera. I took some photos this morning and spent some time updating my website so that I can add easy thumbnails (I don't have to have separate images, they are resized with code). I'm trying to add photos next to previous information that talked about a particular subject, like the sketch of the prototype I did and putting the parts on the small breadboard.

Well, I ended up solving the problem with the DIP switches not being read. Apparently for PORT A (and some of PORT B), you have to set the pins to digital through the ADCON registers. After that, it ...

[img breadboard_small1.jpg||left]I wanted to upload some pictures of the progress so far, but when I searched for the camera I couldn't find it. Anyways, I went ahead and put the 18F2620 onto one of my small breadboards and added all the resistors necessary to run it. I also took the code and stripped it down to it's minimal function by removing LCD and LED test code, which brought it to around 750 bytes, which is quite small nowadays. I went ahead and tried it, but wasn't able to get any results with regards to SPI. I decided to separate my code and set it up for the 2 different chips, so I c...

[img proto1design.jpg||right]I went ahead and drew out a sketch of what I wanted to put onto the first prototype board. In this version, I will only be making 2 boards. One, which I already designed, will hold the USB port that will be extended from the Arduino for easy access and a set of 4 DIP switches. The second board will hold the PIC chip, pins for input from the receiver, and the MMC card. Originally, I was debating on whether to use the 28-pin PIC18F2620 or the 40-pin PIC18F4620, which would give me an additional 8-pin port, but upon seeing how little space I had to work with, I decide...

I ended up looking at I²C another time, but didn't have any better luck. It just seems to be a protocol that the 2 types of chips aren't able to communicate with. I have been going over the possibility of using the ATmega chip I'll be replacing from the arduino and transferring my algorithms for reading timing over to it, so it would be able to communicate better with the arduino, but it probably won't happen.

I ended up making a change to the prescaler of the timer on the PIC chip. I changed it from 1:1 to 1:8 because after that change, when I converter the values to decimal, I ended up with ...

[img dapa_adapter.jpg||left]I pretty much worked on learning about the hardware for Arduinos and various AVR chips yesterday. I built a parallel port adapter, known as a dapa (Direct AVR Parallel Access) type that connects to the arduino. I had a little trouble at first since I didn't realize the USB cable needed to be plugged in too at first, in order to provide power. After that, it worked fine. Another option for programming the ATmega chips is to use the arduino itself to transfer the code from the computer to a chip sitting on a breadboard. I'm not certain if the Arduino software sets fus...

I finished getting the autodetect function running, so now the chip has the basic program on it that I set out to do a few years ago. For auto detecting, I just looped through 32 times while waiting for the timer to count from 0 to 0xb000 and looked for activity on any pin. If it saw some, it was set as active by just running activeChannels |= PORTD each time. I also took my timing code and made it a little cleaner and more efficient. The entire program is around 1.5KB, though I have 16KB of total space I can use on the chip.I have been kicking around the idea of using the same chip to send ou...

Yesterday I got the code for transferring multibyte data via SPI working. I ended up using the first byte from the arduino to choose which channel I wanted to get data on, which stored the data on the PIC in a static variable, so I could get read multiple times without the number changing and then sending 0xff to get remaining bytes. It works quite well and I was considering setting it up so the first byte was a command, with subsequent bytes being data transferring back and forth. This would allow me to set the PIC up in different modes and allow it more capabilities than I had originally int...

I got my timer code working nicely. I originally kept losing the the high byte of the timer because even though I bitshifted, my timer variable was only 8 bits, so when I shifted the bits over, they would just fall off the undersized variable. As soon as I started reading into 16-bit variables, the problem went away. When I generated my algorithm, I had assumed that the signals for all 6 channels occurred simultaneously. However, upon hooking up 2 channels of my oscilloscope together I discovered they actually occur sequentially, so as soon as one channel ends, the next one starts. An easy way...

I started work on the timing coding. Unfortunately, at this point it's behaving a little erratically. I hooked my oscilloscope up and wasn't able to get any clear reading. So, I decided to try the receiver in the car itself and charged up the batteries overnight. This morning, I connected everything and when I tried to operate it, I had no response. I did notice the car twitched if I shut off the transmitter, so I was pretty sure it wasn't broken. After pulling out the manual, I went through the settings and found it was in QPCM (Quick Pulse Code Modulation) mode rather than PPM (Pulse Positio...

After a lot of fine tuning and tweaking, as of last night, I've finally been able to get the PIC and arduino to communicate without errors. I've noticed that occasionally one of the shift registers gets it's bits rotated on power-up, but a reset of the arduino seems to fix the problem. I'll still look into that so it can work reliably.

The next will be reading PWM values from the receiver. According to documentation and as I've seen on my oscilloscope, the times should vary between 1000-2000 microsecond pulses depending on the direction of the controls. My plan is to have a 16-bit timer consta...