Go Down

Topic: My top 5 wish list for improvements to the Arduino core library/IDE (Read 3 times) previous topic - next topic

dc42

These are all based on real needs. It appears to me that none of these is implemented in 1.0 beta.

1. Additional member functions print_P and println_P in the Print class, for printing PROGMEM strings

I often see posts on the forum where users report that their sketches don't work since they added a small piece of apparently benign code. The usual reason is running out of RAM, and the most common reason for running out of RAM is use of a large number of string literals. The fix is to move the strings into PROGMEM, however they can't then be printed directly using e.g. Serial.print(). I suggest new member functions print_p(const PROGMEM char*) and println_p(const PROGMEM char*) in the Print class, similar to the corresponding print and println members but taking PROGMEM strings. This would allow for example:

 Serial.println_p(PSTR("Hello world!"));

The _p suffix is in line with other functions that take PROGMEM strings. I have code available for these functions.

[EDIT: in fact the 1.0 release includes a new F() macro for creating strings in PROGMEM, and print/println are overloaded to support it - so print_p and println_p are not required. Thanks to CodingBadly for poinitng this out.]

2. Facility for hooking the tick interrupt

Many sketches need a regular tick interrupt, for example for polling buttons and rotary encoders. I usually use the MsTimer2 library to set up a tick interrupt. However, there is already a regular interrupt used to count millseconds, and it would make sense to hook into this instead, keeping timer 2 free for other uses. See http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1293546475 for a possible implementation.

3. When compiling a sketch, as well as displaying the amount of Flash used, display the amount of RAM used by static data and string literals.

The IDE currently provides no clues to the user that lack of RAM may be an issue. In fact, lack of RAM is much more likely to be a problem than lack of Flash. See http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1224729260/all for a possible implementation.

4. Configurable delay in analogRead() after switching the multiplexer

Another problem that I often see on the forums is users finding that analog pins 'interfere' with each other. The usual suggestion is to read from the pin twice, possibly with a delay between the two reads. However, it would be better to include a configurable delay in analogRead() itself, for two reasons:

(a) including a small amount of delay by default would avoid many users experiencing the problem in the first place;

(b) a delay is more effective than doing multiple analogRead() calls, i.e. a stable reading is achieved in a shorter time.

See http://arduino.cc/forum/index.php/topic,69675.msg517237.html#msg517237 for more details and some measurements I took. The default delay of 10uS that I suggest adds less than 10% to the time taken by an analogRead() call. As an alternative to the suggestion I made in that post, the delay could be passed as an optional second parameter to analogRead().

5. Fix the bug that causes delayMicros(0) to delay for a very long time

This is the sort of bug that may go unnoticed, until an unsuspecting user calls delayMicros with a calculated delay time and the calculation just happens to return zero on rare occasions. See http://arduino.cc/forum/index.php/topic,68383.msg504892.html#msg504892.

Formal verification of safety-critical software, software development, and electronic design and prototyping. See http://www.eschertech.com. Please do not ask for unpaid help via PM, use the forum.

dc42


Re: (4) Note that the analogRead() anomaly is dependent on the source impedance of the analog voltage. The "interference" (crosstalk) and "delay" (settling time) issues are diminished or eliminated by a lower impedance. Hard-wiring factors based on the assumption of marginal circuit design doesn't seem like a desirable thing to me.  Like many design decisions, it is an interaction of several factors, hardware and software.


Yes, the analogRead() problem goes away with sufficiently low source impedance. However, I don't regard using source resistances of greater than 10k as marginal circuit design when the signal is varying very slowly, for example, from a temperature sensor (sampling an audio signal would be a different matter). And I'm not proposing to hard-wire anything, my proposal is for a configurable delay with a fairly low default value.

Presumably, whenever a user reports this issue and is using a sensor with a source resistance of more than 10k, you think we should always tell him/her to add an op-amp to buffer the input pin, rather than use the workaround of reading the pin more than once?

Formal verification of safety-critical software, software development, and electronic design and prototyping. See http://www.eschertech.com. Please do not ask for unpaid help via PM, use the forum.

dc42

Thanks. I completely agree with you that it must be easy to reduce the delay to zero. Also, any default delay must be small enough to have minimal impact on existing sketches.

My objectives behind this proposal are:

1. Reduce the amount of trouble that Arduino newbies have; and

2. Provide a more efficient (time-wise) way of handling source resistance greater than 10K. For example, my measurements indicate that with 100k source resistance, a delay of 10us is sufficient, as opposed to doing a second analogRead call which takes over 100us.
Formal verification of safety-critical software, software development, and electronic design and prototyping. See http://www.eschertech.com. Please do not ask for unpaid help via PM, use the forum.

Coding Badly

1. Additional member functions print_P and println_P in the Print class, for printing PROGMEM strings


void setup( void )
{
 Serial.begin( 57600 );
}

void loop( void )
{
 Serial.println( F( "This is a test." ) );  // <<<
 delay( 1000 );
}


Quote
The fix is to move the strings into PROGMEM, however they can't then be printed directly using e.g. Serial.print(). I suggest new member functions print_p(const PROGMEM char*) and println_p(const PROGMEM char*) in the Print class, similar to the corresponding print and println members but taking PROGMEM strings.


Does not work.  The compiler cannot tell the difference between "const char*" and "const PROGMEM char*".

Coding Badly

4. Configurable delay in analogRead() after switching the multiplexer

Another problem that I often see on the forums is users finding that analog pins 'interfere' with each other. The usual suggestion is to read from the pin twice, possibly with a delay between the two reads. However, it would be better to include a configurable delay in analogRead() itself, for two reasons:


Ideally, analogRead should provide both the delay you recommend and discarding-the-next-value recommended by Atmel.

For each read, ADC Noise Reduction Mode and averaging / filtering would also be useful additions.

This would make a very nice library.   ;)

Go Up