AVR Freaks

Well "undefined ref" means "I am seeing a call to foo() but nothing in all the linked files seems to be providing foo()"

In your case the error is:

undefined reference to `ST7920_SPI::ST7920_SPI(unsigned char)'  

So basically the file that contains the code of the ST7920_SPI class is probably not being presented to the build.

The other thing that may be going on is that there is no overload to match. Perhaps the ST7920_SPI class code is built but the only variants of the c'tor are:

ST7920_SPI() {
    // stuff
}

ST7920_SPI(double d) {
    // stuff
}

and what it is really telling you that it doesn't have a variant taking uchar (actually I think promotion rules might implicitly promote a uchar to double and use that one??).

PS as this in Arduino import it could simply be that the AS7 import process failed in some way and failed to recognise that the ST7920_SPI class code needed to be pulled into the build.

Describe how you got the "sketch" imported into Atmel Microchip Studio.

Indeed - there's been a number of threads recently about the import process not working.

Depends how you define "compact" - things like Arduino can make your source code a lot more compact by not having to laboriously spell-out in detail all the  arcane details of every single register.

You know what "habit" means?

and you know that you can break habits, and learn new things?

No, it's not weird at all: you've clearly made it too light by missing out a required library (binary or source).

clawson explained that in #3.

I'm interested in this issue because it's uncommon to me.

Actually, it is very common indeed - usually comes from including just a header without the necessary supporting source or binary code to complete the library.

Only yesterday: https://community.arm.com/develo...

and the day before: https://community.st.com/s/quest...

The above highlighting that it is nothing specifically to do with Atmel Microchip Studio - it is standard C (and C++) stuff.

That picture does not show ST7920_SPI.CPP within GccApplication4 so it's not part of the project being built!?!?

Andy,

That is in the Solution not the project. For example main.cpp is "below" the GccApplication4 entry which is the actual project.

To be honest I'm not actually sure what "Solution Items" are or how they got there? It's true that in VS2017 I often have "filters" outside of any actual project in the solution (the thing I work on has a heirarchy of about 30 configuration files and I keep a tree of those inside a separate "filter" alongside the projects for libs/dlls that actually make up the binary image. But AS7/MCS7 does not support such "filters" so the "Solution Items" there is a bit of a mystery to me. But anyway when MSBuild is told to "build GccApplication4" as one of the projects in the solution it will only be using things within that.

EDIT: OK so I see how that could have been created:

but I'm not sure why one would? And if this is like the other bits of AS7 this would actually create a directory on disk called "Solution Items" as I don't think it does "filters".

EDIT: oh now this is ODD. At the Project level you cannot create "filters" but it seems that at the Solution level this "new solution folder" is acting like a Visual Studio filter. It does not create an actual directory on disk at this level and then you can group items into it but, unlike projects, the default action of [add] is not to "copy to current folder then add" but the [Add] really does act like "Add as link".

When you "build solution" anything in such a solution folder is ignored completely - even .c or .cpp files. So it seems to be a way to "add stuff I might want look at or edit but is not part of any project in the solution"

If you had a hierarchy of config files or something like that then I guess this would be the place to put it. I just tried nesting...

For foo.c I used "Add new item" - the file was actually placed at the solution directory level.

Only last week: https://www.avrfreaks.net/forum/learning-atmel-studio-7

Absolutely!

Look the key thing is here:

"C:\Program Files (x86)\Atmel\Studio\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-g++.exe" -o GccApplication4.elf  main.o   -Wl,-Map="GccApplication4.map"
-Wl,--start-group -Wl,-lm  -Wl,--end-group -Wl,--gc-sections -mmcu=atmega328p -B "C:\Program Files (x86)\Atmel\Studio\7.0\Packs\atmel\ATmega_DFP\1.2.132\gcc\dev\atmega328p"  

The *only* file being linked is main.o. What this should really look like is:

"C:\Program Files (x86)\Atmel\Studio\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-g++.exe" -o GccApplication4.elf  main.o ST7920_SPI.o  -Wl,-Map="GccApplication4.map"
-Wl,--start-group -Wl,-lm  -Wl,--end-group -Wl,--gc-sections -mmcu=atmega328p -B "C:\Program Files (x86)\Atmel\Studio\7.0\Packs\atmel\ATmega_DFP\1.2.132\gcc\dev\atmega328p"  

ST7920_SPI.o does not appear in the list currently because it is NOT A FILE IN THE PROJECT.

I've already said that files to be built in the GccApplication4 project need to be listed in the Solution Explorer within the GccApplication4 project. Use "Add existing item" to make them appear there. The fact that the file also happens to be listed under "Solution Items" does NOT make it part of the build.

@amirdelta:  You appear to have missed #26 ?

Indeed.

Also, earlier in the build output, the only file being compiled is main.cpp

@amirdelta:  that is presumably why none of the other build errors (see #26) showed up in your build - because your project is simply not building them at all

presumably also SPI.o ?

It's all very well saying that you don't want to use the Arduino stuff - but that means you're going to have to take on responsibility for understanding and managing the whole build process yourself.

This is all standard C (and C++) stuff - not really specific to Microchip Studio or AVRs

See this thread https://www.avrfreaks.net/forum/avr-gcc-compiling-linking-and-assembly for an overview of the full build process - preprocessor, compiler/assembler, linker, etc