Possible "hesitation" bug revealed using strcmp()

LeafLabs Garden » Support » Maple IDE Support

Possible "hesitation" bug revealed using strcmp()

(46 posts) (7 voices)

Started 5 years ago by StephenFromNYC
Latest reply from gbulmer

StephenFromNYC
Moderator

Wednesday September 29, 2010

Hello,

In my previous post I asked for help with implementing micros() before the release of Maple-IDE 0.0.7 because I want to determine if the problems I have with my ported LabVIEW/Maple code (which works with LabVIEW/Arduino Duemilanove 0017 IDE) was caused by a strcmp() bug. I did not want to attach my LabVIEW vi because it is large (and the LabVIEW vi still needs some development before it is ready for release).

Here is a link to my original post ("Arduino / Maple Time micros command"):

http://forums.leaflabs.com/topic.php?id=86&page=2#post-1420

In my LabVIEW/Maple code the problem (which occurs at iterations of 21n; see my previous post) is observed when a string of length 3 is sent by LabVIEW to the Maple. The problem is solved if the string sent by LabVIEW to the Maple is only 1. I did not test other string lengths (because I was happy that the LabVIEW/Maple code was finally working after several months of head banging).

I tried to look for strange behavior using just the strcmp() function (without LabVIEW) using just FOR loops and the millisecond timer millis(). I found some partially reproducible problems. I do not know if the "new" problems I observe with just the Maple code (in the absence of LabVIEW) is the cause of my LabVIEW/Maple problem.

My development system is Windows XP Pro SP3 and Maple-IDE 0.0.6. I power my Maple (Rev 3, summer 2010) with a USB 1.1 port. The Maple appears as COM7. I was using the Maple-IDE serial terminal (I did not test HyperTerminal or another serial terminal app).

In the code below I use a FOR loop where I set the interations (using LIMIT) to 1000 (1K), 10000 (10K), or 100000 (100K). The string length ranges from 0 to eleven characters (assuming you do not count the terminating null character).

Here is the data with some comments at the bottom of the "table":

string length LIMIT=1000 LIMIT=10000 LIMIT=100000

"0": 1000-> 3 ms; 10000-> 17 ms; 100000-> 162 ms
"01": 1000-> 3 ms; 10000-> 19 ms; 100000-> 182 ms
"012": 1000-> 3 ms; 10000-> 18 ms; 100000-> 174 ms

"0123": 1000-> 3 ms; 10000-> 14 ms; 100000-> 135 ms
"01234": 1000-> 3 ms; 10000-> 16 ms; 100000-> 154 ms
"012345": 1000-> 3 ms; 10000-> 18 ms; 100000-> 174 ms
"0123456": 1000-> 3 ms; 10000-> 20 ms; 100000-> 193 ms

"01234567": 1000-> 3 ms; 10000-> 17 ms; 100000-> 160 ms
"012345678": 1000-> 3 ms; 10000-> 19 ms; 100000-> 179 ms
"0123456789": 1000-> 3 ms; 10000-> 21 ms; 100000-> 199 ms
"01234567891": 1000-> 3 ms; 10000-> 23 ms; 100000-> 218 ms

"": 1000-> 3 ms; 10000-> 3 ms; 100000-> 23 ms

in set "0123456789" with 1000 reps see occasional "spikes" of 15, 10, 23, 41 millis (compared to 3 ms)
in set "0123456789" with 10000 reps see occasional "spikes" of 38, 25, 35 millis (compared to 21 ms)
in set "0123456789" with 100000 reps no spikes were observed

