Hello,
I develop one university project with MSP430F148 microcontroller.
And I must call one Interrupt Service Routine with the period of 16 us.
I read in the manual that the one instruction take 1 cycle (5ns on the 8MHz) 
and all instructions take the same time for run. In my ISR are about 60 
assembler instructions and this ISR take about 13 us (13us/125ns = 104 
instructions).And now if I add one instruction, the problem with timing is 
occured.The timer is faster than the running of ISR.And the next calling of ISR 
must wait 8,2ms(the full range of timer).
It looks that no all instructions take the same time (1 cycle), probably some 
instructions take 2 or more cycles.It is possible??
I use MSPGCC compiler.
Thank you, Peter




______________________________________________________________________________
Vechny eny jsou krn http://eva.email.cz 

It might also help if you tell us what the task is that you're trying 
to do that quickly.  With all the special function modules built into 
the MSP and the nifty ways of using them, I can't imagine trying to 
get timing that fast without allowing plenty of headroom.  Maybe this 
functionallity can be offloaded into a PLD or other H/W?

CP

--- In msp430@msp4..., <petr.jurcik@e...> wrote:
> Hello,
> I develop one university project with MSP430F148 microcontroller.
> And I must call one Interrupt Service Routine with the period of 16 
us.
> I read in the manual that the one instruction take
1 cycle (5ns 
on the 8MHz) 
> and all instructions take the same time for run.
In my ISR are 
about 60 
> assembler instructions and this ISR take about 13
us (13us/125ns 104 
> instructions).And now if I add one instruction, the problem with 
timing is 
> occured.The timer is faster than the running of
ISR.And the next 
calling of ISR 
> must wait 8,2ms(the full range of timer).
> It looks that no all instructions take the same time (1 cycle), 
probably some 
> instructions take 2 or more cycles.It is
possible??
> I use MSPGCC compiler.
> Thank you, Peter
> 
> 
> 
> 
> 
______________________________________________________________________
________
> Vechny eny jsou krn http://eva.email.cz

Hello, Peter -

I think I have seen one of the TI pdfs that shows
instructions taking anywhere from 1 cycle to 5 cycles,
depending on the addressing modes of the operands and
depending on the instruction, itself. 

Also, I think that interrupt response is 5 cycles, but I am
not absolutely certain. And, it probably takes the same time
to execute an reti. If those numbers are correct, you will
have more than 1 microsecond even if there is no code in the
service routine!

Check the SLAU049 document on TI website for interrupt
service times. Appendix B should have the information about
instruction times.

Jim Wagner
---------------------------
---------------------------
>Next Version of Mac OS X, code named
"Panther."
........... previewed and WWDC 
http://developer.apple.com/wwdc/applelinks.html
----------------
The Think Different Store
http://www.thinkdifferentstore.com/
---------------------------
---------------------------

Download a copy of SLAUE10B or a later version, then study chapter5. It
gives all of the instruction execution times. typically only Register
source/destination instructions take 1 cycle, other instructions take up
to 6 cycles, in the case of MOV	&src,&dst. I ahve attached a copy of
chapter 5  for you.

An interrupt takes 6 cycles, plus you must allow for up to 6 more to
allow the processor to complete the current instruction. RETI takes 5
cycles, so even an NULL  interrupt , with no instructions requires up to
17 cycles, or  2.125usecs. 

ISR's should be as short as feasibly possible. I would place a 60
instruction ISR in the 'capital offense' class, unless it is
absolutely
unavoidable. In my experience (30 years) this is rarely the case. To
compound it you are expecting the ISR to be executed every 16usecs, or
128 clock, this now verges on 'crimes against humanity' ;@}.

When are your foreground routines going to operate? if you have none
then you can delegate the ISR code to the foreground. Of course being a
student you may be forgiven yours since, but only once!!!

The following is a typical ISR. It uses Timer_B.6 to generate an
interrupt every 5 milliseconds. This is used to generate all sorts of
other delays, like key debounce, periodic refresh of registers, power on
timer, to automatically shut down after no use for 2 minutes. The last
instruction is used to run a LED (actually the /OE pin of a buffer
driving 8 LEDs) to reduce current. The routine which handles the TICK
timer then uses a shift register driving the /EN pin to control a 1 in N
modulator. Just 4 instructions in the ISR, the rest in the foreground.

