Freeing grbl_stm32 from eclipse

[J-Dunn]

Hi again, I hope you are doing well.

Are you able to suggest a way to free this project from using eclipse ?

Every time I update the eclipse package I waste at least a day trying to get back to the stage where I can even load this project. It's a mess. I need to reinstall the a6 workbench and then it always seems to loose all track of the project and I'm left slashing around in the totally confused interface trying get it to open something which was fine before I updated.

This time I'm lost. I've spend a day screwing around and I can't get it find the project file. I have no idea what is wrong and there is not intelligible output. It's just empty.

I really need a way to build the project outside of eclipse and never hear that name again.

Do you have any suggestions on how I can go about that?

Many thanks for any ideas, I really have to find another way of working.

[langwadt]

I'm surprised that you have problems with eclipse, I've never had any real problems with AC6 or CUBEIDE, anyway
a starting point would be looking at the console output with all the commands for a clean build, or the make file generated in the Debug folder

[J-Dunn]

Thanks, I use the distro installer, I don't know whether that clearing configs for some reason. Anyway each time I update I loose the a6 workbench and when I reinstall that, agree to the EULA again, it's lost its setting too.

I can now build the project on eclipse but I can't flash or run it. It's failing to get a lock file because it still attempting to write to /var/lock ( that went out of fashion a while ago because of an exploit ).
Error: opening lock file: /var/lock/LCK..ttyS0: Permission denied.

There's no error in the UI but that maybe just failing silently. A lot of the problem is eclipse tries to do everything plus the kitchen sink and it's painfully complex to find whatever you need to set anything up.

I'd like to get to a makefile based system. I've looked at makefile structure in Debug but that does not work from the command line. It seems to be mapping cos and sin calls differently when run from CLI.

../src/grbl/motion_control.c:258:18: error: 'csinl' undeclared (first use in this function); did you mean 'csinh'?
  258 |         sin_Ti = sin(i*theta_per_segment);
      |                  ^~~
../src/grbl/motion_control.c:258:18: error: argument 6 of '__builtin_tgmath' is not a function pointer

It's also quite a complex iterative build system created , presumably, in java code. That means I still have a dependency on eclipse.

When I was working with avr grbl, I had a nice simple set up using Geany and Makefile. I need to get back to something like that.

Fortunately I still have the dev system attached to the machine which I don't update (for exactly this reason). It's just not practical for making mods and testing code.

[langwadt]

I might have a look at it later, I have another STM project that builds with a makefile

sure the error isn't related to the TTY being owned by root or you not in the dialup group?

[J-Dunn]

yes, user is in lock and dialout

#groups
stm dialout ftp lock audio users

I tried changing /var/lock -> /run/lock to be writeable by the user. No change. Probably a false lead.

If you have a sample makefile that certainly could be useful. Thanks.

[langwadt]

what is the permissions on the TTY?

[langwadt]

I just tried importing the project in Cubeide(because that is what I have installed on this pc) and with the compiler added to the path it builds with make on the command line, just can't use make clean because it deletes everything

[J-Dunn]

what is the permissions on the TTY?

ls -ail /dev/ttyACM0
1229 crw-rw----. 1 root dialout 166, 0 May 29 22:45 /dev/ttyACM0

[J-Dunn]

Ah, I think I may have found the problem:

Again, some part of the config got borked during updates. Unfortunately, when I click on the "Define board target" button, nothing happens !

[langwadt]

you must be doing something weird :) I've never had any problem installing AC6( or Cube I believe that is the official tool from STM now) import the project and build. can you try that ?

btw. why tty for flashing?

[J-Dunn]

I just wondered whether the WB was trying to set a lock file and then abandonning communication with the card, if it failed. Sure the flash process does not use the pseudo comm port device ( which is a USB device on the same bit of wire ).

Did you see my previous post ? IIRC ST stopped paying a6 for this WB a couple of years ago. They may simply have stopped supporting these dev boards now.

That's another reason I don't like depending upon proprietory s/w with some opaque installation procedure, which needs reinstalling every 3mo or so. I had to update Eclipse because of a distro upgrade, now my development system has evaporated !

[langwadt]

did you install eclipse or AC6? I'd switch to cubeide. Imported the project into cubeide and it doesn't have any settings for target board, I not even sure it does anything in AC6 other than preset some things when you first make the project

[J-Dunn]

I think it sets some useful stuff like what FPU it has. I recall this was all very specifically tailored to exactly fit the nucleo F411RE dev board. It seems to have lost all that.

I installed Eclipse from distro then installed a6 from the help menu in eclipse. I remember screwing around like this once before but its a couple of years back and I can't remember the path through the labyrinth. I'll try to look at Cube, I had it with this mess.

I'd still be more comfortable with a makefile ;)

[langwadt]

