Show Posts
Pages: 1 ... 327 328 [329] 330 331 ... 433
4921  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 ?
4922  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...
4923  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...)
4924  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...)
4925  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.)
4926  Forum 2005-2010 (read only) / Bugs & Suggestions / Re: A proper explanation of the preferences.txt files. on: January 27, 2009, 07:09:49 pm
Quote
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.)

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

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

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

Quote
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.

Quote
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:
Code:
build.verbose=false
into
Code:
build.verbose=true
This will change the amount of output from the compiler that is copied to the cconsole window of the IDE during compiles.
4927  Forum 2005-2010 (read only) / Bugs & Suggestions / Re: Hardware Protection on: January 08, 2009, 06:12:31 pm
Quote
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."
4928  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...
4929  Forum 2005-2010 (read only) / Bugs & Suggestions / Re: Stronger CPU options. on: August 21, 2008, 09:36:06 am
Quote
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?
4930  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...)
4931  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?
4932  Forum 2005-2010 (read only) / Bugs & Suggestions / Re: PROGMEM on: October 20, 2008, 10:32:39 am
PROGMEM is important in an arduino-like sytem, but it's a bit complex to deal with from the beginner perspective.  What would be nice is to wrap the most common PROGMEM usage within an easier-to-use set of primitives:
Code:
Serial.print(FLASHMEM("this is a string in flash"));
4933  Forum 2005-2010 (read only) / Bugs & Suggestions / Re: Reading IR signals.. Arduino is too SLOW?? on: August 02, 2008, 03:07:23 am
Let's get back to the original question...  You have a IR remote control that speaks an unknown protocol, and have been unsuccessful decoding it (or, detecting differences between the buttons?) using assorted combinations of pulseIn() function.  You spent a long time trying different things, mostly based on the assumption that the Arduino was too slow to get correct results in your previous attempt...  So:
  • The arduino is NOT too slow to do this, and in particular, array index addressing is quite fast.  I know it can be particularly frustrating to have spent a lot of time chasing the wrong bug, but it happens, and you need to start over too.
  • You said that the example that used Serial.Print() was "working", while I and a number of other posters have mentioned that Serial.Print() introduces long and somewhat variable delays into your code (on the order of 1ms per output character at 9600bps)  What exactly is your definition of "working" here?  You seem to expect relatively short pulses (<400us), but elsewhere you say you're not sure what the protocol is.  Is it just that the serial-printing code gave you variability of timing, while the array-based code didn't?
  • Aside from the Sony Protocol, the most common IR protocol is Philips RC5 protocol, which you seem to be expecting based on the size of your arrays, but it uses a basic bit time of 1778 us, (always half high and half low, with the direction of change indicating 0 or 1), so I'm not sure why you're expecting short pulses.  For that matter, it's not clear to me that measuring pulse durations for only high or low state is very helpful for decoding RC5...
  • The first step is to get a better picture of what the protocol actually looks like.  It seems you tried to do that with your Serial.print() code, but perhaps were led astray by the delays introduced by serial.print.  Start over storing pulse times in an array, and measuring both high and low times.  (I checked, pulseIn(x,LOW) WILL measure the remaining time if the pin is already low, so you should be able to get to reasonable places with code similar to that shown below, though I haven't actually tried it.)  There will be errors introduced by the start of function and such, but they should be small compared to the multi-hundred us pulse times expected for most IR protocols.
  • I saw an interesting scheme for IR decoding suggested once that consisted essentially of sampling for a certain amount of time at a certain sample interval known to me much smaller than the bit times involved, and calculating a CRC-like value from the samples.  You don't necessarily need to know what the format is to recognize just a few distinct keys, and it takes very little storage...
Code:
for (i=0; i<50; i+=2) {
  times[i] = pulsein(pin, LOW, 5000);
  if (times[i] ==0) break;
  times[i+1]=pusein(pin, HIGH,5000);
  if (times[i+1] ==0) break;
}
for (i=0; i<50; i++) {
  Serial.println(times[i]);
     if (times[i] ==0) break;
}
4934  Forum 2005-2010 (read only) / Bugs & Suggestions / Re: bug with serial port? on: October 08, 2007, 12:14:54 am
They added the capability of having the Arduino software environment reset the Arduino processor, so that you would not have to do the little dance of pushin the reset button and hitting the download button within a relatively small time period.  It also makes it possible for the timer period to be reduced that the AVR waits. deciding whether it should run the existing sketch or the bootload code.  Unfortunately, the USB interface chip that the
Arudino uses emulates a serial port, and the initialization that most software does when you "open" the serial port causes the same reset action on the arduino side.

4935  Forum 2005-2010 (read only) / Bugs & Suggestions / Re: spectra symbol SUCKS! on: February 15, 2008, 05:04:41 am
I think you overreacted some.  "Samples" doesn't necessarily mean "FREE samples"; sometimes it just means that the company is willing to sell you a smaller quantity than they'd normally deal with.  ("Gee, we thought six (12?) samples for $300 was a much better deal than our usual 10k piece, 6w lead time minimum order.")  Understand that if you were a "real company" of the sort they'd LIKE to have as a customer, the $300 would probably be irrelevant; more important would be getting them SOON, without having to go through the dreaded PURCHASING DEPARTMENT.
(but of course in this case they ought to have been more responsive...)
Pages: 1 ... 327 328 [329] 330 331 ... 433