Lpc2000

Yes I know the issue of IDE choice is often discussed, but please bear
with me on this.
I'm a relative newbie with Philips lpc2xxx, but reasonably familiar
with PIC microcontrollers. So far I have been playing round with the
demo (16k limit) of the Keil uVision IDE + their jtag, and I am coming
to the stage when I have to pay real money for a full IDE / compiler /
debug suite to produce commercial code.

Two points that cause me to question my current loyalty to Keil are
the poor performance of its compiler in some recently-posted
benchmarks, and the (apparently) closed nature of its jtag interface.
There is also the active support given to this list by those at Rowley.

But a feature of Keil which I do not want to lose is their debug
support for on-chip peripherals. By peripheral I mean (for example)
the Vector Interrupt Controller, the I2C hardware etc. The Keil
debugger has summary windows showing the state of each peripheral, and
allows you to change the peripheral registers without needing to look
up how the peripheral register is mapped in memory or which bit
corresponds to a given flag.

So my question is: Do other debugging environments have support for
on-chip peripherals? Either built-in or provided by third-party? I
would like an answer for both Rowley and IAR, not necessarily from the
same person.

Thanks in advance,
Danish

> So my question is: Do other debugging environments have support for
> on-chip peripherals? Either built-in or provided by third-party? I
> would like an answer for both Rowley and IAR, not necessarily from the
> same person.

Yes IAR does.  You can twiddle all the on-chip peripherals.  IAR's debugger
(C-Spy) also supports the concept of plug-ins.  So depending on your RTOS
vendor, this may be an option.  There is plenty of information at
www.iar.com.


Joel

dr_danish_ali wrote:

>Yes I know the issue of IDE choice is often discussed, but please bear
>with me on this.
>I'm a relative newbie with Philips lpc2xxx, but reasonably familiar
>with PIC microcontrollers. So far I have been playing round with the
>demo (16k limit) of the Keil uVision IDE + their jtag, and I am coming
>to the stage when I have to pay real money for a full IDE / compiler /
>debug suite to produce commercial code.
>
>Two points that cause me to question my current loyalty to Keil are
>the poor performance of its compiler in some recently-posted
>benchmarks, and the (apparently) closed nature of its jtag interface.
>There is also the active support given to this list by those at Rowley.
>
>But a feature of Keil which I do not want to lose is their debug
>support for on-chip peripherals. By peripheral I mean (for example)
>the Vector Interrupt Controller, the I2C hardware etc. The Keil
>debugger has summary windows showing the state of each peripheral, and
>allows you to change the peripheral registers without needing to look
>up how the peripheral register is mapped in memory or which bit
>corresponds to a given flag.
>
>So my question is: Do other debugging environments have support for
>on-chip peripherals? Either built-in or provided by third-party? I
>would like an answer for both Rowley and IAR, not necessarily from the
>same person.
>  
>
Hi Danish,

CrossWorks For ARM supports the display of memory mapped peripheral 
registers.

Regards
Michael

>Thanks in advance,
>Danish
>
>
>
>
>
>
> 
>Yahoo! Groups Links
>
>
>
> 
>
>
>  
>

Thanks very much Michael and Joel.
This means I ought to download and try out the demo versions of IAR
and Crossworks. (Although I can't link them to my hardware unless I
buy an appropriate JTAG interface).
I will say in my defence that it was not obvious from the IAR website
that the peripherals could be debugged. I did go through the flash
demo of the debugger and peripherals were not demonstrated.
Regards,
Danish
--- In lpc2000@yahoogroups.com, Michael Johnson <mpj@r...> wrote:

>
> dr_danish_ali wrote:
> 
> >Yes I know the issue of IDE choice is often discussed, but please bear
> >with me on this.
> >I'm a relative newbie with Philips lpc2xxx, but reasonably familiar
> >with PIC microcontrollers. So far I have been playing round with the
> >demo (16k limit) of the Keil uVision IDE + their jtag, and I am coming
> >to the stage when I have to pay real money for a full IDE / compiler /
> >debug suite to produce commercial code.
> >
> >But a feature of Keil which I do not want to lose is their debug
> >support for on-chip peripherals.
> Hi Danish,
> 
> CrossWorks For ARM supports the display of memory mapped peripheral 
> registers.
> 
> Regards
> Michael

derbaier wrote:

>--- In lpc2000@yahoogroups.com, "dr_danish_ali" <danish@g...> wrote:
>  
>
>>Thanks very much Michael and Joel.
>>This means I ought to download and try out the demo versions of IAR
>>and Crossworks. (Although I can't link them to my hardware unless I
>>buy an appropriate JTAG interface).
>>I will say in my defence that it was not obvious from the IAR website
>>that the peripherals could be debugged. I did go through the flash
>>demo of the debugger and peripherals were not demonstrated.
>>Regards,
>>Danish
>>    
>>
>
>FWIW, it appears that both Keil and IAR support RDI, and IAR also
>supoorts Wiggler, so they hardly have "closed" debug interfaces. Don't
>know about Crossworks, since I have not seen a demo version of their IDE.
>  
>
CrossWorks supports the Wiggler (on windows and linux), Segger J-Link 
(windows only) and the CrossConnect (on windows and linux). We don't 
support RDI at this point in time.