seems like the AC6 installation is screwed up, I've always installed AC6 (or cubeide) and not eclipse.
I just tried the standalone CUBEMX, it can generate a standalone makefile, it compiles on the command line or in eclipse, but programmming, debugging, code index etc. is going to take some hacking

[J-Dunn]

Thanks, I recovered the target problem by copying .project and .cproject from your original archive. I now have the board defined where it was missing above and what looks like a correct build.

But make all will not run from console: "no target for all" , and make alone just builds one file: src/util/delay.o :?

It seems the various WB install scripts make a local copy of eclipse with the respective WB already installed. That maybe a way to avoid the distro pkg upgrades but I did not get a lot further with cubeIDE. A whole different set of niggly problems.

All these "workbenches" seem to be pretty much the same thing with slightly different window dressing on the same eclipse functionality. So I think whatever is wrong is going to apply to them all.

I don't see how to "import" a project. If I import "as makefile based project with source code" it seems to expect that to include the makefile structure. If I import as C/C++ it does not create it either.

So far the best I have is distro eclipse + a6 which at least gives me a bin and elf image. I thought it was producing a hex too before , IIRC that is what was sent to the board.

I don't seem to be able to define any debug/run targets. In the setup dlg, if I select either a6-debug or the STM options it just silently fails and leaves me still with no entries. The C/C++ goes further but is not going to create a cross-dev debugging session.

[langwadt]

in AC6; import,general,"existing projects into workspace"
in cubeide; import, general, "import ac6 System Workbench for STM32 Project"

[J-Dunn]

Ah, right it's just to import one eclipse project into another eclipse installation. I did manage to import the eclipse + a6 version ( which does compile but has no run/debug ) into cubeIDE but now that fails to compile with the csinl errors again. I'm not sure what is causing the problem with these built-in functions. It appeared and went on the original installation , now it's back here on ice.

It's about 4 days I've wasted on this garbage and it's still not running anywhere. I started looking into using autotools but that whole other rabbit hole to fall down.

[langwadt]

the errors seems to me like you have something screwed up with which compiler it uses

what OS are you on?

[J-Dunn]

I'm using Fedora. The IDEs show:
a6 on eclipse says it using "A6 STM32 MCU GCC" I think that's the lacarno build.
cubeIDE: "gnu tool for stm32 ( 9-2020-q2 ) installed with cubeIDE 1.6.0"

I did an import but that is one thing which does not seem to have been preserved.

I did have the distro cross toolchain and newlib installed but I've removed that to avoid possible confusion.

I added -fno-builtin to the GCC compiler "miscellaneous" flags in cubeIDE, but it seems to be ignored.

equally setting -fno-builtin-sin -fno-builtin-cos seems ignored.

[langwadt]

your PC must be haunted, it makes no sense that it doesn't just work. I just tried cloning the repo, import into cube, build, debug, everything works.

Do you really want to go back to geany and a makefile? it'll be like going back to the 80's, no debugger, no smart editor, etc.

[J-Dunn]

In the 80's I was working with Borland's Turbo Pacal IDE. Still the fastest and best IDE I've ever used. ;) I long for those days.

Geany is syntax aware that's smart enough for me. I find it clearer to look at code with that than eclipse.

I did successfully run the "Scope" debugger plugin on Geany via gdb doing remote debugging on these boards and it was at least ten times quicker than Eclipse when stepping through code. ( IMO the IDE spends 99.8% of its time updating every panel in the "perspective" and 0.02% of its time debugging ).

Sadly Scope debugger has not been updated to py3, but at this stage, it's looking like fixing that could be less work than fixing the current mess with eclipse.

Why do I get the csinl problems and why don't the compiler flags work? I get no feedback, no errors yet the compiler output does not change. It maybe just some minor config is still missing but with the size of a IDE like there a metric haystack of chaff to crawl through to find the config needle. cubeIDE looks like it might be close to working apart from that _builtin trig function stuff.

This is why I hate free, closed source proprietory GUIs for this sort of stuff, when it works it's fine and when it doesn't you're stuffed. There is no support at a6, I gave up on that idea about 4y ago.

Makefile is a pain to set up on a complex structure like this but at least you get to write the rules and you can see and test what it going on. It's a documented procedure you just have to put in the work. GUI's often just silently swallow the error and leave you blind.

Thanks for all your suggestions, I don't know where I go from here.

[langwadt]

the only thing I can think of it the you have a screwed up path so that i doesn't use the right compiler

I'll try to setup a makefile

[J-Dunn]

Ah thanks, that would be brilliant.

[langwadt]

I've added a makefile, it builds and the board boots with the usual boot message but it has not been tested on cnc hw and I have not checked that all the settings are identical so use at your own risk

[J-Dunn]

Many thanks, that's a great help.
At first it was using the distro cross compiler and I was getting csinl problem again. I then dug out the path to the a6-installed compiler deep in the bowels of my eclipse structure and added a GCC_PATH. That built perfectly.

