That still requires a wireless access point.  The WiShield, as far as I can tell, can not give out dhcp addresses and automatically have the web browser go to a page.

I am not sure I could achieve what I want with ad hoc.

True.  I'm just looking at my options.

If the bluetooth arduino wasn't so expensive I would go that route.

I just read how the auto-reset works.  That might be a possibility.  I wonder if the command line stuff supports that.

Thanks for giving me a place to start.  I will be looking into this.

I am making an LED controller for my motorcycle.  I plan on hooking up the arduino to a fonera router running dd-wrt.  I am going to set it up so anyone can connect to the AP and control the colors of the LEDs through a web server on the fonera.  

Because of this if I make a new program with different LED fades and such it would be nice to upload the program without taking the arduino out.  I plan on putting the arduino in the fairing so taking the fairing apart each time would be annoying.

I have a thought on this.  Does the arduino software have a command line interface?  If not I suppose I could look into adding it.

I am looking at connecting an arduin to a fon router though the serial port.  In theory I could install the arduino software on a fon with dd-wrt.  If the arduino software has a command line interface I could could make a web page to up load a program and then program the arduino.

Doesn't the serial interfaced used to upload a program to the arduino the same as a couple of the pin available?  If so how does the arduino know the difference between uploading code and program communications?

The playground page for Timer1 says "Note that this breaks analogWrite() for digital pins 9 and 10 on Arduino."  Digital write and read would still work for those pins though, correct?

I get that also.  But if I wait abit and try again I get the following errors.
avrdude: stk500_getsync(): not in sync: resp=0x00
avrdude: stk500_disable(): protocol error, expect=0x14, resp=0x51

You don't need an arduino for that.  There are several VU meter ICs out there.  Most work with line out - which I am not sure what a car stereo would have.  Line out is not an amplified signal.  To do a spectrum analyzer you will have to look into different filters.  High pass, low pass, and band pass I believe.

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

I assume that fast spi library works and solves the issues you mentioned.  I haven't been around my project yet to try the library.  But it seems like it must work as the example code is bliptronic's code converted to using the library.

I get what you are saying.  It is the same reason you suggested to me to blank the TLC5947 before sending data - to reset the PWM cycle.

So, assuming the library is keeping track of where the beginning of the PWM cycle is - hardware wise does my idea work?  Because the idea could be applied to other hardware, not just LEDs.

I wish there was a datasheet on that IC that was in english.

This is a software and hardware interfacing question, but I am going to start with the hardware first.

I am using the bliptronic (lpd6803) leds in my project.

Looking at bliptronic's example code the timer simulates a single clock cycle, correct?  That means the LEDs are getting updated rather slowly.  Then I found the fast spi library for them.  However, I am already using an SPI device with cable select in my project.  So that means I would have to add a CS - also modify the library to use it, but that is the next step.

To add CS to the LEDs would it be as simple as to hook up a transistor to the the CS pin and between the MOSI arduino pin and data pin on the LEDs?  Or does it need to be a relay?


http://code.google.com/p/fastspi/

Related project to give you ideas.

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

Reply 27 and 28 I have details on my current progress.

Instead of using RBG LEDS you can use bright whites.

FYI, here's a video of the code.

I gave that modification to the code a shot.  Wow, that worked perfectly.  Well, there's a slight flicker but I only see it in my side vision.

So this?  I'm not a hardware guy, I'm a programmer.  Most of what you said didn't make sense.


void LEDDriver::SetLatch()
{
  digitalWrite(blank_pin, HIGH);
  digitalWrite(latch_pin, HIGH);
  delay(1);
  digitalWrite(blank_pin, LOW);
  digitalWrite(latch_pin, LOW);
}

I created a LEDDriver class.  I have some #ifdefs in the code for testing.  When I compile using XCode I define TESTING.  This enables code that outputs data to a file for debugging on the PC before uploading to the arduino.  Befor eI upload to the arduino I undefine TESTING so that code won't execute.

I based the code off the tlc5947's datasheet and the octobright code.  It contains two arrays: temp_data[NUM_PINS] and led_data[NUM_PINS].  led_data gets pushed out to the tlc.  temp_data gets pushed to led_data if it is different than led_data.  This way I am not pushing led_data to the tlc if I don't need to.

LEDDriver.h

Code:

#ifndef LEDDriver_H
#define LEDDriver_H

#include <stdint.h>
#include "led_config.h"

#ifdef TESTING
#include <iostream>  //remove for AVR
#include <fstream>
using namespace std;
#endif

class LEDDriver
{
  public:
    LEDDriver();
    ~LEDDriver();
      
    void SetPins(uint8_t pClock_pin, uint8_t pData_pin, uint8_t pBlank_pin, uint8_t pLatch_pin);
            
    void Update();  //this should set pLED_data to tempLedData, then compare with led_data to see if need to update.
                //if need to update then update led_data and SetLatch().  This will minimize flickering.  Only latch if needed.
      