/**************************************************************************

	TIMER B.6 IS USED TO GENERATE THE 5 MSEC TIMEBASE. 
	
**************************************************************************/	

TB6INT:
	BIC	#CCIFG,&CCTLB6
	BIS	#TICK,&SYSTEM_FLAGS
	ADD	#TICK_TIME,&CCRB6
	XOR.B	#LEDPWM,&P4OUT		;DOES LED FLASH
	RETI	

Cheers

Al	
	

petr.jurcik@petr... wrote:
> 
> Hello,
> I develop one university project with MSP430F148 microcontroller.
> And I must call one Interrupt Service Routine with the period of 16 us.
> I read in the manual that the one instruction take 1 cycle (5ns on the
8MHz)
> and all instructions take the same time for run. In my ISR are about 60
> assembler instructions and this ISR take about 13 us (13us/125ns = 104
> instructions).And now if I add one instruction, the problem with timing is
> occured.The timer is faster than the running of ISR.And the next calling of
ISR
> must wait 8,2ms(the full range of timer).
> It looks that no all instructions take the same time (1 cycle), probably
some
> instructions take 2 or more cycles.It is possible??
> I use MSPGCC compiler.
> Thank you, Peter
> 
>
______________________________________________________________________________
> Vechny eny jsou krn http://eva.email.cz
> 
> 
> .
> 
> 
> 
> ">http://docs.yahoo.com/info/terms/

Thank all for help.
I use MSP430 for decoding the data from the Profibus PA bus (it runs 
on 31 kHz and the data must be taked two times per period = 62kHz 16usec).

To Al: I didn't  find the  SLAUE10B document on the TI web side.Can 
you send me it or link on it? Thank you.


Peter

Hi!
What are the foreground routines..??. If the ISR has to do many 
things, what are the techniques to make it short..?. I cant 
understand the example which you have given here. Can you please 
elaborate it more..
Regards,
Khubaib

--- In msp430@msp4..., onestone <onestone@b...> wrote:
> Download a copy of SLAUE10B or a later version,
then study 
chapter5. It
> gives all of the instruction execution times.
typically only 
Register
> source/destination instructions take 1 cycle,
other instructions 
take up
> to 6 cycles, in the case of MOV	&src,&dst.
I ahve attached a 
copy of
> chapter 5  for you.
> 
> An interrupt takes 6 cycles, plus you must allow for up to 6 more to
> allow the processor to complete the current instruction. RETI takes 
5
> cycles, so even an NULL  interrupt , with no
instructions requires 
up to
> 17 cycles, or  2.125usecs. 
> 
> ISR's should be as short as feasibly possible. I would place a 60
> instruction ISR in the 'capital offense' class, unless it is 
absolutely
> unavoidable. In my experience (30 years) this is
rarely the case. To
> compound it you are expecting the ISR to be executed every 16usecs, 
or
> 128 clock, this now verges on 'crimes against
humanity' ;@}.
> 
> When are your foreground routines going to operate? if you have none
> then you can delegate the ISR code to the foreground. Of course 
being a
> student you may be forgiven yours since, but only
once!!!
> 
> The following is a typical ISR. It uses Timer_B.6 to generate an
> interrupt every 5 milliseconds. This is used to generate all sorts 
of
> other delays, like key debounce, periodic refresh
of registers, 
power on
> timer, to automatically shut down after no use for
2 minutes. The 
last
> instruction is used to run a LED (actually the /OE
pin of a buffer
> driving 8 LEDs) to reduce current. The routine which handles the 
TICK
> timer then uses a shift register driving the /EN
pin to control a 1 
in N
> modulator. Just 4 instructions in the ISR, the
rest in the 
foreground.
> 
> /*******************************************************************
*******
> 
> 	TIMER B.6 IS USED TO GENERATE THE 5 MSEC TIMEBASE. 
> 	
> 
**********************************************************************
****/	
> 
> TB6INT:
> 	BIC	#CCIFG,&CCTLB6
> 	BIS	#TICK,&SYSTEM_FLAGS
> 	ADD	#TICK_TIME,&CCRB6
> 	XOR.B	#LEDPWM,&P4OUT		;DOES LED FLASH
> 	RETI	
> 
> Cheers
> 
> Al	
> 	
> 
> petr.jurcik@e... wrote:
> > 
> > Hello,
> > I develop one university project with MSP430F148 microcontroller.
> > And I must call one Interrupt Service Routine with the period of 
16 us.
> > I read in the manual that the one instruction
take 1 cycle 
(5ns on the 8MHz)
> > and all instructions take the same time for
run. In my ISR are 
about 60
> > assembler instructions and this ISR take
about 13 us (13us/125ns 
= 104
> > instructions).And now if I add one
instruction, the problem with 
timing is
> > occured.The timer is faster than the running
of ISR.And the next 
calling of ISR
> > must wait 8,2ms(the full range of timer).
> > It looks that no all instructions take the same time (1 cycle), 
probably some
> > instructions take 2 or more cycles.It is
possible??
> > I use MSPGCC compiler.
> > Thank you, Peter
> > 
> > 
______________________________________________________________________
________
> > Vechny eny jsou krn http://eva.email.cz
> > 
> > 
> > .
> > 
> > 
> > 
> > ">http://docs.yahoo.com/info/terms/
> 
> 

