Future of Microchip Development Tools? See inside...

http://Microcontroller.com/Embedded.asp?did=142

Atmel;  Moto... uh, Freescale(!);  8051;  ARM;  Microchip.

I'm taking a short survey of Microchip users to help decide what future directions
development tools should take. The survey is confidential - I don't even ask for your
email address, O.K.?

It's only 11 questions that should take you less than a minute. Unless you really want
to get opinionated ("Embedded Developers opinionated?!?? Nah!!!") in which case, go
ahead, "comment" to your heart's content...!

http://Microcontroller.com/Embedded.asp?did=142

I'm basically trying to figure out whose development tools are completely reliable, and
whose tools really suck. And it's your opportunity to say whatever you want to say -
really!

Thanks for your support,

- Bill Giovino
  Executive Editor
  http://Microcontroller.com
  "Stamping out Bad Development Tools since 1995"

On Wed, 30 Nov 2005 14:22:54 -0500, "Bill Giovino"
<editor@nospam-microcontroller.com> wrote:
>http://Microcontroller.com/Embedded.asp?did=142
>Atmel;  Moto... uh, Freescale(!);  8051;  ARM;  Microchip.
>I'm taking a short survey of Microchip users to help decide what future directions
>development tools should take. The survey is confidential - I don't even ask for your
>email address, O.K.?
>It's only 11 questions that should take you less than a minute. Unless you really want
>to get opinionated ("Embedded Developers opinionated?!?? Nah!!!") in which case, go
>ahead, "comment" to your heart's content...!
>http://Microcontroller.com/Embedded.asp?did=142
>I'm basically trying to figure out whose development tools are completely reliable, and
>whose tools really suck. And it's your opportunity to say whatever you want to say -
>really!
>
>Thanks for your support,
>- Bill Giovino
>  Executive Editor
>  http://Microcontroller.com
>  "Stamping out Bad Development Tools since 1995"

MPLab is fine, but the cost of the C compilers for their family of PIC
and dsPIC processors is a consideration compared to ATMEL and GNU.

Regarding tools that suck, while  Analog Devices Visual DSP++ is
actually a pretty nice tool, the support of that tool really sucks.
If you try to do anything atypically your own your own. They don't
appear to have inhouse expertise on their own toolset.

I started using Microchip's dsPIC  on a project and abandoned it in
favor of TI.  The fact that I found the tools absolutely abysmal had a
lot to do with my decision.  The other factor was that for less money,
I was able to get a much more powerfull TI processor.

The tools crashed constantly and irrecoverably even took my development
project with it on one occasion

On 1 Dec 2005 07:30:07 -0800, the renowned "Noway2"
<no_spam_me2@hotmail.com> wrote:

>I started using Microchip's dsPIC  on a project and abandoned it in
>favor of TI.  The fact that I found the tools absolutely abysmal had a
>lot to do with my decision.  The other factor was that for less money,
>I was able to get a much more powerfull TI processor.
>
>The tools crashed constantly and irrecoverably even took my development
>project with it on one occasion

Using C or assembly? 


Best regards, 
Spehro Pefhany
-- 
"it's the network..."                          "The Journey is the reward"
speff@interlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com

I worked with a friend on a project using the same processor (dspic
30F64 I think) .  That project was a combination of C and Assembly.  In
addition to the tools effing up a lot, I remember how much of a pain it
was trying to figure out how to define const variables in program
memory and access them at rum time.  It required the use of a program
visibility window or something similar.

I didn't even get that far on my project before switching to TI.  I was
using the MPLAB and the visual configuration tool to plan out the
desired pin assignments for the chip in preparation for PCB layout.  By
that point, I was displeased enough with Microchip that  I didn't want
to continue with using them any longer.  I would have to say, that
overall, I am as pleased with TI as I was displeased with Microchip.

"Noway2" <no_spam_me2@hotmail.com> wrote in message 
news:1133464473.203191.66320@z14g2000cwz.googlegroups.com...
> "... define const variables in program memory and access them at rum time. 
> "

See, there's the problem.  You should never try to think about work during 
"rum" time. :-|

Sorry, I couldn't help myself.  It's Friday.

Scott 

I hear you there!  I must have had "rum" on the brain then too!

"Bill Giovino" <editor@nospam-microcontroller.com> skrev i meddelandet 
news:rqmdnQlTSdbSYRDeRVn-vQ@comcast.com...
> http://Microcontroller.com/Embedded.asp?did=142
>
>
> I'm taking a short survey of Microchip users to help decide what future 
> directions
> development tools should take. The survey is confidential - I don't even 
> ask for your
> email address, O.K.?
>


STK500 & AVR + GNU?

Sorry, could not resist ;-)

-- 
Best Regards,
Ulf Samuelsson
This is intended to be my personal opinion which may,
or may bot be shared by my employer Atmel Nordic AB 

On Thu, 01 Dec 2005 12:38:35 +0000, AntiSPAM_g9u5dd43 wrote:

> On Wed, 30 Nov 2005 14:22:54 -0500, "Bill Giovino"
> <editor@nospam-microcontroller.com> wrote:
>> [quoted text muted]
> 
> MPLab is fine, but the cost of the C compilers for their family of PIC
> and dsPIC processors is a consideration compared to ATMEL and GNU.
> 
> Regarding tools that suck, while  Analog Devices Visual DSP++ is
> actually a pretty nice tool, the support of that tool really sucks.
> If you try to do anything atypically your own your own. They don't
> appear to have inhouse expertise on their own toolset.

You can program dsPIC using gcc. Somebody has ported the microchip changes
over to linux. It would be nice to figure out how to use the
microchip runtime monitor to drive GDB, but I haven't gotten around to
that yet.

---
Regards,
  Bob Monsen

Music is the pleasure the human soul experiences from counting without 
being aware that it is counting.
- Gottfried Leibniz