Witam
Mam mały problem z Eclipse (tak sądzę ) otóż podczas kompilacji mojego programu otrzymuje błąd przy zamykającym nawiasie } funkcje int main(void) {} dokładnie chodzi o błąd "internal compiler error: in push reload, at reload.c:1360" opisywany też w tym temacie topic14846.html

Błąd powstaje wtedy gdy w programie pojawi się ta część kodu

gdy ją za komentuje całą wszystko kompiluje się Ok.

W załączniku wrzucam cały plik main.c

Sprawdziłem i na pewno nawiasy są OK.
Założenie nowego projektu również nie pomogło.
Zmienne pm, pm2, czd, czu, mam zdefiniowane na początku programu przed ciałem funkcji main() więc jeśli dobrze rozumiem powinny mieć zakres globalny o czym mowa jest w temacie topic14846.html również nie pomogło.

Program dałem do skompilowania koledze i w Atmel Studio 4 kompiluje się bez problemu.

Ja program kompiluję w Eclips MARS (Mars.1 Release (4.5.1)) , Atnel Toolchain 3.4.5.1522 i AVR_plugin_241 pobrane z bloga Mirka.

Będę bardzo wdzięczny za każdą sugestię.

Błąd masz tutaj:


Błąd powoduje zmienna "czu".
A bezpośrednią przyczyną są wyliczenia:


Pytanie jest takie dlaczego to się dzieje? Coś jest nie tak z przekazaniem parametru do sprintf.
A AS działało, bo tam prawdopodobnie jest inaczej zrobiony sprintf, inne biblioteki.
Po chwili prób niestety nie udało mi się znaleźć przyczyny. Próbowałem jawnie rzutować na kilka sposobów, ale bez rezultatu, może ktoś bardziej zaawansowany coś jeszcze podpowie.

Co do kodu, to wg mnie piszesz trochę za dużo "linijek na raz".
Warto skracać rozwlekłe ciała funkcji, czy if'y do mniejszych "bloków", łatwiej to analizować

Kolejne analizy.
Błąd mamy przy optymalizacji -Os, oczko niżej -O3 już wszystko działa.
Zatem kompilator wpływa prawdopodobnie na przekazanie parametru.
Znalazłem obejście dla -Os, wystarczy wprowadzić dodatkową zmienną, np

i podstawić ją zamiast "czu" do funkcji sprintf.

Jeszcze inne obejście problemu, to zamknięcie problematycznej sekwecji do osobnej funkcji, np:


i wywołanie jej w odpowiednim miejscu.
W następnym kroku należałoby zajrzeć do rozwinięcia asemblerowego, ale to już pozostawiam innym

Do tego należy dodać jeszcze jedno pytanie dlaczego w AVR Studio 4 wszystko kompiluje się OK. A u mnie w Eclip problem pojawia się tylko wtedy gdy pojawia się drugi raz kod



A przecież wcześniej w części //pomiar kanał 1 też jest zmienna czu i obliczenia też są te same ?? Co ciekawe wprowadzenie innych zmiennych dla pomiar kanał 2 np. zamiast czu wprowadzenie czu1 też nic nie zmienia błąd dalej jest.

Jak widzę taki kod to zachodzę w głowę - po jakiego grzyba jest ten IF ? skoro wystarczy TA JEDNA LINIA bez IF'a



------------------------ [ Dodano po: 1 minucie ]

po to stosuje się formatowanie żeby nie bawić się w takie kocie IF'y, które pokazałem w Bluebooku TYLKO po to aby zrozumieć jak to działa .... a jak już się sięga po sprintf i formatowanie - to się z tego w pełni korzysta

_________________
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 ]

Będę się upierał, póki co, że podałem przyczynę.
Inny program, inny kompilator, inny poziom optymalizacji.
Pójdź tym tropem i porównaj wersje składowych obu środowisk.

Poprawiłem według i podpowiedzi kolegi Zealota i według Mirka błąd nadal występuje bez zmian.
Jeszcze raz załączam cały main.c
Ten sam błąd kiedyś Mirku występował w kodzie FAT FS z blueboka topic14846.html