Khubaib wrote:
> 
> Hi!
> What are the foreground routines..??. If the ISR has to do many
> things, what are the techniques to make it short..?. I cant
> understand the example which you have given here. Can you please
> elaborate it more..
> Regards,
> Khubaib
> 
> --- In msp430@msp4..., onestone <onestone@b...> wrote:
> > Download a copy of SLAUE10B or a later version, then study
> chapter5. It
> > gives all of the instruction execution times. typically only
> Register
> > source/destination instructions take 1 cycle, other instructions
> take up
> > to 6 cycles, in the case of MOV      &src,&dst. I ahve
attached a
> copy of
> > chapter 5  for you.
> >
> > An interrupt takes 6 cycles, plus you must allow for up to 6 more to
> > allow the processor to complete the current instruction. RETI takes
> 5
> > cycles, so even an NULL  interrupt , with no instructions requires
> up to
> > 17 cycles, or  2.125usecs.
> >
> > ISR's should be as short as feasibly possible. I would place a 60
> > instruction ISR in the 'capital offense' class, unless it is
> absolutely
> > unavoidable. In my experience (30 years) this is rarely the case. To
> > compound it you are expecting the ISR to be executed every 16usecs,
> or
> > 128 clock, this now verges on 'crimes against humanity' ;@}.
> >
> > When are your foreground routines going to operate? if you have none
> > then you can delegate the ISR code to the foreground. Of course
> being a
> > student you may be forgiven yours since, but only once!!!
> >
> > The following is a typical ISR. It uses Timer_B.6 to generate an
> > interrupt every 5 milliseconds. This is used to generate all sorts
> of
> > other delays, like key debounce, periodic refresh of registers,
> power on
> > timer, to automatically shut down after no use for 2 minutes. The
> last
> > instruction is used to run a LED (actually the /OE pin of a buffer
> > driving 8 LEDs) to reduce current. The routine which handles the
> TICK
> > timer then uses a shift register driving the /EN pin to control a 1
> in N
> > modulator. Just 4 instructions in the ISR, the rest in the
> foreground.
> >
> > /*******************************************************************
> *******
> >
> >       TIMER B.6 IS USED TO GENERATE THE 5 MSEC TIMEBASE.
> >
> >
> **********************************************************************
> ****/
> >
> > TB6INT:
> >       BIC      #CCIFG,&CCTLB6
> >       BIS      #TICK,&SYSTEM_FLAGS
> >       ADD      #TICK_TIME,&CCRB6
> >       XOR.B      #LEDPWM,&P4OUT            ;DOES LED FLASH
> >       RETI
> >

This is (almost) as simple as it gets. The first line clears the
interrupt flag so that the interrupt isn't called again immediately on
exit. The secobnd line sets a single bit flag in a 16 bit register
called [SYSTEM_FLAGS] that is used by the foreground routine to
determine whether or not an event has occurred. The third line adds a
delay period to the current value of CCRB6, producing a time delay to
the next interrupt.
The final line is used to demonstrate actions from within the ISR. In
this case an LED control line is toggled, turning the LED alternately on
and off.