Regards
Michael

>-- Dave
>
>
>
>
>
>
>
> 
>Yahoo! Groups Links
>
>
>
> 
>
>
>
>  
>

--- In lpc2000@yahoogroups.com, "dr_danish_ali" <danish@g...> wrote:
>
> Thanks very much Michael and Joel.
> This means I ought to download and try out the demo versions of IAR
> and Crossworks. (Although I can't link them to my hardware unless I
> buy an appropriate JTAG interface).
> I will say in my defence that it was not obvious from the IAR website
> that the peripherals could be debugged. I did go through the flash
> demo of the debugger and peripherals were not demonstrated.
> Regards,
> Danish

FWIW, it appears that both Keil and IAR support RDI, and IAR also
supoorts Wiggler, so they hardly have "closed" debug interfaces. Don't
know about Crossworks, since I have not seen a demo version of their IDE.

-- Dave

Dave, 

> > Thanks very much Michael and Joel.
> > This means I ought to download and try out the demo versions of IAR
> > and Crossworks. (Although I can't link them to my hardware unless I
> > buy an appropriate JTAG interface).
> > I will say in my defence that it was not obvious from the 
> IAR website
> > that the peripherals could be debugged. I did go through the flash
> > demo of the debugger and peripherals were not demonstrated.
> > Regards,
> > Danish
> 
> FWIW, it appears that both Keil and IAR support RDI, and IAR also
> supoorts Wiggler, so they hardly have "closed" debug interfaces. 

RDI is open in the sense that it's "open to all those that pay the
entrance fee."  I find it hard to call that "open."

--
Paul Curtis, Rowley Associates Ltd  http://www.rowley.co.uk
CrossWorks for MSP430, ARM, AVR and now MAXQ processors

----- Original Message ----- 

From: "derbaier" <dershu@...>
To: <lpc2000@yahoogroups.com>
Sent: Thursday, January 19, 2006 1:57 PM
Subject: [lpc2000] Re: IDE choice for peripheral support


> --- In lpc2000@yahoogroups.com, "dr_danish_ali" <danish@g...> wrote:
>>
>> Thanks very much Michael and Joel.
>> This means I ought to download and try out the demo versions of IAR
>> and Crossworks. (Although I can't link them to my hardware unless I
>> buy an appropriate JTAG interface).
>> I will say in my defence that it was not obvious from the IAR website
>> that the peripherals could be debugged. I did go through the flash
>> demo of the debugger and peripherals were not demonstrated.
>> Regards,
>> Danish
>
> FWIW, it appears that both Keil and IAR support RDI, and IAR also
> supoorts Wiggler, so they hardly have "closed" debug interfaces. Don't
> know about Crossworks, since I have not seen a demo version of their IDE.

Crossworks supports the Wiggler, Segger and their own USB JTAG interfaces. 
The latter is good value at 99 GBP.

Leon

You may get the ARM-JTAG (USD19.95) from Olimex. It works well under 
both CrossWorks and IAR.

regards,
Tim Chua
EmbeddedHub.

--- In lpc2000@yahoogroups.com, "Leon Heller" <leon.heller@b...> 
wrote:
>
> ----- Original Message ----- 
> From: "derbaier" <dershu@s...>
> To: <lpc2000@yahoogroups.com>
> Sent: Thursday, January 19, 2006 1:57 PM
> Subject: [lpc2000] Re: IDE choice for peripheral support
> 
> 
> > --- In lpc2000@yahoogroups.com, "dr_danish_ali" <danish@g...> 
wrote:
> >>
> >> Thanks very much Michael and Joel.
> >> This means I ought to download and try out the demo versions of 
IAR
> >> and Crossworks. (Although I can't link them to my hardware 
unless I
> >> buy an appropriate JTAG interface).
> >> I will say in my defence that it was not obvious from the IAR 
website
> >> that the peripherals could be debugged. I did go through the 
flash
> >> demo of the debugger and peripherals were not demonstrated.
> >> Regards,
> >> Danish
> >
> > FWIW, it appears that both Keil and IAR support RDI, and IAR also
> > supoorts Wiggler, so they hardly have "closed" debug interfaces. 
Don't
> > know about Crossworks, since I have not seen a demo version of 
their IDE.
> 
> Crossworks supports the Wiggler, Segger and their own USB JTAG 
interfaces. 

> The latter is good value at 99 GBP.
> 
> Leon
>

Hi, you may try ARM-JTAG (USD19.95) from Olimex. It works well under 
both CrossWorks and IAR.

regards,
Tim Chua
EmbeddedHub.

