Is ST Cube IDE a piece of buggy crap?

[paulca]

On the topic of STM32CubeIDE and weird breakpoint behaviour.

I had a couple of occurrences of this last night.  Scenarios were I had an if condition like (txHead!=txTail).  The step over never visited that line, it jumped straight into the else clause.

It then occured to me that most ARM instructions can be conditional.  So comparing 2 volatiles and jumping to the else label was probably done in the single instruction.  Maybe the eclipse / gdb setup can't work that out when there are less ASM instructions than there are lines of code.

[peter-h]

Yes I have seen that too.

[DavidAlfa]

I hope you're not using any kind of optimization when debugging...

[paulca]

A tip for using Eclipse.  This featured saved my work!

Yesterday, having hit a small milestone in a project I decided to move it "back to the git repo".  I had previously recreated the project for a different MCU.

I set about rm'ing everything in the git repo.  Copying the contents of the project from workspace.  Adding, commiting and pushing all the changes to git.

It was only when I went back to eclipse, right clicked the project to remove all trace from disk and re-import from the git repo... did I notice the project path.... was already the one in the git repo.... or at least it was.

A long, "Did I just...", pause followed.  Until, I broke it slowly to myself that, yes, yes indeed, I had just deleted a weeks work.  Checked the git log and, yep, the last commit was a week ago.

All gone.  The whole display driver I wrote, all the bug fixes, the start of message parsing.  All gone.

I checked the backups, but, no, they are only backing up the git repo, the live files are on the Windows VM unbacked.  So I rolled the git change back again and sat sadly looking at the work from a week ago.

It was then that I noticed Eclipse had one of it's "Local History" tabs open and is was showing history for the last 3 days.  "No!  Could I get this lucky?"

Yes indeed I could!  I was able to not only restore the versions I had saved only a an hour ago, but I could restore entirely deleted files.  Took me a careful 20 minutes to restore the deleted project entirely in Eclipse.  The windows recovery task I had started hadn't found a single deleted file in that time, so I stopped it.

The trick is... you can right click a folder in a project and select "Restore from local history" and it will show all the files it's aware of that have been deleted.  Once you have all the files back, you can then just go through each one and select the "latest" from it's local history.  "Replace with ...."  "Local history.." even shows you a diff editor while you pick one.

[peter-h]

That's clever

I work in a strange way: a master copy of my project lives at home and a copy of it lives at the office. The office copy is a "throwaway" copy on which I can test various things. The home copy gets backed up whole (whole 200MB, not diffs or using any VCS) to a network drive daily, and there is an automatic backup at 3am which goes somewhere else.

I found that if I delete any files while Cube is running, Cube gets into a right mess, because it detects them going missing within a second or two. I think there is a config for that somewhere. So if you've been doing external editing, you should exit Cube when pushing any updates back to your project.

[DavidAlfa]

Use GitHub, set the project to private! Relying on local storage is silly!

[SiliconWizard]

Your tools make me sad.

[Siwastaja]

Yesterday, having hit a small milestone in a project I decided to move it "back to the git repo".  I had previously recreated the project for a different MCU.

Why do you work like this? Like, isn't this totally counter-intuitive and making your life extra hard, even if you don't make such goofs? Copying files once few weeks, then trying to retrospectively make commits? Really, why?

Just use git as intended, i.e., work with the working tree, do frequent commits, with at least somewhat descriptive messages. Every time you compile and test some kind of feature, at very least then do a commit:
git commit -a -m "UI cleaned up"
git add pixel.c
git commit -a "pixel update function works faster now"
git add adc.c
git commit -a "ADC calibration"
git push
git add important_header.h
git commit -a -m "oh forgot a file sorry bout that"
git push
git commit -a -m "didnt feel like committing today so sorry about full days of changes not documented separately here (still better than two weeks of work)"
git push

You get the point? Not optimum use of git, but at least something remotely sane No need to learn advanced usage, and for one-person projects, working with one master branch is fine, but at least do the commits. And don't do utterly stupid things like develop elsewhere and copy files over and retrospectively try to make it look like you tried to version control them.

[paulca]

Thank you very much.  I do know how to use git.  When you tell me how to create a project outside of the STMCubeIDE workspace, that would help.

The only reason it was OUT of git was because I needed to recreate it.  Yes, I could have (did) hack the IOC file to the new MCU, but I didn't trust it.

