Show Posts
Pages: 1 ... 23 24 [25] 26 27 ... 41
361  Development / Other Software Development / Re: Arduino Library downloader on: May 02, 2012, 10:05:17 am
Indeed, maintaining a good list of Arduino libraries is a challenge.  My goal isn't a comprehensive list, but only the most important and most useful ones.  One of my main interests is learning of new libraries as early as possible, rather than random chance (either I see it online, or someone asks me for help using it with Teensy).

I could generate an xml file for the libraries I've tested and plan to test.

There are several details in the sample xml I don't quite understand.  Each "lib" has an id number, starting at 19.  How are they assigned?  Do I just make up numbers?  Likewise, there's a "category" tag, with id=1.  What that about?

In the xml, links to the zip file are in a "versions" section.  What should be done for libraries which don't have a clearly published version number?

There's also an "authors" section.  All in the example are "sascha".  What does that mean?

The XML doesn't provide any means to embed one or more URLs where documentation about the library is maintained.  At least that doesn't seem to be in the example.
362  Development / Other Software Development / Re: Arduino Library downloader on: May 02, 2012, 09:17:42 am
I could probably write a script to generate xml.

Is Ardulibrary still in development?
363  Using Arduino / Networking, Protocols, and Devices / Re: AltSoftSerial Library on: April 26, 2012, 01:13:38 pm
From what I can tell your library does not use pin change interrupts, can you confirm this?

Confirmed, pin change interrupts are not used.

Also you mention that PWM on pin D10 can't be used.  I assume I can still use D10 for other functions just not PWM?

Yes.  I've added some text to the web page to clarify this point.

How does code size compare to NSS?

I didn't compare.  Maybe you can tell me?

Just click "Verify", make a note of the size, then change just a couple lines your code to switch to AltSoftSerial, and click Verify again.  Subtract the numbers.... pretty easy!
364  Development / Suggestions for the Arduino Project / Re: Arduino 1.0 IDE Compatibility with previous versions on: April 24, 2012, 04:40:48 pm
I really don't think merely "starring" (a.k.a. voting for) the issue on google code will be noticed.
David does monitor the issue list, at least for reading new issues, but I doubt old ones get much attention unless brought up in a conversation.

Obviously the Arduino developers do participate on the developer mail list.  My frustration with that list is involves the philosophical responses, usually without having even read, not to mention actually compiled and used the code in question!  Often it seems a useful bit of code or a practical idea gets lost in a swarm of off-topic responses.