--- In lpc2000@yahoogroups.com, "Leon Heller" <leon.heller@b...> 
wrote:
>
> ----- Original Message ----- 
> From: "derbaier" <dershu@s...>
> To: <lpc2000@yahoogroups.com>
> Sent: Thursday, January 19, 2006 1:57 PM
> Subject: [lpc2000] Re: IDE choice for peripheral support
> 
> 
> > --- In lpc2000@yahoogroups.com, "dr_danish_ali" <danish@g...> 
wrote:
> >>
> >> Thanks very much Michael and Joel.
> >> This means I ought to download and try out the demo versions of 
IAR
> >> and Crossworks. (Although I can't link them to my hardware 
unless I
> >> buy an appropriate JTAG interface).
> >> I will say in my defence that it was not obvious from the IAR 
website
> >> that the peripherals could be debugged. I did go through the 
flash
> >> demo of the debugger and peripherals were not demonstrated.
> >> Regards,
> >> Danish
> >
> > FWIW, it appears that both Keil and IAR support RDI, and IAR also
> > supoorts Wiggler, so they hardly have "closed" debug interfaces. 
Don't
> > know about Crossworks, since I have not seen a demo version of 
their IDE.
> 
> Crossworks supports the Wiggler, Segger and their own USB JTAG 
interfaces. 

> The latter is good value at 99 GBP.
> 
> Leon
>

--- In lpc2000@yahoogroups.com, "Paul Curtis" <plc@r...> wrote:
> 
> RDI is open in the sense that it's "open to all those that pay the
> entrance fee."  I find it hard to call that "open."
> 
> --
> Paul Curtis, Rowley Associates Ltd  http://www.rowley.co.uk
> CrossWorks for MSP430, ARM, AVR and now MAXQ processors
>

I can appreciate your point of view, but 'open' in the standards sense
has never been the same as 'free'.  So you may find it hard to call it
'open', but that difficulty does not alter the fact that anyone who
wants to can support the standard.

-- Dave

derbaier wrote:

>--- In lpc2000@yahoogroups.com, "Paul Curtis" <plc@r...> wrote:
>  
>
>>RDI is open in the sense that it's "open to all those that pay the
>>entrance fee."  I find it hard to call that "open."
>>
>>--
>>Paul Curtis, Rowley Associates Ltd  http://www.rowley.co.uk
>>CrossWorks for MSP430, ARM, AVR and now MAXQ processors
>>
>>    
>>
>
>I can appreciate your point of view, but 'open' in the standards sense
>has never been the same as 'free'.  So you may find it hard to call it
>'open', but that difficulty does not alter the fact that anyone who
>wants to can support the standard.
>
>  
>
As long as they pay the Gatekeeper fee and sign a non-disclosure, then 
it is "open" to them, right?

heh, interesting logic.

TomW

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

--- In lpc2000@yahoogroups.com, Tom Walsh <tom@o...> wrote:

> As long as they pay the Gatekeeper fee and sign a non-disclosure, then 
> it is "open" to them, right?
> 
> heh, interesting logic.
> 
> TomW
> 

OK, where in your somewhat biased terminolgy above did you demonstrate
that there was anything that prevented you from access to the ARM RDI
standard? Does "your logic" equate the words 'open' and 'free'? 

"open" just means that access is available if you want it, IMHO.
"closed" means no access at any price, also IMHO.

For me, support for an 'open' debug interface like ARM's RDI is much
more of an issue than things like an IDE's 'eye candy'. Fortunately, a
very large number of commercial development system vendors also seem 
to consider ARM's RDI an itegral part of ARM support since it is
provided in a very large number of them.

Sorry to start a disagreement, but that's how I see it.

-- Dave

> derbaier:

> "open" just means that access is available if you want it, IMHO.
> "closed" means no access at any price, also IMHO.

then micro$ofts APIs would have to be considered "open", because they
supply specs and even source to people paying the $$.

  clemens

--- In lpc2000@yahoogroups.com, clemens fischer <ino-qc@s...> wrote:
>
> > derbaier:
> 
> > "open" just means that access is available if you want it, IMHO.
> > "closed" means no access at any price, also IMHO.
> 
> then micro$ofts APIs would have to be considered "open", because they
> supply specs and even source to people paying the $$.
> 
>   clemens

Well, there you go then!   :-)
If they were not open then there would be nobody providing software
for their OSs except M$.  And, of course with M$, they certainly are
not free.  So you are still making my point about there being some
difference between 'open' and 'free'.

BTW, WHG and the boys certainly have made a lot of money out of the
business they started by using someone elses software for free, and
then selling it! 

-- Dave

So MS Windows is also open source because you can get a shared source 
license from microsoft?
I don't think so. I don't know what the best definition for "open" is, 
but yours is definitely flawed.

Richard.


derbaier wrote:

> --- In lpc2000@yahoogroups.com, clemens fischer <ino-qc@s...> wrote:
> >
> > > derbaier:
> >
> > > "open" just means that access is available if you want it, IMHO.
> > > "closed" means no access at any price, also IMHO.
> >
> > then micro$ofts APIs would have to be considered "open", because they
> > supply specs and even source to people paying the $$.
> >
> >   clemens
>
> Well, there you go then!   :-)
> If they were not open then there would be nobody providing software
> for their OSs except M$.  And, of course with M$, they certainly are
> not free.  So you are still making my point about there being some
> difference between 'open' and 'free'.
>
> BTW, WHG and the boys certainly have made a lot of money out of the
> business they started by using someone elses software for free, and
> then selling it!
>
> -- Dave
>

