ATNEL tech-forum

Re: Kłopoty z PSTR() w nowym toolchanie? w Eclipse - koniec!

2013-11-12T17:37:47+01:00

Dzięki nie pomyślałem

Statystyki: Napisane przez EmCom5 — 12 lis 2013, o 17:37

Re: Kłopoty z PSTR() w nowym toolchanie? w Eclipse - koniec!

2013-11-11T20:10:50+01:00

No a poprawiłeś także deklarację funkcji w *.h ?

Statystyki: Napisane przez mirekk36 — 11 lis 2013, o 20:10

Re: Kłopoty z PSTR() w nowym toolchanie? w Eclipse - koniec!

2013-11-11T20:00:11+01:00

Witam

Po prawienia w bibliotece HD44780.h funkcji lcd_str_P, otrzymuję błąd:

conflicting types for 'lcd_str_P'

Statystyki: Napisane przez EmCom5 — 11 lis 2013, o 20:00

Re: Kłopoty z PSTR() w nowym toolchanie? w Eclipse - koniec!

2012-08-28T13:30:38+01:00

makro PSTR ma taką postać:

Code:

# define PSTR(s) (__extension__({static const char __c[] PROGMEM = (s); &__c[0];}))

i już nie ważne czy z const czy bez const, jest to niejako instrukcja zakończona średnikiem, co oznacza, że jeśli jest w postaci definicji czy deklaracji to jest OK, jeśli zaś wystąpić ma w postaci argumentu funkcji to rzeczywiście z punktu widzenia syntaktyki zdaje się C++ jest to instrukcja, która NIC NIE ROBI (statement has no effect). Niestety gdyby to był C czy C++ stosowany na PC to nigdy z taką sytuacją byśmy nie mieli do czynienia ponieważ tam nie ma takich hocków-klocków z jakimś PROGMEM ... i całymi sztuczkami jakie trzeba robić w avr gcc żeby dopasować niejako C na potrzeby procków. Więc coś za coś - udało się to sprytnie za pomocą tego makra ominąć i kompilator AVR GCC sobie z tym radzi bo przecież nie zgłasza żadnych warningów! a to jest najważniejsze - więc możemy być pewni że z punktu widzenia AVR GCC jest wszystko ok

owszem jak się pracuje w eclipse to te podkreślenia (szlaczek żółty i to oznaczenie po prawej na pionowej belce) mogą drażnić bo po kompilacji zawsze wydaje się że pozostał jakiś warning, więc jeśli często posługujemy się czymś takim, to może to prowadzić do sytuacji, że wciąż będziemy musieli skrupulatnie od nowa przeglądać każdy przypadek i oceniać czy to coś złego czy nie....

więc znowu - można ponarzekać a można poszukać przyczyny ale i rozwiązania problemu. OK przyczynę już widać gołym okiem - za te szlaczki odpowiedzialne jest samo Eclipse i to akurat ta wersja - bo w innych tego nie ma. Czy to oznacza, że z tak błahego powodu ja miałbym np nie próbować nadal korzystać ze sporo lepszego Juno ????

Nie nie - można szukać dalej i znaleźć rozwiązanie - nie może być tak że coś tam się dzieje i nic nie da zrobić, no chyba że wykryjemy BUG'a w eclipse

Ja poszedłem tym tropem, że jak się najedzie kursorem myszki na to podkreślenie, to pojawia się:

hmmm w takim razie zamiast się martwić - może kliknę ten klawisz F2, żeby zobaczyć co mi się dalej pokaże:

Oooo! moim oczom ukazuje się podpowiedź: "Configure Annotation Preferences"

czyli będzie można to gdzieś ustawić w preferencjach - coś tam musi być takiego i to może jeszcze coś czego nie ma w innych wersjach Eclipse. No to bach na tapetę bierzemy kilka poprzednich wersji Eclipse i tę najnowszą - sprawdzamy.... skanujemy.... sprawdzamy.... skanujemy....

i ciach! okazuje się że w Juno mamy dodatkowo taką pozycję w drzewku jak niżej:

czyli pojawiło się: "Code Analysis" !!! a co w nim mamy po prawej ???

"Statement has no effect" !!!

generowane przez Eclipsa i możemy to pięknie wyptaszyć .... więc odptaszkowujemy tę opcję i pseudo-warningi z takich instrukcji znikają a nasze oczęta nie są drażnione.

Można byłoby się obawiać no że hmmm no ale co teraz jeśli tego typu błąd tzn ostrzeżenie wystąpi gdzieś w kodzie na prawdę ? to co - może tego nie zauważymy ???? ....

O nie nie - spokojnie to już byłoby ostrzeżenie kompilatora a nie Eclipsa więc po pierwsze pojawiłoby się w konsoli po kompilacji a jednocześnie nie wyobrażam sobie aby na taki Warning od kompilatora miał nie zareagować Eclips. No i proszę mam rację - zasymulujmy sobie w kodzie C wyrażenie które wygeneruje nam Warniga prawdziwego w konsoli można to zrobić tak:

i co widzimy że teraz nawet Eclips pokazuje obydwa ostrzeżenia nieco inaczej. To wygenerowane przez kompilator oznaczył standardowo trójkątem ostrzegawczym, a to wynikające z jego "Code Analysis" jakąś pchłą .... (bo znowu włączyłem PTAKA) przy tej opcji. A zatem teraz go wyłączam i proszę jak to wygląda:

czyli podkreślenia z domysłów eclipsa (code analysis) zniknęły bezpowrotnie natomiast warningi z kompilatora tak jak miały być tak pozostają.

KONIEC TEMATU

Statystyki: Napisane przez mirekk36 — 28 sie 2012, o 13:30

Re: Kłopoty z PSTR() w nowym toolchanie? w Eclipse - koniec!

2012-08-28T12:06:14+01:00

robiw napisał(a):

PS.1
Co prawda wbudowane funkcje ze string.h nadal krzyczą .

tak tego mogłem nie przebadać, ale podaj mi tu jakichś kilka linii z tymi funckjami, przypadkami gdzie krzyczą - to z chęcią sprawdzę bo pewnie i tak wcześniej czy później się z tym będę musiał zmierzyć - a nie cierpię warnigów w kodzie

Statystyki: Napisane przez mirekk36 — 28 sie 2012, o 12:06

Re: Kłopoty z PSTR() w nowym toolchanie? w Eclipse - koniec!

2012-08-28T11:01:24+01:00

Nie jest jedna i druga sugerowana zmiana deklaracji taka sama, ponieważ pierwsza dotyczy konfliktu typów zmiennych co pokazałem wyraźnie w przykładzie:

[syntax=c]char napis[] PROGMEM = "jakis napis"; // tak definiowaliśmy zmienną - bez const
void lcd_str_P( char * str ); // tak deklarowaliśmy funkcję - bez const przy argumencie
void lcd_str_P( napis ); // a tak wywoływaliśmy ją w kodzie - i to działało wcześniej[/syntax]

czyli tak pisaliśmy kiedyś (może nie wszyscy ale ja często pozwalałem sobie nie używać tu specyfikatora const - co się teraz zemściło) i to jest RÓŻNE od tego:

[syntax=c]
void lcd_str_P( char * str ); // tak deklarowaliśmy funkcję - bez const przy argumencie
lcd_str_P( PSTR("jakis napis") ); // tak wywoływaliśmy ją z PSTR() - i to też działało[/syntax]

gdzie tu widać takie same przypadki ?

Tylko rozwiązanie pozostaje to samo czyli należy (albo wystarczy) , użyć specyfikatora const przy argumencie w takich własnych funkcjach i koniec problemów, czyli teraz te dwa przypadki teraz muszą wyglądać tak:

[syntax=c]const char napis[] PROGMEM = "jakis napis"; // tak TERAZ powinniśmy definiować zmienną/stałą we FLASH
void lcd_str_P( const char * str ); // tak TERAZ powinniśmy opatrywać argument specyfikatorem const
void lcd_str_P( napis ); // to nie będzie warningu i wszystko zadziała prawidłowo[/syntax]

niże widać że rozwiązanie nieco innego kłopotu - właśnie z PSTR(), które w postaci makra automatycznie definiuje to samo ale ze specyfikatorem const to musimy tak zrobić:

[syntax=c]
void lcd_str_P( const char * str ); // tak TERAZ powinniśmy definiować zmienną/stałą we FLASH - jak wyżej -
lcd_str_P( PSTR("jakis napis") ); // teraz nie będzie warninga ponieważ zarówno stała zdefiniowana przez PSTR i argument mają const[/syntax]

Statystyki: Napisane przez mirekk36 — 28 sie 2012, o 11:01

Kłopoty z PSTR() w nowym toolchanie? w Eclipse - koniec!

2012-08-24T17:51:46+01:00

Witam, w związku z tym, że na maila dostałem więcej zapytań o co chodzi z tymi warningami przy PSTR()

http://mirekk36.blogspot.com/2012/08/ec ... zytaj.html

podczas używania nowego toolchaina atmelowskiego postanowiłem skrobnąć coś na ten temat - zapraszam do poczytania

Statystyki: Napisane przez mirekk36 — 24 sie 2012, o 17:51