Show Posts
Pages: 1 2 [3] 4 5 ... 70
31  Forum 2005-2010 (read only) / Troubleshooting / Re: Analog Sample Rate on: December 09, 2008, 06:16:36 pm
If anyone spots an error in my math, let me know.

With all the delay() calls in your loop(), you're taking at least 61 milliseconds between samples, and more depending on how long it takes to send the serial characters.  That's at least 1/16th of one second.  If it took you 2 seconds to roll the potentiometer from max to min, then you'd only get about 32 readings, not all 1024 possible readings, from max to min.
32  Forum 2005-2010 (read only) / Troubleshooting / Re: eeprom memory resetting on: December 17, 2008, 12:45:32 pm
Exactly, dcb.  It just bothers me to see fifty apps reinvent the above idiom, and risk getting it wrong or bloated.
33  Forum 2005-2010 (read only) / Troubleshooting / Re: eeprom memory resetting on: December 17, 2008, 11:35:14 am
If nobody objects, I'll submit an extension to the EEPROM library this evening, which can store and retrieve multi-byte values like ints and structs.  It's better if a standard routine does this, to avoid byte ordering bugs etc.  I need to look at how to get the latest git/svn/cvs code first, and where to send patches.
34  Forum 2005-2010 (read only) / Troubleshooting / Re: eeprom memory resetting on: December 17, 2008, 09:52:08 am
If you're counting a big number with your hands, what do you do?  You count to ten, then you start over again but remember "ten" in your head, and if you count another ten, you remember "twenty" in your head, and so on.

An EEPROM location is a byte.  If you want to count a bigger number, you need another EEPROM byte to count the number of times the first location overflowed.  Two bytes could count to 65535 (256*256-1) and then both locations would overflow.  If you need bigger numbers than this, then you need a third EEPROM byte to count those overflows.  And so on.  With three bytes, it would count to 16,777,215 before overflowing.  With four bytes, it would count to 4,294,967,295 before overflowing.

Unlike the "int" and "long" variable types in the usual C code, you'll have to handle the EEPROM code to handle multiple-byte numbers a bit more yourself.
35  Forum 2005-2010 (read only) / Troubleshooting / Re: multi dem arrays using data from EEPROM on: December 15, 2008, 10:41:57 am
A useful definition to have, when working with arbitrary-length arrays:

Code:
#define countof(a)  ( sizeof(a) / sizeof(*(a)) )

A fixed width, arbitrary-length array of bytes:

Code:
byte rfids[][10] =
{
    { 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0A },
    { 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0A },
    { 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0A },
    { 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0A },
};

byte* p = rfids[3]; // pointer to rfid at index #3

A fixed width, fixed-length array of bytes is similar, just give the number of rows.  The compiler will complain if you don't match the number of rows expected and the actual rows given:

Code:
byte rfids[4][10] =
{
    { 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0A },
    { 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0A },
    { 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0A },
    { 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0A },
};

byte* p = rfids[3]; // pointer to rfid at index #3

If you really want them as char strings, terminated with zeros (easy for use with Serial.print() for example):

Code:
// takes 11 bytes per string due to '\0' terminators
// plus a separate index table of one pointer per string
char* rfids[] =
{
    "123456789A",
    "123456789A",
    "123456789A",
    "123456789A",
};

char* p = rfids[3]; // pointer to rfid at index #3

To put them into the EEPROM attic, I would make small custom functions that read or wrote an RFID array or string.  Then I could refer to EEPROM RFID #3 and retrieve it into a RAM string for use.
36  Forum 2005-2010 (read only) / Troubleshooting / Re: multi dem arrays using data from EEPROM on: December 14, 2008, 10:42:10 pm
It depends on whether you have a need for variable-length character strings, or fixed-length character arrays.  If they're all RFID tags of the same length, you could just store them and calculate their addresses.  If not, you will have to have an index table to point to each string, or walk through the list of strings, to find a particular string.
37  Forum 2005-2010 (read only) / Troubleshooting / Re: multi dem arrays using data from EEPROM on: December 14, 2008, 05:44:24 pm
Once it is running, your program can stuff whatever it wants into EEPROM, but I don't think you can declare C data to go directly into EEPROM during the sketch-uploading process.  Instead, you use the EEPROM library of functions and your program writes things or reads things from it.

However, if your strings aren't changing, unless you're totally crammed for program space AND runtime memory, you probably want to put them into the program space ("progmem") instead.  There's an example on how to do this exact thing on the arduino site:  http://www.arduino.cc/en/Reference/PROGMEM

If you're really sure you want the strings in EEPROM, I guess you could make a temporary program that took your initial string values and put them into EEPROM, then replace the temporary program with your ultimate application.  I don't think the upload process modifies EEPROM at all.
38  Forum 2005-2010 (read only) / Bugs & Suggestions / Re: Feature request: Adjustable PWM frequency on: February 16, 2009, 12:12:06 pm
There's no friendly setAnalogFrequency() kind of function included in the standard library, but it's a pretty straightforward task.

