Thread: creating a variable consisting of two other variables side by side

Code:

#include <stdio.h>
#include <string.h>

main() {
       int TMR1H = 12345678;
       int TMR1L = 12345678;
       char str1[8];
       char str0[8];
       str1[0] = TMR1H;
       str0[0] = TMR1L;
       char str[16];
       strcpy (str, str1);
       strcat (str, str0);
       printf("%s", str);
       getchar();
}

This is my code so far. All I want is to create a variable which consists of TMR1H immediately followed by TMR1L. These two variables contain the first half(L) and second half(H) of a 16 bit binary number. I dont want any arithmetic operations performed on them, simply str = 1234567812345678. Ideally, the output type is an int. At the moment I'm getting some odd characters from the printf function. Im probably doing very silly things here so if anyone can enlighten me I would be very grateful!

Dan

Lots of things...

1) The correct entry point for C programs is int main (void)
2) Since main return an int you must return a value when exiting; typically 0.
3) 12345678 is to big to fit in a 16 bit binary number... 65535 is the max for an unsigned value.
4) You cannot assign integers to strings without conversion.
5) str1[0] is an 8 bit value that cannot hold 12345678 and will cause an overflow.
6) All your strings are too short , they need at least 1 extra space for the null teriminator.

Overall I would also suggest your approach is wrong since this is very easily done with simple math.

Yep I thought I was. I've been at this for ages so everything is a littlr blurry, I knew half the stuff you just pointed out =/ I've rethought the whole thing - would this work:

t1 = (TMR1H*256) + TMR1L

given that TMR1H is the most significant 8 bits of a 16 bit binary number?

Originally Posted by dannybeckett

Yep I thought I was. I've been at this for ages so everything is a littlr blurry, I knew half the stuff you just pointed out =/ I've rethought the whole thing - would this work:

t1 = (TMR1H*256) + TMR1L

given that TMR1H is the most significant 8 bits of a 16 bit binary number?

Yep... it's about that simple BUT the values you are giving 12345678 will not fit in a 16 bit value...
They will cause overflows, returning garbage answers.

If you are combining 2 8 bit values you are restricted to numbers from 0 to 255. and t1 must be type int or short int.

If you are combining 2 16 bit values to make a 32 you are restricted to 0 -> 65535 in each base value and t1 needs to be an int or long int the formula becomes:

t1 = (tmr1h * 65536) + tmr1l;

To do it with type safety you should use:

t1 = ((tmr1h & 65535) * 65536) + (tmril & 65535)

Excellent, thanks a lot. I know that value wont fit into a 16 bit binary number, I was being rediculous choosing it in the first place. I believe 123456789 corresponds to 111010110111100110100010101 hahahaha.

I understand everything you just told me apart from the last line.

t1 = ((tmr1h & 65535) * 65536) + (tmril & 65535)

Would you care to explain what's going on here?

Thanks for your patience

Originally Posted by dannybeckett

Excellent, thanks a lot. I know that value wont fit into a 16 bit binary number, I was being rediculous choosing it in the first place. I believe 123456789 corresponds to 111010110111100110100010101 hahahaha.

I understand everything you just told me apart from the last line.

t1 = ((tmr1h & 65535) * 65536) + (tmril & 65535)

Would you care to explain what's going on here?

Thanks for your patience

Anduril explained is nicely... the reason for anding with 65535 is to strip away anything in the upper half of a 32 bit variable, preventing overlaps or overflows.

65535 = 000000000000000001111111111111111 So only the lower 16 bits are used in each case.

Thanks for the explanations guys. I understand the bitwise operation of & and << now, I also understand the operation of both statements (is that meant to be an & between the two terms Anduril?)

I'm still not completely clear as to what the anding process safeguards you against. Could you think of an example where the statement I came up with, t1 = (TMR1H*256) + TMR1L, could produce an erroneous result? And how the &'ing would fix that?

LOL... Yeah I think you're pretty safe in assuming you won't get a value bigger than 255 out of an 8 bit register... and if you do, you should be looking for a new uC to play with...

FWIW... maybe next time explain that you're combining PIC or uC registers... save us all a fair bit of confusion.

For hex ... it's easy...

Code:

0000  0x0
0001  0x1
0010  0x2
0011  0x3
0100  0x4
0101  0x5
0110  0x6
0111  0x7
1000  0x8
1001  0x9
1010  0xA
1011  0xB
1100  0xC
1101  0xD
1110  0xE
1111  0xF

hahahaha yeah I'll include all the facts next time I think At least I learned quite a lot! Yeah the whole hex system makes sense to me now, I think im more glad that's been de-mystified than the & operator!

I have 1 more question for you guys. I want to test wether the operations I am performing on this combined value are actually working, and the way I can do that is split the new value back up again in to 8 bits and stick it on two 8 bit ports to light leds.

Code:

#include <htc.h>
#define _XTAL_FREQ 8000000
__CONFIG (FOSC_XT & WDTE_OFF & PWRTE_ON & MCLRE_ON & CP_OFF & CPD_OFF & BOREN_OFF & IESO_OFF & FCMEN_OFF & LVP_OFF & DEBUG_OFF);

void initDigitalOut() {
	PORTA = PORTB = PORTC = PORTD = 0;
	TRISA = TRISB = TRISC = TRISD = 0;
	ANSEL = ANSELH = 0;
}

void test() {
	int test = 0;
	test = 0xFFFF&0xFFFF;
	PORTB = test >> 10;
}

void main() {
	initDigitalOut();
	test();
}

What this should do is light 6 LEDs on PORTB (16 bit number shifted left 10 times). Instead it lights all 8. My only guess is that the data outside the scope of 'test' has 1s on it. I even shifted it 16 times bit they all stayed lit. Could this to do with me trying to operate outside the scope of test? I added the &0xFFFF but im guessing this is quite pointless becuse int can only be 16 bits long anyway (maybe even this is incorrect, since the microprocessor is 8 bits?)

I'm guessing there is going to be a much easier way to achieve this than what im trying to do here. Sorry for the noob-ness.

0xFFFF shifted left 10 times should now read 0x3F the same as 0xFF00 would, or is that wrong? I'm assuming PORTB = temp in your example, unfortunately that didn't work either! all 8 LEDs lit up on PORTB and I dont know why.

The reason why I text it on the MCU is because unexpected things like this happen so I want to make sure it runs fine on the controller before moving on. It's not so bad writing the code onto the controller anyway, takes max 10 seconds from the compile to chip execution.