MPLAB-X Plugin...

Discuss the Integrated Development Environment (IDE)

Moderators: David Barker, Jerry Messina

User avatar
Coccoliso
Posts: 152
Joined: Mon Feb 17, 2014 10:34 am

Re: MPLAB-X Plugin...

Post by Coccoliso » Wed Aug 12, 2015 7:06 pm

Jerry Messina wrote:I've always liked the PICKit2 and even though you can add programming support for some new devices to the PK2, that only gets you so far.
Many people who have worked with the PicKit2 and continue to do so because it is the only one that does not need any MPLAB / MPLAB X-installed to work with the command line.
For example, I've purchased over a year ago, I installed its MPLAB to make it work but I never used because I feel better with the PicKit2 (without debug) and I did not find the need to replace it
Propose a survey .. :wink:

User avatar
octal
Registered User
Registered User
Posts: 586
Joined: Thu Jan 11, 2007 12:49 pm
Location: Paris IDF
Contact:

Re: MPLAB-X Plugin...

Post by octal » Wed Aug 12, 2015 8:17 pm

Coccoliso wrote: Propose a survey .. :wink:
No need for a survey. I'll keep updating the plugin for each version until I can see that MPLabX v3.xx is stable and mature enough. From my personal experience, there will always be people using v2.xx because they can't upgrade their Java Virtual Machine for some reason, or because they don't got the ICD3 or PICKitxx driver to work correctly under MacOS and so on.

Jerry Messina
Swordfish Developer
Posts: 1469
Joined: Fri Jan 30, 2009 6:27 pm
Location: US

Re: MPLAB-X Plugin...

Post by Jerry Messina » Wed Aug 12, 2015 8:25 pm

There are command-line interfaces available for the PK3 (PK3CMD.exe), ICD3 (ICD3CMD.exe), and RealICE (RealICECMD.exe). You can find them under MPLAB IDE\Programmer Utilities. There's even the equivalent available under MPLABX in the mplab_ipe folder.

As I said I've always liked the PK2, but if it's not being supported by Microchip anymore then it's basically a dead-end. Doesn't mean it's not useful, just that does it really need to be supported by MPLABX when there's other ways of using it?

Chances are you could even rig up a bat file to be called as a post build step to run a command-line programmer if programming's all you're interested in. That would work with just about anything.

Probably the real question is if you're not using MPLAB now, why would you want to use MPLABX?

User avatar
RadioT
Registered User
Registered User
Posts: 157
Joined: Tue Nov 27, 2007 12:50 pm
Location: Winnipeg, Canada

Re: MPLAB-X Plugin...

Post by RadioT » Fri Aug 14, 2015 12:28 pm

OK, Octal, thanks for all the great work!
I got the plugin set up in MPLab X 2.35.
The test program compiles fine!

However, when I went to compile an existing program, I received the following error:

Code: Select all

make -f nbproject/Makefile-default.mk SUBPROJECTS= .build-conf
make[1]: Entering directory 'C:/Program Files/Mecanique/Swordfish/MonitorV6/MonitorV6.X'
make  -f nbproject/Makefile-default.mk dist/default/production/MonitorV6.X.production.cof
make[2]: Entering directory 'C:/Program Files/Mecanique/Swordfish/MonitorV6/MonitorV6.X'
make[2]: Leaving directory 'C:/Program Files/Mecanique/Swordfish/MonitorV6/MonitorV6.X'
nbproject/Makefile-default.mk:81: recipe for target '.build-conf' failed
make[1]: Leaving directory 'C:/Program Files/Mecanique/Swordfish/MonitorV6/MonitorV6.X'
nbproject/Makefile-impl.mk:39: recipe for target '.build-impl' failed
make[2]: *** No rule to make target 'MonitorV6.bas', needed by 'dist/default/production/MonitorV6.X.production.cof'.  Stop.
make[1]: *** [.build-conf] Error 2
make: *** [.build-impl] Error 2

BUILD FAILED (exit value 2, total time: 1s)
I thought it was a path thing, so I installed MPLab 2.35 on an XP computer and re-ran everything. I still get the same error.

Any ideas?

73's,
de Tom

Jerry Messina
Swordfish Developer
Posts: 1469
Joined: Fri Jan 30, 2009 6:27 pm
Location: US

Re: MPLAB-X Plugin...

Post by Jerry Messina » Fri Aug 14, 2015 1:33 pm

Are all your source files under the 'Swordfish/MonitorV6/MonitorV6.X' directory?
And, is your main program file named 'MonitorV6.bas'?