    void SetClock();
    void SetLatch();
            
    void BlankToggle();
    void ClearLEDS();
            
    void SetLED(uint16_t led, uint16_t red, uint16_t green, uint16_t blue);
            
  private:
#ifdef TESTING
    ofstream fp_out;
#endif

    uint16_t temp_data[NUM_PINS];
    uint16_t led_data[NUM_PINS];
            
    uint8_t blank_status;
            
    uint8_t clock_pin;
    uint8_t data_pin;
    uint8_t blank_pin;
    uint8_t latch_pin;
      
    void _WriteChannel(uint16_t value);
    void _UpdateLEDS();
};
#endif

LEDDriver.cpp

Code:

#include "led_config.h"
#include "LEDDriver.h"

#include "wiring.h"
#include "HardwareSerial.h"

#ifdef TESTING
#include <iostream>  //remove for AVR
#include <fstream>

using namespace std;
#endif

LEDDriver::LEDDriver()
{
  blank_status = LOW;
#ifdef TESTING
  fp_out.open("myfile.txt");
#endif
}

LEDDriver::~LEDDriver()
{
#ifdef TESTING
  fp_out.close();
#endif
}

void LEDDriver::SetPins(uint8_t pClock_pin, uint8_t pData_pin, uint8_t pBlank_pin, uint8_t pLatch_pin)
{
  clock_pin = pClock_pin;
  data_pin = pData_pin;
  blank_pin = pBlank_pin;
  latch_pin = pLatch_pin;
}

void LEDDriver::Update()
{
  //compare with led_data to see if need to update.
  //if need to update then update led_data and SetLatch().  This will minimize flickering.  Only latch if needed.
  uint8_t updateleds = 0;
  int i = 0;
      
  //Check if we need updating first TODO
  //The function shoudl transfer tempData if needed
      
  for(i = (NUM_PINS - 1); i >= 0; i--)
  {
    if(led_data[i] != temp_data[i])
    {
      updateleds++;
      led_data[i] = temp_data[i];
    }
  }
      
  //Check if leds need to be updates then push the update
  if(updateleds > 0)
  {
#ifdef TESTING
    fp_out << "  Update " << endl;
#endif
#ifdef SERIAL_DEBUG
    Serial.println(" Update ");
#endif
    _UpdateLEDS();
    SetLatch();
  }
#ifdef TESTING
  else
  {
    fp_out << "  No update " << endl;
  }
      
  for(i = (NUM_PINS - 1); i >= 0; i--)
  {
    fp_out << "l " << i << ": " << led_data[i] << endl;
  }
  fp_out << flush;
#endif
}

void LEDDriver::SetClock()
{
  digitalWrite(clock_pin, HIGH);
  digitalWrite(clock_pin, LOW);
}

void LEDDriver::SetLatch()
{
  digitalWrite(latch_pin, HIGH);
  delay(1);
  digitalWrite(latch_pin, LOW);
}

void LEDDriver::ClearLEDS()
{
  for(int i = (NUM_PINS - 1); i >= 0; i--)
  {
    temp_data[i] = 0;
  }
}


void LEDDriver::BlankToggle()
{
  if(blank_status == LOW)
  {
    blank_status = HIGH;
   }
  else
  {
    blank_status = LOW;
  }
}

void LEDDriver::SetLED(uint16_t led, uint16_t red, uint16_t green, uint16_t blue)
{
  temp_data[(led*PINS_PER_LED)+RED] = red;
  temp_data[(led*PINS_PER_LED)+GREEN] = green;
  temp_data[(led*PINS_PER_LED)+BLUE] = blue;
}

void LEDDriver::_WriteChannel(uint16_t value)
{
  int bit;
      
  // Write value, MSB first
  for (bit=11; bit>=0; --bit)
  {
    if (value & (1<<bit))
    {
      digitalWrite(data_pin, HIGH);
    }
    else
    {
      digitalWrite(data_pin, LOW);
    }
            
    // We need to wait 30ns after writing data before clocking it in.
    // Fortunately, our AVR is slow enough that we don't need to
    // do an explicit wait here
    digitalWrite(clock_pin, HIGH);
    digitalWrite(clock_pin, LOW);
    }
}


void LEDDriver::_UpdateLEDS()
{
  //Check if we need updating first TODO
  //The function should transfer tempData if needed
  for(int i = (NUM_PINS - 1); i >= 0; i--)
  {
    _WriteChannel(led_data[i]);

#ifdef SERIAL_DEBUG
     Serial.print("write led pin ");
    Serial.print(i);
    Serial.print(": ");
    Serial.println(led_data[i]);
#endif
            
#ifdef TESTING
    fp_out << "write led pin " << i << ": " << led_data[i] << endl;
    fp_out << flush;
#endif
  }
  SetClock();
}