Post by thread:[EE] Bit shifting

OK, I must be doing some ridiculous here and I'm just not catching it. Does anyone see anything wrong with this code: //Set page 103 for details regarding the +2 tmr0l = (unsigned char)65000; tmr0h = (unsigned char)(65000 >> 8); //Right shift so the top byte becomes the bottom byte All I'm trying to do is split the 65000 across the two variables, tmr0L and tmr0H. tmr0L is being assigned correctly the lower 8 bits of the 16 bit value, but the tmr0H is being assigned 0. -- Shawn Wilton (b9 Systems)

Perhaps casting and shifting is causing the problem. What does the asm code look like? Colin :: Does anyone see anything wrong with this code: :: :: //Set page 103 for details regarding the +2 :: tmr0l = (unsigned char)65000; :: tmr0h = (unsigned char)(65000 >> 8); //Right shift so the top :: byte :: becomes the bottom byte -- cdb, spam_OUTcolinTakeThisOuTbtech-online.co.uk on 15/11/2006 . -- No virus found in this outgoing message. Checked by AVG. Version: 7.5.431 / Virus Database: 268.14.5/534 - Release Date: 11/14/2006 3:58 PM

--- Shawn Wilton <.....black9KILLspam@spam@gmail.com> wrote: {Quote hidden}> OK, I must be doing some ridiculous here and I'm > just not catching it. > > Does anyone see anything wrong with this code: > > //Set page 103 for details regarding the +2 > tmr0l = (unsigned char)65000; > tmr0h = (unsigned char)(65000 >> 8); //Right > shift so the top byte > becomes the bottom byte > > All I'm trying to do is split the 65000 across the > two variables, tmr0L and > tmr0H. > > tmr0L is being assigned correctly the lower 8 bits > of the 16 bit value, but > the tmr0H is being assigned 0. > try this tmr0l = (unsigned char)(((unsigned short int)65000) & 0x00FF); tmr0h = (unsigned char)((((unsigned short int)65000) & 0xFF00)>>8); John > -- > > Shawn Wilton (b9 Systems) > --

I'll give it a shot. On 11/14/06, John Chung <kravnusKILLspamyahoo.com> wrote: {Quote hidden}> > > > --- Shawn Wilton <.....black9KILLspam.....gmail.com> wrote: > > > OK, I must be doing some ridiculous here and I'm > > just not catching it. > > > > Does anyone see anything wrong with this code: > > > > //Set page 103 for details regarding the +2 > > tmr0l = (unsigned char)65000; > > tmr0h = (unsigned char)(65000 >> 8); //Right > > shift so the top byte > > becomes the bottom byte > > > > All I'm trying to do is split the 65000 across the > > two variables, tmr0L and > > tmr0H. > > > > tmr0L is being assigned correctly the lower 8 bits > > of the 16 bit value, but > > the tmr0H is being assigned 0. > > > > try this > tmr0l = (unsigned char)(((unsigned short int)65000) & > 0x00FF); > tmr0h = (unsigned char)((((unsigned short int)65000) > & 0xFF00)>>8); > > > John > > -- > > > > Shawn Wilton (b9 Systems) > > --

> //Set page 103 for details regarding the +2 > tmr0l = (unsigned char)65000; > tmr0h = (unsigned char)(65000 >> 8); //Right > shift so the top byte > becomes the bottom byte > > All I'm trying to do is split the 65000 across the > two variables, tmr0L and Doesn't this need to be an unsigned integer (possibly long integer, depending on default length of integer) because a char is only 8 bits, so max value is 255 ????