in set "" with 1000 reps observed one spike of 152 (without a preceding "End of loop" message)
in set "" with 10000 reps observed one abnormal 3 (no newline after 3; saw "3End of loop" on one line
in set "" with 100000 reps no unusual times observed, but why is it not 3 ms?

I was assuming the 1000 iterations column (3 ms for all) is measuring "overhead". Not a problem.

First "problem":

A "trend" is not predictable when the iterations are increased to 10K and 100K.

At 10K, with string lengths of 1, 2, and 3 chars the time starts at 17 ms, before an increase to 19 ms, and a decrease to 18 ms. This UP/DOWN pattern is also observed at 100K with the same string lengths.

At 10K, with string lengths of 4, 5, 6, and 7 chars the times drop to 14 ms, before increasing to 16, 18, and 20 ms. This DOWN/UP/UP/UP pattern is also observed at 100K with the same string lengths.

At 10K, with string lengths of 8, 9, 10, and 12 chars the times drop to 17 ms, before increasing to 19, 21, and 23 ms. This DOWN/UP/UP/UP pattern is also observed at 100K with the same string lengths.

I did not have time to test string lengths of 13, 14, 15, and 16 chars. I do not know if the same DOWN/UP/UP/UP pattern will be observed.

Question: why does a strcmp comparison of string length of 4 chars have the fastest execution time (especially when compared to shorter strings)?

Second "problem":

I did not notice this until I was testing the string of length 10 chars ("0123456789"). At 1000 iterations 3 ms was the most common time (with a little "noise"). However, when I was staring at the data stream by in the Maple serial terminal window I saw a blip of 15 ms (which was easy to see because it has two digits). When I looked through the data more carefully I saw other blips of 10, 23, and 41 ms.

Not many blips, but they were there. I guess it is possible to edit the sketch to count how many loops take significantly more time to finish.

When I used a string of zero characters (and 1000 iterations) I saw one spike of 152 ms. This point was also strange in that is did not follow an "End of loop" message.
When the iterations was increased to 10K I saw one line with "3End of loop" (which means the "SerialUSB.println(stop-start)" line did not print the newline character.

One small bug or a mixture of several bugs? I do not have the tools (eg. knowledge using a debugger) to test the problem in fine detail.

Thanks!

Stephen from NYC

Here is the test code ("shortest code"). LIMIT is set to 1000 and the string is set to "0123456789".

#include <string.h>

#define LIMIT 1000

void setup()
{
// this is not necessary, but I include it to make it easy to port my code between the Maple/Arduino.

SerialUSB.begin();
delay(5000);
}

void loop()
{
char stringArray[]="0123456789";

int count=0;

long start=0;
long stop=0;

start=millis();

for (count=0; count < LIMIT; count++)
{
if ((strcmp(stringArray, "0123456789") == 0) && (count == (LIMIT-1)))
{
SerialUSB.println("End of loop");
}
}

stop=millis();

SerialUSB.println(stop-start);
}

Posted 5 years ago #
StephenFromNYC
Moderator

Wednesday September 29, 2010

Hello,

My previous post was more qualitative (I was describing trends and "blips"). In this post I will be more quantitative.

In the code below I simply count the number of loops which require more time than the "average" to execute. On the Maple, the most common elapsed time is 3 or 4 milliseconds, so 6 ms is "significantly" greater. I am too lazy to do the real stats (eg. standard deviation), but I assume 6 ms is a good "cutoff" value.

On the Arduino (Duemilanove and Maple IDE 0017) the times are spread over the range 18, 19, and 20 millisecs. For the Arduino the cut-off for "blips" is arbitrarily set to 21.

I call these unusually long loop execution times "blips".

My assumption is that identical FOR loops should require very similar times to execute. However, I do not know if this assumption is true with microcontrollers.

Maple trials:

Run 1: 12 "blips" in 1000 loops (1.2%)
Run 2: 7 "blips" in 1000 loops (0.7%)
Run 3: 34 "blips" in 1000 loops (3.4%)
Run 4: 27 "blips" in 1000 loops (2.7%)
Run 5: 13 "blips" in 1000 loops (1.3%)
Run 6: 7 "blips" in 1000 loops (0.7%)
Run 7: 9 "blips" in 1000 loops (0.9%)
Run 8: 9 "blips" in 1000 loops (0.9%)
Run 9: 11 "blips" in 1000 loops (1.1%)

Arduino trials (using "Serial.begin(9600)"):

Run 1: 0 "blips" in 1000 loops (0.0%)
Run 2: 0 "blips" in 1000 loops (0.0%)
Run 3: 0 "blips" in 1000 loops (0.0%)
Run 4: 0 "blips" in 1000 loops (0.0%)
Run 5: 0 "blips" in 1000 loops (0.0%)

Although the observed time range for the Arduino is surprisingly wide (18-20 ms) no times are observed which are significantly longer than the average. No blips for the Arduino. Many blips for the Maple.

Is the presence of blips on the Maple a problem with gcc or libmaple?

I do not have time to follow the gcc forum or time to contribute a possible bug to their forum.

Thanks!

Stephen from NYC

Here is the test code. LIMIT is set to 1000 and the string is set to "0123456789".

The code is set for use on a Maple, but by removing and adding comments an Arduino can be tested.

#include <string.h>

#define COMM SerialUSB // for Maple
// #define COMM Serial // for Arduino

#define MAXIMUM 6 // for Maple
// #define MAXIMUM 21 // for Arduino

#define LIMIT 1000

long totalLoops = 0;
long totalBlips = 0;

void setup()
{
// this is not necessary, but I include it to make it easy to port my code between the Maple/Arduino.

COMM.begin();
// COMM.begin(9600);

delay(5000);
}

void loop()
{
char stringArray[]="0123456789";

int count=0;

long start=0;
long stop=0;
long interval=0;

totalLoops++;

start=millis();

for (count=0; count < LIMIT; count++)
{
if ((strcmp(stringArray, "0123456789") == 0) && (count == (LIMIT-1)))
{
COMM.println("End of loop");
}
}

stop=millis();

interval=stop-start;

COMM.println(interval);

if (interval > MAXIMUM)
{
totalBlips++;

COMM.print("Total number of blips (> ");
COMM.print(MAXIMUM);
COMM.print(" ms) now: ");

COMM.println(totalBlips);
COMM.print("Total number of loops now: ");
COMM.println(totalLoops);
}

if (totalLoops==1000) quit();
}

void quit()
{
COMM.print("Final number of blips (> 10 ms): ");
COMM.println(totalBlips);
COMM.print("Final number of loops: ");
COMM.println(totalLoops);

while (1)
{
;
}
}

Posted 5 years ago #
crenn
Moderator

Are you using stock v0.0.6?

Posted 5 years ago #
StephenFromNYC
Moderator
Thursday September 30, 2010

Hello,

I just realized I did not say I uploaded my two strcmp() test sketches into SRAM. I have a version of "blink" in FLASH. I know when a new sketch is successfully loaded into SRAM, because the pin13 LED pattern changes. When I power up the Maple board using the USB cable the blink program in FLASH executes, which is a nice "I am functioning" message. In my two strcmp() test programs I do not use the LED, because Perry asked me to make the code as simple as possible.

crenn, did you try to replicate my observations? Did you use FLASH or SRAM memory? I hope your ADXL345 accelerometer is not faulty because of too many bumpy landings on test flight!

On my system I swapped out the just the "boards.txt" file, because I wanted the ability to upload larges sketches.

However, I have been playing it safe with the other Maple files. I have been peeking at the updated *.c, *.h, and *.cpp files checked-in on github, but I have not used them in any sketches. Not quite "stock 0.0.6", but close.

After 0.0.7 comes out I will maintain three installs of the Maple software. 0.0.6, 0.0.7, and 0.0.7. A few weeks ago one the LeafLabs team members said this is safe. I will ask this question again when 0.0.7 is released in case there have been any changes which make multiple installs of Maple less predictable.

I am looking forward to using 0.0.7, hopefully this weekend.

http://forums.leaflabs.com/topic.php?id=204#post-1450

Thanks to the LeafLabs team. As a reward you all deserve a weekend of rest or a weekend of sleepless nights hacking your own projects!

Stephen from NYC

P.S. This is just a test of the forum's markup tags:
```
This text is between "backtick" characters (not between less than and greater than); it seems to change the font.
```
This text is between "a" characters (between less than and greater than signs -/+ a closing slash); it turns the text green.
Posted 5 years ago #
gbulmer
Moderator
Stephen - I have two theories, but I can't find the code to check one, and too hungry to check the other for a while.

There is always 0.5mSec jitter on the millis() timer, so I think it is hard to conclude much from a difference of 1mSec.
I haven't checked the most current Arduino release, but the Arduino millis timer interrupt routine collected up the error on its hardware timer (timer 0), and incremented the millis time by 2 every now and then, so it's jitter looked worse than it was.

Theory 1.
On the Arduino, I/O is blocking (upto the last character), so when the COMM.print's happen, the Arduino won't begin the next set of test loops until the last character is on the way. So its timing will be relatively clean, only distorted by the hardware interrupt that supports millis().

On the Maple, I/O is none-blocking, so when the test loop starts, there are still characters to be sent, and interrupts to be handled, so that is impacting the test times, and causing a lot of 'jitter' on the measurements. To test the theory put a large delay in at the start of loop(), if the jitter is significantly less, this is a plausible explanation.

Theory 2
There may be small amounts of difference between, e.g. 2 and 3 character strcmp's, where 3 is quicker than 2 characters (and some other patterns like 7 is quicker than 6). I can't find the source of strcmp to confirm this, but I will try to look later today.

A simple way of implementing strcmp was:
```
int strcmp(char *s, char *t) {
    while ((*s == *t) && (*s != 0)) {    // I'd like to say ' backslash 0 ',
        ++s; ++t;     // but the forum formatting eats that
    }
    return (*s == *t);
}
```
Which compares character by character.

For longer strings, a simple optimisation (which relies on the processor doing non-aligned reads) was to compare 4 characters at a time. In this case, the processor being little-endian or big endian matters too.

I haven't found the source of the Maples strcmp yet, to check this theory, but the 'optimised' strcmp looked approximately like:
```
// Little endian, I think, reverse for big endian :-)
#define CHAR0 (0xff000000)
#define CHAR1 (0x00ff0000)
#define CHAR2 (0x0000ff00)
#define CHAR3 (0x000000ff)

int strcmp(char *sp, char *tp) {
    int *s = (int*) sp;
    int *t = (int*) tp;

    while ((*s == *t) && (*s & CHAR0) && (*s & CHAR1) && (*s & CHAR2) && (*s & CHAR3))  {
        ++s; ++t;
    }

    if (*s == *t) return true;   // simple case, if at end of string,
                               // this happens mostly when strings are n%4 == 3

    if ((*s & CHAR0) != (*t & CHAR0) return false; // 1st character of 4 match?
    if ((*s & CHAR0) == 0) return true; // yes, and it's end of string, so all matched

    if ((*s & CHAR1) != (*t & CHAR1) return false; // 1st characters matched, 2nd match?
    if ((*s & CHAR1) == 0) return true; // yes, and it's end of string, so all matched

    if ((*s & CHAR2) != (*t & CHAR2) return false; // 2nd characters matched, 3rd match?
    if ((*s & CHAR2) == 0) return true;  // yes, and it's end of string, so all matched

    if ((*s & CHAR3) != (*t & CHAR3) return false; // 3rd characters matched, 4th match?
    if ((*s & CHAR3) == 0) return true; // yes, and it's end of string, so all matched
                                           // There is an ERROR in my code!

    return false; // should never get here
}
```
WARNING - this code has not be compiled, and may be full of errors

As I think can be seen, this doesn't have a run time which monotonically increases with the length of the string, instead it 'jitters' with string matches on strings of length (N%4 == 3) being faster than other, shorter strings.

Anyway, they are my two theories (ignoring the one about dinosaurs being thin at one end, etc. :-)
Posted 5 years ago #
snigelen
Member

Hello, just a small comment.

> I haven't found the source of the Maples strcmp yet

strcmp (and all other std c-functions) comes from the CodeSourcery gcc-distribution. They probably use newlib.

Posted 5 years ago #
gbulmer
Moderator

sniglen - thank you.

I had a look at the newlib source, and strcmp() may use the 4-byte technique I outlined, depending on compile-time flags.

There is an error in my code.
strcmp() returns a +/0/- value depending on which the lexical comparison of the strings, not just the true/false my code returns.

Also, the newib version has a test for a null byte within a 4 byte int, which is very sneaky:
#define DETECTNULL(X) (((X) - 0x01010101) & ~(X) & 0x80808080)

Their code simply does a byte by byte comparison if 4-bytes do not match, sidestepping issues of endian-ness. Much nicer.

Overall, the newlib strcmp does compare 4 bytes at a time if compiled up to favour speed over space, and will compare 4 bytes at a time when the strings are aligned on 4 byte boundaries. I believe literal character strings are aligned to 4-byte boundaries, so I think the test program would see that behaviour.

Summary - Theory 2 may explain the non-monotonic speed changes when comparing strings of slightly different lengths.

Posted 5 years ago #
gbulmer
Moderator

I forgot to add the optimisation (which might actually not be there) which would give the 'jittery' behaviour of strcmp(), where (n%4 == 3) strings compare the fastest can easily be turned off.

change
char stringArray[]="0123456789";
to
char stringArray[]="X0123456789";
and change
if ((strcmp(stringArray, "0123456789") == 0) && (count == (LIMIT-1)))
to
if ((strcmp(&stringArray[1], "0123456789") == 0) && (count == (LIMIT-1)))

The char array stringArray address passed to strcmp won't be aligned to a 4 byte boundary, so that would force strcmp() to do simple byte by byte comparison (if it ha been compiled to do that).

So, using this technique, and a big delay at the start of loop(), may remove the two explicable sources of jitter in the timings, leaving the inexplicable!

If the strcmp() timings then become consistent (ad sane), then this is a less fruitful place to look for an explanation of your 21n delay bug, and it's probably worth looking elsewhere for an explanation.

Usual Health Warning - this code has not been compiled and tested

Posted 5 years ago #
StephenFromNYC
Moderator

Hello everyone,

In my previous post (above) I should have said I plan to maintain three installs of the Maple-IDE on my system, 0.0.6, 0.0.7, and 0.0.7 alpha/beta.

I attached the two sketches, because I was hoping other users would replicate my observations of the "sawtooth" pattern (DOWN/UP/UP/UP) which may or may not be related to my "21n" problem. All of these very useful (to me) contributions would not be necessary if the strange "sawtooth" timings I observe with strcmp () are due to a quirkiness of my Windows XP Pro SP3 system. The processor is a Pentium III.

Did anyone try running the code? Did anyone see a few unpredictable times which were significantly longer than 3 ms (when tested on a Maple Rev 3)? I am not referring to the "sawtooth" behavior, but the occasional and unpredictable loop which takes > 6 ms? The second code is easier to use, because it displays the final number of errors after 1000 loops.

gbulmer, I like your ideas which might explain the "sawtooth" phenomenon. I do not know if this was your intent, but your code suggests two significant improvements to me. Thanks!

1) if I do not #include <string.h> then my compiled code may be smaller (a byte saved is a byte earned)
2) the first step would require using a "homemade" version of strcmp(), but it could be optimized for speed since I will know ahead of time the length of the strings being sent from LabVIEW to the microcontroller.

