Lpc2000

Hi all,

I'm looking for a Mictor 38-pin connector for a little quitity.
(5 parts).

Have you some address where can I buy this connector.

It's AMP/TYCO product.

best regards
Yodathegreat

> Hi all,
> 
> I'm looking for a Mictor 38-pin connector for a little quitity.
> (5 parts).
> 
> Have you some address where can I buy this connector.
> 
> It's AMP/TYCO product.
> 
> best regards
> Yodathegreat

Look up the part number on digikey or Avnet, it'll have the
form 795845-1 or something like that (AMP/TYCO).

The 38-pin mictor is a standard logic analyzer header, so
it should be easily available - I know I have purchased
some in the past.

Dave

--- In lpc2000@yahoogroups.com, "yodathgreat" <christophe.darnet@l...> 
wrote:
> Hi all,
> 
> I'm looking for a Mictor 38-pin connector for a little quitity.
> (5 parts).
> 
> Have you some address where can I buy this connector.
> 
> It's AMP/TYCO product.
> 
> best regards
> Yodathegreat

A29126-ND www.digikey.com
unfortunately these are not Pb-free

best regards
Tsvetan

--- In lpc2000@yahoogroups.com, "yodathgreat" 
<christophe.darnet@l...> wrote:
> Hi all,
> 
> I'm looking for a Mictor 38-pin connector for a little quitity.
> (5 parts).
> 
> Have you some address where can I buy this connector.
> 
> It's AMP/TYCO product.
> 
> best regards
> Yodathegreat

Hi Yodathegreat,

little quantities are also available at www.farnell.com 
(AMP 2-767004-2, order code: 3158627)

Bye
Rainer

No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.344 / Virus Database: 267.11.3/107 - Release Date: 20/09/2005


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

Hi All,

ARM_UCOS 1.16 port includes BSPs for both LPC210x &
LPC213x series.

Download:
--------

http://www.geocities.com/michaelanburaj/downloads/arm_ucos_1.161.zip

Cheers,
-Mike.

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

Hey Michael,

In your port os_cpu_a.S, you use the store/load-multiple
instructions in your context save and restore routines, whereas
in Jean Labrosse's versions he uses individual instructions.

The comment made by Jean in one or more of his app notes runs 
along the lines that in User/System mode the store/load-multiple 
instructions are unsafe. Sure enough the ARM-ARM makes some 
comments to that extent, but the comments are a bit obtuse
(to me anyway). It may be that in some situations the code 
is unsafe while in others its ok.

In an earlier version of your port, tasks ran in supervisor
mode (in which the store/load multiple instructions would
be deemed safe). From init.S from the lpc2xxx folder, it
looks like you leave the processor in SVC mode.
Is this why you chose this mode? 

Any other arguments in favor of SVC vs SYS mode?

Any comments on the store/load-multiple instructions and
issues with their use?

(Philips apps guys - any comments?)

Cheers
Dave Hawkins.
Caltech.

On Wednesday 21 September 2005 10:27, David Hawkins wrote:
> Hey Michael,
>
> In your port os_cpu_a.S, you use the store/load-multiple
> instructions in your context save and restore routines, whereas
> in Jean Labrosse's versions he uses individual instructions.
>
> The comment made by Jean in one or more of his app notes runs
> along the lines that in User/System mode the store/load-multiple
> instructions are unsafe. Sure enough the ARM-ARM makes some
> comments to that extent, but the comments are a bit obtuse
> (to me anyway). It may be that in some situations the code
> is unsafe while in others its ok.

ldm/stm are used just about everywhere for stack saving, block copying etc.

There are two forms of stm: stm(1) and stm(2)
There are three forms of ldm: 1,2,3.

The stm(1) form seems to be generally safe whereas the stm(2) form is only 
safe in certain cases (saving the SYS/user register bank while not in that 
mode). How you determine which you get, perhaps someone else knows...

