Yahoo Groups archive

Lpc2000

Index last updated: 2026-04-28 23:31 UTC

Thread

Interrupt function declaration

Interrupt function declaration

2006-05-10 by Andy

Hi all,

Just wondering if anyone can clear something up for me.
I'm using the Vectored Interrupt Controller as decribed below, just wondering what function delaration extention I should use and what the difference is?

Thanks,
Andy

// Vectored Interrupt - Using Timer 0
VICVectAddr0 = (tDWord)Interrupt_Function;
VICVectCntl0 = 0x20 | 4;
VICIntEnable |= 1<<4;

void Interrupt_Function (void) __attribute__((interrupt));
void Interrupt_Function (void) __attribute__((interrupt ("IRQ")));
void Interrupt_Function (void) __attribute__((interrupt ("FIQ")));
void Interrupt_Function (void) __irq; 


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

Re: [lpc2000] Interrupt function declaration

2006-05-10 by Tom Walsh

Andy wrote:

>Hi all,
>
>Just wondering if anyone can clear something up for me.
>I'm using the Vectored Interrupt Controller as decribed below, just wondering what function delaration extention I should use and what the difference is?
>
>Thanks,
>Andy
>
>// Vectored Interrupt - Using Timer 0
>VICVectAddr0 = (tDWord)Interrupt_Function;
>VICVectCntl0 = 0x20 | 4;
>VICIntEnable |= 1<<4;
>
>void Interrupt_Function (void) __attribute__((interrupt));
>void Interrupt_Function (void) __attribute__((interrupt ("IRQ")));
>void Interrupt_Function (void) __attribute__((interrupt ("FIQ")));
>  
>
Both "IRQ" and "FIQ" should switch register contexts and save certain 
registers (FIQ stacks nothing).  "interrupt" is more a general "save 
what you use here and restore when exiting".

Look at the ASM code, is the attribute doing what you need it to do?  
You need to be carefull if you are doing nested interrupts to ensure 
that you don't suffer a re-entry into the current context (IRQ) and 
forget to save things.


TomW

-- 
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net, http://cyberiansoftware.com
"Windows? No thanks, I have work to do..."
----------------------------------------------------

Re: [lpc2000] Interrupt function declaration

2006-05-10 by Andy

Thanks Tom,

I'm still quite new to embedded systems generally so please bear with me.
I'm running a task scheduler based on a 1ms tick using Timer0, so need one 
interrupt for this.  In addition I require an interrupt from EINT3 due to an 
external ethernet chip which requires attention when a message is recieved.
The timer0 int is time critical and must happen on time, the external 
interrupt can wait a bit if need be.  Currently I have the follow setup, do 
you think this would be ok?

VICVectAddr0 = (tDWord)Sch_Tick_Function;
VICVectCntl0 = 0x20 | 4;
VICIntEnable |= (1 << 4);

VICVectAddr1 = (tDWord)W3100A_Int_Service;
VICVectCntl1 = 0x20 | 17;
VICIntEnable |= (1 << 17);

and using the __attribute__((interrupt)); extention for the task 
declarations.
The program sits in a while(1) loop until either of the interrupts occur.
Also, so whats the __irq; extention for?

Thanks again,
Andy
Show quoted textHide quoted text
> Andy wrote:
>
>>Hi all,
>>
>>Just wondering if anyone can clear something up for me.
>>I'm using the Vectored Interrupt Controller as decribed below, just 
>>wondering what function delaration extention I should use and what the 
>>difference is?
>>
>>Thanks,
>>Andy
>>
>>// Vectored Interrupt - Using Timer 0
>>VICVectAddr0 = (tDWord)Interrupt_Function;
>>VICVectCntl0 = 0x20 | 4;
>>VICIntEnable |= 1<<4;
>>
>>void Interrupt_Function (void) __attribute__((interrupt));
>>void Interrupt_Function (void) __attribute__((interrupt ("IRQ")));
>>void Interrupt_Function (void) __attribute__((interrupt ("FIQ")));
>>
>>
> Both "IRQ" and "FIQ" should switch register contexts and save certain
> registers (FIQ stacks nothing).  "interrupt" is more a general "save
> what you use here and restore when exiting".
>
> Look at the ASM code, is the attribute doing what you need it to do?
> You need to be carefull if you are doing nested interrupts to ensure
> that you don't suffer a re-entry into the current context (IRQ) and
> forget to save things.
>
>
> TomW
>
> -- 
> Tom Walsh - WN3L - Embedded Systems Consultant
> http://openhardware.net, http://cyberiansoftware.com
> "Windows? No thanks, I have work to do..."
> ----------------------------------------------------
>
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
>
>

