linux kernel module problems

make -C /lib/modules/2.6.20-15-generic/build M=/home/santiago/pctxDriver/helloTest modules
make[1]: Entering directory `/usr/src/linux-headers-2.6.20-15-generic'
scripts/Makefile.build:17: /home/santiago/pctxDriver/helloTest/Makefile: No such file or directory
make[2]: *** No rule to make target `/home/santiago/pctxDriver/helloTest/Makefile'. Stop.
make[1]: *** [_module_/home/santiago/pctxDriver/helloTest] Error 2
make[1]: Leaving directory `/usr/src/linux-headers-2.6.20-15-generic'
make: *** [all] Error 2

The problem with this is that although Ubuntu Makefiles maybe named makefile, the kernel subsystem is looking for a makefile by the name of Makefile. In other words capitalization does matter.

Sonar update

Well I'm working on multi-plexing the sonars and I have it working to some extent. I can't send a signal to both and read the results separately without adding some transistors. What was happening was I had everything connected to a bus, so even though I was trying to read one sensor, the signal was being transferred through the bus to the other sensors. This information is only useful to me as a reminder.

SRF02 arduino address confusion

Well, I've been looking over the code from Tom Igoe for the Devantech SRF02 sonar based on arduino

http://www.tigoe.net/pcomp/code/category/code/arduinowiring/39

Well even though it worked right off the bat, I was terribly confused why the address for the SRF02 sensor was 0x70 instead of 0xE0 as it was in the Basic Stamp example I used.

Well aparently the I2C address standard only works from 0 to 127 the LSB is used for read / write so the 0xE0 becomes 0x70 for the address of the chip. I found the answer here

http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1205634009/3

more sonar

I've realized that only the SDA pins are messed up on my "green" and "orange" sonars. So I was able to reuse the same SCL pin and just have the SDA pins connected to different pins. So instead of the original 2 pins used up I now have 3. Better than having to get new sonar. Unfortunately, I think they can still only transmit. Have to also re-solder green one.

own sonar

I'm using this site as an example

http://www.micro-examples.com/public/microex-navig/doc/090-ultrasonic-ranger.html

while testing it I'm reminding myself that I have to use a 33k resistor

SRF02

I found out the problem with the SRF02 modules. Somehow during my dealings with them, the boards seem to have shorted. They won't turn on if the SDA and SCL on the green and orange ones are plugged in. I found this out by using software I2C and changing the SDA and SCL pins for them. The orange and green modules can both ping but not receive data. I'm going to try and create my own sonar modules as I only have to calculate time in microseconds between them.

ATTINY13 DAPA cable half duplex uart

I've been recently messing around with learning to code in AVR, or more specifically learn why serial isn't working. I think I have it down to the fact that the default mode for the ATTINY13 is 9.6 MHz and that the frequency is off somehow compared to the half duplex software serial offered by Atmel, I'm going to order an 8Mhz oscillator and see if that fixes it, I"ll also order some 16Mhz oscillators for my arduino projects. Sometimes I like things to work easily.

While I was trying to get the serial to work right, my chip seemed to stop working, like I couldn't reprogram it with the DAPA cable. I went back and downloaded a new Makefile from a tutorial and I made the necessary changes I had previously made. The one that got it to work again was to uncomment
AVRDUDE_FLAGS += -E noreset
this allowed the program to run with the DAPA cable still attached

Player stage

I had problems installing player stage on Ubuntu, specifically stage, the solution was to include a few extra libraries, mainly


>$sudo apt-get install libgtk2.0-dev libltdl3-dev libboost-dev libboost-signals-dev libboost-thread-dev libssl0.9.7