derbaier wrote:

>--- In lpc2000@yahoogroups.com, clemens fischer <ino-qc@s...> wrote:
>  
>
>>>derbaier:
>>>      
>>>
>>>"open" just means that access is available if you want it, IMHO.
>>>"closed" means no access at any price, also IMHO.
>>>      
>>>
>>then micro$ofts APIs would have to be considered "open", because they
>>supply specs and even source to people paying the $$.
>>
>>  clemens
>>    
>>
>
>Well, there you go then!   :-)
>If they were not open then there would be nobody providing software
>for their OSs except M$.  And, of course with M$, they certainly are
>not free.  So you are still making my point about there being some
>difference between 'open' and 'free'.
>
>BTW, WHG and the boys certainly have made a lot of money out of the
>business they started by using someone elses software for free, and
>then selling it! 
>
>  
>
You don't know your history!  There was a famous article which Bill 
Gates wrote in DDJ (Doctor Dobbs Journal) back around 1978, in which he 
lambasted people who were using his 4K Basic without paying for it.  
Bill Gates was one of the early people who started the, then, radical 
idea of paying for software.  Prior to that, we gave each other source 
code and helped each other out with their projects as it was fun to do.  
Apparently you've never heard of FidoNet?

TomW


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

----- Original Message ----- 

From: "Tom Walsh" <tom@...>
To: <lpc2000@yahoogroups.com>
Sent: Thursday, January 19, 2006 5:48 PM
Subject: Re: [lpc2000] Re: IDE choice for peripheral support


> You don't know your history!  There was a famous article which Bill
> Gates wrote in DDJ (Doctor Dobbs Journal) back around 1978, in which he
> lambasted people who were using his 4K Basic without paying for it.
> Bill Gates was one of the early people who started the, then, radical
> idea of paying for software.  Prior to that, we gave each other source
> code and helped each other out with their projects as it was fun to do.
> Apparently you've never heard of FidoNet?

A friend of mine with a Z80 S100 system typed in the hex for one of the 
early 8080 BASIC interpreters from a listing in DDJ that I gave him. He got 
it working, to my surprise.

Leon

--- In lpc2000@yahoogroups.com, Tom Walsh <tom@o...> wrote:
>
> >
> You don't know your history!  There was a famous article which Bill 
> Gates wrote in DDJ (Doctor Dobbs Journal) back around 1978, in which he 
> lambasted people who were using his 4K Basic without paying for it.  
> Bill Gates was one of the early people who started the, then, radical 
> idea of paying for software.  Prior to that, we gave each other source 
> code and helped each other out with their projects as it was fun to
do.  
> Apparently you've never heard of FidoNet?
> 
> TomW
> 

Cool, when you can't think of anything else you can always start with
an insult to make your logic stronger.

Basic was NOT the IP theft that I was refering to, and that tangent
thread is irrelevant to the thread subject, so I'll stop right here.

-- Dave

--- In lpc2000@yahoogroups.com, Richard Duits <yahoo@r...> wrote:
>
> So MS Windows is also open source because you can get a shared source 
> license from microsoft?
> I don't think so. I don't know what the best definition for "open" is, 
> but yours is definitely flawed.
> 
> Richard.
> 

Of course it is flawed after you misstate it!
"open source" and an "open" interface specifcation are not the same
thing. "open source" has a defined meaning if you look here:
   http://www.opensource.org/docs/definition.php
That, of course, has rather little to do with RDI!

Anyway, I think that I should just give in to you "open-equals-free"
guys and give it a rest.

The next time you come to a store with an "OPEN" sugn in the window
please consider it all right to take all you want from the store since
it is "free".

The whole point that I really wanted make before the
"open-equals-free" group jumprd in is that RDI support is an important
part of any pretension to support for ARM micros. It is not necessary,
but it is a more serious consideration than an IDE's eye candy.


-- Dave

derbaier wrote:

>--- In lpc2000@yahoogroups.com, Tom Walsh <tom@o...> wrote:
>  
>
>>You don't know your history!  There was a famous article which Bill 
>>Gates wrote in DDJ (Doctor Dobbs Journal) back around 1978, in which he 
>>lambasted people who were using his 4K Basic without paying for it.  
>>Bill Gates was one of the early people who started the, then, radical 
>>idea of paying for software.  Prior to that, we gave each other source 
>>code and helped each other out with their projects as it was fun to
>>    
>>
>do.  
>  
>
>>Apparently you've never heard of FidoNet?
>>
>>TomW
>>
>>    
>>
>
>Cool, when you can't think of anything else you can always start with
>an insult to make your logic stronger.
>
>Basic was NOT the IP theft that I was refering to, and that tangent
>thread is irrelevant to the thread subject, so I'll stop right here.
>\
>  
>
Oh, we call that "Trolling". 



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

--- In lpc2000@yahoogroups.com, Tom Walsh <tom@o...> wrote:

> >
> Oh, we call that "Trolling". 
> 
>
Was that the royal "we"?   ;-) 

In any case, you have yet another definition wrong.

*****************************QUOTE***********************************
From Wikipedia, the free encyclopedia.
Jump to: navigation, search
Internet Troll

