Show Posts
Pages: [1]
1  Using Arduino / Installation & Troubleshooting / Re: another avrdude: stk500_getsync(): not in sync: resp=0x00 problem on: November 26, 2013, 08:07:28 pm
Looks like I just fixed my problem, but I have no good explanation. 

I took another computer (win 7 64bit OS), which had 1.0.3 and tried to reproduce the problem.  At first it looked like it was happening again.  But then I uninstalled the Uno device in the device manager (making sure to check the box to delete the driver from the system), installed the new driver from 1.0.5, burned the bootloader with the AVR ISP from 1.0.5, and then plugged it back in and tested the blink example.  It worked. 

So then I went back to my original machine with the problem (win 7 32bit OS) and repeated the same process as above.  This is basically the same thing I tried at least 3 times before, but for seemingly no rhyme or reason, it worked this time. 

So, to fix this problem.  Spend an hour doing something.  Don't get mad.  Just turn off the computer.  Then come back 2 days later and try the same thing again.
2  Using Arduino / Installation & Troubleshooting / Re: another avrdude: stk500_getsync(): not in sync: resp=0x00 problem on: November 24, 2013, 08:53:58 pm
I'm having the same problem.  Everything was working at 1.0.3 and then I did the update just to do the update to 1.0.5.

Looks like a classic case of "if its not broken, don't fix it."... but I fixed it for no reason, so now its broken.  Didn't need to update for any reason.  Regretting it after an hour of messing with drivers, deleting hidden com ports, burning bootloaders, and testing on two different UNO's. 

If anyone did anything specific to fix this problem, please share.
3  Using Arduino / Sensors / Short SPI controlled DAC demo with MCP4921 on: November 03, 2013, 08:37:35 pm
I wanted to generate an analog signal so I read through several of the DAC solutions here.  I've used SPI commands before so the MCP4921 seemed like an easy solution. The demo's I read seemed like they were heavier than they needed to be just to teach someone how to generate a DAC signal.  They are good write ups, but I just wanted to do my own twist on it.  So here it is.

http://www.speedlimit88.com/arduino/adc2dac/

I wrote this up fairly quickly and will probably make updates.  Criticism welcome.

Quote from: code from the site
#include <SPI>
  const int chipSelectPin = 10;
  const int analogInPin = A0;
  int sensorValue = 0;
  int outputValue = 0;
  byte outputValueByte0 = 0;
  byte outputValueByte1 = 0;

  void setup()
{
     SPI.begin();
     SPI.setBitOrder(MSBFIRST);
     SPI.setClockDivider(SPI_CLOCK_DIV4);
     pinMode(chipSelectPin, OUTPUT);
     digitalWrite(chipSelectPin, HIGH);
  }

  void loop()
  {
     sensorValue = analogRead(analogInPin);
     outputValue = map(sensorValue, 0, 1023, 0, 4095);
     outputValueByte0 = byte(outputValue);
     outputValue = outputValue >> 8;
     outputValueByte1 = byte(outputValue | 0b00110000);

     digitalWrite(chipSelectPin, LOW);
     SPI.transfer(outputValueByte1);
     SPI.transfer(outputValueByte0);
     digitalWrite(chipSelectPin, HIGH);
  }
4  Products / Arduino Due / Re: DUE problem with micros() inside interrupts on: March 02, 2013, 02:31:12 pm
I just tested the code from my first post and noticed the same problem on a brand new DUE, so I don't think that my hardware is damaged.  Here are other things I have tested:

Using different pins - problem persists
Using RISING instead of FALLING - problem persists
Using CHANGE instead of FALLING - similar problem
Using higher and lower input frequencies - problem persists

I changed the code to only have a counter in the interrupt and it worked correctly, but that doesn't help me.  Here is the code:
Code:
volatile int counter = 0;

void setup() {
  Serial.begin(115200);
  attachInterrupt(2, FallEdge, FALLING);
}

void loop() {
  interrupts();
  if (counter >= 1)  {
    Serial.println(micros());
    counter = 0;
  }
}

void FallEdge(){
  counter++;
}

Then I moved the print statement out of the interrupt, but kept the micros() in the interrupt.  It still had the same problem.  Here is the code:
Code:
volatile unsigned long counter = 0;

void setup() {
  Serial.begin(115200);
  attachInterrupt(2, FallEdge, FALLING);
}

void loop() {
  interrupts();
  if (counter >= 1)  {
    Serial.println(counter);
    counter = 0;
  }
}

void FallEdge(){
  counter = micros();
}
5  Products / Arduino Due / Re: DUE problem with micros() inside interrupts on: February 11, 2013, 11:02:18 pm
Thanks for the idea.  That was what the original program was doing in the interrupt along with a little math.  Originally I wasn't using any serial commands.  I started to write this topic before I was totally done debugging and thats why the title doesn't exactly make sense for how I described it (forgot to change it).  At first I thought it was something specific to the micros() command, but when I realized the time stamps were happening only at a rising or falling edge it started making a little more sense... although it still doesn't make much sense to me.  Seems like something is busted.
6  Products / Arduino Due / Re: DUE problem with micros() inside interrupts on: February 10, 2013, 08:11:04 pm
At 490Hz the 0.5ms time to print shouldn't matter though.  Plenty of time to do it and move on, right?  I also tried a little less than 400Hz and had the same problem.  And actually, I noticed the problem without the serial commands.  The example code I posted is just the easiest way to demonstrate the problem.  The program I wrote worked fine on the UNO, but not on the DUE.  The only reason I need the DUE is that I need more memory than the UNO has available.
7  Products / Arduino Due / DUE problem with micros() inside interrupts on: February 10, 2013, 06:10:55 pm
Hi internet,

I have a project that is working refectly with an UNO but not so well with the DUE.  The problem seems to be that the interrupt type is changing or not working as expected.  I have an UNO generating a 490hz 50% PWM signal as the test input to pin 2 on the DUE.  I am using a Parallax oscilloscope to monitor the input signal and it is spot on.  Here is a simple piece of code I have loaded on the DUE that highlights the fault:
Code:
void setup() {
  Serial.begin(115200);
  attachInterrupt(2, FallEdge, FALLING);
}

void loop() {
  interrupts();
}

void FallEdge(){
  Serial.println(micros());
}
If I open the serial monitor, copy the output into a spreadsheet, write an equation to get the difference from one cell to the next ("=A2-A1") ... I can see that every 200 to 80 cycles it only reads about 1040 and then 3040 instead of 2040. It is not a consistent number of cycles from one error to the next. 

This seems like it is trigger on the rising edge instead of the falling edge once in a while, then ignoring a falling edge before going back to working off of falling edges.  I have the circuit protected with a 3.0V zener diode and fed in through a 1kohm resistor so that it doesn't get the UNO's 5V peak output.  Again, on the oscilloscope it looks solid, 3.0V.

As a check on the hardware I also used a frequency generator set at about 3.3v and removed my resistance/zener circuit protection entirely.  I am using Arduino IDE 1.5.2, had the same problem with previous release, 1.5.1r2.

Can someone else setup the same test and verify my sanity?  Has anyone else seen any problems with the interrupts on the DUE?
Pages: [1]