Hello all,
I have a C + assembly program that I wrote that needs to get through an ISR as quickly as possible. Time is very critical and I am counting every ISR clock cycle. The rest of the program is written in C, and it can take its time doing what it needs to do.

I wrote the ISR in assembly and I need to preserve 2 of the 16 general purpose CPU registers for the ISR so I can save the push and pop instructions that would otherwise restore them on the way out.

I am using CCE Pro tools on a MSP430F2131. Does anyone know of a way to tell the compiler to keeps its grubby hands off of two of the CPU registers? It works right now, but adding things in the C code causes the compiler to needlessly gobble up another register or two. Any info would be appreciated.

Thanks -
Dave

------------------------------------

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

I use IAR KickStart. You can tell the c compiler hands off R4 & R5.

--- In m...@yahoogroups.com, "desertrc_tucson" wrote:
>
> Hello all,
> I have a C + assembly program that I wrote that needs to get through an ISR as quickly as possible. Time is very critical and I am counting every ISR clock cycle. The rest of the program is written in C, and it can take its time doing what it needs to do.
>
> I wrote the ISR in assembly and I need to preserve 2 of the 16 general purpose CPU registers for the ISR so I can save the push and pop instructions that would otherwise restore them on the way out.
>
> I am using CCE Pro tools on a MSP430F2131. Does anyone know of a way to tell the compiler to keeps its grubby hands off of two of the CPU registers? It works right now, but adding things in the C code causes the compiler to needlessly gobble up another register or two. Any info would be appreciated.
>
> Thanks -
> Dave
>

------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

To be quite honest, if the timing on your interrupt function is so
tight that you cannot afford the 4 instructions required to push and
pop these registers then there is an inadequacy in your system design.
Your choice of processor or processing clock speed needs to be
re-considered because, if your processing is really as tight as you
say, something WILL cause a sufficient delay to one of your interrupts
so that the processing fails.

Ian

2009/10/21 old_cow_yellow :
> I use IAR KickStart. You can tell the c compiler hands off R4 & R5.
>
> --- In m...@yahoogroups.com, "desertrc_tucson" wrote:
>>
>> Hello all,
>> I have a C + assembly program that I wrote that needs to get through an ISR as quickly as possible. Time is very critical and I am counting every ISR clock cycle. The rest of the program is written in C, and it can take its time doing what it needs to do.
>>
>> I wrote the ISR in assembly and I need to preserve 2 of the 16 general purpose CPU registers for the ISR so I can save the push and pop instructions that would otherwise restore them on the way out.
>>
>> I am using CCE Pro tools on a MSP430F2131. Does anyone know of a way to tell the compiler to keeps its grubby hands off of two of the CPU registers? It works right now, but adding things in the C code causes the compiler to needlessly gobble up another register or two. Any info would be appreciated.
>>
>> Thanks -
>> Dave
>>
> ------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

----- Original Message -----
From: Ian Okey
To: m...@yahoogroups.com
Sent: Wednesday, October 21, 2009 9:44 AM
Subject: Re: [msp430] Re: Preserving CPU Registers

To be quite honest, if the timing on your interrupt function is so
tight that you cannot afford the 4 instructions required to push and
pop these registers then there is an inadequacy in your system design.
Your choice of processor or processing clock speed needs to be
re-considered because, if your processing is really as tight as you
say, something WILL cause a sufficient delay to one of your interrupts
so that the processing fails.

Ian

2009/10/21 old_cow_yellow :
> I use IAR KickStart. You can tell the c compiler hands off R4 & R5.
>
> --- In m...@yahoogroups.com, "desertrc_tucson" wrote:
>>
>> Hello all,
>> I have a C + assembly program that I wrote that needs to get through an ISR as quickly as possible. Time is very critical and I am counting every ISR clock cycle. The rest of the program is written in C, and it can take its time doing what it needs to do.
>>
>> I wrote the ISR in assembly and I need to preserve 2 of the 16 general purpose CPU registers for the ISR so I can save the push and pop instructions that would otherwise restore them on the way out.
>>
>> I am using CCE Pro tools on a MSP430F2131. Does anyone know of a way to tell the compiler to keeps its grubby hands off of two of the CPU registers? It works right now, but adding things in the C code causes the compiler to needlessly gobble up another register or two. Any info would be appreciated.
>>
>> Thanks -
>> Dave
>

.

The question is if program is time critical by programming method or by condition. Preventing registers is not only about push/pop - in some case you can store buffer position directly in register and then for 256 bytes buffer for sirial line receiving you can write ISR like this>
mov.b &U0RXBUF, buffer(R4)
inc.b R4
totally 4 cycles in case R4 is DEDICATED as buffer pointer only
In other case, if R4 (all registers) is "general purpose" you can rewrite code as follow:
push R4
mov.b &pos,R4 ; for indirect addresing I have to use register
mov.b &U0RXBUF,buffer(R4)
inc.b R4
mov.b R4,&pos
pop R4
totally 16 cycles, in other words 4-times (!) longer

