Show Posts
Pages: 1 ... 31 32 [33] 34 35 ... 42
481  Development / Suggestions for the Arduino Project / Re: Serial Monitor Suggestion-Could we please be allowed to change the Font SIZE? on: October 31, 2011, 03:30:49 pm
I uploaded another patch to issue 550.  This new patch makes both the serial monitor and console panel (error messages) use the editor font size selected in Preferences.

http://code.google.com/p/arduino/issues/detail?id=550
482  Development / Suggestions for the Arduino Project / Re: Why not (finally) expose main.cpp to the user ? on: October 27, 2011, 04:05:24 pm
Bump.

This patch became part of 1.0-rc2.  Anyone who really cares about main() might want to give 1.0-rc2 a try before 1.0 officially releases?

http://code.google.com/p/arduino/wiki/Arduino1
483  Development / Suggestions for the Arduino Project / Re: Serial Monitor Suggestion-Could we please be allowed to change the Font SIZE? on: October 27, 2011, 03:56:08 pm
I submitted a patch to issue 550.  It makes the serial monitor font the same size as the editor font.

You can change the editor font size in the preferences dialog box.
484  Development / Suggestions for the Arduino Project / Re: Arduino/Processing and Java RT – save 2x110 MB of disk space. on: October 25, 2011, 07:50:12 pm
Be careful what you wish for!

The Linux version includes pretty much nothing extra, no JRE, not even the avr-gcc toolchain.  It's a tiny download (at least relative to Windows and Mac), but the downside is all sorts of compatibility issues that change in subtle ways over the years.

Just because everything seems to work fine if you delete the bundled JRE on your own machine doesn't necessarily mean it will always be so for everybody, across many versions of Windows and Java spanning 10 years, both now and especially into the future as Microsoft and Oracle change their platforms.
485  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.
486  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.
487  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

488  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.
489  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.
490  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.
491  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.
492  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.
493  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.
494  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.
495  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.
Pages: 1 ... 31 32 [33] 34 35 ... 42