365  Development / Suggestions for the Arduino Project / Re: Arduino 1.0 IDE Compatibility with previous versions on: April 24, 2012, 04:45:12 am
yet, the changes made to Wire API, for example, have broken many of these libraries and left users who depended on them in a weird kind of ("gee, everything broke when I updated to 1.0" limbo.  Would it really have been that hard to include additional methods to allow for backwards comparability with these libraries until their respective authors could have time to update them and, more important, have time for these updated libraries trickle down into all the secondary sources, projects and books that reference them.

Several weeks ago, actually on March 11, I tried to bring this exact idea up on the Arduino developer mail list, to be included in 1.0.1.  

Of the many lingering 1.0 incompatibility issues, legacy sketches and examples using Wire seems to be the most persistent.  Nearly all widely used libraries have been updated, so the initial pain of changes like WProgram.h to Arduino.h have largely been solved.

I submitted issue 854 with a patch.  Here's the URL:

You can read the developer list archives on March 11-12 if you want to see the conversation.

Eight people gave opinions, where 3 of those 8 were from the Arduino Team.  Tom Igoe replied "That's a good idea."  Massimo Banzi wrote "Personally I think we warned people well in advance that we were going to break a few things in order to have a more consistent 1.0 release.  We clearly stated that 1.0 was going to be stable in the future."  David Mellis responded (on the issue tracker) "I'm not quite convinced this is a good idea, but if we're going to do it, we should do it for 1.0.1.  Will consider."

Responses from others also varied, with some in favor, some against, and some neutral, including Todd Krein (who's actively working on Wire) willing to go with whatever the decision ended up being.

With Massimo and David seemingly against, I decided not to advocate this patch further.  It's still on issue 854, and I'm planning to keep it as part of the Teensyduino installer for the forseeable future, so at least people using Teensy will automatically have pre-1.0 sketches using Wire work automatically.  I honestly believe it would benefit so many Arduino users if included in the upcoming 1.0.1 release, with no practical downside.  That's why I went to the trouble to create it for Teensy users, and the additional effort to prepare an issue+patch and write up a lengthy post to the developer list to advocate it.  Much as I'd like to see this in Arduino 1.0.1, it's simply not my decision, nor within my ability to convince those who do.

Sadly, the playground, old forum and numerous websites will probably never be fully updated or purged of old Wire library examples.
366  Topics / Robotics / Re: interrupt issues: Adafruit motor shield + servo + timer interrupt + arduino on: April 17, 2012, 12:36:51 am
2. If If the Arduino receives serial data while this is happening I can hear breaks in the hum, which tells me I am losing steps over time.

Perhaps you might try 1.0.1-rc2, or 1.0.1 if you see this message after it's officially released.  Until then, here's where you can get it:,100503.0.html

One of many bugs fixed was a terrible inefficiency in the serial interrupt.
367  Development / Suggestions for the Arduino Project / Re: Programming speed. on: April 16, 2012, 04:12:06 pm
I'm afraid I must revise my time to 7 seconds.  I thought about this again and realized much of the data I was uploading was blank.  I copied a 120K jpeg image into the data set used in the initial disk image.  During upload, the erase step before the upload begins takes longer if the memory was previously programmed with non-blank data.

I measured 7 seconds to upload 127K to a Teensy++, using the digital kitchen timer, from the instant I clicked the Upload button in Arduino until the LED begins blinking when the code starts running.
368  Development / Suggestions for the Arduino Project / Re: Access to T1,T3 and T4 inputs on Mega 1280, etc. on: April 16, 2012, 03:49:29 pm
But that doesn't mean that you'll get official agreement that T1/T3/T4 should have been accessible...

Maybe not, but I would absolutely agree with wholder's original post.  It's a shame those pins weren't at least brought to pads within the large interior space of the Mega, and assigned higher pin numbers, so they could at least be used.

It is a strength of Arduino that hardware can be utilized.  But in this case, with 4 on-chip 16 bit timers, only 2 of them have ICP pins exposed and only one has the clock input pin exposed.  You can't actually use those other timers for these hardware functions, much like a Basic Stamp, due to design decisions made in the board layout and pin assignments.

I believe that's really unfortunate.
369  Development / Suggestions for the Arduino Project / Re: Programming speed. on: April 16, 2012, 05:16:33 am
Paul Stoffregen: Is that 127KB a uploading performance test or an application you have?

I just clicked the Upload button in Arduino and watched a clock window on my computer, which admittedly isn't highly accurate, especially since I'm looking at the LED on the board and then I look over at the screen to see how many seconds elapsed.

I just tried it again, using a digital kitchen timer (with 1 second precision), where I click the Upload button with 1 hand and the timer start button with the other hand.  The sketch I'm loading is File > Examples > Basics > Blink with the pin changed to 6 (since Teensy++ has a LED on pin 6), and I set the Tools > USB Type to "Disk(internal)" (which causes all unused flash memory to become a tiny USB disk drive, creating a maximum size upload of 127K).  After clicking Upload, I stare at the LED with my finger on the stop button, which I press the instant the LED lights again.  The first second or so it continues to blink, while the PC compiles code, and then stops blinking during the actual upload.  It lights up again when the freshly-uploaded code begins running.  That occurs right after the timer advances from 4 to 5 seconds, so it's between 5 to 6 seconds, but much closer to 5 than 6.  Sorry, I don't own a sub-second stopwatch.  I could build something, but I'm not going to.  This is as accurate as I'm willing to measure for the sake of this conversation.

Again, the 5 second is from the moment the Upload button is clicked until the LED starts blinking again, so it includes the compile step and any overhead, and perhaps a slight error of human reaction time.

I stopped when the LED lights, but since Teensy is a native USB device which has just rebooted, the PC takes a moment to detect the newly-connected USB device.  I did NOT measure the extra time (on the scale of a second or two) until Linux fully enumerates the USB device and the kernel and udev deamon create new device files, and a moment later a new window appears showing the files (since in this test Teensy was configured to be a USB disk).

While those 5 seconds do include the compiling, when using Teensyduino, Arduino is patched with a speedup which avoids recompiling previously compiled files.  I contributed this code to Arduino and it has become part of 1.0.1-rc2, so you can grab that version for a small speedup in the compile step.  I repeated this test, but changed boards back and forth before clicking upload (changing Tools > Board causes a full recompile).  It measured 6 seconds, and the timer had been on 6 and might have been just about to advance to 7... so the full recompile adds about 1.5 seconds on my machine (which is Ubuntu 10.10, 32 bit, on a 2.8 GHz core2 processor, 2009 vintage).  The full recompile for Teensy probably takes longer than Arduino Uno, since it's recompiling a complex USB stack as well as all the usual Arduino functionality.

Anyway, that's exactly how I measured 5 seconds for 127K upload, since you asked....

Trust me, one of the first comments I regularly hear from long-time Arduino users when they try Teensy is how much faster the upload goes.  It's native USB with a specially written application, so it ought to be fast!  The speed varies slightly on each operating system, but it truly does upload very quickly compared to using AVRDUDE on conventional boards.

370  Development / Suggestions for the Arduino Project / Re: Access to T1,T3 and T4 inputs on Mega 1280, etc. on: April 16, 2012, 04:41:20 am
I can see it as in the best interests of Arduino that the use of special purpose functions of particular pins on particular variations of particular Arduinos be discouraged.

Does that mean I should not have written those 3 libraries?

Many people have used them in their projects.

Especially AltSoftSerial has made a lot of people's projects "magically work" in cases where SoftwareSerial / NewSoftSerial caused trouble with simultaneous data on HardwareSerial or other libraries.  AltSoftSerial can offer low interrupt latency (less interference with other functions using interupts) only because it uses the special timer input capture and output compare waveform generation features.
371  Development / Suggestions for the Arduino Project / Re: Programming speed. on: April 14, 2012, 12:19:30 pm
For another data point, writing 127K to a Teensy++ using Linux (32 bit) takes approx 5 seconds.
372  Development / Suggestions for the Arduino Project / Re: minimizing codesize by removing println() in favor of print('\n'); on: April 14, 2012, 11:55:39 am
Tell the truth - did you actually optimize it, or did you just avoid bloating it?  :-)

Teensyduino's "Serial" isn't HardwareSerial at all.  It's completely different code for USB virtual serial.  There is a highly optimized Serial.write(buf, size) function which does block copy directly to USB packet buffers using 2 instructions per byte.  It's optimized for speed, not minimal code size.

Teensyduino's Print has many optimizations that try to maximize use of write(buf, size), rather than writing 1 byte at a time.  Recently Arduino's Print class has started implementing some of these, but in many places it still writes 1 byte at a time.  With HardwareSerial, it doesn't matter, since write(buf, size) is just a loop which repetitively calls the single byte write.  But with Teensyduino's Serial, and with Ethernet and the SD card library, using block writes is much faster.  These Print optimizations are separate from optimizations in the code which actually implements available/read/write I/O.  For streams than use block copy, it makes a huge improvement in performance.

End-to-end speed depends on many software factors, including the software on the PC side, but many people have reported easily achieving 300 kbytes/sec (yes bytes, not bits), and speeds in the 800 kbyte/sec range are possible.

(It's been a bit depressing to watch Serial grow and grow with nearly every release...  Despite contributions that would improve things.)

Yes, Arduino's HardwareSerial is horribly inefficient.  The use of indirect addressing for all the I/O registers and constants is terribly inefficient on AVR hardware.  Somebody obviously felt 1 copy of the code, no matter how complex and inefficient, would be better than a separate copy for each port.  From a maintenance perspective, maybe it is, but the trade-off is slow performance and unnecessary compiled code size.

At least 1.0.1 changes the index variables to unsigned, so the interrupt won't use the math library to implement the modulus operator!  That's actually a huge improvement in interrupt latency.

Teensyduino also has a HardwareSerial which is heavily optimized, but it only needs to support a single hardware serial port.  If there were 2 or more, I'd make copies.  It's similar to the pre-0015 version Arduino had, but it has a number of small optimizations which have never appeared in any version of Arduino.

All this code I've published is open source.  If anyone really cared, it could be ported back to Arduino, or at least mined for ideas to separately optimize the Arduino version.
373  Development / Suggestions for the Arduino Project / Re: Access to T1,T3 and T4 inputs on Mega 1280, etc. on: April 14, 2012, 09:13:12 am
My goal was to write a library that might be useful to others.  But, if it's only going to be usable on a narrow set of Ardunio variants, why bother...

I've hit similar issues with a couple libraries I've published.  Usually I just use #define in a header, and in the web-based documentation I only document the default setting.  But if anyone looks in the header, I have commented out the other possible timers.  Occasionally I get emails from people asking if I can add lines for the other on-chip timers.  Of course, it's impossible since those pins don't have numbers assigned and can't be accessed, at least not without extremely difficult soldering.

For example, in AltSoftSerial

// Arduino Mega
#elif defined(__AVR_ATmega1280__) || defined(__AVR_ATmega2560__)

 //#define ALTSS_USE_TIMER4
 //#define INPUT_CAPTURE_PIN            49 // receive
 //#define OUTPUT_COMPARE_A_PIN          6 // transmit
 //#define OUTPUT_COMPARE_B_PIN          7 // unusable PWM
 //#define OUTPUT_COMPARE_C_PIN          8 // unusable PWM

 #define INPUT_CAPTURE_PIN              48 // receive
 #define OUTPUT_COMPARE_A_PIN           46 // transmit
 #define OUTPUT_COMPARE_B_PIN           45 // unusable PWM
 #define OUTPUT_COMPARE_C_PIN           44 // unusable PWM

In FreqCount

// Arduino Mega
#if defined(__AVR_ATmega1280__) || defined(__AVR_ATmega2560__)
  // #define COUNTER_USE_TIMER1 // T1 is not connected
  // #define COUNTER_USE_TIMER3 // T3 is not connected
  // #define COUNTER_USE_TIMER4 // T4 is not connected
  #define COUNTER_USE_TIMER5    // T5 is pin 47
  #define TIMER_USE_TIMER2

In FreqMeasure

// Arduino Mega
#elif defined(__AVR_ATmega1280__) || defined(__AVR_ATmega2560__)
  // #define CAPTURE_USE_TIMER1    // ICP1 is not connected
  // #define CAPTURE_USE_TIMER3    // ICP3 is not connected
  #define CAPTURE_USE_TIMER4       // ICP4 is pin 49
  // #define CAPTURE_USE_TIMER5    // ICP5 is pin 48
374  Development / Suggestions for the Arduino Project / Re: minimizing codesize by removing println() in favor of print('\n'); on: April 11, 2012, 06:24:15 pm
Teensyduino is where the F() macro started.... of course also with input from Mikal Hart and Brian Cook, and then it was contributed to Arduino.  Teensyduino supports it on 0022 and 0023.  Even if you're not using Teensy, you could install Teensyduino and copy-n-paste bits from Teensy's Print.cpp to get a F() that works in 0022.
375  Development / Suggestions for the Arduino Project / Re: minimizing codesize by removing println() in favor of print('\n'); on: April 11, 2012, 05:10:41 pm

Binary sketch size: 1500 bytes (of a 32256 byte maximum)

Under version 1.0, compiles as:

Binary sketch size: 3480 bytes (of a 258048 byte maximum)

Yes, but 1.0 also magically increased your maximum size from 32256 to 258048.  That's a pretty impressive upgrade!!!

Or perhaps you tested 0022 on Uno and 1.0 on Mega?  The code sizes between boards aren't really comparable, since lots of extra code gets included to support Mega's 4 serial ports, extra timers and so on.
Pages: 1 ... 23 24 [25] 26 27 ... 41