Zealota też tak myślę wyciągając wniosek z tematu wyżej gdzie też na jednym Atnel Toolchain było dobrze a na drugi nowszym był już błąd, niestety jestem za cienki żeby sam to poprawić.
Może Mirek jeszcze coś podpowie.
Dziękuję za pomoc.

Ja nie mam na tyle czasu aby analizować tak rozbudowane kody, jak sprowadzisz go do postaci o jakiej pisał Zelaota



dla mnie to PODSTAWA jak się wrzuca jakiś problem w kodzie, czyli wyizolowany mały fragment - wtedy można testować

------------------------ [ Dodano po: 6 minutach ]


Ja bym potrzebował fragmentu kodu a nie hektolitry kodu. Więc wyizoluj problem do kilku linijek i go wklej. Wiesz - tak żeby ktoś kto zagląda do postu mógł stworzyć sobie w Eclipse pusty projekt, wkleić twój fragment kodu i sprawdzić czy ma taki błąd i próbować znaleźć rozwiązanie. A przecież w tym swoim pliku mainC poza mnóstwem kodu nie mającego NIC WSPÓLNEGO z problemem, masz pełno zależności z różnymi plikami bibliotek itp itd

Pokaż dokładnie jaki masz błąd w konsoli

wtedy będę mógł sprawdzić - no i w ogóle jakiej wersji toolchaina używasz ? zakładam, że najnowszej ?

------------------------ [ Dodano po: 10 minutach ]

ok żeby nie było, że cię zbywam - to WEŹ ŻE PAN ZOBACZ co to znaczy "wyizolowanie problemu do kilku linijek:




no ale ten twój kod u mnie nie powoduje żadnych błędów kompilacji - więc ty sprawdź czy u ciebie powoduje - i na bazie czegoś takiego zadaje się porządne pytanie na forum - rozumiesz ?

_________________
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 ]

Akurat miałem trochę "czasu", więc wyizolowałem problem, podałem dwa rozwiązania obejścia.
Jedno ze zmienną tymczasową, a drugą z migracją bloku programu do funkcji.
U mnie obie kompilują się bez błędów, na Eclipse Neon, aczkolwiek bez modyfikacji miałem dokładnie taki sam błąd jak Kolega Rafciu.



Po modyfikacjach, stworzeniu funkcji wyświetl(), taki main.c się u mnie kompiluje bez błędów.
Nie powiem tylko czy działa, ale nich Kolega podejmie próby - może zadziała poprawnie aczkolwiek ten kod i tak do przerobienia, bo ta moja funkcja to w złym miejscu jest i działa na zmiennych globalnych, a to mało eleganckie .
Ustawiłem u siebie opcję optymalizacji -Os

No ale to w czym jest problem jeśli i u ciebie się kompiluje wszystko poprawnie ? bo u mnie też ten fragmencik co ja pokazałem

------------------------ [ Dodano po: kilkunastu sekundach ]

czy jednak masz błędy przy jakiejś wersji toolchaina ? jeśli tak to możesz sprawdzić ten mój wyizolowany problem ?

_________________
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 ]

Ja sprawdziłem u siebie i o dziwo działa
Nawet wrzuciłem do petli głównej i wrzuciłem do if'a, podobnie jak w "oryginale" i nadal działa
Na razie nie rozumiem...

ano właśnie ale to w taki sposób warto izolować problem - czyli PO kawałkach - bo babol czasem może leżeć całkiem gdzie indziej

_________________
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 ]

Dobra po kolei
Mirku
Błąd w konsoli

Kompiluję w Eclips MARS (Mars.1 Release (4.5.1)) , Atnel Toolchain 3.4.5.1522 i AVR_plugin_241 pobrane z bloga Mirka.

Błąd pojawia się wtedy gdy w całym main.c pojawia się ten wycinek kodu

jeśli wytnę pomiar kanał 1 lub pomiar kanał 2 tak żeby została tylko ta część