Jarda
[Non-text portions of this message have been removed]

------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

If your timing is so tight, can you crank-up your MCLK during your critical section? If it's just for a brief time, it should barely make a dent in your power consumption.

Stuart

--- In m...@yahoogroups.com, "desertrc_tucson" wrote:
>
> Hello all,
> I have a C + assembly program that I wrote that needs to get through an ISR as quickly as possible. Time is very critical and I am counting every ISR clock cycle. The rest of the program is written in C, and it can take its time doing what it needs to do.
>
> I wrote the ISR in assembly and I need to preserve 2 of the 16 general purpose CPU registers for the ISR so I can save the push and pop instructions that would otherwise restore them on the way out.
>
> I am using CCE Pro tools on a MSP430F2131. Does anyone know of a way to tell the compiler to keeps its grubby hands off of two of the CPU registers? It works right now, but adding things in the C code causes the compiler to needlessly gobble up another register or two. Any info would be appreciated.
>
> Thanks -
> Dave
>

------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

It may be 4 times longer but 4 times nearly nothing is still nearly
nothing. If I pay you CZK16 because it is 4 times the CZK4 that I
paid you last week you are hardly going to feel rich despite the 400%
pay rise that I have just given you.

Having a system that relies on such narrow margins is just not good Enginee=
ring.

Ian

(CZK16 =3D =A30.55 =3D =800.62 ~=3D Small chocolate bar)

2009/10/21 Jaromir Subcik :
>
> =A0----- Original Message -----
> =A0From: Ian Okey
> =A0To: m...@yahoogroups.com
> =A0Sent: Wednesday, October 21, 2009 9:44 AM
> =A0Subject: Re: [msp430] Re: Preserving CPU Registers
>
> =A0To be quite honest, if the timing on your interrupt function is so
> =A0tight that you cannot afford the 4 instructions required to push and
> =A0pop these registers then there is an inadequacy in your system design.
> =A0Your choice of processor or processing clock speed needs to be
> =A0re-considered because, if your processing is really as tight as you
> =A0say, something WILL cause a sufficient delay to one of your interrupts
> =A0so that the processing fails.
>
> =A0Ian
>
> =A02009/10/21 old_cow_yellow :
> =A0> I use IAR KickStart. You can tell the c compiler hands off R4 & R5.
> =A0>
> =A0> --- In m...@yahoogroups.com, "desertrc_tucson" wrote=
:
> =A0>>
> =A0>> Hello all,
> =A0>> I have a C + assembly program that I wrote that needs to get throug=
h an ISR as quickly as possible. Time is very critical and I am counting ev=
ery ISR clock cycle. The rest of the program is written in C, and it can ta=
ke its time doing what it needs to do.
> =A0>>
> =A0>> I wrote the ISR in assembly and I need to preserve 2 of the 16 gene=
ral purpose CPU registers for the ISR so I can save the push and pop instru=
ctions that would otherwise restore them on the way out.
> =A0>>
> =A0>> I am using CCE Pro tools on a MSP430F2131. Does anyone know of a wa=
y to tell the compiler to keeps its grubby hands off of two of the CPU regi=
sters? It works right now, but adding things in the C code causes the compi=
ler to needlessly gobble up another register or two. Any info would be appr=
eciated.
> =A0>>
> =A0>> Thanks -
> =A0>> Dave
> =A0> =A0.
>
> The question is if program is time critical by programming method or by c=
ondition. Preventing registers is not only about push/pop - in some case yo=
u can store buffer position directly in register and then for 256 bytes buf=
fer for sirial line receiving you can write ISR like this>
> =A0mov.b =A0 =A0&U0RXBUF, buffer(R4)
> =A0inc.b =A0 =A0 =A0R4
> totally 4 cycles in case R4 is DEDICATED as buffer pointer only
> In other case, if R4 (all registers) is "general purpose" you can rewrite=
code as follow:
> =A0 =A0push =A0 =A0R4
> =A0 =A0mov.b =A0 =A0&pos,R4 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0; for indirect=
addresing I have to use register
> =A0 =A0mov.b =A0 =A0&U0RXBUF,buffer(R4)
> =A0 =A0inc.b =A0 =A0R4
> =A0 =A0mov.b =A0 =A0R4,&pos
> =A0 =A0pop =A0 =A0 R4
> totally 16 cycles, in other words 4-times (!) longer
>
> Jarda
> [Non-text portions of this message have been removed]
>
> ------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

Ian,
sorry, but your answer is not so polite for technical discusion.
O.K. - in case of payment 4CZK every second I'm going to feel very rich
;-)))

I have battery powered project with serial line (115200Bd) where each 10ms
is transmitted 16bytes and in this case my example save 19200 cycles each
second. With 8MHz Xtal (MSP430F413) it represent 2.4ms. Total active time in
my case is 6ms per second (awerage value depending on action) compare to
8.4ms without optimisation it represents +30% battery life. Protocol is out
of my control ;-(, thus I cannot optimise it.
Yes in this case I feel rich ;-)