Re: Interrupt function declaration

2006-05-10 by brendanmurphy37

My advice would be to avoid using extensions at all and code an 
assembler prolog and epilog. 

See http://groups.yahoo.com/group/lpc2000/message/14623 for an 
example. 

I haven't verified this particular one myself, but it looks OK.

This approach has the advantage:

- doesn't rely on compiler extensions, which have a habit of being 
bug-prone (see messages posted around the same time)

- you know exactly what's going on, and aren't relying on possibly 
poorly documented compiler features.

- you can control whether you allow nested interrupts or not

Brendan


--- In lpc2000@...m, "Andy" <me@...> wrote:
>
> Hi all,
> 
> Just wondering if anyone can clear something up for me.
> I'm using the Vectored Interrupt Controller as decribed below, 
just wondering what function delaration extention I should use and 
what the difference is?
Show quoted textHide quoted text
> 
> Thanks,
> Andy
> 
> // Vectored Interrupt - Using Timer 0
> VICVectAddr0 = (tDWord)Interrupt_Function;
> VICVectCntl0 = 0x20 | 4;
> VICIntEnable |= 1<<4;
> 
> void Interrupt_Function (void) __attribute__((interrupt));
> void Interrupt_Function (void) __attribute__((interrupt ("IRQ")));
> void Interrupt_Function (void) __attribute__((interrupt ("FIQ")));
> void Interrupt_Function (void) __irq; 
> 
> 
> [Non-text portions of this message have been removed]
>

Re: Interrupt function declaration

2006-05-10 by ghetto_shinobi

HI!

Hi Andy i got couple off topic question.Hope u can help me out.
I see that u are using one of those hardware Tcp stack from Wiznet.Im
thinking about getting one myself.Is it hard to get this thing working
cause i dont have much time to spend on it and was also thinkin about
getting web server which can communicate with MCU thru RS232.
Ive heard they come with I2C bus and parrarel bus.How did u hook up
yours to LPC?
Does Winzet provides some sample code or headers etc for ARM?

Thanks in advance.

Re: [lpc2000] Interrupt function declaration

2006-05-10 by Robert Adsett

At 09:05 PM 5/10/2006 +0100, Andy wrote:
>I'm still quite new to embedded systems generally so please bear with me.
>I'm running a task scheduler based on a 1ms tick using Timer0, so need one
>interrupt for this.  In addition I require an interrupt from EINT3 due to an
>external ethernet chip which requires attention when a message is recieved.
>The timer0 int is time critical and must happen on time, the external
>interrupt can wait a bit if need be.

Just a question that might help.  Why is the timer interrupt that 
critical?  Have you something scheduled that must happen at 1 ms 
intervals?  If so how close to the ms does it need to be?

Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,   be 
they legal, genetic, or physical.  If you don't believe me, try to chew a 
radio signal. "  -- Kelvin Throop, III
http://www.aeolusdevelopment.com/

Re: [lpc2000] Interrupt function declaration

2006-05-10 by Tom Walsh

Andy wrote:

>Thanks Tom,
>
>I'm still quite new to embedded systems generally so please bear with me.
>I'm running a task scheduler based on a 1ms tick using Timer0, so need one 
>interrupt for this.  In addition I require an interrupt from EINT3 due to an 
>external ethernet chip which requires attention when a message is recieved.
>The timer0 int is time critical and must happen on time, the external 
>interrupt can wait a bit if need be.  Currently I have the follow setup, do 
>you think this would be ok?
>
>  
>
Well, in that case, you want to run nested interrupts.  I don't use that 
mode, perhaps some others can comment on implementing nesting?

 From what I understand, you have to use some assembly language stubs 
to: save out some registers onto stack, ACK the current interrupt being 
serviced to allow others to pre-empt your current routine if needed, and 
then call your actual code for the current interrupt service.  Return 
from the call, restore the registers and simply return.


>VICVectAddr0 = (tDWord)Sch_Tick_Function;
>VICVectCntl0 = 0x20 | 4;
>VICIntEnable |= (1 << 4);
>
>VICVectAddr1 = (tDWord)W3100A_Int_Service;
>VICVectCntl1 = 0x20 | 17;
>VICIntEnable |= (1 << 17);
>
>  
>
What that will do is to allow preference for the Sch_Tick_Function over 
the W3100A_Int_Service should they be asserted simultaneously.  It does 
not allow the timer interrrupt to interrupt the execution of the W3100A 
service, if the timer fires during the ISR for the W3100A, it will be 
heldoff until you write to the VicVectAddr (VICVectAddr = 0;).  From the 
LPC2106 manual:

"Following the completion of the desired interrupt service routine, 
clearing of the interrupt flag on the peripheral level will propagate to 
corresponding bits in VIC registers (VICRawIntr, VICFIQStatus and 
VICIRQStatus). Also, before the next interrupt can be serviced, it is 
necessary that write is performed into the VICVectAddr register before 
the return from interrupt is executed. Thiswrite will clear the 
respective interrupt flag in the internal interrupt priority hardware."

Nesting handled differently.  As I mentioned, I do not have a need to 
nest.  Essentailly you have to simultaneously turn on the Interrupt an 
switch your context to Supv mode (this would be done by setting value in 
the CPSR register).  By switching to Supv Mode, you use the Supv stack 
for your ISR.  When a higher level interrupt pre-empts an on-going ISR, 
it would get the IRQ context stack, leaving your stack frame intact.

Then that higher level service switches to the Supv context.  So, your 
first job in the Supv context is to save registers(!) as you may have 
pre-empted  a lower ISR task.

I am not sure of the return process...

>and using the __attribute__((interrupt)); extention for the task 
>declarations.
>  
>
That attribute tells gcc that any register it uses in the service must 
be preserved.  gcc is two pass, maybe three pass, compiler, it will 
build the code, then when it is time to emit the opcodes, it will 
produce a prolog / epilog to save / restore registers used.

>The program sits in a while(1) loop until either of the interrupts occur.
>Also, so whats the __irq; extention for?
>  
>

Don't know, gcc-4.01 considers "__irq" in place of "__attribute__ 
((interrupt))" as a syntax error.  I would suspect that you are using a 
modified gcc compiler, or some other compiler?  Actually, I see no 
effect when using ((interrupt)), ((interrupt("IRQ"))), or 
((interrupt("FIQ"))) upon the code generated.  IIRC, I think that I read 
somewhere that those attributes are ignored?


TomW

-- 
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net, http://cyberiansoftware.com
"Windows? No thanks, I have work to do..."
----------------------------------------------------

GCC, uCOS-II, nested interrupts

2006-05-11 by David Hawkins

Hi all,

I just uploaded a project I tinkered on last year for
the Philips ARM 2005 contest held by Circuit Cellar. It
has a PDF document inside describing the code, along
with the code and a port of the uCOS-II RTOS that
uses nested interrupts. The document and code show
how to use nested interrupts without having to use
uCOS-II as well.

Please don't flame me for the poor Makefile style and
repeated code, I was going for simplicity :)

I hope this document and code will be a useful place
to point beginners who keep asking the same standard
questions regarding configuring interrupts etc.

Send me comments, I'll try and incorporate any fixes
into the document. Unfortunately my real job has kept
me tinkering with ARMs, so I haven't got time to work
on documenting more.

Happy reading !

Cheers
Dave Hawkins.

Re: [lpc2000] Re: Interrupt function declaration

2006-05-11 by David Hawkins

brendanmurphy37 wrote:
> My advice would be to avoid using extensions at all and code an 
> assembler prolog and epilog. 
> 
> See http://groups.yahoo.com/group/lpc2000/message/14623 for an 
> example. 
> 
> I haven't verified this particular one myself, but it looks OK.
> 

Hiya,

I just uploaded the project that that code was extracted from
into the files section; gcc_and_ucosii.zip.

The interrupt and nesting stuff is described from the
stand-alone case and for use with the uCOS-II RTOS.

Cheers
Dave

Re: [lpc2000] GCC, uCOS-II, nested interrupts

2006-05-11 by David Hawkins

> I just uploaded a project I tinkered on last year for
> the Philips ARM 2005 contest held by Circuit Cellar. It
> has a PDF document inside describing the code, along
> with the code and a port of the uCOS-II RTOS that
> uses nested interrupts. The document and code show
> how to use nested interrupts without having to use
> uCOS-II as well.
> 
> Please don't flame me for the poor Makefile style and
> repeated code, I was going for simplicity :)
> 
> I hope this document and code will be a useful place
> to point beginners who keep asking the same standard
> questions regarding configuring interrupts etc.
> 
> Send me comments, I'll try and incorporate any fixes
> into the document. Unfortunately my real job has kept
> me tinkering with ARMs, so I haven't got time to work
> on documenting more.
> 
> Happy reading !

http://www.ovro.caltech.edu/~dwh/ucos/
http://www.ovro.caltech.edu/~dwh/ucos/project_AR1803.pdf
http://www.ovro.caltech.edu/~dwh/ucos/gcc_and_ucosii.zip

Here's an alternative link with the PDF broken out of the
zip file, so people can read it and decide if they
want to look at the source further.

Dave

