MPLAB X v1.0 released
After a long beta testing period Microchip finally released MPLAB X V1.0.
MPLAB X is the new integrated development system for Microchip microcontrollers. It is built on the Java platform so Mac, Linux, and Windows users are supported. Here are some major features of MPLAB X:
- Based on Java / Netbeans.
- Supported under Windows, Linux and Mac OS X 10.5 and Mac OS X 10.6.
- Newer, more functional GUI.
- MPLAB C32 (for PIC32MX), C30 (for PIC24 and dsPIC), C18 compilers are available.
- HI-TECH C Lite Compiler for PIC18s, and HI-TECH C Lite Compiler for PIC10/12/16 are also available.
Via lucadentella.it
This entry was posted in software and tagged microchip, MPLAB X.
Comments
works like a charm. I’m using mplabx since b3 and this is really production quality now.
Is DP transfering to MPLABX now?
It will be a little while.
Is there a change list? I’ve been using beta 8 for a while now :-)
What they should do, is improve the MAL!
after b8 they fixed most (I think all) bugs in mal
That’s good news :-) I’m not too much a fan of MPLAB 8…
I haven’t used mplab8 since mplabx b4 :)
What mplabx still lacks compared to v8 is simulation tools in ide but I never used that in v8 hence I haven’t missed it :D
Nice tool.
However, I’m thinking about opensource alternatives. I prefer free software when it is possible. Mplab is free of cost but not free software. It is good for most projects but sometimes opensource could be even better.
Doing opensource hardware project entirely with opensource software tools looks more better.
I tried gputils and sdcc (these are free software tools for PICs with 14 and 16 bit instruction word).
These are not as mature as Mplab, but it worth to try them. In the last weeks / months these tools improved a lot.
Dos anybody have expereience with them?
plab ide is 100% free, its not “open” but it is free.
compilers are almost free :)
sdcc is piece of shit, don’t waste your time with it.
gputils are ok but last time I checked they still lacked support for lot of devices
There is some open source version of C32 and C30 iirc but I never tried it out
Has anyone been able to get the in-circuit debugging working on Linux? I tried with PicKit2 and a 18F4550, but no joy (yet). Otherwise it works well… and a big thumbs up to Microchip for supporting Linux.
Yes I did, with both PICKIT2 and PICKIT3, works like a charm. Only thing is – you have to call mplab with 32bit java (was not working with 64bit java). Now it looks like v1.0 works also with 64bit java but I haven’t tried out debugging yet (b12 worked like a charm with both pk2 and pk3 from linux fedora 14 64bit running 32bit jre)
I hope Microchip are listening. Here are my points of issue with MPLABX under Linux as it stands.
1. It needs root to install even if you’re installing it in your home dir.
2. The “please reboot for the changes to take effect” msg after you install is quaint and unneeded.
3. The ~1k of text readme’s that have been blown out to 50+k with Microsoft Word to HTML generator.
4. The fact that there are “plugins” listed to install that only tell you they only work in windows when you try to use them. They pop-up a helpful dialog that says “this option only works in windows”. Helpful.
5. The fact that you CANNOT stop it from making a “MPLABXProjects” directory in your home dir even after you’ve change the preferences and it’s not using that dir any more. (I cannot make it stop).
6. There isn’t a simple command line util to program a PIC using the ICD2/3 or let alone a gdb proxy. You MUST use the IDE if you want to use the tool. They could eliminate 90% of their support problems if they let people use the tools that are native to their operating system.
7. The dumping of support for ICD2 when basically the framework for a working device was already previously released forcing and upgrade to ICD3. (which I did begrudgingly)
This MPLABX is a catch-up to my mind. Atmel and the rest of the gang have very good Linux/OSX tools via themselves or the community and Microchip has been caught dragging behind in the bad-old-days of Windows-only-land.
I agree with 100% everything you wrote :D. I didn’t notice they removed support for ICD2 (I don’t have ICD) but for pickit there is a command line programmer (not part of mplabx but available for download), maybe there’s also for icd. That’s for programming only, still no gdb proxy.
Btw, the need to be root to install it is seriously flawed IMO. They are iirc changing some libraries (libusb or something like that) on system and that’s plain wrong. You should be able to install it in home as user, if they need to change system libs they should put them in the lib directory under mplabx directory and add LD_LIBRARY_PATH into script that starts the ide .. this way they can preload any libraries and use them instead of system ones …
Yup *any* executable that requires root to install to my mind is hiding things from me and shouldn’t be trusted no matter who it is that made it.
Screwing with system libraries (like libusb) is a HUGE no no.
Alain,
Since you posted the same questions at the MPLAB X forum, we’d like to address them over there.
http://www.microchip.com/forums/m621829.aspx
Thanks for your input.
Jose
@Alan Garfield
You do bring-up some of the point that make my life like hell. However, while the Atmel side is much better in that aspect. I might point out that Atmel did let go of their AVR32Studio in favor of the MS Visual Studio based AVR Studio 5. Even, when I tried out the IDE on Windows, it was just horrible. As for the toolchain, they don’t give instruction (AFAIK) for building it. All what you get (beside the outdated deb) is a pre-build bin by some guy with a user name hudson. So, it’s not really so much better.
This is true, but the community in AVR-land has taken up the slack somewhat. Tools like AVRice and avrdude simply do not exist for the ICD2/3. They’ve written drivers for them in java so why not make a small command line java application that is simply an ICD programmer. Heck make a gdb proxy while they’re at it. Making a cusom IDE is a tall task and fraught with many issues ala AVR Studio 5, but at least in AVR-land there are alternatives. Unless you buy a PICKit2/3 you’re screwed.
There is an MDB command line, it has basic programming functionality but it needs filling out. Ala GDB. It is not shipped with the IDE on v1.0 but will be in future releases. It is in the SDK which will be posted on the opensource4pic website. At this time beta 7.12 SDK is posted there.
So your commandline request is very close to being fully functional for those who need it.
Thanks for the reply Vince. 395MB SDK for a few kilobytes worth of util. :(
As I said CLI utility will be shipped with future versions. The utility itself is small.
The SDK is a full SDK which will allow development in almost any facet anyone wants to.
I applaud that mchip is working on all this. Compared to winblows only version philosophy that existed for years this is a huge step forwards. Guy’s don’t forget this is mplbax version 1.0, let’s give them some credit for working on it. It’s important that they are working on MDB/GDB and other cli tools in the multi operating system version. Yes maybe it’s not 100% usable at the moment, maybe it’s buried in the SDK, it’s still beta … let’s be constructive and report bugs, test stuff, give ideas … way better then “this is shit, avrdude rulez” ..
@ Alan
if you find 395MB much….
go and try to install Xilinx ISE webpack. 14 GB!!! They offer an uncompressed 5GB tarball for download. You have to unpack this to get a folder with many other packed files and run the installer.
14 GB will end on your harddisk. 2x5GB for the installation. This makes 24GB after your installation is finished. Starting the IDE and run a project and you see in the terminal window half dozen of little CLI doing there job.
Seriously that is plain wrong! If they wanted to provide all data for every single chip in there portfolio why not establish some kind of plugin-system update. If a new architecture is selected for a new project, check for it and download necessary files. Or at least keep them packed as long as they are not needed.
So yes microchip is doing better already, will like to see the SDK appearance. And applause to them, it seems they are reading this lines and even have enough balls to answer :)
“IDE on Windows” – Looks like AVR Studio 5.1 is imminent so hopefully some improvements.
“toolchain”, “building” – avr-gcc 4.5 on Linux was recently released by one of the members of the AVR community of users.
“hudson” – Hudson (a continuous integration tool) may be used by Atmel. Atmel’s AVR toolchain has a bug that indicates “hudson”. One may be able to work-around the bug or simply step back to WinAVR (Windows) or avr-gcc 4.3 (Linux deb). Hopefully Atmel will also release a new Atmel AVR toolchain with AVR Studio 5.1.
Great
even I do not like PIC and even it seems there are still some trouble on Linux,,, it is another big vendor who decided to add Linux support into there IDE.
This shows that Linux is becoming a more and more important platform for major players.
Often you find crippled IDEs and if you look carefully you will notice that behind all this bloatware there are a couple of terminal programs who are doing the real important job.
I still can’t understand why companies like to present a IDE if most programmers just would be happy with a good describtion how to use the command line tools and how to integrate them with there very own toolchain.
VI/VIM/EMACS + some Makefile, scons, cmake or whatever, is all you need to become happy. If someone prefer a heavy GUI usage, there could be Eclipse. If none of that fit, people would start to get there own little GUI-wrappers.
“I still can’t understand why companies like to present a IDE if most programmers just would be happy with a good describtion how to use the command line tools and how to integrate them with there very own toolchain.
VI/VIM/EMACS + some Makefile, scons, cmake or whatever, is all you need to become happy. If someone prefer a heavy GUI usage, there could be Eclipse. If none of that fit, people would start to get there own little GUI-wrappers.”
Linux is still scary for most people because they wouldnt like to get their hands dirty tinkering around the system.
I use linux and am quite comfortable using MPLABX on it.
Just my opinion.
If i was paying good money for getting a toolchain up and running. i would not want to waste time trying to set it up. I’d want it to run right out of the box. Tinkering around CLI would be the last thing i would want to do. Not to mention lack of a visual representation of debugging and structure of the program.
CLI does the job sure. But GUI makes life easier.
While i am exactly not a big fan of the limitations of MPLABX on linux i sure prefer it to windoze which takes eternity to do anything productive with its overbloated code structure.
IMHO while MPLABX on linux might not be the best IDE+Compiler combi for PIC it does the job.Well atleast for me.Take the case of eclipse and AVR or ARM. Pure PITA to get it up and running. I gave up on AVR and ARM because i did not like being forced back to windows just for the sake of programming the respective MCUs. However i have some respect for PIC because AVR and ARM toolchains for linux have been around the block much much earlier than PIC and still are not half as refined as MPLABX. That for itself should say something about MPLABX.
It is like our programming the little PICs themselves. Inspite of careful planning and methodical working, we do need a few iterations to get the right kind of output.
I suspect that microchip is in the process. I do sincerely believe that we can look forward to subsequent releases of MPLABX.
“Tinkering around CLI would be the last thing i would want to do. Not to mention lack of a visual representation of debugging and structure of the program.
CLI does the job sure. But GUI makes life easier.”
Umm I might be wrong but I’d be willing to bet at least more than half of the worlds software is/was written tinkering around on the CLI. Just because you don’t like to use it doesn’t mean the rest of us are wrong in doing so. GUI’s can equally make life much much much harder. Who says you can’t have a “visual representation” of a program on a CLI. I’ve been using vim for more years than I can remember and I’ve never found it to be a burden or lacking in “visual” features.
Why go to the lengths of making complex IDEs and tools, yet still not provide a simple command line programmer/debugger for the ICD2/3? Most compilers from Microchip now work on the command line which is great! However there is STILL no command line tool officially from Microchip that supports ANY of their programmers in Linux/OSX. The programmers that are supported are ones that are done so by 3rd parties.
With a supported command line tool I wouldn’t even _need_ to worry about MPLABX.
I use pickit2 mostly and it works like a charm (make flash -> bang the firmware is in the pic) … I understand other tools are not supported yet / are supported in the beta stage only (sdk that is mentioned here in comments) .. so maybe if we give them another few months they will make all the cli tools too :)
I was not judging anybody. Each one to his own. I did say it was only my opinion.
:-D
As arhi said. It is their first release after beta. They did clean up a bunch of bugs in the beta process. I do rather like the course they are taking.
I am pretty sure public forums would be taken very seriously by microchip or for that matter any company who would like to stay in business.
So it is only a matter of time before we see standalone CLI tools for MPLABX and linux.
@Alan
Going a bit further i m pretty sure that programs were written in assembly. and further down in 0s and 1s.
We do like the comfort of C/C++/C# in programming .
CLI is flexible and powerful. period.
:-D
I am not, as i said, judging those who like CLI to GUI. It is just my take on things.
I am with you on standalone tools however. I do miss the Pickit2 application on windows for my present pickit3 on linux.
you do not need to tinker with mplabx – it just works (at least version 1.0, the betas required some tinkering). The only prerequisite is that you have java 1.6 installed on your system. On Fedora 14 and Fedora 16, both 64 bit, it works out of the box, pickit2 works, pickit3 works ..
You might like or dislike the ide but imo netbeans is 1000000 times better and faster then eclipse. Also noone prevents you from making and using makefiles and editing your sources in vi or emacs ?! All c compilers that mplabx use on linux work from command line and with make system without any problems.
“All c compilers that mplabx use on linux work from command line and with make system without any problems.”
Exactly, but what good is a compiler if you cannot program a device. Having windows around or MPLABX running just to program/debug is just silly to my mind.
Is there some magical way to get the MPLABX to work with PICKIT 2… I am trying to use it with a pic12F1822 and all I keep getting is unable to conect to programmer, bla bla…In fack I have never sucesfully programmed any MC using mplab and PICKIT 2, only using the stande alon app…
Is there a guide on how to setup pickit2 for mplab? BTW I am using a clone…
What os? I just programmed 18F2550 with pickit2 and mplabx 1.0 on linux 10 minutes ago
windows 7 64 ultimate ovo ono :)
Well my point is,
before you go and release a half baken GUI-based IDE, why not spending some time in well documented well organized CLI.
All the other stuff might be solved rather quickly buy the community itself. If Chaitanya likes to get a IDE with many many windows… no prob with this. He can have netbeans, eclipse, or even get his own in his favourite desktop programming language. Why not something in python, some integration in already exisiting IDEs, etc.
Actually I get more and more annoyed about this Java stuff, since it seems to bring more and more trouble then any good, it breaks standard desktop rules, does not work nicely with other programs and is eating resources like cookies.
Not to tinker with an OS is not an argument in my opinion. We are talking about a target group who do tinkering for a living and many of us have developed a very personal set of toolchains over the years. Why not write up a lengthy whitepaper about what to install, what to do and how to do. That would avoid the need of tinkering.
I use Emacs since many many years (and have VIM-friends! ;) ) and being forced to use the very crippled editors on those IDEs is like giving me MS paint to do a photoshop job. I hate that companies believe they should know best how to program, I mean seriously, there customers are often full-time programmers, this is ridiculous. It would be like Canon or Nikon force pro-photographers to only use the full automatic mode on there DSLRs. Or to tell a formula one driver, that his car will have automatic transmission. Heck would be the buspirate such a success if Ian would had started with a proprietary protocol and some kind of Java-GUI… I don’t think so.
Sure I open the files in Emacs and do my edit there. Sure, I can figure out how to create a makefile and call it from within Emacs. My point is, they should much more promote the possibility to use CLI and yes also for uploading, instead of presenting with much noise crippled half baken GUI screenshots.
@Torwag: I agree with your sentiment re CLI. Every decent tool should be scriptable. But I think Java was a good choice for building the IDE. I personally would have gone for Eclipse, but Netbeans is fine. It means a few things: with minimal effort it will run on all major OSs. It also means that Microchip can focus on the core functionality unique to their products and leave the tedious and expensive IDE framework to the IDE project. It also facilitates (should they want to) 3rd party plugins and add ons. Ok, the downside is that it’s relatively heavy on resources and doesn’t provide the user with a native OS look and feel. I can live with that. But like you said… I would just love to have access to a traditional command line compiler, linker, debugger too.
@Vince Sheard – I know what an SDK is, my point was _why_ wasn’t this a tool released by itself to start with? Why is it burried in an SDK and not out there sticking it to avrdude and the rest of your competitors. It’s rather short-sighted to my mind.
@arhi Oh I applaud them, don’t get me wrong. Anything is better than the past. I just don’t understand their logic. With more and more competitors breathing down their throats I don’t get the “will be in future releases” comments that keep being said both here now and on the forums at Microchip. I’ve seen it being said on there for years now.
I’ve only recently considered going back to Microchip parts because of PIC32. Having moved away because of the Windows only environment and the mental compiler licenses of the past given alternative manufacturers have open tools available or large community support.
So far my trip back to Microchip has seen support for my existing ICD2 dropped (fair enough for newer parts), I’ve purchase a ICD3 (at a xmas discount, thanks!), an IDE that is quirky and very windows centric, and no command line support for either of my debuggers even after _all_ the years I’ve had my ICD2 and all the whinging on the forums over the years.
Release the specs for the debuggers and given enough community support they’ll write the tools themselves.
@Torwag Oh I don’t find 395MB too much for a complete devel environment. I do however find it too much for a few jar files and a shell script. I have Xilinx ISE installed here too and yes it is HUGE. But my point was why is this mbd.sh tool not up front and center like people have been asking for on the web for years? They’re just stalling for whatever reason, or putting their efforts into the wrong things. No idea.
People can say what they want about MPLAB X and even actually be right. The simple fact remains that there are many users like myself who now have at least a half decent tool. Without MPLAB X there is simply now way I could work effectively with the likes of the IR TOY and BPv4 firmware. It is miles ahead of MPLAB 8 for navigating and editing code. Sure there are some big hassles with some aspects (who likes waiting…) and the support for assembler is far behind that for C. And why will not the global search and replace grab the text under the caret? That drives me nuts. But anyway it is still a big leap forward and if it make the grade of “good enough” it will be one less reason for people to look to churn from microchip.
Hopefully microchip will iron out a few bugs that have you jumping through hoops in the next release.