O.T. From my point of view vasting computing time leads to as slow product
as Microsoft Word is.

Jarda

----- Original Message -----
From: "Ian Okey"
To:
Sent: Wednesday, October 21, 2009 2:22 PM
Subject: Re: [msp430] Re: Preserving CPU Registers
It may be 4 times longer but 4 times nearly nothing is still nearly
nothing. If I pay you CZK16 because it is 4 times the CZK4 that I
paid you last week you are hardly going to feel rich despite the 400%
pay rise that I have just given you.

Having a system that relies on such narrow margins is just not good
Engineering.

Ian

(CZK16 = £0.55 = €0.62 ~= Small chocolate bar)

2009/10/21 Jaromir Subcik :
>
> ----- Original Message -----
> From: Ian Okey
> To: m...@yahoogroups.com
> Sent: Wednesday, October 21, 2009 9:44 AM
> Subject: Re: [msp430] Re: Preserving CPU Registers
>
> To be quite honest, if the timing on your interrupt function is so
> tight that you cannot afford the 4 instructions required to push and
> pop these registers then there is an inadequacy in your system design.
> Your choice of processor or processing clock speed needs to be
> re-considered because, if your processing is really as tight as you
> say, something WILL cause a sufficient delay to one of your interrupts
> so that the processing fails.
>
> Ian
>
> 2009/10/21 old_cow_yellow :
> > I use IAR KickStart. You can tell the c compiler hands off R4 & R5.
> >
> > --- In m...@yahoogroups.com, "desertrc_tucson" wrote:
> >>
> >> Hello all,
> >> I have a C + assembly program that I wrote that needs to get through an
> >> ISR as quickly as possible. Time is very critical and I am counting
> >> every ISR clock cycle. The rest of the program is written in C, and it
> >> can take its time doing what it needs to do.
> >>
> >> I wrote the ISR in assembly and I need to preserve 2 of the 16 general
> >> purpose CPU registers for the ISR so I can save the push and pop
> >> instructions that would otherwise restore them on the way out.
> >>
> >> I am using CCE Pro tools on a MSP430F2131. Does anyone know of a way to
> >> tell the compiler to keeps its grubby hands off of two of the CPU
> >> registers? It works right now, but adding things in the C code causes
> >> the compiler to needlessly gobble up another register or two. Any info
> >> would be appreciated.
> >>
> >> Thanks -
> >> Dave
> > .
>
> The question is if program is time critical by programming method or by
> condition. Preventing registers is not only about push/pop - in some case
> you can store buffer position directly in register and then for 256 bytes
> buffer for sirial line receiving you can write ISR like this>
> mov.b &U0RXBUF, buffer(R4)
> inc.b R4
> totally 4 cycles in case R4 is DEDICATED as buffer pointer only
> In other case, if R4 (all registers) is "general purpose" you can rewrite
> code as follow:
> push R4
> mov.b &pos,R4 ; for indirect addresing I have to use register
> mov.b &U0RXBUF,buffer(R4)
> inc.b R4
> mov.b R4,&pos
> pop R4
> totally 16 cycles, in other words 4-times (!) longer
>
> Jarda
> [Non-text portions of this message have been removed]

------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

Very neat solution to maximizing battery usage in an efficient manner. I
hope you don't mind if I bury this in my technical tricks to remember file.
May not be necessary as self-discharge of the battery is probably nearly
equivalent to the drain caused by the infrequently used MSP430 but still an
interesting trick :)

Have a better one,

Alan

On Wed, 21 Oct 2009 16:10:16 +0200, "Jaromir Subcik"
wrote:
> I have battery powered project with serial line (115200Bd) where each
10ms
> is transmitted 16bytes and in this case my example save 19200 cycles
each
> second. With 8MHz Xtal (MSP430F413) it represent 2.4ms. Total active
time
> in
> my case is 6ms per second (awerage value depending on action) compare to

> 8.4ms without optimisation it represents +30% battery life.
------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

The answer is both polite enough and correct enough. If your system is
truly that clock conscious then it has no margin for error, and since
you do not understand how to solve these problems yourself, it suggests
your experience is such that you cannot possibly consider your system
will be free of errors, or will have considered all unexpected
circumstances, therefore you would probably do well to heed the advice
offered. If it is that critical why not simply write the whole thing in
assembler? That way you get to optimise register usage yourself and all
the interrupts will be free from register stacking.

Al

P.S.

CZK16 = £0.55 = aus$0.95 = 1 SHOT @ lotto on 31st OCTOBER 2009 odds =
1:8,145,060, 1ST PRIZE = $20,000,000. pot odds are in favour

