[Code.]

Woo Hoo. My test worked perfectly.

It writes a PROGMEM string into EEPROM then prints the EEPROM text over serial.
This code is also safe, the EString won't overwrite unchanged data, so it only writes the string once.

Code.

Code:

char c0[] PROGMEM = "Test string one.";

void setup(){
 
  PString p = c0;
  EString e( 0 );
 
  Serial.begin(115200);
  e.print( p );
  Serial.println( "-----------------------" );
  Serial.println( e );
  Serial.println( "-----------------------" );
}
void loop(){}

Output.

-----------------------
Test string one.
-----------------------

[Usage.]

In addition to the code I linked to in my last post, here is the PROGMEMReader class.

Usage.

Code:

char c0[] PROGMEM = "Test string one.";
char c1[] PROGMEM = "Test string two.";

void setup(){
  
  PString p = c0;
  
  Serial.begin(115200);
  Serial.println( "-----------------------" );
  Serial.println( p );
  Serial.println( p = c1 );
  Serial.println( "-----------------------" );
}

void loop(){}

Output.

-----------------------
Test string one.
Test string two.
-----------------------

Class.

Code:

class PROGMEMReader : public Printable{
public:
template< typename T >
PROGMEMReader( T *t_DataPtr ) : Start( ( uint8_t* ) t_DataPtr )
{ return; }

PROGMEMReader &operator =( uint8_t *t )
{
Start = t;
return *this;
}
protected:

friend class Print;
size_t printTo(Print& p) const
{
uint8_t *u_Cursor = Start;
size_t s_Return = 0;

while( true ){
unsigned char u_Current = pgm_read_byte( u_Cursor++ );
if ( u_Current == 0 ) break;
s_Return += p.write( u_Current );
}
return s_Return;
}

private:
uint8_t *Start;
};

typedef PROGMEMReader PString;

This is included in the code I will release.

In a previous post here. I have an EEPROMWriter class, that can be used to print the data to eeprom and is passable to print so you can write the eeprom string out to another print, like serial.

EDIT, thanks for your printf input. I agree, the parameter method is best. I didn't intend to write to eeprom from it, just read. Which is what my EEPROMWriter class was originally for.

Just a quick question for all interested.

For EEPROM & PROGMEM control via printf, would you prefer either

• Passing the address as a parameter to printf.
• Have the address as part of the format string.

There are pros & cons to both sides, I have used the parameter approach for now.
Both methods could be written to allow formatting ( printf just prints the stored strings for now ).

To fix it, put your own prototype below the typedef, so CallbackType is defined before its used.

typedef int (*CallbackType)(float); 
void DoWork(CallbackType callback);

The IDE won't add a new prototype if you manually put your own in.

Here is a useful link: http://gcc.gnu.org/projects/cxx0x.html
It appears range based for loops aren't available until 4.6.X

The sprintf used by the AVR's does not have float support, or many other sprintf features.

Here is a library I'm working on at the moment, there is a working 'GString' library which contains an sprintf function:    
String/sprintf alternative for Arduino.

However this requires the Print library, which you'll have if you use the Arduino core.

There is nothing amateurish about it. For sure the Arduino project hosts a large API of code that does make things relatively easy for the beginner; however the Arduino boards are merely a dual role programmer / prototyping board. The workhorse of the boards are fully fledged CPU's.

The AVR ( Uno, Mega, most Arduino boards ) is a complex but easy to learn architecture.
The Arduino DUE uses an extremely complex architecture ( ARM ), where only the learned are able to utilize it maximum potential.

I would say the people claiming the Arduino as amateurish did not have the programming skill to utilize the CPU outside of the Arduino API, therefore relied upon higher-spec platforms to do the same job, but on a faster clock.

Also, if that does not fix it.

I'm pretty sure the beta IDE's have two library folders, one of them is AVR and SAM compatible ( the folder you are viewing ), the other 'libraries' folder is inside the SAM and AVR folders. It should be down the path a bit more:

C:\Users\Adam\Downloads\Apps\arduino-1.5.2-windows\arduino-1.5.2\Arduino\???

Add the SPI.h include to your sketch as well.

The two passed in values are for the CE, and CSN pins.

Here is the documentation I used ( successfully ): http://maniacbug.wordpress.com/2011/11/02/getting-started-rf24/

Well, I imagine when the IDE starts distributing a more modern compiler than the 4 year old compiler they are currently distributing, C++11 features will work.

In their defense the "more modern" compiler is noticeably slower.

Do you mean the compile time or emitted instructions.
I have been interested in C++11 for a while and heard the new AVR compiler produces more efficient code  with things like constexpr and such. Could be wrong though.

Just to bust your bubble, I prefer this:

Code:

enum PINS{
  LED_WARNING = 13
};

Not really, this is equal to the define.
The const is clearly a compile time constant in this context so it is also equal... But this context only, there are various scenarios when a compiler cannot guarantee a variable is a compile time constant, and therefore may not be compiled as one.

Do not use a 'variable' type when you mean 'constant variable', i.e const int over int

I'm not sure if you were using 'Serial' during your tests, or just for debugging. However if during the tests you used serial; you will encounter timing variances.

The serial library uses interrupts to control the UART, so when it runs its ISR it'll halt the timing interrupts which could miss events. Or simply there is too much data to send and it is bogging down the cpu, which takes the time seen in your latencies.

Maybe increase the Serial baud rate, or send less data.

Just to plug my new library here:
I'm working on a new library which will allow you to use print & printf on ram, so you could shrink your sets of Serial.println's into one memory print, then print that to serial. Soon I'll have a patch which will allow Serial.printf(), which will print directly to the output.

Yes robtillaart is correct, it inherits the print library, so it has the same capabilities as the Serial library.

Incase you didn't know, the print and println overloads for float accept a precision parameter.

Serial.print( 123.4567f );      <-- This will print "123.46"

Serial.print( 123.4567f, 4 );  <-- This will print "123.4567"