In Internet terminology, a troll is a person who posts rude or
offensive messages on the Internet, such as on online discussion
forums, to disrupt discussion or to upset its participants. "Troll"
can also mean the message itself or be a verb meaning to post such
messages. "Trolling" is also commonly used to describe the activity.
*****************************END QUOTE******************************

Seems to me that your "open-equals-free" off topic posts come a lot
closer to fitting that definition. When I started, my point was about
the importance of RDI to an "IDE choice" [part of the threads title]
before the "open-equals-free" TROLLS started.

Hopefully we can try to stay a little closer to the threads topic???

-- Dave


-- Dave

I asked ARM if I could get access to the RDI specifications, and got a "no". I 
didn't ask to have it for free, but I said that I wanted to use it for my 
open source debugger (OpenOCD).
I asked if there would be licensing issues when using RDI in an open product 
(there's enough information publicly available to get RDI working), and got a 
"sorry can't help".

I want to support it, but I can't. By your definition, that makes RDI a closed 
standard.

Regards,

Dominic

On Thursday 19 January 2006 16:06, derbaier wrote:
> --- In lpc2000@yahoogroups.com, "Paul Curtis" <plc@r...> wrote:
> > RDI is open in the sense that it's "open to all those that pay the
> > entrance fee."  I find it hard to call that "open."
> >
> > --
> > Paul Curtis, Rowley Associates Ltd  http://www.rowley.co.uk
> > CrossWorks for MSP430, ARM, AVR and now MAXQ processors
>
> I can appreciate your point of view, but 'open' in the standards sense
> has never been the same as 'free'.  So you may find it hard to call it
> 'open', but that difficulty does not alter the fact that anyone who
> wants to can support the standard.
>
> -- Dave

--- In lpc2000@yahoogroups.com, Dominic Rath <Dominic.Rath@g...> wrote:
>
> I asked ARM if I could get access to the RDI specifications, and got
a "no". I 
> didn't ask to have it for free, but I said that I wanted to use it
for my 
> open source debugger (OpenOCD).
> I asked if there would be licensing issues when using RDI in an open
product 
> (there's enough information publicly available to get RDI working),
and got a 
> "sorry can't help".
> 
> I want to support it, but I can't. By your definition, that makes
RDI a closed 
> standard.
> 
> Regards,
> 
> Dominic
> 
You are right, Dominic!  By my definition your experience with ARM
pretty much describes a "closed" standard.  If that is the current
situation regarding RDI from, then I am completely wrong in calling it
an "open" standard.

That does raise some interesting questions though!  How did twentyone
get it working so well for H-JTAG?  It works very well with all the
debuggers that I have tried that claimed RDI support.  There are also
a number of other high priced commercial debuggers in existance that
support RDI, when you do a Google on RDI. SDT2.51, Keil, and IAR are
the only systems that I have personally used RDI with.  I've also used
 ARM ADS1.2, but I used Trace32 instead of an RDI debugger with that.

Anyway, I apologize for classifying RDI as an "open" interface if it
is as "closed" as it was to you, Dominic.

-- Dave

Hello!

I solved "heap problems" with stdlib's malloc(); So far it's fairly OK...

Now I need some help with real time sensor signal transport over some 
PHY layer (either wireless or wired). Importance is efficiency (smallest 
protocol overhead with maximum payload) and "real-time-ness". That means 
if I sample x(t1), x(t2)... x(tn), I would like to reproduce x(t1+T), 
x(t2+T)... x(tn+T), where T is shortest possible delay. Sampling is 
1ks/s at N channels with 16 bits, where N is 1...8.

Are there some standard protocols or implementations for "streaming 
sensor signals"? I looked for  Real Time Streaming Protocol but it's 
really heavy weight category for sensor applications.

MCU is LPC213x.

Thans!


Marko

--- In lpc2000@yahoogroups.com, "derbaier" <dershu@s...> wrote:

I understand RDI to be the name of the API used by the Segger Jlink
DLL on Windows, and not the name of any low-level chip functions?

As I understand it, the chip's module is called EmbeddedICE and it
doesn't "speak RDI" natively.

If I'm right, then Arm would have no business giving away trade
secrets developed and owned by Segger.

Eric

Sorry folks,
    I didn't mean to start a flame war about open / closed interfaces. My comment was 
meant to imply that (afaik) the Keil uLink is only listed as compatible with Keil software, 
whereas JLink is supported by Rowley and IAR (unless Segger JLink is not the same as IAR 
JLink). As long as Keil software does all I want, this is not a problem for me.

Thanks to Tim Chua (embeddedhub) for pointing out that a wiggler will be enough for me 
to evaluate the other packages. I have ordered the Olimex one from mivation at the 
"throwaway" price of GBP 15. If I decide to move to a different package, I will buy an 
appropriate USB JTAG interface - it won't make much difference in speed but I will not be 
constrained by the short cable limit on wigglers.

Regards,
Danish

--- In lpc2000@yahoogroups.com, "dr_danish_ali" <danish@g...> wrote:

> Two points that cause me to question my current loyalty to Keil are
> the poor performance of its compiler in some recently-posted
> benchmarks, and the (apparently) closed nature of its jtag interface.

Hi Danish,

There is no limitation with the short cable. You could always get a 
DB25 M/F cable to extend the connection btw ARM-JTAG and your PC. 

ARM-JTAG works well with CrossWorks. You could start working on it 
without any setting. As for the IAR, you may follow the environment 
setup given by Olimex support: http://www.sparkfun.com/cgi-
bin/phpbb/viewtopic.php?t=3D2129. 

Enjoy the fun. :)

Regards,
Tim Chua
http://www.embeddedhub.com

--- In lpc2000@yahoogroups.com, "dr_danish_ali" <danish@g...> wrote:
>
> Sorry folks,
>     I didn't mean to start a flame war about open / closed 
interfaces. My comment was 
> meant to imply that (afaik) the Keil uLink is only listed as 
compatible with Keil software, 
> whereas JLink is supported by Rowley and IAR (unless Segger JLink 
is not the same as IAR 
> JLink). As long as Keil software does all I want, this is not a 
problem for me.
> 
> Thanks to Tim Chua (embeddedhub) for pointing out that a wiggler 
will be enough for me 
> to evaluate the other packages. I have ordered the Olimex one from 
mivation at the 
> "throwaway" price of GBP 15. If I decide to move to a different 
package, I will buy an 
> appropriate USB JTAG interface - it won't make much difference in 
speed but I will not be 
> constrained by the short cable limit on wigglers.
> 
> Regards,
> Danish
> 
> --- In lpc2000@yahoogroups.com, "dr_danish_ali" <danish@g...> 
wrote:
> > Two points that cause me to question my current loyalty to Keil 
are
> > the poor performance of its compiler in some recently-posted
> > benchmarks, and the (apparently) closed nature of its jtag 
interface.
>

I've seen limited info posted on this, so for reference:


The RDI 1.5.1 header and library files are available under GNU here:
http://www.armdevzone.com/registered/RDIDownload/

Referenced on this page:
"A complete RDI 1.5.1 development package is available to ARM Licensees
(semiconductor partners) and DevZone 3rd party subscribers, including the
header files, libraries, specification, FAQ and example code."

I'm not sure how aged this statement is.

Registering is free:
http://www.armdevzone.com/open/register?OpenDocument

If you register you get access to this limited document:
RDI_GettingStarted.pdf (RDI-0057-CUST-ESPC-A)


The same header files, but no registration required:
http://www.arm.com/support/downloads/info/5570.html


Referenced in ARM document RDI-0057-CUST-ESPC-A:
Version 1.5 of RDI and WinRDI is defined in RDI-0003-CUST-ESPC.
Version 1.0 of RDI is defined in ARM DUI 0041B, the ARM SDT Version 2.11
Reference Guide.

ARM DUI 0041B:
http://infoeng.ee.ic.ac.uk/~gac1/Architecture/refman2v2.pdf

ADP - Angel Debug Protocol:
http://www.arm.com/pdfs/ADP_ARM_DUI0053D.pdf

RDP - Remote Debugger Protocol:
http://www.arm.com/pdfs/DAI0039B_demon_rdp.pdf



Joel

Hello Joel,

thanks for the information you dug out. I believe there would be enough 
information publicly available to build an RDI compatible interface, but I'm 
not sure if it's legally possible to use this in an open source product.

The RDI headers required to build a GDB multi-ice server are GPL, but the 
libraries that come with the headers are only available in an object format. 
The redhat multi-ice-gdb-server sources (with a GPL notice in the sources) 
also contain one of these libraries, and link it. 
Codesourcery's toolchain includes an "rdi-stub" which seems to serve the same 
purpose as the multi-ice-gdb-server. The rdi-stub.c's license notice says 
"license to be decided".
There are a few other sources of information available, including RDI skeleton 
code, but the code lacks a license note, and it is unclear how the 
information used to write it was gained.

From my understanding, using any of this is at least a legal grey zone.

The Angel debug protocol might be easier to support. There's publicly 
available documentation, and the official GDB sources already contain support 
for this protocol, so it's only a matter of implementing what this code 
expects to talk to.

Regards,

Dominic

On Saturday 21 January 2006 10:56, Joel Winarske wrote:
> I've seen limited info posted on this, so for reference:
>
>
> The RDI 1.5.1 header and library files are available under GNU here:
> http://www.armdevzone.com/registered/RDIDownload/
>
> Referenced on this page:
> "A complete RDI 1.5.1 development package is available to ARM Licensees
> (semiconductor partners) and DevZone 3rd party subscribers, including the
> header files, libraries, specification, FAQ and example code."
>
> I'm not sure how aged this statement is.
>
> Registering is free:
> http://www.armdevzone.com/open/register?OpenDocument
>
> If you register you get access to this limited document:
> RDI_GettingStarted.pdf (RDI-0057-CUST-ESPC-A)
>
>
> The same header files, but no registration required:
> http://www.arm.com/support/downloads/info/5570.html
>
>
> Referenced in ARM document RDI-0057-CUST-ESPC-A:
> Version 1.5 of RDI and WinRDI is defined in RDI-0003-CUST-ESPC.
> Version 1.0 of RDI is defined in ARM DUI 0041B, the ARM SDT Version 2.11
> Reference Guide.
>
> ARM DUI 0041B:
> http://infoeng.ee.ic.ac.uk/~gac1/Architecture/refman2v2.pdf
>
> ADP - Angel Debug Protocol:
> http://www.arm.com/pdfs/ADP_ARM_DUI0053D.pdf
>
> RDP - Remote Debugger Protocol:
> http://www.arm.com/pdfs/DAI0039B_demon_rdp.pdf
>
>
>
> Joel

Eric, 

> I understand RDI to be the name of the API used by the Segger Jlink
> DLL on Windows, and not the name of any low-level chip functions?

RDI is an interface specification from software (e.g. debuggers) to
hardware (J-Link, MultiICE, and so on).  As such, it is possible to
write software that works with any hardware debugger or simulator that
has an RDI interface.  Similarly, it is possible to have hardware work
with any RDI-enabled debugger/flasher/whatever.

> As I understand it, the chip's module is called EmbeddedICE and it
> doesn't "speak RDI" natively.

Correct.

> If I'm right, then Arm would have no business giving away trade
> secrets developed and owned by Segger.

RDI is an ARM specification, Segger has an implementation of the RDI
interface for their J-Link.

--
Paul Curtis, Rowley Associates Ltd  http://www.rowley.co.uk
CrossWorks for MSP430, ARM, AVR and now MAXQ processors

Hello Dave,

On Thursday 19 January 2006 20:52, derbaier wrote:
> You are right, Dominic!  By my definition your experience with ARM
> pretty much describes a "closed" standard.  If that is the current
> situation regarding RDI from, then I am completely wrong in calling it
> an "open" standard.
>
> That does raise some interesting questions though!  How did twentyone
> get it working so well for H-JTAG?  It works very well with all the
> debuggers that I have tried that claimed RDI support.  There are also
> a number of other high priced commercial debuggers in existance that
> support RDI, when you do a Google on RDI. SDT2.51, Keil, and IAR are
> the only systems that I have personally used RDI with.  I've also used
>  ARM ADS1.2, but I used Trace32 instead of an RDI debugger with that.
>
> Anyway, I apologize for classifying RDI as an "open" interface if it
> is as "closed" as it was to you, Dominic.
>
> -- Dave

There is enough information publicly available that would allow you to support 
RDI, but much of this raises legal questions. H-JTAG is different in that it 
isn't open source - if ARM only offers the RDI specs under an NDA (or some 
restrictive license that prohibits you to disclose the contained 
information), it isn't possible to use it in an open source project, but it 
may still be possible to use it in "free as in beer" software.