There may be a way to change those, but that's two things that'll keep a new project from building.

Also, do you have access rights to be able to write to the "C:/Program Files/Mecanique/Swordfish/MonitorV6" directory? I don't think win7 would like that.

User avatar
RadioT
Registered User
Registered User
Posts: 157
Joined: Tue Nov 27, 2007 12:50 pm
Location: Winnipeg, Canada

Re: MPLAB-X Plugin...

Post by RadioT » Fri Aug 14, 2015 2:27 pm

Hi Jerry,

Yes, the files are under there. I am also running this in XP so it would work fine.

I also set it up in Win7 and get the same error.

It's like MPLab is not finding the files. I copied them into the same subdir as the example file that does compile, yet still the same error.

Unless MPLab is complaining about not finding library. But you would think it would indicate that.

-Tom

Jerry Messina
Swordfish Developer
Posts: 1469
Joined: Fri Jan 30, 2009 6:27 pm
Location: US

Re: MPLAB-X Plugin...

Post by Jerry Messina » Fri Aug 14, 2015 2:38 pm

I copied them into the same subdir as the example file that does compile, yet still the same error
You have to be careful... you can't move the files around.

When you create a new project (let's call it 'newprojectname') you get the 'newprojectname.X' subdirectory created.
That's where your files have to be located, and the main file HAS to be named "newprojectname.bas"

In the project viewer under 'Source Files' make sure that "newprojectname.bas" is listed.

User avatar
RadioT
Registered User
Registered User
Posts: 157
Joined: Tue Nov 27, 2007 12:50 pm
Location: Winnipeg, Canada

Re: MPLAB-X Plugin...

Post by RadioT » Fri Aug 14, 2015 2:43 pm

OK, I got it! As suggested, I noodled around the different directories. The original *.bas file was in a directory to start with, and when the project was created, MPLab X created the new project subdirectory in that directory. So, as you say, MPLab expected the .bas file to be placed into the project file <project>.X

I did that...and now it works!

So, something to keep in mind when using a pre-existing project file. It needs to be copied into the new <projectname>.X directory.

Thanks,

-Tom

Jerry Messina
Swordfish Developer
Posts: 1469
Joined: Fri Jan 30, 2009 6:27 pm
Location: US

Re: MPLAB-X Plugin...

Post by Jerry Messina » Fri Aug 14, 2015 3:40 pm

Yeah, it's pretty finicky as to where the files are located. I don't know if that's solely an mplabx thing or if it's just the way the plugin is setup.

It seems you can point to files in different locations in the 'projects' navigator, but it doesn't use them. It would be nice to be able to use an existing dir structure and file names without having to make everything match up, but I suppose it is what it is. Right now, my main .bas file is never named the same as the project source directory. Guess I'll have to change that.

I'm happy that it works at all! Octal's done a great job getting it this far along.

User avatar
octal
Registered User
Registered User
Posts: 586
Joined: Thu Jan 11, 2007 12:49 pm
Location: Paris IDF
Contact:

Re: MPLAB-X Plugin...

Post by octal » Fri Aug 14, 2015 8:40 pm

Hi Jerry, RadioT,

sorry that you have some troubles with MPLabX IDE file management.

Well, I'll try to explain some of the problems I faced with Microchip file management in the project.
Actually, you must understand that in the "Project" view of the IDE, the tree structure you are seing is a pure "virtual" structure. It means, on disk, your files can be anywhere. The Project view give you the possibility to organise your files in virtual folders. Those virtual folders do **not** necessarily map to physical folders on disk.
So, you can right click the "Source Files" virtual folder, create your virtual tree view and structure, and then right click each virtual subfolder you created and select the option "Add exsiting items..." from the menu in order to add your *.bas files.

Since Swordfish basic can access files in the folder and subfolders contained in the project folder (in fact in the folder containing your SF PROGRAM file), and it can also access files in the SF "UserLibrary" subfolder, you can simply add those files to your virtual directory structure and then have them accessible from the project view.

If you don't add those files, they'll be compiled anyway as SF compiler will look for them when they are included in the usual SF way (current prog folder, UserLibfolder, Lib folder, ...).

Actually, there is an option in the context menu when you right click the "Source Files" virtual folder (blue folder) in the "Projects" view of the IDE. This option is named "Add existing items from Folders". This feature is intended to add the selected folder(s) and its files to your project, and create associated virtual directory structure automatically (all above described work automatically).

UNFORTUNATELY Microchip made this option specific to the "C" language soure files, and then, it does accept (automatically) only *.c, *.h, *.asm files. If you select any folder with it and ask the directory selection window to use ALL FILES, it'll create the virtual directory structure for you, but it won't add any *.bas file. You'll have to add *.bas files by hand as explained above (using "add existing items..." option).

I need to implement the same functionnality (and hide Microchip one related to C files) by hand in the futur.

As for the MAIN file that need to have the Project name, this is a choice I have been forced to do.

In fact, the make file builder called automatically when you click build (for release or debug) need to pass the Swordfish PROGRAM file as a parameter to SF command line compiler.
The PROBLEM is that when you create a new project, I need to know which file in the project directory IS THE MAIN Swordfish PROGRAM file.

I had 4 alternatives:

1- Force the user to name his main file "main.bas" or "program.bas". I don't like this option because SF will give this name to final *.hex file, and thus, all your projects will have the same output hex name :(

2- Give the user the possibility to select the main program file, and use the menu to tag it as MAIN program file. (Turbo Pascal 5 and 6 users remember that in the IDE they had this option in order to be able to compile the project without having to have the "Program" file opened or selected in the IDE) . This means I had first to add this option, store this information somewhere in the project file, and update this information each time user change or rename his program file. This is too much work. It also need to be documented.

3- Force user to name the PROGRAM file the same as the Project. This is what I prefered as it's very easy to deduce the name of the file to pass as a parameter to the SF command line compiler.

4- Create a full SF code parser that parses all the project files and then guess the main program file directly (as it's done actually by the SF IDE). I have an almost working parser, but I need to finish the Preprocessor Options handling to have it fully working. THIS IS THE WAY TO DO things correctly. Unfortunately, due to some (personal life) events this year, I didn't finished this part of the work :( I'll manage to work on it in few days, and if I got it working completely, I'll remove the constraint on the program file name completely. This full parser will also let me implement code folding (and eventually syntax completion).

User avatar
RadioT
Registered User
Registered User
Posts: 157
Joined: Tue Nov 27, 2007 12:50 pm
Location: Winnipeg, Canada

Re: MPLAB-X Plugin...

Post by RadioT » Sat Aug 15, 2015 1:07 pm

Has anyone seen problems setting up watches in MPLab X?

Here is what I am encountering:

- adding a watch for Special Function Registers - by clicking on "SFR" on the right top side of the Add Watch window - no problem.

- adding a global parameter by clicking on "Global Symbols", and then clicking on a function name that contains a number of parameters, such as "SetBaudrate" - it goes into the list but the values of variables inside the function are not listed. Instead, a single a hex value is given. I have no idea if that is in fact the value of the output of the function - I can't set the "type", it just says "void". I hope Watches do not depend on C features we don't have in SF.

- adding a global parameter by clicking on "Global Symbols", and then clicking on a parameter that is defined in a module - for example the variable "[Main] initializationRoutineCompleted (bit0)" or "[I2C] interrupts_enabled (bit3)". These do not appear on the Watch list. Typing them in directly also does not work.

I do see the new "Variables" windows that DOES show variables in a function but you can't add parameters to them like in the old Watch window. It updates each time you go to a new function.

Any suggestions? Perhaps there is a setup parameter that needs to be pre-set in order for the COF file data to be created correctly (if, in fact, that is the cause)? Is there a difference in what MPLab X vs. MPLab 8.xx is looking for in COF files - perhaps yet another small detail that was changed with the creation of MPLab X? I am using MPLab X version 2.35. Or is there a better way to set up the Variables window?

-Tom

Jerry Messina
Swordfish Developer
Posts: 1469
Joined: Fri Jan 30, 2009 6:27 pm
Location: US

Re: MPLAB-X Plugin...

Post by Jerry Messina » Sat Aug 15, 2015 3:08 pm

Debugging is a bit of a work in progress I think. The COF file debugging format has changed for mplabx (once again Microchip made something "better").

David has a beta version of the compiler available (2.2.2.5.B6) that address some of the changes, but some of them you may not like (I'd post a link to it here but I'm not sure if he wants it public or not. Check w/him).

From what I understand, they removed the ability to specify a module name in the watch list, so watches like "[main] b" are no longer valid. All you get is a single "b" variable (more on this later). Also, watches for single bit and boolean variables doesn't work very well. Last I checked you can find the byte that the thing is in, but it won't isolate the bit... just the whole byte so you have to know it's bit position. There is a way of using structures of bits to get symbolic names, but that requires changing your code.

Some of the operation changes depending on whether you use the std 2.2.2.5 release vs the B6 version, so my comments may not match 100% what you're seeing.
- adding a global parameter by clicking on "Global Symbols", and then clicking on a function name that contains a number of parameters, such as "SetBaudrate" - it goes into the list but the values of variables inside the function are not listed. Instead, a single a hex value is given. I have no idea if that is in fact the value of the output of the function - I can't set the "type", it just says "void"
The "Variables" tab doesn't seem to work at all... just "Watches". It's not going to show what parameters are from where... it's just a big list of all the symbols. Clicking on a sub/function name is showing you the CODE address of the symbol, not it's variables.
I hope Watches do not depend on C features we don't have in SF
That just may be the case. Some of the features seem to be expecting C (like no more bit types).
- adding a global parameter by clicking on "Global Symbols", and then clicking on a parameter that is defined in a module - for example the variable "[Main] initializationRoutineCompleted (bit0)" or "[I2C] interrupts_enabled (bit3)". These do not appear on the Watch list. Typing them in directly also does not work
As explained above, not more "[module]" or "(bit3)" qualifiers.
I do see the new "Variables" windows that DOES show variables in a function but you can't add parameters to them like in the old Watch window. It updates each time you go to a new function.
I think that functionality disappears entirely in B6. As I said, I don't see anything in the 'Variables' tab.
[EDIT]: I take that back. I DO see entries in the 'variables' tab. There's a little toggle box at the left of the window for "show all locals/ show only variables used near PC location (whatever THAT means), and I had that turned on. I didn't even know that was there.

One of the things I'm having a hard time with is the big list of flat symbols. For example, if you use some common name like 'i' to set a watch it may not follow it as you go into and out of routines that have local 'i' variables.
[EDIT]: And this too. Things work MUCH better when you have "show all locals" turned on (or the other way turned off, however you want to look at it).

User avatar
RadioT
Registered User
Registered User
Posts: 157
Joined: Tue Nov 27, 2007 12:50 pm
Location: Winnipeg, Canada

Re: MPLAB-X Plugin...

Post by RadioT » Sat Aug 15, 2015 6:45 pm

eeyouch, losing the ability to designate a sub in watches hurts. That is a strange one. Well, it's easy to switch debug hardware interface USB drivers between 8.xx and MPLab X, so we're back on 8.xx and will watch developments in X.

-Tom

Jerry Messina
Swordfish Developer
Posts: 1469
Joined: Fri Jan 30, 2009 6:27 pm
Location: US

Re: MPLAB-X Plugin...

Post by Jerry Messina » Sat Aug 15, 2015 7:52 pm

eeyouch, losing the ability to designate a sub in watches hurts
Tom, it's actually not that bad. All this time I never realized I had that button on, so that's why I couldn't see the local variables. The locals automatically appear for you when you enter/leave a routine, so you don't need to do anything special to see them. That's sort of handy.

User avatar
octal
Registered User
Registered User
Posts: 586
Joined: Thu Jan 11, 2007 12:49 pm
Location: Paris IDF
Contact:

Re: MPLAB-X Plugin...

Post by octal » Sun Aug 16, 2015 10:42 am

Hi Tom,
Jerry Messina wrote:Tom, it's actually not that bad. All this time I never realized I had that button on, so that's why I couldn't see the local variables. The locals automatically appear for you when you enter/leave a routine, so you don't need to do anything special to see them. That's sort of handy.
I agree with Jerry, it's far more useful to have the local variables when the context permit it (appear/disapear when you enter/leave a function).
Actually, the plugin do not handle the debug stuff explicitely. All debug infrastructure is provided by Microchip. The SF plugin only provides needed editors for syntax highlight, and project settings. So all limitations you may incounter are due to the way debug infrastructure handles COFF file, and I simply cannot override any behaviour at this level (unless I rewrite a full debug infrastructure, which can take easily one year of development full time).
As for bits, I think you simply can't see them separately because COFF file do not have any ability to represent BIT data type. In "C" langugage, you can't see this behaviour because ANSI C (like XC8, MCC18, ...) do not have this data type. You can bypass this limitation by packing your bits explicitely within enums/structures. Under old MPLab SF was showing something like xx(bit0), xx(bit1), ... Unfortunately this do not work under MPLabX debug infrastructure.

For having used MPLabX and SF with the plugin, I personally will never get back to MPLab. Seriously, while there are always something you lose when moving forward, under MPLabX I have tons of tools I can't have under MPLab. if I consider the modification history of editor and the netbeans GIT plugin for source management alone, I can't see myself looking back to old MPLab.

Post Reply