Show Posts
Pages: 1 ... 69 70 [71] 72 73 ... 150
1051  General Category / General Discussion / Re: Should I start with Arduino? on: May 25, 2013, 05:47:44 am
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.
1052  Products / Arduino Due / Re: Due and the SD Library on: May 25, 2013, 04:29:30 am
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:

Quote
C:\Users\Adam\Downloads\Apps\arduino-1.5.2-windows\arduino-1.5.2\Arduino\???
1053  Products / Arduino Due / Re: Due and the SD Library on: May 25, 2013, 04:26:03 am
Add the SPI.h include to your sketch as well.
1054  Using Arduino / Networking, Protocols, and Devices / Re: nRF24L01+ and roles on: May 25, 2013, 04:08:01 am
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/
1055  Using Arduino / Programming Questions / Re: Arduino does not understand a ranged FOR loop on: May 24, 2013, 10:42:05 pm
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.
1056  Using Arduino / Programming Questions / Re: Which one is faster or better ? why? on: May 24, 2013, 08:23:14 am
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
1057  Using Arduino / Programming Questions / Re: Program Execution and Timing on: May 24, 2013, 08:17:22 am
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.
1058  Development / Other Software Development / Re: LiquidCrystal print() reference page doesn't show print(float) on: May 24, 2013, 08:04:58 am
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"
1059  Development / Other Software Development / Re: String/sprintf alternative specifically for Arduino. on: May 23, 2013, 11:18:57 pm
I have finished a major overhaul, with far more possibilities.

I have created a generic printing class called NonStreamingIO and combined with the Arduino core provided 'Printable' Class, the eeprom code ( EString ) functions the same as the GString, except prints to ROM.

The Printable class allows printing strings directly into the print class. There is still more to go, but here is what the builtin version of GString and EString will look like, the printf functionality is builtin to Print now.

These allow things like:
Code:
EString e( 0, 10 ); //Set string from 0 to 0 + 10, or 11 characters.

//Send current string from EEPROM over serial.
Serial.print( e );

//Write a float to EEPROM.
e.print( 123.456f, 3 );

That code above is how the Print library and sprintf will deal with EEPROM and SRAM reading writing ( printing out / printing to ).

This is only a preliminary attempt, but here is the SRAMWriterand EEPROMWriter, which are typedef'd to GString and EString.

Code:
#ifndef HEADER_PRINTER
  #define HEADER_PRINTER
  
  class NonStreamingIO : public Print{
    public:
      size_t count( void ) const { return End - Start; }
    
      virtual size_t write(uint8_t) = 0;
    
      template< typename T > NonStreamingIO &operator +=( const T &t )
        {
          print( t );
          return *this;
        }  

      template< typename T > NonStreamingIO &concat( const T &t )
        {
          print( t );
          return *this;
        }
        
      template< typename T > NonStreamingIO &concat( const T &t, const int i )
        {
          print( t, i );
          return *this;
        }    

      template< typename T > inline void assign( const T *u_DataPtr, const uint16_t u_Length )
        {
          Start = ( uint8_t* ) u_DataPtr;
          End = Start + u_Length;
        }
    protected:
      NonStreamingIO( uint8_t *u_DataPtr ) : Start( u_DataPtr ) , End( Start )
        { return; }  
        
      NonStreamingIO( uint8_t *u_DataPtr, const unsigned int u_Length ) : Start( u_DataPtr ) , End( Start + u_Length )
        { return; }          
        
      uint8_t  *Start;
      uint8_t *End;        
    private:
  };
  
  #include <avr/eeprom.h>
  class EEPROMWriter : public NonStreamingIO, public Printable{
    public:
      template< typename T > EEPROMWriter( const T *t_DataPtr ) : NonStreamingIO( ( uint8_t* ) t_DataPtr ), Printable()
          { return; }
      template< typename T > EEPROMWriter( const T *t_DataPtr, const unsigned int u_Length  ) : NonStreamingIO( ( uint8_t* ) t_DataPtr, u_Length ), Printable()
          { return; }  

      size_t write( uint8_t u_Data )
        {
          if( eeprom_read_byte( End ) != u_Data )
            eeprom_write_byte( End, u_Data );
          ++End;
          return 0x01;
        }
    protected:
      friend Print;
      
      size_t printTo(Print& p) const  
        {
          uint8_t  *u_Cursor = Start;
          while( u_Cursor <= End ) p.write( ( uint8_t ) eeprom_read_byte( u_Cursor++ ) );
          return count();
        }
    private:
  };
  
  class SRAMWriter : public NonStreamingIO{
    public:
      template< typename T > SRAMWriter( const T *t_DataPtr ) : NonStreamingIO( ( uint8_t* ) t_DataPtr )
        { return; }
      template< typename T > SRAMWriter( const T *t_DataPtr, const unsigned int u_Length  ) : NonStreamingIO( ( uint8_t* ) t_DataPtr, u_Length )
          { return; }  
          
      operator char*( void )
        {
          *End = '\0';
          return ( char* ) Start;
        }  

      void end( void ) { *End++ = '\0'; }  

      size_t write( uint8_t u_Data )
        {
          *End++ = u_Data;
          return 0x01;
        }      
    protected:
    private:
  };
  
  typedef SRAMWriter GString;
  typedef EEPROMWriter EString;
    