Re: GCC, uCOS-II, nested interrupts

2006-05-11 by roger_lynx

Dave, kudos for the AR1803.pdf! 
Very nicely done.

Roger

--- In lpc2000@yahoogroups.com, David Hawkins <dwh@...> wrote:
Show quoted textHide quoted text
>
> 
> > I just uploaded a project I tinkered on last year for
> > the Philips ARM 2005 contest held by Circuit Cellar. It
> > has a PDF document inside describing the code, along
> > with the code and a port of the uCOS-II RTOS that
> > uses nested interrupts. The document and code show
> > how to use nested interrupts without having to use
> > uCOS-II as well.
> > 
> > Please don't flame me for the poor Makefile style and
> > repeated code, I was going for simplicity :)
> > 
> > I hope this document and code will be a useful place
> > to point beginners who keep asking the same standard
> > questions regarding configuring interrupts etc.
> > 
> > Send me comments, I'll try and incorporate any fixes
> > into the document. Unfortunately my real job has kept
> > me tinkering with ARMs, so I haven't got time to work
> > on documenting more.
> > 
> > Happy reading !
> 
> http://www.ovro.caltech.edu/~dwh/ucos/
> http://www.ovro.caltech.edu/~dwh/ucos/project_AR1803.pdf
> http://www.ovro.caltech.edu/~dwh/ucos/gcc_and_ucosii.zip
> 
> Here's an alternative link with the PDF broken out of the
> zip file, so people can read it and decide if they
> want to look at the source further.
> 
> Dave
>

Re: GCC, uCOS-II, nested interrupts

2006-05-11 by brendanmurphy37

I'll second that. Very highly recommended to anyone using these 
parts: clear, simple document with easy-to-understand text and good 
examples. 

Just the kind of stuff you need to know when coming to these parts 
for the first time, and you otherwise have to dig out from multiple 
sources or find out for yourself.

I haven't read the uCOS part: the rest is relevant to all systems. 

Maybe Philips could look at extracting the non-uCOS stuff and 
putting it on their Web site (or linking to it)?

Well done, again, David!

Brendan

--- In lpc2000@yahoogroups.com, "roger_lynx" <roger_lynx@...> wrote:
Show quoted textHide quoted text
>
> Dave, kudos for the AR1803.pdf! 
> Very nicely done.
> 
> Roger
> 
> --- In lpc2000@yahoogroups.com, David Hawkins <dwh@> wrote:
> >
> > 
> > > I just uploaded a project I tinkered on last year for
> > > the Philips ARM 2005 contest held by Circuit Cellar. It
> > > has a PDF document inside describing the code, along
> > > with the code and a port of the uCOS-II RTOS that
> > > uses nested interrupts. The document and code show
> > > how to use nested interrupts without having to use
> > > uCOS-II as well.
> > >

Re: [lpc2000] Interrupt function declaration

2006-05-11 by Andy

Robert,
I am running a shared clock network over ethernet, so to reduce task jitter 
on the slave nodes the timer0 interrupt needs to be as close as possible.

Ghetto,
I am currently using the indirect mode parallel bus (WR, RD, CS, INT, 2 addr 
lines and 8 data lines) which is fine but requires a lot more IO Pins than 
the I2C.  Previously I have used the I2C interface which is very easy to 
setup and use, however for my purposes was way too slow.  Wiznet do supply 
sample code which is very helpful and I belive RealOS has some code for it 
too, tho I haven't seen it.

Tom,
Thanks once again.  I think my best bet will be to make the Ext Int 
Fuunction and Timer0 int function as short as possible.  The timings of the 
network should mean that no clashes occur (send out tick message, recieve 
rply message).  I would prefer not to have to mess around with nested 
interrupt where possible.

Cheers,
Andy
Show quoted textHide quoted text
----- Original Message ----- 
From: "Tom Walsh" <tom@...>
To: <lpc2000@yahoogroups.com>
Sent: Thursday, May 11, 2006 12:10 AM
Subject: Re: [lpc2000] Interrupt function declaration


Andy wrote:

>Thanks Tom,
>
>I'm still quite new to embedded systems generally so please bear with me.
>I'm running a task scheduler based on a 1ms tick using Timer0, so need one
>interrupt for this.  In addition I require an interrupt from EINT3 due to 
>an
>external ethernet chip which requires attention when a message is recieved.
>The timer0 int is time critical and must happen on time, the external
>interrupt can wait a bit if need be.  Currently I have the follow setup, do
>you think this would be ok?
>
>
>
Well, in that case, you want to run nested interrupts.  I don't use that
mode, perhaps some others can comment on implementing nesting?

 From what I understand, you have to use some assembly language stubs
