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

Yeah weird isnt it. I'm thinking that the bits it's bringing into int test as it shifts them alongto the right are all 1's?

Putting in things like that light up exactly how you would expect them to. PORTB = 1; // RB0 is lit up. Any direct specification like that works. I can set portb to output contects of 8 bit registers no problem, even 16 bit variables (but the most significant byte is chopped off). The only anomoly I have found is this bit shifting problem.

OK heres some progress...

Code:

test() {
	unsigned int temp;
	temp = 0x80FF;		// an 8 bit number in the upper byte of 16 bits
	temp = temp >> 8;	// only 6 bits remain (0x3F)
	PORTB = temp;
}

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

This lights up RB7 only on PORTB as it should.

A little more to add... I took the above program and shifted the bits incrementally from 8 to 16. As you would expect, the single LED traveled from RB7 to RB0 - then when I shifted it 16 times (expecting no LEDs to be lit) they all came on!

let me try your method tater, ill post back in 5

Ill try what you said anduril as well

OK I've done some relatively thorough testing and here are my results:

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;
}

test0() {
	int temp;
	int y = 0xFF;				// 11111111
	PORTB = y;
	__delay_ms(1000);
	for (int x = 0; x < 8; x++) { 
    	y = y >> 1;
    	PORTB = y; 
    	__delay_ms(1000);
	}
}

test1() {
	int y = 0x88;				// 10001000
	PORTB = y;
	__delay_ms(1000);
	for (int x = 0; x < 8; x++) { 
    	y = y >> 1;
    	PORTB = y; 
    	__delay_ms(1000);
	}
}

test2() {
	int y = 0x8888;				// 1000100010001000
	PORTB = y;
	__delay_ms(500);
	for (int x = 0; x < 16; x++) { 
    	y = y >> 1;
    	PORTB = y; 
    	__delay_ms(500);
	}
}

test3() {
	int y = 0x7888;				// 0111100010001000
	PORTB = y;
	__delay_ms(500);
	for (int x = 0; x < 16; x++) { 
    	y = y >> 1;
    	PORTB = y; 
    	__delay_ms(500);
	}
}

test4() {
	unsigned int y = 0x4888U;	// 0100100010001000
	PORTB = y;
	__delay_ms(500);
	for (int x = 0; x < 16; x++) { 
    	y = y >> 1;
    	PORTB = y; 
    	__delay_ms(500);
	}
}

test5() {
	unsigned int y = 0x8888;	// 1000100010001000
	PORTB = y;
	__delay_ms(500);
	for (int x = 0; x < 16; x++) { 
    	y = y >> 1;
    	PORTB = y; 
    	__delay_ms(500);
	}
}

void main() {
	initDigitalOut();
//	test0();	// Worked fine.
//	test1();	// This worked fine. Bits shifted along nicely and the last loop outputted a fully-off PORTB.
//	test2();	// This worked fine until the most significant 1 appeared... It left a trail of 1s behind it!
//	test3();	// Worked fine.
//	test4();	// Worked fine.
	test5();	// Worked as expected. U suffix didn't seem to make a difference, unsigned did though. Tried all combinations of both.	
}

So there we have it! All is well (after some rejiggering of numbers). Seems that unsigned is what's making the difference here.

Ok... well done, good problem analysis...

So instead of defining variables as int (which is signed) use unsigned int
or if int is 32 bits on that uC, use unsigned short int for 16 bit values.

If your compiler supports the <stdint.n> header you can be very explicit with uint16_t which is a 16 bit unsigned integer.

Originally Posted by dannybeckett

yeah I can use stdint.h, thats awesome. Whats the _t for at the end?

It's a naming convention that is sometimes used for typedefs.