Show Posts
Pages: 1 ... 357 358 [359] 360 361 ... 463
5371  Forum 2005-2010 (read only) / Bugs & Suggestions / Re: Print library is to big on: July 16, 2009, 03:04:29 am
(Normal people can ignore this message!)

/Applications/arduino/arduino-0016/hardware/cores/arduino/wiring_shift.c -o/tmp/build6607.tmp/wiring_shift.c.o
hardware/tools/avr/bin/avr-g++ -c -g -Os -w -fno-exceptions -ffunction-sections -fdata-sections -mmcu=atmega168 -DF_CPU=16000000L -I/Applications/arduino/arduino-0016/hardware/cores/arduino /tmp/build6607.tmp/Temporary_6327_9221.cpp -o/tmp/build6607.tmp/Temporary_6327_9221.cpp.o

hardware/tools/avr/bin/avr-gcc -Os -Wl,--gc-sections -mmcu=atmega168 -o /tmp/build6607.tmp/fastwrite.elf /tmp/build6607.tmp/Temporary_6327_9221.cpp.o /tmp/build6607.tmp/core.a -L/tmp/build6607.tmp -lm
hardware/tools/avr/bin/avr-objcopy -O ihex -j .eeprom --set-section-flags=.eeprom=alloc,load --no-change-warnings --change-section-lma .eeprom=0 /tmp/build6607.tmp/fastwrite.elf /tmp/build6607.tmp/fastwrite.eep
Here are representative compile and link commands from the Arduino IDE build process.  The pieces your eclipse build is missing are probably the pieces that I've made bold.  In the compile "-ffunction-sections" causes each function to be put in its own linker section, and in the link I'm pretty sure that "-gc-sections" causes the linker to garbage collect (omit) any section that isn't referenced from somewhere else.
5372  Forum 2005-2010 (read only) / Bugs & Suggestions / Re: Diecimila resets easily when controlling a mot on: October 31, 2007, 02:05:09 pm
The 3.3V supply is only good for 50mA, which is "not much."  It's common for a flash card to use 100mA or more when it's active (Sandisk uSSD datasheet; couldn't find an actual SD card datasheet.)
5373  Forum 2005-2010 (read only) / Bugs & Suggestions / Re: Diecimila resets easily when controlling a mot on: October 18, 2007, 08:47:57 pm
It would be interesting to know the reason for the reset.  The AVR stores bits in a register that distinguish between power-on reset, brown-out reset, watchdog reset, and reset input reset; I don't THINK that the bootloader clears those bits, so your sketch could examine them and show which had occurred somehow...

5374  Forum 2005-2010 (read only) / Bugs & Suggestions / Re: Arduino sound player on: May 17, 2009, 02:41:01 pm
Your transistor is not connected in a way that will lead to the correct amplification of an analog signal.  I always found analog amplification to be pretty mysterious; the easiest solution is to replace the chip with an audio amplifier chip like an LM386...
5375  Forum 2005-2010 (read only) / Bugs & Suggestions / Re: Arduino 15 hardwareserial on: April 15, 2009, 09:43:47 am
Interesting.  The sketch compiles fine here (MacOSX, arduino-0015)

It looks like the link phase is including both wiring_serial.o and core.a (a library that contains wiring_serial.o), resulting in two copies of the ISR vector.  But it should not be doing so (and it only includes core.a when I compile it here.)

What OS are you running?  Can you turn on build.verbose in the the arduino preferences.txt and post the entire build log ?
5376  Forum 2005-2010 (read only) / Bugs & Suggestions / Re: Crystal selection affects achievable baud rates on: February 23, 2009, 08:11:14 pm
The concern is 115200bps (the default speed for certain Atmel tools like the STK500, BTW.)  Although I'm not convinced that the difference between 57600 and 115200 is very important...
5377  Forum 2005-2010 (read only) / Bugs & Suggestions / Re: Crystal selection affects achievable baud rates on: February 23, 2009, 11:45:42 am
Yah; in the interest of "a computer should never get slower", we can note that 18.432 Mhz allows "perfect" bit rates up to 230400bps, and 20MHz allows up to 115200 with acceptable margins...

I woulda been nice if the low-voltage variants had picked 11.0592 MHz or 9.216 MHz, but I suspect that non-serial-related issues dominated.  (I see that crystal and resonator selection gets really sparse around there...)
5378  Forum 2005-2010 (read only) / Bugs & Suggestions / Re: A proper explanation of the preferences.txt files. on: January 29, 2009, 02:18:40 am
Did you try "tools/burn bootloader/parallel programmer" with your parallel programmer (I assume you built it yourself?  Good job getting it working!)
That should have worked without modifying the preferences, and should have permitted you to continue using the normal "upload" process (via the serial port) (assuming that it was the bootloader that was broken.  The advantage of the built-in USB/serial chip on "official" arduino board is that it removes a LOT of variables that can happen in between your computer and the avr chip...)
5379  Forum 2005-2010 (read only) / Bugs & Suggestions / Re: A proper explanation of the preferences.txt files. on: January 28, 2009, 07:18:57 pm
Hmm.  When my arduino AVR lost it's bootloader, I used avrdude in "bare" form with an STK-500 to re-install the bootloader, and then went back to using the (unmodified) Arduino IDE to download sketches using the (fixed) normal bootloader...

(The problem with helping people fix bootloader problems is that it usually takes some sort of ADDITIONAL AVR programmer to fix, which takes it out the "easy" category.  A generally "correct" piece of advice is that if your brand new arduino doesn't upload programs, you should contact the vendor for advice or replacement.  But that's so "general" as to not be very helpful.)
5380  Forum 2005-2010 (read only) / Bugs & Suggestions / Re: A proper explanation of the preferences.txt files. on: January 27, 2009, 07:09:49 pm
since it (they) are so important to the function of the sketches, and information on it (them) is rather vague.
But they're NOT important.  Important options show up in the menus of the IDE.  preferences.txt holds the things that the IDE "remembers" between invocations (like which sketch you're working on), and it holds settings or a bunch of UN-important options that the IDE designers implemented but left out of the actual IDE because "too many options make a program confusing" (which is quite true.)