Jaromir Subcik wrote:
> Ian,
> sorry, but your answer is not so polite for technical discusion.
> O.K. - in case of payment 4CZK every second I'm going to feel very rich
> ;-)))
>
> I have battery powered project with serial line (115200Bd) where each 10ms
> is transmitted 16bytes and in this case my example save 19200 cycles each
> second. With 8MHz Xtal (MSP430F413) it represent 2.4ms. Total active time in
> my case is 6ms per second (awerage value depending on action) compare to
> 8.4ms without optimisation it represents +30% battery life. Protocol is out
> of my control ;-(, thus I cannot optimise it.
> Yes in this case I feel rich ;-)
>
> O.T. From my point of view vasting computing time leads to as slow product
> as Microsoft Word is.
>
> Jarda
>
> ----- Original Message -----
> From: "Ian Okey"
> To:
> Sent: Wednesday, October 21, 2009 2:22 PM
> Subject: Re: [msp430] Re: Preserving CPU Registers
> It may be 4 times longer but 4 times nearly nothing is still nearly
> nothing. If I pay you CZK16 because it is 4 times the CZK4 that I
> paid you last week you are hardly going to feel rich despite the 400%
> pay rise that I have just given you.
>
> Having a system that relies on such narrow margins is just not good
> Engineering.
>
> Ian
>
> (CZK16 = £0.55 = €0.62 ~= Small chocolate bar)
>
> 2009/10/21 Jaromir Subcik :
>> ----- Original Message -----
>> From: Ian Okey
>> To: m...@yahoogroups.com
>> Sent: Wednesday, October 21, 2009 9:44 AM
>> Subject: Re: [msp430] Re: Preserving CPU Registers
>>
>> To be quite honest, if the timing on your interrupt function is so
>> tight that you cannot afford the 4 instructions required to push and
>> pop these registers then there is an inadequacy in your system design.
>> Your choice of processor or processing clock speed needs to be
>> re-considered because, if your processing is really as tight as you
>> say, something WILL cause a sufficient delay to one of your interrupts
>> so that the processing fails.
>>
>> Ian
>>
>> 2009/10/21 old_cow_yellow :
>>> I use IAR KickStart. You can tell the c compiler hands off R4 & R5.
>>>
>>> --- In m...@yahoogroups.com, "desertrc_tucson" wrote:
>>>> Hello all,
>>>> I have a C + assembly program that I wrote that needs to get through an
>>>> ISR as quickly as possible. Time is very critical and I am counting
>>>> every ISR clock cycle. The rest of the program is written in C, and it
>>>> can take its time doing what it needs to do.
>>>>
>>>> I wrote the ISR in assembly and I need to preserve 2 of the 16 general
>>>> purpose CPU registers for the ISR so I can save the push and pop
>>>> instructions that would otherwise restore them on the way out.
>>>>
>>>> I am using CCE Pro tools on a MSP430F2131. Does anyone know of a way to
>>>> tell the compiler to keeps its grubby hands off of two of the CPU
>>>> registers? It works right now, but adding things in the C code causes
>>>> the compiler to needlessly gobble up another register or two. Any info
>>>> would be appreciated.
>>>>
>>>> Thanks -
>>>> Dave
>> .
>>
>> The question is if program is time critical by programming method or by
>> condition. Preventing registers is not only about push/pop - in some case
>> you can store buffer position directly in register and then for 256 bytes
>> buffer for sirial line receiving you can write ISR like this>
>> mov.b &U0RXBUF, buffer(R4)
>> inc.b R4
>> totally 4 cycles in case R4 is DEDICATED as buffer pointer only
>> In other case, if R4 (all registers) is "general purpose" you can rewrite
>> code as follow:
>> push R4
>> mov.b &pos,R4 ; for indirect addresing I have to use register
>> mov.b &U0RXBUF,buffer(R4)
>> inc.b R4
>> mov.b R4,&pos
>> pop R4
>> totally 16 cycles, in other words 4-times (!) longer
>>
>> Jarda
>> [Non-text portions of this message have been removed]
>>
>> ------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

Sorry for getting back so late, and thank you for all of your responses. I =
understand real-time systems very well, I even teach it, and I understand t=
he trade-offs associated with cost vs performance. It is easy to do the ana=
lysis for the real-time processing, and it is easy to understand the system=
requirements as they relate to the interrupt service. This is not rocket s=
cience, my friends, and I have taken proper precautions to guarantee that n=
othing else will get in the way. The solution is simple, and the analysis h=
as been verified. That being said, there appears to be two solutions propos=
ed since the device is already running at 16MHz all the time. 1) Write the =
whole thing in assembler, or 2) use IAR with the ability to say "hands off"=
to a register pair. I like option 2, especially since the tools for such a=
small processor are free.=20