#endif

I'll have to post the full patch later on tonight after work.
1060  Development / Other Software Development / Re: String/sprintf alternative specifically for Arduino. on: May 23, 2013, 08:35:17 pm
@robtillaart:

The playground idea is a good idea, however I have only peeked at scanf, it seems like it might have a significant overhead, unless a lot of the functionality can be reproduced using the stream library, like printf does with Print.

@Docedison, the latest code I have released is only the GString version, the built in Print patch is coming shortly. I'll try post it before work today, otherwise tonight sometime.
1061  Development / Other Software Development / Re: String/sprintf alternative specifically for Arduino. on: May 23, 2013, 07:11:01 am
This feature is for my Print based printf code highlighted here: http://forum.arduino.cc/index.php?topic=166540.msg1247875#msg1247875

If you are to use the GString library by its self you can do this:
Code:
char buffer[32];
GString g( buffer );
g.print( EE( address ) );
//or
g.printEEPROM( address );
//or
g.printf( "%r", address );


Once I release my Print patch, the functionality will be added to every derived class (Serial, Ethernet, WiFi, SD, LiquidCrystal, Wire, SoftwareSerial).
Then you can use code like this ( each line is equivalent ):
Code:
wifi.printEEPROM( address );
glcd.print( EE( address ) );
Serial.printf( "%r", address );

PROGMEM support is already in the Print library, and uses the printf command '%p'.
1062  Development / Other Software Development / Re: String/sprintf alternative specifically for Arduino. on: May 23, 2013, 05:05:58 am
PRG_MEM is not EEPROM but flash.  smiley-wink

Yup, this is reading strings from both eeprom and flash.
1063  Development / Other Software Development / Re: String/sprintf alternative specifically for Arduino. on: May 23, 2013, 04:15:22 am
I've been experimenting some different ways to do things.

Here are a few common functions implemented using the Print library.

Code:
inline int sprintf( char * str, const char * format, ... )
{
va_list v_List;
va_start( v_List, format );
GString g( str );
int i_Return = g._printf( format, v_List );
g.end();
va_end( v_List );
return i_Return;
}

inline char *itoa( int value, char * str, int base )
{
GString( str ).print( ( long ) value, base );
return str;
}

inline char *utoa( unsigned int value, char * str, int base )
{
GString( str ).print( ( unsigned long ) value, base );
return str;
}

inline char *ltoa( long value, char * str, int base )
{
GString( str ).print( value, base );
return str;
}

inline char *ultoa( unsigned long value, char * str, int base )
{
GString( str ).print( value, base );
return str;
}

On a large test sketch the optimisations made a huge difference.

  • 7762 bytes: Original Arduino code.
  • 7388 bytes: Print based sprintf
  • 7274 bytes: using Print based itoa, utoa, ltoa, ultoa
  • 7014 bytes: using printf
  • 6958 bytes: force itoa and utoa using 32-bit conversions. ( sprintf does not use 16 bit Print code. )

I have the eeprom code ready too. I'll give it a testing soon too.
1064  Development / Suggestions for the Arduino Project / Re: Reference section for "ShiftOut" on: May 23, 2013, 03:41:31 am
Yeah, mistakes like these are questioned often here. It seems that a few reference items have been written in a rush. Unfortunately general public/members do not have access to fix the mistakes.
1065  Using Arduino / Programming Questions / Re: What's the mean of "f" in this Code on: May 23, 2013, 03:37:40 am
No worries, remember stack overflow, it has a lot of great non-Arduino answers ( arduino stuff too ).
Pages: 1 ... 69 70 [71] 72 73 ... 150