Searching \ for '[PIC]: Is MPLAB Junk?' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/languages.htm?key=mplab
Search entire site for: 'Is MPLAB Junk?'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: Is MPLAB Junk?'
2002\08\09@163842 by Michael A. Powers

picon face
Don't get me wrong, I like Microchip, and I like the way that they provide their development software for free.  But there are just a few things about MPLAB that really get to me.  I can ignore the small bugs, lackluster interface, and the fact Microsoft is developing 64 bit windows and MPLAB is still 16 bit. Such things are immaterial.  (Hopefully v. 6.0 will be a big improvement.)  What I can't ignore is the poor performance of the simulator.  It seems to be intentionally lethargic!  Why must programs like SPEED.EXE be used as an accelerant?  Is MPLAB sandbagged?  It consumes about 1% of the CPU's resources and idles the rest.  I though that Microchip might not expend much effort on MPLAB in the hopes that 3rd party developers would pick up the slack, but where are they?

What do you think about this?
-Mike

--
http://www.piclist.com hint: To leave the PICList
spam_OUTpiclist-unsubscribe-requestTakeThisOuTspammitvma.mit.edu


2002\08\09@165156 by Herbert Graf

flavicon
face
> Don't get me wrong, I like Microchip, and I like the way that
> they provide their development software for free.  But there are
> just a few things about MPLAB that really get to me.  I can
> ignore the small bugs, lackluster interface, and the fact
> Microsoft is developing 64 bit windows and MPLAB is still 16 bit.
> Such things are immaterial.  (Hopefully v. 6.0 will be a big
> improvement.)  What I can't ignore is the poor performance of the
> simulator.  It seems to be intentionally lethargic!  Why must
> programs like SPEED.EXE be used as an accelerant?  Is MPLAB
> sandbagged?  It consumes about 1% of the CPU's resources and
> idles the rest.  I though that Microchip might not expend much
> effort on MPLAB in the hopes that 3rd party developers would pick
> up the slack, but where are they?
>
> What do you think about this?

       Simple, they probably don't want you using the simulator that much, they
want you buying their emulators (which are much more accurate in some
circumstances). TTYL

--
http://www.piclist.com hint: To leave the PICList
.....piclist-unsubscribe-requestKILLspamspam@spam@mitvma.mit.edu


2002\08\09@172301 by mike

flavicon
face
On Fri, 9 Aug 2002 16:49:47 -0400, you wrote:

>> Don't get me wrong, I like Microchip, and I like the way that
>> they provide their development software for free.  But there are
>> just a few things about MPLAB that really get to me.  I can
>> ignore the small bugs, lackluster interface, and the fact
>> Microsoft is developing 64 bit windows and MPLAB is still 16 bit.
>> Such things are immaterial.  (Hopefully v. 6.0 will be a big
>> improvement.)  What I can't ignore is the poor performance of the
>> simulator.  It seems to be intentionally lethargic!  Why must
>> programs like SPEED.EXE be used as an accelerant?  Is MPLAB
>> sandbagged?  It consumes about 1% of the CPU's resources and
>> idles the rest.  I though that Microchip might not expend much
>> effort on MPLAB in the hopes that 3rd party developers would pick
>> up the slack, but where are they?
>>
>> What do you think about this?
>
>        Simple, they probably don't want you using the simulator that much, they
>want you buying their emulators (which are much more accurate in some
>circumstances). TTYL
I'd put it slightly differently... The people doing serious development for real products which sell PIC
chips will mostly be using in-circuit emulators, as their time is too
valuable not to do so. Add this to the fact that most PIC projects interact with the outside
world in ways that are difficult or impossible to emulate under
simulation. The bottom line is that the people who buy the vast majority of PICs
will not be using the simulator to any serious degree, so it does not
justify much in the way of development budget.  
--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestspamKILLspammitvma.mit.edu


2002\08\09@172919 by Olin Lathrop

