Show Posts
Pages: 1 ... 29 30 [31] 32 33 ... 40
451  Development / Suggestions for the Arduino Project / Re: Serial Monitor Suggestion-Could we please be allowed to change the Font SIZE? on: October 24, 2011, 08:13:20 pm
Maybe like issue 550.  I filed this bug after helping someone with limited vision get started with Arduino.  Sadly, he just couldn't make use of the serial monitor.

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

So far this issue hasn't been accepted, not to mention given a milestone.
452  Development / Suggestions for the Arduino Project / Re: Regression between uno and uno R2 VALIDATED. HARDWARE PROBLEM CONFIRMED on: October 24, 2011, 04:20:26 pm
It might be difficult to add anything to the 8u2 firmware, since it currently fills all but 6 bytes of the available space.
453  Development / Suggestions for the Arduino Project / Re: Why not (finally) expose main.cpp to the user ? on: October 23, 2011, 01:33:35 pm
Done, issue #691, including a patch!  smiley

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

454  Using Arduino / Project Guidance / Re: Sanguino, servo, LCD, and serial... on: October 20, 2011, 06:56:52 pm
This sounds like issue 146

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

Maybe Sanguino never implemented this fix?

Just look at digitalWrite() inside wiring_digital.c to see if it's properly disabling interrupts when writing to the port register through the pointer.  Copy the fix from issue 146 and your jitters will probably be a thing of the past.
455  Development / Suggestions for the Arduino Project / Re: Why not (finally) expose main.cpp to the user ? on: October 19, 2011, 08:15:37 am
I believe the idea was to allow 3rd party boards to use the standard Arduino core more easily.  All the pinout-specific stuff is supposed to go into a single header file, and boards.txt can specify the directory.  So in theory, a board which only needs to customize pins could just add a directory and its own copy of pins_arduino.h, and not need to modify any files, except perhaps boards.txt.

