Word to nibbles

I have a word (16 bits) that I want to break into 4 bytes, i.e.

word = dddd cccc bbbb aaaa

convert to

byte1 = 0000 aaaa
byte2 = 0000 bbbb
byte3 = 0000 cccc
byte4 = 0000 dddd

any sugestions on how I would go about doing this?

There's as many ways to do this as there are readers on this forum... here's just one way...

Byte1=Myword.Lowbyte & $0F
Byte2=Myword.Lowbyte >> 4
Byte3=Myword.Highbyte & $0F
Byte4=Myword.Highbyte >> 4

Thanks Melanie, I forgot about variable modifiers. Your solution appears that it will work however when I compile the code I get the following error ...
Error[101] C:\PROGRAM FILES\PICBASIC\PBPPIC12.LIB 5693 :
ERROR: (Library cannot exceed first 256 words.)
This seems to be caused by the ">>" (shift right) command. Any thoughts?

Compiles fine without error for me.

You running a demo or otherwise restricted version of PICBasic?

or you run out of the RAM capability on your 12XXXX PIC.

Post your whole code here and PIC model, we'll have a look to that.

Compile ok here to.

I'm using PICBasic Pro 2.46 and programming a 16F59. I really can't show the entire code (because it is for work). However, its not that large and an associate told me he has always had problems with << and >> so he shifts bits in assembly language, ie. RRF _MyVariable, 1. Do you know what that error message means? Is there a complete list of error codes published ?

Well as i'd never ever heard about that problem and never ever had it myself, even if i use that >> and << often, i can't comment. and i tried the following

Code:

---

a var byte
b var byte
c var byte
d var byte
f var word

a=f.Lowbyte & $0F
b=f.Lowbyte >> 4
c=f.Highbyte & $0F
d=f.Highbyte >> 4

---

so the RAM oveflow guess is a probable cause IMHO. what about if you compile your code with another PIC???

ALL MPASM error are listed in the following pdf
http://gputils.sourceforge.net/33014g.pdf
Error 101 is a user-defined error. And i'm really not sure it's related to the PM error message 101

Quote:

---

101 Use of Local Label Prior to Use of Non-Local Label

Indicates that a local label (i.e. starting with a colon) has been defined
prior to the definition of a non-local label (i.e. a legal label name
starting with other than a colon). Because local names depend on the named
of last non-local label defined, this usage is obviously suspicious. The
label generating the warning is not expanded as are other local labels (see
Local Labels).

---

That make no sense at all. BTW all error message of PM are listed in PM.TXT

Sometimes error message do not reflect the real error. So is that error disapear when you comment-out the lines who use >> ???

I have v2.46 and just compiled a small test program (350 words) for the 16F59 incorporating the example I posted for you without error.

If you are getting errors with usage of << or >>, then your compiler may be corrupt. Reinstall from your master disk, and if problems still persist, contact Jeff at MeLabs for his comment.

May I suggest you also check your labels and definitions that you're not using a reserved word as a label.

I remed out most of the code except the code containing the shifts. and started compiling. all went well until I unremed the following line:

SEROUT PORTA.3,BRate,[32,Leader,#DataOut[5],#DataOut[4],#DataOut[3],#DataOut[2],#DataOut[1],10]

then the error occurred.

If I rem out all lines containing >> the above line compiles fine. If I rem out the line above (SEROUT PORTA.3 ... )the >> lines compile fine. If I change the above line to:

SEROUT PORTA.3,BRate,[32,Leader,DataOut[5],DataOut[4],#DataOut[3],#DataOut[2],#DataOut[1],10]

(thus removing the pound sign (#))

Everything compiles fine.

WIRD WIRD WEIRD can't confirm it here...
what about if you split your SEROUT statement in two like..

Code:

---

SEROUT PORTA.3,BRate,[32,Leader,#DataOut[5],#DataOut[4]]
SEROUT PORTA.3,BRate,[#DataOut[3],#DataOut[2],#DataOut[1],10]

---

or in a multiple line like

Code:

---

SEROUT PORTA.3,BRate,[32,Leader,#DataOut[5],_
                      #DataOut[4],#DataOut[3],_
                      #DataOut[2],#DataOut[1],10]

---

the little thing that could do... i said could, if DataOut is a word size variable BUT i tried it also... works for me.

BTW there's certainely somebody here or at MELABS who know why... over for me :(

PBP offers pretty limited support for the 12-bit core.

Calls and computed jumps can only be made to the first half (256 words) of any code page on the 12-bit core with PBP due to the meager resources on the 12-bit core.

And, all PBP library routines have to squeeze into the 1st page, so it's tough to do much with PBP on a 12-bit core unless you're pretty creative.

mmm now that make sense to me. So as i suggest before, trying to compile with another PIC would have solved the problem.. well if a 14 or 16 bit core where choose of course.

Thanks Bruce for the neat and deep explanation.

Thanks to you all for your input, I think the mystery is solved. On my next project, I'll remember the limitations of the 12 bit core.