>
> In an earlier version of your port, tasks ran in supervisor
> mode (in which the store/load multiple instructions would
> be deemed safe). From init.S from the lpc2xxx folder, it
> looks like you leave the processor in SVC mode.
> Is this why you chose this mode?
>
> Any other arguments in favor of SVC vs SYS mode?

One argument against leaving things in SVC mode is that you cannot then do 
SWIs, since SWIs need to switch to SVC mode to execute.

>
> Any comments on the store/load-multiple instructions and
> issues with their use?

STM and LDM provide nice compact data shuffling, but they can push out 
interrupt latency since the whole instruction must finish before the 
interrupt can be serviced. For that reason, some compilers allow for 
controlling the maximum number of registers save/restored by an ldm/stm.

Hi Charles,

Thanks for the interesting comments.

> One argument against leaving things in SVC mode is that you 
> cannot then do SWIs, since SWIs need to switch to SVC mode to 
> execute.

Is that really true? Since an SWI is generated from an instruction,
you could push the contents of the link register, then call
an SWI, and then restore the link register? So you could run the
RTOS from SVC and still use SWIs.

> > Any comments on the store/load-multiple instructions and
> > issues with their use?
> 
> STM and LDM provide nice compact data shuffling, but they can push out 
> interrupt latency since the whole instruction must finish before the 
> interrupt can be serviced. For that reason, some compilers allow for 
> controlling the maximum number of registers save/restored by an ldm/stm.

Good point. But in the case of exception handler prolog and epilog
code, you'd ideally use those instructions. Even when interrupt
nesting, its nice to save full context before enabling interrupts of 
higher priority, ditto for the restore sequence.

Dave

> 
> There are two forms of stm: stm(1) and stm(2)
> There are three forms of ldm: 1,2,3.
> 
> The stm(1) form seems to be generally safe whereas the stm(2) 
> form is only 
> safe in certain cases (saving the SYS/user register bank while 
> not in that 
> mode).

> How you determine which you get, perhaps someone else knows...

There is the slight syntacical difference between a context
restore sequence, eg. 

  ldmfd sp!,{r0-r12,lr,pc}^   // pop new task's r0-r12,lr & pc

versus not including pc in the register list. In that case
the user/sys registers are updated. (I think thats right,
I don't have my ARM-ARM open).

So I was wondering whether the 'safety' issues with using
ldm from user/sys mode are related to this particular use
only, or were in general not useable from user/sys mode.

If this is the case, then I suspect Jean Labrosse's uCOS
port was based on caution, and that the ldm instructions
can be used to speed up the context save/restore sequence
slightly.

At some point I'll just boot the LPC board I have with
one version of the code or the other and see if I break
anything :)  (Busy on other things at the moment tho).

Dave

> ldm/stm are used just about everywhere for stack saving, block 
copying etc.
> 
> There are two forms of stm: stm(1) and stm(2)
> There are three forms of ldm: 1,2,3.
> 
> The stm(1) form seems to be generally safe whereas the stm(2) form 
is only 
> safe in certain cases (saving the SYS/user register bank while not 
in that 
> mode). How you determine which you get, perhaps someone else knows.
..

I just found out:

The difference is achieved by using the "^" and specifying r15 (== pc
). This sets the "S" flag in the instruction encoding.

eg  ldmia r13!,{r0,r1,pc}^

http://www.cl.cam.ac.uk/users/acjf3/papers/bdt.pdf gives some nice 
background

--- In lpc2000@yahoogroups.com, "David Hawkins" <dwh@o...> wrote:
> 
> Hi Charles,
> 
> Thanks for the interesting comments.
> 
> > One argument against leaving things in SVC mode is that you 
> > cannot then do SWIs, since SWIs need to switch to SVC mode to 
> > execute.
> 
> Is that really true? Since an SWI is generated from an instruction,
> you could push the contents of the link register, then call
> an SWI, and then restore the link register? So you could run the
> RTOS from SVC and still use SWIs.

I guess you could do that, but that would add extra overhead to the 
SWI calls.