to: save out some registers onto stack, ACK the current interrupt being
serviced to allow others to pre-empt your current routine if needed, and
then call your actual code for the current interrupt service.  Return
from the call, restore the registers and simply return.


>VICVectAddr0 = (tDWord)Sch_Tick_Function;
>VICVectCntl0 = 0x20 | 4;
>VICIntEnable |= (1 << 4);
>
>VICVectAddr1 = (tDWord)W3100A_Int_Service;
>VICVectCntl1 = 0x20 | 17;
>VICIntEnable |= (1 << 17);
>
>
>
What that will do is to allow preference for the Sch_Tick_Function over
the W3100A_Int_Service should they be asserted simultaneously.  It does
not allow the timer interrrupt to interrupt the execution of the W3100A
service, if the timer fires during the ISR for the W3100A, it will be
heldoff until you write to the VicVectAddr (VICVectAddr = 0;).  From the
LPC2106 manual:

"Following the completion of the desired interrupt service routine,
clearing of the interrupt flag on the peripheral level will propagate to
corresponding bits in VIC registers (VICRawIntr, VICFIQStatus and
VICIRQStatus). Also, before the next interrupt can be serviced, it is
necessary that write is performed into the VICVectAddr register before
the return from interrupt is executed. Thiswrite will clear the
respective interrupt flag in the internal interrupt priority hardware."

Nesting handled differently.  As I mentioned, I do not have a need to
nest.  Essentailly you have to simultaneously turn on the Interrupt an
switch your context to Supv mode (this would be done by setting value in
the CPSR register).  By switching to Supv Mode, you use the Supv stack
for your ISR.  When a higher level interrupt pre-empts an on-going ISR,
it would get the IRQ context stack, leaving your stack frame intact.

Then that higher level service switches to the Supv context.  So, your
first job in the Supv context is to save registers(!) as you may have
pre-empted  a lower ISR task.

I am not sure of the return process...

>and using the __attribute__((interrupt)); extention for the task
>declarations.
>
>
That attribute tells gcc that any register it uses in the service must
be preserved.  gcc is two pass, maybe three pass, compiler, it will
build the code, then when it is time to emit the opcodes, it will
produce a prolog / epilog to save / restore registers used.

>The program sits in a while(1) loop until either of the interrupts occur.
>Also, so whats the __irq; extention for?
>
>

Don't know, gcc-4.01 considers "__irq" in place of "__attribute__
((interrupt))" as a syntax error.  I would suspect that you are using a
modified gcc compiler, or some other compiler?  Actually, I see no
effect when using ((interrupt)), ((interrupt("IRQ"))), or
((interrupt("FIQ"))) upon the code generated.  IIRC, I think that I read
somewhere that those attributes are ignored?


TomW

-- 
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net, http://cyberiansoftware.com
"Windows? No thanks, I have work to do..."
----------------------------------------------------






Yahoo! Groups Links

Re: [lpc2000] Re: GCC, uCOS-II, nested interrupts

2006-05-11 by Andy

I've just started reading and getting to grips with a few of the concepts.
Thanks David a great help.

Andy
Show quoted textHide quoted text
----- Original Message ----- 
From: "brendanmurphy37" <brendanmurphy37@...>
To: <lpc2000@yahoogroups.com>
Sent: Thursday, May 11, 2006 8:18 AM
Subject: [lpc2000] Re: GCC, uCOS-II, nested interrupts



I'll second that. Very highly recommended to anyone using these 
parts: clear, simple document with easy-to-understand text and good 
examples. 

Just the kind of stuff you need to know when coming to these parts 
for the first time, and you otherwise have to dig out from multiple 
sources or find out for yourself.

I haven't read the uCOS part: the rest is relevant to all systems. 

Maybe Philips could look at extracting the non-uCOS stuff and 
putting it on their Web site (or linking to it)?

Well done, again, David!

Brendan

--- In lpc2000@yahoogroups.com, "roger_lynx" <roger_lynx@...> wrote:
>
> Dave, kudos for the AR1803.pdf! 
> Very nicely done.
> 
> Roger
> 
> --- In lpc2000@yahoogroups.com, David Hawkins <dwh@> wrote:
> >
> > 
> > > I just uploaded a project I tinkered on last year for
> > > the Philips ARM 2005 contest held by Circuit Cellar. It
> > > has a PDF document inside describing the code, along
> > > with the code and a port of the uCOS-II RTOS that
> > > uses nested interrupts. The document and code show
> > > how to use nested interrupts without having to use
> > > uCOS-II as well.
> > > 







 
Yahoo! Groups Links