I don't mix git and workspace.  The workspace is only on a local drive because CubIDE doesn't like network drives, other wise the whole dev folder would be backed up nightly.  Projects that life beyond the first few hurdles, get extracted out of the Eclipse workspace and put into git.

Git is local git.  Local git and the whole network ~/devel/ folder (along with my photos and other memorability) are rsynced to a RAID0 pair nightly, which is OFFLINE unmounted all other times.  Every few months, I put an other 2 Tb drive in there and take another copy, plan was for that one to live elsewhere as a fire safe.  It's not made it further than downstairs!

I also have an S3 backup, but, I'm already over the free teir.  I have a tendency to dislike any cloud service, file service etc.  They tend to come and go.  AWS at least gives me raw access and should be around a while.

Note that github and gitlab both, I may be wrong, but have restrictions on what percentage of your projects are open source.  Make them all closed source, private and I believe at least gitlab charges you?

Beyond anything else, they are personal projects, I take liberties I can't in work with personal projects, because I can

[nctnico]

There is a simple solution: create a bare (*) git repository (with shared group rights) that is on your network drive. Everytime you push, git copies your work from the Eclipse work directory onto the network drive. Added bonus is that you can clone that repository onto different computers as well. I have organised most of my projects that way. Sometimes even with multiple remotes so I can push into customer's git repositories directly. This makes sure I can never make a mistake with deleting files etc from projects that causes me to lose work.

* A bare git repository is a 'special' git repository which is for archival and sharing purposes. Not to checkout / work from.

[SiliconWizard]

Using a version control system is a good idea, even for relatively small projects. I personally do prefer mercurial for this. For people finding git intimidating or with annoying quirks, that's worth a look.

