Searching \ for '[PIC] A dsPIC30F programming question' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: techref.massmind.org/techref/microchip/devprogs.htm?key=programming
Search entire site for: 'A dsPIC30F programming question'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] A dsPIC30F programming question'
2006\01\26@185611 by Mark Jeronimus

picon face
Hi,

There is an instruction CP f, which compares f with WREG

Is this what you need?

Regards,
Mark Jeronimus

On 1/26/06, John Nall <spam_OUTjwnallTakeThisOuTspamgmail.com> wrote:
{Quote hidden}

> -

2006\01\26@191453 by John Nall

picon face
Mark Jeronimus wrote:

>> There is an instruction CP f, which compares f with WREG
>
>Is this what you need?
>  
>
.
No, because it compares f with WREG, but nothing else after that.  You
have to follow it with a "BRA EQ,$+4".  Whereas the 452 instruction
CPFSEQ both does a compare and a skip, with just the one instruction.  I
have pretty much decided that I just have to go with two instructions to
replace the one instruction, and do not see any way around it.  But it
is always worthwhile asking -- someone like Olin might jump in and tell
me how to do it with just one instruction. :-)

Anyway, in the meantime, I have discovered a few more like that.   So be
it.  Not very elegant, though.

John

2006\01\26@195821 by Mark Jeronimus

picon face
Being assembly language, there is a great chance some routines are very time
critical. The best way to translate these instruction is by hand, so you can
check if there will be any (slight) changes in the behaviour after a direct
approach. Doing this automatically is quite impossible because a computer
can never know what a bunch of instructions is supposed to do in the big
picture except their literal meaning.

Beat regards,
Mark Jeronimus

2006\01\26@201903 by John Nall

picon face
Mark Jeronimus wrote:
> Being assembly language, there is a great chance some routines are very time
> critical. The best way to translate these instruction is by hand, so you can
> check if there will be any (slight) changes in the behaviour after a direct
> approach. Doing this automatically is quite impossible because a computer
> can never know what a bunch of instructions is supposed to do in the big
> picture except their literal meaning

Well, yes, that is true, of course.  But I don't agree that doing it
automatically is quite impossible.   What that does is give you a
starting point.   In my case, I have some 18F452 code.  I know exactly
what it does, where the time-critical parts are, and which instructions
have to be included within a timing algorithm.  I can translate each
line by hand -- but, in the same amount of time, I think, I can write a
program which will automatically convert each line of the 452 code into
an equivalent line (or sometimes 2 lines) of 30F code.  Once that is
done, then I have to go through the new code, I agree.  But the next
time the issue comes up then the time will be a lot shorter.  Do you
disagree with that?  If so,  then I would love to hear why.  :-)

John

2006\01\26@211303 by Timothy Weber

face picon face
John Nall wrote:
> I can translate each
> line by hand -- but, in the same amount of time, I think, I can write a
> program which will automatically convert each line of the 452 code into
> an equivalent line (or sometimes 2 lines) of 30F code.  Once that is
> done, then I have to go through the new code, I agree.

Maybe you're already doing this, but inserting a big visible comment
before the second added instruction might make inspection easier.

In fact, inserting something that *won't* assemble, so you have to take
it out, would be a more extreme but even safer tactic.  Ensures that you
actually inspect each place where the code size was changed.
--
Timothy J. Weber
http://timothyweber.org

2006\01\26@221757 by John Nall

picon face
Timothy Weber wrote:

>
>> Maybe you're already doing this, but inserting a big visible comment
>before the second added instruction might make inspection easier.
>
>In fact, inserting something that *won't* assemble, so you have to take
>it out, would be a more extreme but even safer tactic.  Ensures that you
>actually inspect each place where the code size was changed.
>  
>
.
My thinking right now is along  the following lines:

1.  The 18F452 program must assemble with no errors, using MPASM.

2.  The translator will produce a 30F version which will assemble with
no errors, using ASM30,  but only after assembler directives have been
corrected by hand (such as INCLUDE, etc.)  The translator just passes
through directives, with no attempt to modify them in any way (ditto
with comments).