Thanks for the suggestions,
Dave
--- In m...@yahoogroups.com, OneStone wrote:
>
> The answer is both polite enough and correct enough. If your system is=20
> truly that clock conscious then it has no margin for error, and since=20
> you do not understand how to solve these problems yourself, it suggests=20
> your experience is such that you cannot possibly consider your system=20
> will be free of errors, or will have considered all unexpected=20
> circumstances, therefore you would probably do well to heed the advice=20
> offered. If it is that critical why not simply write the whole thing in=20
> assembler? That way you get to optimise register usage yourself and all=20
> the interrupts will be free from register stacking.
>=20
> Al
>=20
> P.S.
>=20
> CZK16 =3D =EF=BF=BD0.55 =3D aus$0.95 =3D 1 SHOT @ lotto on 31st OCTOBER 2=
009 odds =3D=20
> 1:8,145,060, 1ST PRIZE =3D $20,000,000. pot odds are in favour
>=20
> Jaromir Subcik wrote:
> > Ian,
> > sorry, but your answer is not so polite for technical discusion.
> > O.K. - in case of payment 4CZK every second I'm going to feel very ri=
ch=20
> > ;-)))
> >=20
> > I have battery powered project with serial line (115200Bd) where each 1=
0ms=20
> > is transmitted 16bytes and in this case my example save 19200 cycles ea=
ch=20
> > second. With 8MHz Xtal (MSP430F413) it represent 2.4ms. Total active ti=
me in=20
> > my case is 6ms per second (awerage value depending on action) compare t=
o=20
> > 8.4ms without optimisation it represents +30% battery life. Protocol is=
out=20
> > of my control ;-(, thus I cannot optimise it.
> > Yes in this case I feel rich ;-)
> >=20
> > O.T. From my point of view vasting computing time leads to as slow prod=
uct=20
> > as Microsoft Word is.
> >=20
> > Jarda
> >=20
> > ----- Original Message -----=20
> > From: "Ian Okey"
> > To:
> > Sent: Wednesday, October 21, 2009 2:22 PM
> > Subject: Re: [msp430] Re: Preserving CPU Registers
> >=20
> >=20
> > It may be 4 times longer but 4 times nearly nothing is still nearly
> > nothing. If I pay you CZK16 because it is 4 times the CZK4 that I
> > paid you last week you are hardly going to feel rich despite the 400%
> > pay rise that I have just given you.
> >=20
> > Having a system that relies on such narrow margins is just not good=20
> > Engineering.
> >=20
> > Ian
> >=20
> > (CZK16 =3D =EF=BF=BD0.55 =3D =EF=BF=BD0.62 ~=3D Small chocolate bar)
> >=20
> > 2009/10/21 Jaromir Subcik :
> >> ----- Original Message -----
> >> From: Ian Okey
> >> To: m...@yahoogroups.com
> >> Sent: Wednesday, October 21, 2009 9:44 AM
> >> Subject: Re: [msp430] Re: Preserving CPU Registers
> >>
> >> To be quite honest, if the timing on your interrupt function is so
> >> tight that you cannot afford the 4 instructions required to push and
> >> pop these registers then there is an inadequacy in your system design.
> >> Your choice of processor or processing clock speed needs to be
> >> re-considered because, if your processing is really as tight as you
> >> say, something WILL cause a sufficient delay to one of your interrupts
> >> so that the processing fails.
> >>
> >> Ian
> >>
> >> 2009/10/21 old_cow_yellow :
> >>> I use IAR KickStart. You can tell the c compiler hands off R4 & R5.
> >>>
> >>> --- In m...@yahoogroups.com, "desertrc_tucson" wrote:
> >>>> Hello all,
> >>>> I have a C + assembly program that I wrote that needs to get through=
an=20
> >>>> ISR as quickly as possible. Time is very critical and I am counting=
=20
> >>>> every ISR clock cycle. The rest of the program is written in C, and =
it=20
> >>>> can take its time doing what it needs to do.
> >>>>
> >>>> I wrote the ISR in assembly and I need to preserve 2 of the 16 gener=
al=20
> >>>> purpose CPU registers for the ISR so I can save the push and pop=20
> >>>> instructions that would otherwise restore them on the way out.
> >>>>
> >>>> I am using CCE Pro tools on a MSP430F2131. Does anyone know of a way=
to=20
> >>>> tell the compiler to keeps its grubby hands off of two of the CPU=20
> >>>> registers? It works right now, but adding things in the C code cause=
s=20
> >>>> the compiler to needlessly gobble up another register or two. Any in=
fo=20
> >>>> would be appreciated.
> >>>>
> >>>> Thanks -
> >>>> Dave
> >> .
> >>
> >> The question is if program is time critical by programming method or b=
y=20
> >> condition. Preventing registers is not only about push/pop - in some c=
ase=20
> >> you can store buffer position directly in register and then for 256 by=
tes=20
> >> buffer for sirial line receiving you can write ISR like this>
> >> mov.b &U0RXBUF, buffer(R4)
> >> inc.b R4
> >> totally 4 cycles in case R4 is DEDICATED as buffer pointer only
> >> In other case, if R4 (all registers) is "general purpose" you can rewr=
ite=20
> >> code as follow:
> >> push R4
> >> mov.b &pos,R4 ; for indirect addresing I have to use register
> >> mov.b &U0RXBUF,buffer(R4)
> >> inc.b R4
> >> mov.b R4,&pos
> >> pop R4
> >> totally 16 cycles, in other words 4-times (!) longer
> >>
> >> Jarda
> >>
> >>
> >> [Non-text portions of this message have been removed]
> >>
> >>
> >=20
> >=20
> >=20
> >=20
> >=20
> > ------------------------------------
> >=20
> >
> >=20
> >



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

