Reply by Al Clark ●February 3, 20142014-02-03
Rob Doyle <radioengr@gmail.com> wrote in
news:lcnatj$q9o$1@speranza.aioe.org: 


> On 2/2/2014 9:20 PM, Al Clark wrote:
>> I'm not sure that having all the JTAG details would really
>> be that helpful. They were published for the SHARC for the
>> 2106x and 2116x. The only people I know that tried to take
>> advantage of it was Mike Rosing, an old compdsp'er and his
>> brother, whose name escapes me now. They made a product
>> called Beastrider which I resold for awhile.
>>
>> The hardware interface is really not that special for any
>> JTAG device. The real effort is good integration with the
>> dev tools. I don't think it should be considered much
>> different than a compiler or linker from this perspective.
>>
>> Keep in mind, I am talking about the proprietary
>> extensions that ADI and most other manufacturers use to
>> support emulation. The original purpose of JTAG was for
>> boundary scan testing which is documented by ADI.
>>
>> I think the original poster was actually complaining that
>> ADI wasn't sharing schematics of their debug agent (on
>> board ICE module). It is true that the specifics of the
>> JTAG extensions are not published.
>>
>> When we decided to build our dspFlash programmer, I
>> thought it would be easy. It has the worst dev cost versus
>> return of any of our standard products. The catch is that
>> there are DSP variations for different targets and way too
>> many flash variations. We theoretically support hundreds
>> of thousands of possible combinations, most which we have
>> never been able to test. We sometimes fall victim to bad
>> signal integrity on the target boards or the adapters that
>> are used on test fixtures. 
>>
>> So if you are thinking of building your own tools, you are
>> really doing it as a labor of love, it is MUCH, MUCH
>> cheaper to buy tools.
>>
>> I think maybe the reason ADI stopped with the details is
>> to avoid relatively useless tech support issues that do
>> not facilitate the sell of cheaps which is how they make
>> their money.
>>
>> No doubt, the other processor companies have similar
>> issues. 
>>
>> Al Clark
>> www.danvillesignal.com
> 
> I mostly don't disagree with what you've said...
> 
> ... but there are times when I'd like to integrate the JTAG
> programmer and in-circuit emulation onto the target
> hardware. 
> 


You might like our dspblok products. We have "ICE" versions 
that are pin compatible.



> In my mind, I separate the JTAG programming hardware which
> can be generic and inexpensive from the programming
> software. I can do that for other manufacturers devices.
> 
> In the end, ADI makes their money selling chips. But you
> can't do that without /decent/ tools.  IOW selling tools
> will never make you money - *on the tools*.


That is my view also.




> 
> I think I will disagree with the tech support issue you've
> raised. Many companies have been rewarded by supporting the
> open source community. It is an issue that can be
> managed... 
> 
> Rob.
> 
> 


With respect to the support question, I don't actually know 
that this is their reasoning. I just know that taking 
advantage of the JTAG port is much more work than it would 
seem at first glance.

If you need more info about the specific JTAG registers, you 
might just ask them. I don't know what they will say.

Al




---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com
Reply by Rob Doyle ●February 3, 20142014-02-03
On 2/2/2014 9:20 PM, Al Clark wrote:

> I'm not sure that having all the JTAG details would really be
> that helpful. They were published for the SHARC for the 2106x
> and 2116x. The only people I know that tried to take advantage
> of it was Mike Rosing, an old compdsp'er and his brother,
> whose name escapes me now. They made a product called
> Beastrider which I resold for awhile.
>
> The hardware interface is really not that special for any JTAG
> device. The real effort is good integration with the dev
> tools. I don't think it should be considered much different
> than a compiler or linker from this perspective.
>
> Keep in mind, I am talking about the proprietary extensions
> that ADI and most other manufacturers use to support
> emulation. The original purpose of JTAG was for boundary scan
> testing which is documented by ADI.
>
> I think the original poster was actually complaining that ADI
> wasn't sharing schematics of their debug agent (on board ICE
> module). It is true that the specifics of the JTAG extensions
> are not published.
>
> When we decided to build our dspFlash programmer, I thought it
> would be easy. It has the worst dev cost versus return of any
> of our standard products. The catch is that there are DSP
> variations for different targets and way too many flash
> variations. We theoretically support hundreds of thousands of
> possible combinations, most which we have never been able to
> test. We sometimes fall victim to bad signal integrity on the
> target boards or the adapters that are used on test fixtures.
>
> So if you are thinking of building your own tools, you are
> really doing it as a labor of love, it is MUCH, MUCH cheaper
> to buy tools.
>
> I think maybe the reason ADI stopped with the details is to
> avoid relatively useless tech support issues that do not
> facilitate the sell of cheaps which is how they make their
> money.
>
> No doubt, the other processor companies have similar issues.
>
> Al Clark
> www.danvillesignal.com


I mostly don't disagree with what you've said...

... but there are times when I'd like to integrate the JTAG programmer
and in-circuit emulation onto the target hardware.

In my mind, I separate the JTAG programming hardware which can be
generic and inexpensive from the programming software. I can do that for
other manufacturers devices.

In the end, ADI makes their money selling chips. But you can't do that
without /decent/ tools.  IOW selling tools will never make you money - 
*on the tools*.

I think I will disagree with the tech support issue you've raised. Many
companies have been rewarded by supporting the open source community. It
is an issue that can be managed...

Rob.
Reply by Al Clark ●February 3, 20142014-02-03
I'm not sure that having all the JTAG details would really be 
that helpful. They were published for the SHARC for the 2106x 
and 2116x. The only people I know that tried to take advantage 
of it was Mike Rosing, an old compdsp'er and his brother, 
whose name escapes me now. They made a product called 
Beastrider which I resold for awhile.

The hardware interface is really not that special for any JTAG 
device. The real effort is good integration with the dev 
tools. I don't think it should be considered much different 
than a compiler or linker from this perspective.

Keep in mind, I am talking about the proprietary extensions 
that ADI and most other manufacturers use to support 
emulation. The original purpose of JTAG was for boundary scan 
testing which is documented by ADI.

I think the original poster was actually complaining that ADI 
wasn't sharing schematics of their debug agent (on board ICE 
module). It is true that the specifics of the JTAG extensions 
are not published. 

When we decided to build our dspFlash programmer, I thought it 
would be easy. It has the worst dev cost versus return of any 
of our standard products. The catch is that there are DSP 
variations for different targets and way too many flash 
variations. We theoretically support hundreds of thousands of 
possible combinations, most which we have never been able to 
test. We sometimes fall victim to bad signal integrity on the 
target boards or the adapters that are used on test fixtures.

So if you are thinking of building your own tools, you are 
really doing it as a labor of love, it is MUCH, MUCH cheaper 
to buy tools.

I think maybe the reason ADI stopped with the details is to 
avoid relatively useless tech support issues that do not 
facilitate the sell of cheaps which is how they make their 
money. 

No doubt, the other processor companies have similar issues.

Al Clark
www.danvillesignal.com

 










robert bristow-johnson <rbj@audioimagination.com> wrote in
news:lcm0kq$fj0$1@dont-email.me: 