At 04:57 AM 11/15/2006, you wrote: > > //Set page 103 for details regarding the +2 > > tmr0l = (unsigned char)65000; > > tmr0h = (unsigned char)(65000 >> 8); //Right > > shift so the top byte > > becomes the bottom byte > > > > All I'm trying to do is split the 65000 across the > > two variables, tmr0L and > >Doesn't this need to be an unsigned integer (possibly long integer, >depending on default length of integer) because a char is only 8 bits, so >max value is 255 ???? Constants are supposed to be (signed) 'int' by default, and 'long' if they are too big to fit into an 'int'. An 'int' has to hold at least 32767 maximum and a 'long' has to handle at least 2147483647 maximum (as in limits.h) for a compiler to be ANSI compliant. So, his compiler is broken. I'd be tempted to try 65000U to get around the problem, and also to be very suspicious of that particular compiler in the future. Best regards, Spehro Pefhany --"it's the network..." "The Journey is the reward" EraseMEspeffspam_OUTTakeThisOuTinterlog.com Info for manufacturers: http://www.trexon.com Embedded software/hardware/analog Info for designers: http://www.speff.com ->>Test equipment, parts OLED displys http://search.ebay.com/_W0QQsassZspeff

char is signed, so that the max value is 127 (the min value is -128) -- unsigned char would be a bit better description for "byte". But anyway, I'd rather use a union so that the compiler do not have to figure out how to optimise the code to pick up low and high values. I am not familiar with C in PIC environment, but there may be some macros that can do this trick. Tamas On 11/15/06, Alan B. Pearce <A.B.Pearcespam_OUTrl.ac.uk> wrote: {Quote hidden}> > > //Set page 103 for details regarding the +2 > > tmr0l = (unsigned char)65000; > > tmr0h = (unsigned char)(65000 >> 8); //Right > > shift so the top byte > > becomes the bottom byte > > > > All I'm trying to do is split the 65000 across the > > two variables, tmr0L and > > Doesn't this need to be an unsigned integer (possibly long integer, > depending on default length of integer) because a char is only 8 bits, so > max value is 255 ???? > > -

Spehro Pefhany wrote: >>> //Set page 103 for details regarding the +2 >>> tmr0l = (unsigned char)65000; >>> tmr0h = (unsigned char)(65000 >> 8); //Right >>> shift so the top byte >>> becomes the bottom byte >>> >>> All I'm trying to do is split the 65000 across the >>> two variables, tmr0L and > So, his compiler is broken. I'd be tempted to try 65000U to get around > the problem, and also to be very suspicious of that particular compiler > in the future. Since this looks like a compiler problem, having a look at the generated assembly code could be interesting. It should be a relatively short piece, and you probably can see easily where things go wrong. Gerhard

Tamas Rudnai wrote: > char is signed May be or may not be. The standard leaves that open. char was originally not intended to do math (the name gives a hint :) so this probably wasn't thought of being important. This has been mentioned before: when actual sizes and signed/unsigned are important, it's good practice to use specific types that are unambiguous. The standard types char and int are not (in the standard). Gerhard

> Tamas Rudnai wrote: > >> char is signed > > May be or may not be. The standard leaves that open. char was originally > not intended to do math (the name gives a hint :) so this probably wasn't > thought of being important. > > This has been mentioned before: when actual sizes and signed/unsigned are > important, it's good practice to use specific types that are unambiguous. > The standard types char and int are not (in the standard). > I can never remember how big Microchip makes various types, so I did a bunch of typedefs in a header file. My "friendly" types are like this: u8b unsigned 8 bit s8b signed 8 bit u16b unsigned 16 bit s16b signed 16 bit etc. Harold -- FCC Rules Updated Daily at http://www.hallikainen.com - Advertising opportunities available!

On Tue, 2006-11-14 at 18:07 -0800, Shawn Wilton wrote: > Does anyone see anything wrong with this code: > > //Set page 103 for details regarding the +2 > tmr0l = (unsigned char)65000; > tmr0h = (unsigned char)(65000 >> 8); //Right shift so the top byte > becomes the bottom byte Others may or may not be correct about the default signedness of chars, but I believe your problem is even more fundamental. When writing to a 16-bit timer, you must write the high byte first. The write to the low byte will initiate a full 16-bit to real hardware. Similarly, to read a 16-bit timer, read the low byte first. This will initiate an access of the high byte too which you may read on the subsequent instruction. Scott