AFAIK, the problem only applies to a few encodings of ldm/stm that you 
don't use in normal use anyway. Therefore I don't see much need to 
jump through hoops to accomodate it.

> 
> > > Any comments on the store/load-multiple instructions and
> > > issues with their use?
> > 
> > STM and LDM provide nice compact data shuffling, but they can push 
out 
> > interrupt latency since the whole instruction must finish before 
the 
> > interrupt can be serviced. For that reason, some compilers allow 
for 
> > controlling the maximum number of registers save/restored by an 
ldm/stm.
> 
> Good point. But in the case of exception handler prolog and epilog
> code, you'd ideally use those instructions. Even when interrupt
> nesting, its nice to save full context before enabling interrupts of 
> higher priority, ditto for the restore sequence.

For calling APCS compilant (ie. C generated isrs) you do not have to 
save all registers, only r0..r3. The called function will save any 
other registers it needs itself.

The lockout also applies to fiqs too. fiq handling can sometimes be 
done at a very high rate (ie. a few well chosen instructions).

> I guess you could do that, but that would add extra overhead to the 
> SWI calls.
> 
> AFAIK, the problem only applies to a few encodings of ldm/stm that you 
> don't use in normal use anyway. Therefore I don't see much need to 
> jump through hoops to accomodate it.

Thats what I am trying to determine.
 
> For calling APCS compilant (ie. C generated isrs) you do not have to 
> save all registers, only r0..r3. The called function will save any 
> other registers it needs itself.

Right, but if you are running an RTOS, then the C generated ISR
code is insufficient, since a context switch may occur as a
consequence of the interrupt. So in uCOS-II you need to save
all processor context, service the interrupts, and then restore
to the highest priority task. Since you basically have to store
all registers, it would seem that the ldm/stm instructions would
be the desired ones to use.

Dave

On Wednesday 21 September 2005 12:33, David Hawkins wrote:
> > I guess you could do that, but that would add extra overhead to the
> > SWI calls.
> >
> > AFAIK, the problem only applies to a few encodings of ldm/stm that you
> > don't use in normal use anyway. Therefore I don't see much need to
> > jump through hoops to accomodate it.
>
> Thats what I am trying to determine.

From a read of the ARMARM it would appear that the Bad Form only applies when 
you use stm(2)/ldm(2) in user/system mode because these provide a special 
"worm hole" to access the user/system registers - something that is pointless 
when you are already in sustem/user mode.

From what I can tell, this form would only be reasonably used when you are 
trying to access system/user registers when in a different protected mode.  
Example of this might be:
1) In an OS environment where you are using SWI as a trap to the OS.
2) Exception handler for data aborts/page swapping etc.
3) Perhaps as part of a scheduler in an RTOS.


>
> > For calling APCS compilant (ie. C generated isrs) you do not have to
> > save all registers, only r0..r3. The called function will save any
> > other registers it needs itself.
>
> Right, but if you are running an RTOS, then the C generated ISR
> code is insufficient, since a context switch may occur as a
> consequence of the interrupt. So in uCOS-II you need to save
> all processor context, service the interrupts, and then restore
> to the highest priority task. Since you basically have to store
> all registers, it would seem that the ldm/stm instructions would
> be the desired ones to use.


Unwrapped C generated code is definitely insufficient for many purposes, but 
perhaps you miss my point.

The IRQ wrapper that calls a C function does not need to save all the 
registers. According to the APCS, the caller should preserve r0-r3,r12 (and 
r14) and the callee any others. Thus, the wrapper only needs to preserve 
r0-r3,r12,r14. The C function will save/restore any others itself.

Of course if you trash other registers in the IRQ wrapper then you need to 
save those too.

Of course, too, any context needed by the scheduler will need to save all 
registers.