The fact that OpenOCD is open source has many advantages:
- if I should ever stop working on it, anyone else can continue this work
- you can use a different cable layout, just add a new cable definition
- you can add additional signals like RTCK
- I'm currently preparing support for cfi flashes using the Intel command set, 
but everyone can add support for the flash he's using
...

That's the freedom to use an open project for any purpose you want. The 
drawback is that it's difficult to support closed standards.

Regards,

Dominic

You can also get the free H-JTAG from:
                    http://twentyone.blogchina.com
That will allow your Wiggler to work with all of the Windows debuggers
that supports RDI. H-JTAG even works well with ARM's own older
debugger that was included in SDT2.51

The Wiggler can be installed at the end of a 25 pin DB25 extension
cable, if you need more length.  It would be best to use the shortest
enxtension cable that works, because the cable can affect signal
quality. Working with an IBM T23 laptop, the Wiggler works great
installed directly on the laptop's parallel port connector.

-- Dave


--- In lpc2000@yahoogroups.com, "dr_danish_ali" <danish@g...> wrote:
>
> Sorry folks,
>     I didn't mean to start a flame war about open / closed
interfaces. My comment was 
> meant to imply that (afaik) the Keil uLink is only listed as
compatible with Keil software, 
> whereas JLink is supported by Rowley and IAR (unless Segger JLink is
not the same as IAR 
> JLink). As long as Keil software does all I want, this is not a
problem for me.
> 
> Thanks to Tim Chua (embeddedhub) for pointing out that a wiggler
will be enough for me 
> to evaluate the other packages. I have ordered the Olimex one from
mivation at the 
> "throwaway" price of GBP 15. If I decide to move to a different
package, I will buy an 
> appropriate USB JTAG interface - it won't make much difference in
speed but I will not be 