Hi Dave,

I've glanced at this thread briefly because I dropped in it just now. I
agree with you in that you're trying to optimise the ISR.
In actual fact I personally encourage it as well. Ideally, anyone writing
in a HLL
like C should still understand the low machine level. Different constructs
and techniqiues in C
can heavily vary the produced code. Thus IMO the coder should know enough
about the machine to write
C code resulting in smallest generated object code (and the specific
compiler for that matter).

That said, you CAN still write your ISR in C AND produce code that equals
ASM.
(I've done it many times, so I think I understand what you mean)
But this will - in many cases - rely on the specific machine, and very
likely also on a particular C compiler.
That of course kinda defeats the whole idea of HLL, but again, not
necessarily.

I'm all too familiar with the desire to produce the tightest and most
efficient ASM from your C code, even from an ISR. I think that's great.
But indeed, if this need is because you're intrinsically relying on it in
your system design, then be cautious of course - I'd take the "criticism"
of others under advice.
It works for you that the ISR, once entered, can't be re-interrupted by
default. But make sure it conversely doesn;t work against you, else
you'll need constructs to stop this from happening and before you know it
you could be spending more time debugging and integrating
the final (proper) system, rather than re-iterate the system design with a
"head aches -free" ISR.

I think more queries like yours should be thrown around. But do make sure
you're doing this for the _right_ reasons !
FWIW It sounds like you do....

Finally, IMO don't listen to critics claiming this should be in ASM and
args a la - C "can't do this".
The ones I've seen bagging C over the years on this group seem to have
invariably demonstrated that their anti-C opinion is uninformed - it's
through a lack of understanding embedded C .....
Have fun.

B rgds
Kris
On Thu, 22 Oct 2009 15:29:49 -0000, "desertrc_tucson"
wrote:
> Sorry for getting back so late, and thank you for all of your responses.
I
> understand real-time systems very well, I even teach it, and I
understand
> the trade-offs associated with cost vs performance. It is easy to do the
> analysis for the real-time processing, and it is easy to understand the
> system requirements as they relate to the interrupt service. This is not
> rocket science, my friends, and I have taken proper precautions to
> guarantee that nothing else will get in the way. The solution is simple,
> and the analysis has been verified. That being said, there appears to be
> two solutions proposed since the device is already running at 16MHz all
the
> time. 1) Write the whole thing in assembler, or 2) use IAR with the
ability
> to say "hands off" to a register pair. I like option 2, especially since
> the tools for such a small processor are free.
>
> Thanks for the suggestions,
> Dave
> --- In m...@yahoogroups.com, OneStone wrote:
>>
>> The answer is both polite enough and correct enough. If your system is
>> truly that clock conscious then it has no margin for error, and since
>> you do not understand how to solve these problems yourself, it suggests

>> your experience is such that you cannot possibly consider your system
>> will be free of errors, or will have considered all unexpected
>> circumstances, therefore you would probably do well to heed the advice
>> offered. If it is that critical why not simply write the whole thing in

>> assembler? That way you get to optimise register usage yourself and all