> On Wednesday 21 September 2005 12:33, David Hawkins wrote:
> > > I guess you could do that, but that would add extra overhead to the
> > > SWI calls.
> > >
> > > AFAIK, the problem only applies to a few encodings of ldm/stm that you
> > > don't use in normal use anyway. Therefore I don't see much need to
> > > jump through hoops to accomodate it.
> >
> > Thats what I am trying to determine.
>
> >From a read of the ARMARM it would appear that the Bad Form only
> applies when
> you use stm(2)/ldm(2) in user/system mode because these provide a special
> "worm hole" to access the user/system registers - something that
> is pointless
> when you are already in sustem/user mode.
>
> >From what I can tell, this form would only be reasonably used
> when you are
> trying to access system/user registers when in a different
> protected mode.
> Example of this might be:
> 1) In an OS environment where you are using SWI as a trap to the OS.
> 2) Exception handler for data aborts/page swapping etc.
> 3) Perhaps as part of a scheduler in an RTOS.
>
> > > For calling APCS compilant (ie. C generated isrs) you do not have to
> > > save all registers, only r0..r3. The called function will save any
> > > other registers it needs itself.
> >
> > Right, but if you are running an RTOS, then the C generated ISR
> > code is insufficient, since a context switch may occur as a
> > consequence of the interrupt. So in uCOS-II you need to save
> > all processor context, service the interrupts, and then restore
> > to the highest priority task. Since you basically have to store
> > all registers, it would seem that the ldm/stm instructions would
> > be the desired ones to use.
>
> Unwrapped C generated code is definitely insufficient for many
> purposes, but perhaps you miss my point.
>
> The IRQ wrapper that calls a C function does not need to save all the
> registers. According to the APCS, the caller should preserve
> r0-r3,r12 (and
> r14) and the callee any others. Thus, the wrapper only needs to preserve
> r0-r3,r12,r14. The C function will save/restore any others itself.
>
> Of course if you trash other registers in the IRQ wrapper then
> you need to save those too.
>
> Of course, too, any context needed by the scheduler will need to save all
> registers.

Yep, understood. Thanks for the valuable discussion.

Cheers
Dave

David Hawkins <dwh@...> schrieb am Tue, 20 Sep 2005 17:33:45 
-0700:

>
>> I guess you could do that, but that would add extra overhead to the
>> SWI calls.
>>
>> AFAIK, the problem only applies to a few encodings of ldm/stm that you
>> don't use in normal use anyway. Therefore I don't see much need to
>> jump through hoops to accomodate it.
>
> Thats what I am trying to determine.
>
>> For calling APCS compilant (ie. C generated isrs) you do not have to
>> save all registers, only r0..r3. The called function will save any
>> other registers it needs itself.
>
> Right, but if you are running an RTOS, then the C generated ISR
> code is insufficient, since a context switch may occur as a
> consequence of the interrupt.

For most applications the interrupt latency is interresting, so
commercial RTOS' save at first only the registers a APCS compliant
function will not save (i.e. r0-r3, lr_sys,lr_irq).
Only if the ISR causes a re-schedule the rest is also saved.

The reason is simply, that not every ISR causes a re-schedule and the time
in front of the ISR should be kept short.


-- 
42Bastian Schick

Hi David,

[ My views on the subject ]

--- David Hawkins <dwh@...> wrote:

> 
> Hey Michael,
> 
> In your port os_cpu_a.S, you use the
> store/load-multiple
> instructions in your context save and restore
> routines, whereas
> in Jean Labrosse's versions he uses individual
> instructions.
> 
> The comment made by Jean in one or more of his app
> notes runs 
> along the lines that in User/System mode the
> store/load-multiple 
> instructions are unsafe. Sure enough the ARM-ARM
> makes some 
> comments to that extent, but the comments are a bit
> obtuse
> (to me anyway). It may be that in some situations
> the code 
> is unsafe while in others its ok.
> 
> In an earlier version of your port, tasks ran in
> supervisor
> mode (in which the store/load multiple instructions
> would
> be deemed safe). From init.S from the lpc2xxx
> folder, it
> looks like you leave the processor in SVC mode.