This might be the best way to fix my "21n" problem in my LabVIEW/Maple code, but it does not explain the "21n" problem.

gbulmer, do you have any explanation for the occasional (in my hands 0.7%-3.4% of loops) which take significantly longer to execute. This phenomenon worries me more. Your explanation works well for the "sawtooth" pattern, but not for the occasional "blip".

Thanks to all!

Stephen from NYC

Posted 5 years ago #
gbulmer
Moderator

do you have any explanation for the occasional (in my hands 0.7%-3.4% of loops) which take significantly longer to execute. This phenomenon worries me more.

Stephen - I agree this is much more perplexing.
The only explanation I have for a blip is an overlap of I/O and the strcmp loop.

Assuming I've understood it, I was a bit suspicious that it was 21n with 3 byte commands.
21x3bytes = 63bytes, and I had thought some USB buffers were set to 64 bytes.

I'll run your code on my Mac, and see what happens (I need a nice cup of tea, and maybe a biscuit, first to gird my loins :-)

EDIT - Stephen - Please don't take any of my code as good examples, I just wrote it to illustrate a point.
The library strcmp() is robust and reliable (according to the web site that snigelen helpfully pointed to, strcmp hasn't changed in ten years). Saving a byte in 128K probably isn't worth the effort.

Posted 5 years ago #
StephenFromNYC
Moderator

Hello,

gbulmer, you and I are thinking exactly along the same lines. See last paragraph before you read the rest of this message.

I was wondering if 21X3 bytes (63 bytes) was related to a small USB buffer (possibly configured to be 64 bytes) when I posted this question a few days ago:

http://forums.leaflabs.com/topic.php?id=206#post-1422

Regarding the 512 bytes of SRAM which can be configured for USB use I said:

Is there any leaflabs documentation which describes how these 512 bytes of memory are configured on the Maple? Are the USB buffers ring buffers? How are the USB buffers cleared? Can users manually clear the USB buffer? For example, if the USB buffer size is 256 bytes and the Maple needs to send 256 bytes of data to the system is the data more likely to be transmitted at one time if the buffer is first emptied manually?

mbolivar has not followed up since his initial "ping" response. He is probably spending his time working on the 0.0.7 release, which is a better use of his time. Releasing 0.0.7 sooner serves more users. I am a minority of one.

It is possible the LabVIEW/Arduino setup does not exhibit the "21n" glitch because the Arduino/FTDI system uses a larger 128 byte buffer (I think). It is possible the Arduino system can prepare the larger 128 byte buffer for new data because it has the space. With only 1 byte to spare it is possible the Maple gets "clogged".

In my previous post I was more focused on finding a function to manually clear the USB buffer. If the Maple USB buffer is only 64 bytes my "21n" problem might be solved by increasing the buffer size, but I did not ask if this would conflict with other Maple features.

I tried to separated the "21n" problem from this thread, because I do not know if the "21n" problem is related to the sporadic strcmp() behavior. I am focusing on the strcmp() behavior, because it is something other users can help diagnose (because it requires only a Maple board). Solving the LabVIEW/Maple problem requires LabVIEW, which is not open source.

All I know for sure is that with strcmp() the "21n" problem occurs when LabVIEW sends an instruction (which is three characters long; AR0) to the Maple. The "pause" occurs AFTER 21n iterations of the loop.

Full disclosure: the command sent from LabVIEW to the Arduino/Maple is terminated by a newline character, so I do not know if a total of four characters are sent [A][R][0][\n]. If four are sent each time then the "21n" problem occurs after 84 bytes are sent/received, not 63 bytes.

Thanks again!

Stephen from NYC

Posted 5 years ago #
gbulmer
Moderator

It is possible the LabVIEW/Arduino setup does not exhibit the "21n" glitch because the Arduino/FTDI system uses a larger 128 byte buffer (I think). It is possible the Arduino system can prepare the larger 128 byte buffer for new data because it has the space.

I was fortunate to see the USB stream between an Arduino and host PC, using a hardware USB sniffer, and the packets were never more than 16 bytes.

Which thread would you like to use for the 21n glitch?

Posted 5 years ago #
gbulmer
Moderator

Stephen - I tried running both programs.
It was impossible for me to tell if the first program worked, it just flies past.

I ran the second 'blips' program half a dozen times.
About half of the times, it gave no blips.
Once it gave 1 blip.
Twice it gave 9 blips.
Whenever I got blips, I had popped up the serial monitor so quickly that the first time I got a message in the status bar of the serial monitor saying it couldn't find /dev/fubar (or whatever) so I had to close it, and open again.
Whenever I got 0 blips, my timing was such that I opened the serial monitor as the output started.

My hypothesis is the blips are caused by characters backed up in the USB output waiting to get sent, and hence causing interrupts, which cause time to be 'stolen' from the loop. I don't current;y feel I need any more complex explanation.

The things I would add are:
1. the bug where anything in RAM gets preference over something newer in Flash is annoying, and would confuse the life out of a lots of newbies. I believe this is fixed in 0.0.7.
2. This switching of USB device back and forth, so that the device isn't there when the serial monitor is opened, is horrific. It looks exactly like a transient bug. Please just ditch this DFU device.
3. It might be useful to remove the value from the serial monitors baud rate drop down, its just confusing (but low priority).

Posted 5 years ago #

Stephen - I modified your program, so that it saves the elapsed time for each run.
At the end of all the runs (just 20 in my test), it sorts the times into descending order, and prints them. Hence, their is no USB output while it is timing stuff.

Each run is 100000 comparisons, which is about 1/3rd of a second.
It flashes the blue LED on and off on alternate runs, so it's easy to see when to open the serial monitor.
It goes into a slow (3 seconds on, one off) flash when it has finished.

I get the same time within 1 millisecond, so their is no jitter on strcmp.
I believe the 21n problem is elsewhere.

It's probably time to make the smallest example that exhibits the error and post it.

#include <string.h>

#define COMM SerialUSB // for Maple
// #define COMM Serial // for Arduino

#define MAXIMUM 6 // for Maple
// #define MAXIMUM 21 // for Arduino

#define LIMIT 100000

#define MAX_LOOPS (20)
long currentLoop = 0;
int intervals[MAX_LOOPS];  // unusable on an Arduino - this is likely too big
int dumbMath = 0;

int ledPin =  13;    // LED connected to digital pin 13

void setup()
{
  pinMode(ledPin, OUTPUT);     

  // this is not necessary, but I include it to make it easy to port my code between the Maple/Arduino.

  COMM.begin();
  // COMM.begin(9600);

  delay(5000);
}

void loop()
{
  char stringArray[]="0123456789";
  int ledState = HIGH;

  for (int currentLoop=0; currentLoop < MAX_LOOPS; ++currentLoop) {
    digitalWrite(ledPin, ledState);   // set the LED on/off
    ledState = !ledState;

    long start=millis();

    for (int count=0; count < LIMIT; count++) {
      if ((strcmp(stringArray, "0123456789") == 0) && (count == (LIMIT-1))) {
        CountLoops();  // function should force compiler to leave stuff in
      }
    }

    long stop=millis();

    intervals[currentLoop] = (int)(stop-start);
  }

  quit();
}

void CountLoops() {
    dumbMath++;
}

void quit() {
  bubblesort(intervals, MAX_LOOPS);

  COMM.print("Final number of loops: ");
  COMM.println(MAX_LOOPS);  

  COMM.println("Elapsed time sorted from largest to smallest");

  for (int i=0; i<MAX_LOOPS /*totalBlips*/; ++i) {
    COMM.print("blip ");
    COMM.print(i+1);
    COMM.print(" = ");
    COMM.print(intervals[i]);
    COMM.println(" msec");
  }  

  COMM.print("Garbage to stop compiler optimising away stuff ");
  COMM.println(dumbMath);

  while (1) {
    digitalWrite(ledPin, HIGH);   // set the LED on
    delay(3000);
    digitalWrite(ledPin, LOW);    // set the LED off
    delay(1000);
  }
} 

void bubblesort(int list[], int n)
{
   int i,j;
   for(i=0;i<(n-1);i++) {
      for(j=0;j<(n-(i+1));j++) {
         if(list[j] < list[j+1]) {    // sort largest to start of array
             int temp = list[j];
             list[j] = list[j+1];
             list[j+1] = temp;
         }
      }
   }
}

Posted 5 years ago #

crenn
Moderator

The things I would add are:
1. the bug where anything in RAM gets preference over something newer in Flash is annoying, and would confuse the life out of a lots of newbies. I believe this is fixed in 0.0.7.
2. This switching of USB device back and forth, so that the device isn't there when the serial monitor is opened, is horrific. It looks exactly like a transient bug. Please just ditch this DFU device.

1. I believe that is a firmware related bug, not IDE related.
2. I think the more annoying bug is the lack of auto-reset on opening the terminal window. (which I believe is fixed in v0.0.7)

A workaround might be to include a long delay in Setup() before anything occurs. I'm not sure if this will help solve the problem. And are you sure that calling SerialUSB.begin() in Setup() doesn't actually cause problems?

Posted 5 years ago #

RSS feed for this topic

12…4 Next »

Reply »

You must log in to post.