9S12 project to 9S12X

Hi,

I would like to migrate a project written for 9S12A to a 9S12XA using
Freescale Codewarrior 4.6.
Is there any possibility to make it easily ? (excepting some parameters due
to clock....)

Thanks.
--

Start a New Thread

Hi,

I did that very easily from 9s12dp256 to 9s12XDP512 just by changing
#include file, (under ImageCraft ICC12) :

#include
replaced by
#include

No other problem for the soft I developed.
Warning, change in connect quartz...

Best regards.
Joel
> -----Message d'origine-----
> De: 6... [mailto:6...] De la part de
> toto261
> Envoy mercredi 18 juin 2008 15:06
> : 6...
> Objet: [68HC12] 9S12 project to 9S12X
>
>
> Hi,
>
> I would like to migrate a project written for 9S12A to a 9S12XA using
> Freescale Codewarrior 4.6.
> Is there any possibility to make it easily ? (excepting some parameters
> due
> to clock....)
>
> Thanks.
> --
>
>
>
>
>
> Start a New Thread

We also had to change the #pragma for banked data to use GPAGE instead of PPAGE. Before finding this out we had random restarts of the CPU due to invalid memory accesses. This applices to Freescale Codewarriors and the transition was made from dg256 to xdt512.



Kind regards

Daniel



________________________________

Fr: 6... [mailto:6...] F jpdi
Skickat: den 18 juni 2008 15:12
Till: 6...
ne: RE: [68HC12] 9S12 project to 9S12X



Hi,

I did that very easily from 9s12dp256 to 9s12XDP512 just by changing
#include file, (under ImageCraft ICC12) :

#include
replaced by
#include

No other problem for the soft I developed.
Warning, change in connect quartz...

Best regards.
Joel

> -----Message d'origine-----
> De : 6...





















Start a New Thread

Hello,

Even if transposing the PPAGE to GPAGE is a working solution, this is
a high waste of resources in term of clock cycles.
I suggest to read description of DIRECT RPAGE, PPAGE, EEPAGE
registers and use them instead.
Of course, if processing power is no object you don't need to worry.
However, using GPAGE for every single access makes you lose 1 cycle
per access + execution of changing GPAGE content.
GPAGE is only efficient when ponctual access a location outside of
current address scope is needed and the other ones are used for all
types of accesses.

Regards,
Alban Rampon.

--- In 6..., "Daniel Friberg"
wrote:
>
> We also had to change the #pragma for banked data to use GPAGE
instead of PPAGE. Before finding this out we had random restarts of
the CPU due to invalid memory accesses. This applices to Freescale
Codewarriors and the transition was made from dg256 to xdt512.
>
>
>
> Kind regards
>
> Daniel
>
>
>
> ________________________________
>
> Fr: 6... [mailto:6...] F
jpdi
> Skickat: den 18 juni 2008 15:12
> Till: 6...
> ne: RE: [68HC12] 9S12 project to 9S12X
>
>
>
> Hi,
>
> I did that very easily from 9s12dp256 to 9s12XDP512 just by changing
> #include file, (under ImageCraft ICC12) :
>
> #include
> replaced by
> #include
>
> No other problem for the soft I developed.
> Warning, change in connect quartz...
>
> Best regards.
> Joel
>
> > -----Message d'origine-----
> > De : 6...

























Start a New Thread

I think banked data (probably const), and then GPAGE were used for *large*
amounts of data, somewhat bigger than 16 or even 32k available in nonpaged
memory map. GPAGE is very efficient in many more cases than you pointed out.

Edward

----- Original Message -----
From: "Alban Rampon"
To: <6...>
Sent: Wednesday, June 18, 2008 9:23 PM
Subject: [68HC12] Re: 9S12 project to 9S12X
Hello,

Even if transposing the PPAGE to GPAGE is a working solution, this is
a high waste of resources in term of clock cycles.
I suggest to read description of DIRECT RPAGE, PPAGE, EEPAGE
registers and use them instead.
Of course, if processing power is no object you don't need to worry.
However, using GPAGE for every single access makes you lose 1 cycle
per access + execution of changing GPAGE content.
GPAGE is only efficient when ponctual access a location outside of
current address scope is needed and the other ones are used for all
types of accesses.

Regards,
Alban Rampon.

--- In 6..., "Daniel Friberg"
wrote:
>
> We also had to change the #pragma for banked data to use GPAGE
instead of PPAGE. Before finding this out we had random restarts of
the CPU due to invalid memory accesses. This applices to Freescale
Codewarriors and the transition was made from dg256 to xdt512.
>
> Kind regards
>
> Daniel
>
> ________________________________
>
> Fr: 6... [mailto:6...] F
jpdi
> Skickat: den 18 juni 2008 15:12
> Till: 6...
> ne: RE: [68HC12] 9S12 project to 9S12X
>
> Hi,
>
> I did that very easily from 9s12dp256 to 9s12XDP512 just by changing
> #include file, (under ImageCraft ICC12) :
>
> #include
> replaced by
> #include No other problem for the soft I developed.
> Warning, change in connect quartz...
>
> Best regards.
> Joel
>
> > -----Message d'origine-----
> > De : 6...

