A google search for "arduino set pwm frequency" will find a few useful threads on this site and on other sites like uchobby.

I think one reason for excluding the function is because there are some subtle interplay that you should be familiar with, before you start messing with these things.

For example, there are six PWM-capable output pins, and each of the six outputs has their own PWM-comparator to adjust the duty cycle of that pin.  But there are only three actual timers, so pins in pairs, 3/11, and 5/6, and 9/10, each pair shares a timer.  Adjust the frequency of pin 3, and pin 11 also gets the new shared frequency.
39  Forum 2005-2010 (read only) / Bugs & Suggestions / Re: arduino icon on: December 19, 2009, 12:19:57 am
I hand-traced the .png file above, to make a scaleable vector graphic.  http://halley.cc/paste/arduino.svg
40  Forum 2005-2010 (read only) / Bugs & Suggestions / Re: No cost streams on: January 11, 2009, 02:37:55 pm
Quote
I don't think I quite understand the syntax. ... Or is "<<" already magical in some way ("streaming" ??)

When C++ started supporting "overloaded operators," the first bit of wisdom was to say, don't overload an operator with something completely different from its original intent.  A Vector plus a Vector should use the operator + to add them.

But then C++ creator Bjarne Stroustrup (or "Barney Shoestrap" as some like to say) broke this sensible wisdom in a big way with operator << and operator >>.  He didn't use them for shifting, but for streaming.  It's a love/hate thing with C++ programmers.  Some love it, some absolutely loath it.

The usage mikalhart shows is quite common:  it lets you bang a bunch of things through the various print() methods in sequence, using only one expression.  I think his idea to include it in the Print header makes a lot of sense, even if I'm not too warm on the syntax.

If print() returned a reference, *this, you could do the same with Serial.print(x).print(y).print(z), but that's not obvious either.
41  Forum 2005-2010 (read only) / Bugs & Suggestions / Re: asterisks in comments fails compilation on: February 09, 2010, 03:12:31 pm
Some notes for whomever is investigating:

The Java regular expression library is notoriously bad at backtracking, especially with the Pattern.DOTALL option specified.  The IDE needs to break up the search for beginning and end of a /*...*/ comment into two parts: if a comment begins with "/\\*", then find the end "\\*/".  If possible, search for the end of the comment without relying on the DOTALL to search multiple lines.  Search each line independently instead.
42  Forum 2005-2010 (read only) / Bugs & Suggestions / Re: switch case example ambiguity / error on: December 08, 2009, 07:42:16 am
As unprinted indicated, sometimes it's useful to the human reader that there is nothing to be done in a certain condition or case.  Remember that the code is not just for the machine's benefit.  Writing clear code that can be understood months or years later is an important skill.  The compiler can optimize the overhead out when it sees there's nothing to be done.

The C language did not always require that extra statement after the default: case.  I think it's dumb that it requires it now.  You can use just an empty semicolon to fulfill the new requirement.  You don't need an empty semicolon if you put a goto label: just before a closing brace, so I don't know why they demand one after default: now.
43  Forum 2005-2010 (read only) / Bugs & Suggestions / Re: Occasional "Couldn't determine program size" error on: April 03, 2009, 08:10:30 am
Agreed, jcw, it's a flaw that should be investigated.  Should have been investigated for some time now.

The error reporting mechanism often drops errors (only showing "In function foo():" but no error text), and often fails to collect any output at all (only showing "Couldn't determine program size").

It seems like the IDE is not properly getting the stdin/stdout handles of the spawned build process, and since it's more flaky on a platform that has a lot of dual-core machines, I'm putting money on a race condition of some kind:  the routine returns but the returned handles aren't really ready yet.
44  Forum 2005-2010 (read only) / Bugs & Suggestions / Re: delay using empty FOR loop?? on: April 17, 2009, 04:08:40 pm
Quite a bit.  And trying to trick the compiler to avoid optimizations can be inconsistent, frustrating and futile.

Two choices:  call delayMicroseconds() (recommended), or implement your own delay with inline assembler instructions.
45  Forum 2005-2010 (read only) / Bugs & Suggestions / Re: Linux install doesn't include avr-gcc/etc ? on: April 06, 2009, 07:57:52 pm
I think it's just different philosophy.  Linux distros tend to slice and dice tools and libraries pretty small, and let the package managers deal with the interdependencies.  So a good arduino release would include the yum/deb/rpm/ipk dependencies upon avr-gcc, and thus get updates more automatically as the months go by and the patches get rolled out.

I like that idea in theory, but I find the .app bundles on OSX to be favorable:  far more installable/reorganizable/segmented so different tools or bundles don't conflict with each other.  Disk space is cheap.  Only thing I don't like about it is the fact that only one instance of a given .app can run at a time... ugh.

I don't use Windows except at my day job, so I don't know if I'd rather the avr-gcc stuff be bundled or separate.
Pages: 1 2 [3] 4 5 ... 70