3.  The normal .s file produced by the translator will be just the
translated version of the 452 program.

4.  An optional .cmp file produced by the translator will be a listing
that, for every original 452 instruction, shows both the 452 version and
the 30F version.  That would give you the information you need to check
timing information and critical code.

Right now, I have the prototype version of the translator running (it is
a Perl script), with about half the 452 instructions mapped.   Once I
have every instruction mapped, then the work begins of verification,
which will be the tedious part.  Probably what I will do for that is
have side-by-side PC's, with MPLAB running on each one, and step through
each instruction, using the simulator and watching the appropriate
variables.  (One MPLAB will be simulating the 452, the other will be
simulating the 30F).  I feel  confident  this will produce some amazing
surprises.   :-)

John

2006\01\27@045213 by Alan B. Pearce

face picon face
>An optional .cmp file produced by the translator will be
>a listing that, for every original 452 instruction, shows
>both the 452 version and the 30F version.

Such a file is almost essential to my way of thinking. When I do
disassemblers, I always include the original hex as a comment, so if
something looks wrong it is easy to check. Having the original code as a
comment would be essential in a translator as well.

2006\01\27@050840 by Jan-Erik Soderholm

face picon face
Hi.
Even if this PIC18 -> PIC24/30/33 converter might be a
nice technical project, isn't the problem that the overall
application architecture will probably be quite wrong
for the "other" plattform ? Or at least, could have been
written much more efficiently ?

It's no different then porting PIC16 code to PIC18, b.t.w.
You can port it one instruction at-a-time, or you can look
over it and write it "better" on the PIC18 architecture. It
can even be more work to "fix" the machine-ported app
later then to think about it a bit more in the first place.

Still, it's an interesting programming projet, and I'm sure
you'll learn a lot about the instruction set... :-)

Jan-Erik.
>



2006\01\27@072030 by olin piclist

face picon face
John Nall wrote:
> someone like Olin might jump in and tell
> me how to do it with just one instruction. :-)
>
> Anyway, in the meantime, I have discovered a few more like that.   So be
> it.  Not very elegant, though.

There are a few operations for which a PIC 18 has a specific instruction
that the PIC 30 does not.  There are a few skip instructions, but there are
far more BRA instructions for conditionals.  Once you go native on the 30F
you won't use the file register operations much, and generally do arithmetic
decisions with BRA instructions.

The one I notice missing most is some sort of decrement and test in one
instruction, like DECFSZ on other PICs.  The PIC 30 does have the DO
instruction for looping, but it only has two hardware levels so you reserve
that for the rare bit of truly critical code.

You generally don't use file register instructions because these can only
reach a subset of the address space.  You can define some critical words to
be in near memory so that these instructions can be used, but you don't want
to do that generally in non-critical code (even though the RAM space of most
dsPICs is small enough so that all of it is "near", it's just not a good
practise.).

I hadn't jumped in here before because I personally don't see much point in
a PIC 18 to PIC 30 translator, other than it's something you want to do just
because you want to do it.  The differences in peripherals are going to make
all put purely "internal" code pretty much impossible.  You can make a PIC
30 stand on its head and waste a bunch of cycles and sortof act like a PIC
18 some ot the time with a lot of work.  I'd rather spend the time to recode
the application into native PIC 30 and get the full benefit of the
processor.  If you aren't pushing the speed, then why isn't the 18F good
enough in the first place?


******************************************************************
Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
consultant in 2004 program year.  http://www.embedinc.com/products

2006\01\27@084253 by John Nall