What I haven't done is show the constant and varoiable definitions and a
fore ground routine to handle the flag. Frankly I thought these should
have been self evident. But I'll list them. here is a very tiny progam
fragment.


;************ Define Constants

TICK_TIME	EQU	40000	;GIVES INTERRUPT EVERY 5msecs AT 8MHz

;*********** PORT 4 CONFIGURATION

LEDPWM		EQU	01H

;*********** RAM ALLOCATION

		ORG	RAMSTART

SYSTEM_FLAGS		DS	2	;BITWSIE FLAG REGISTER

;********** FLAG DEFINITIONS

TICK		EQU	0001H		;LSB IS 5MS EVENT FLAG


;*************** PROGRAM
RESET:
	MOV	STACK_TOP,SP		;INITIALISE THE STACK POINTER
	CALL	#INITSYS		;INITIALISE THE SYSTEM
MAINLOOP:
	TST	&SYSTEM_FLAGS		;ARE ANY FLAGS SET
	JZ	MAINLOOP		;NO, SO IDLE HERE
	BIT	#TICK,&SYSTEM_FLAGS	;IS THE 5MSEC EVENT SET
	JZ	TEST_REST		;NO, SO KEEP TESTING
	CALL	#TICK_HANDLER		;YES SO HANDLE THE EVENT
TEST_REST:
	CHECK OTHER FLAGS HERE

	JMP	MAINLOOP
TICK_HANDLER:
	BIC	#TICK,&SYSTEM_FLAGS	;FIRTS CLEAR THE CALLING FLAG
	REST OF CODE HERE
	RET

ETC

Hope this clarifies things for you.

Al

Hi!
thanx for your reply. It s OK with me. But, i ahev a question. In low 
power applications, the MCU is supposed to be in low power (sleep 
mode) always. When an interrupt comes, it should service interrupt 
and then again power downs itself. If it has to check for some flags 
in main routine, there will be very less time (and even no time, if 
there are many interrupt handlers) for the microcontroller to be in 
sleep mode. what do u say about that..?
Another questiuon: I have read tat while servicing pin interupts, if 
another pin (I/O) interrupt comes, it wont be wasted (when RETI is 
executed ,another interupt is requested).. Is it true..?/. What about 
other interupts e.g. timer and ADC interrupts...??. While servicing a 
e.g. timer interrupt (in ISR), if another interrut comes, would that 
be registered or not...??.
Khubaib



