Show Posts
Pages: 1 ... 22 23 [24] 25 26 ... 40
346  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:

http://code.google.com/p/arduino/issues/detail?id=854

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.
347  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:

http://arduino.cc/forum/index.php/topic,100503.0.html

One of many bugs fixed was a terrible inefficiency in the serial interrupt.
348  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.
349  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.
350  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.

351  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.
352  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.
353  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.


Quote
(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.
354  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 http://www.pjrc.com/teensy/td_libs_AltSoftSerial.html

Code:
// 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 ALTSS_USE_TIMER5
 #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 http://www.pjrc.com/teensy/td_libs_FreqCount.html

Code:
// 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 http://www.pjrc.com/teensy/td_libs_FreqMeasure.html

Code:
// 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
355  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.
356  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
Compare:

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

Under version 1.0, compiles as:

Code:
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.
357  Development / Suggestions for the Arduino Project / Re: arduino and rasberry pi on: April 11, 2012, 11:25:42 am
Just get the Linux version of the arduino IDE and run it on the Pi, there is no need for anything to be developed.

Actually, working ARM versions of gcc-avr, binutils-avr, avr-libc, avrdude and librxtx would be needed.  A working java runtime is also required.  Hopefully the Linux distro will provide all that?  Do any ARM distros currently provide all these?

Especially for avr-libc and gcc-avr, the specific older versions that Arduino uses on Windows and Mac, and will soon also provide on Linux with 1.0.1 (at least for 32 and 64 bit x86 platforms), should be used rather than the latest ones.

The Pi's limited 256 megs of RAM might also be an issue.  On my 32 bit x86 Linux machine, java shows 70 megs resident (and far more virtual) immediately upon launch, and of course it grows substantially with use.  Running gcc requires quite a bit of memory, if only temporarily, but if the usual Linux desktop stuff is running, and java, it's very likely that 256 megs is going to run out.  Then the already-not-very-fast Pi will need to start swapping to its SD card.  Even the class 6 speed cards are quite slow compared to conventional rotating disks.  While it technically may "work", there is an "unusably slow" point, where waiting is just too distracting from the task of developing and troubleshooting a project.
358  Development / Suggestions for the Arduino Project / Re: minimizing codesize by removing println() in favor of print('\n'); on: April 11, 2012, 09:29:32 am
Teensyduino has a heavily optimized Print (and many other Arduino functions).  Here's the code I wrote for Print::println():

Code:
size_t Print::println(void)
{
        uint8_t buf[2]={'\r', '\n'};
        return write(buf, 2);
}
359  Community / Bar Sport / Re: Arduino Due - what will be the killer app(s) on: April 03, 2012, 12:07:07 pm
How compatible is Maple?

Sure, pinMode, digitalWrite, analogRead, etc probably work fine.  But what about most libraries and more complex sketches?
360  Development / Suggestions for the Arduino Project / Re: Will we ever see higher spec chips in the Arduino on: April 01, 2012, 06:38:44 am
Yes that is my point, the hardware abstraction can take place under the hood like it is done now and most users will be non the wiser.

Sadly, the Arduino world is filled with sketches and libraries that directly manipulate the timers and ports.

While pinMode, digitalWrite and digitalRead do provide a nice hardware abstraction, lots of authors are dissatisfied with their sluggish performance.  Several libraries, like Capsense, Ping, OneWire and others legitimately need the performance and can't work well with the 50-some cycles taken by digitalWrite.  But in many other cases I've seen, authors are simply familiar with directly manipulating the ports and do so, even if their code spends much of its time in delay().

Even with the Arduino functions are used, a very AVR trick is used to activate the pullup resistors.  All ARM chips, and even AVR XMEGA, use a separate register to control the pullups, rather than repurposing the output register when the pin is using input mode.  Arduino 1.0.1 will finally provide INPUT_PULLUP with pinMode(), but there is already a vast amount of code written which depends on the AVR register behavior.

When it comes to timers, Arduino provides nothing other than polling with millis() or micros().  A good portion of all Arduino libraries directly manipulate one or more hardware timer, with lots of AVR timer register assumptions built in.  If you look at ChipKit and Maple, very few libraries are compatible.  Usually it's timers.

Arduino has also been long missing a number of other important features.  In their absence, authors have resorted to direct hardware access.  For example, I recently worked on porting (only to Teensy with non-UART "Serial", not a non-AVR chip) a sketch that allowed a specific software package to control several stepper motors.  It was based on a big polling loop that depending on non-blocking access to Serial and the motors.  Of course, Arduino's Stepper library is a fully blocking API (only 1 stepper can move at a time).  Until very recently, transmitting on Serial also blocked if more than 2 bytes were sent.  So the author wrote his own stepper control code, using direct port manipulation, and wrote all the output to a buffer, with direct access to the UART registers to incrementally transmit the buffer contents only when the UART was ready for another byte.  Had Arduino offered something like Serial.available() to know if writing would block, that sketch probably wouldn't have directly hit the UART and might be portable to a future ARM-based board.  But like so many Arduino application, the gaps in Arduino's functionality required direct hardware access.

Eventually Arduino is going to need to provide a more complete API.  It's so very unfortunate that the motivation to design the API with forward thinking towards future platforms hasn't been present all these years.  So many very compelling sketches and libraries have been written over the last couple years.  A great number that do anything "interesting" are unable to use only the Arduino functions without resorting to AVR-specific direct hardware manipulation.

Even today, lots of sketches work on Uno but not Mega.  When/if Due is released, certainly simple LED blink examples will work, but it's going to be take a lot of work for many of the compelling libraries and sketches are ported.
Pages: 1 ... 22 23 [24] 25 26 ... 40