How they are created!
They are written whenever the Arduino IDE exits (perhaps other times as well, like if you switch sketches.)

What happens to them!
They are read by the Arudino IDE when it starts up, and used to set various internal parameters.

Where they are stored!
(operating system dependent.)(<username>/Library/Arduino on my Mac.)

How they can be modified, if user finds it necessary!
You can modify them with any plain-ascii text editor, but be sure that you don't have the Arduino app open at the time or it will be overwritten when the IDE exits.

What effect they have on the whole operation!
In addition to remembering options that have been set in the menus that DO exist (bit rate for the serial monitor, etc.), it holds settings for various options that we're important enough to have menu options.  Like, oh, the various colors used in the editor window, and the font used on the buttons.  I couldn't find ANY options that actually affect the "function of sketches." (it MIGHT have had an "extra options to give the compiler" preference.  But it doesn't.)

The items in preferences.txt are supposed to have pretty obvious names, and have pretty exact correspondence to variables in the SOURCE CODE of the ide (which of course you can download and browse.)  I think the basic idea is that if you can't read the source code, and can't guess what the preference variable name might mean, then it's something you probably shouldn't modify unless you've been told to do so by someone who has read the source code.

The most useful thing to change IMO is to make the line that says:
This will change the amount of output from the compiler that is copied to the cconsole window of the IDE during compiles.
5381  Forum 2005-2010 (read only) / Bugs & Suggestions / Re: Hardware Protection on: January 08, 2009, 06:12:31 pm
It is not about the voltage. It is about the pulse power.
Um, my impression was that most of the failures of the sort the OP was talking about occurred when the owner did something really stupid like connected the other side of their LED/whatever to a 12V supply instead of 5V through a resistor...  Most of the time, even the newbies realize they did something bad.  In a way, this is part of the education one SHOULD receive from something like the arduino.

ESD is comparatively easy to protect against, since there's been a lot of interest in doing so.  Protecting an explicitly experimental device against accidental mis-connections of all sorts is nearly impossible (assuming reasonable cost is a requirement.)  We have a saying "It is very difficult to make something truly foolproof, because fools are so ingenious."
5382  Forum 2005-2010 (read only) / Bugs & Suggestions / Re: Hardware Protection on: January 04, 2009, 11:36:08 pm
I don't think a PTC is fast enough to protect semiconductors, and with a low-power device like an arduino, the protection diodes serve mainly to raise/lower the device power rails instead of just a single pin; just as deadly (maybe.)  At about $0.40 per pin, it would be pretty expensive protection (and BIG, too.)

There are multi-line SMD ESD filters that might be a better option for some types of damage (National NUF8000MU), but frankly, An Arduino is at a price point where "replace the main CPU" is adequate for situations that would zap the board...
5383  Forum 2005-2010 (read only) / Bugs & Suggestions / Re: Stronger CPU options. on: August 21, 2008, 09:36:06 am
the ATmega1281 series. For the surface-mount Arduino BT, the difference in prices on Digi-Key between the ATmega168 and the ATmega1281 are basically $0.61. (Granted, it looks like you have to buy quantities in the 100s to order the DIP packaging, but still.)
Huh?  The 1281 is about $9.50 (100s at digikey), compared to $2.39 for 168.  And the 1281 doesn't seem to have a DIP package.  Were you looking at some other chip?
5384  Forum 2005-2010 (read only) / Bugs & Suggestions / Re: PWR_SEL suggestion for next board batch on: September 05, 2008, 05:53:45 pm
No; your explanation helps a lot.  I hadn't considered the case where the battery pack was a physically separate piece from the arduino; I can see how that would be a pain to move back and forth...

You could consider powering the arduino through the USB jack instead of the power jack; that would mean making your battery pack include a 5V regulation circuit, and a USB plug for "output"; using USB jacks/cables for power-only seems to be gaining popularity...

(In fact, I've been wondering if the regulator circuit on arduinos hasn't become nearly obsolete.  It seems these days that I can find 5V 500mA regulated power supplies (mostly from/for cell phones) more easily and cheaply than I can find 9Vdc 500mA supplies...)
5385  Forum 2005-2010 (read only) / Bugs & Suggestions / Re: PWR_SEL suggestion for next board batch on: September 01, 2008, 08:09:00 pm
I don't think I get it; you don't have to set the board to USB power just to connect it to USB; if you're developing a battery-powered application, why don't you want to run off the battery (or other external power) ALL the time?
Pages: 1 ... 357 358 [359] 360 361 ... 463