embedded software boot camp

An open letter to the developers of the MPLAB IDE

Tuesday, September 27th, 2011 by Nigel Jones

I recently inherited a project that uses a Microchip PIC18 processor. Without going into too much detail, suffice it to say that I ended up using Microchip’s MPLAB IDE Version 8.73 together with Microchip’s C compiler. It had been a number of years since I last used MPLAB, in part because my experience back then was so painful. I was heartened to see that the version number had jumped from 6.X to 8.X and so I was fully expecting to find an IDE that was at the very least, decent. Boy was I disappointed. In no particular order, here are some of the head-slapping things I discovered. Disclaimer: I’m no MPLAB expert (and quite frankly after this experience I doubt I will ever become one). Thus it’s entirely possible that the issues listed below are a reflection of my incompetence.

No editor support for splitting the window

The title says it all. Text editors back in the DOS allowed you to open a file and look at various parts of the file at the same time via split windows. This is such a fundamental operation for text editors that I couldn’t believe it wasn’t supported. Do the developers of MPLAB use an editor with this limitation?

No single file compilation

There appears to be no way to simply compile a single file. Instead one is forced to perform a make. Not only is this really time consuming as make wades through all the files that aren’t relevant, it’s also a pain because:

  • It forces you to correct problems in the first file that make finds to process – rather than the one you are interested in.
  • If the compilation passes, it proceeds immediately to the link and download phase – regardless whether you want to or not.

A baffling debugger configuration interface

The first time I tried to download to the debugger, I received an error message telling me that there was a problem with the configuration bits. I beat my head against the issue for a few hours and in the end called a colleague who is a Microchip Consultant (Matt).  Matt told me that he avoided using MPLAB, but vaguely recollected that you had to configure the debugger to explicitly download to the target. Well Matt was spot on. I was just left wondering why anyone would want to debug code without having it downloaded first.

A joke of a simulator

While I was waiting to get hold of Matt, I experimented with the simulator. Despite the documentation saying that various peripherals were supported, I found that the simulator simply didn’t support them. Matt confirmed that the simulator was a piece of junk that no one bothered using.

Unnecessary variable scope limitation

I’m not sure if this is an IDE or a compiler issue. Anyway, when debugging within MPLAB, I discovered that if I had the temerity to declare a variable as static, then the only time I could examine its value was if the variable was in compiler scope. That is, if I was stopped in file foo.c, then the debugger would not let me see the values of static variables declared in bar.c. As a result, I was forced to declare variables as global simply so that I could look at them. Quite frankly, it blows my mind that in 2011 an IDE can force you to adopt lousy programming practices because of its limitations.

No pointer dereferencing

In a similar vein, I discovered that MPLAB only shows you the values of pointers, and not what they are pointing to. I thought that limitation disappeared at least ten years ago.

Limited support for ‘large ‘arrays

The PIC18 doesn’t handle arrays or structures greater than 256 bytes very well. However the Microchip compiler guys came up with a decent work around that is quite straight forward to use – until you want to look at the array in the debugger. In a nutshell all you seem to be able to do is examine the array / structure in the memory window. You can forget about looking at 16 bit integers, or other such ‘complex’ constructs.

Breakpoints that aren’t where I put them

I discovered that placing a breakpoint on a function call was highly problematic. In some cases the break would occur prior to the call, and in other cases it would occur after the call. If I wanted the breakpoint in the called function, I’d put it there myself, thank you.

Anyway, I could go on – but I think you get the picture. What I don’t get is this. Microchip is a big successful company. Why, after a decade of trying can’t they come up with a decent development environment? It has got to be costing them a lot of design wins when people such as myself cringe at the though of having to use their tools.

 

Tags: ,