picon face
Jan-Erik Soderholm wrote:
> > Even if this PIC18 -> PIC24/30/33 converter might be a
> nice technical project, isn't the problem that the overall
> application architecture will probably be quite wrong
> for the "other" plattform ? Or at least, could have been
> written much more efficiently ?
>  
.
Oh, yes, absolutely  that is so!
.
> > It's no different then porting PIC16 code to PIC18, b.t.w.
> You can port it one instruction at-a-time, or you can look
> over it and write it "better" on the PIC18 architecture. It
> can even be more work to "fix" the machine-ported app
> later then to think about it a bit more in the first place.
>  
.
Yup.  No disagreement there, either.  You are stating the obvious,
Jan-Erik!  :-)
.
> > Still, it's an interesting programming project, and I'm sure
> you'll learn a lot about the instruction set... :-)
>  
.
That is true (already have), but also I needed to refresh myself with
Perl programming, and this is an excellent text-manipulation project.  
Pattern-matching and "regular expressions" have always been a weak area
in Perl for me -- probably because there is nothing intuitive about
looking at a statement such as "/^\$([A-Za-z]).*/" and making sense out
of it.  :-)

That said, I still think the translator would be useful for someone
wanting to convert code from one family to another family.  But only in
the sense of producing a starting point to work with.

John

2006\01\27@085113 by John Nall

picon face
Olin Lathrop wrote:
> < I hadn't jumped in here before because I personally don't see much point in
> a PIC 18 to PIC 30 translator, other than it's something you want to do just
> because you want to do it.
.
I would say that there probably isn't much point in such a translator
other than it's something I want to do just because I want to do it.  
It is an interesting project, and my reply to Jan-Erik's response
probably says it all.  One of  the joys of being both retired and a
hobbyist.  :-)

>  > I'd rather spend the time to recode
> the application into native PIC 30 and get the full benefit of the
> processor.  
.
Yes, that will be  the next step.  The translator merely produces a
starting point.

John

2006\01\27@140251 by Jorge Nakandakari

flavicon
face
Hi, there are some instructions that may work for you from the DSPIC30F
Programmer's Reference manual:

CPSEQ Wb,Wn --> Compare Wb-Wn, skip if =
CPSGT Wb,Wn --> Compare Wb-Wn, skip if >
CPSLT Wb,Wn --> Compare Wb-Wn, skip if <
CPSNE Wb,Wn --> Compare Wb-Wn, skip if Not Equal

Best regards,
   Jorge Nakandakari


2006\01\27@151824 by James Newton, Host

face picon face
> I hadn't jumped in here before because I personally don't see
> much point in a PIC 18 to PIC 30 translator, other than it's
> something you want to do just because you want to do it.  The
> differences in peripherals are going to make all put purely
> "internal" code pretty much impossible.  You can make a PIC
> 30 stand on its head and waste a bunch of cycles and sortof
> act like a PIC
> 18 some ot the time with a lot of work.  I'd rather spend the
> time to recode the application into native PIC 30 and get the
> full benefit of the processor.  If you aren't pushing the
> speed, then why isn't the 18F good enough in the first place?


There is a huge volume of available code on piclist.com that is not specific
to peripherals and which can most effectively be translated into PIC 30 code
with machine assistance. If the translation can be improved by hand,
hopefully people will do so and share the result.

---
James Newton: PICList webmaster/Admin
.....jamesnewtonKILLspamspam@spam@piclist.com  1-619-652-0593 phone
http://www.piclist.com/member/JMN-EFP-786
PIC/PICList FAQ: http://www.piclist.com



'[PIC] A dsPIC30F programming question'
2006\02\02@061133 by Alan B. Pearce
face picon face
>That said, I still think the translator would be useful
>for someone wanting to convert code from one family to
>another family.  But only in the sense of producing a
>starting point to work with.

IIRC the original IBM PC Basic was the Microsoft 8080 basic run through a
translator. I seem to remember articles in Byte magazine where people had
dug into the code and were able to show that some obviously hideous code
translations done by an Intel translator existed.

As the years went by I believe the GW-Basic version got cleaned up.

As for porting from 18F to 30F and onwards, there is probably a place for a
translator to deal with run of the mill code, leaving only some I/O specific
portions to be tidied up, when a project needs to take a processor leap due
to memory or I/O changes as feature creep comes in over the years.

On the other hand, such code may well be written in C, and able to be run
through the appropriate compiler for the new chip, resulting in better
optimisation anyway ...

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