>> the interrupts will be free from register stacking.
>>
>> Al
>>
>> P.S.
>>
>> CZK16 = �0.55 = aus$0.95 = 1 SHOT @ lotto on 31st OCTOBER 2009 odds =
>> 1:8,145,060, 1ST PRIZE = $20,000,000. pot odds are in favour
>>
>> Jaromir Subcik wrote:
>> > Ian,
>> > sorry, but your answer is not so polite for technical discusion.
>> > O.K. - in case of payment 4CZK every second I'm going to feel very
>> > rich
>> > ;-)))
>> >
>> > I have battery powered project with serial line (115200Bd) where each
>> > 10ms
>> > is transmitted 16bytes and in this case my example save 19200 cycles
>> > each
>> > second. With 8MHz Xtal (MSP430F413) it represent 2.4ms. Total active
>> > time in
>> > my case is 6ms per second (awerage value depending on action) compare
>> > to
>> > 8.4ms without optimisation it represents +30% battery life. Protocol
>> > is out
>> > of my control ;-(, thus I cannot optimise it.
>> > Yes in this case I feel rich ;-)
>> >
>> > O.T. From my point of view vasting computing time leads to as slow
>> > product
>> > as Microsoft Word is.
>> >
>> > Jarda
>> >
>> > ----- Original Message -----
>> > From: "Ian Okey"
>> > To:
>> > Sent: Wednesday, October 21, 2009 2:22 PM
>> > Subject: Re: [msp430] Re: Preserving CPU Registers
>> >
>> >
>> > It may be 4 times longer but 4 times nearly nothing is still nearly
>> > nothing. If I pay you CZK16 because it is 4 times the CZK4 that I
>> > paid you last week you are hardly going to feel rich despite the 400%
>> > pay rise that I have just given you.
>> >
>> > Having a system that relies on such narrow margins is just not good
>> > Engineering.
>> >
>> > Ian
>> >
>> > (CZK16 = �0.55 = �0.62 ~= Small chocolate bar)
>> >
>> > 2009/10/21 Jaromir Subcik :
>> >> ----- Original Message -----
>> >> From: Ian Okey
>> >> To: m...@yahoogroups.com
>> >> Sent: Wednesday, October 21, 2009 9:44 AM
>> >> Subject: Re: [msp430] Re: Preserving CPU Registers
>> >>
>> >> To be quite honest, if the timing on your interrupt function is so
>> >> tight that you cannot afford the 4 instructions required to push and
>> >> pop these registers then there is an inadequacy in your system
design.
>> >> Your choice of processor or processing clock speed needs to be
>> >> re-considered because, if your processing is really as tight as you
>> >> say, something WILL cause a sufficient delay to one of your
interrupts
>> >> so that the processing fails.
>> >>
>> >> Ian
>> >>
>> >> 2009/10/21 old_cow_yellow :
>> >>> I use IAR KickStart. You can tell the c compiler hands off R4 & R5.
>> >>>
>> >>> --- In m...@yahoogroups.com, "desertrc_tucson" wrote:
>> >>>> Hello all,
>> >>>> I have a C + assembly program that I wrote that needs to get
>> >>>> through an
>> >>>> ISR as quickly as possible. Time is very critical and I am
counting
>> >>>> every ISR clock cycle. The rest of the program is written in C,
and
>> >>>> it
>> >>>> can take its time doing what it needs to do.
>> >>>>
>> >>>> I wrote the ISR in assembly and I need to preserve 2 of the 16
>> >>>> general
>> >>>> purpose CPU registers for the ISR so I can save the push and pop
>> >>>> instructions that would otherwise restore them on the way out.
>> >>>>
>> >>>> I am using CCE Pro tools on a MSP430F2131. Does anyone know of a
>> >>>> way to
>> >>>> tell the compiler to keeps its grubby hands off of two of the CPU
>> >>>> registers? It works right now, but adding things in the C code
>> >>>> causes
>> >>>> the compiler to needlessly gobble up another register or two. Any
>> >>>> info
>> >>>> would be appreciated.
>> >>>>
>> >>>> Thanks -
>> >>>> Dave
>> >> .
>> >>
>> >> The question is if program is time critical by programming method or
>> >> by
>> >> condition. Preventing registers is not only about push/pop - in some
>> >> case
>> >> you can store buffer position directly in register and then for 256
>> >> bytes
>> >> buffer for sirial line receiving you can write ISR like this>
>> >> mov.b &U0RXBUF, buffer(R4)
>> >> inc.b R4
>> >> totally 4 cycles in case R4 is DEDICATED as buffer pointer only
>> >> In other case, if R4 (all registers) is "general purpose" you can
>> >> rewrite
>> >> code as follow:
>> >> push R4
>> >> mov.b &pos,R4 ; for indirect addresing I have to use register
>> >> mov.b &U0RXBUF,buffer(R4)
>> >> inc.b R4
>> >> mov.b R4,&pos
>> >> pop R4
>> >> totally 16 cycles, in other words 4-times (!) longer
>> >>
>> >> Jarda
>> >>
>> >>
>> >> [Non-text portions of this message have been removed]
>> >>
>> >>
>> >
>> >
>> >
>> >
>> >
>> > ------------------------------------
>> >
>> >
>> >
>> >



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

There is no such thing as rocket science ;@}

Al

