Show Posts
Pages: 1 [2] 3 4 ... 70
16  Forum 2005-2010 (read only) / Troubleshooting / Re: Rel 0013 and Serial.print(double) on: February 08, 2009, 12:51:13 am
If I were tying in the float support, I would think this is probably the technique I'd use.  Not sure what mellis' reasoning was, he may have had some preference or issue with this approach.

Code:
class Print {
...
    void print(double n[glow], int places = 2[/glow]);
...
};
Code:
void Print::print(double n[glow], int places /* = 2 */[/glow])
{
  printFloat(n, [glow]places[/glow]);
}
17  Forum 2005-2010 (read only) / Troubleshooting / Re: Pyserial help on: January 31, 2009, 05:08:36 pm
Well, reading the bits right there in the error dump, it's saying /dev/tty.usbserial does not exist.  Have you opened up a bash shell and looked at whether that entry exists in your /dev path?  Considering your dump also shows C:/Documents and Settings, I'm going to go way out on a limb and say that you're on Windows, so of course the Unix path /dev/tty.usbserial is not correct for you.  What COM port do you use to connect with the IDE?  Use that same port name in your program.

18  Forum 2005-2010 (read only) / Troubleshooting / Re: Memory issues at run time i.e. stack size on: January 22, 2009, 01:42:26 pm
You need to know two things:  the top of your heap, and the "top" of your stack, and see if they're colliding.

Heap is the memory allocated by all static variables (permanent lifetime) and malloc() calls.  It grows from low memory upward.

I think you can find the amount of heap used by static variables by using avr-objdump on your .elf file.  The .elf is written as an intermediate file by the Makefile or Arduino IDE (the .hex is the final variant of it that gets uploaded).  The Arduino IDE tends to delete intermediaries often, so do a Verify and look in your temporary directory to find it.  Note that this doesn't address malloc() and I haven't learned specifically how the avr malloc() works with the heap.

Stack is the memory allocated every time you call a function, or declare a local variable that will die when the current function returns.  It grows from high memory downward.

To find the current position on the stack at any given time, you just create a new stack variable (C calls these "auto" variables), and then look at the address of the variable.  I've toyed with the idea of making a macro that does this, and then writes the worst stack address as a sort of "high water mark" to an EEPROM location so you can analyze it later.
19  Forum 2005-2010 (read only) / Troubleshooting / Re: Daily-action question on: January 09, 2009, 10:56:35 am
If your board should do nothing for 24 hours, then do one small task, then using delay() should be fine.  Note that the crystal is accurate to within a few seconds of drift per day, so any inaccuracy in delay() will probably be lost in the noise.

If you want to do various tasks, and for one task, notice that 24 hours have elapsed since the last time it ran, then you should track the passage of millis().  Ignoring leap seconds and leap days, 1 day = 86,400,000 milliseconds (simple math).  The millis() number will roll over at some point.  I think it's 32 bits, so (2^32) milliseconds = 49.7102696 days.  There's just a little math to do when you notice the millis() number returns is LESS than your last task invocation.
20  Forum 2005-2010 (read only) / Troubleshooting / Re: Problems with reading A/D... on: January 19, 2009, 08:09:47 pm
As George says, you're losing data in knock_volt.

Code:
byte knock_volt;
knock_volt = analogRead(knockPin);
knock_volt = map(knock_volt, 0, 1023, 0, 255);

After this, the highest value you could have in knock_volt is 63.  What's worse, the value 63 will appear when the voltage is at 1/4, 1/2, 3/4 and full levels.
21  Forum 2005-2010 (read only) / Troubleshooting / Re: Problems with reading A/D... on: January 16, 2009, 03:52:23 pm
Hm.  It "does not remotely reflect the voltages" the way you expect.

How about telling us more?  What's producing the voltage?  What range of voltages do you read with a meter?  Where are you sending that signal?  How are you reading that signal?  What range of readings do you get?  Is the reading high when the meter shows a high voltage?  Is the reading low when the meter shows a low voltage?  Are the readings noisy?  random?  clipped?  inverted?  not the same number you see on the meter?  ...

How to ask questions the smart way.
22  Forum 2005-2010 (read only) / Troubleshooting / Re: Stack Overlfow when compiling on: January 16, 2009, 11:28:24 am
Well, I'm not sure which tool in your toolchain is breaking (cut and paste the message), but I'm guessing the 'code scanning' features of the IDE are at fault here.

