Signal Generator

[dcb]

I've never witnessed that behavior and I have tried to reproduce it, lots of fast rights and lefts, casual lefts and rights, hundreds in a row, no problemo.

FYI, on the plan for the signal generator program (eventually) is to add button signals too.

If you want to give that a go, the resistors are cheap insurance, I do have actual, non speculative, first hand experience with cooking a chip by connecting them directly The pin states may not be in a known state when the chips boot up and they may not boot up perfectly in sequence, or you just forgot what code you had on one of the chips . so two pins could be in output mode (non-low impedence) and one high and one low and that's all it takes.

[awillard69]

Maybe I wasn't very clear. When I display the CPU screen, I see what appears to be a single update, then the apparent reset.

I'll plug in some resistors to see how it goes. Currently, both Freeduino's are powered from the same 12v source (bench power) with a split pigtail for the power jacks, so a common ground. Since the Guino code is vastly larger, I'm speculating that it comes online after the test generator, but, you're right, that's no guarantee. My two Freeduinos are not easy to mix up as the Guino one has the proto-shield with the LCD and the generator is just a plain board. Yes, I suppose I could have uploaded the incorrect program, but I think I'm better than that .

I think I'll update the generator to put a signature pin 13 blink sequence or something to it will be obvious when it's functioning.

[dcb]

Hmm.. Can you try commenting out all the lines inside doDisplay7()? Should just have a nonsense screen for CPU Monitor hopefully instead of a quasi-reset.

[awillard69]

I'll give that a try this evening when I get home.

[awillard69]

It appears the the memoryTest() function is the culprit - on 2 different Duinos. I've commented it out completely, and it works; I've commented out the while loop and it works. Something in the allocation routine is amiss, like maybe the processor is getting trounced - at the moment it needs memory, the program has it allocated, so it resets.

I've modified it as follows, what do you get on the serial? I changed it to an unsigned long to match the data type in the calling function, but no luck. I even added the check before the final deallocation.

// this function will return the number of bytes currently free in RAM    
unsigned long memoryTest() {    
  unsigned long byteCounter = 0; // initialize a counter    
  byte *byteArray = NULL; // create a pointer to a byte array    

  while ( (byteArray = (byte*) malloc ((int)byteCounter * sizeof(byte))) != NULL ) 
  {    
//    byteCounter++; // if allocation was successful, then up the count for the next try    
    byteCounter += 10; // if allocation was successful, then up the count for the next try    
    free(byteArray); // free memory after allocating it    
    #ifdef debuguino
    Serial.print("Memory: ");Serial.print(byteCounter);Serial.print("\n");
    #endif
  }
  if( byteArray != NULL ) free(byteArray); // also free memory after the function finishes    
  return byteCounter; // send back the highest number of bytes successfully allocated    
}

On count by 1 (ie byteCounter++), I get:

...snip
Memory: 840
Memory: 841
Memory: 842
Memory: 843
JMemory: 844KMemory: L845Memory:M846MemoryN847MemorO848MemoP849MemQ850MeR851MS852T85385485585685785885986086186286386486586686786886987087187287387487587687787887988088188288388488588688788888989089189289389489589689789889990090190290390490590690790890991091191291317367953914915916917918919920921922923924925926927928929930931932933934935936937938939940941942943944945946947948949950951952953954955956957958959960961962963964965966967968969970971972973974975976977978979instant: 0,133444,54,166
current: 0,133444,54,166

...snip

For += 10, I get:

...snip
Memory: 910
Memory: 920
Memory: 930
M¢940
M¢950
M¢960
M¢970
M¢980
M¢990
M¢1000

...snip

Any help?

[dcb]

Here's what I get, no problem there, about time for another round of optimizing though

instant: 0,44072,18,27
current: 0,879320,360,550
Memory: 10
Memory: 20
Memory: 30
Memory: 40
Memory: 50
Memory: 60
Memory: 70
Memory: 80
Memory: 90
Memory: 100
Memory: 110
Memory: 120
Memory: 130
Memory: 140
Memory: 150
Memory: 160
Memory: 170
instant: 0,46516,19,28
current: 0,925836,379,578

[awillard69]

Ok, my next stab might be something like: something different between our ATMEGA's, like maybe a different generation of boot loader software, some memory management issue. I've tried it on two different Duino's bought weeks apart, so that doesn't seem very likely..

But, I'm willing to consider other options, as well.

What about your coding IDE? What platform are you using? I'm using v0011 on Ubuntu 8.04. Even though it's supposed to be the same, might there be a difference in the bytecode generated?

I haven't ruled out my proto board, either. Tonight I'll try running the Duino on just the board itself, no peripherals and just trigger the left switch and watch the trace.

[dcb]

Hard to imagine something external messing up malloc(), I would suspect linux is the key difference here. Are you using a script to start arduino (run.sh or something)? I know strange things can happen in windows if you do not use the script, there is less possibility of linking in the wrong malloc on windows too


I tried 0010 and 0011 fyi, on a lot of chips. Some that I had used the IDE to load the decimillia bootloader on too.

FYI, in addition to the supercheap but flakey parallel iCSP, there is also a bit of code to turn a duino into an icsp programmer if you want to try a different bootloader: http://www.arduino.cc/playground/Code/Programmer2

[awillard69]

I'm running "arduino" in the arduino-0011 folder. It's basically a shell script:

#!/bin/sh

CLASSPATH=java/lib/rt.jar:lib:lib/build:lib/pde.jar:lib/core.jar:lib/antlr.jar:lib/oro.jar:lib/registry.jar:lib/mrj.jar:lib/RXTXcomm.jar
export CLASSPATH

# put the directory where this file lives in the front of the path, because
# that directory also contains jikes, which we will need at runtime.
#
PATH=`pwd`/tools:${PATH}
export PATH

# put the directory with the native RXTX libs in the library path
LD_LIBRARY_PATH=`pwd`/lib:${LD_LIBRARY_PATH}
export LD_LIBRARY_PATH

java processing.app.Base

Nothing special there. I compared it to the Windoz version, and it seems comparable. So, maybe there is a bug in the Linux variant. I'll have to try to find a different machine to use the IDE and see if it actually matters.

[awillard69]

I found this link, http://www.arduino.cc/cgi-bin/yabb2/...num=1213583720, and http://forum.pololu.com/viewtopic.ph...w=unread#p4218, and it seems to indicate the complexity of checking free RAM.

It might also be related to the intermixing of C++ and C constructs on immature compiler/libraries. I only have anecdotal support, but I've seen it happen before - on Solaris no less!