Show Posts
Pages: 1 ... 72 73 [74] 75 76 ... 122
1096  Products / Arduino Due / Re: USB fash drives and HDD on: October 22, 2012, 04:25:39 pm
The USB port is a host device. It should be able to connect to anything with appropriate software.
This is something that will be used extensively if available, I'd imagine you could emulate any address length you want.
1097  Using Arduino / Programming Questions / Re: Problem shifting bitwise Output on: October 22, 2012, 03:35:22 pm
Have you checked weather the shift library shifts the MSB first or LSB? The pin order may be reversed.
1098  Products / Arduino Due / Re: No ethernet wiring on: October 22, 2012, 03:29:51 pm
Yeah that's a shame, for all terminated pins it would have been nice to have a header underneath the board ( so out of the way I guess ) even if it required manual soldering of a header strip ( could then be user decision above or below ).

I'm gonna be looking at Ethernet via USB, I think an Ethernet shield ( not new 32 bit wifi ) on the Due could be a significant bottleneck.
1099  Development / Other Software Development / Re: BitBool Class ( boolean array ), upto 16000 elements on UNO. on: October 22, 2012, 03:02:38 pm
Hmmm, I'm not sure, I'll have to do some investigation on making it compatible, but as it stands I don't think it would work, needs a way to retrieve the data.

You have given me some more ideas anyway. I also have a class for dealing with PROGMEM types which may be better for this type of thing.
1100  Development / Suggestions for the Arduino Project / Re: Is Arduino Due coming? on: October 22, 2012, 02:36:37 pm
unfortunatly the courier from europe to australia is going to expensive... We're not ripping you off.. they are.
We have distributors around the world to alleviate this problem.
I think that accusing us of "daylight robbery" is unfair.

As I said before we can't use the postal shipping because there are way too many packages that get "lost". since there is no way to track then efficently in many countries, we had to ship boards multiple times.


Yes, maybe my words were a bit strong for what I intended, I've been waiting to do testing on a large Arduino specific library for almost 10 months now, held off buying other 32bit arm & avr boards like the Olimex. If the estimated postal price was released a year ago, I would not have bothered waiting. The clones will flood in soon.

I would have been happy accepting some risk, also maybe some sarcasm was lost in translation, for that price I'd expect it to be delivered at gun point.
1101  Development / Suggestions for the Arduino Project / Re: Is Arduino Due coming? on: October 22, 2012, 09:07:04 am
Wanting to put in an order, but 112 Euro to Australia, are you serious, almost twice the cost of the board for shipping, no wonder people buy clones...

I waited a year I suppose I can wait till clones come out, I was expecting a large fee for postage, not daylight robbery.
1102  Development / Other Software Development / Re: BitBool Class ( boolean array ), upto 16000 elements on UNO. on: October 22, 2012, 03:12:32 am
I agree that the names should match, I have extracted this from a larger library I plan to release once the Due is here, so artifacts have crept in. Also I assume you do already know 'byte' is simply an alias for uint8_t.

And as far as sizing the types, its done in compile time, and I don't believe your method is any more intuitive. I have my own style of writing expressions, I think it is  more of a personal preference thing.

I'll edit the code in a sec, another artifact... done.

b_Data cannot be private.
Original code is fixed now.

Oh and I'm using the Arduino IDE, nothing special ( not relevant now as it was my code error ), thanks for the find.
1103  Development / Suggestions for the Arduino Project / Re: Is Arduino Due coming? on: October 22, 2012, 01:08:04 am
Hmmm, release must be imminent. Geez, wake up Italy...  smiley-razz
I'm quite interested to see the new IDE and code base.

As for the shield problem, plenty of hardware/software nerds here, why not start a community developed voltage tolerant shield just for plugging any voltage shields in, maybe add a few lasers too.
1104  Development / Other Software Development / BitBool Class ( boolean array ), upto 16000 elements on UNO. on: October 21, 2012, 06:21:34 pm
This is a small class designed to lower SRAM usage for bool arrays. Values can be inspected or assigned using standard array sub-script operators ( '[]' ), the code below is the library, and underneath that is a sample sketch of generic array usage, it contains a #define called USE_STANDARD_BOOL which if uncommented will use a standard bool array, otherwise a BitBool array is used. The internal data is accessible allowing manipulation of bits and bytes.

Some usages may be: large sets of bool flags, LED patterns/shift data.