Wszystko jest Ok kompilacja bez błędu.

Sprawdziłem też tak jak zaproponowałeś Mirku i też jest dobrze.

Zealota Twój kod też sprawdzę być może będzie dobrze, zastanawia mnie tylko to dlaczego tak się dzieje ? czy jest to wina jakieś błędu w programie czy problem kompilatora jakiego Atmel Tolchain używasz?

Niestety izolowanie wpędza mnie w pętlę, raz nie działa jeden sprintf raz inny
Po usunięciu "tego magicznego bloku, o którym pisaliśmy", to zaczęło się wywalać na :


Babol faktycznie musi być gdzieś indziej. Ten podejrzany nawias "}" w opisie błędu jakoś wskazuje mi, że gdzieś jest jakieś ukryte makro, a błąd w nich, jak wiadomo, potrafi być upierdliwy.

------------------------ [ Dodano po: 4 minutach ]


Tak to u mnie wygląda:


A to wersja ogólna toolchain.
toolchain-3.5.3.1700

Zealota jak byś chciał jeszcze coś zerknąć to podaj maila pośle Ci cały projekt, bo ze względu na duża ilość kodu z książek Mirka nie chciał bym publikować tego w sieci, a wtedy będziesz mógł wszystko kompilować tak jak jest bez wycinania pewnych rzeczy. Dziękuję i pozdrawiam.

Możesz wysłać przez prywatną wiadomość, tak mi się zdaje, ale podejrzę dopiero wieczorkiem.

Zealota poszło PW

Zrobiłem pewne poprawki:


Popatrz na main i pętlę główną, wg. mnie o wile lepiej to wszystko analizować.

Co do błędu, niestety nie znam konkretnych przyczyn aczkolwiek, jak pisałem wcześniej, opakowanie problematycznych procedur w funkcje zamaskowało problem. Może to wystarczy. Skompiluj to co przygotowałem, może zacznie Ci działać

PS
Niestety rozwaliłem Ci kodowanie, będziesz musiał poprawić sobie krzaczki

Zealota wrzuciłem kod do siebie i generalnie jest ok błędu nie ma. Jednak pomiar prądu nie działa za dobrze na chwilę dodałem oddzielne zmienne pm i pm1 dla kanału 1 i pm2, pm3 dla kanału 2, może mało eleganckie ale na chwilę do testów wystarczy, bo i tak będę jeszcze przerabiał pomiar z tych kanałów.

Moim zdaniem problem tkwi w kompilatorze może nowszy ma coś pozmieniane odnośnie optymalizacji i po prostu pewne nie eleganckie kody jak mój mogą powodować takie błędy. Wyjaśniało by to że na AVR Studio wszystko kompiluje się ok a kolega wiem że używa starszej wersji.

Co by nie było jestem bardzo wdzięczny za pomoc i pokazanie bardziej poprawnego stylu pisania programu co dla mnie osoby bardzo rzadko bawiącej się w programowanie jest bardzo przydatne.
Jeszcze raz wielkie dziękuję.

Tak. To jest błąd kompilatora powiązany z kodem oraz stopniem optymalizacji. Niestety optymalizacja kodu to dość skomplikowany proces i czasami gcc potrafi się wyłożyć . No cóż to na razie piszą tylko ludzie .
Patrząc się na zgłoszenia błędów w gcc, to ten błąd pojawiał się kilkukrotnie w różnych sytuacjach i był teoretycznie poprawiany a potem znowu wychodził . W najnowszej wersji gcc (>= 8.0) podobno już wszystko znowu działa poprawnie. Ale avr-gcc z toolchaina nie jest oparte na najnowszym gcc, więc my ten problem mamy niestety nie poprawiony.
Z oficjalnych rad (workaroundów) na problem, to zmiana stopnia optymalizacji kodu (zmienna -O, na -O2 lub -O3) lub zmiana kodu by gcc mógł poprawnie go zoptymalizować nie trafiając na swoje ograniczenia.

--
Pozdrawiam,
Robert

Dziękuję za info rskup A czy mógł byś powiedzieć gdzie w Eclipse zmienia się stopień optymalizacji, czyli zmienia zmienną -O, na -O2 lub -O3?
Dziękuję i pozdrawiam.

Może ja podpowiem . W Project/Properties

_________________
Pozdrawiam
PP

Optymalizację zmienia się we właściwościach projektu w C/C++ Build -> Settings -> Tool Settings -> AVR Compiler -> Optimization.
Ale raczej powinieneś pozmieniać kod w miejscu gdzie generuje się błąd by kompilacja działała a nie zmieniać stopień optymalizacji, bo ta wpływa na cały kod a nie tylko ten fragment.
Z tego co widziałem w zgłoszeniach bugów gcc, to ten problem generuje używanie funkcji sscanf, sprintf, itp. Zakomentuj je w tej części kodu na chwilę i zobacz czy to jest związane z użyciem tych funkcji. A potem zastanów się czy da się ten fragment zrobić inaczej .

--
Pozdrawiam,
Robert

------------------------ [ Dodano po: 12 minutach ]

Rzuciłem okiem na Twój kod i prawdę mówiąc to jeżeli chcesz go optymalizować do wersji -Os to kompilator ma dużo do zrobienia, bo jest on bardzo nieoptymalny. Więc pewnie przez ten "natłok" roboty i wewnętrzny błąd wysypuje się on .
Nie analizowałem wszystkich propozycji w tym wątku, ale czy przeniesienie obróbki pomiarów w kanałach do funkcji nadal generuje błąd przy kompilacji?

Dzięki za info odnośnie ustawień optymalizacji kodu.
Kolega Zealota pomógł mi i przeniesienie problematycznego kawałka kodu do oddzielnej funkcji pomogło, poza tym trochę uporządkował ten mój bałagan

Nie generuje i to jest ten plus nie wiemy za to dlaczego, a to ten minus

Wątek ciągnie się troszkę "jak makaron" ... a wnioski są dość proste i oczywiste. Gdy stosuje się prawidłowe techniki programowania - czyli wyprowadzanie fragmentów kodów do funkcji (jak powinno się programować w C) to problem nie występuje nawet (z tego co czytam - nawet w starszych wersjach kompilatora)

Wniosek jest jeden - jeśli ktoś traktuje pisanie kodu w C tak jak w Bascomie czy w Andruino - tzn jeden WIELKI plik źródłowy a o funkcjach? - można zapomnieć ... to nie dziwota - że tym bardziej przy takim podejściu które pokazałem wyżej - kompilator może zaświrować

-------------------------

proponuję prosty test - bo nie mogę wciąż osiągnąć waszych problemów które opisujecie - żeby zastosować JEDNĄ funkcję sprintf() ale z prawidłowym formatowaniem i pewnie już będzie po problemie

a po drugie - tak jak to zaczął SŁUSZNIE pokazywać kolega Zelaota .... czyli wyprowadzać wszystko do funkcji zewnętrznych - bo TO JEST NORMALNA DROGA w programowaniu w C .... to wtedy nie będzie trzeba tracić czasu i analizować "dlaczego jest błąd?" gdy ktoś pisze kod wbrew no niestety logice - rozbudowując main.c do jakichś monstrualnych rozmiarów.

Nie mam zamiaru tu robić komuś przytyków czy przykrości a tylko zwrócić uwagę autorowi, że warto się skupić JAK NALEŻY podchodzić do tworzenia kodu (tak jak pokazał np Zelaota) niż przez 30 dni rozważać dlaczego kompilator pokazuje błąd gdy się w tak nieodpowiedzialny sposób tenże kod źródłowy tworzy. Mam nadzieję, że zostanę poprawnie zrozumiany - a nie, że komuś jakieś przytyki robię. Pewien wzór rozwoju tak źle napisanego kodu pokazał Zelaota i ... panie Raficu - warto się uczyć takiego podejścia

_________________
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 ]