Compiling the code into main.cpp was probably just an oversight?  It very likely belongs in either wiring_digital.c (where it's actually used), or in its own dedicated .c file (as it was in prior to 1.0).

If you delete the ARDUINO_MAIN line from main.cpp, and add it into wiring_digital.c like this:

Code:
#define ARDUINO_MAIN
#include "wiring_private.h"
#include "pins_arduino.h"

I believe that solves this problem.
456  Development / Suggestions for the Arduino Project / Re: Why not (finally) expose main.cpp to the user ? on: October 16, 2011, 04:05:30 pm
You CAN use main() instead of setup() and loop().  Really, yes, you can.

Quote
void setup() {
  Serial.begin(9600);
  Serial.println("setup does not run");
}

void loop() {
  Serial.println("loop does not run");
}

int main() {
  init();
  Serial.begin(9600);
  while (1) {
    Serial.println("My main is running");
    delay(1000);
  }
}

This works because main() is inside the core, which gets compiled to a ".a" library archive.  If you use any function with the same name, the linker will put your copy into the final output, rather than the one from the library.

So go ahead and use main().  The ability to do so has been there all along.  Just make sure you call init() to initialize the hardware, so things like millis() and delay() will work properly.
457  Development / Suggestions for the Arduino Project / Re: My top 5 wish list for improvements to the Arduino core library/IDE on: October 02, 2011, 06:02:49 pm
You're right about the danger of keeping interrupts disabled too long.  If the callback is made from interrupt context, interrupts really need to be re-enabled.  Yes, that uses even more stack space, possibly risking an out-of-memory collision, but there really isn't much other option for interrupt context.

However, another option would be to avoid interrupt context calls completely!  That decision was made for the new serialEvent.  The huge advantage is the user doesn't need to use volatile variables and carefully disable interrupts or use some other design that assures atomic access to shared data structures.  Those are such difficult topics that normal context callbacks are pretty compelling, even if their latency is much worse.

To be useful, the callback would have to be made from a number of places that block, and maybe even some that don't if users build long-lived looping structures calling them.  From delay() would be the most obvious.  The blocking in Serial.write() when the buffer is full would be another obvious place.
458  Development / Suggestions for the Arduino Project / Re: My top 5 wish list for improvements to the Arduino core library/IDE on: October 02, 2011, 05:37:47 am
I agree, at least partially, yes, a periodic callback can easily enable a programmer to burn far too much CPU time.  But does that really mean it shouldn't be available at all?  If they really need to check something periodically, consider the alternatives.

If it's polled in loop(), together with lots of other stuff, the polling has tremendous jitter, and the worst case times can become really horrible if Serial.print() or some other function blocks.  The Bounce library is a great example, where failure to keep each loop() execution short enough could possibly miss a short duration button press entirely!

Given the choice between a novice using a library that silently burns 6% of the CPU time for highly reliable performance versus reliability hinging upon that novice user's ability to constrain the total worst-case time that loop() runs, I'd go for highly reliable easy-to-use libraries.

Today, that choice is already made in many libraries, which commandeer the timers for this sort of purpose.  Perhaps they use slightly less CPU time than they otherwise would, but the trade-off is interfering with PWM on certain pins, incompatibility with other code using those timers, and lack of portability between chips.

There are a lot of trade-offs.  I don't have any perfect answers that avoid all potential undesirable outcomes.  But I do believe a periodic interrupt-context callback can be useful, especially for library authors.  Just because it can't be done perfectly doesn't mean it isn't worth doing.  I believe, despite imperfections, it could offer a much better alternative to how some things are currently done.
459  Development / Suggestions for the Arduino Project / Re: My top 5 wish list for improvements to the Arduino core library/IDE on: September 30, 2011, 09:53:41 am
I like a lot of these ideas.

A simple Arduino-style API really is necessary.  If it's even moderately complex, there's zero chance it will ever be accepted as a contribution to Arduino.
460  Development / Suggestions for the Arduino Project / Re: My top 5 wish list for improvements to the Arduino core library/IDE on: September 30, 2011, 08:39:45 am
Yup, all code is in flash on AVR, so any callback would need to be a RAM-based pointer which is tested at runtime.  Any implementation would eat a bit more CPU time, even if the feature is never used, just for checking the pointer.

My 2 main implementation concerns are how to allow multiple callbacks, since this is likely to be used by libraries without the user being aware, and what to do if the callback uses too much CPU time (eg, about 16200 CPU cycles).

One possible way to deal with the CPU time issue would be to re-enable interrupts before calling.  A flag would need to be set, so if the timer0 interrupt happens again before it returns, no additional callbacks are made.

Enabling multiple functions needs to work.  A library like Ethernet could really benefit, so it could flush partial packets after a short timeout, rather than the horribly inefficient approach of placing every call to Serial.write() into its own packet.  But if a project uses Ethernet, which might use a timer callback without the user's knowledge, the user will still expect to be able to have their own callback, or use some other library which also requires a callback.

Maybe a linked list with malloc makes sense?  Or maybe a small fixed size table might work?

I know 1000 Hz (actually 976 Hz) rate would be nice for some applications.  But if the API offers one callback for every timer0 ISR, and if multiple callbacks can be registered, even if the functions do very little, such a scheme could quickly consume all available CPU time calling several every tick.  A slower callback rate, like 244 Hz or 97.6 Hz could still be very useful.

If an application or library really needs a high rate of timer interrupts, it's best path is to commandeer one of the other timers, rather than getting a CPU-hogging callback from timer0.  Several libraries do this today, and having looked at several of them, their needs are pretty specialized.  I do not believe a scheme for sharing timer0 will work well for applications which need good performance.

But it would be really useful for slower things, like implementing automatic timeouts, debouncing pushbuttons, etc.
461  Development / Suggestions for the Arduino Project / Re: My top 5 wish list for improvements to the Arduino core library/IDE on: September 28, 2011, 07:15:54 pm
Thanks for this list.  While I have pretty much no control over the official Arduino IDE and environment, I'm always looking for ideas to incorporate into Teensyduino.

Teensyduino already has #1 and #5 for, for 0022 and earlier, and also 1.0-rc1.

The F() macro and flash string support appearing in 1.0 was contributed by me, with help and input from Mikal Hard and Brian Cook, both on the Arduino developers list and in private followups.  I realize the _P suffix is commonly used by avr-libc and other programs.  It was discussed, but there was strong consensus it wasn't Arduino's API style.  Had I gone with a _P suffix, this contribution never would have been accepted (it took many months as-is to convince the Arduino Team to merge it).

Something they did not accept, but I tried to contribute, was F() flash-string integration with the String class.  So you can use F() with XYZ.print(), but not with anything that takes the newer String objects.

Teensyduino has a heavily optimized delayMicroseconds(), which works for 0 and also small values, with exactly cycle-accurate delays for the common const input case.  If anyone wants to see it in Arduino, the code is available.  I doubt it ever be accepted, because my coding style and extreme use of inline assembly is not consistent with Arduino's coding style.  But if you want this fixed, it is indeed fixed in Teensyduino and the code is open source (after installing, look in hardware/teensy/cores/teensy).

#3 is on my serious wish-list.  I worked on some elf/drawf parsing code to extract the call tree and stack framing info from the debug data inside the .elf file.  It's quite tricky, and of course if recursion is detected you can't know worst-case stack use.  I may never get this written, but I really, really want to have this feature, since running out of RAM really sucks.

I'm also really interested in #2, but if I develop it for Teensyduino and Arduino proper never accepts it, I wonder how much use it would ever get?  The huge benefit I see is for libraries.  I was considering a table of perhaps 5 or 10 callbacks, which could be triggered at something like 100 Hz (so with 10, the ISR would never need to call more than one).  That way, if the user needs 1 or 2, and uses a couple libraries than each need 1 tick callback, everything would still work nicely.

I'm open to ideas on this, and there's a very good chance I'll implement it in Teensyduino at some point, but my hope is the Arduino developers can at least buy into the idea and commit to an outline of the API... so it doesn't end up being a contribution they'll never accept.  (while many things I've contributed are now part of Arduino, on average most of the stuff I try to contribute never gets used... eg, look at issue #140).

Anyway, my point of this lengthy rambling post is I am indeed working on some of this stuff for Teensyduino, and a couple have been available for over a year.  I generally do try to contribute my improvements back to Arduino when they're general to the hardware, but usually it takes a very long time for any contribution to be accepted into Arduino proper, and often they just sit unused indefinitely.
462  Development / Suggestions for the Arduino Project / Re: Suggestion for Arduino Leonardo on: September 28, 2011, 06:32:11 pm
Joystick and Midi are available in Teensyduino, so it's probably only a matter of time until they're ported or reimplemented in Leonardo.  If you have a Teensy 2.0, you can use them in Arduino now!

Audio would be really interesting.  LUFA does it, with callback and/or tightly coded loops to keep up the speed..... but how would an audio stream integrate with Arduino?  Would you pass blocks of samples with Mic.write(buffer, len); ?  It's be really easy to get a buffer underrun.
463  Development / Suggestions for the Arduino Project / Re: Compile Speed - testing & feedback needed! on: September 22, 2011, 11:24:53 am
As a final followup, I prepared a patch and posted it to issue 638.

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

Due to the underwhelming response, I'm not planning to work further to contribute this feature to the larger Arduino community.  The source is there if anyone wants to use it, or continue to improve it and advocate its use.
464  Development / Suggestions for the Arduino Project / Re: Arduino Due with SAM3U4E on: September 20, 2011, 06:50:20 pm
But will it be "cheap"?  Has any pricing been announced?  What if it ends up being in the same price range as Arduino Mega?
465  Development / Suggestions for the Arduino Project / Re: Compile Speed - testing & feedback needed! on: September 20, 2011, 06:48:16 pm
Yup, it only speeds up the compile part.

If you're using Teensy, the data transfer goes pretty fast, since it's full USB speed.  I recently discovered that Teensy can go even faster.  It turns out much of the time is wasted waiting for operating system scheduling.  I'm planning to overhaul the process to use overlapping async I/O to remove the dependency on operating system scheduling.  I like things to go fast!

The process for official Arduino boards isn't under my control.  In fact, with Teensyduino, I try very hard to make sure I don't accidentally alter anything about how non-Teensy boards work.  That's why you need to copy that line into boards.txt to enable this.
Pages: 1 ... 29 30 [31] 32 33 ... 40