Sure enough, went back to the data sheet looking for info regarding reads/writes. It's there in section 10.4. You must write the high byte first because that goes in to a buffer that is written when you write the low byte. Original code works like a charm after flipping the order of the high and low byte writes. Thank you Scott and everyone else that took the time to respond. On 11/15/06, Scott Dattalo <@spam@scottKILLspamdattalo.com> wrote: {Quote hidden}> > On Tue, 2006-11-14 at 18:07 -0800, Shawn Wilton wrote: > > > > Does anyone see anything wrong with this code: > > > > //Set page 103 for details regarding the +2 > > tmr0l = (unsigned char)65000; > > tmr0h = (unsigned char)(65000 >> 8); //Right shift so the top byte > > becomes the bottom byte > > Others may or may not be correct about the default signedness of > chars, but I believe your problem is even more fundamental. When > writing to a 16-bit timer, you must write the high byte first. The > write to the low byte will initiate a full 16-bit to real > hardware. Similarly, to read a 16-bit timer, read the low byte > first. This will initiate an access of the high byte too which you may > read on the subsequent instruction. > > Scott > -

Good catch there Scott. The price you pay for HLL. You tend to forget the specifics for an arch*Which I can't remember all the tiny gold nuggets*. John --- Scott Dattalo <KILLspamscottKILLspamdattalo.com> wrote: {Quote hidden}> On Tue, 2006-11-14 at 18:07 -0800, Shawn Wilton > wrote: > > > > Does anyone see anything wrong with this code: > > > > //Set page 103 for details regarding the +2 > > tmr0l = (unsigned char)65000; > > tmr0h = (unsigned char)(65000 >> 8); //Right > shift so the top byte > > becomes the bottom byte > > Others may or may not be correct about the default > signedness of > chars, but I believe your problem is even more > fundamental. When > writing to a 16-bit timer, you must write the high > byte first. The > write to the low byte will initiate a full 16-bit to > real > hardware. Similarly, to read a 16-bit timer, read > the low byte > first. This will initiate an access of the high byte > too which you may > read on the subsequent instruction. > > Scott > --

On 15/11/06, Harold Hallikainen <RemoveMEharoldTakeThisOuThallikainen.org> wrote: > I can never remember how big Microchip makes various types, so I did a > bunch of typedefs in a header file. My "friendly" types are like this: > > u8b unsigned 8 bit > s8b signed 8 bit > u16b unsigned 16 bit > s16b signed 16 bit > > etc. The C designers also found that this wasn't clear and fixed it themselves. To avoid name collisions (which you will certainly have) they appended _t to all new types too. The C people call them uint8_t, int16_t etc. There's also a wchar_t that replaces the char when you need wide characters. Using these standard names should bring your own experience closer to the rest of the world and will both make you better at generic C programming and make the code you produce more reusable. Of course, your solution is no better or worse, but it's nonstandard and thereby throwing up an arbitrary barrier to people beside or after you. Regards, Peter

Thanks! I'll start using those names for types! Harold {Quote hidden}> On 15/11/06, Harold Hallikainen <spamBeGoneharoldspamBeGonehallikainen.org> wrote: >> I can never remember how big Microchip makes various types, so I did a >> bunch of typedefs in a header file. My "friendly" types are like this: >> >> u8b unsigned 8 bit >> s8b signed 8 bit >> u16b unsigned 16 bit >> s16b signed 16 bit >> >> etc. > > The C designers also found that this wasn't clear and fixed it > themselves. To avoid name collisions (which you will certainly have) > they appended _t to all new types too. > > The C people call them uint8_t, int16_t etc. There's also a wchar_t > that replaces the char when you need wide characters. > > Using these standard names should bring your own experience closer to > the rest of the world and will both make you better at generic C > programming and make the code you produce more reusable. Of course, > your solution is no better or worse, but it's nonstandard and thereby > throwing up an arbitrary barrier to people beside or after you. > > Regards, > Peter > -