Hi,
> > In our experience, the USB FET is a bunch of
trouble for many
> reasons.
> > Users continue to purchase it on spec because (a) it's fairly cheap
> and (b)
> > it has a TI sticker on it.
> >
> > --
> > Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
> > CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors
>
> Which USB FET tools made by Elprotronic, SoftBaugh, etc. is preferred /
> suitable???
The Elprotronic tools are hard to fault.
> Or Rowley is updating the CrossConnect to support
SBW???
Unfortunately the hardware in the CrossConnect doesn't support SBW, it was
designed quite some time before SBW was published.
> Planning to buy one or two soon... :)
We use the USB FETs to do SBW debug. However, they still have problems and are
sometimes unreliable. The driver and DLL situation is a complete mess.
--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors
IAR vs CCE
Started by ●June 20, 2007
Reply by ●June 21, 20072007-06-21
Reply by ●June 21, 20072007-06-21
John,
> I do not normally 'lose contact' with the target with CCE. I use a PC
> that has sufficient resources to run CCE (for example 1GB RAM).
My Windows XP machine has 4GB of RAM and is an Athlon 4800 X2: the FET still
screws up when debugging using CCE. It gets pretty bad requiring the FET to
be unplugged and plugged in again, a dice with death as it sometimes results
in a blue screen.
> CCE uses a lot more PC resources than IAR for two reasons.
> 1. Eclipse is JAVA based
> 2. A version of GDB that runs with CYGWIN is used.
>
> As far as I am aware both IAR and CCE use the same MSP430 JTAG debug
> dlls.
...how wrong can you be?
--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors
> I do not normally 'lose contact' with the target with CCE. I use a PC
> that has sufficient resources to run CCE (for example 1GB RAM).
My Windows XP machine has 4GB of RAM and is an Athlon 4800 X2: the FET still
screws up when debugging using CCE. It gets pretty bad requiring the FET to
be unplugged and plugged in again, a dice with death as it sometimes results
in a blue screen.
> CCE uses a lot more PC resources than IAR for two reasons.
> 1. Eclipse is JAVA based
> 2. A version of GDB that runs with CYGWIN is used.
>
> As far as I am aware both IAR and CCE use the same MSP430 JTAG debug
> dlls.
...how wrong can you be?
--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors
Reply by ●June 21, 20072007-06-21
Here are some hints to avoid problems with CCE.
I sometimes leave CCE running overnight and can still continue to
debug in the same session.
The basic story with CCE is not to confuse it with tricks.
These hints will also help with other debuggers.
There is an hysterical attitude towards CCE that is not backed up by
my experience and does not concur with Eclipse/GDB based toolsets for
other processors for users who do not expect to have their 'hands
held'.
If you do not even have a functional program to start off with as
described below then you will not have a good experience with CCE.
I have never had a 'blue screen of death' with CCE.
My basis for asserting that as far as I know IAR and CCE use the same
JTAG debug dlls is that:
-TI makes available a set of JTAG debug dlls to toolset vendors
-My USB FET works interchangeably with both IAR and CCE
-IAR and CCE appear to have the same install program for the USB
drivers. However the versions used may be out of synch.
HINTS TO AVOID PROBLEMS
1. Make sure you have plenty of spare RAM available
2. Always ensure your MSP430 is adequately powered. Externally
powered MSP430 devices are preferable to devices that take their
power form the JTAG lines.
3. Make sure the connection cable is adequate. The shorter the better.
4. CCE always appears to single step until it reaches main. If your
code does not have a main, if main is never reached or there is a
long path to main CCE will appear to be sluggish.
5. If your MSP430 behaves unpredictably because of a reset or jumping
to a non existent interrupt handler then CCE will behave sluggishly
or appear to have lost contact.
HINTS TO RECOVER FROM PROBLEMS DUE TO MISBEHAVING PROGRAMS
1. If contact appears to be lost (because your MSP430 is poorly
powered, has reset or taken a non existent interrupt for example) and
CCE appears to be difficult to get going again try the following
- Bring up any instances of GDB in task manager and shut then down
- Shut down any program instances starting with ti_server_manager
To find these instances use Ctrl+Alt+Del, click on Task Manager,
click on Processes Tab, click on Image Name to get the process names
in alphabetical order, click on the process, click on End Process.
2. If step 1 does not work then try unplugging the USB FET but leave
it unplugged for a few seconds.
3. If step 2 does not work then leave the USB FET unplugged for
several minutes (or swap another one in)
4. Leaving the MSP430 device unpowered for several minutes has solved
some problems.
John Heenan
I sometimes leave CCE running overnight and can still continue to
debug in the same session.
The basic story with CCE is not to confuse it with tricks.
These hints will also help with other debuggers.
There is an hysterical attitude towards CCE that is not backed up by
my experience and does not concur with Eclipse/GDB based toolsets for
other processors for users who do not expect to have their 'hands
held'.
If you do not even have a functional program to start off with as
described below then you will not have a good experience with CCE.
I have never had a 'blue screen of death' with CCE.
My basis for asserting that as far as I know IAR and CCE use the same
JTAG debug dlls is that:
-TI makes available a set of JTAG debug dlls to toolset vendors
-My USB FET works interchangeably with both IAR and CCE
-IAR and CCE appear to have the same install program for the USB
drivers. However the versions used may be out of synch.
HINTS TO AVOID PROBLEMS
1. Make sure you have plenty of spare RAM available
2. Always ensure your MSP430 is adequately powered. Externally
powered MSP430 devices are preferable to devices that take their
power form the JTAG lines.
3. Make sure the connection cable is adequate. The shorter the better.
4. CCE always appears to single step until it reaches main. If your
code does not have a main, if main is never reached or there is a
long path to main CCE will appear to be sluggish.
5. If your MSP430 behaves unpredictably because of a reset or jumping
to a non existent interrupt handler then CCE will behave sluggishly
or appear to have lost contact.
HINTS TO RECOVER FROM PROBLEMS DUE TO MISBEHAVING PROGRAMS
1. If contact appears to be lost (because your MSP430 is poorly
powered, has reset or taken a non existent interrupt for example) and
CCE appears to be difficult to get going again try the following
- Bring up any instances of GDB in task manager and shut then down
- Shut down any program instances starting with ti_server_manager
To find these instances use Ctrl+Alt+Del, click on Task Manager,
click on Processes Tab, click on Image Name to get the process names
in alphabetical order, click on the process, click on End Process.
2. If step 1 does not work then try unplugging the USB FET but leave
it unplugged for a few seconds.
3. If step 2 does not work then leave the USB FET unplugged for
several minutes (or swap another one in)
4. Leaving the MSP430 device unpowered for several minutes has solved
some problems.
John Heenan
Reply by ●June 21, 20072007-06-21
John,
> There is an hysterical attitude towards CCE that is not backed up by
> my experience and does not concur with Eclipse/GDB based toolsets for
> other processors for users who do not expect to have their 'hands
> held'.
The fact you've had a good experience with CCE is fantastic. However, I
have plenty of customers that have jumped off CCE because they can't get it
to work. It's a bit hit-and-miss for me.
> If you do not even have a functional program to start off with as
> described below then you will not have a good experience with CCE.
No programs are written, from scratch, to be functional first time. It's a
fact of life.
> I have never had a 'blue screen of death' with CCE.
I didn't say that CCE caused it. I said unplugging and plugging the USB FET
causes it. This is because the drivers that TI use for the 3410 were not
written by them and the company subsequently tanked. Things may have
improved recently, I know they wanted to.
> My basis for asserting that as far as I know IAR and CCE use the same
> JTAG debug dlls is that:
> -TI makes available a set of JTAG debug dlls to toolset vendors
Sure does.
> -My USB FET works interchangeably with both IAR and CCE
That's nice.
> -IAR and CCE appear to have the same install program for the USB
> drivers. However the versions used may be out of synch.
TI's DLL requires that the USB FET be "upgraded" to make them compatible in
some instances. That's all fine and dandy until you have more than one
development environment loaded onto your machine where the two DLLs are not
identical and require different firmware--then you're nicely hosed.
--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors
> There is an hysterical attitude towards CCE that is not backed up by
> my experience and does not concur with Eclipse/GDB based toolsets for
> other processors for users who do not expect to have their 'hands
> held'.
The fact you've had a good experience with CCE is fantastic. However, I
have plenty of customers that have jumped off CCE because they can't get it
to work. It's a bit hit-and-miss for me.
> If you do not even have a functional program to start off with as
> described below then you will not have a good experience with CCE.
No programs are written, from scratch, to be functional first time. It's a
fact of life.
> I have never had a 'blue screen of death' with CCE.
I didn't say that CCE caused it. I said unplugging and plugging the USB FET
causes it. This is because the drivers that TI use for the 3410 were not
written by them and the company subsequently tanked. Things may have
improved recently, I know they wanted to.
> My basis for asserting that as far as I know IAR and CCE use the same
> JTAG debug dlls is that:
> -TI makes available a set of JTAG debug dlls to toolset vendors
Sure does.
> -My USB FET works interchangeably with both IAR and CCE
That's nice.
> -IAR and CCE appear to have the same install program for the USB
> drivers. However the versions used may be out of synch.
TI's DLL requires that the USB FET be "upgraded" to make them compatible in
some instances. That's all fine and dandy until you have more than one
development environment loaded onto your machine where the two DLLs are not
identical and require different firmware--then you're nicely hosed.
--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors
Reply by ●June 21, 20072007-06-21
Hello,
What you describe is precisely what I don't like in CCE.
This reminds me these old pre-worldwar II cars, where you
had to estimate the ignition advance (don't know the vocabulary
in english) and adjust it manually from the board.
That has nothing to do with hystery but with efficiency.
The way the IDE / emulator works is not my problem and should
never be. My problem is to work as fast as possible (i.e. with
the least possible trouble). What I expect from a compiler is
that it does its job fast, what I expect from a debugger is that
it steps when I press step instead of dying.
Usually, I have no time to leave the stuff unpowered for several
minutes everytime it does not work.
Beside this, there are some things I like in CCE better than
in IAR and CCE could gain a lot if TI ever decides to invest
some time in it. I have been waiting for more than 2 years
(to which I should add many "several minutes unplugged" states)
that things improve, they don't.
Pascal
--- In m..., "John Heenan" wrote:
>
> Here are some hints to avoid problems with CCE.
>
> I sometimes leave CCE running overnight and can still continue to
> debug in the same session.
>
> The basic story with CCE is not to confuse it with tricks.
>
> These hints will also help with other debuggers.
>
> There is an hysterical attitude towards CCE that is not backed up by
> my experience and does not concur with Eclipse/GDB based toolsets for
> other processors for users who do not expect to have their 'hands
> held'.
>
> If you do not even have a functional program to start off with as
> described below then you will not have a good experience with CCE.
>
> I have never had a 'blue screen of death' with CCE.
>
> My basis for asserting that as far as I know IAR and CCE use the same
> JTAG debug dlls is that:
> -TI makes available a set of JTAG debug dlls to toolset vendors
> -My USB FET works interchangeably with both IAR and CCE
> -IAR and CCE appear to have the same install program for the USB
> drivers. However the versions used may be out of synch.
>
> HINTS TO AVOID PROBLEMS
>
> 1. Make sure you have plenty of spare RAM available
>
> 2. Always ensure your MSP430 is adequately powered. Externally
> powered MSP430 devices are preferable to devices that take their
> power form the JTAG lines.
>
> 3. Make sure the connection cable is adequate. The shorter the better.
>
> 4. CCE always appears to single step until it reaches main. If your
> code does not have a main, if main is never reached or there is a
> long path to main CCE will appear to be sluggish.
>
> 5. If your MSP430 behaves unpredictably because of a reset or jumping
> to a non existent interrupt handler then CCE will behave sluggishly
> or appear to have lost contact.
> HINTS TO RECOVER FROM PROBLEMS DUE TO MISBEHAVING PROGRAMS
>
> 1. If contact appears to be lost (because your MSP430 is poorly
> powered, has reset or taken a non existent interrupt for example) and
> CCE appears to be difficult to get going again try the following
>
> - Bring up any instances of GDB in task manager and shut then down
> - Shut down any program instances starting with ti_server_manager
>
> To find these instances use Ctrl+Alt+Del, click on Task Manager,
> click on Processes Tab, click on Image Name to get the process names
> in alphabetical order, click on the process, click on End Process.
>
> 2. If step 1 does not work then try unplugging the USB FET but leave
> it unplugged for a few seconds.
>
> 3. If step 2 does not work then leave the USB FET unplugged for
> several minutes (or swap another one in)
>
> 4. Leaving the MSP430 device unpowered for several minutes has solved
> some problems.
>
> John Heenan
>
What you describe is precisely what I don't like in CCE.
This reminds me these old pre-worldwar II cars, where you
had to estimate the ignition advance (don't know the vocabulary
in english) and adjust it manually from the board.
That has nothing to do with hystery but with efficiency.
The way the IDE / emulator works is not my problem and should
never be. My problem is to work as fast as possible (i.e. with
the least possible trouble). What I expect from a compiler is
that it does its job fast, what I expect from a debugger is that
it steps when I press step instead of dying.
Usually, I have no time to leave the stuff unpowered for several
minutes everytime it does not work.
Beside this, there are some things I like in CCE better than
in IAR and CCE could gain a lot if TI ever decides to invest
some time in it. I have been waiting for more than 2 years
(to which I should add many "several minutes unplugged" states)
that things improve, they don't.
Pascal
--- In m..., "John Heenan" wrote:
>
> Here are some hints to avoid problems with CCE.
>
> I sometimes leave CCE running overnight and can still continue to
> debug in the same session.
>
> The basic story with CCE is not to confuse it with tricks.
>
> These hints will also help with other debuggers.
>
> There is an hysterical attitude towards CCE that is not backed up by
> my experience and does not concur with Eclipse/GDB based toolsets for
> other processors for users who do not expect to have their 'hands
> held'.
>
> If you do not even have a functional program to start off with as
> described below then you will not have a good experience with CCE.
>
> I have never had a 'blue screen of death' with CCE.
>
> My basis for asserting that as far as I know IAR and CCE use the same
> JTAG debug dlls is that:
> -TI makes available a set of JTAG debug dlls to toolset vendors
> -My USB FET works interchangeably with both IAR and CCE
> -IAR and CCE appear to have the same install program for the USB
> drivers. However the versions used may be out of synch.
>
> HINTS TO AVOID PROBLEMS
>
> 1. Make sure you have plenty of spare RAM available
>
> 2. Always ensure your MSP430 is adequately powered. Externally
> powered MSP430 devices are preferable to devices that take their
> power form the JTAG lines.
>
> 3. Make sure the connection cable is adequate. The shorter the better.
>
> 4. CCE always appears to single step until it reaches main. If your
> code does not have a main, if main is never reached or there is a
> long path to main CCE will appear to be sluggish.
>
> 5. If your MSP430 behaves unpredictably because of a reset or jumping
> to a non existent interrupt handler then CCE will behave sluggishly
> or appear to have lost contact.
> HINTS TO RECOVER FROM PROBLEMS DUE TO MISBEHAVING PROGRAMS
>
> 1. If contact appears to be lost (because your MSP430 is poorly
> powered, has reset or taken a non existent interrupt for example) and
> CCE appears to be difficult to get going again try the following
>
> - Bring up any instances of GDB in task manager and shut then down
> - Shut down any program instances starting with ti_server_manager
>
> To find these instances use Ctrl+Alt+Del, click on Task Manager,
> click on Processes Tab, click on Image Name to get the process names
> in alphabetical order, click on the process, click on End Process.
>
> 2. If step 1 does not work then try unplugging the USB FET but leave
> it unplugged for a few seconds.
>
> 3. If step 2 does not work then leave the USB FET unplugged for
> several minutes (or swap another one in)
>
> 4. Leaving the MSP430 device unpowered for several minutes has solved
> some problems.
>
> John Heenan
>
Reply by ●June 21, 20072007-06-21
Paul,
That is great news.. I have been quite happy with your product and have recommended to other colleagues..
Paul Curtis wrote:
Hi,
> My choice was Crossworks by Rowley.. its affordable (under $1k) and
> produces the best code on the projects I tried it with, the only
> downside is that it doesn't support the 20bit addressing of the new
> larger parts like IAR does, hopefully this will be rectified..
Large MSP430X variants using the flash above 64K require a bit of a rework
in the compiler and linker. V2 of our product is very close which
seamlessly steps around the interrupt vectors placed at the end of the first
64K. There's a whole lot more goodness in V2 along with MSP430X support.
Regards,
--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors
That is great news.. I have been quite happy with your product and have recommended to other colleagues..
Paul Curtis wrote:
Hi,
> My choice was Crossworks by Rowley.. its affordable (under $1k) and
> produces the best code on the projects I tried it with, the only
> downside is that it doesn't support the 20bit addressing of the new
> larger parts like IAR does, hopefully this will be rectified..
Large MSP430X variants using the flash above 64K require a bit of a rework
in the compiler and linker. V2 of our product is very close which
seamlessly steps around the interrupt vectors placed at the end of the first
64K. There's a whole lot more goodness in V2 along with MSP430X support.
Regards,
--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors
Reply by ●June 21, 20072007-06-21
I agree with John. I have used CCE extensively and have never seen the
blue screen of death. CCE does have some areas that can be improved,
who doesn't. The very recent service pack appears to have done more
than put in the new processors. They have addressed some bugs and weak
areas, especially around breakpoints.
The USBFET issues that I have seen are primarily related to powering
issues or power glitches and John's comments are spot on in terms of
dealing with them. The only thing that I would add is that aggressive
ACPI on the PC can lead to some of these issues as well.
In general I have found CCE to quite good and have stuck with it for
that reason.
Frank
John Heenan wrote:
>
> Here are some hints to avoid problems with CCE.
>
> I sometimes leave CCE running overnight and can still continue to
> debug in the same session.
>
> The basic story with CCE is not to confuse it with tricks.
>
> These hints will also help with other debuggers.
>
> There is an hysterical attitude towards CCE that is not backed up by
> my experience and does not concur with Eclipse/GDB based toolsets for
> other processors for users who do not expect to have their 'hands
> held'.
>
> If you do not even have a functional program to start off with as
> described below then you will not have a good experience with CCE.
>
> I have never had a 'blue screen of death' with CCE.
>
> My basis for asserting that as far as I know IAR and CCE use the same
> JTAG debug dlls is that:
> -TI makes available a set of JTAG debug dlls to toolset vendors
> -My USB FET works interchangeably with both IAR and CCE
> -IAR and CCE appear to have the same install program for the USB
> drivers. However the versions used may be out of synch.
>
> HINTS TO AVOID PROBLEMS
>
> 1. Make sure you have plenty of spare RAM available
>
> 2. Always ensure your MSP430 is adequately powered. Externally
> powered MSP430 devices are preferable to devices that take their
> power form the JTAG lines.
>
> 3. Make sure the connection cable is adequate. The shorter the better.
>
> 4. CCE always appears to single step until it reaches main. If your
> code does not have a main, if main is never reached or there is a
> long path to main CCE will appear to be sluggish.
>
> 5. If your MSP430 behaves unpredictably because of a reset or jumping
> to a non existent interrupt handler then CCE will behave sluggishly
> or appear to have lost contact.
>
> HINTS TO RECOVER FROM PROBLEMS DUE TO MISBEHAVING PROGRAMS
>
> 1. If contact appears to be lost (because your MSP430 is poorly
> powered, has reset or taken a non existent interrupt for example) and
> CCE appears to be difficult to get going again try the following
>
> - Bring up any instances of GDB in task manager and shut then down
> - Shut down any program instances starting with ti_server_manager
>
> To find these instances use Ctrl+Alt+Del, click on Task Manager,
> click on Processes Tab, click on Image Name to get the process names
> in alphabetical order, click on the process, click on End Process.
>
> 2. If step 1 does not work then try unplugging the USB FET but leave
> it unplugged for a few seconds.
>
> 3. If step 2 does not work then leave the USB FET unplugged for
> several minutes (or swap another one in)
>
> 4. Leaving the MSP430 device unpowered for several minutes has solved
> some problems.
>
> John Heenan
>
>
--
Frank
This message and any attachments are confidential and intended solely for the addressees. If you receive this message in error, please delete it and immediately notify the sender. If the reader of this message is not the intended recipient, you are hereby notified that any unauthorized use, copying or dissemination is prohibited.
blue screen of death. CCE does have some areas that can be improved,
who doesn't. The very recent service pack appears to have done more
than put in the new processors. They have addressed some bugs and weak
areas, especially around breakpoints.
The USBFET issues that I have seen are primarily related to powering
issues or power glitches and John's comments are spot on in terms of
dealing with them. The only thing that I would add is that aggressive
ACPI on the PC can lead to some of these issues as well.
In general I have found CCE to quite good and have stuck with it for
that reason.
Frank
John Heenan wrote:
>
> Here are some hints to avoid problems with CCE.
>
> I sometimes leave CCE running overnight and can still continue to
> debug in the same session.
>
> The basic story with CCE is not to confuse it with tricks.
>
> These hints will also help with other debuggers.
>
> There is an hysterical attitude towards CCE that is not backed up by
> my experience and does not concur with Eclipse/GDB based toolsets for
> other processors for users who do not expect to have their 'hands
> held'.
>
> If you do not even have a functional program to start off with as
> described below then you will not have a good experience with CCE.
>
> I have never had a 'blue screen of death' with CCE.
>
> My basis for asserting that as far as I know IAR and CCE use the same
> JTAG debug dlls is that:
> -TI makes available a set of JTAG debug dlls to toolset vendors
> -My USB FET works interchangeably with both IAR and CCE
> -IAR and CCE appear to have the same install program for the USB
> drivers. However the versions used may be out of synch.
>
> HINTS TO AVOID PROBLEMS
>
> 1. Make sure you have plenty of spare RAM available
>
> 2. Always ensure your MSP430 is adequately powered. Externally
> powered MSP430 devices are preferable to devices that take their
> power form the JTAG lines.
>
> 3. Make sure the connection cable is adequate. The shorter the better.
>
> 4. CCE always appears to single step until it reaches main. If your
> code does not have a main, if main is never reached or there is a
> long path to main CCE will appear to be sluggish.
>
> 5. If your MSP430 behaves unpredictably because of a reset or jumping
> to a non existent interrupt handler then CCE will behave sluggishly
> or appear to have lost contact.
>
> HINTS TO RECOVER FROM PROBLEMS DUE TO MISBEHAVING PROGRAMS
>
> 1. If contact appears to be lost (because your MSP430 is poorly
> powered, has reset or taken a non existent interrupt for example) and
> CCE appears to be difficult to get going again try the following
>
> - Bring up any instances of GDB in task manager and shut then down
> - Shut down any program instances starting with ti_server_manager
>
> To find these instances use Ctrl+Alt+Del, click on Task Manager,
> click on Processes Tab, click on Image Name to get the process names
> in alphabetical order, click on the process, click on End Process.
>
> 2. If step 1 does not work then try unplugging the USB FET but leave
> it unplugged for a few seconds.
>
> 3. If step 2 does not work then leave the USB FET unplugged for
> several minutes (or swap another one in)
>
> 4. Leaving the MSP430 device unpowered for several minutes has solved
> some problems.
>
> John Heenan
>
>
--
Frank
This message and any attachments are confidential and intended solely for the addressees. If you receive this message in error, please delete it and immediately notify the sender. If the reader of this message is not the intended recipient, you are hereby notified that any unauthorized use, copying or dissemination is prohibited.
Reply by ●June 21, 20072007-06-21
Pascal,
> Beside this, there are some things I like in CCE better than
> in IAR and CCE could gain a lot if TI ever decides to invest
> some time in it.
I think TI has invested more time in this than you could ever believe.
--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors
> Beside this, there are some things I like in CCE better than
> in IAR and CCE could gain a lot if TI ever decides to invest
> some time in it.
I think TI has invested more time in this than you could ever believe.
--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors
Reply by ●June 21, 20072007-06-21
Hi Paul,
You might be true. But for the simple user I am, they have
released V2.0 a year ago, they have released 2 service packs
that are updates for the new processors and beside that, no
patch, not evem a V2.0.1, whatever it would mean.
I heard that their plan is to integrate MSP430 in CCS (code
composer studio) to get a single IDE for all DSPs and
MCUs. And that might explain that CCE does not evolve.
This would be great. I use CCS for DM642 and it's really
another world.
Don't misunderstand me, I don't blame Texas. They have their
priorities that are not the same as individual developers'
priorities. CCE works (somewhat), I didn't have a blue screen
either but 3rd party tools usually work better with their own
emulator than their own tools.
Pascal
--- In m..., "Paul Curtis" wrote:
>
> Pascal,
>
> > Beside this, there are some things I like in CCE better than
> > in IAR and CCE could gain a lot if TI ever decides to invest
> > some time in it.
>
> I think TI has invested more time in this than you could ever believe.
>
> --
> Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
> CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors
>
You might be true. But for the simple user I am, they have
released V2.0 a year ago, they have released 2 service packs
that are updates for the new processors and beside that, no
patch, not evem a V2.0.1, whatever it would mean.
I heard that their plan is to integrate MSP430 in CCS (code
composer studio) to get a single IDE for all DSPs and
MCUs. And that might explain that CCE does not evolve.
This would be great. I use CCS for DM642 and it's really
another world.
Don't misunderstand me, I don't blame Texas. They have their
priorities that are not the same as individual developers'
priorities. CCE works (somewhat), I didn't have a blue screen
either but 3rd party tools usually work better with their own
emulator than their own tools.
Pascal
--- In m..., "Paul Curtis" wrote:
>
> Pascal,
>
> > Beside this, there are some things I like in CCE better than
> > in IAR and CCE could gain a lot if TI ever decides to invest
> > some time in it.
>
> I think TI has invested more time in this than you could ever believe.
>
> --
> Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
> CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors
>
Reply by ●June 21, 20072007-06-21
Pascal,
For the record, I am currently using CCE 2.0.2.4 which addresses several
bugs as well a adding new processors. It is readily available,
slac135.zip, CCE Service Pack 2
on the
TI website. It might help to download an read the release notes.
Frank
p_murayama wrote:
>
> Hi Paul,
>
> You might be true. But for the simple user I am, they have
> released V2.0 a year ago, they have released 2 service packs
> that are updates for the new processors and beside that, no
> patch, not evem a V2.0.1, whatever it would mean.
>
> I heard that their plan is to integrate MSP430 in CCS (code
> composer studio) to get a single IDE for all DSPs and
> MCUs. And that might explain that CCE does not evolve.
> This would be great. I use CCS for DM642 and it's really
> another world.
>
> Don't misunderstand me, I don't blame Texas. They have their
> priorities that are not the same as individual developers'
> priorities. CCE works (somewhat), I didn't have a blue screen
> either but 3rd party tools usually work better with their own
> emulator than their own tools.
>
> Pascal
>
> --- In m... , "Paul
> Curtis" wrote:
> >
> > Pascal,
> >
> > > Beside this, there are some things I like in CCE better than
> > > in IAR and CCE could gain a lot if TI ever decides to invest
> > > some time in it.
> >
> > I think TI has invested more time in this than you could ever believe.
> >
> > --
> > Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
>
> > CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors
> >
--
Frank
This message and any attachments are confidential and intended solely for the addressees. If you receive this message in error, please delete it and immediately notify the sender. If the reader of this message is not the intended recipient, you are hereby notified that any unauthorized use, copying or dissemination is prohibited.
For the record, I am currently using CCE 2.0.2.4 which addresses several
bugs as well a adding new processors. It is readily available,
slac135.zip, CCE Service Pack 2
on the
TI website. It might help to download an read the release notes.
Frank
p_murayama wrote:
>
> Hi Paul,
>
> You might be true. But for the simple user I am, they have
> released V2.0 a year ago, they have released 2 service packs
> that are updates for the new processors and beside that, no
> patch, not evem a V2.0.1, whatever it would mean.
>
> I heard that their plan is to integrate MSP430 in CCS (code
> composer studio) to get a single IDE for all DSPs and
> MCUs. And that might explain that CCE does not evolve.
> This would be great. I use CCS for DM642 and it's really
> another world.
>
> Don't misunderstand me, I don't blame Texas. They have their
> priorities that are not the same as individual developers'
> priorities. CCE works (somewhat), I didn't have a blue screen
> either but 3rd party tools usually work better with their own
> emulator than their own tools.
>
> Pascal
>
> --- In m... , "Paul
> Curtis" wrote:
> >
> > Pascal,
> >
> > > Beside this, there are some things I like in CCE better than
> > > in IAR and CCE could gain a lot if TI ever decides to invest
> > > some time in it.
> >
> > I think TI has invested more time in this than you could ever believe.
> >
> > --
> > Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
>
> > CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors
> >
--
Frank
This message and any attachments are confidential and intended solely for the addressees. If you receive this message in error, please delete it and immediately notify the sender. If the reader of this message is not the intended recipient, you are hereby notified that any unauthorized use, copying or dissemination is prohibited.