face picon face
> Don't get me wrong, I like Microchip, and I like the way that
> they provide their development software for free.  But there are
> just a few things about MPLAB that really get to me.  I can
> ignore the small bugs, lackluster interface, and the fact
> Microsoft is developing 64 bit windows and MPLAB is still 16 bit.
> Such things are immaterial.  (Hopefully v. 6.0 will be a big
> improvement.)  What I can't ignore is the poor performance of the
> simulator.  It seems to be intentionally lethargic!  Why must
> programs like SPEED.EXE be used as an accelerant?  Is MPLAB
> sandbagged?  It consumes about 1% of the CPU's resources and
> idles the rest.  I though that Microchip might not expend much
> effort on MPLAB in the hopes that 3rd party developers would pick
> up the slack, but where are they?
>
> What do you think about this?

I think the ICE works very nicely and I don't care much what the simulator
does.  If you don't like the product, you can get all your money back any
time.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: To leave the PICList
.....piclist-unsubscribe-requestKILLspamspam.....mitvma.mit.edu


2002\08\09@181245 by Matt Pobursky

flavicon
face
On Fri, 9 Aug 2002 16:38:58 -0400, Michael A. Powers wrote:
>Don't get me wrong, I like Microchip, and I like the way that they
>provide their development software for free.  But there are just a few
>things about MPLAB that really get to me.  I can ignore the small
>bugs, lackluster interface, and the fact Microsoft is developing 64
>bit windows and MPLAB is still 16 bit. Such things are immaterial.
>(Hopefully v. 6.0 will be a big improvement.)  What I can't ignore is
>the poor performance of the simulator.  It seems to be intentionally
>lethargic!  Why must programs like SPEED.EXE be used as an accelerant?
>Is MPLAB sandbagged?  It consumes about 1% of the CPU's resources and
>idles the rest.  I though that Microchip might not expend much effort
>on MPLAB in the hopes that 3rd party developers would pick up the
>slack, but where are they?
>
>What do you think about this?

I haven't liked MPLAB for at least 5 years (since before they said
MPLAB 6 would be out "anytime" and "soon"). Yes, they were saying that
at the Masters Conference in 1997! So far I'm not too impressed with
MPLAB 6 either, but it's obviously still young.

My major gripes with MPLAB has always the 16-bit code, the clunky
simulator (although I do use it once in a while), the AWFUL support for
3rd party compilers -- especially source level debugging in C. Some may
say it's not realistic to ask Microchip to support 3rd party tools,
BUT...

this leads us to Michael's question "I though that Microchip might not
expend much effort on MPLAB in the hopes that 3rd party developers
would pick up the slack, but where are they?"

The answer is simple: Would you expend significant time and energy to
design, develop and market a 3rd party equivalent to MPLAB when MPLAB
is FREE? I've thought several times about writing one myself, but each
time I look at what I might be able to charge for it and the limited
market size -- well, it's very discouraging to say the least. Plus,
Microchip is not very willing to divulge technical details of things
like the Picstart+ interface and such. I doubt anyone could sell
anything less than a full-featured IDE for a sum that would pay back
the engineering investment in a reasonable time frame.

I'm disappointed in Microchip's development tool group. They are good
guys and I've met several of them. My own personal opinion is they
really don't have sufficient funding/staffing/support with regards to
the tools they'd like to produce and support. Of course, that's my
opinion... I could be wrong. ;-)

Matt Pobursky
Maximum Performance Systems

--
http://www.piclist.com hint: To leave the PICList
EraseMEpiclist-unsubscribe-requestspam_OUTspamTakeThisOuTmitvma.mit.edu


2002\08\09@211400 by Sergio Masci

picon face
----- Original Message -----
From: Michael A. Powers <mapowersspamspam_OUTIEEE.ORG>
To: <@spam@PICLISTKILLspamspamMITVMA.MIT.EDU>
Sent: Friday, August 09, 2002 9:38 PM
Subject: [PIC]: Is MPLAB Junk?


> Don't get me wrong, I like Microchip, and I like the way that they provide
> their development software for free.

It's not free if it costs you in other ways! My time is valuable to me I
assume yours is valuable to you.

