There is an application note byt Atmel AVR415 that deals will using an AVR as an intelligent RC5 IR transmitter.

The code will not be directly useable but the application note might help.

http://www.atmel.com/dyn/products/app_notes.asp?family_id=607

Look for Application note 415

Another possibility (instead of an interrupt or fast polling) is to use something like a 555 in one shot mode to trigger a fixed duration pulse.  This pulse could be 100-200 milliseconds long.  Depending on your preference you could trade software complexity for hardware complexity.

I moved the arduino-0007 from the C:\ to C:\Program Files and the IDE found the new libraries.  Not sure what could have caused this behavior.

I don't think it is a permission issue.  I have Win XP home edition on both machines.  I don't have user accounts setup for either machine.  The only permission/security I have installed is firewall software that is setup the same on both machines.

The machine that it worked on is a DELL E310 Desktop.  The machine that it didn't work on is a DELL INSPIRON 1501 Laptop.

When I get a chance this week I plan to remove the arduino installation from the laptop and reinstall it under the Program Files directory structure.  I'll let you know if it works.

This was the only version of Arduino installed on this machine.  The file extensions were .cpp and .h (lowercase) respectively.  The standard libraries show up but neither the Test or my Camera library.  Neither the Test or my Camera library is compiled (no .o object files).

On another data point I installed the arduino software on another computer and copied the Camera library into the appropriate directory and it shows up in the arduino IDE.  The only difference is that on this computer I installed the arduino software into the C:\Program Files directory.  This is the standard install location for Windows software but since the arduino used a different install mechanism I didn't place it here on the other machine.

I wonder if the Windows version of the arduino software has the C:\Program Files  hard coded as part of the root path?

Anyway I have a work around.  Thanks for the help.

I am having a problem creating a new library--or getting the IDE to recognize the Test library from the Hacking/Libraries page.

I have created a directory in C:\arduino-0007\lib\targets\libraries\Camera  that contains a Camera.cpp, Camera.h, and keywords.txt

I have also extracted the Test.zip sample library to the same path (C:\arduino-0007\lib\targets\libraries\Test)

When I start the Arduino IDE (even after a reboot) and Goto Sketch/Import Library neither library shows up.

Am I missing something?

Here is what I would try.

1. Disconnect the board from all additional hardware (resisters, LEDs, etc...)
2. Try external programming software that Arduino uses (AVRDUDE?) to program new sketch.
3. Try AVRDUDE to reprogram chip with bootloader.
4. Purchase new preprogrammed ATmega168

Can't think of anything else to try.

>No no no! Thats not the problem at all. I have allready gone through that issue. You didn't read my entire post, did you?

Please take this as constructive criticism.  

Remember that by virtue of being open source all of the help offered on this board is free of charge.  That means that people respond with a greater or lesser degrees of time to give.  Daniel (who is one of the major contributors here) didn't deserve such a rebuke.

Use PINB to read the values of the pins.  PORTB is used to write the values

There are a couple of things to keep in mind when developing electronics for an automotive environment.

The power supply and long signal lines are subject to a great deal of electrical noise--which can cause intermittent hard to diagnose problems.

Second there is a great deal of vibration which requires that all devices have a solid mechanical as well as electrical connections.

If your project works well on the bench but problems appear in the car then one (or both) of these two areas are the likely source of the problem.

One terminal app that I can recommend (it was designed to facilitate communication with microcontrollers) is Brays Terminal.  

http://www.smileymicros.com/download/term20040714.zip?&MNM_position=42:42

Here is a suggested change that gets rid of the floating point math and replaces the if then statements with a switch case structure.  This compiles to 4320 bytes

Code:

int number = 0;
int number2 = 0;
int var = 0;
int val = 0;
long temp = 0;

void setup() {
  //Inizializzo i pin come uscite
  for(int i=2; i<6; i++) {
    pinMode(i, OUTPUT);
    pinMode(i+7, OUTPUT);
  }
}

