1. Home
  2. Embedded Programming
  3. Understanding PIC machine code

Understanding PIC machine code

I'd like to write my own PIC compiler because there isn't one on the Macintosh OS X platform.

Can someone explain how to convert the machine code? Consider this example:

ORG H'0000'

BCF PORTA,0 BCF PORTA,1 BCF PORTA,2 BCF PORTA,3 BCF PORTA,4 BCF PORTA,5 BCF PORTA,6 BCF PORTA,7

END

If I compile the above thru an existing PC compiler I get a .hex file that looks like this:

:020000040000FA :10000000051085100511851105128512051385133C :00000001FF

The PIC manual tells me that these lines can be read like this:

:BBAAAATTHHHH....HHHCC where:

BB is a two digit hexadecimal byte count representing the number of data bytes that will appear on the line.

AAAA is a four digit hexadecimal address representing the starting address of the data record.

TT is a two digit record type record type that will always be '00' except for the end-of-file record, which will be '01'.

HH is a two digit hexadecimal data byte, presented in low-byte/high-byte combinations.

CC is a two digit hexadecimal checksum that is the two's complement of the sum of all preceding bytes in the record.

Now we know that the PIC 16F628 is a 14 bit device. So first question is, what do we do with the extra two bits that we get? What if we get one less than 14 bits?

According to the spec - the BCF instruction is the following format:

0100bbbfffffff where 0100 is the opcode, bbb is the bit #, fffffff is the file #.

Looking at the first instruction, BCF PORTA,0 equates to machine code

0510. Converting that to binary I get 10100010000. This is not 14 bits so I assume padding with leading zeros. That makes it 00010100010000. Where's the 0100 opcode? As you can see from below, I have the same issues interpreting the other instructions. Some of them are more than 14 bits! Some of them are less!

Also, why does the compiler use a 16 bit word for a 14 bit instruction? Why would it ever write out an 8510 which is a value greater than 14 bits?

0510 = XXXXX10100010000 8510 = 1000010100010000 0511 = XXXXX10100010001 8511 = 1000010100010001 0512 = XXXXX10100010010 8512 = 1000010100010010 0513 = XXXXX10100010011 8513 = 1000010100010011
Reply to
Pokey
Loading thread data ...

Why not just look at the datasheet? It explains what the opcode for each instruction is.

cheers,

Al

Reply to
Al Borowski

gputils?

formatting link

Vadim

Reply to
Vadim Borshchev

You may have already discovered this but there is

formatting link
available to you. It does say on the page you can compile it for Mac OS X but you will need the "December 2001 Developer Tools". That doesn't mean anything to me but perhaps it means something to you...

Rob

Reply to
Rob Young

Have you taken a look at

formatting link
According to the homepage:

"Work is in progress on supporting the Motorola 68HC08 as well as Microchip PIC16 and PIC18 series. The entire source code for the compiler is distributed under GPL."

You might be able to compile and / or convert to compiler under MAC.

Regards, Richard.

formatting link

Reply to
Richard

the

each

I know what the opcodes should be. What I don't understand is how an

8511, the value in the .hex file, equates to a BCF PORTA, 1. If you look at the binary equivalent of 8511 it does not match what the data sheet says is the opcode. The binary of 8511 is 1000010100010001.

Page # 110 of the datasheet says that the format of this instruction is

0100bbbfffffff where 0100 is the opcode, bbb is the bit #, fffffff is the file #. The binary equivalent of an 8511 does not match the opcode on the datasheet.

As far as other compilers out there, I will look at them but I would still like to know the answer and I have not found it anywhere.

-C

Reply to
Pokey

You haven't told what tool chain you are using, but I suspect that the assembler might have an option to yield the listing with opcodes and addresses. Have you tried it?

Vadim

Reply to
Vadim Borshchev

Most compilers will also produce a list file which includes both the source and the binary codes. Try looking at this first.

Ian

--
Ian Bell
Reply to
Ian Bell

Hi Pokey,

the answer is very simple. The 2nd byte is the higher one.

So, not 8513h but 1385 is the right opcode for "BCF PORTA,7"

Michael

Reply to
Michael Lange

Incorrect assertion. The gputils suite at gputils.sf.net certainly works under Mac OSX.

Here's a link from the first page of a google search for "gputils OSX"

formatting link

You really really don't want to write your own assembler. Scott Dattalo and Craig Franklin have been working for several years on this toolchain. You don't want to start from scratch.

OSX has a fundamental UNIX core. Virtually any console base Unix application can be finagled to compile under OSX.

BAJ

Reply to
Byron A Jeff

works

OSX"

Dattalo and

You

application

All true. gputils is not only portable but it has excellent MPASM compatibility; it's a great solution for UNIX based PIC development. My code assembles and runs equally happily whether using MPLAB or gputils.

Reply to
toby

Of course he does! If for no other reason than learning to write an assembler. :)

Have fun!

--

Wing
Reply to
Win

Writing a cross-assembler is quite easy, writing a native assembler running in a PIC would be a bit more challenging :-).

Paul

Reply to
Paul Keinanen

If you are only using the 12 and 14 bit cores, you may want to have a look at the Crossbow Assembler (at

formatting link
). It runs in Classic mode, is solid, and supports other uPs as well.

--
Jim Nagy
Elm Electronics
Reply to
Jim Nagy

See here! Did you read this? The data is presented in low-byte/high byte combinations! so the HH part of your record is: 05108510051185110512851205138513

Taken as low byte/high byte combinations, you get

1005 1085 1105 1185 1205 1285 1305 1385

Doesn't that make more sense?

Now you see the upper bits are zeros.

But if you look at the spec, it is machine code 0100 000 0000101 which is 1005 hex. Amazing, isn't it?

I think you can take it from here...

Rufus

Reply to
Rufus V. Smith

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.