> constrained by the short cable limit on wigglers.
> 
> Regards,
> Danish
> 
> --- In lpc2000@yahoogroups.com, "dr_danish_ali" <danish@g...> wrote:
> > Two points that cause me to question my current loyalty to Keil are
> > the poor performance of its compiler in some recently-posted
> > benchmarks, and the (apparently) closed nature of its jtag interface.
>

Segger did not create RDI, it was developed by arm.
It is a pity it is closed, especially as the previous protocol ADP
(Angel) is classed as open.

Regards
Spen

--- In lpc2000@yahoogroups.com, "Eric Engler" <englere.geo@y...> wrote:

>
> --- In lpc2000@yahoogroups.com, "derbaier" <dershu@s...> wrote:
> 
> I understand RDI to be the name of the API used by the Segger Jlink
> DLL on Windows, and not the name of any low-level chip functions?
> 
> As I understand it, the chip's module is called EmbeddedICE and it
> doesn't "speak RDI" natively.
> 
> If I'm right, then Arm would have no business giving away trade
> secrets developed and owned by Segger.
> 
> Eric
>

--- In lpc2000@yahoogroups.com, "ntfreak2000" <ntfreak2@h...> wrote:
>
> Segger did not create RDI, it was developed by arm.
> It is a pity it is closed, especially as the previous protocol ADP
> (Angel) is classed as open.
> 
> Regards
> Spen
> 