--- In msp430@msp4..., onestone <onestone@b...> wrote:
> Khubaib wrote:
> > 
> > Hi!
> > What are the foreground routines..??. If the ISR has to do many
> > things, what are the techniques to make it short..?. I cant
> > understand the example which you have given here. Can you please
> > elaborate it more..
> > Regards,
> > Khubaib
> > 
> > --- In msp430@msp4..., onestone <onestone@b...> wrote:
> > > Download a copy of SLAUE10B or a later version, then study
> > chapter5. It
> > > gives all of the instruction execution times. typically only
> > Register
> > > source/destination instructions take 1 cycle, other instructions
> > take up
> > > to 6 cycles, in the case of MOV      &src,&dst. I ahve
attached 
a
> > copy of
> > > chapter 5  for you.
> > >
> > > An interrupt takes 6 cycles, plus you must allow for up to 6 
more to
> > > allow the processor to complete the
current instruction. RETI 
takes
> > 5
> > > cycles, so even an NULL  interrupt , with no instructions 
requires
> > up to
> > > 17 cycles, or  2.125usecs.
> > >
> > > ISR's should be as short as feasibly possible. I would place
a 
60
> > > instruction ISR in the 'capital
offense' class, unless it is
> > absolutely
> > > unavoidable. In my experience (30 years) this is rarely the 
case. To
> > > compound it you are expecting the ISR to
be executed every 
16usecs,
> > or
> > > 128 clock, this now verges on 'crimes against humanity'
;@}.
> > >
> > > When are your foreground routines going to operate? if you have 
none
> > > then you can delegate the ISR code to
the foreground. Of course
> > being a
> > > student you may be forgiven yours since, but only once!!!
> > >
> > > The following is a typical ISR. It uses Timer_B.6 to generate an
> > > interrupt every 5 milliseconds. This is used to generate all 
sorts
> > of
> > > other delays, like key debounce, periodic refresh of registers,
> > power on
> > > timer, to automatically shut down after no use for 2 minutes. 
The
> > last
> > > instruction is used to run a LED (actually the /OE pin of a 
buffer
> > > driving 8 LEDs) to reduce current. The
routine which handles the
> > TICK
> > > timer then uses a shift register driving the /EN pin to control 
a 1
> > in N
> > > modulator. Just 4 instructions in the ISR, the rest in the
> > foreground.
> > >
> > 
> /*******************************************************************
> > *******
> > >
> > >       TIMER B.6 IS USED TO GENERATE THE 5 MSEC TIMEBASE.
> > >
> > >
> > 
**********************************************************************
> > ****/
> > >
> > > TB6INT:
> > >       BIC      #CCIFG,&CCTLB6
> > >       BIS      #TICK,&SYSTEM_FLAGS
> > >       ADD      #TICK_TIME,&CCRB6
> > >       XOR.B      #LEDPWM,&P4OUT            ;DOES LED FLASH
> > >       RETI
> > >
> 
> This is (almost) as simple as it gets. The first line clears the
> interrupt flag so that the interrupt isn't called again immediately 
on
> exit. The secobnd line sets a single bit flag in a
16 bit register
> called [SYSTEM_FLAGS] that is used by the foreground routine to
> determine whether or not an event has occurred. The third line adds 
a
> delay period to the current value of CCRB6,
producing a time delay 
to
> the next interrupt.
> The final line is used to demonstrate actions from within the ISR. 
In
> this case an LED control line is toggled, turning
the LED 
alternately on
> and off.
> 
> What I haven't done is show the constant and varoiable definitions 
and a
> fore ground routine to handle the flag. Frankly I
thought these 
should
> have been self evident. But I'll list them.
here is a very tiny 
progam
> fragment.
> 
> 
> ;************ Define Constants
> 
> TICK_TIME	EQU	40000	;GIVES INTERRUPT EVERY 5msecs AT 8MHz
> 
> ;*********** PORT 4 CONFIGURATION
> 
> LEDPWM		EQU	01H
> 
> ;*********** RAM ALLOCATION
> 
> 		ORG	RAMSTART
> 
> SYSTEM_FLAGS		DS	2	;BITWSIE FLAG REGISTER
> 
> ;********** FLAG DEFINITIONS
> 
> TICK		EQU	0001H		;LSB IS 5MS EVENT FLAG
> 
> 
> ;*************** PROGRAM
> RESET:
> 	MOV	STACK_TOP,SP		;INITIALISE THE STACK POINTER
> 	CALL	#INITSYS		;INITIALISE THE SYSTEM
> MAINLOOP:
> 	TST	&SYSTEM_FLAGS		;ARE ANY FLAGS SET
> 	JZ	MAINLOOP		;NO, SO IDLE HERE
> 	BIT	#TICK,&SYSTEM_FLAGS	;IS THE 5MSEC EVENT SET
> 	JZ	TEST_REST		;NO, SO KEEP TESTING
> 	CALL	#TICK_HANDLER		;YES SO HANDLE THE EVENT
> TEST_REST:
> 	CHECK OTHER FLAGS HERE
> 
> 	JMP	MAINLOOP
> TICK_HANDLER:
> 	BIC	#TICK,&SYSTEM_FLAGS	;FIRTS CLEAR THE CALLING FLAG
> 	REST OF CODE HERE
> 	RET
> 
> ETC
> 
> Hope this clarifies things for you.
> 
> Al

Khubaib wrote:
> 
> Hi!
> thanx for your reply. It s OK with me. But, i ahev a question. In low
> power applications, the MCU is supposed to be in low power (sleep
> mode) always. When an interrupt comes, it should service interrupt
> and then again power downs itself. If it has to check for some flags
> in main routine, there will be very less time (and even no time, if
> there are many interrupt handlers) for the microcontroller to be in
> sleep mode. what do u say about that..?

