Show Posts
Pages: 1 ... 14 15 [16]
226  Forum 2005-2010 (read only) / Frequently-Asked Questions / Re: Using Arduino as a uart on: March 17, 2009, 01:27:55 pm
Well I misread your original post a little and thought you had a clock signal for your data line. In that case you'd put the interrupt on the clock pin and read the data pin state at clock transitions.

If you're using sychronous serial without a clock line, how do you expect to sychronize the transmitter/receiver? With async serial you get the advantage of a start/stop bit to get things in sync. Sychronous serial assumes the transmitter and receiver are "in sync" some way and mutually know when the bit boundaries occur.
227  Forum 2005-2010 (read only) / Frequently-Asked Questions / Re: Using Arduino as a uart on: March 17, 2009, 01:05:49 pm
I believe the data is sent somewhat synchronously in that the code hands the characters off to the hardware UART and then waits for the send to complete, etc.

Regardless, you should be using interrupts to monitor the data pin state. Then you won't have to worry about the critical timing.
228  Forum 2005-2010 (read only) / Frequently-Asked Questions / Re: Most Wanted Shield on: March 16, 2009, 10:32:22 am
A multi-channel UART shield.

Incorporate a dedicated multi-channel hardware UART that could be accessible via I2C, SPI or serial shift. Just for fun, throw on a few MAX232's for optional RS232 level connections.
229  Forum 2005-2010 (read only) / Frequently-Asked Questions / Re: Scrounge List on: March 09, 2009, 10:31:09 pm
Quote
I can scan those containers at a rate of 10 per second!

Sounds like it's time to cut back on the beans just a little.  :o
230  Forum 2005-2010 (read only) / Frequently-Asked Questions / Re: ARGGGGGG.... Servos... on: February 20, 2009, 10:16:10 pm
Are you sure you have the accelerometer connected to analog pin 3 and not digital pin 3?

If so, put some debugging in to check the values coming out of your accelerometer.  
231  Forum 2005-2010 (read only) / Frequently-Asked Questions / Re: Long term running of an Arduino (years) on: February 10, 2009, 04:29:09 pm
I've had an Arduino-based ATmega168 running an RFID garage door entry system for over a year now.  It's been rock-solid even when the outside temperature was -10F.

One of the key things to remember is that a programmed chip starts running its program on power-up (after a short bootloader delay).  So even if you have a power outage or some other kind of "reset", your device should automatically return to a functional state.  The only exception to this would be time-critical or real-time types of needs.  In this case your biggest concern is power stability, not the ATmega168.
232  Forum 2005-2010 (read only) / Frequently-Asked Questions / Re: Read out of DS1621 on: January 05, 2008, 10:30:16 pm
The bit shift is because the TWI library only wants the 7 most significant bits of the device address passed as a byte.  Yes, it's confusing.

The TWI library then left-shifts what you supply and OR's a 0 or 1 in bit0 to specify a read/write operation.

You can see this happening in the source code for the Wire library.  In Wire.cpp and twi.c:

Code:
Wire.cpp:

void TwoWire::begin(uint8_t address)
{
  twi_setAddress(address);
  twi_attachSlaveTxEvent(onRequestService);
  twi_attachSlaveRxEvent(onReceiveService);
  begin();
}

twi.cpp:

void twi_setAddress(uint8_t address)
{
  // set twi slave address (skip over TWGCE bit)
  TWAR = address << 1;
}


233  Forum 2005-2010 (read only) / Frequently-Asked Questions / Re: Turning an Arduino into a programmer on: June 02, 2007, 07:56:53 pm
Okay...

I downloaded -0008 from the CVS and after some debugging in the make.sh, I finally got it to Arduino-0008 to compile.  Once I had that running, the Programmer2 code compiled without any problems.

So I downloaded it to my Arduino board, breadboarded up another ATMega168 with its own crystal (16MHz) and powered it from my Arduino board.  I wired up the LEDs and control lines as documented.  Then I gave it a try...

Well the LEDs flashed as expected, but none of the commands would work.  The Probe_Device() function was failing to identify the ATMega168.    Well, I take that back.  On one or two rare occasions (out of dozens), the *p command returned the correct data (which led my thinking towards a signal timing issue - see below).  I double checked all of the connections and everything seemed correct.  I even put an already programmed chip in my breadboard (with a blink LED program) to confirm that I had the ATMega168 wired up properly and the oscillator was running.  It worked fine so I knew my circuit was good.

So next I started digging into the code and put some debugging in the Send_ISP function.  I was seeing discrepencies on received data.  The echo back of the first byte through MISO when sending the second byte was not matching.  The echo back of the second byte when sending the third seemed to be okay.  Then I tore into the Atmel datasheet and focused on the serial programming docs.  What ended up solving my problem was loosening up the timing of the RESET pin in the SeizeTarget() function.  I think the timing was just too quick and the 4 microsecond blip high was not enough to get the chip in program mode.  Also the 21ms delay after bringing the RESET line back low is dangerously close to the 20ms minimum recommended by the datasheet.  Overall I couldn't see any real reason to no give the RESET transitions lots of time.

Here's the revised SeizeTarget() function that works consistently for me.  The timings are probably excessive, but it's only an extra 50ms or so on command start and seems to give consistent results.

Code:
static void SeizeTarget()
{
  digitalWrite(SCK,0);
  pinMode(SCK,OUTPUT);
  pinMode(MISO,INPUT);
  pinMode(MOSI,OUTPUT);
  digitalWrite(RESET,0);
  pinMode(RESET,OUTPUT);
  delay(10);               /* Let the RESET line settle low
  //delayMicroseconds(4);
  digitalWrite(RESET,1);
  delay(10);               /* "Blip" the RESET line high for 10ms
  //delayMicroseconds(4);
  digitalWrite(RESET,0);   /* Bring the RESET line back low
  delay(50);               /* Wait 50ms before sending command
  CMD_Program_Enable();
  targetSeized = 1;
  digitalWrite(ERR_LED,0);
  digitalWrite(GOOD_LED,0);
}

So with this change in place, everything is working perfectly.  Thanks for developing this code.  It allowed me to use some spare parts and a simple circuit to load the bootloader onto blank ATMega168's without having to buy an expensive programmer.
234  Forum 2005-2010 (read only) / Frequently-Asked Questions / Re: Turning an Arduino into a programmer on: June 01, 2007, 06:50:35 pm
I'd love to give this a try but unfortunately the code won't compile (Arduino NG w/ATMega168).

The code includes the header "pins_arduino.h" which I can't seem to find anywhere.  I even tried googling for it with no luck.

Also, your page in the playground doesn't detail which input the "turn this chip into an arduino chip" button should be connected to.

Edit: I'm using Arduino-0007 on OSX.  I found a "pins_arduino.h" in the CVS so I'm guessing that you developed for Arduino-0008?
Pages: 1 ... 14 15 [16]