> On 2/2/14 12:38 PM, Al Clark wrote:
>> Randy Yates<yates@digitalsignallabs.com>  wrote in
>> news:87r47lr8ux.fsf@digitalsignallabs.com:
>>
>>> eric.jacobsen@ieee.org (Eric Jacobsen) writes:
>>>
>>>> On Sat, 01 Feb 2014 21:28:53 -0500, robert
>>>> bristow-johnson <rbj@audioimagination.com>  wrote:
>>>>
>>>>> On 2/1/14 1:42 PM, Al Clark wrote:
>>>>>> I could have jumped in earlier but I have been
>>>>>> traveling all week.
>>>>>>
>>>>> you a busy dude.
>>>>>
>>>>>> You are correct that ADI does not share JTAG ICE (or
>>>>>> debug agent) schematics.
>>>>>> ...
>>>>>> This is all proprietary to ADI, so no I won't
>>>>>> share any of the details.
>>>>>
>>>>> ya know what seems odd to me, Al.  it seems to me that,
>>>>> if ADI wants to sell chips, they would make the whole
>>>>> SHArC JTAG protocol thing public.
>>>>>
>>>>> i don't get why not.
>>>>
>>>> Security.
>>>
>>> In other words, they DON'T want to sell (just) chips.
>>> They like selling the tools, too.
>>>
>>> TI is doing a smart thing in offering their Code Composer
>>> Studio for a mere $800, while other folks' IDEs like
>>> ADI's VisualDSP and Freescale's Code Warrior are
>>> $3000-$5000. That and TI's broad product base is enough
>>> to design-in their products just to avoid coughing up
>>> these fees. 
>>
>> ADI's newest tools, CrossCore Studio supports Blackfin& 
>> SHARC and is $1000.
>>
>> I don't know all the reasoning with the JTAG strategy. I
>> can tell you that making tools as a third party is not a
>> particularly great business decision. The market is too
>> small. 
>>
> 
> tools (like assembler, compiler, linker, library) are one
> thing (they cost money, so expect to be charged for it),
> but communications/control protocol (which is how i
> understand JTAG) is another thing.  if you build and sell a
> chip, it is to your customers' best interest to be able to
> communicate with and control every feature you put into
> that chip. if you have on-board flash, you should tell your
> customers exactly how to burn a program or boot code into
> that flash memory.  if you have the ability to control
> execution, start/stop, examine/change registers and memory,
> set/clear breakpoints, single-step, etc.  all of that 
> functionality should be readily available (which it isn't,
> if you keep the protocol secret) to developers using the
> chip that you hope to sell them.
> 
> so i still don't get it.
> 
> 



---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com
Reply by Eric Jacobsen ●February 2, 20142014-02-02
On Sun, 02 Feb 2014 18:25:52 -0500, Randy Yates
<yates@digitalsignallabs.com> wrote:


>eric.jacobsen@ieee.org (Eric Jacobsen) writes:
>
>> On Sun, 02 Feb 2014 07:34:46 -0500, Randy Yates
>> <yates@digitalsignallabs.com> wrote:
>>
>>>eric.jacobsen@ieee.org (Eric Jacobsen) writes:
>>>
>>>> On Sat, 01 Feb 2014 21:28:53 -0500, robert bristow-johnson
>>>> <rbj@audioimagination.com> wrote:
>>>>
>>>>>On 2/1/14 1:42 PM, Al Clark wrote:
>>>>>> I could have jumped in earlier but I have been traveling all
>>>>>> week.
>>>>>>
>>>>>you a busy dude.
>>>>>
>>>>>> You are correct that ADI does not share JTAG ICE (or debug
>>>>>> agent) schematics.
>>>>> > ...
>>>>>> This is all proprietary to ADI, so no I won't
>>>>>> share any of the details.
>>>>>
>>>>>ya know what seems odd to me, Al.  it seems to me that, if ADI wants to 
>>>>>sell chips, they would make the whole SHArC JTAG protocol thing public.
>>>>>
>>>>>i don't get why not.
>>>>
>>>> Security.
>>>
>>>In other words, they DON'T want to sell (just) chips. They like selling
>>>the tools, too.
>>
>> No, I really mean security.   For systems where security is important
>> the JTAG interface on a processor provides potential access to the
>> code and possibly the processor state.  You don't want that to be
>> possible on a secure system, and not publishing any details helps.
>> ADI is probably smart enough to not want to close the door on markets
>> where security is important, especially if any competitors do.
>
>Gotcha. 
>
>But wouldn't it be possible to put security in place even with knowledge
>of the JTAG interface?


Every door you can keep closed enhances security, and if you don't
want your code cracked or pirated, minimizing access to it is
advantageous.   If you have to choose platforms between one that has
kept the doors open and one that has made an effort to keep them
closed, it's not a hard choice when security is important to you.