// 9 10 11 12 || 9 10 11 12
void loop()
{
  switch (number) {
   case 0:
    digitalWrite(9, LOW);
    digitalWrite(12, LOW);
    digitalWrite(11, LOW);
    digitalWrite(10, LOW);
    break;
   case 1:
    digitalWrite(9, HIGH);
    digitalWrite(12, LOW);
    digitalWrite(11, LOW);
    digitalWrite(10, LOW);
    break;
   case 2:
    digitalWrite(9, LOW);
    digitalWrite(12, HIGH);
    digitalWrite(11, LOW);
    digitalWrite(10, LOW);
    break;
   case 3:
    digitalWrite(9, HIGH);
    digitalWrite(12, HIGH);
    digitalWrite(11, LOW);
    digitalWrite(10, LOW);
    break;
   case 4:
    digitalWrite(9, LOW);
    digitalWrite(12, LOW);
    digitalWrite(11, HIGH);
    digitalWrite(10, LOW);
    break;
   case 5:
    digitalWrite(9, HIGH);
    digitalWrite(12, LOW);
    digitalWrite(11, HIGH);
    digitalWrite(10, LOW);
    break;
   case 6:
    digitalWrite(9, LOW);
    digitalWrite(12, HIGH);
    digitalWrite(11, HIGH);
    digitalWrite(10, LOW);
    break;
   case 7:
    digitalWrite(9, HIGH);
    digitalWrite(12, HIGH);
    digitalWrite(11, HIGH);
    digitalWrite(10, LOW);
    break;
   case 8:
    digitalWrite(9, LOW);
    digitalWrite(12, LOW);
    digitalWrite(11, LOW);
    digitalWrite(10, HIGH);
    break;
   case 9:
    digitalWrite(9, HIGH);
    digitalWrite(12, LOW);
    digitalWrite(11, LOW);
    digitalWrite(10, HIGH);
  }
  
  switch (number2) {
   case 0:
    digitalWrite(2, LOW);
    digitalWrite(5, LOW);
    digitalWrite(4, LOW);
    digitalWrite(3, LOW);
    break;
   case 1:
    digitalWrite(2, HIGH);
    digitalWrite(5, LOW);
    digitalWrite(4, LOW);
    digitalWrite(3, LOW);
    break;
   case 2:
    digitalWrite(2, LOW);
    digitalWrite(5, HIGH);
    digitalWrite(4, LOW);
    digitalWrite(3, LOW);
    break;
   case 3:
    digitalWrite(2, HIGH);
    digitalWrite(5, HIGH);
    digitalWrite(4, LOW);
    digitalWrite(3, LOW);
    break;
   case 4:
    digitalWrite(2, LOW);
    digitalWrite(5, LOW);
    digitalWrite(4, HIGH);
    digitalWrite(3, LOW);
    break;
   case 5:
    digitalWrite(2, HIGH);
    digitalWrite(5, LOW);
    digitalWrite(4, HIGH);
    digitalWrite(3, LOW);
    break;
   case 6:
    digitalWrite(2, LOW);
    digitalWrite(5, HIGH);
    digitalWrite(4, HIGH);
    digitalWrite(3, LOW);
    break;
   case 7:
    digitalWrite(2, HIGH);
    digitalWrite(5, HIGH);
    digitalWrite(4, HIGH);
    digitalWrite(3, LOW);
    break;
   case 8:
    digitalWrite(2, LOW);
    digitalWrite(5, LOW);
    digitalWrite(4, LOW);
    digitalWrite(3, HIGH);
    break;
   case 9:
    digitalWrite(2, HIGH);
    digitalWrite(5, LOW);
    digitalWrite(4, LOW);
    digitalWrite(3, HIGH);
  }
  delay(1000); // waits for 1000 milli seconds
  val = analogRead(5);
  //temp = (val * (5.0/1024.0)) / 0.01;
  temp = (val * 5 * 100) / 1024;
  var = temp * 1000;
  if((var % 1000) > 500) {
    temp++;
  }
  temp += 2;
  number = temp / 10;
  number2 = temp - (number * 10);
}
 

I had the same problem using an AVRISP mk2 to program an ATMega8 with the AVRstudio software.

After checking with the folks on AVRFREAKS.NET is was suggested to check the ISP clock frequency in the AVR Studio software.  It seems that for the AVRISP mkII it defaults to something like 8,000Hz and this doesn't work.  If you change the frequency to something between 1 and 4 MHZ it should work--at least it did for me.

When you check the fuse/protection bits with this setup.  If they won't accept changes you'll need to do a complete chip erase and try again.

Note that in my case it showed the same symptoms on the clock line because in the first attempt to program the SW/HW reprogrammed the fuses to use an internal clock!

To one of the site administrators.  It sounds like it would be a good idea to make this or the original thread "sticky" so that it stays up top in the forum.

Just a suggestion!

Even when you calculate the power consumption from the data sheets you still need to measure the actual circuits on the bench (and maybe even under the field).

A while back I built a small data collector that was to be deployed in a remote location.  I did the calculations, built the circuit and measured it on the bench and ended up measuring a current demand about 50% higher than calculated.  Further when the application was deployed, I discovered the current demand was higher yet further the small solar panel produced less than expected.

Moral:Nothing can compete with test, measure, and repeat!

If you are looking to do this as a learning exercise--then disregard this message.  Have fun, it will be a great project.

However, if you are doing this to save money then I would strongly suggest you reconsider.  There are multitudes of commercial solutions that perform these operations.  The vast majority of which can be purchased for less the the cost of getting set up to develop this hardware--not counting the time involved.  You could easily get what you looking for for less than $200 and possibly less than $100 if your frugal and spend some time.

Some of the low end mini-itx motherboards have these features and can be had for $100-$150 with a foot print of 7" x 7".  I believe the waysmall brand controllers can implement these (video would be SVGA) and are smaller than a pack of cigerettes.