Yes it works ok if you aren't trying to use the same debugger from either the VM or the base machine, and keep swapping around.
Maybe it can be done reliably if one knows about the VM config intricacies.
BTW I have just done the same 1.7.0 update on a freshly updated win10 machine and that also needed the VC++ "2015-2019" update. Win10 doesn't do that automatically.
The latest Cube, 1.7.0 still has not fully fixed the "invisible lines" issue, where much of the text scrolling up the console window during a build is invisible, probably due to being in a white font.
The issue has improved, with two win7-64 machines now ok, one win10 ok, one win10 not ok. The last one is used by a guy writing software and he has to swipe the invisible text and paste it to Notepad, to see the error messages
In all cases, if the machine is accessed via Remote Desktop, the text is fully visible.
The latest Cube, 1.7.0 still has not fully fixed the "invisible lines" issue, where much of the text scrolling up the console window during a build is invisible, probably due to being in a white font.
The issue has improved, with two win7-64 machines now ok, one win10 ok, one win10 not ok. The last one is used by a guy writing software and he has to swipe the invisible text and paste it to Notepad, to see the error messages
In all cases, if the machine is accessed via Remote Desktop, the text is fully visible.
I will half-heartedly pretend to defend ST here:
That's Eclipse crap for you. I have exactly the same in MCUxpresso (not that I use it unless I feel masochist).
In frigging 2021 Eclipse can't still have a decent dark theme...
Pedant mode on: Cube is actually the library/driver packages or more generally speaking the whole ecosystem including STM32CubeMX, STM32CubeProg, and STM32CubeIDE (and other stuff, probably).
I never had the invisible lines bug, mayeb it's related to windows 7 and/or the java version.
I've always used w10 - now w11- and definitely not happening.
Unless you install themes. Themes are custom mods, might not be correctly done or be outdated.
I recall having such text issues after installing a dark theme, text color was the same as background's.
It's not ST's or Eclipse's fault, it's the theme.
The latest Cube, 1.7.0 still has not fully fixed the "invisible lines" issue, where much of the text scrolling up the console window during a build is invisible, probably due to being in a white font.
The issue has improved, with two win7-64 machines now ok, one win10 ok, one win10 not ok. The last one is used by a guy writing software and he has to swipe the invisible text and paste it to Notepad, to see the error messages
In all cases, if the machine is accessed via Remote Desktop, the text is fully visible.
I will half-heartedly pretend to defend ST here:
That's Eclipse crap for you. I have exactly the same in MCUxpresso (not that I use it unless I feel masochist).
In frigging 2021 Eclipse can't still have a decent dark theme...
Pedant mode on: Cube is actually the library/driver packages or more generally speaking the whole ecosystem including STM32CubeMX, STM32CubeProg, and STM32CubeIDE (and other stuff, probably).
Well, I have to defend Eclipse here.
I am using native Eclipse for years and didn't have any issues like that.
Maybe the vendors mess something up?
It's not ST's or Eclipse's fault, it's the theme.
Not a platform problem, I have the same on Linux, Win 10 & 11. nVidia or AMD graphics, Intel or AMD CPUs.
The dark theme is the one available in both STM32CubeIDE or MCUxpresso, and as far as I know provided by Eclipse, not a vendor thing.
But hey, IDEs are a personal preference. I simply can't stand it.
I never had the invisible lines bug, mayeb it's related to windows 7 and/or the java version.
I would also strongly suspect it's related to the specific JVM that's bundled with their IDE for this specific platform.
I do also strongly dislike Eclipse anyway. To each their own. But if you use your own favorite tools while going a little bit more baremetal with the MCUs, you'll become a much happier camper in the end. That's almost a guarantee.
I am using native Eclipse for years and didn't have any issues like that.
But that's exactly the problem.
JW
Well, it is more complicated because of inter-dependencies like clock configs, alternate functions, half the UARTs/SPIs/whatever are not usable because the pins are used for other stuff. Setting up that sort of stuff is a great use for a GUI.
What they COULD focus on is a resource planning tool, as this puzzle is an NP-complete problem. That's all. Document the peripherals properly (which they mostly do, but you better read ALL the fine print), use canonical nomenclature, and explain how to set up common use cases (which they also mostly do). Leave the code end to me, because looking both at code using HAL and its implementation makes me just go... WUT.
It looks like someone's school project.
Well, it is more complicated because of inter-dependencies like clock configs, alternate functions, half the UARTs/SPIs/whatever are not usable because the pins are used for other stuff. Setting up that sort of stuff is a great use for a GUI.
What they COULD focus on is a resource planning tool, as this puzzle is an NP-complete problem. That's all. Document the peripherals properly (which they mostly do, but you better read ALL the fine print), use canonical nomenclature, and explain how to set up common use cases (which they also mostly do). Leave the code end to me, because looking both at code using HAL and its implementation makes me just go... WUT. It looks like someone's school project.
Nothing is stopping you from using CubeMX to plan and then implementing the code yourself? What am I missing here.
Cube does not need one to separately install Java, BTW. Some of these machines have Java, some haven't.
"Nothing is stopping you from using CubeMX to plan and then implementing the code yourself? What am I missing here."
I have not used MX (the code generator) because I have just been writing the "functional" software on this project, but the other guy working on it does that. I guess a lot of people also do - because it saves hours going through the RM trying to work out which peripheral can connect to which pins, etc. I haven't yet got stuck into that part (the AF settings etc), but most people seem to do it by calling some huge ST HAL function.
The problem with MX is that if you later modify the code, it obviously doesn't reflect itself in the original design. For example the very pretty diagram of the clock config (which
is useful for documentation) cannot be updated if you changed say PCLK1 in the code.
" It looks like someone's school project."
It does - like seeing a hardware design where somebody used a 10.1k resistor instead of 10k, where anything from 5k to 20k would have been fine
But there is an amazing lot of that around; we just don't expect it in software...
Just installed Cube v1.8 (in a VM just in case) and
new: 341k 348,560 bytes in 1.8
old: 341k 348,560 bytes in 1.7
So, no change in the compiler version or any of the libs we use
The Big Q is whether they have fixed the "white text"...
Check the documentation, all the new stuff is explained there.
They only ever list a small subset of issues there
First of all, don't mix IDE and compiler.
The IDE receives updates more frequently, usually fixes for CubeMX and the IDE itself.
However the compiler is updated very few times a year. Maybe once or twice, if any.
ALso, most updates will be for newer devices, so it'll be the same thing for older ones.
Unfortunately, my experience with STM cube was not very good.
I am actually really happy the compiler isn't updated, because it seems to work faultlessly, while Cube itself looks like a bit of a hack. But it is free, which is actually a huge plus especially if you are trying to divide up a project among several people / several devices. The last thing I ever want for any serious development is some floating license thingy which works until the license server packs up or the company stops supporting it, and which guarantees that it will be hard or impossible to open the project up 10 years from now. I have some Xilinx FPGA projects from mid-1990s whose customer (I used to do FPGA & ASIC design consultancy) resurfaced 10 years later, for another £30k "improved version of the last project"
The Xilinx software (Viewlogic4-LCA and XACT5) was double-dongled, both dongles broke, Xilinx washed their hands of the whole lot ("got to crack some eggs to make an omelette" was the sales guy's reply, when I questioned why their latest sw would not import the old project) and it was only via cracks from some Russian guy that I was able to rebuild the project. Most of the CAD/EDA business has moved to either rental or floating licenses, which is fine if you work in somebody else's company, get paid 50-100k, and change jobs every few years.
A Cube project can be archived as a VMWARE VM package which plays in any VMWARE player. It can be fully run in a VM anyway, if you want to do that.
Fully agree. There is a very good reason why I only buy software (with a perpetual license) for which a cracked version exists.
peter-h - you seem to be in an insightful and generous mood today. So why not take this opportunity to rename this thread, which you started, into something more professionally sounding? After all, we have collected quite a bit of valuable information about that collection of tools, known by the common developer as CubeIDE.
Merry Christmas.
peter-h - you seem to be in an insightful and generous mood today. So why not take this opportunity to rename this thread, which you started, into something more professionally sounding? After all, we have collected quite a bit of valuable information about that collection of tools, known by the common developer as CubeIDE.
Merry Christmas.
I think the original thread title is just fine, if a bit clickbaity; it's the right question to ask. Do not confuse professionalism and political correctness. Even in professional environment, such strong wording is pretty useful sometimes, but of course in moderation. But this seems to be OK since peter-h's every topic is not titled like this. Merry Christmas indeed!
"you seem to be in an insightful and generous mood today."
I think that's known as a "backhand compliment"
I don't think one can rename threads. Only subsequent posts' title gets renamed.
Merry Xmas All
The title is actually pretty soft given the things I've seen/experienced in the past
You can edit each individual post of your own, changing their titles. The responses of others will remain with the old titles, unless their authors do the edits. Whoever happens to click the reply button on a post with edited title, will cause the new post to inherit this new title. The result is a thread where titles change on the fly randomly, and on the front page showing new posts, no one knows which thread is actually updated.
Obviously, this technical difficulty only underlines the deeper meaning: rewriting history tends to be at least stupid, if not dangerous. So it's best left undone unless you have a strong technical reason to actually do it to help others, not "just because".
The title is actually pretty soft given the things I've seen/experienced in the past
Yeah, if you want to do that in Professional Style, how about:
"ST CubeMX considered harmful".
I think Cube IDE is really nice. Great set of features and quite intuitive and easy to use.
Your problem could be a C / C++ one (especially C++). Some features when use in certain ways can produce undefined behaviour.
Could it be that another included header file elsewhere in the project is having an effect.