MacOS target build issues

[jvco98]

Hi! I'm having some troubles in setting everything up in a Unix environment. I'm pretty new to it all, but I think I installed GCC correctly using homebrew. I have my Nucleo stm32f446 which I'd like to use but I've been getting some error messages. When following along, I'm stuck here:

After entering ./target/build/build.sh stm32f446 rebuild
i get the error

Are you familiar with what this would mean? Thanks for any help!

[ckormanyos]

Thanks for reporting this Jeff (@jvco98).

what this would mean...

At a first glance, it seems like the file app_make_linux.gmk is not being found via the -f flag by GNUmake.

I'll set up a few builds and report back later. I don't have this exact OS running locally, so I will set up a CI build and try to find out that way what's going on and if there is an easier way to make it work.

[ckormanyos]

Hi Jeff (@jvco98) I just verified the stm32f446 build on Ubuntu. It is OK as documented.

I'm a bit concerned that your file setup might be incomplete or not quite right.

Which repository did you get or clone? How did you save it?

[ckormanyos]

Hi Jeff (@jvco98)

OK. I can confirm exactly the same error message running on MacOS-latest on GitHub Actions, as shown here.

I will now attempt to solve this apparent problem or figure out what phenomenon is going on and get back to you in this thread as soon as possible.

In the intermediate time, it might make sense to try for a CMake-based build on MacOS. But i will, nontheless, try to solve the problem with GNUmake on MacOS anyway, as this build option is intended to be supported and work.

[ckormanyos]

Hi Jeff (@jvco98).

OK I found that the default-installed version of GNUmake on MacOS is actually incompatible with the make files in this repository.

I am working out the following recipe for building ARM targets with GNUmake on MacOS.

The preliminary draft of the docs looks like this:

The default 3.81 version of GNUmake on MacOS, has been found to be slightly incompatible with the make files used in this repository. So in this case, we need to install (via brew) a newer versoin of GNUmake. This installs a version of GNUmake called gmake in the path and we will be using this gmake instead of the usual make.

brew install make

Query the gmake version with

gmake --version

Now build the target with a direct call to gamke.

cd real-time-cpp
cd ref_app
gmake -f target/app/make/app_make_linux.gmk rebuild TGT=stm32f446 MY_GMAKE=gmake

[ckormanyos]

Hi Jeff. I got the GNUmake builds running on MacOS runners in CI.

I posted a successful recipe in the new chapter Example build on MacOS for target stm32f446 in the docs. The changes are already pushed to master.

Feel free to try and see if it works for your case...?

Many thanks for raising awareness for this issue. This problem has remained hidden for a long time up till this point.

Kindest regards, Chris

[jvco98]

Thank you! I believe I successfully followed along, though when I'm trying to assemble the startup code (first example in section 2.2) I'm getting this error.

Is this a completely new issue?

[ckormanyos]

Thank you! I believe I successfully followed along

Good.

Actually Jeff (@jvco98) you are discdussing two independent issues now.

1. The first is building the ref_app for target stm32f446. Let's handle that issue first. This is the original topic of this thread. Were you successful building the ref_app for target stm32f446? This is a 32-bit ARM controller that can use the gcc-arm-none-eabi toolchain.
2. The sample code for example 2.2 is designed for a completely different microcontroller/compiler system. it is for the AVR atmega328P, known from the orignal Arduino Board. You need the gcc-avr toolchain for this example. Or need to adapt to the ARM target board.

I'd like to first handle point 1. Were you successful on the stm32f446?

We can handle point 2 either here or in another thread. In fact, we could even adapt 2.2 to the ARM board if you like.

Keep going Jeff! Good stuff.

[jvco98]

Sounds good!

Were you successful on the stm32f446?

I believe I was! The commands for building the ref_app returned a ton of compile messages and created a few files in the ref_app directory.

In fact, we could even adapt 2.2 to the ARM board if you like.

This works for me!

[ckormanyos]

I believe I was! The commands for building the ref_app returned a ton of compile messages and created a few files in the ref_app directory.

Good. There should be a file ref_app.hex located in the ref_app/bin directory. You might actually like to program this hex file on the STM32F446 board and see blinky running.

[ckormanyos]

adapt 2.2 to the ARM board

works for me!

I'll take this as a new feature. it might take a few weeks to do it, as I'm busy with a lot of things nowdays. But I would also like this adaption of some of the 2.x examples.

Please be aware that the ARM CM4 core that you mention has completely different startup code, interrupt vector, port handling, etc. from the Arduino. So although the functional interfaces remain the same, these examples directly on the metal will necessarily have a lot of differences.

[ckormanyos]

adapt 2.2 to the ARM board

works for me!

take this as a new feature

New feature adapt some of Examples 2.x to ARM CM4 Core on STM32F446 in #279

[ckormanyos]

Hi @jvco98 I have a suspicion that this issue might have been caused by the trivial yet critical form of line endings LINUX/DOS.

MacOS is installed with GNUmake 3.81, which only handles LINUX/UNIX-style line endings. I've known about this problem before but never really handled it. So I converted all Make-File line endings to LINUX/UNIX-style.

It's been forever since we dealt with this issue, but I think #396 wil/should fix this on MacOs

[ckormanyos]

See also #396