Here is a statement from ARM concerning RDI at
         http://www.arm.com/devzone

********************QUOTE*******************************************
Access to the Remote Debug Interface

The Remote Debug Interface (RDI) has for ten years served as a useful
and widely adopted interface between debuggers and debug target 
(simulators, emulators and monitors) for the ARM architecture. If
you require access to the specification, please contact 
support@... giving details of what you wish to use the 
specification for.

If you simply require the RDI header files necessary for building 
multi-ice-gdb-server, then these can be downloaded from: 
http://www.arm.com/support/downloads/multi-ice.html
*********************END QUOTE**************************************

That statement does not sound like they want to license it, but it
also looks like they do not intend for the specification to be freely
available either.     :-(

So I was sure wrong about it being an open standard!

-- Dave

An update to the comment Michael Johnson made below about
Crossworks (I'm including my question as well to keep things
in context even though it makes for a long post)

Although the hardware JTAG interface might support
display/control of peripheral registers, the software ARM
simulator does NOT include such capability :-(

To quote the Rowley helpdesk:
>The ARM simulator does not simulate the peripherals of an LPC2138.
>The next release of the software will simulate the memory system
>of many popular ARM chips, but full device simulation isn't going to
>happen any time soon.

In the Keil environment, the software ARM simulator has
facilities for code execution coverage (when ensuring all
possible code flows have been excercised) and precise
instruction timing.
Built-in peropherals are simulated.
And there's a control language to allow one to emulate the
external hardware.

When my wiggler arrives I'll be able to carry on evaluating
Crossworks.

Regards,
Danish 
--- In lpc2000@yahoogroups.com, Michael Johnson <mpj@r...> wrote:

>
> dr_danish_ali wrote:
> 
> >Yes I know the issue of IDE choice is often discussed, but please bear
> >with me on this.
> >I'm a relative newbie with Philips lpc2xxx, but reasonably familiar
> >with PIC microcontrollers. So far I have been playing round with the
> >demo (16k limit) of the Keil uVision IDE + their jtag, and I am coming
> >to the stage when I have to pay real money for a full IDE / compiler /
> >debug suite to produce commercial code.
> >
> >Two points that cause me to question my current loyalty to Keil are
> >the poor performance of its compiler in some recently-posted
> >benchmarks, and the (apparently) closed nature of its jtag interface.
> >There is also the active support given to this list by those at Rowley.
> >
> >But a feature of Keil which I do not want to lose is their debug
> >support for on-chip peripherals. By peripheral I mean (for example)
> >the Vector Interrupt Controller, the I2C hardware etc. The Keil
> >debugger has summary windows showing the state of each peripheral, and
> >allows you to change the peripheral registers without needing to look
> >up how the peripheral register is mapped in memory or which bit
> >corresponds to a given flag.
> >
> >So my question is: Do other debugging environments have support for
> >on-chip peripherals? Either built-in or provided by third-party? I
> >would like an answer for both Rowley and IAR, not necessarily from the
> >same person.
> >  
> >
> Hi Danish,
> 
> CrossWorks For ARM supports the display of memory mapped peripheral 
> registers.
> 
> Regards
> Michael

Danish, 

> An update to the comment Michael Johnson made below about
> Crossworks (I'm including my question as well to keep things
> in context even though it makes for a long post)
> 
> Although the hardware JTAG interface might support
> display/control of peripheral registers, the software ARM
> simulator does NOT include such capability :-(
> 
> To quote the Rowley helpdesk:
> >The ARM simulator does not simulate the peripherals of an LPC2138.
> >The next release of the software will simulate the memory system
> >of many popular ARM chips, but full device simulation isn't going to
> >happen any time soon.

Yes, I wrote that.

> In the Keil environment, the software ARM simulator has
> facilities for code execution coverage (when ensuring all
> possible code flows have been excercised) 

No--this is simple code coverage and *does not* show that all possible
paths have been exercised.  That is a *big* problem, one that is well
beyond any current dynamic technology.  You need static analysis in
order to do this.

> Built-in peropherals are simulated.
> And there's a control language to allow one to emulate the
> external hardware.

...but from recent comments, the 2103 isn't fully simulated...  I'm not
sure device simulation is a good place to spend your software tokens.

--
Paul Curtis, Rowley Associates Ltd  http://www.rowley.co.uk
CrossWorks for MSP430, ARM, AVR and now MAXQ processors