Show Posts
Pages: [1] 2 3
1  Using Arduino / Programming Questions / Re: Confusing Behavior with 2D Array in Flash on: February 01, 2013, 04:36:38 pm
I would have to assume compiler optimization changed something.

That was my thought, but I'm not all that familiar with modifying compiler flags within the Arduino environment.  One time where I'd rather be using a "full fledged" IDE!
2  Using Arduino / Programming Questions / Re: Confusing Behavior with 2D Array in Flash on: February 01, 2013, 04:30:33 pm
Yeah, "i" was definitely 0, which is what was confusing me the most.  Oh well, I've got it working now, not quite as I thought it would look, but it's actually a lot more maintainable this way, so I'm ok with that!

Thanks for your help.
3  Using Arduino / Programming Questions / Re: Confusing Behavior with 2D Array in Flash on: February 01, 2013, 08:52:08 am
Ah, that's making more sense.  I've re-worked my code to just have the whole thing declared as a single 2D array because that's a little easier to understand at a quick glance.

One thing I'm still a bit confused on, if I used a hardcoded index it worked fine, but if I used a variable it failed.  Any thoughts on why that be?

For example, the following would fail:
Code:
Serial.print(pgm_read_byte(&(array[i][j])), DEC);

But this would print the correct data:
Code:
Serial.print(pgm_read_byte(&(array[0][j])), DEC);

I see why the code itself is wrong, but I don't understand why hardcoding the first index would allow it to work.  Obviously I'd rather just code this correctly, but I'd like to understand this better because it tripped me up for the better part of a day.

Thanks!
4  Using Arduino / Programming Questions / Re: Confusing Behavior with 2D Array in Flash on: January 31, 2013, 04:50:52 pm
Nick,

There's actually another identical set of arrays (same structure, different data) and then a much bigger 3D array as well.  This probably could all go in SRAM, but there's thought that this project could grow, and I'm trying to future proof it by just dumping all of the arrays into PROGMEM.  I copied this setup from the Arduino PROGMEM example, here: http://arduino.cc/en/Reference/PROGMEM.

One thought, would it work to have the Array of Arrays (aka, array of pointers) as a regular variable, but leave the longer Arrays in PROGMEM?  Like I said, I was just following the example as best I could so I assumed it was easier for everything to be PROGMEM, but now I'm not sure.

5  Using Arduino / Programming Questions / Confusing Behavior with 2D Array in Flash on: January 31, 2013, 03:37:17 pm
I'm seeing some confusing behavior with a 2D Array I've created in Flash (using the PROGMEM attribute).  First, some code:

Code:
// Macro to perform "sizeof" on PROGMEM Arrays
#define ELEM_CNT(x)                          (sizeof(x) / sizeof(x[0]))

// Individual Arrays
const byte a0[] PROGMEM = {0, 0, 1, 2, 3, 4, 5, 6};
const byte a1[] PROGMEM = {0, 0, 9, 8, 7, 6, 5, 4};
const byte a2[] PROGMEM = {0, 0, 5, 6, 7, 8, 9, 0};

// Array of arrays
const byte *arrays[] PROGMEM = {
  a0,
  a1,
  a2,
};

byte i,j;

for (i = 0; i < ELEM_CNT(arrays); i++)
  { 
    Serial.print("Array #");
    Serial.print(i, DEC);
    Serial.print(": ");
   
    for (j=0; j<8; j++)
    {
      Serial.print(pgm_read_byte(&(array[i][j])), DEC);
      Serial.print(" ");
    }
    Serial.println();
  }

Like this, I get gibberish in the serial output, like this:
Code:
Array #0: 0 0 251 193 0 0 249 193
Array #1: 2 3 4 5 6 1 2 3
Array #2: 2 3 4 5 6 1 2 3
But if I make one change, things work great...

Code:
// snippet from above with modification
for (i = 0; i < ELEM_CNT(arrays); i++)
  { 
    Serial.print("Array #");
    Serial.print(i, DEC);
    Serial.print(": ");
   
    for (j=0; j<8; j++)
    {
      if (i == 0)
        Serial.print(pgm_read_byte(&(array[i][j])), DEC);
      Serial.print(" ");
    }
    Serial.println();
  }