Every little bit helps.


Eric Jacobsen
Anchor Hill Communications
http://www.anchorhill.com
Reply by robert bristow-johnson ●February 2, 20142014-02-02
On 2/2/14 6:25 PM, Randy Yates wrote:

> eric.jacobsen@ieee.org (Eric Jacobsen) writes:
>
>> On Sun, 02 Feb 2014 07:34:46 -0500, Randy Yates
>> <yates@digitalsignallabs.com>  wrote:
>>
>>> eric.jacobsen@ieee.org (Eric Jacobsen) writes:
>>>
>>>> On Sat, 01 Feb 2014 21:28:53 -0500, robert bristow-johnson
>>>> <rbj@audioimagination.com>  wrote:
>>>>
>>>>> On 2/1/14 1:42 PM, Al Clark wrote:
>>>>>> I could have jumped in earlier but I have been traveling all
>>>>>> week.
>>>>>>
>>>>> you a busy dude.
>>>>>
>>>>>> You are correct that ADI does not share JTAG ICE (or debug
>>>>>> agent) schematics.
>>>>>> ...
>>>>>> This is all proprietary to ADI, so no I won't
>>>>>> share any of the details.
>>>>>
>>>>> ya know what seems odd to me, Al.  it seems to me that, if ADI wants to
>>>>> sell chips, they would make the whole SHArC JTAG protocol thing public.
>>>>>
>>>>> i don't get why not.
>>>>
>>>> Security.
>>>
>>> In other words, they DON'T want to sell (just) chips. They like selling
>>> the tools, too.
>>
>> No, I really mean security.   For systems where security is important
>> the JTAG interface on a processor provides potential access to the
>> code and possibly the processor state.  You don't want that to be
>> possible on a secure system, and not publishing any details helps.
>> ADI is probably smart enough to not want to close the door on markets
>> where security is important, especially if any competitors do.
>
> Gotcha.
>
> But wouldn't it be possible to put security in place even with knowledge
> of the JTAG interface?


yeah, like isn't public-key encryption open sourced.  so, if you're 
trying to break a message, at least for the first layer you know 
everything about decrypting it except for the actual private key.

now, isn't there a state that the chips (with some non-volatile memory) 
can be sold in so that anyone can get in.  and then set some word in 
memory that is the public key that causes all I/O with the debugger to 
be scrambled.  only an emulator tool with the private key would be able 
to take control of the chip for debugging.

at least put in a single set-only bit that disables the whole JTAG for 
production models.

i mean, relying on state secrets seems to be the least secure.  all i 
need to do is pay Al a few bucks and i'll know all of the ADI state 
secrets.  at least those regarding the SHArC JTAG whatever secret sauce.

:-o

or maybe he'll change his mind and become Al Snowden and publish in 
WikiWhatever the whole thing.  for the good of humankind.

-- 

r b-j                  rbj@audioimagination.com

"Imagination is more important than knowledge."
Reply by robert bristow-johnson ●February 2, 20142014-02-02
On 2/2/14 5:32 PM, Rob Doyle wrote:

> On 2/2/2014 10:52 AM, robert bristow-johnson wrote:
>> On 2/2/14 12:38 PM, Al Clark wrote:
>>> Randy Yates<yates@digitalsignallabs.com> wrote in
>>> news:87r47lr8ux.fsf@digitalsignallabs.com:
>>>
>>>> eric.jacobsen@ieee.org (Eric Jacobsen) writes:
>>>>
>>>>> On Sat, 01 Feb 2014 21:28:53 -0500, robert bristow-johnson
>>>>> <rbj@audioimagination.com> wrote:
>>>>>
>>>>>> On 2/1/14 1:42 PM, Al Clark wrote:
>>>>>>> I could have jumped in earlier but I have been traveling
>>>>>>> all week.
>>>>>>>
>>>>>> you a busy dude.
>>>>>>
>>>>>>> You are correct that ADI does not share JTAG ICE (or
>>>>>>> debug agent) schematics.
>>>>>>> ...
>>>>>>> This is all proprietary to ADI, so no I won't
>>>>>>> share any of the details.
>>>>>>
>>>>>> ya know what seems odd to me, Al. it seems to me that, if
>>>>>> ADI wants to sell chips, they would make the whole SHArC
>>>>>> JTAG protocol thing public.
>>>>>>
>>>>>> i don't get why not.
>>>>>
>>>>> Security.
>>>>
>>>> In other words, they DON'T want to sell (just) chips. They
>>>> like selling the tools, too.
>>>>
>>>> TI is doing a smart thing in offering their Code Composer
>>>> Studio for a mere $800, while other folks' IDEs like ADI's
>>>> VisualDSP and Freescale's Code Warrior are $3000-$5000.
>>>> That and TI's broad product base is enough to design-in
>>>> their products just to avoid coughing up these fees.
>>>
>>> ADI's newest tools, CrossCore Studio supports Blackfin& SHARC
>>> and is $1000.
>>>
>>> I don't know all the reasoning with the JTAG strategy. I can
>>> tell you that making tools as a third party is not a
>>> particularly great business decision. The market is too small.
>>>
>>
>> tools (like assembler, compiler, linker, library) are one thing (they
>> cost money, so expect to be charged for it), but communications/control
>> protocol (which is how i understand JTAG) is another thing. if you
>> build and sell a chip, it is to your customers' best interest to be able
>> to communicate with and control every feature you put into that chip. if
>> you have on-board flash, you should tell your customers exactly how to
>> burn a program or boot code into that flash memory. if you have the
>> ability to control execution, start/stop, examine/change registers and
>> memory, set/clear breakpoints, single-step, etc. all of that
>> functionality should be readily available (which it isn't, if you keep
>> the protocol secret) to developers using the chip that you hope to sell
>> them.
>>
>> so i still don't get it.
>>
>
> I've used openocd for Texas Instruments processors and others - it also
> supports some FPGAs.
>
> http://openocd.sourceforge.net/
>
> There are plenty of very inexpensive open source JTAG hardware
> programming solutions.
>
> I suspect that all ADI would need to do is release their JTAG interface
> specification and the open source community would provide support.
>
> My latest project has USB-based JTAG programming onboard.
>
> Pity.
>


see guys, i'm not so dum.  we roberts'es just have good taste.


-- 

r b-j                  rbj@audioimagination.com

"Imagination is more important than knowledge."
Reply by Randy Yates ●February 2, 20142014-02-02
eric.jacobsen@ieee.org (Eric Jacobsen) writes:


> On Sun, 02 Feb 2014 07:34:46 -0500, Randy Yates
> <yates@digitalsignallabs.com> wrote:
>
>>eric.jacobsen@ieee.org (Eric Jacobsen) writes:
>>
>>> On Sat, 01 Feb 2014 21:28:53 -0500, robert bristow-johnson
>>> <rbj@audioimagination.com> wrote:
>>>
>>>>On 2/1/14 1:42 PM, Al Clark wrote:
>>>>> I could have jumped in earlier but I have been traveling all
>>>>> week.
>>>>>
>>>>you a busy dude.
>>>>
>>>>> You are correct that ADI does not share JTAG ICE (or debug
>>>>> agent) schematics.
>>>> > ...
>>>>> This is all proprietary to ADI, so no I won't
>>>>> share any of the details.
>>>>
>>>>ya know what seems odd to me, Al.  it seems to me that, if ADI wants to 
>>>>sell chips, they would make the whole SHArC JTAG protocol thing public.
>>>>
>>>>i don't get why not.
>>>
>>> Security.
>>
>>In other words, they DON'T want to sell (just) chips. They like selling
>>the tools, too.
>
> No, I really mean security.   For systems where security is important
> the JTAG interface on a processor provides potential access to the
> code and possibly the processor state.  You don't want that to be
> possible on a secure system, and not publishing any details helps.
> ADI is probably smart enough to not want to close the door on markets
> where security is important, especially if any competitors do.


