Fajny ten C.
Wkurzam się tylko, że zamiast pisać, a właściwie próbować pisać, to mnóstwo czasu tracę na "pierdoły" w stylu zastanawianie się dlaczego kompilator się pluje na taką deklarację i definicję:

błąd:
No naprawdę nie wiem o co mu chodzi. Jak zmienię parametr z uint8_t na char to już nie ma błędu.

Wie ktoś o co biega?

Kolega lepiej pokaże deklarację swojej stałej dosłownej CLIP_DISABLE, bo skoro jest taki komunikat to tam trzeba szukać błędu, gdyż nazwa CLIP_DISABLE jest prawdopodobnie źle rozwijana.

I tak mi się coś zdaje, że u kolegi ta definicja wygląda mniej więcej tak: (nie istotna tu jest już wartość)



a pisałem w książce wyraźnie, żeby unikać średników na końcu linii podczas definicji #define .... bo jeśli tak kolega ma to jak kompilator może się "nie pluć" jak kolega pisze, jeśli grzeczny sługa PREPROCESOR zamienia tą nazwę CLIP_DISABLE tak dla kompilatora:



czy kolega jako kompilator też by się nie wkurzył, gdyby ktoś mu podał takie coś do kompilacji ???

Zatem błąd może się okazać banalny jeśli jest tak jak przewiduję, zatem definicja powinna zgodnie z regułami podanymi w książce wyglądać tak:



Reasumując proszę być spokojnym - tego typu błędy na początku są normalne - i niedługo kolega się ich pozbędzie na zawsze.

Chyba że źle przypuszczam - więc proszę pokazać więcej kodu żeby to rozwikłać - czekam na info.

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

To chyba nie to.
Definicja jest ok:
To samo w eclipse i avrstudio5. Wystarczy, że zmienię uint8_t na char i się kompiluje.
Próbowałem już usuwać pliki *.c i *.h tworzyć nowe, albo bez pliku nagłówkowego, z deklaracjami w *.c .

Jak pousuwam deklaracje i definicje, to jak chcę na nowo je utworzyć ( po prawidłowej kompilacji kiedy są usunięte ), to po wpisaniu nazwy funkcji intellisense pamięta jakie były ostatnio parametry i podpowiada. Zresztą samą nazwę funkcji też chyba pamięta.
Piszę o tym, bo nie wiem czy to może pomóc dojść o co chodzi, ale wątpię, bo nowa nazwa funkcji nic nie zmienia.
Dla mnie czary

Posłuchaj ale ja ten twój kod na żywca wpisałem u siebie do Eclipse. I żadnych takich cudów nie mam. Dlatego twierdzę, że błąd może leżeć jeszcze całkiem gdzie indziej lecz na podstawie takiego wyrywka informacji/kodu programu nie da się tego wprost stwierdzić. Można co najwyżej tylko jak widzisz - przypuszczać i nie trafiać.\

Dlatego proponuję jak zwykle - spakuj cały projekt i podeślij mi na maila: biuro@atnel.pl

Tylko projekt w Eclipse a nie ten brrrr w kocim AVR Studio 5

Nie ma takiej możliwości żeby to nie działało - a warto dojść co się dzieje, żebyś się nie męczył i nie zniechęcił - a przy okazji nauczył się szukać tego typu błędów

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

Ok. Wieczorem podeślę jak wrócę z pracy.

No dostałem maila. Panie kolego żbik otworzyłem ten projekt, chociaż przyznam, że o mało co nie przeżegnałem się lewą nogą .... (jednak rozumiem początki - sam kiedyś mocno mieszałem, aż za mocno).

Szkoda tylko, że kolega nie stosuje się do zasad podanych w książce jeśli chodzi o tworzenie projektów, nazewnictwo plików czy folderów - niestety to pokutuje i będzie jeszcze długo pokutować - jeśli kolega nie przekona się do zasad dobrego programowania.

Jeśli potrzeba jakiejś konsultacji w tej sprawie to zapraszam serdecznie na Skype do mnie, akurat tego typu sprawy łatwo naprostować - tylko trzeba chcieć.

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

WRACAJĄC DO TEMATU:

oczywiście winny jest sposób myślenia o którym piszę wyżej a rozwiązanie takie na szybko problemu kolegi sprowadza się do tak banalnej rzeczy, że aż strach. Przecież kolega pisze jakiś plik z rozszerzeniem *.c, jak więc to możliwe, że chce korzystać z typów, z nazw pinów procesora itp nawet kolega w tym pliku nie podciąga

N A J W A Ż N I E J S Z E G O SYSTEMOWEGO PLIKU NAGŁÓWKOWEGO

#include <avr/io.h>

????? hmmm - toż to nie dziwne, że jeśli brak tego pliku to będzie burza na wiok typu uintx_t - gdyż kompilator nie wie skąd wziąć plik nagłówkowy dla danego procesora i w ogóle dla języka C

Proszę na poważnie rozważyć jeszcze raz:

1. jak najszybszą rezygnację z AVR Studio 5 - bo tu wprowadza się kolega w wyższe stany nieświadomości i już w ogóle nie panuje nad projektem.

2. działanie w Eclipse zgodnie z zaleceniami - przynajmniej na czas nauki - początków nauki języka C - bo to pomoże koledze mieć kontrolę nad plikami projektu. (ja wiem że wiele osób uważa, że przesadzam - ale proszę to nie jedyny przypadek, że tak się kończą projekty - tzn jakimi błędami. Przecież jak już wiadomo skąd bierze się ten błąd to każdy sobie zda sprawę jakie to niby banalne) no ale żeby do niego dojść to najpierw warto po drodze zapoznawać się z całą hierarchią plików i bibliotek w C. A dzięki Eclipse - poruszanie się pomiędzy nimi to poezja. Szkoda tylko, że niektórzy na siłę robią sobie krzywdę.

Dlatego - szczerze zapraszam na Skype do mnie, będzie można zadać parę pytań a ja z chęcią udzielę odpowiedzi i kilku wskazówek, żeby naprowadzić na właściwe tory. To jak kolega już zaskoczy - wtedy dalej będzie już sam swobodnie jechał w tym wagoniku o nazwie C

(tylko jeśli ma to być szybka i zwarta konsultacja to na Skype zapraszam wyłącznie z mikrofonem i słuchawkami - bo niestety na pisanie w komunikatorze za dużo czasu schodzi i o wiele trudniej się porozumieć czy coś wytłumaczyć)

życzę powodzenia

a dla porównania tak wyglądał plik kolegi z tym super tajemniczym błędem:



a tak wygląda po mojej propozycji obróbki i dodaniu najważniejszego INKLUDA



Proszę wziąć do siebie uważnie wszystkie propozycje poprawek i dokładnie przeanalizować różnice. W końcu chodzi o to żeby także kod był bardziej czytelny prawda ?

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

Dzięki za pomoc w rozwiązaniu problemu. Nigdy nie wpadł bym na to, że może chodzić o <avr/io.h>.

I w sumie dalej nie wiem dlaczego jest wymagany, skoro w pliku są same deklaracje / definicje, a nie są użyte operacje na portach.
Wygląda na to, że muszę jeszcze sporo doczytać.

Mam jeszcze pytanie o stringi, ale to w innym temacie..

pzdr.

Ale dołączenie <avr/io.h> wcale nie jest wymagane tylko wtedy gdy są operacje na jakichś tam portach. To jest podstawowy plik, który zawsze trzeba załączyć jeśli już piszemy jakiś kod. To od niego zależy w ogóle czy kompilator będzie wiedział dla jakiego mikrokontrolera piszemy swój program. Bez tego jest ślepy i głuchy. A kolejną ważną rzeczą poza nazwami portów w tym przypadku było już użycie TYPÓW przez kolegę. A ponieważ typ "uint8_t" nie jest typowym typem czystego języka C, tylko pewnym rozwinięciem i udogodnieniem konkretnej wersji AVR GCC to nie trudno się domyśleć, że chociażby i z tego powodu kompilator musi mieć zainkludowany taki podstawowy plik nagłówkowy. Mam nadzieję, że teraz trochę jaśniej.

I jak na drugi raz kolega będzie pisał kod, to sporo problemów tego typu zniknie - bo już zawsze kolega podciągnie ten plik.

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