Output:
Code:
Array #0: 0 0 1 2 3 4 5 6
Array #1:         
Array #2:

Now with this, I get the expected output, with the obvious caveat of it only works for one case, which defeats the entire purpose of trying to make a 2D array in the first place.  Alternatively, I can just hardcode in a value for the first index (i) of the array and it works great, but as soon as I try to iterate over more than one index, it doesn't work.  I'm confuse by it because I don't see any obvious errors, especially since it works with a hardcoded value, but this is my first foray into the PROGMEM attribute, so I could just be missing something frustratingly obvious.  Any ideas?

Thanks!
6  Development / Suggestions for the Arduino Project / Re: pulseIn Bug on: January 14, 2012, 04:05:25 pm
100 mS, I must've missed a 0 when typing in the uSeconds.

I'm not sure I can actually post the code as it's not mine.
7  Development / Suggestions for the Arduino Project / Re: pulseIn Bug on: January 14, 2012, 08:25:30 am
Again, for those of you who doubt me, I ask you to try playing with this yourself.  As I've said, I'm pretty sure the voltage doesn't matter, a HIGH is anything over 3V.

The sketch was used for both images, some stuff may have changed elsewhere, but not this part.  Additionally, 6uS for digitalWrite is still fast enough that it pulseIn should be triggering properly, as there's at least 40 uS between pulses.

The only thing that changed, that I can find a difference for, is going from Arduino 1.0 back to Arduino 0021.  Again, I urge someone with more experience with the Arduino environment to regression test this.  If you're unwilling, well, that's kind of poor form.  If you're unable, at least say so.  If you're convinced I'm doing something wrong, I ask that you "prove it" to me by actually running a test.  I've done my testing, on several different Arduinos and found a workable, though unexplained solution.  The engineering side of me would love to know why there's a difference like this, but on the other hand, if the Arduino community doesn't seem to want to test this...I'm not going to waste any more of my time on it.
8  Development / Suggestions for the Arduino Project / Re: pulseIn Bug on: January 11, 2012, 10:39:39 am

My bugreport - http://code.google.com/p/arduino/issues/detail?id=675 - included math problems due to macro expansion with timeout too ... But the effect was that "long" timeouts went off too early due to overflow, not that it gave too large values....


It looks like pulseIn is reporting the correct pulse length, just not returning right away which causes it to miss the next (closely, but not too closely) spaced pulse.

That could be due to unoptimized math happening at the end, I haven't really looked into that though.
9  Development / Suggestions for the Arduino Project / Re: pulseIn Bug on: January 11, 2012, 10:09:22 am
I thought that might have something to do with it too, but I don't know why that would matter.  My timeout (usLong) is set to 100 mS, or 10,000 uS.  According to the reference page*, it needs to be between 10 uS and 3 minutes (1.8 x 108 uS), and it also says the following:

Quote
Reads a pulse (either HIGH or LOW) on a pin. For example, if value is HIGH, pulseIn() waits for the pin to go HIGH, starts timing, then waits for the pin to go LOW and stops timing. Returns the length of the pulse in microseconds. Gives up and returns 0 if no pulse starts within a specified time out.

I don't see why that change should be affecting this, as the pulses I'm measuring are 2 orders of magnitude below my timeout period.

*http://arduino.cc/en/Reference/pulseIn
10  Development / Suggestions for the Arduino Project / Re: pulseIn Bug on: January 11, 2012, 05:55:07 am
For all intents and purposes, this appears to be resolved on my part by moving to an older Arduino IDE.  I do apologize for being a "this isn't my problem" type of person, but I simply don't have time to troubleshoot this.  All I can say is I've found what appears to be a regression bug, and I want to make sure the right people know.
But until someone else can reproduce the issue you have reported, nothing will happen.

Iain

I've encouraged others to do so.  I believe it should be easy enough to do, though you may need two Arduinos (or a function generator) since you won't be able to read a pulse while triggering another one, though you might be able to do something with interrupts, but that might have unintended results.  Voltage shouldn't matter, so long as your LOW is under 0.1Vcc (500 mV) and your HIGH is over 0.6Vcc (3 V).  I suspect it won't take long to do a quick test, but it would take some effort to properly regression test this.  I've already done my "quick" testing, and I don't have the time, or knowledge of the Arduino IDE's guts, to do proper regression testing.
11  Development / Suggestions for the Arduino Project / Re: pulseIn Bug on: January 10, 2012, 05:01:27 pm
Quote
I suspect the problem lies in interrupt handlers,
An interrupt at the wrong moment can indeed "ruin" measurements, but is your code receiveing bytes while measuring? If no then there are no interrupts...