This is only a basic implementation, if anybody has a need for some form of shifting / conversion /any other mod, please post your ideas.

  #include "Arduino.h"

  template< size_t _Count >
    class BitBool{
        struct BitRef{
          BitRef( uint8_t &u_DataRef, const uint8_t u_Idx ) : u_Data( u_DataRef ), u_Index( 0x1 << u_Idx ) { return; }

          operator const bool() const { return this->u_Data & this->u_Index; }
          const bool operator =( const BitRef &b_Copy ) const { return *this = ( const bool ) b_Copy; }

          const bool operator =( const bool &b_Copy ) const
              if( b_Copy )  this->u_Data |= this->u_Index;
              else          this->u_Data &= ~this->u_Index;
              return b_Copy;
          uint8_t &u_Data;
          uint8_t const u_Index;
        enum{ BitCount = _Count, ByteCount = ( BitCount / 0x8 ) + ( ( BitCount % 0x8 ) ? 0x1 : 0x0 ) };

        BitRef operator []( const uint16_t i_Index ) { return BitRef( this->u_Data[ i_Index >> 0x3 ], i_Index & 0x7 ); }  
        uint8_t u_Data[ ByteCount ];

#define MAX_ITEMS 100

#include <BitBool.h> //use "BitBool.h" if file is local, or remove include and copy class directly in.

  bool b_Array[ MAX_ITEMS ] = { true, true, true };
  BitBool< MAX_ITEMS > b_Array = { B00000111 };

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

void loop()
    bool b_TempCopy = b_Array[ MAX_ITEMS - 1 ];
    //Roll items up.
    for( int i_Index = MAX_ITEMS - 1 ; i_Index ; --i_Index )
      b_Array[ i_Index ] = b_Array[ i_Index - 1 ];
    b_Array[ 0 ] = b_TempCopy;
    //Show contents.
    for( int i_Index = 0 ; i_Index < MAX_ITEMS ; ++i_Index )
      Serial.print( b_Array[ i_Index ] ? '#' : '-' );

1105  Using Arduino / Programming Questions / Re: Variables in functions ... What is best? on: October 20, 2012, 05:16:29 am
"A union may be thought of as a structure all of whose members begin at offset 0 and whose size is sufficient to contain any of its members. At most one of the members can be stored in a union at any time."


union myunion {
  int var_a;
  int var_b;
  float var_c;
} uval;

will allow (actually, force) vars var_a, var_b and var_c to share the same memory address.

uval.var_a and uval.var_b will be typed as ints, while uval.var_c will be typed as a float.

Sometimes you just gotta tell the compiler who's boss!

That is not the same as the optimisation I pointed out, what about two variables of different sizes? Your optimisation causes sub-optimal performance.

 Also its not forcing anything, the names are aliases to a single type. Your example is in violation of the specifications if you write to one member then read another ( strict aliasing rule ), and becomes unsafe once you start using non-trivial members, not to mention trap representations.

Once you have to use unions for much other than sign extension, minimum type sizing, or handling c code, you could be explicitly adding 'undefined behaviour' to your code.
1106  Using Arduino / Programming Questions / Re: Variables in functions ... What is best? on: October 19, 2012, 10:50:56 pm
A union is itself a unique entity commonly known as a type. Multiple typed names shouldn't be mixed in usage to conform to standard.
1107  Using Arduino / Programming Questions / Re: Variables in functions ... What is best? on: October 19, 2012, 10:37:19 pm
My personal preference: I use global variables with no specific names, so I can reuse them whenever it's possible smiley

Once you encounter some excruciating errors, you'll think twice about this.


Local var memory/registers can be re-used by the compilers optimisations, so two variables that don't have an overlapping usage can sometimes be in the same address ( compilers decision, cannot be forced ).

If you are copying data into the variable, a local initialisation can be more efficient than a global assignment.

Memory pools are another option.

Globally allocate a block/pool, then using placement new operator ( search on google, c++ FAQ ) create your local object in pool, and explicitly call the destructor when finished. This allows initialisations without allocations, plus no de-allocation ( only 1 if pool isn't persistent throughout the applications lifetime ).
1108  Using Arduino / Programming Questions / Re: Bitshifting bytes to form a long var fails! on: October 17, 2012, 09:07:34 pm
That won't do you justice.

For starters you don't write anything to the most significant byte. A variable declared on the stack will have an undefined contents until initialised or assigned. Therefore you read rubbish data off the stack.

Secondly you don't combine the data properly, you mask away the bits of 'high_nibble'

And no, apart from the fact the code is unusable, it is not faster.

This is probably what you intended.
 uc_ptr = (unsigned char *) &address;
  *uc_ptr++ = (( d << 4 ) | e);
  *uc_ptr++ = (( b << 4 ) | c);
  *uc_ptr++ = a;
  *uc_ptr = 0;

Which also is slower than a union construct.
1109  Using Arduino / Programming Questions / Re: Bitshifting bytes to form a long var fails! on: October 17, 2012, 08:23:17 pm
Who knows, maybe it was a combination of mistakes that i did
@psyche good to see you have it working, the previous examples were vaild.

And just to be picky:
If you want to reconstitute a long type from char types, here is something that you can try beyond all the shifting / union.

unsigned char *uc_ptr; //unsigned char ptr, used for conversion
  uc_ptr = (unsigned char *) &address; //point uc_ptr at the conversion results
  *uc_ptr++=dat1; //assign the 1st char
  *uc_ptr++=dat2; //assign the 2nd char
  *uc_ptr++=dat3; //assign the 3rd char
  *uc_ptr   =dat4; //assign the 4th char
  //after this point, address should contain the values represented by the four char types
Speed-wise, this will be as fast as the union approach and potentially faster. However, like the union approach, it is dependent on the compiler's endianess - so the code's portability is poor.

@dhnery, I hope there is more to come, most of your assumptions above are wrong. The task at hand is interlacing nibbles, more specifically 'un-serialisation' of data. The algorithm above is not intended for re-factoring and is almost guaranteed to be slower. One rule of thumb when designing an algorithm is assignments can be 'equal to' in speed compared to initialisations but never faster.

The algorithm above is typically used as  a replacement for a loop, or used in conjunction with one, to trade off size for greater speed.

Also on a side note, most compilers suffer a small side effect relating to using a 'pointer to' or 'reference of' constant data, as a result these constants cannot be considered 'compile time constants'.

As for comparing the above to my union in reply #30, just counting the operations shows it does less work before the compiler even gets to it.

Moving on to the versions in replies 1541, they are not quite as fast as the union due to their shifts greater than the native processor width, however they are faster than the above example too.
I haven't considered the union here as its use of bit fields is very inefficient.
And as for them being non-portable, there is no reason to not include endianess handling into the struct which would give you portablility.

Hope this gives some thoughts.
1110  Using Arduino / Programming Questions / Re: PROGMEM: storing and retrieving unsigned long data on: October 16, 2012, 08:09:22 am
Here is a link to all the PROGMEM functionality

the macros like pgm_read_byte are what you need.
Pages: 1 ... 72 73 [74] 75 76 ... 122