Is there any RPM or portable format of MCUXpresso that can run in any linux distro, especially not DEB based distro. My Opensuse have no dpkg.
Sorry - we have no current plans to support on other distributions.
MCUXpresso IDE Support
I have successfully installed and am running MCUXpresso on Mageia 64 which is RPM based. Here is what I did:1 ) Run the installer this way: ./mcuxpressoide-10.0.0_344.x86_64.deb.bin --noexec --keep
These switches will keep the installer from running. However a directory structure will be created called 'installer'.
2) Change to the installer directory where you will find the .deb files.
3) I converted each of these to RPM files using the 'alien' command which converts .deb files to .rpm files.
You will need to run this as root (or su): alien -r --scripts <filename.deb>
Do this for both JLink_Linux_x86_64.deb and mcuxpressoide-10.0.0_344.x86_64.deb.
You will then have 2 RPM files that you can install. Regarding the package scripts, I'm no sure if they may impact your install. Directory structures from on Linux to another vary to some degree. Let me know if it works for you.
BTW - everything works fine on Mageia 5 64bit - debuggers included.
bob_walker wrote: I converted each of these to RPM files using the 'alien' command which converts .deb files to .rpm files.You will need to run this as root (or su): alien -r --scripts <filename.deb>
I converted each of these to RPM files using the 'alien' command which converts .deb files to .rpm files.
That was my idea too, however I did not know how to stop at unpacking the single executable.Following the procedure, the installer successfully run, the only dependency that could not be resolved was some ffmpeg codec - whatever, I can live with that.
However, when trying to burn some image with LPC-Link (1, from a 11U14 dev board) MCUXpresso reported that it could not find dfu-util during probe detection. I installed that too. - It SHOULD be a dependecny, I think LPCXpresso supplied its own, now it relies on the system to provide it - correct me if I am wrong.
Sadly, the LPC-Link is still not detected, despite that no error message pops up since. To be sure, I tried MCUXpresso on a Windoz machine, the probe is in perfectly working condition.
Do you have an idea where to look for troubleshooting?
I am running OpenSUSE Tumbleweed (rolling release, with newest "stable" packages). And, just like you said, I am not going to switch to Windows, furthermore, without the intention of insulting anyone, neither will I switch to any linux using deb/apt, it just feels wrong to me in so many ways.
BTW - I am glad that the IDE is 64bit now (LPCXpresso never made the switch AFAIK - come on, it is the 2010s, no new development should be done using 32bit software), and that it is in a package, even though that is now a source of problems like this.
I've installed NXPs lpcscrypt and it has the dfu-util binary. Install lpcscrypt and then specify the bin search directory in MCUXpresso. This worked for me.
The installation of lpcsrypt did the trick, now I can use the LPC-Link 1 on (OpenSUSE) linux!On the other hand, even the lpcscypt documentation forget to mention that running the script requires libgtk2-32bit library. I know, the LPCXpresso required it anyway, so for most people it was already there...If it is not installed, install script reports (I am leaving this here as a reference for google):
invalid command name "bind" ...
Anyway, thanks again for your help, have a nice weekend!
Thank you very much bob_walker for the tutorial how to get MPCXpresso installed on rpm-based systems!!!! I am running opensuse leap 42.2 and made the same experiances as Kriszian Szegi.
But still, I need a bit more assistance with lpcscrypt. What did you mean with
...."specify the bin search directory in MCUXpresso"
I am at the point where mcuxpresso's debug process is looking for a debug probe and complains "unable to find dfu-util". I have nxpscrypt installed but I don't know at the moment how to make mcuxpresso aware of the "dfu-util"-executable.
@ Krisztián Szegi:
see the 'LPCScrypt User Guide' in the chapter "3.2 Linux install notes"
Thank you very much again for your help!
While looking around in the old lpcxpresso folder I understood that the executable used to be in the <...>/lpcxpresso/bin folder. So I created a link in: /usr/local/mcuxpressoide-<VERSION>/ide/bin/ to the /bin folder of the lpcscrypt installation folder. Type somethink like:sudo ln -s /usr/local/lpcscrypt/lpcscrypt/bin/dfu-util dfu-utilThis works for me and I hope this helps also others.
Path of lpcscrypt can be added under:
Window->Preferences->MCUXPresso IDE->Path and DirectoriesAdd it to the top of the list, so system dfu-util won't interfere with it.
Also, if you have an LPC-Link 2 or LPCXpresso V2/V3 development board, you can program CMSIS-DAP firmware (see the LPCScrypt documentatation you just linked ) onto the debug probe flash, so it won't have to boot from USB (default behaviour), meaning dfu-utils won't get called. Downside is that the (now default) CMSIS-DAP firware won't get automatically updated on the probe.
I am glad that more and more people use linux (and openSUSE on top of that!) for embedded development!
Offtopic:If you are interested in Rust, check out this blog (not mine, I wish it would be): Rust your ARM microcontroller! | Embedded in Rust After initial tests, it looks like the LPC-Link 2 with onloaded CMSIS-DAP is working together with openOCD, so I am starting a LPC based embedded project with Rust, even though it means not using MCXpresso. Beware if you start: NXP LPCs' SVD files needs some manual fixing!
For those of you at MCUXpresso IDE Support.... c'mon, add an install switch (--RPM) and some scripting code for us RPM users. There are MANY Linux systems that are RPM based....my system of choice for the last 10 years has been Linux...
and it will stay that way....
as said, currently no plans for this (given the number of users with using RPM format), but this could be considered for a future version, depending on how many would use it.
I hope that makes sense,
It's quite simple to add the functionality and RPM and DEB package formats are going to cover the vast majority of Linux distros. In my mind, the benefits HUGELY offset any time needed to support this package format. Most Linux forks are based on Red Hat (RPM) and Debian (DEB)....
BTW - kudos for your support of NXP, Freescale, and ARM. I've been following your contributions to this community for some time now as a fellow embedded fimware programmer and product designer.
Thank you for your answer, I was solve my problems before. I just ask about the official one .
What i did is just extract the content of deb files (data.tar.gz), and copying to my system. Its run, but i haven't try to debug yet.
Erich Styger and LPCX presso support I think, what you do in LPCXpresso is way better.
Retrieving data ...