Witajcie wszyscy szlachetni rycerze władający językiem C!
Przyuczając się do operowania tymże "orężem" natrafiłem na pewien problem który od 3 dni nie daje mi spokoju.
Zanim jednak zacznę opisywać intrygujące mnie zagadnienie kilka słów o karierze "domorosłego programisty" jakim jestem. Moja droga zdobywania wiedzy kręta jest i zahaczająca o źródła internetowe wszelakie. Podstawy elektroniki, liźnięcie asemblera procesorów 8051 w szkole średniej i obecnie na studiach C ułatwiła nieco start w pełnym prądów, napięć, sygnałów i programów świecie. O ATNEL-owskim stylu dowiedziałem się stosunkowo niedawno, pożyczając Blue Booka od znajomego. Stąd też dopiero uczę się nawyków dobrego pisania kodów i odpowiedniej obsługi... i odkładam PLN-y na własną, bardzo mi się spodobała i chcę mieć ową książkę oraz jej następczynie w swojej biblioteczce. Działam też na pakiecie-staruszku WinAVR 20100110 4.3.3 z Programer's Notepadem i edytorem Makefile. Poligon testowy stanowi płytka stykowa z ATMEGĄ-8, a do przelewania mojej twórczości do mikroprocesora zwykły programator USB-ASP. Dotychczas jednak kody wszelakie, czy to ostatnimi czasy z książki, czy też z sieci problemów nie do rozgryzienia raczej nie stwarzały.

Chcąc zaprzyjaźnić się ze wskaźnikami, strukturami, typami wyliczeniowymi, callbackami na przykładzie generowanego poprzez program z tego tematu http://forum.atnel.pl/topic12164.htmltrafiłem na różne błędy w trakcie kompilacji. Świadom tego, że wynikać mogą one zapewne z tego, iż obsługuję wyświetlacz z pomocą innych niż w książce bibliotek (samą książkę mam, ale zasobów jakie są do niej dołączane ów znajomy mi nie dał) zasiadłem do dostosowywania jej wedle swoich potrzeb. Dodam że wyświetlacz LCD HD44780 4x20 z przejściówką I2C na układzie PCF8574AT steruję na co dzień z powodzeniem dzięki bibliotekom z tego oto bloga: http://moja-elka.blogspot.com/2016/03/modu-i2c-1602-dla-wyswietlaczy-lcd-ze.html
I wszystko szło pięknie, ilość błędów związanych z brakiem pewnych funkcji spadła w zasadzie do 0 dzięki podglądaniu na bieżąco BB. Aaale stety niestety nie ma tak lekko. Gdyż w miejscach gdzie menu odwołuje się do wyświetlenia stringów z pamięci FLASH dostaję błąd invalid initializer.

Pliki na których obecnie pracuje spakowałem w zip i dodaję w formie załącznika (Dzięki Pan_Kracy za podpowiedź) .
A to komunikaty błędów z konsoli

Compiling C: jbmenu.c
avr-gcc -c -mmcu=atmega8 -I. -gdwarf-2 -DF_CPU=8000000UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wa,-adhlns=./jbmenu.lst -std=gnu99 -MMD -MP -MF .dep/jbmenu.o.d jbmenu.c -o jbmenu.o
jbmenu.c: In function 'display_menu':
jbmenu.c:108: error: invalid initializer
jbmenu.c:119: error: invalid initializer
jbmenu.c: In function 'zmiana_wartosci':
jbmenu.c:195: error: invalid initializer
jbmenu.c: In function 'zmiana_wartosci_godzinowych':
jbmenu.c:250: error: invalid initializer
jbmenu.c: In function 'on_off':
jbmenu.c:286: error: invalid initializer
make.exe: *** [jbmenu.o] Error 1

Czy jest ktoś z was w stanie choć naprowadzić mnie na to, gdzie powinienem był szukać błędów? Złe typy, złe odwołania, czy jeszcze coś innego? Będę bardzo wdzięczny za każdą formę pomocy, niekoniecznie przysłowiową "rybę". W razie rażących błędów oraz zbyt długiego tekstu proszę o łagodny wymiar kary

Spakuj projekt do zipa (wszystkie pliki razem z makefilem) i zamieść w poście, jest większa szansa, że ktoś ściągnie i wrzuci do siebie na kompilator.

Zapoznaj się z tym opisem: http://mirekk36.blogspot.com/2012/08/ec ... zytaj.html
Myślę, że powinieneś zainteresować się makrem PSTR i polecałbym, przerzucenie się na nowy zestaw narzędzi do programowania uC, w tym na Atmel Toolchain.

_________________
Migracja z punktu B do punktu C
Pozdrawiam

Eclipse i atmelowski toolchain zainstalowany, żałuję że tak długo zwlekałem, poczułem nową jakość "kodzenia" .

Makro PSTR zostało przypisane przez dyrektywę preprocesora w kodzie w ten sposób:
lcdpcf8574.h


zmieniłem deklarację i definicję funkcji zgodnie z poradą na blogu mirka(tu deklaracja):


Niestety, odwołanie do funkcji nadal zwraca ten sam błąd:
../jbmenu.c: In function 'display_menu':
../jbmenu.c:109:4: error: invalid initializer
lcd_str_P((const unsigned char *) pgm_read_word(&menu[current_menu].text));

Zmiana z unsigned na jego brak też różnicy nie robi.

Natrafiłem też na pokrewny temat na forum ( http://forum.atnel.pl/post174998.html#p174998 ) i spróbowałem nie używać pgm_read word, bezskutecznie.

../jbmenu.c: In function 'on_off':
../jbmenu.c:286:2: error: invalid initializer
lcd_str_P((const char*)&menu[current_menu-1].text);

Po zakomentowaniu zaś deklaracji makra z z PSTR w pliku .h wyświetlacza jest już ok, a po ujednoliceniu znaków argumentów typu char przyjmowanych przez funkcję lcd_str_P nawet bardzo, bo warningi poznikały
Obsługa klawiatury dodana iiii ruszyło! Jeszcze tylko funkcję lcd_defchar muszę dopieścić.

Mam jeszcze tylko małe pytanie (coby wiedzieć na przyszłość).

Usunąłem z kodu tą dyrektywę #define, program zaczął działać. Mniemam że związane jest to z faktem, że ta dyrektywa podstawia ciąg znaków na ślepo. Nawias (__s) w normalnym biegu programu oznacza naszą zmienną odpowiedzialną za tablicę znaków do wyświetlenia. W kodzie menu argument funkcji podawany był zaś jako bezpośrednia nazwa pola struktury. Osoba pisząca tą bibliotekę musiała mieć jednak jakiś zamysł takiej makrodefinicji. Czy zatem __s może być jednak odczytywane przez preprocesor jako "weź zmienną jaką Ci podadzą i dla niej wykonaj lcd_str_P(PSTR())?

Nie można stosować PSTR() do wszystkiego jak leci ..... Tylko do stałych dosłownych a dokładniej mówiąc do literałów, nie zaś do np zmiennych czy wskaźników które już wskazują na adres we flash. Tylko że one muszą być również const.

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Wczoraj to też przerabiałem przy minimalizacji zajętości RAM. Wniosek - bez tego makra lub braku "PSTR" w kodzie, zajętość RAMu jest większa. Jest dublowany zapis(w RAM i FLASH). Nadal testuję!

Mirku, rzeczywiście. Przy pierwszym czytaniu o PSTR musiało mi to jakoś umknąć. Wirnick, chętnie poczytam o efektach Twoich testów!
Tymczasem męczy mnie funkcja defchar, zarówno przy zapisie do RAM-u jak i FLASH-a. Czy możliwe to, aby sterownik który mam w wyświetlaczu posiadał inne adresy pamięci CGRAM do definicji własnych znaków? Wnioskuję po tym, że odwołując się bez używania defchara do znaków \x80-\x87 otrzymuję na wyświetlaczu znaki tj 'y' '{' '}' 'strzałka w prawo', spacje i 'w'. Zaraz wygrzebię wyświetlacz 2x16 bez modułu I2C i sprawdzę czy mam podobne problemy z definiowaniem znaków na nim.

Na chwilę obecną defchar działa, ale tylko w wersji dla znaków z ram i tylko wyświetlanych poprzez np lcd_putc('0x80'); Co ciekawe definiowanie znaków i ich wyświetlanie działa też poprzez adresy 0x00-0x07, a nawet wymiennie z 0x80-87. Tu "poligonowy" kod. Co robię nie tak?