At last !

st-flash did its job and verified data. Jolly good !

I can now make and flash from Geany :)

The compiler calls itself:
gcc version 7.3.1 20180622 (release) [ARM/embedded-7-branch revision 261907] (GNU Tools for Arm Embedded Processors 7-2018-q2-update)

I think I read it's the Lacarno build. I'll dig it out and put a copy in a safe place.

I now have something close to a working development system again. So I need to look into the current state of the Geany debugging plug-in "scope" and see whether I can still configure it to connect to do remote debugging.

Many thanks for your patient assistance.

[langwadt]

you are welcome, it was a chance to brush up on makefiles.
The wrong compiler was likely the issue, which is odd I just installed the default one in Ubuntu 20.04, 9.2.1 and it works

Be aware that st-flash is "broken", it erases the flash sector used to simulate eeprom. So you will be back to default settings every time you flash

[J-Dunn]

Thanks for the warning. Isn't that what happens when flashing via the IDE as well?

I've actually modified the grbl defaults to those suited to the machine so it's not a big issue. If I change speeds etc while working it goes back to my working defaults rather than something I don't want.

I may open a bug about this at fedora since it seems to ignore the compiler options and also tries to substitute a function which is not even defined. What is the gcc -v info from the Ubuntu version? If that works they may have a patch.

[J-Dunn]

Thanks for the warning. Isn't that what happens when flashing via the IDE as well?

I've actually modified the grbl defaults to those suited to the machine so it's not a big issue. If I change speeds etc while working it goes back to my working defaults rather than something I don't want.

I may open a bug about this at fedora since it seems to ignore the compiler options and also tries to substitute a function which is not even defined. What is the gcc -v info from the Ubuntu version? If that works they may have a patch.

[langwadt]

The IDE doesn't erase sector the is used to simulate EEPROM because it isn't used for code, st-flash should do the same when programming an ihex file but it doesn't

The compiler installed with apt-get: gcc version 9.2.1 20191025 (release) [ARM/arm-9-branch revision 277599] (15:9-2019-q4-0ubuntu1)
The compiler installed with CUBE: gcc version 7.3.1 20180622 (release) [ARM/embedded-7-branch revision 261907] (GNU Tools for STM32 7-2018-q2-update.20190328-1800)

both work

[J-Dunn]

st-flash should do the same when programming an ihex file but it doesn't
I think I read that the stm-a6 WB still uses st-tools. Maybe that the difference between to "official" version and the open source release. ;)

It looks like Cube and a6 use exactly the same compiler version. That makes sense. Unless I have reason to change, that's probably a good enough choice. I suppose I could always unpack the deb file if I need gcc version 9.2.1 20191025 .

The buggy Fedora cross-gcc is : gcc version 10.2.0 (Fedora 10.2.0-4.fc34). That's the deal with Fedora we get to be lab rats for Redhat :D

[langwadt]

the IDEs use stlink gdb, not stflash

[langwadt]

I just tried gcc 10.2.1 and with a -fcommon to fix a change in defaults it works

[J-Dunn]

Thanks. I added that option to your Makefile and let it default to the distro cross compiler by not defining GCC_PATH

# compile gcc flags
ASFLAGS = $(MCU) $(AS_DEFS) $(AS_INCLUDES) $(OPT) -Wall -fdata-sections -ffunction-sections -fcommon

CFLAGS = $(MCU) $(C_DEFS) $(C_INCLUDES) $(OPT) -Wall -fdata-sections -ffunction-sections  -fcommon

Is that what you meant? I'm still getting the built-in function errors.

BTW I was mistaken in thinking -fno-builtin and -fno-builtin-sin should affect this.
https://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html#C-Dialect-Options

With the -fno-builtin-function option only the built-in function function is disabled. function must not begin with ‘__builtin_’.

However, the fact that those built-ins are not defined does seem to be a drawback ;)

src/grbl/motion_control.c:258:18: error: 'csinl' undeclared (first use in this function); did you mean 'csinh'?
  258 |         sin_Ti = sin(i*theta_per_segment);
      |                  ^~~
src/grbl/motion_control.c:258:18: error: argument 6 of '__builtin_tgmath' is not a function pointer
make: *** [Makefile:203: build/motion_control.o] Error 1
[

[J-Dunn]

Could you confirm I'm reading this correctly? Irrespective of the right compiler switch to prevent the built-ins being used, it seems that they are not even defined.

It seems the compiler is mapping sin() to '__builtin_tgmath' with the sixth arg of csinl . ( I'm guessing that means c compiler's longint sine substitute ). However this variable which should point to the built-in version of sin() is not actually defined in the cross-compiler.

That looks like a compiler bug. Though I don't find any trace of similar output in searches.