Parsers have to use deep stack structures to understand the intent of a big expression.  While that expression is childsplay for the avr gcc compiler, it is probably trickier for the scanner.  Why?  The scanner isn't trying to understand everything, just the bare minimum.  This could create some weird situations where the scanner can get confused because it's not keeping track of the starting and stopping of each statement.  The code scanner just wants to guess at the type info for each method you use, so it ensures the right headers and object code linkages are employed "magically."
23  Forum 2005-2010 (read only) / Troubleshooting / Re: Stack Overlfow when compiling on: January 16, 2009, 11:20:51 am
Split that line into three:  equation, print, println.  Issues?
24  Forum 2005-2010 (read only) / Troubleshooting / Re: Interrupt Vector filling? [SOLVED] on: January 08, 2009, 12:40:54 pm
mem, that may be true for microcontrollers like the ATmega, but it's not true of most larger microprocessors.  On other devices, I have seen them prioritized.  IRQ0 could interrupt any other ISR.  IRQ1 could interrupt all but IRQ0.  And so on.  This isn't even the only arrangement you could use.

It's really not that hard:  if you get an interrupt, start saving current state on the stack; if you are interrupted by a faster IRQ while saving state on the stack, you still start saving your state on the stack and do your ISR; when you're done, you'll quit and restore state from the stack so the interrupted slower IRQ's ISR will resume... saving state on the stack.  It just requires the push/pop instructions to be atomic, and enough stack to deal with the nested interruptions.
25  Forum 2005-2010 (read only) / Troubleshooting / Re: Interrupt Vector filling? [SOLVED] on: January 08, 2009, 09:21:02 am
Quote
Does ISR stands for Interrupt Sub Routine?

Close.  I've usually heard it as Interrupt Service Routine.
26  Forum 2005-2010 (read only) / Troubleshooting / Re: max length of arrray on: December 16, 2008, 05:00:25 pm
If you need to store 8bit values, make your array of bytes instead of ints.

Code:
byte myLights[512];

If you use an int for each element, it can store bigger numbers but takes two bytes PER ELEMENT, so that table you gave would take up 1024 bytes of memory.
27  Forum 2005-2010 (read only) / Troubleshooting / Re: build process on: December 29, 2008, 06:41:45 pm
Aha, thanks, mellis.  Easy enough for me to fix, but...

Why arduino-includes-after-mine?  It would be so much easier to mentally predict what magic is done to the sketch, if all magic inserts are done above line 1.  Then every header tab can enjoy/expect that WProgram.h is already available.

Code:
// magic stuff
#include <magic-arduino-stuff.h>
void magic_main_sketch_prototype(int foo);

// user's main sketch tab(s)
#include "/tmp/users_main_sketch.pde"
28  Forum 2005-2010 (read only) / Troubleshooting / Re: build process on: December 29, 2008, 12:47:57 pm
Here's a minimal example:

Code:
//#include "abcdef.h"

#ifndef __abcdef_h__
#define __abcdef_h__

class F
{
public:
    byte a;
public:
    F() { ; }
};

#endif // __abcdef_h__

void setup() { ; }
void loop() { F f; }

If this is all in the main file, it will compile properly.  If the #ifdef...#endif is put into the separate .h tab and included, it will fail but not explain the failure.  Even odder, if I have it in a separate header file, but comment out the member variable a in the class F, it will succeed compiling again.
29  Forum 2005-2010 (read only) / Troubleshooting / build process on: December 29, 2008, 12:16:07 pm
I have read the official page on the build process, http://www.arduino.cc/en/Hacking/BuildProcess but it doesn't say whether there's a Makefile or other script that drives this process.

I'm trying to split out a single-tab sketch into a multi-tab sketch (1 .pde, plus 1 or more .h files).  In multi-file form, it has some kind of error in it, but the builder won't show the actual error.  It shows something like this:

Code:
In member function 'void Pummer::show()':
 In member function 'void Pummer::goal(int, int, int, long unsigned int)':
 In member function 'void Pummer::loop()':
 In constructor 'Accelerometer::Accelerometer(int, int, int, int, int)':
 In member function 'void Accelerometer::update()':
 In member function 'void Accelerometer::dump()':
 In member function 'void Accelerometer::calibrate()':
 In function 'void setup()':

Note there's no actual explanation for any of these lines, just the fact that these functions are objectionable for some reason.  If I turn build.verbose=true, then we see that all the avr-gcc lines have run, but no avr-ld is run, then all the error message fragments are spit out in red.

The middle bar of the 0012 IDE turns brown with no text, and an irrelevant line (usually in the comment above my first #include) is highlighted.

I'm sure it's due to something in the IDE, and I must have dropped some semicolon or something, but unless I can run the same build process without stderr/stdin trapping, I can't see what I'm doing wrong.
30  Forum 2005-2010 (read only) / Troubleshooting / Re: Error message; Nothing on Troubleshooting Guide on: December 29, 2008, 12:00:41 am
You need semicolons at the end of lines 2 and 3 (potPin and pos).  The colon on the last line of setup() should be a semicolon.
Pages: 1 [2] 3 4 ... 70