Re: [lpc2000] Interrupt function declaration

2006-05-12 by Robert Adsett

At 09:27 AM 5/11/06 +0100, Andy wrote:
>Robert,
>I am running a shared clock network over ethernet, so to reduce task jitter
>on the slave nodes the timer0 interrupt needs to be as close as possible.

Do you need to have your message sent as close to 1mS as possible?  If so 
I'm surprised that ethernet uncertainties don't swamp any jitter from the 
interrupt.  Never mind the additional uncertainties introduced by whatever 
higher level protocol you are running on ethernet (probably TCP/IP consider 
you are using WIZnet?)

Or do you just need to know the time that you sent the packet as accurately 
as possible.  If that's the case (and I think it should be with a good 
clock synchronization algorithm) then there are other approaches that will 
give you greater accuracy without the interrupt overhead. With the timers 
on the LPC series it is quite easy to setup a polled timer that will give 
you time with an precision of a few tenth's of a uS that will not exhibit 
any significant wrap around oddities as long as you poll it every few 
minutes.  Accuracy is actually limited in most cases by the crystal. Chalk 
one up for 32bit timers, one of the features I really like on this micro.

See

http://www.aeolusdevelopment.com/AppNotes/LPC210X/an-timerperformance.pdf

It's an app note I did on taking some performance measurements on such a clock.


Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,   be 
they legal, genetic, or physical.  If you don't believe me, try to chew a 
radio signal. "  -- Kelvin Throop, III
http://www.aeolusdevelopment.com/

Re: [lpc2000] GCC, uCOS-II, nested interrupts

2006-05-12 by Mukund Deshmukh

> > I just uploaded a project I tinkered on last year for
> > the Philips ARM 2005 contest held by Circuit Cellar. It
> > has a PDF document inside describing the code, along
> > with the code and a port of the uCOS-II RTOS that
> > uses nested interrupts. The document and code show
> > how to use nested interrupts without having to use
> > uCOS-II as well.
> >
> http://www.ovro.caltech.edu/~dwh/ucos/project_AR1803.pdf

Excellent Document !!
I am not a C expert but use C for Embedded Application.
Although I  am using ld, make and asm file for LPC, but never understood
what's inside these files.
Your document has helped me to understand a little bit of it.
Thanks again!!

BTW, are there any more links, documentation, for ld, make and asm files for
GCC compiler, and suitable for a layman like me.


Best Regards,

Mukund Deshmukh.
Beta Computronics Pvt Ltd
10/1, IT Park, Parsodi,
Nagpur-440022
Cell - 9422113746

RE: [lpc2000] Interrupt function declaration

2006-05-12 by Andrew Berney

Without a slightly more detailed description of what you're trying to
acheive via time synchronisation it's hard to give any advice, however I've
done quite a lot of work in the past in high accuracy embedded network time
sychronisation techniques in association with a number of switch
manufacturers: RuggedCom etc - although admittedly on a much more powerful
ARM 9 core.

If you're actually wanting to get a time synch across an ethernet network
down to better than 1ms then you'll definately need to bypass the ethernet
stack and deal with your ethernet controller directly. To be honest 1ms is
pretty much as low as you'll get purely in software and even then you'll
have to implement a fairly intensive version of NTP. There are papers out
there for companies (Siemens and ABB for example) that have done significant
research in this area as they helped define the relatively new IEC61850
standards for use in electricity substations - where real time control can
be required down to 10us.

If you can give us a little more info on what you're trying to achieve I may
well be able to point you in the direction of some helpful reading.

Andy
Show quoted textHide quoted text
-----Original Message-----
From: lpc2000@yahoogroups.com [mailto:lpc2000@yahoogroups.com]On Behalf
Of Robert Adsett
Sent: 12 May 2006 05:21
To: lpc2000@yahoogroups.com
Subject: Re: [lpc2000] Interrupt function declaration


At 09:27 AM 5/11/06 +0100, Andy wrote:
>Robert,
>I am running a shared clock network over ethernet, so to reduce task jitter
>on the slave nodes the timer0 interrupt needs to be as close as possible.

Do you need to have your message sent as close to 1mS as possible?  If so
I'm surprised that ethernet uncertainties don't swamp any jitter from the
interrupt.  Never mind the additional uncertainties introduced by whatever
higher level protocol you are running on ethernet (probably TCP/IP consider
you are using WIZnet?)

RE: [lpc2000] GCC, uCOS-II, nested interrupts

2006-05-12 by Andrew Berney

Cardiff University has a nice C write up for use with Unix at
http://www.cs.cf.ac.uk/Dave/C/CE.html that may help - although its not
directly aimed at GCC etc.