Start a New Thread

Hello Edward,
I don't have the application details. What I understood is that all
paging calls were replaced by a GPAGE.
Even with large amount of data, you still lose one cycle for each
access, except if you also the DIRECT register as it makes you gain
one cycle.
Which means you can only break even and not get better performance.

GPAGE and PPAGE are both 8-bit registers completing the 16-Bit
address and therefore I don't understand how GPAGE would not have to
be updated as often as PPAGE when addressing large amount of memory.
[with the exception I mentioned in my post being that PPAGE is
already used (for execution and data is in another page)].

May you please explain to me ?

Regards,
Alban.

--- In 6..., "Edward Karpicz" wrote:
>
> I think banked data (probably const), and then GPAGE were used for
*large*
> amounts of data, somewhat bigger than 16 or even 32k available in
nonpaged
> memory map. GPAGE is very efficient in many more cases than you
pointed out.
>
> Edward
>
> ----- Original Message -----
> From: "Alban Rampon"
> To: <6...>
> Sent: Wednesday, June 18, 2008 9:23 PM
> Subject: [68HC12] Re: 9S12 project to 9S12X
> Hello,
>
> Even if transposing the PPAGE to GPAGE is a working solution, this
is
> a high waste of resources in term of clock cycles.
> I suggest to read description of DIRECT RPAGE, PPAGE, EEPAGE
> registers and use them instead.
> Of course, if processing power is no object you don't need to worry.
> However, using GPAGE for every single access makes you lose 1 cycle
> per access + execution of changing GPAGE content.
> GPAGE is only efficient when ponctual access a location outside of
> current address scope is needed and the other ones are used for all
> types of accesses.
>
> Regards,
> Alban Rampon.
Start a New Thread

Hi

> Hello Edward,
> I don't have the application details. What I understood is that all
> paging calls were replaced by a GPAGE.

I'm not sure I understand what are those "paging calls"? Are you talking
about function calls here? Is so then GPAGE has nothing in common with
function calls.
> Even with large amount of data, you still lose one cycle for each
> access, except if you also the DIRECT register as it makes you gain
> one cycle.
> Which means you can only break even and not get better performance.

Try on S12D (not S12XD) defining and using say 60k of const data in flash
for strings, calibration constants etc, and code in paged memory. Large
memory model if you are using CW. Then do the same using S12XD. Compare
performance and figure that this waste of single cycle is nothing compared
to very slow call to routine in nonpaged memory, that switches PPAGE, copies
byte or so from PPAGE window, then switches PPAGE back and returns to
function that accessed just byte.

>
> GPAGE and PPAGE are both 8-bit registers completing the 16-Bit
> address and therefore I don't understand how GPAGE would not have to
> be updated as often as PPAGE when addressing large amount of memory.

What if you need just 64k of data? GPAGE could be fixed then. Even if you
rewrite GPAGE on each access, it's many times faster than banked data on
S12.

> [with the exception I mentioned in my post being that PPAGE is
> already used (for execution and data is in another page)].
>
> May you please explain to me ?

Hope I did.

Regards,
Edward

>
> Regards,
> Alban.
>
> --- In 6..., "Edward Karpicz" wrote:
>>
>> I think banked data (probably const), and then GPAGE were used for
> *large*
>> amounts of data, somewhat bigger than 16 or even 32k available in
> nonpaged
>> memory map. GPAGE is very efficient in many more cases than you
> pointed out.
>>
>> Edward
>>
>> ----- Original Message -----
>> From: "Alban Rampon"
>> To: <6...>
>> Sent: Wednesday, June 18, 2008 9:23 PM
>> Subject: [68HC12] Re: 9S12 project to 9S12X
>> Hello,
>>
>> Even if transposing the PPAGE to GPAGE is a working solution, this
> is
>> a high waste of resources in term of clock cycles.
>> I suggest to read description of DIRECT RPAGE, PPAGE, EEPAGE
>> registers and use them instead.
>> Of course, if processing power is no object you don't need to worry.
>> However, using GPAGE for every single access makes you lose 1 cycle
>> per access + execution of changing GPAGE content.
>> GPAGE is only efficient when ponctual access a location outside of
>> current address scope is needed and the other ones are used for all
>> types of accesses.
>>
>> Regards,
>> Alban Rampon.
> Start a New Thread

Hello Edward,

Yes, you did explain and we were not talking about the same.

I was not comparing the efficiency S12 vs. S12X, but I was
disagreeing to simply replace all the use of paging to GPAGE in S12X
instead of also using over paging schemes.