If you want low power mode and lots of asynchronous interrupts you need
to rethink your design concepts. In a system such as this I would use
the waking interrupt to perform an action, check if any other interrupts
are pending, if not I would go back to sleep, or else I would service
them all. First though I would examine the design thoroughly to see if I
could improve on it. 

> Another questiuon: I have read tat while servicing
pin interupts, if
> another pin (I/O) interrupt comes, it wont be wasted (when RETI is
> executed ,another interupt is requested).. Is it true..?/. What about
> other interupts e.g. timer and ADC interrupts...??. While servicing a
> e.g. timer interrupt (in ISR), if another interrut comes, would that
> be registered or not...??.
> Khubaib

A lot of questions! Here is very briefly how interrupts work.

When an ISR is being serviced interrupts are disabled, by default. That
measn that the ISR currently active WILL NOT BE exited to service a new
interrupt. You can enable this, but it is not something that novices, or
even more experienced programmers should take on if it can be avoided,
and, most times, good design will allow you to avoid it. However the
good news is that interrupt events that occur while interrupts are
disabled are not lost. The interrupt flag for that event is still set,
and, once the current interrupt completes, and after interrupts are
automatically re-enabled any interrupts that occurred during the ISR
will be serviced.

The plus side is that you don't lose events, and that, quite often, the
slight delay in servicing the interrupt is not important. The trick is
to structure your design. For example a capture event will capture the
actual time at which the event occured, even if another ISR is active.
This is because the capture event is a hardware event. However your
software may not get to service the capture until some period after it
occured. Remember this. COmpare events may be set up to automatically
control their associated output pin, and, since these are also hardware
events, no time is lost, unless and actual ISR has to be called. Even
then the pulses and other timing events generated can be extremely
accurate provided the ISR is less than the tim9ing intervals required.

The A/D can work the same, although lowest power modes don't work with
many peripherals as power and CPU are turned off.

The problem arises when your ISR's are too long, and other short timing
periods are needed, one ISR will hog the processor, and the second
cannot be serviced, if another event occurs on the interrupt that is
still pending the firt one will be lost. This is why the golden rule is
keep interrupts very short. 

This is not always possible. I have a situation right now with some
scanning code. one event occurs every 12usecs, it requires 13 to
process,and a depedant event then occurs 8usecs later. I cannot slip in
and out of the ISR, timing is critical, and there are 8 of these events
sequentially.. The problem is it is a dynamic system running motors,
other sensors, keyboard LCD etc. This single interrupt breaks all my
rules, in that it is nearly 250usecs in total execution time, and it is
unavoidable without goign to external hardware. but why do that when I
can do it in the micro, I just have to be creative. 

In sleep modes if you find that you have so many interrupts occuring
that you are mostly servicing them, you should perhaps not use sleep
mode, but use another technique to save on battery power, or re-think
your design. For example, the A/D is a relatively heavy user of current.
Do you need to keep it running? or can you live with periodic
measurements triggered from a timer

As an example I currently have a system that has 4 pwm sensor inputs at
1200Hz, 3 PWM sensor inputs at 1000hz, 4 temperature sensors, 3 gyros, 1
pressure sensor, 1 humidity sensor 1 UV sensor, 1 white light sensor 1
IR sensor, 1 GPS with active antenna, battery monitor, 8Mbyte of memory,
an RF transceiver and power supplies. It runs from an Li-poly cell, it
must capture all signals, monitor the RF receiver, and keep real time
GPS locations, it cannot utilise low power modes most of the time,
because it must also process 12 digital filters, yet its mean current
consumption is under 5mA. That meets my power budget, hence the MSP430
is used in a typical DSP role, because no DSP I could find met the power
specs. In fact if I off loaded the processing to an external host I
could reduce mean power to under 1mA. Because size was critical, as wa
weight, my battery was severely limited too, yet I had to guarantee 72
hours of continuous operation. I can get away with a 500mAh battery and
have some room to spare. Another design uses sleep mode heavily to get
several years running from a 180mAh battery.

The point is how you handle low power modes depends upon the absolute
needs of the design. If you don't need to compromise performance, or
sensor sample rates and don't have size restrictions (my system above is
smaller than a matchbox, incluidng the battery) don't compromise things
with a badly spec'd battery.

Al