Now once you use a VCS, if you are a lone developer, it can of course be all in local repos, that you can back up on a regular basis. No problem with that. (It seems like people increasingly believe they can't back up their own data, but they sure can.) You can alternatively use local repos and "server" repos on a machine in your LAN.

I really recommend staying away from "cloud" services as much as you possibly can, especially if you don't need to share development with remote people. If you do, then of course it's a completely different matter. But even so, unless you absolutely want/need a worldwide audience, you can set up your VCS on a server using Linode or similar instead of relying on github or the like. It's not free, but not that expensive.

This doesn't appear to be a very popular option, but I don't really care about that. I'll never fail to suggest options to make people more independent. You can of course do whatever you want.

[paulca]

For reasons I leave out.  I do not mix git/project files and IDE workspaces.  The only thing that stays in the actual workspace are "scrap book" projects.  Even when I started using the Arduino I got my files out of there and symlinked things to fix it up. 

Ideally, everything should be under the one (logical) folder, including the local git repos and just accessed from any machine without spreading files around.

Yes, using git religiously, committing and pushing on every session means you can check it out else where and work on it.  Which is fine, though a bit of overhead.  You also need to be careful you DO commit or you can end up doing your own made merge hell.

[peter-h]

I started a VCS thread a long time ago and soon there were as many opinions as posters

I understand the reasons for a VCS but utimately it just moves the decision on where to backup the whole thing. I backup the whole project each time and to different locations. With a VCS you have to backup the whole "database" at the same frequency if you want the same "safety".

[paulca]

VCS includes all the history. 

[peter-h]

Sure; you can retrieve v1.23, v1.22, v1.21, etc. The database is incremental and it sorts it all out. I first used this in the 1980s. But for myself now, I have no use for it, any "cloud" database has to be considered as totally insecure, so what's the point.

[paulca]

A bit of an over simplification on the versions.

Also... git is not a cloud service.  git is not a server.  There is no service.  its the same command on both ends.  "Remote" git is just an SSH shell with the right key and group perms for the repo.  So you can create one locally just by creating an empty repo and giving yourself SSH access to it.

[nctnico]

A bit of an over simplification on the versions.

Also... git is not a cloud service.  git is not a server.  There is no service.  its the same command on both ends.  "Remote" git is just an SSH shell with the right key and group perms for the repo.  So you can create one locally just by creating an empty repo and giving yourself SSH access to it.

That is even too complicated. A git remote can be as simple as a directory.

[SiliconWizard]

I started a VCS thread a long time ago and soon there were as many opinions as posters

I understand the reasons for a VCS but utimately it just moves the decision on where to backup the whole thing. I backup the whole project each time and to different locations. With a VCS you have to backup the whole "database" at the same frequency if you want the same "safety".

You make a decent point, but you don't need to have all your projects on the same "database". Actually they'd each have their own repo that you can back up individually.
There is no "single database" with all your repos in most distributed VCS. Each repo is its own "database".
Now if you put all your projects in the same base repo, which would be a big mess, then that would be a problem. But you shouldn't do that anyway.

[paulca]

Obviously in a team environment some form of VCS is critical.  However I find amateurs often see it as a burden too far.  I myself have a limit before which projects do not go into git or any VCS.  I just leave them, usually, in a bulk nightly backed up folder.  It's only recently I've had issues with network drives and IDEs from VMs.

Anyway.  Reasons for hobbyists/amateurs...

You have the history of all committed changes.
You can rollback/forward individual files or just reference files from the past.  (I know I had this working last week!)
You can easily migrate the project to a cloud service if you wish to.

Probably the biggest driver for me and when most of my hobby projects get moved to git.... when I want to try a new direction or try adding a new feature that will require refactoring.  I can take a branch.  I can make hell in that branch and completely break the code for weeks, however, I always have the working branch to return to.  This is very useful if you happen to be using the code day to day is a kinda-production setting, but still want to develop possibly breaking changes.

Even without branching you can just remember a point in time when you had it all working, tested and where happy with the known bugs.  You tear on breaking the code adding new features.  At any time, you can simply "checkout" that point in time and deploy working code even if your current working folder or branch (even master~HEAD) is completely trashed.

There are at least 2 copies of your project.

Reasons not to use VCS/Git.

It can be an admin overhead.  If you don't keep it up and let code and repo depart significantly whle you have open branches and unpushed code etc... you can get yourself in a bit of a tangle that might be off putting to solve.  I know the first dozen trashed git repos I've had to fix were very off putting, but you learn by your mistakes in hobby land, in work it's often learning the hardware after someone elses mistake.

[peter-h]

Obviously in a team environment some form of VCS is critical.  However I find amateurs often see it as a burden too far.

For team projects, definitely.

For me, I don't really see the point. My biggest concern has always been security, in the sense of losing data. And data loss can be produced by accident. One keystroke is all that is often needed. And with Cube popping up random files during a build (and these absorb any keystrokes at the time, because each one grabs the windows focus) this is a real risk.

I do have others working on the project but only on separate modules which can be plugged-in.

I want to keep my life simple

[newbrain]

Anyway.  Reasons for hobbyists/amateurs...

You have the history of all committed changes.
You can rollback/forward individual files or just reference files from the past.  (I know I had this working last week!)
You can easily migrate the project to a cloud service if you wish to.

You can experiment a lot using branches, and keep all the experiments while choosing one.
You can easily develop, even as a lone hobbyist, in different sites (if you use a cloud service, or have other ways - I use a home run instance of Gitea) as I often do across SE and IT.

It can be an admin overhead.  If you don't keep it up and let code and repo depart significantly

Committing It's just a couple of clicks away in most decent IDEs, as is synchronizing with a remote (which can be a local dir, as already pointed out).
Is that really more admin overhead than copying around stuff and keeping track of what goes where and which version is that?
My terminal laziness says it isn't.

[paulca]

For me, I don't really see the point. My biggest concern has always been security, in the sense of losing data. And data loss can be produced by accident. One keystroke is all that is often needed. And with Cube popping up random files during a build (and these absorb any keystrokes at the time, because each one grabs the windows focus) this is a real risk.

This is exactly one of the things git/vcs saves you from.  You can immediately ask it what is different and ask it to undo whatever you want.

When you have VCS you don't have just one copy of files, you have several.  You can rm -fr the whole folder and restore it in seconds... as long you have up to date commits.

[peter-h]

What I don't get is why a VCS is not integrated into Cube.

[paulca]

It is.

Right click->  "Team"-> Share project...

[nctnico]

It is.

Right click->  "Team"-> Share project...

Well, you need to install the right 'collaboration' plugin first (there are several different version control systems) but this is pretty simple to do. After that you'll have a nicely integrated version control system.

As I wrote before: I have everything in version control (preferably git). It is a huge help for trying things but also to check whether things went right after restructuring code. What is nice about Eclipse (Cube) is that you can compare the files you are working with, with any previous version. So if something has stopped working, you can easely check where you messed up.