fix build

[barafael]

While building this project on WSL (windows) and arch linux, make gives an error, as described by another use here:

https://github.com/riscv-mcu/GD32VF103_Firmware_Library/issues/5

To fix the build for me, I needed to rename 2 assembler files.

[reynoldsbd]

I ran into this issue as well, thanks for finding a fix @barafael!

Instead of changing the extensions, I suggest modifying the Makefile to search for the .S (capital "S") extension. I've tested this myself and it seems to work correctly.

Background

[elfmimi]

It is a convention in gnu toolchain to differentiate .s and .S by whether it should be preprocessed or not.

[barafael]

Hey @reynoldsbd, Good point, thanks for letting me know about that. However, I could not get it to 'make' with the ".S" externsion... Could you post how you did it?

[GPSBabelDeveloper]

@barafael, it's been a while, but I'll teach you to fish AND give you a fish. Preprocessing hand-written assembler is the bee's knees. You can #include other files (constants - no structs but you can #ifndef ASSEMBLER them away) and you can have board-specific things in an #ifdef, #define macros for word size so your code can work on 32 AND 64 bit parts, and so on. By GNU convention, those files that are written by a human are .S while machines write .s files. So knowing about .S is super handy. The Makefile rule to process them is pretty much like any other translation to one "language" as designated by an extension to another. So get get an object from a .S source file, you might use something like:

%.o: %.S $(CC) -o $@ -c $<

GCC knows how to deal with a .S (feed it to the preprocessor, then the assembler) much like it knows how to deal with a .c vs a .cc or a .C. GCC isn't the only compiler that supports this convention (now) but there are definitely compilers that don't. It's such an easy thing for tool vendors to support (Hey, the compiler knows how to call the assembler and it already has a C preprocessor...) and it's so useful, that I think most vendors probably DO support it these days.

You could probably find the place in whatever Makefile you're using that's dealing with .s sources and replace with .S with very little, if any, other changes.

I know it's long-winded, but hopefully it's educational. And to the maintainers of this project, we see .s in the Template/Makefile and .S files. That's pretty clearly a bug that should be fixed in the Makefile as described above.

[barafael]

@gpsbabel Thanks for the fish and the fishing net. This is very informative and useful.

As there seems to be no further activity in this repository for now, I think this is unlikely to get merged anyway, so I am not pursuing this. The issue, pull request, discussion and explanation are open for anyone who wants to read, anyway :)

[GPSBabelDeveloper]

@barafael It seems that Gigadevice threw this code over a wall and isn't really interested in supporting it (their LCD code is known to be pretty broken) or hearing from users, so we're all here to help each other. This is why there are a zillion forks of this library - nobody's accepting pull requests on this project. Unfortunately, most of them are incompatible with each other, so combining them is a problem. (This person renamed the registers to match BluePill. That person changed all the ugly hardcoded pointer offsets to use structs. This person's LCD library screws with SPIO just enough that another persons SD card library mysteriously won't work, #defines vs. const ints with different names, etc.)

Kendryte, maker of the K210, has pretty much the same stance and their doc is even worse.

SiFive seems to be the only one that's actively farming a community, but they're also selling $$$$ licenses for coreware instead of $.48 chips that people then attach to $3.78 boards. I get the economics of it.

[tuupola]

Nuclei seems to be pretty active too.

https://github.com/Nuclei-Software/nuclei-sdk

[barafael]

Also possible to use: https://github.com/riscv-rust/longan-nano and https://github.com/riscv-rust/gd32vf103-pac but not really up to par.