> But there are just a few things about
> MPLAB that really get to me.  I can ignore the small bugs, lackluster
> interface, and the fact Microsoft is developing 64 bit windows and MPLAB
is
> still 16 bit. Such things are immaterial.  (Hopefully v. 6.0 will be a big
> improvement.)  What I can't ignore is the poor performance of the
simulator.
> It seems to be intentionally lethargic!  Why must programs like SPEED.EXE
be
> used as an accelerant?  Is MPLAB sandbagged?

I doubt it. It sounds as though the task switching is relying on windows
events.

>  It consumes about 1% of the
> CPU's resources and idles the rest.

Depending on how MPLAB is refreshing its windows and how it is processing
mouse and keyboard input will determine how it gets suspended and
reactivated.

>  I though that Microchip might not
> expend much effort on MPLAB in the hopes that 3rd party developers would
> pick up the slack, but where are they?

Hello - kooie - over here!

Multiple interacting PIC simulator, high level assembler, state machine case
tool
http://www.xcprod.com

>
> What do you think about this?
> -Mike

We understand that students and hobbyists have financial restrictions this
is why we offer a version of our software for these users at greatly
discounted rates. Only time will tell if this was a wise decision.

Regards
Sergio Masci

--
http://www.piclist.com hint: To leave the PICList
KILLspampiclist-unsubscribe-requestKILLspamspammitvma.mit.edu


2002\08\09@211432 by Sergio Masci

picon face
----- Original Message -----
From: Olin Lathrop <RemoveMEolin_piclistTakeThisOuTspamEMBEDINC.COM>
To: <spamBeGonePICLISTspamBeGonespamMITVMA.MIT.EDU>
Sent: Friday, August 09, 2002 10:28 PM
Subject: Re: [PIC]: Is MPLAB Junk?


> I think the ICE works very nicely and I don't care much what the simulator
> does.  If you don't like the product, you can get all your money back any
> time.

I think that ICE facilities in general are fantastic. But there are many
situations were a good simulator is of greater benefit. For example
debugging a protocol involving multiple processors. In this situation being
able to freeze time, save and reload a simulation to try different scenarios
can greatly improve system development. Also when developing algorithms that
generate or process complex data it is very useful to be able to attach the
simulated processor to a background task (with trusted reference code) that
can produce test data or verify results. Simulators don't have to be slow.
Given the speed of modern affordable desktop PCs it is easy to simulate
multiple interacting PICs running at full speed.

Regards
Sergio Masci

--
http://www.piclist.com hint: To leave the PICList
TakeThisOuTpiclist-unsubscribe-requestEraseMEspamspam_OUTmitvma.mit.edu


2002\08\10@054031 by mike

flavicon
face
On Fri, 9 Aug 2002 17:12:25 -0500, you wrote:

{Quote hidden}

I think they're just too busy keeping up with all the zillions of
product variations.... do they REALLY need that many different PICs ?

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\08\12@063545 by Alan B. Pearce

face picon face
>My major gripes with MPLAB has always the 16-bit code, the clunky
>simulator (although I do use it once in a while), the AWFUL support for
>3rd party compilers -- especially source level debugging in C. Some may
>say it's not realistic to ask Microchip to support 3rd party tools,
>BUT...

I cannot understand why they have not caused the Borland compiler they use,
to produce 32 bit code. Perhaps Microchip have been developing MPLAB on Win
3.1 machines :))

The bits I hate about it are the way a new version breaks previous versions.
Installed one of the 5.6.something releases recently to find that the macro
handling during emulation was broken. Previously when stepping through a
macro, the cursor would sit at the instruction previous to the macro, until
the single step reached the next instruction after the macro. The broken one
would shoot the cursor several instructions previous to the macro, which
could be in the previous subroutine, and had one looking twice to verify
where the code was actually executing.

Also had some strange happenings with attempting to scroll windows. Try to
scroll a source code window, and no matter what one did, the ROM code window
would insist on scrolling, even though it was not the foreground window.

So yes, there are aspects about it that are junk. It is not unreasonable to
expect it to improve as new versions come out, not break existing bits -
that is why people use HLL's, isn't it??? :))

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2002\08\12@130709 by Harold M Hallikainen