Totally agree with your concern. Just like you said,
the code is run completely in SVC mode till date in
all my ports. And as someone pointed (and mentioned in
the ARM_ARM document) the LDM(3) \ufffd is unsafe only in
System or User mode \ufffd Which is completely avoided in
my port. And the other failure case is when Rn = R15,
which is not true either.

> Is this why you chose this mode? 

You could say that. But, Nope :)
I did not choose this; but rather I chose not to
switch out of SVC, because it is the default mode &
did not find kernel protection to be all that useful
in a monolithic, tight RTOS like this (same philosophy
applies to all my other architecture uCOS-II ports).
Apart from this, I would use system mode briefly to do
nested interrupts as suggested in the ARM_ARM
document.

The RTOS, foreground tasks \ufffd pretty much all the code
except for the ISRs run in SVC mode; I don\ufffdt see any
good reason to support SWI.

[ I have been in primary kernel development roles for
Linux like virtual space user processes (TLB based
MMU) & protected kernel OS on ARM9, where SWI was very
much useful ]

One thought I always have is, Why not SVC?

> 
> Any other arguments in favor of SVC vs SYS mode?
> 
> Any comments on the store/load-multiple instructions
> and
> issues with their use?

Apart from these, the IRQ handler in normal course
(when a Task sw is not required) preserves just the
registers required by ATPCS & the rest of the context
saving happens only when a task context switch is
needed. Due to this you will see some extra coping
done in the int_ctx_sw portion of the code \ufffd And lot
of caution has be taken to work with ARM-THUMB mixed
mode code.

As such the code is thoroughly tested; the same code
(under common) runs in many different flavors of
ARM7/9s.

[ Please feel free to comment, suggest improvements on
the port ]

Cheers,
-Mike.


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

Skip all valid stuff.... Zoom in on SWI.

> The RTOS, foreground tasks – pretty much all the code
> except for the ISRs run in SVC mode; I don't see any
> good reason to support SWI.

> 
> [ I have been in primary kernel development roles for
> Linux like virtual space user processes (TLB based
> MMU) & protected kernel OS on ARM9, where SWI was very
> much useful ]
> 
> One thought I always have is, Why not SVC?

For the most part, I think you are right. SWI is rather pointless in 
many/most single-chip embedded applications. I have shipped a few 
products that only use SVC and interrupt modes.

> 
> > 
> > Any other arguments in favor of SVC vs SYS mode?

The only time you might realisticly want to support SWI is for semi-
hosting mode support. I have also seen an RTOS done using SWI to make 
all OS calls atomic, but that was rather contrived and it would have 
been done better a duifferent way. Semi-hosting allows BIOS-like 
handlers (for you old x86/DOS rememberers like me) for printing etc to 
be handled by SWI handlers, but that can be typically ignored with no 
ill effects (other than not getting the functionality).

You might have semi-hosting without even realising it. For example, 
libgcc, by default, issues semi-hosting calls for various things like 
divide by zero handling.

>The only time you might realisticly want to support SWI is for semi-
>hosting mode support. I have also seen an RTOS done using SWI to make
>all OS calls atomic, but that was rather contrived and it would have
>been done better a duifferent way. Semi-hosting allows BIOS-like
>handlers (for you old x86/DOS rememberers like me) for printing etc to
>be handled by SWI handlers, but that can be typically ignored with no
>ill effects (other than not getting the functionality).

I use the SWI for tasks to force a context switch (Yield).  The context
switch occurs out of system mode so no problem with ldmfd's.  Seems the
simplest way to me but I would be interested in an expansion on your
comments above.

AFAIK provided ldmfd's are always followed by a NOP they are fine in
supervisor and IRQ modes.

Regards,
Richard.


http://www.FreeRTOS.org





----------------------------------------------------------------------------
----
YAHOO! GROUPS LINKS

  a..  Visit your group "lpc2000" on the web.

  b..  To unsubscribe from this group, send an email to:
   lpc2000-unsubscribe@yahoogroups.com

  c..  Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.


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

Hey Michael,

> [ My views on the subject ]

Thanks for all the feedback - I'll definitely send comments if
I have any. 

Cheers
Dave