35 Responses to “An open letter to the developers of the MPLAB IDE”

  1. Alfred says:

    Please add one more.

    After certain depth (levels) of function calls, the MPLAB IDE call stack window will not show what/where invoked the current function. In another words you don’t know why you are in the current function until you step out of it. This is a big fail.

  2. Dale says:

    It’s not that bad. I think it really depends on what you ‘cut your teeth on’. Anyway, they are working on a new platform MPLAB X, which may address some of these issues you raise here. Cheers, Dale.

    • cpegeo says:

      I, like the OP, experience the exact same problems and then some. So I tried MPLAB X, only to find that in its current state (beta) it is worse than 8.xx. And, it has been at beta for since I can remember… MicroChip as a whole is the biggest fail of the 21st century to date. When they released there 32bit line, they were plagued with soooo much errata that most of the peripherals were completely useless. An intelligent engineer goes with the cortex m series instead.

  3. Punta says:

    No editor support for splitting the window: I use it! Just check the window menu

    No single file compilation: View menu->project and then right click & say compile! It doesn’t link here

    No pointer dereferencing: In the projects pane, select second tab at the bottom and say “Enable tags”

    Breakpoints that aren’t where I put them: This may be due to optimization

    By the way MPLAB X is coming (beta already available) which is based on Netbeans platform

  4. NJ says:

    You’ve got a few things just plain wrong!.
    The rest are matters of opinion where we either agree or disagree

    No editor support for splitting the window – Wrong
    There are little “bars” on the bottom of the vertical scrollbar and the rightmost of the horizontal that allow you to do this.

    No single file compilation – Wrong
    Right click on the file in the Project Tree. That easy!

    No single file compilation: Bullet 2 – Yes and No
    States, “If the compilation passes, it proceeds immediately to the link and download phase”.
    Yes, it will immediately link.
    No, it will not immediately download unless you EXPLICITLY enable this behavior, under your tool’s settings.

    A baffling debugger configuration interface – Your Opion; I disagree
    I don’t find it confusing, but I guess this is depends on the user.

    You also state,
    “Matt… vaguely recollected that you had to configure the debugger to explicitly download to the target”
    No idea what you’re referring to here. Never had to do anything special.

    A joke of a simulator – I totally disagree
    So many software programmers want to avoid touching hardware at all possible costs.
    The simulator can probably do more, but at some point you’re going to need to pick up a scope and probe signals.
    If you’re using a simulator to debug your SPI slave code, you’re not going to test it thoroughly enough, no matter how good the sim is.

    Matt confirmed that the simulator was a piece of junk that no one bothered using.
    A LOT of people use the simulator. It’s perfectly fine.
    If by no one he means “himself”, then I guess that’s fine.

    Unnecessary variable scope limitation
    This can probably be improved.

    No pointer dereferencing
    This used to be supported but now seems to be gone. It would be a nice add.

    Limited support for ‘large ‘arrays
    You can forget about looking at 16 bit integers, or other such ‘complex’ constructs.
    What are you talking about? You can view large arrays of ints, structs, enums, etc.
    What are you trying to do?

    “What I don’t get is this. Microchip is a big successful company.
    Why, after a decade of trying can’t they come up with a decent development environment?”
    If you’re expecting the next-generation IDE, why aren’t you using it?
    Have you even looked at MPLAB X?
    http://www.microchip.com/MPLABX

    • Nigel Jones says:

      Hi NJ – thanks for the information. However I have a few comments:
      1. I can split the windows using the technique you described – so thank you. However no such option appears under the Windows menu where I’d expect to find it.
      2. I can indeed perform a single file compilation using the technique you described. However on the toolbar there are buttons for ‘Make’, Build All’, ‘Export Makefile’ and ‘Locate Headers’. I use the first a lot, the second rarely, I never use the third and rarely use the fourth. Why isn’t this option on the tool bar – since it is a far more common operation than ‘Export Makefile’ or even ‘Build All’?
      3. While I recognize that interfaces are highly subjective, I think it’s reasonable to assume that if someone with my level of experience is baffled then the interface is suspect.
      4. Regarding the simulator. I wasn’t trying to do anything fancy – just have a few timers running and generating interrupts. They did not work. Maybe I was just unlucky in my choice of CPU.
      5. Regarding the large arrays. Here is what I was trying to do:
      #pragma udata DisplayBuf
      static UINT8 DispBuffer[BUFSIZE];
      #pragma udata
      static UINT8 * DisplayBuffer = &DispBuffer[0];

      I could find no way to examine the contents of DispBuffer[] in a watch window. Perhaps it’s related to the pointer dereferencing issue?
      6. Isn’t MPLAB X in beta still? I don’t like using beta release tools for obvious reasons. Perhaps I made the wrong choice?

  5. Hi,

    I’m happy I’m not the only one who is struggling;)

    On top of the fun you had I also ported FreeRTOS to a 18lf45k22 which was lots of fun. Besides the troubles you had I also faced some interesting hardware features, like not being able to erase the device at 1.8V. Which kind of makes sense with the current flash technology, but I needed a device which runs at 1.8V in order to interface with another board utilizing such logic levels. It turned out that 1.99V are enough to erase the device, which is out of specs, but does not fry my other board, so it’s good enough for me to develop software.

    I guess the Microchip guys know that their stuff is “suboptimal”, but there is hope: http://www.microchip.com/mplabx/

    It’s still in Beta testing, but looks promising and more like an IDE one would expect in 2011, well the C compiler does not support the extended instruction set yet, so I can’t use it for my project,…

    Regards,

    Robert

  6. George Pikoulis says:

    Hello Nigel,

    I use MPLAB for debugging in my work environment for about 2 years now and all I can say is “Spot on”.

    * The editor is a joke, I never used it. I always use UltraEdit.
    * Using 16bit cores only fixes the large array problem.
    * If you try to directly change the value of a 16bit data variable from the Watch window, while using an 8bit core, will only change the byte on the even address. You have to manually add a line in your code or add a dummy byte variable located on the even address adjacent to the odd address, to test specific behavior.
    * Scope limitation and pointer dereferencing is what hurts me most. Combined with the fact that sometimes I use IAR EW for compiling EC++ code, while MPLAB doesn’t support C++ can lead to the very fun game of “Guess debugging”, where you guess the variable values of C++ only types like booleans, strings, classes etc. Of course you can pass them to more basic types inside your code for pre-release code, but come on…

    Yeah, it’s 2011 and I’m using a 2011 debugger…

    All these have lead me to put pressure on the management, to change platforms and migrate even our older projects to the new platform.

  7. hpro says:

    I wholehartedly agree! I was put in the exact same situation of inheriting an MPLAB+PIC based project and had the same frustrating experiences you had.

    It is very clear to me that the 8-bit PIC+MPLAB has been very severely outpaced by rivals Atmel. I’d go so far as to suggest that no one doing new-from-scratch design that has been in contact with both architectures will ever choose PIC.

    Why does the C18 compiler still force me to manually fiddle with linker files?!? Why can I not declare an array larger than 256 bytes? Aarhghh.

    • Max says:

      I am not a fan of MPLAB 8.x either, but you actually can declare large arrays, it is just not straightforward. You have to make room in the linker file to accommodate your array, but not to much to have other objects falling across bank boundaries. Then it is best to have your array declared on a dedicated .c file, so that there is no chance to have static variables outside the single bank where the generated code would look.

  8. Frank says:

    I use MPLAB in my daily work, also on a PIC18. I agree in most of your points.
    I want to add the pretty useless Debug/Release drop-down box in the Toolbar “Project Manager”. Changing this setting has no effect in the compiled output. You have to change the compiler switches in the build options: “Project” -> “Build options…” -> “Project” -> “MPLAB C18″ -> Dropdown-Box “Categories” -> “Optimization”.
    One more hint: compiling a single file can be done by right-clicking the file in the project window and selecting “compile”.
    Hopefully everything gets better if MPLAB X (http://www.microchip.com/en_US/family/mplabx/index.html) is finally released one day …

  9. Anonymous says:

    MPLAB-X is the way to go forward – a word of note is that there will also be a new upcoming C compiler suite from Microchip, which includes a single compiler for the 8-bit PICmicro family (aka MPLAB XC8)!

  10. Peter says:

    The IDE really is from another century. That is obvious and out of question (i use it myself).
    However, many of your points are quite feeble, which was already shown by other replies…
    It would be great to divide EmbeddedGurus in personal stuff (for those daily disappointments we all suffer) and expert stuff to avoid such personal opinion discussions. Cheers, Peter.

  11. Vince Sheard says:

    Nigel,
    We enjoyed reading your post. We appreciate hearing about tangible issues we can overcome with expectations. That way we have something to sink our teeth into. Some topics we may very well be able to improve while others may not make sense to every customer using the IDE.

    Regarding the debugging information and viewing the debug data in the IDE, I agree this has been a shortfall of the 8 bit tool chain but is getting a lot more focus at this time. With MPLAB X full release out later this year we will also be launching the XC8 compilers, in a few versions these will support the DWARF debugging format to a superior standard than Coff which is what is used in MPLAB 8. This will provide a better experience for the customer when they are debugging.

    MPLAB X has many features a new generation IDE would use. Fully customizable toolbars, Editor parsing that can eliminate the single file compile development process since it shows errors when you are editing the file. One click navigation from source to include files to prototypes etc. back and forth. One click “make, program and debug” on the target. True multiple configurations on a project, local history, task management, call graph, multiple debug tool support, macro expansion, code templates plus much more. You can read about many of the already solid features here http://www.microchip.com/en_US/family/mplabx/index.html

    I know you mention you do not try Beta tools but having constructive feedback on a beta product can only help improve a final release.

    We appreciate your comments and interest in our work.

    Thanks!
    Vince Sheard
    MPLAB IDE Manager.

  12. Bob Paddock says:

    “Breakpoints that aren’t where I put them: This may be due to optimization”

    This issue is indeed due to the optimizer. Where you place the breakpoint may not actually exist in the generated code.

    Solution is to place a volatile NOP instruction where you want the breakpoint. The volatile will prevent code-motion, so you at least get close to were you really want in the code.

    Here is what I do in the AVR GCC compiler, should be something similar in PIC:

    #if( BREAK_POINT_ENABLED > 0 )
    #define BREAK_POINT() do{ __asm__ __volatile__ (“nop”); }while(0) /* That is a zero, looks like the letter Oh in this font */
    #else
    #define BREAK_POINT()
    #endif

    While it is in theory possible that disabling the BREAK_POINT could introduce a bug by reordering the code, again, I have not seen it happen.

    • Lundin says:

      Why would you ever want to debug optimized code for? The only case where you would want that is when looking for bugs in the optimizer itself.

      The solution is obviously to disable optimization. If that can’t be done, then the compiler/linker is a poor one.

  13. Max says:

    “Breakpoints that aren’t where I put them: This may be due to optimization”. From my experience this may be caused also by using the hardware breakpoints without optimization.
    Hardware breakpoints, for a reason I still fail to understand, do not halt the execution where you place them, but few instruction after. This leads both to skipping the point you are interested to examine and to step into function even if you stepped over.
    Many PIC18F devices supports software breakpoints that have many advantages to the price of program memory worn-out. First they are precise, execution halts where you place them, next the stepping behaves as you expect and finally you can have as many as you want (if there is a limit, then it is very reasonable even for a PC programmer).
    The optimization option (of mplabc18) that really messes debugging up is the procedural abstraction – this causes the code to be rearranged so to avoid code duplication. This yields great gain in size, but, since the code is factorized in assembly, when you single-step through your code you literally wildly jump around the compilation unit. This is very confused even when you know this behavior and you often have to peek at assembly code and step a bit ahead to understand what’s going on and where the execution really is.
    I wrote some posts on my blog about the matter, a sort of Pic18F software project survival guide, I would be happy to hear comments and critics:

    http://www.maxpagani.org/blog.php?entry=20110520132037
    http://www.maxpagani.org/blog.php?entry=20110525234143
    http://www.maxpagani.org/blog.php?entry=20110531133303
    http://www.maxpagani.org/blog.php?entry=20110608135353
    http://www.maxpagani.org/blog.php?entry=20110614132842

    • Gauthier says:

      “Hardware breakpoints, for a reason I still fail to understand, do not halt the execution where you place them, but few instruction after.”
      Could this be related to pipelining?

  14. Gary Urista says:

    If you have ever done any assembly language programming on a PIC you will really appreciate how much can be done writing in C. The banked architecture is really hard to manage in assembly language and you don’t really notice that in C so there has to be a lot of tricky juggling going on. An 8051 processor was a better model than some PICs. Maybe the new PICs are a flat addressing scheme but I’m not sure. There was once another processor company that made an idiotic processor called an 8088 which was far inferior to the competition and you know where they ended up.

  15. Don says:

    I really like the GUI it looks great. But it is a nightmare to find where my familiar functions are. They should have kept the same menu system and on top of that additional fancy functions they introduced in x, so mplab8x users wont get confused. mplabx might be great for those who are new to microchip but as a 8+ year user of the mplab, after few days of trying I returned to mplab8. Mainly because I dont have time to findout how to do things as i did before efforlessly with mplab8. The main disappointment is inability to seperate editor windows, undock option isnt we want. oh i give up. Back to good old mplab8..

  16. Micro Engineer says:

    I will agree with pretty much all of the points here, and mention some things that are actually make me as an employee of a major manufacturer who uses PICs in production items to start considering other devices:

    The MPLAB IDE was not inherently great, that is for sure. Those of us who started as hobbyists didn’t really know what a “real” IDE was/is until moving over into ARMs and seeing what the competition had to offer.

    I realize that a hobbyist’s needs are typically much more limited, and in basic practical terms MPLAB is ok, but I have had frequent frustration and wasted time dealing with the Microchip tools and that includes the debugging tools.

    Now sometimes I have to use “real” editor like Notepad++ to do some work as well.

    When bad problems arise, you may start reconsidering some things.

    Issues I ran into:
    - Some released parts are not fully supported by the MPLAB SIM functionality! Meaning you’re limited in debugging…the SIM may do very odd things & eventually in some situations can be useless (Ran into this with a PIC24E)

    - The debuggers, when it comes down to it, are quite limited in functionality. A few breakpoints (which I can deal with) but it can be impossible to track down some bugs in a reasonable amount of time using the ICD3. Forget the RealICE – according to the documentation can’t use trace to capture sequential execution of instructions in order to debug very difficult traps without having to modify the code. (Note: the old ICE2000 could do it, I think, but doesn’t support a lot of devices)

    - I have had serious issues when debugging when attempting to view RAM contents, which are listed in a “File Register” window; sometimes doing a search fails even when it shouldn’t-other times, it hangs MPLAB

    - Yes, viewing data contents limits the values to a local or global scope (can’t see relevant variable values when I’m inside another function).

    - Using the simulator to debug logic/programming/etc errors is a hassle. Always have to spend a load of time just figuring out how to get the tools to do basic functionality.

    - The simulator supposedly allows for advanced stimulus & simulation of the operation of pins & peripherals, but eventually you’ll have to use the SCL language features, WHICH AREN’T OFFICIALLY DOCUMENTED, which means you’ll have to learn a another language just to use it!

    - Also haven’t always had the best results when contacting Microchip support. We seem to somewhat go around in circles and never really address the REAL issues that keep a design from moving forward.

    I do hope the next generation dev. tool (“X”) addresses a lot of this, but I don’t believe that is all of what makes for better, more time-efficient development. The debugging tools simply aren’t up to par in my humble opinion.

    But of course that seems to be related to the scope of what you’re doing, and the PIC18xxx families seem to be easier to deal with using the given tools available.

    Please understand I don’t mean to go on a long-winded rant or anything but I feel like Microchip has really dropped the ball on a lot of things. A lot of problems have existed for years and yet little to nothing has been done to make the development tools more legitimate and desirable resources.

  17. Misha says:

    “I was just left wondering why anyone would want to debug code without having it downloaded first”

    Well, if the code is already downloaded and running and programmer just wants to attach to it?
    However, I agree that the default should be to download before starting.

  18. PICSAREPOOR says:

    After spending years programming AVR, PSoC and MSP430 micro controllers, i have unfortunately ended up coming back to PIC’s for some projects not by choice, and found that nothing has changed, poor architecture, compilers and IDE’s that make me what to pull the remaining hairs off my head.

    The IDE and compilers are frankly a joke compared to the free offerings from the above and the PIC architecture is very poor.

    Hopefully i will only be spending a few months with these horrible devices and compilers and be getting back to programming some superior chips, i simply cannot understand why people are still using them:

    AVR’s have a larger community, better tools, better architecture and in most cases are cheaper.
    MSP430 – the tools are very good, not really any community as yet and TI datasheets need work.
    PIC’s – poor tools, poor compilers, poor architecture and cost the same, power power consumption (i could go on all night)

  19. Tom P says:

    Microchip debugger is fairly lame compared to Freescale BDM, or generic ARM Jtag debugging, or even TI Jtag.
    Limitations:
    RealTime Watch limited to 3 variables or so and you need to use Real Ice for this! What a joke! And the realtime watch is severly limited to 16 bits of data.

    Debug Monitor instead of dedicated silicon for debug. You have to specifically load a debug monitor, and then program differently for a release build. If you are trying to debug startup or sleep/wake issues, you can’t do it with debug mode since the debug monitor needs an active debug connection to even run! I’ve had to do hot attaches in the past to connect to a system that just woke up so we could probe for issue. You can’t do that here.

    Debug monitor state lost on power cycle, again you need to re-attach and resync/download your code or you end up with phantom break points from a previous session.

    MPLAB X is much better, but this even crashes and looses sync with the target.

    There architecture on 16 bit variants seems lacking also. No code execution out of RAM. Ti Picollo is a Harvard type architecture and that allows execution out of RAM.

  20. Brad says:

    I agree MPLAB X isn’t the best, but I found if you know what your doing, it works, most of the issues I encountered, requires the IDE to reboot, and it’s working again.

    Yes, the debugger is has limited functionality, but if you understand the functionality of the code at hand, you can still use the debugger by pausing, adding a break-point and than restart the program from where you left out. It isn’t the best solution, but it can help, “somewhat”. Major issues I had was that my timers wouldn’t run while debugging, ugh.

    I purchased a logic analyzer from Saleae, this helped me out a lot with timing outputs/inputs more than the debugger it’s self. It allowed me to thoroughly analyze my I/O ‘s, which helped determine the location of the issues I was fixing. I would consider this to anyone whose using MPLAB and programming PIC’s, its a little 150$ device, that’s easy to install and runs on any operating system. If your a Co-op Student like myself (or know a student), you can get $50 off, just ask Saleae.

    I feel all your pain, I am a 1st year Co-op student whose had little to none knowledge of embedded systems when I came into my placement, and I am learning how to program embedded systems through previous programmers code using MPLAB, if it wasn’t for the logic analyzer, i would be lost still.

    Hope this helps!

    Brad

  21. John Moore says:

    I have been *painfully* using MPLAB IDE and more recently MPLAB X.

    In particular:

    With MPLAB X and XC8:

    1) It doesn’t know how to do a stack trace. Since it also doesn’t support “jump out of reoutine”, this makes step debugging very painful.

    2) XC8 (a very good compiler/linker, mostly) has no way to force a function to be inlined. When one has to do stepping, this (combined with #1) makes certain kinds of debugging so slow as to be useless. I end up implementing in memory trace functions as if I was using stone age pre-1980 tools.

    3) Breakpoints sometimes don’t set. When you run or continue, *then* it marks the breakpoint as broken. It should do this when you try to set it!

    Frankly, I am able to develop more quickly in assembly language on the Freescale 8 bit’s than in C on the PIC, and that’s a damning statement about the PIC18 development environment! Oh, and since the PIC18 has such a primitive architecture (bank switching on RAM due to no 16 bit or greater registers), assembly language on it is very tedious. Overall, I would never recommend the PIC to a consulting customer. I would recommend Freescale or Atmel (and Atmel isn’t all that great, but it beats this debugging environment).

  22. Amarja Deshpande says:

    Why does it take too long to build certein projects. On what factors does the build time taken by the compiler depend upon. One of the project codes i had written took almost 5 minutes to build?…thats a huge time lapse..any solutions to this?

    • Nigel Jones says:

      In MPLAB X there is an option to perform parallel compilation on multi-core CPUs. This helps quite a bit when you are doing a large make. If all you want to do is compile one file then it of course does nothing.

  23. Jody says:

    MPLAB X is at v2.0 as I write this. It is riddled with bugs; The simulator is turning out to be so buggy and unpredictable it is, to me, looking to be as good as useless. I am encountering such strange behaviours that there is now no point even mentioning them on the forum since they are very hard to replicate and Microchip support, limited at the best of times, simply wouldn’t (be able to) help.

  24. yuval says:

    Hi folks ,
    All that’s said above lead to one end point – microchip are not investing in their ide , although “net beans” is really great environment. microchip’s dev engine is a hornet’s nest that sticks you painfully time after time . moreover they don’t have even minimum of tech support . not for paying customers nor for students and novices or any one else . I really wonder what is their business goal , is it worth to deal with their products .

  25. yuval says:

    stings . (sorry)

  26. Adolf Hilter says:

    Michrichip is a bizarre company, they are in the business to make MCUs yet having stone age
    tools or no tools at all (buggy as hell) to support their main business yet they are an extremely
    successful company!?!

    How come? Some one must buy their chips and think their tols are superb, right?

    So then all you whiiiineeeers must be wrong? right?

    For the time dsPIC33 was actually really OK so is PIC32 but the tools is butt-ware!

    I’m still using MPLAB 8 but moving over to ARM not that i want but becuse i must
    because everybody else is doing so, and in a couple of years we all MUST move over
    to INTEL low power devices because they have said they will enter this market and
    crush MCHP and ARM!

    I dont like C, its not a embedded language! Its actually pretty rotten language for
    MCU’s!

  27. Ken Tait says:

    Yes I agree this is the biggest piece of crap I have had to use. The PicKit3 is a joke, locks up all the time, never breaks at the breakpoint set, cursor gets lost..the list of bugs is endless in MpLab x.
    Run to cursor..ya right.

    Exactly what business is microchip in these days, it’s clearly not in cpus….

    It’s nearly impossible to get any productivity with this. Time is money and thisis costing me for sure all the time..
    Next project will be an ARM with decent tools…

    JMTC….

Leave a Reply