Moving projects from MPLAB 8.x to MPLAB X

Bogdan (Arhi in the forum) moved nearly 50 projects from MPLAB 8 to MPLAB X over the last few weeks, including the USB Bit Whacker 32. We asked if he could point out any bugs he might have encountered. Read the small interview below.

UBW32 is a large project, how long did it take you to move it?

The project leader of UBW32 was hesitant to move to MPLAB X so he kept putting it off. One day I decided to port it for him. Within 15 minutes the project was compiled and functioning 1:1 on MPLAB X.

Where there any difficulties, bugs, etc.., you may have encountered?

Well since I use Linux, many of the include commands that use the front-slash ‘\’ have to be rewritten with back-slashes ‘/ ‘.  That was 90% of the problems. The rest were case-sensitive file names, also in the include statements. For example if the file name is theFile.h you can’t include “thefile.h”, but the exact use of upper, and lower cases in the name.

That sounds easy enough, anything else?

Well there were some issues with the compiler settings not being copied over the way I expected, but that problem was fixed with MPLAB X v1.2 release.

7 comments on this post.
  1. Victor:

    Sorry for nitpicking, but ‘\’ is backslash, and ‘/’ is just slash, no “front”. So he really converted backslashes to slashes.

  2. arhi:

    :)
    few clarifications …

    UBW32 project was looong time ago, I think it was BETA4 or BETA5 of MPLABX that was actual and Brian didn’t ask for it, I converted it for myself and after I did I sent him the archive with project. I have no knowledge if he used that to base his MPLABX version of UBW32 or he did it from scratch… the only reason I mentioned ubw32 was because it’s bigger then your average small project and it took 15 minutes to convert it..

    I converted bunch of backslashes to slashes, I don’t even thing backslash is regular even on windows, it’s an escape character in C/C++ so stuff like #include “USB\Usb.h” should be illegal on windows too (MAL was full of them), in best case scenario it could be #include “USB\\Usb.h” ..

    Case mismatch problem is 100% related to MAL, I had no issues with any of projects I converted exept for microchip files that were inconsistent among themselves.

    I found few bugs in BETAx and 1.0 and 1.1 .. and they are all fixed, using 1.2 attm and the only problem is with regards to full screen on 64bit linux and that’s some java problem that will hopefully be fixed soon… for now the workaround is not to use mplabx in full screen

  3. Brian Schmalz:

    The UBW32 code is more tricky than most because of the dependence on particular versions of MAL. I did try converting it several times with the early versions of MPLAB X beta, and the problems I had were mainly due to bugs in MPLAB X and incompatibilities with MAL. At one point it became very frustrating and I gave up. The latest version of MPLAB X (1.2) is quite good, and the latest version of MAL works well with it, I believe. It took Microchip a long time to get all of the MPLAB X issues in MAL worked out. However, as arhi says, converting the old project into MPLAB X wasn’t a big deal – as long as you clean up any issues with MAL. Thanks for bringing up the project again here guys.
    *Brian

  4. Teslafreak:

    A lot of people call it forward or front slash. The convention is mostly so people can ensure you are talking about the correct symbol.

    I think I hear it as forward slash more often then just slash.

  5. arhi:

    weird, I am into computers since 1981, I lived on 3 continents in 6 countries, visited more, had customers from all over the World and never heard the term “forward slash” till few days ago :D …

    I see that wiki also mentiones it (just searched for it) but in every day usage – never, it’s a slash and a back-slash… it always was :)

  6. voidptr:

    :)
    cool to see that v1.2 is good,
    how about coverage of the complete pic families, 8bits to 32,
    is everything can be compile now ?

  7. arhi:

    On MPLAB v8 you had

    C18 – you still have C18 (they talk about removing it when they get XC8 working stable), it works just like C18 on windows and mplab 8

    C30 – it’s being replaced by XC16, should be 100% compatible with C30 (I haven’t tried it, I use C30 that was available for download until recently)

    C32 – it’s being replaced by XC32 and should be 100% compatible with C32 (I haven’t tried it, I use C32 that was availble for download until recently)

    Additionally to what you had with mplab v8 now you have
    – C8 that should work with ALL 8bit devices and not only 18F’s (so 10F, 12F, 14F, 16F and 18F’s). It’s supposed to be based on Hitech C compiler (no clue, never tried it)
    – lite versions of hitech

    I haven’t tried C8 but I did tried lite version of hitech and it’s utter crap as it produces unusable bloated ugly code… but hitech lite was always crap, that’s not related to mplabx …

    Basically, with mplabx you have more then you had with mplab 8, it’s better interface, modern, based on netbeans (I personally find netbeans to be order of magnitude better then eclipse so this is a great + from me to mcp)… it works both on Linux and windows, haven’t tried it on Mac but I think it works there without a problem too …

    As I mentioned, converting project, a large complex project, from mplab 8 to mplab x is really piece of cake and if you don’t use MAL, it’s in most cases just matter of importing the project into mplabx and it works immediately..

Leave a comment





Notify me of followup comments via e-mail. You can also subscribe without commenting.