Nothing else is happening when I am trying to take these measurements, but there is an open serial port (using the Serial commands).

For all intents and purposes, this appears to be resolved on my part by moving to an older Arduino IDE.  I do apologize for being a "this isn't my problem" type of person, but I simply don't have time to troubleshoot this.  All I can say is I've found what appears to be a regression bug, and I want to make sure the right people know.
12  Development / Suggestions for the Arduino Project / Re: pulseIn Bug on: January 10, 2012, 11:14:52 am
Does that trace show working or non-working code?

The behavior shown there looks correct to me.

That image shows it working, when using Arduino 0021.  If you clicked on the link above, you would see the original post (before I thought this was a bug) that shows the following image of it not working.



The code is the same.  The only difference is what compiler I'm using.  The bug does not appear to be in the pulseIn function itself, though there are some slight modifications between versions.  I suspect the problem lies in interrupt handlers, perhaps for Serial communications, but I don't have the time, or experience, to dig in and find the solution myself.

I hope that the developers responsible for the Arduino IDE see this (or, tell me where their bug tracker is, because I couldn't find one linked on this website), because this seems like a pretty clear bug to me.  Behavior should not change depending on the compiler used, especially without giant warnings to let users know of possible issues.
13  Development / Suggestions for the Arduino Project / Re: pulseIn Bug on: January 09, 2012, 05:07:29 pm

From the picture (more than good enough) I see the following:  correct me if I'm wrong

- The blue signal looks like it really takes time to get up to its max => looks like a "big capacitor effect". Are you using long/thick cables?
- The blue signal is 3V. IIRC this is in the undefined range of TTL levels. It just could be that the HIGH level is not seen as HIGH

1) You can ignore the ramp up effects...that's a hardware issue in my custom shield that I'm aware of.

2) Yep, I'm playing with a "black box" that uses 3V logic.  I've checked the datasheet for the MEGA2560 (Page 267), and anything over .6*Vcc (3V) is HIGH, so it should be fine, though it is pretty close to the edge.  I've got a hardware fix I'm working on to do proper level shifting (would also fix issue in #1), but I haven't bothered with that yet because I've seen this hardware work.

So yes, you are correct on both, but neither actually matter.  I've proven, to myself at least, that going from Arduino 1.0 to 0021 fixes the problem, at least at a quick glance.  I encourage you to try a similar setup, at 5V.  I'd like to try that, but I don't have time to do that right now.
14  Using Arduino / Programming Questions / Re: pulseIn Taking "Too Long" on: January 09, 2012, 04:46:13 pm
I started going down that path and found that 0021 appears to work.  Going through the changelog now, I'm suspecting this is a bug that's not specific to pulseIn, but I'm not sure.
15  Development / Suggestions for the Arduino Project / Re: pulseIn Bug on: January 09, 2012, 04:37:06 pm
What is the length of the pulse you are trying to measure?

They're between 40 - 150 uS.  You can see in the plot I've posted, though I apologize it's not great resolution, I just posted it to illustrate working results.
COuld you please post the code - or better a minimized version that still produces this side-effect aka bug ?

If you look in the link I posted above, I have another thread I started before I realized this appears to be a bug.  Here's what's running to capture that plot above.

Code:
  noInterrupts();
  digitalWrite(Y, HIGH);
  P = pulseIn(X, LOW, usLong);
  digitalWrite(Y, LOW);
  a = pulseIn(X, LOW, usLong);
  digitalWrite(Y, HIGH);
  b = pulseIn(X, LOW, usLong);
  digitalWrite(Y, LOW);
  c = pulseIn(X, LOW, usLong);
  digitalWrite(Y, HIGH);
  d = pulseIn(X, LOW, usLong);
  digitalWrite(Y, LOW);

  interrupts();

The BLUE trace is X, the RED trace is Y.  I was using Y as a simple method to show when exactly pulseIn starts and stops.
Pages: [1] 2 3