Gotcha. 

But wouldn't it be possible to put security in place even with knowledge
of the JTAG interface?
-- 
Randy Yates
Digital Signal Labs
http://www.digitalsignallabs.com
Reply by Rob Doyle ●February 2, 20142014-02-02
On 2/2/2014 10:52 AM, robert bristow-johnson wrote:

> On 2/2/14 12:38 PM, Al Clark wrote:
>> Randy Yates<yates@digitalsignallabs.com>  wrote in
>> news:87r47lr8ux.fsf@digitalsignallabs.com:
>>
>>> eric.jacobsen@ieee.org (Eric Jacobsen) writes:
>>>
>>>> On Sat, 01 Feb 2014 21:28:53 -0500, robert bristow-johnson
>>>> <rbj@audioimagination.com>  wrote:
>>>>
>>>>> On 2/1/14 1:42 PM, Al Clark wrote:
>>>>>> I could have jumped in earlier but I have been traveling
>>>>>> all week.
>>>>>>
>>>>> you a busy dude.
>>>>>
>>>>>> You are correct that ADI does not share JTAG ICE (or
>>>>>> debug agent) schematics.
>>>>>> ...
>>>>>> This is all proprietary to ADI, so no I won't
>>>>>> share any of the details.
>>>>>
>>>>> ya know what seems odd to me, Al.  it seems to me that, if
>>>>> ADI wants to sell chips, they would make the whole SHArC
>>>>> JTAG protocol thing public.
>>>>>
>>>>> i don't get why not.
>>>>
>>>> Security.
>>>
>>> In other words, they DON'T want to sell (just) chips. They
>>> like selling the tools, too.
>>>
>>> TI is doing a smart thing in offering their Code Composer
>>> Studio for a mere $800, while other folks' IDEs like ADI's
>>> VisualDSP and Freescale's Code Warrior are $3000-$5000.
>>> That and TI's broad product base is enough to design-in
>>> their products just to avoid coughing up these fees.
>>
>> ADI's newest tools, CrossCore Studio supports Blackfin&  SHARC
>> and is $1000.
>>
>> I don't know all the reasoning with the JTAG strategy. I can
>> tell you that making tools as a third party is not a
>> particularly great business decision. The market is too small.
>>
>
> tools (like assembler, compiler, linker, library) are one thing (they
> cost money, so expect to be charged for it), but communications/control
> protocol (which is how i understand JTAG) is another thing.  if you
> build and sell a chip, it is to your customers' best interest to be able
> to communicate with and control every feature you put into that chip. if
> you have on-board flash, you should tell your customers exactly how to
> burn a program or boot code into that flash memory.  if you have the
> ability to control execution, start/stop, examine/change registers and
> memory, set/clear breakpoints, single-step, etc.  all of that
> functionality should be readily available (which it isn't, if you keep
> the protocol secret) to developers using the chip that you hope to sell
> them.
>
> so i still don't get it.
>


I've used openocd for Texas Instruments processors and others - it also
supports some FPGAs.

http://openocd.sourceforge.net/

There are plenty of very inexpensive open source JTAG hardware
programming solutions.

I suspect that all ADI would need to do is release their JTAG interface
specification and the open source community would provide support.

My latest project has USB-based JTAG programming onboard.

Pity.

Rob.
Reply by Eric Jacobsen ●February 2, 20142014-02-02
On Sun, 02 Feb 2014 07:34:46 -0500, Randy Yates
<yates@digitalsignallabs.com> wrote:


>eric.jacobsen@ieee.org (Eric Jacobsen) writes:
>
>> On Sat, 01 Feb 2014 21:28:53 -0500, robert bristow-johnson
>> <rbj@audioimagination.com> wrote:
>>
>>>On 2/1/14 1:42 PM, Al Clark wrote:
>>>> I could have jumped in earlier but I have been traveling all
>>>> week.
>>>>
>>>you a busy dude.
>>>
>>>> You are correct that ADI does not share JTAG ICE (or debug
>>>> agent) schematics.
>>> > ...
>>>> This is all proprietary to ADI, so no I won't
>>>> share any of the details.
>>>
>>>ya know what seems odd to me, Al.  it seems to me that, if ADI wants to 
>>>sell chips, they would make the whole SHArC JTAG protocol thing public.
>>>
>>>i don't get why not.
>>
>> Security.
>
>In other words, they DON'T want to sell (just) chips. They like selling
>the tools, too.


No, I really mean security.   For systems where security is important
the JTAG interface on a processor provides potential access to the
code and possibly the processor state.  You don't want that to be
possible on a secure system, and not publishing any details helps.
ADI is probably smart enough to not want to close the door on markets
where security is important, especially if any competitors do.


>TI is doing a smart thing in offering their Code Composer Studio for a
>mere $800, while other folks' IDEs like ADI's VisualDSP and Freescale's
>Code Warrior are $3000-$5000. That and TI's broad product base is enough
>to design-in their products just to avoid coughing up these fees.
>-- 
>Randy Yates
>Digital Signal Labs
>http://www.digitalsignallabs.com


Eric Jacobsen
Anchor Hill Communications
http://www.anchorhill.com
Reply by robert bristow-johnson ●February 2, 20142014-02-02
On 2/2/14 12:38 PM, Al Clark wrote:

> Randy Yates<yates@digitalsignallabs.com>  wrote in
> news:87r47lr8ux.fsf@digitalsignallabs.com:
>
>> eric.jacobsen@ieee.org (Eric Jacobsen) writes:
>>
>>> On Sat, 01 Feb 2014 21:28:53 -0500, robert bristow-johnson
>>> <rbj@audioimagination.com>  wrote:
>>>
>>>> On 2/1/14 1:42 PM, Al Clark wrote:
>>>>> I could have jumped in earlier but I have been traveling
>>>>> all week.
>>>>>
>>>> you a busy dude.
>>>>
>>>>> You are correct that ADI does not share JTAG ICE (or
>>>>> debug agent) schematics.
>>>>> ...
>>>>> This is all proprietary to ADI, so no I won't
>>>>> share any of the details.
>>>>
>>>> ya know what seems odd to me, Al.  it seems to me that, if
>>>> ADI wants to sell chips, they would make the whole SHArC
>>>> JTAG protocol thing public.
>>>>
>>>> i don't get why not.
>>>
>>> Security.
>>
>> In other words, they DON'T want to sell (just) chips. They
>> like selling the tools, too.
>>
>> TI is doing a smart thing in offering their Code Composer
>> Studio for a mere $800, while other folks' IDEs like ADI's
>> VisualDSP and Freescale's Code Warrior are $3000-$5000.
>> That and TI's broad product base is enough to design-in
>> their products just to avoid coughing up these fees.
>
> ADI's newest tools, CrossCore Studio supports Blackfin&  SHARC
> and is $1000.
>
> I don't know all the reasoning with the JTAG strategy. I can
> tell you that making tools as a third party is not a
> particularly great business decision. The market is too small.
>


tools (like assembler, compiler, linker, library) are one thing (they 
cost money, so expect to be charged for it), but communications/control 
protocol (which is how i understand JTAG) is another thing.  if you 
build and sell a chip, it is to your customers' best interest to be able 
to communicate with and control every feature you put into that chip. 
if you have on-board flash, you should tell your customers exactly how 
to burn a program or boot code into that flash memory.  if you have the 
ability to control execution, start/stop, examine/change registers and 
memory, set/clear breakpoints, single-step, etc.  all of that 
functionality should be readily available (which it isn't, if you keep 
the protocol secret) to developers using the chip that you hope to sell 
them.

so i still don't get it.


-- 

r b-j                  rbj@audioimagination.com

"Imagination is more important than knowledge."