picon face
On Mon, 12 Aug 2002 11:33:55 +0100 "Alan B. Pearce" <RemoveMEA.B.PearcespamTakeThisOuTRL.AC.UK>
writes:
> Also had some strange happenings with attempting to scroll windows.
> Try to
> scroll a source code window, and no matter what one did, the ROM
> code window
> would insist on scrolling, even though it was not the foreground
> window.
>

       I find that problem quite frequently. I click another window, then click
back into the window I want. The proper one then scrolls. I think they
just lost track of which window was the top one. I'm sure it'll be fixed
in a later revision (if it's not already fixed), and something else will
be broken...

Harold


FCC Rules Online at http://hallikainen.com/FccRules
Lighting control for theatre and television at http://www.dovesystems.com

Reach broadcasters, engineers, manufacturers, compliance labs, and
attorneys.
Advertise at http://www.hallikainen.com/FccRules/ .


________________________________________________________________
GET INTERNET ACCESS FROM JUNO!
Juno offers FREE or PREMIUM Internet access for less!
Join Juno today!  For your FREE software, visit:
dl.http://www.juno.com/get/web/.

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2002\08\12@130722 by Harold M Hallikainen

picon face
On Sat, 10 Aug 2002 09:38:12 +0100 Mike Harrison <mikeEraseMEspam.....WHITEWING.CO.UK>
writes:
> >I'm disappointed in Microchip's development tool group. They are
> good
> >guys and I've met several of them. My own personal opinion is they
> >really don't have sufficient funding/staffing/support with regards
> to
> >the tools they'd like to produce and support. Of course, that's my
> >opinion... I could be wrong. ;-)
> I think they're just too busy keeping up with all the zillions of
> product variations.... do they REALLY need that many different PICs
> ?
>

       Of course not! They should only make PICs that fit MY applications!

Harold


FCC Rules Online at http://hallikainen.com/FccRules
Lighting control for theatre and television at http://www.dovesystems.com

Reach broadcasters, engineers, manufacturers, compliance labs, and
attorneys.
Advertise at http://www.hallikainen.com/FccRules/ .


________________________________________________________________
GET INTERNET ACCESS FROM JUNO!
Juno offers FREE or PREMIUM Internet access for less!
Join Juno today!  For your FREE software, visit:
dl.http://www.juno.com/get/web/.

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2002\08\12@132701 by Peter L. Peres

picon face
On Mon, 12 Aug 2002, Alan B. Pearce wrote:

>>My major gripes with MPLAB has always the 16-bit code, the clunky
>>simulator (although I do use it once in a while), the AWFUL support for
>>3rd party compilers -- especially source level debugging in C. Some may
>>say it's not realistic to ask Microchip to support 3rd party tools,
>>BUT...
>
>I cannot understand why they have not caused the Borland compiler they use,
>to produce 32 bit code. Perhaps Microchip have been developing MPLAB on Win
>3.1 machines :))

Thank the powers that be that they haven't because 16 bit MPLAB runs fine
under Linux/Wine by grace of this "fault" ... until the GNU tools will be
integrated properly <duck behind large flame shield>.

Peter

>So yes, there are aspects about it that are junk. It is not unreasonable to
>expect it to improve as new versions come out, not break existing bits -
>that is why people use HLL's, isn't it??? :))

Just for laughs compute the number of man-hours required to test every
feature wrt every other feature, assuming 1 hour per bugfix and an initial
'imperfection' of 0.1% (one bug per thousand features - don't forget to
count as features to be tested things like testing scrolling at each
corner, ltrb, and middle of window, maximized or not, with random data,
above or under windows etc etc). If you still think such a thing should be
free, say so ;-). F.ex. a program with 2 partially overlapping text
windows that do just scrolling of text (no editing, no nothing) will have
some 81 tests to pass, depending on how you count ...

Peter

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2002\08\12@142229 by Scott Dattalo

face
flavicon
face
On Mon, 12 Aug 2002, Peter L. Peres wrote:

> On Mon, 12 Aug 2002, Alan B. Pearce wrote:
>
> >>My major gripes with MPLAB has always the 16-bit code, the clunky
> >>simulator (although I do use it once in a while), the AWFUL support for
> >>3rd party compilers -- especially source level debugging in C. Some may
> >>say it's not realistic to ask Microchip to support 3rd party tools,
> >>BUT...
> >
> >I cannot understand why they have not caused the Borland compiler they use,
> >to produce 32 bit code. Perhaps Microchip have been developing MPLAB on Win
> >3.1 machines :))
>
> Thank the powers that be that they haven't because 16 bit MPLAB runs fine
> under Linux/Wine by grace of this "fault" ... until the GNU tools will be
> integrated properly <duck behind large flame shield>.

From who are you fearing flames: MChip, the GNU developers in general, the
GNUPIC developers, or Wine?

Scott

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2002\08\13@050106 by Michael Rigby-Jones

flavicon
face
> -----Original Message-----
> From: Alan B. Pearce [SMTP:EraseMEA.B.PearcespamRL.AC.UK]
> Sent: Monday, August 12, 2002 11:34 AM
> To:   RemoveMEPICLISTEraseMEspamEraseMEMITVMA.MIT.EDU
> Subject:      Re: [PIC]: Is MPLAB Junk?
>
> >My major gripes with MPLAB has always the 16-bit code, the clunky
> >simulator (although I do use it once in a while), the AWFUL support for
> >3rd party compilers -- especially source level debugging in C. Some may
> >say it's not realistic to ask Microchip to support 3rd party tools,
> >BUT...
>
> I cannot understand why they have not caused the Borland compiler they
> use,
> to produce 32 bit code. Perhaps Microchip have been developing MPLAB on
> Win
> 3.1 machines :))
>
Unfortunatley turning a 16bit app into a 32bit one isn't as simple as
setting a compiler flag!

Regards

Mike

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistservspam_OUTspamKILLspammitvma.mit.edu with SET PICList DIGEST in the body


2002\08\13@123852 by Peter L. Peres

picon face
On Mon, 12 Aug 2002, Scott Dattalo wrote:

{Quote hidden}

Esp. GNU fanatics ;-)

Peter

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistservTakeThisOuTspamspammitvma.mit.edu with SET PICList DIGEST in the body


2002\08\16@103158 by o-8859-1?Q?Tony_K=FCbek?=

flavicon
face
Argh ! reposted beacuse my mail server decided to
change the 'from adress' ..first post=lost...
Hi,
reagrding the dicussion of gpsim, linux, windows etc. there's an
quite interesting 'solution' to this, being an win-user myself
mostly due to work requirments, I'm reluctant to make an dual
boot configuration for linux. However there's a linux distro
that's called 'Knoppix' ( http://www.knopper.net/knoppix/index-en.html )
that is an *CD-ONLY* solution, i.e. download an iso, burn to cd,
put in cd-tray, select 'boot from cd' in bios ( fairly recent bios ),
away you go.... Put gpsim on an floppy and you have yourself an
'sandbox'
linux to play with.

You can have the cake and eat it to..sometimes... :)

/Tony

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2002\08\16@121818 by Sergio Masci

picon face
----- Original Message -----
From: Tony K|bek <EraseMEtony.kubekspamspamspamBeGoneFLINTAB.COM>
To: <RemoveMEPICLISTKILLspamspamMITVMA.MIT.EDU>
Sent: Friday, August 16, 2002 3:30 PM
Subject: Re: [PIC]: Is MPLAB Junk?


{Quote hidden}

You can actually install Linux to a file on windows and run it from there. I
did this once many years ago. I cannot remember the exact details but it was
trivial. A lot less hassle than a CD-ONLY system and a lot faster. Booting
to linux was just a simple click on a desktop icon. Sorry I can't remember
which distribution it was, but I do remember it was a straight forward
installation option and not a magic key hack.

There is much more cake if you don't wast it on Windoze

Regards
Sergio Masci
http://www.xcprod.com

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


More... (looser matching)
- Last day of these posts
- In 2002 , 2003 only
- Today
- New search...