Searching \ for '[EE] Bit shifting' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/index.htm?key=bit+shifting
Search entire site for: 'Bit shifting'.

Exact match. Not showing close matches.
PICList Thread
'[EE] Bit shifting'
2006\11\14@215502 by Shawn Wilton

picon face
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)

2006\11\15@002634 by cdb

flavicon
face
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_OUTcolinTakeThisOuTspambtech-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


2006\11\15@003456 by John Chung

picon face


--- Shawn Wilton <.....black9KILLspamspam@spam@gmail.com> wrote:

{Quote hidden}

try this
tmr0l = (unsigned char)(((unsigned short int)65000) &
0x00FF);
tmr0h = (unsigned char)((((unsigned short int)65000)
& 0xFF00)>>8);


John
> --
>
> Shawn Wilton (b9 Systems)
> --

2006\11\15@041528 by Shawn Wilton

picon face
I'll give it a shot.


On 11/14/06, John Chung <kravnusspamKILLspamyahoo.com> wrote:
{Quote hidden}

2006\11\15@045745 by Alan B. Pearce

face picon face
> //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 ????

2006\11\15@064335 by Spehro Pefhany

picon face
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_OUTspamTakeThisOuTinterlog.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


2006\11\15@083652 by Tamas Rudnai

face picon face
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.Pearcespamspam_OUTrl.ac.uk> wrote:
{Quote hidden}

> -

2006\11\15@105044 by Gerhard Fiedler

picon face
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

2006\11\15@111820 by Gerhard Fiedler

picon face
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

2006\11\15@113319 by Harold Hallikainen

face
flavicon
face

> 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!

2006\11\15@114343 by Scott Dattalo

face
flavicon
face
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

2006\11\15@125357 by Andre Abelian

flavicon
face
Shawn,

you need to use "unsigned long"
this is how I did it.


unsigned long prg_meml;
unsigned long prg_memh;
BYTE prg_meml;
BYTE prg_memh;


       prg_meml=prg_mem>>8;
       prg_memh=prg_mem & 0x00FF;


Andre



{Original Message removed}

2006\11\15@135522 by Andre Abelian

flavicon
face
Shawn,

I noticed there is duplicated name in my example.
here is the correct one.

unsigned int16 tmr0_read;  //
BYTE tmr0L;
BYTE tmr0H;

       tmr0L=tmr0_read>>8;
       tmr0H=tmr0_read & 0x00FF;

Andre




{Original Message removed}

2006\11\15@140322 by Shawn Wilton

picon face
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@scottKILLspamspamdattalo.com> wrote:
{Quote hidden}

> -

2006\11\15@220040 by John Chung
picon face
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 <KILLspamscottKILLspamspamdattalo.com> wrote:

{Quote hidden}

> --

2006\11\16@065252 by Peter Bindels

picon face
On 15/11/06, Harold Hallikainen <RemoveMEharoldTakeThisOuTspamhallikainen.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

2006\11\16@102352 by Harold Hallikainen

face
flavicon
face
Thanks! I'll start using those names for types!

Harold


{Quote hidden}

> -

More... (looser matching)
- Last day of these posts
- In 2006 , 2007 only
- Today
- New search...