avr-gcc 7.3.0 i ATtiny10 - __int24 działa w kompilacji, ale Error List pokazuje N3129

Problem dotyczy zmiennych 24-bitowych w kompilatorze avr-gcc.
Używam Microchip Studio 7.0.2594 i kompilatora w wersji 7.3.0.
Na potrzeby zaprezentowania problemu napisałem krótki program na mikrokontroler ATtiny10, który uruchamiam w symulatorze.



Wynik kompilacji w oknie "Output" jest poprawny (0 błędów), ale jak się przejdzie do okna "Error List", widać 5 błędów: [N] 3129: unknown type name '__int24'.
Na linijce "asm volatile("nop");" ustawiam Breakpoint.
Oczywiście program w symulacji nie działa prawidłowo. Po najechaniu myszką na zmienną "wynik" wyświetla się komunikat "Unknown type class".
Zmienne 24-bitowe będę wykorzystywał w innym, bardziej zaawansowanym programie.

Nie wiem, jaka jest przyczyna nieprawidłowego działania.
Może potrzeba dołączyć jakąś bibliotekę?
Czy możesz pokazać pełną komendę kompilacji z okna Output albo ustawienia projektu, zwłaszcza wybrany toolchain, standard języka C i poziom optymalizacji?
Invoking: AVR/GNU Linker : 7.3.0
"C:\Program Files (x86)\Atmel\Studio\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-gcc.exe" -o int24.elf main.o -Wl,-Map="int24.map" -Wl,--start-group -Wl,-lm -Wl,--end-group -Wl,--gc-sections -mmcu=attiny10 -B "C:\Program Files (x86)\Atmel\Studio\7.0\Packs\atmel\ATtiny_DFP\2.0.368\gcc\dev\attiny10"
Finished building target: int24.elf
"C:\Program Files (x86)\Atmel\Studio\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-objcopy.exe" -O ihex -R .eeprom -R .fuse -R .lock -R .signature -R .user_signatures "int24.elf" "int24.hex"
"C:\Program Files (x86)\Atmel\Studio\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-objcopy.exe" -j .eeprom --set-section-flags=.eeprom=alloc,load --change-section-lma .eeprom=0 --no-change-warnings -O ihex "int24.elf" "int24.eep" || exit 0
"C:\Program Files (x86)\Atmel\Studio\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-objdump.exe" -h -S "int24.elf" > "int24.lss"
"C:\Program Files (x86)\Atmel\Studio\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-objcopy.exe" -O srec -R .eeprom -R .fuse -R .lock -R .signature -R .user_signatures "int24.elf" "int24.srec"
"C:\Program Files (x86)\Atmel\Studio\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-size.exe" "int24.elf"
text data bss dec hex filename
210 6 3 219 db int24.elf
Done executing task "RunCompilerTask".
Task "RunOutputFileVerifyTask"
Program Memory Usage : 216 bytes 21,1 % Full
Data Memory Usage : 9 bytes 28,1 % Full
Warning: Memory Usage estimation may not be accurate if there are sections other than .text sections in ELF file
Done executing task "RunOutputFileVerifyTask".
Done building target "CoreBuild" in project "int24.cproj".
Target "PostBuildEvent" skipped, due to false condition; ('$(PostBuildEvent)' != '') was evaluated as ('' != '').
Target "Build" in file "C:\Program Files (x86)\Atmel\Studio\7.0\Vs\Avr.common.targets" from project "C:\Users\Lenovo\Documents\Atmel Studio\7.0\!AVR128DA48_Curiosity_Nano\!Nauka\int24\int24.cproj" (entry point):
Done building target "Build" in project "int24.cproj".
Done building project "int24.cproj".

Build succeeded.
========== Build: 1 succeeded or up-to-date, 0 failed, 0 skipped ==========


Co dokładnie oznacza, że program „nie działa prawidłowo” w symulatorze — jaką wartość ma zmienna

wynik

, jaka jest oczekiwana wartość oraz czy sprawdzałeś wartość w pamięci/rejestrach, a nie tylko przez podgląd zmiennej w debuggerze?
Nie wiem jak sprawdzić wartość zmiennej "wynik" w pamięci. Nie wyświetla się adres komórki pamięci. Tak jakby tej zmiennej nie było.

To raczej wina symulatora. Nie potrafi poprawnie wyświetlić zmiennej zajmującej 3 bajty.
Zmień na int32_t i wtedy zadziała.
Albo musisz "ręcznie" podglądać zmienne.

Ja w pliku .map sprawdziłem gdzie leżą te zmienne


I sobie je podglądnąłem w symulatorze:



Jak widać działa poprawnie

100 * 1000 = 100000 w hexie to 0x64 * 0x3E8 = 0x0186A0

>>21925489 To niestety nie jest wina symulatora, gdyż ten kod nie działa również z debugerem sprzętowym (AVR128DA48 Curiosity Nano). ATtiny10 i symulator użyłem w celu prostego przedstawienia problemu. Pracuję nad wykorzystaniem biblioteki TWI opisanej w książce Tomasza Francuza "Język C dla mikrokontrolerów AVR" do obsługi pamięci AT24C32 przez AVR128DA48. W tej bibliotece stosowane są zmienne 24-bitowe do obsługi adresacji. Zmiana na zmienne 32-bitowe wymagałaby poważnej ingerencji w kod biblioteki.

Może sprzętowy debugger też nie potrafi poprawnie wyświetlić zmiennych o takim rozmiarze. Jutro to sprawdzę.
Ale program na pewno poprawnie wykona się na sprzęcie.
Więc kod działa, co widać w poprzedniej odpowiedzi.

z_lak1 napisał:

W tej bibliotece stosowane są zmienne 24-bitowe do obsługi adresacji. Zmiana na zmienne 32-bitowe wymagałaby poważnej ingerencji w kod biblioteki.

A próbowałeś zamieniać na uint32_t?

Dzisiaj to sprawdziłem na sprzętowym debuggerze (Snap) i wygląda na to, że Microchip Studio nie jest w stanie poprawnie wyświetlić zmiennej 24-bitowej.

Za to MPLAB X IDE v6.30 sprzętowy debugger wyświetla bez problemu zmienne 24-bitowe.
Bo w nim można zdefiniować rozmiar wyświetlania zmiennej.




Ale może opisz dokładniej, z czym masz problem? Że chcesz go debugować?
Ta biblioteka z książki nie działa?

>>21926127 Biblioteka opisana w książce Tomasza Francuza napisana jest na mikrokontrolery starszego typu. Ja piszę program na AVR128DA48, który wymaga innego podejścia do jego rejestrów. Ale to mam opanowane. Problem był ze zmiennymi 24-bitowymi, których (nie wiem dlaczego) nie chciał obsługiwać kompilator 7.3.0 w Microchip Studio 7.0.2594.
Problem rozwiązałem, pisząc swoją bibliotekę obsługi interfejsu TWI. Moja biblioteka nie korzysta ze zmiennych 24-bitowych.

z_lak1 napisał:

Problem był ze zmiennymi 24-bitowymi, których (nie wiem dlaczego) nie chciał obsługiwać kompilator 7.3.0 w Microchip Studio 7.0.2594.

A to ciekawa, bo u mnie nie ma tych błędów.
Ciekawa, czym się różnią twoje ustawienia od moich.

Nie wiem, o jakich ustawieniach piszesz?
Zaktualizowałem wszystkie Device Pack (Tools -> Device Pack Manager), ale to nic nie dało.

Mnie chodzi o to, że u ciebie pokazuje te 5 błędów w "Error List". A u mnie nie pokazuje.