Andy
Show quoted textHide quoted text
-----Original Message-----
From: lpc2000@yahoogroups.com [mailto:lpc2000@yahoogroups.com]On Behalf
Of Mukund Deshmukh
Sent: 12 May 2006 05:54
To: lpc2000@yahoogroups.com
Subject: Re: [lpc2000] GCC, uCOS-II, nested interrupts


> > I just uploaded a project I tinkered on last year for
> > the Philips ARM 2005 contest held by Circuit Cellar. It
> > has a PDF document inside describing the code, along
> > with the code and a port of the uCOS-II RTOS that
> > uses nested interrupts. The document and code show
> > how to use nested interrupts without having to use
> > uCOS-II as well.
> >
> http://www.ovro.caltech.edu/~dwh/ucos/project_AR1803.pdf

Excellent Document !!
I am not a C expert but use C for Embedded Application.
Although I  am using ld, make and asm file for LPC, but never understood
what's inside these files.
Your document has helped me to understand a little bit of it.
Thanks again!!

BTW, are there any more links, documentation, for ld, make and asm files for
GCC compiler, and suitable for a layman like me.


Best Regards,

Mukund Deshmukh.
Beta Computronics Pvt Ltd
10/1, IT Park, Parsodi,
Nagpur-440022
Cell - 9422113746






Yahoo! Groups Links

Re: [lpc2000] Interrupt function declaration

2006-05-12 by Andy

I am investigating exactly that point (academic project), seeing how acurate 
a shared clock network I can produce over ethernet.  I have created a custom 
protocol for ethernet, using the W3100A in mac layer raw mode.  Controlling 
the traffic seems to produce a fairly low jitter network.  Thanks for the 
pointer to your app note, should be very helpful.

Andy.
Show quoted textHide quoted text
----- Original Message ----- 
From: "Robert Adsett" <subscriptions@...>
To: <lpc2000@yahoogroups.com>
Sent: Friday, May 12, 2006 5:21 AM
Subject: Re: [lpc2000] Interrupt function declaration


At 09:27 AM 5/11/06 +0100, Andy wrote:
>Robert,
>I am running a shared clock network over ethernet, so to reduce task jitter
>on the slave nodes the timer0 interrupt needs to be as close as possible.

Do you need to have your message sent as close to 1mS as possible?  If so
I'm surprised that ethernet uncertainties don't swamp any jitter from the
interrupt.  Never mind the additional uncertainties introduced by whatever
higher level protocol you are running on ethernet (probably TCP/IP consider
you are using WIZnet?)

Or do you just need to know the time that you sent the packet as accurately
as possible.  If that's the case (and I think it should be with a good
clock synchronization algorithm) then there are other approaches that will
give you greater accuracy without the interrupt overhead. With the timers
on the LPC series it is quite easy to setup a polled timer that will give
you time with an precision of a few tenth's of a uS that will not exhibit
any significant wrap around oddities as long as you poll it every few
minutes.  Accuracy is actually limited in most cases by the crystal. Chalk
one up for 32bit timers, one of the features I really like on this micro.

See

http://www.aeolusdevelopment.com/AppNotes/LPC210X/an-timerperformance.pdf

It's an app note I did on taking some performance measurements on such a 
clock.


Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,   be
they legal, genetic, or physical.  If you don't believe me, try to chew a
radio signal. "  -- Kelvin Throop, III
http://www.aeolusdevelopment.com/





Yahoo! Groups Links

Re: Interrupt function declaration

2006-05-12 by grapevinetech

Interesting. You are probably aware of this, but there is an IEEE
standard for this. Its IEEE 1588 and is used as part of the LXI
instrumentation standard. See this link for more information.

http://www.lxistandard.org/papers/paperOverview/White_Paper_1_The_Appliaction_of_IEEE_1588_to_Test_and_Measurement_Systems.pdf

I believe that the same concepts are used in the CAN derived TTP.

    Andy..

