Jump to content

Recommended Posts

Could anyone help please whats the equivalent of Move Literal as below:

movlw .255

and

gatedtime equ .33

 

Can I just ignore the decimal point? So I would 'assume' the following equivalent to above

#define gatedtime 33

temp2=255;

 

Tks,

Al.

Tks,

Al.

Share this post


Link to post
Share on other sites

The movlw command on its own is a low level assembler command and as such it has no equivalent in C or any other high level language.

PICs (and most other processors) do not allow direct manipulation of register and memory locations but rather it all must be done via the "w" register.

The assembler sequence

 

movlw .255

movwf temp2

would indeed be equal to

temp2 = 255

 

but the line movlW .255 on its own has no meaning. It could just as easily have been a part of an instruction sequence to store 255 in any other register.

 

eg the sequence

 

movlw .255

movwf portb

 

would be equal to the C command

portb = 255

Share this post


Link to post
Share on other sites

I have searched but cant find how to assimulate the Carry flag in C eg

decf averagelo

movlw .255

xorwf averagelo,w

btfsc status,z

decf averagehi

 

//C

--averagelo;

averagelo=averagelo ^ 255;

//here is where the carry flag check is needed.

asm btfsc status,z

--averagehi;

Share this post


Link to post
Share on other sites
I have searched but cant find how to assimulate the Carry flag in C eg

decf averagelo

movlw .255

xorwf averagelo,w

btfsc status,z

decf averagehi

 

//C

--averagelo;

averagelo=averagelo ^ 255;

//here is where the carry flag check is needed.

asm btfsc status,z

--averagehi;

if( status.Z )
{
}

Regards

Dave

Share this post


Link to post
Share on other sites
I have searched but cant find how to assimulate the Carry flag in C eg

decf averagelo

movlw .255

xorwf averagelo,w

btfsc status,z

decf averagehi

 

//C

--averagelo;

averagelo=averagelo ^ 255;

//here is where the carry flag check is needed.

asm btfsc status,z

--averagehi;

First off the instruction sequence shown checks the zero bit rather than the carry but in any case the C translation could be:

 

--averagelo;

averagelo ^= 255;

if(test_bit(status, Z))

--averagehi;

 

But if you look at what the program is trying to do over all rather than doing a line by line translation, you could no doubt come up with more elegant and much more understandable code.

The whole point of writing code in C is to produce code that is easy to understand and maintain. Simply doing a line line by line translation from assembler to C would seem to defeat that purpose.

Share this post


Link to post
Share on other sites

Worse, he's not even starting with competently written assembler:

	decf	averagelo
movlw .255
xorwf  averagelo,w
btfsc   status,z
decf	averagehi

is obviously decrementing a 16 bit value and checking if the low byte is 255 to decide if the high byte needs decrementing. On most CPUs the XOR test would be redundant but on midrange PIC cores decrement does NOT set the carry flag on a wrap :( however SUBWF does. so I would expect:

	movlw 1
subwf  averagelo,F
btfsc   status,C
subwf  averagehi,F

Its only one instruction shorter for a 16 bit decrement but on 24 bit or 32 bit values the saving becomes considerable, as it also does if there are multiple 16 bit decrements as W remains 1 throughout.

 

I'd translate this as:

   average--

let the compiler do its job and handle the high byte for me and either map the bytes averagelo and averagehi using unions and structures with some #defines to 'simplify' the names, or preferably explicitly shift and mask to access them.

 

The C resulting from a direct and literal translation is not only going to be unreadably vile, but i suspect it will compile to something 2-3 times larger overall - if it works at all.

Share this post


Link to post
Share on other sites

All good stuff. I'll post the end result up here when I've finished and let you pick the eye teeth out of it. Eventually well end up with another component that will be useful to those using BoostC et al.

 

Its a touch sensitive app for PIC; there are no C code around, so having to do this.

Cheers,

Al.

Share this post


Link to post
Share on other sites

You aren't starting from a Microchip AN by any chance? Some of them are NOT well written and at least one of the hardware ones has actually been dangerous!

 

There also seem to be problems actually getting any reported bugs in them fixed.

 

*PLEASE* verify correct operation 'as is' before attempting conversion . . . .

 

Also, just because it cant be googled, doesn't mean it isn't out there. Give us a link to the source, and just maybe someone may have already done this chore . . . and if not, we can at least see the larger context round your next question.

 

Ian

Share this post


Link to post
Share on other sites
You aren't starting from a Microchip AN by any chance? Some of them are NOT well written and at least one of the hardware ones has actually been dangerous!

 

There also seem to be problems actually getting any reported bugs in them fixed.

 

*PLEASE* verify correct operation 'as is' before attempting conversion . . . .

 

Also, just because it cant be googled, doesn't mean it isn't out there. Give us a link to the source, and just maybe someone may have already done this chore . . . and if not, we can at least see the larger context round your next question.

 

Ian

OK here are the links (on my dropbox) there is a C source, but thats not the one Im interested in:

http://dl.dropbox.com/u/1541849/Cap_Sense.h

http://dl.dropbox.com/u/1541849/Cap_Touch727.c

http://dl.dropbox.com/u/1541849/P10F206.INC

http://dl.dropbox.com/u/1541849/Vars.inc

http://dl.dropbox.com/u/1541849/10Ftouch.asm

 

These files wont be up permanently.

Cheers,

Alistair.

Edited by Alistair George

Share this post


Link to post
Share on other sites

I notice the PIC10F206.INC file amongst your list of files.

I hope you don't intend to run the C code on that chip because if you do you're in for a rude shock.

The PIC10 series are not supported by SourceBoostC as they don't have enough resources to run code compiled under C.

Share this post


Link to post
Share on other sites
I notice the PIC10F206.INC file amongst your list of files.

I hope you don't intend to run the C code on that chip because if you do you're in for a rude shock.

The PIC10 series are not supported by SourceBoostC as they don't have enough resources to run code compiled under C.

 

No, I realised that thanks.

 

Its a pity BoostC does not support this set as they are probably just as popular as any of the others.

Arch rivals are also quick to point out to their potential customers 'oh, by the way, make sure you check out what sets the compiler supports; ours supports all including the 12F series'

Share this post


Link to post
Share on other sites

Join the conversation

You are posting as a guest. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×
×
  • Create New...