next topic »

[Reply #15 on:]

I tried that too but it didn't work! I also updated to 1.0.1 but still no luck.

Can you please post what you tried, and what you got. Saying I "tried that" and it "didn't work" is very non-specific.

My code here:

Code:

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

void loop ()
{
  long address;
 
  byte a = 0x0F;
  byte b = 0x0E;
  byte c = 0x0C;
  byte d = 0x0D;
  byte e = 0x0A;
 
  address = long (a) << 16 | long (b) << 12 | c << 8 | d << 4 | e;
 
  Serial.println (address, HEX);
 
  while (1);
}

Works. Output:

Code:

FECDA

So I can't really believe you tried it and it didn't work.

[Reply #16 on:]

I tried that too but it didn't work! I also updated to 1.0.1 but still no luck.

Can you please post what you tried, and what you got. Saying I "tried that" and it "didn't work" is very non-specific.

My code here:

Code:

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

void loop ()
{
  long address;
 
  byte a = 0x0F;
  byte b = 0x0E;
  byte c = 0x0C;
  byte d = 0x0D;
  byte e = 0x0A;
 
  address = long (a) << 16 | long (b) << 12 | c << 8 | d << 4 | e;
 
  Serial.println (address, HEX);
 
  while (1);
}

Works. Output:

Code:

FECDA

So I can't really believe you tried it and it didn't work.

Ok the

Code:

long (b) << 12

did the job BUT it doesn't work in the for loop!
Any reason why? If i remove the 2 "long" then the address is increased as it should! With the 2 "long" in there, what i get is the initial value and then i get the last value! Not any other values between the two, just min and max values! Weird!!!

[Reply #17 on:]

Show us the whole code and output as it is now - there is clearly another issue now.  In particular str1, str2, str3 etc - what types/values are they.

[Reply #18 on:]

Using union or pointers to reconstitute a different data type is actually fairly common.

Yes, when the constituent types align to the platform's native word size.

Still waiting to see dhenry's code to perform the equivalent of a four bit shift with pointers and/or structs/unions.

[Reply #19 on:]

Still waiting to see dhenry's code to perform the equivalent of a four bit shift with pointers and/or structs/unions.

I have a suspicion that it might be possible to achieve using bitfields, but even assuming you could muddle a way through to make it work the result would be pretty convoluted. Straight forward bit shifts offer a far more appropriate solution in this case.

[Reply #20 on:]

I have a suspicion...

Keep your speculation coming. Think out of the box and keep it simple.

[Reply #21 on:]

I have a suspicion...

Keep your speculation coming. Think out of the box and keep it simple.

Well, I suppose a union of a long and the appropriate number of bit fields correctly padded and aligned would produce the desired effect. This would still not be my preferred solution, but I think it could be made to work if the compiler cooperates. You would be at the mercy of the compiler, though, and I don't know whether it would actually work in Arduino. Have you tried it and got it working?

[Reply #22 on:]

it could be made to work if the compiler cooperates.

A big if.

You probably will have to find a compiler that doesn't automatically pad.

[Reply #23 on:]

Are we going to see the grand unveiling of this miracle algorithm, or should I stand the marching bands and the fireworks down, and call more dhenry BS?

[Reply #24 on:]

You probably will have to find a compiler that doesn't automatically pad.

I will have to find? I thought this was the solution that you have been enigmatically hinting was possible, while not actually telling us what you thought the solution was.

[Reply #25 on:]

Ok the

Code:

long (b) << 12

did the job BUT it doesn't work in the for loop!
Any reason why? If i remove the 2 "long" then the address is increased as it should! With the 2 "long" in there, what i get is the initial value and then i get the last value! Not any other values between the two, just min and max values! Weird!!!

Any reason for ignoring my earlier advice? ...

Can you please post what you tried, and what you got. Saying I "tried that" and it "didn't work" is very non-specific.

And what would that reason be?

[Reply #26 on:]

I have a suspicion...

Keep your speculation coming. Think out of the box and keep it simple.

Well, I suppose a union of a long and the appropriate number of bit fields correctly padded and aligned would produce the desired effect. This would still not be my preferred solution, but I think it could be made to work if the compiler cooperates. You would be at the mercy of the compiler, though, and I don't know whether it would actually work in Arduino. Have you tried it and got it working?

I tried with bit fields, no luck at getting the code close to nicks example's output above.

It is a hardware based solution available to any avr

I think the 'MUL' avr instruction is what will do the work in 2 clock cycles. I don't know ASM so could someone check it out. I'll investigate myself but may be some time as I have to read a little first.

EDIT again: ( x << n ) == ( x MUL 2 ^n )

8 << 3 == 8 MUL 8

^ being power of not C++ XOR

[Reply #27 on:]

I think the 'MUL' avr instruction is what will do the work in 2 clock cycles.

Wouldn't any reasonably good compiler implement that statement as left shift instead?


My approach works on mcus without hardware multiplier, so we can rule that out.

[Reply #28 on:]

I'm trying to think of your specific case, you stated "It is a hardware based solution available to any avr" there is no barrel shifter and you don't expect hardware multiplication. Just to make sure, you aren't thinking of some obscure method using the SPI shift register or port registers in loop back config are you.

Is it something using asm, ( BTW compiler won't change asm MUL operation, inline asm subverts the optimiser. )  Or just c++?

[Reply #29 on:]

I was thinking about an approach that fits the following:

1) hardware / software (well, that doesn't exclude much);
2) 2 instructions (actually can be done in 1, depending on how you code it), in C.
3) does not rely on a hardware multiplier;

Whether it is obscure or not is subjective so I would stay away from that.