--- In lpc2000@yahoogroups.com, "Andy" <me@...> wrote:
>
> I am investigating exactly that point (academic project), seeing how
acurate 
> a shared clock network I can produce over ethernet.  I have created
a custom 
> protocol for ethernet, using the W3100A in mac layer raw mode. 
Controlling 
> the traffic seems to produce a fairly low jitter network.  Thanks
for the 
> pointer to your app note, should be very helpful.
> 
> Andy.
> 
> ----- Original Message ----- 
> From: "Robert Adsett" <subscriptions@...>
> To: <lpc2000@yahoogroups.com>
> Sent: Friday, May 12, 2006 5:21 AM
> Subject: Re: [lpc2000] Interrupt function declaration
> 
> 
> At 09:27 AM 5/11/06 +0100, Andy wrote:
> >Robert,
> >I am running a shared clock network over ethernet, so to reduce
task jitter
> >on the slave nodes the timer0 interrupt needs to be as close as
possible.
> 
> Do you need to have your message sent as close to 1mS as possible? 
If so
> I'm surprised that ethernet uncertainties don't swamp any jitter
from the
> interrupt.  Never mind the additional uncertainties introduced by
whatever
> higher level protocol you are running on ethernet (probably TCP/IP
consider
> you are using WIZnet?)
> 
> Or do you just need to know the time that you sent the packet as
accurately
> as possible.  If that's the case (and I think it should be with a good
> clock synchronization algorithm) then there are other approaches
that will
> give you greater accuracy without the interrupt overhead. With the
timers
> on the LPC series it is quite easy to setup a polled timer that will
give
> you time with an precision of a few tenth's of a uS that will not
exhibit
> any significant wrap around oddities as long as you poll it every few
> minutes.  Accuracy is actually limited in most cases by the crystal.
Chalk
> one up for 32bit timers, one of the features I really like on this
micro.
> 
> See
> 
>
http://www.aeolusdevelopment.com/AppNotes/LPC210X/an-timerperformance.pdf
> 
> It's an app note I did on taking some performance measurements on
such a 
> clock.
> 
> 
> Robert
> 
> " 'Freedom' has no meaning of itself.  There are always
restrictions,   be
> they legal, genetic, or physical.  If you don't believe me, try to
chew a
Show quoted textHide quoted text
> radio signal. "  -- Kelvin Throop, III
> http://www.aeolusdevelopment.com/
> 
> 
> 
> 
> 
> Yahoo! Groups Links
>

[lpc2000] Re: Interrupt function declaration

2006-05-12 by Andy

I am investigating exactly that point (academic project), seeing how acurate
a shared clock network I can produce over ethernet.  I have created a custom
protocol for ethernet, using the W3100A in mac layer raw mode.  Controlling
the traffic seems to produce a fairly low jitter network.  Thanks for the
pointer to your app note, should be very helpful.

Andy.
Show quoted textHide quoted text
----- Original Message ----- 
From: "Robert Adsett" <subscriptions@...>
To: <lpc2000@yahoogroups.com>
Sent: Friday, May 12, 2006 5:21 AM
Subject: Re: [lpc2000] Interrupt function declaration


At 09:27 AM 5/11/06 +0100, Andy wrote:
>Robert,
>I am running a shared clock network over ethernet, so to reduce task jitter
>on the slave nodes the timer0 interrupt needs to be as close as possible.

Do you need to have your message sent as close to 1mS as possible?  If so
I'm surprised that ethernet uncertainties don't swamp any jitter from the
interrupt.  Never mind the additional uncertainties introduced by whatever
higher level protocol you are running on ethernet (probably TCP/IP consider
you are using WIZnet?)

Or do you just need to know the time that you sent the packet as accurately
as possible.  If that's the case (and I think it should be with a good
clock synchronization algorithm) then there are other approaches that will
give you greater accuracy without the interrupt overhead. With the timers
on the LPC series it is quite easy to setup a polled timer that will give
you time with an precision of a few tenth's of a uS that will not exhibit
any significant wrap around oddities as long as you poll it every few
minutes.  Accuracy is actually limited in most cases by the crystal. Chalk
one up for 32bit timers, one of the features I really like on this micro.

See

http://www.aeolusdevelopment.com/AppNotes/LPC210X/an-timerperformance.pdf

It's an app note I did on taking some performance measurements on such a 
clock.


Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,   be
they legal, genetic, or physical.  If you don't believe me, try to chew a
radio signal. "  -- Kelvin Throop, III
http://www.aeolusdevelopment.com/





Yahoo! Groups Links

Re: [lpc2000] GCC, uCOS-II, nested interrupts

2006-05-12 by David Hawkins

> I am not a C expert but use C for Embedded Application.
> Although I  am using ld, make and asm file for LPC, but never understood
> what's inside these files.
> Your document has helped me to understand a little bit of it.
> Thanks again!!

Great to hear.

> BTW, are there any more links, documentation, for ld, make and asm files for
> GCC compiler, and suitable for a layman like me.

I read the GNU manuals, and wrote code. Most of the GNU tools
have verbose modes which can help indicate what they are doing.
Some of the 'features' you just have to look in other code,
eg. look at linker files, look at crt0.s files, there are
plenty of examples in the Linux source, and I'm sure FreeRTOS
and other projects have good examples. Even the free Keil
tools have examples.

Have fun!
Dave

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.