What happened here is that a solution given to the poster, in order
to transfer an S12 project to S12X, was to replace PPAGE with GPAGE
(use = "call" I mentioned in my previous post).
I was mentioning the waste of performance in doing so.
It's a bit like having only the PPAGE on S12, except that the S12X
will need one more cycle for a GPAGE that an S12 does for a PPAGE...

I probably should have been clearer in the first place.
Warm Regards,
Alban.

--- In 6..., "Edward Karpicz" wrote:
>
> Hi
>
> > Hello Edward,
> > I don't have the application details. What I understood is that
all
> > paging calls were replaced by a GPAGE.
>
> I'm not sure I understand what are those "paging calls"? Are you
talking
> about function calls here? Is so then GPAGE has nothing in common
with
> function calls.
> > Even with large amount of data, you still lose one cycle for each
> > access, except if you also the DIRECT register as it makes you
gain
> > one cycle.
> > Which means you can only break even and not get better
performance.
>
> Try on S12D (not S12XD) defining and using say 60k of const data in
flash
> for strings, calibration constants etc, and code in paged memory.
Large
> memory model if you are using CW. Then do the same using S12XD.
Compare
> performance and figure that this waste of single cycle is nothing
compared
> to very slow call to routine in nonpaged memory, that switches
PPAGE, copies
> byte or so from PPAGE window, then switches PPAGE back and returns
to
> function that accessed just byte.
>
> >
> > GPAGE and PPAGE are both 8-bit registers completing the 16-Bit
> > address and therefore I don't understand how GPAGE would not have
to
> > be updated as often as PPAGE when addressing large amount of
memory.
>
> What if you need just 64k of data? GPAGE could be fixed then. Even
if you
> rewrite GPAGE on each access, it's many times faster than banked
data on
> S12.
>
> > [with the exception I mentioned in my post being that PPAGE is
> > already used (for execution and data is in another page)].
> >
> > May you please explain to me ?
>
> Hope I did.
>
> Regards,
> Edward

Start a New Thread

Hi Alban

I still don't understand something. What waste of performance? Waste of
performance replacing PPAGE calls with absolutely impossible GPAGE calls???
S12X can't execute code in global memory (GPAGE). I absolutely not
understand what you are talking about, no idea at all. Sorry

Regards
Edward
----- Original Message -----
From: "Alban Rampon"
To: <6...>
Sent: Monday, June 23, 2008 7:28 AM
Subject: [68HC12] Re: 9S12 project to 9S12X
> Hello Edward,
>
> Yes, you did explain and we were not talking about the same.
>
> I was not comparing the efficiency S12 vs. S12X, but I was
> disagreeing to simply replace all the use of paging to GPAGE in S12X
> instead of also using over paging schemes.
>
> What happened here is that a solution given to the poster, in order
> to transfer an S12 project to S12X, was to replace PPAGE with GPAGE
> (use = "call" I mentioned in my previous post).
> I was mentioning the waste of performance in doing so.
> It's a bit like having only the PPAGE on S12, except that the S12X
> will need one more cycle for a GPAGE that an S12 does for a PPAGE...
>
> I probably should have been clearer in the first place.
> Warm Regards,
> Alban.
>
> --- In 6..., "Edward Karpicz" wrote:
>>
>> Hi
>>
>> > Hello Edward,
>> > I don't have the application details. What I understood is that
> all
>> > paging calls were replaced by a GPAGE.
>>
>> I'm not sure I understand what are those "paging calls"? Are you
> talking
>> about function calls here? Is so then GPAGE has nothing in common
> with
>> function calls.
>> > Even with large amount of data, you still lose one cycle for each
>> > access, except if you also the DIRECT register as it makes you
> gain
>> > one cycle.
>> > Which means you can only break even and not get better
> performance.
>>
>> Try on S12D (not S12XD) defining and using say 60k of const data in
> flash
>> for strings, calibration constants etc, and code in paged memory.
> Large
>> memory model if you are using CW. Then do the same using S12XD.
> Compare
>> performance and figure that this waste of single cycle is nothing
> compared
>> to very slow call to routine in nonpaged memory, that switches
> PPAGE, copies
>> byte or so from PPAGE window, then switches PPAGE back and returns
> to
>> function that accessed just byte.
>>
>> >
>> > GPAGE and PPAGE are both 8-bit registers completing the 16-Bit
>> > address and therefore I don't understand how GPAGE would not have
> to
>> > be updated as often as PPAGE when addressing large amount of
> memory.
>>
>> What if you need just 64k of data? GPAGE could be fixed then. Even
> if you
>> rewrite GPAGE on each access, it's many times faster than banked
> data on
>> S12.
>>
>> > [with the exception I mentioned in my post being that PPAGE is
>> > already used (for execution and data is in another page)].
>> >
>> > May you please explain to me ?
>>
>> Hope I did.
>>
>> Regards,
>> Edward
>
> Start a New Thread