desertrc_tucson wrote:
>
> Sorry for getting back so late, and thank you for all of your responses. I understand real-time systems very well, I even teach it, and I understand the trade-offs associated with cost vs performance. It is easy to do the analysis for the real-time processing, and it is easy to understand the system requirements as they relate to the interrupt service. This is not rocket science, my friends, and I have taken proper precautions to guarantee that nothing else will get in the way. The solution is simple, and the analysis has been verified. That being said, there appears to be two solutions proposed since the device is already running at 16MHz all the time. 1) Write the whole thing in assembler, or 2) use IAR with the ability to say "hands off" to a register pair. I like option 2, especially since the tools for such a small processor are free.
>
> Thanks for the suggestions,
> Dave
> --- In m...@yahoogroups.com, OneStone wrote:
>> The answer is both polite enough and correct enough. If your system is
>> truly that clock conscious then it has no margin for error, and since
>> you do not understand how to solve these problems yourself, it suggests
>> your experience is such that you cannot possibly consider your system
>> will be free of errors, or will have considered all unexpected
>> circumstances, therefore you would probably do well to heed the advice
>> offered. If it is that critical why not simply write the whole thing in
>> assembler? That way you get to optimise register usage yourself and all
>> the interrupts will be free from register stacking.
>>
>> Al
>>
>> P.S.
>>
>> CZK16 = �0.55 = aus$0.95 = 1 SHOT @ lotto on 31st OCTOBER 2009 odds =
>> 1:8,145,060, 1ST PRIZE = $20,000,000. pot odds are in favour
>>
>> Jaromir Subcik wrote:
>>> Ian,
>>> sorry, but your answer is not so polite for technical discusion.
>>> O.K. - in case of payment 4CZK every second I'm going to feel very rich
>>> ;-)))
>>>
>>> I have battery powered project with serial line (115200Bd) where each 10ms
>>> is transmitted 16bytes and in this case my example save 19200 cycles each
>>> second. With 8MHz Xtal (MSP430F413) it represent 2.4ms. Total active time in
>>> my case is 6ms per second (awerage value depending on action) compare to
>>> 8.4ms without optimisation it represents +30% battery life. Protocol is out
>>> of my control ;-(, thus I cannot optimise it.
>>> Yes in this case I feel rich ;-)
>>>
>>> O.T. From my point of view vasting computing time leads to as slow product
>>> as Microsoft Word is.
>>>
>>> Jarda
>>>
>>> ----- Original Message -----
>>> From: "Ian Okey"
>>> To:
>>> Sent: Wednesday, October 21, 2009 2:22 PM
>>> Subject: Re: [msp430] Re: Preserving CPU Registers
>>>
>>>
>>> It may be 4 times longer but 4 times nearly nothing is still nearly
>>> nothing. If I pay you CZK16 because it is 4 times the CZK4 that I
>>> paid you last week you are hardly going to feel rich despite the 400%
>>> pay rise that I have just given you.
>>>
>>> Having a system that relies on such narrow margins is just not good
>>> Engineering.
>>>
>>> Ian
>>>
>>> (CZK16 = �0.55 = �0.62 ~= Small chocolate bar)
>>>
>>> 2009/10/21 Jaromir Subcik :
>>>> ----- Original Message -----
>>>> From: Ian Okey
>>>> To: m...@yahoogroups.com
>>>> Sent: Wednesday, October 21, 2009 9:44 AM
>>>> Subject: Re: [msp430] Re: Preserving CPU Registers
>>>>
>>>> To be quite honest, if the timing on your interrupt function is so
>>>> tight that you cannot afford the 4 instructions required to push and
>>>> pop these registers then there is an inadequacy in your system design.
>>>> Your choice of processor or processing clock speed needs to be
>>>> re-considered because, if your processing is really as tight as you
>>>> say, something WILL cause a sufficient delay to one of your interrupts
>>>> so that the processing fails.
>>>>
>>>> Ian
>>>>
>>>> 2009/10/21 old_cow_yellow :
>>>>> I use IAR KickStart. You can tell the c compiler hands off R4 & R5.
>>>>>
>>>>> --- In m...@yahoogroups.com, "desertrc_tucson" wrote:
>>>>>> Hello all,
>>>>>> I have a C + assembly program that I wrote that needs to get through an
>>>>>> ISR as quickly as possible. Time is very critical and I am counting
>>>>>> every ISR clock cycle. The rest of the program is written in C, and it
>>>>>> can take its time doing what it needs to do.
>>>>>>
>>>>>> I wrote the ISR in assembly and I need to preserve 2 of the 16 general
>>>>>> purpose CPU registers for the ISR so I can save the push and pop
>>>>>> instructions that would otherwise restore them on the way out.
>>>>>>
>>>>>> I am using CCE Pro tools on a MSP430F2131. Does anyone know of a way to
>>>>>> tell the compiler to keeps its grubby hands off of two of the CPU
>>>>>> registers? It works right now, but adding things in the C code causes
>>>>>> the compiler to needlessly gobble up another register or two. Any info
>>>>>> would be appreciated.
>>>>>>
>>>>>> Thanks -
>>>>>> Dave
>>>> .
>>>>
>>>> The question is if program is time critical by programming method or by
>>>> condition. Preventing registers is not only about push/pop - in some case
>>>> you can store buffer position directly in register and then for 256 bytes
>>>> buffer for sirial line receiving you can write ISR like this>
>>>> mov.b &U0RXBUF, buffer(R4)
>>>> inc.b R4
>>>> totally 4 cycles in case R4 is DEDICATED as buffer pointer only
>>>> In other case, if R4 (all registers) is "general purpose" you can rewrite
>>>> code as follow:
>>>> push R4
>>>> mov.b &pos,R4 ; for indirect addresing I have to use register
>>>> mov.b &U0RXBUF,buffer(R4)
>>>> inc.b R4
>>>> mov.b R4,&pos
>>>> pop R4
>>>> totally 16 cycles, in other words 4-times (!) longer
>>>>
>>>> Jarda
>>>>
>>>>
>>>> [Non-text portions of this message have been removed]
>>>>
>>>>
>>>
>>>
>>>
>>>
>>> ------------------------------------
>>>
>>>
>>>
>>>



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )