Programy i Problemy

Problemy podczas kompilacji

Pierwszym sprawdzianem dla naszego programu jest kompilacja. Prawdopodobnie wielokrotnie otrzymamy komunikaty o błędach.
Z reguły są to błędy popełnione przez nas i można je podzielić na kilka grup:

• Brak Makefile w katalogu projektu – przykład.
• Błędy spowodowane niedołączeniem plików nagłówkowych – przykład.
• Błędy spowodowane użyciem makr niezdefiniowanych w dołączonych plikach nagłówkowych – przykład.
• Błędy spowodowane niedołączeniem innych plików źródłowych.
• Błędy składniowe.
• Niezadeklarowanie zmiennej.
• Użycie pliku Makefile skopiowanego z innego projektu bez uaktualnienia nazw plików źródłowych.
• Podanie w pliku Makefile jako MCU kontrolera, który nie ma właściwości wykorzystywanych w programie (przykład z grubej rury – podałem jako MCU AT90S2313, a w programie wykorzystuję  przetwornik AD).

W przypadku otrzymania komunikatów o błędach kompilacji należy spokojnie wyszukać miejsce gdzie błąd powstał, poczynając od pierwszego w kolejności. Często okazuje się, że jeden błąd jest przyczyną całego ciągu komunikatów.
Aby zmniejszyć prawdopodobieństwo powstania błędów zadbaj o następujące rzeczy:

• Trzymaj wszystkie pliki źródłowe i plik Makefile w jednym katalogu przeznaczonym dla danego projektu
• Zadbaj o przejrzyste i konsekwentne nazewnictwo plików projektu
• Stosuj edytor z podświetlaniem składni
• Używaj indenacji (wcięć) wbudowanej w edytor aby hierarchia wyrażeń w kodzie była widoczna
• Włącz zaznaczanie par nawiasów
• W przypadku jeśli projekt jest tworzony  w  oparciu  o  inny  pamiętaj  o  uaktualnieniu  Makefile i dołączeniu niezbędnych bibliotek
• Jeżeli  korzystasz z gotowego kodu upewnij się że jest on czytelny dla Twojego kompilatora

Pamiętaj, że kompilator jest programem rozwijanym przez wiele lat przez wielu utalentowanych ludzi, posługuje się nim wielu znakomitych specjalistów raportujących twórcom zauważone nieprawidłości w działaniu.
Czytając komunikaty o błędach pamiętaj, że to są błędy popełnione przez Ciebie.
Prawdopodobieństwo znalezienia błędu w działaniu kompilatora podczas kompilacji programu migającego diodą LED jest zbliżone do prawdopodobieństwa wykrycia kosmitów na Plutonie przy użyciu kamerki internetowej.

Problemy przy programowaniu kontrolera

Jeśli uporamy się już z kompilacją przychodzi czas na próbę działania programu. Generalnie są dwie możliwości, symulacja programowa albo załadowanie programu do kontrolera i sprawdzenia go w świecie realnym. Podczas pierwszych prób programowania kontrolera również możemy się spodziewać różnych komplikacji.
W zdecydowanej większości przypadków przyczyną kłopotów jest użycie wadliwego programatora lub niedostępność portu do którego jest przyłączony.
Wielu z nas stosuje własnoręcznie zmontowane układy. Jakość tak wykonanego urządzenia zależy w dużej mierze od wprawy, staranności i umiejętności lutowania. Odradzam stosowania kabli ISP składających się z kilku drutów i oporników. Zbuduj porządną wtyczkę opartą na sprawdzonym schemacie, a zaoszczędzisz w przyszłości wiele czasu.
W przypadku problemów z zaprogramowaniem należy sprawdzić:

• W systemach Linux i Windowsach opartych na NT czy mamy dostęp do „/dev/parport0” (Linux) lub LPT1 (Windows) . W Linuksie dla upewnienia się można wydać (jako root) polecenie „chmod 666 /dev/parport0”. W Windows należy sprawdzić czy działa program „giveio.sys” dający dostęp do portów –  zobacz jak. Jeżeli nie działa, to przy próbie programowania otrzymasz następujący komunikat.
• Dostępność portu USB (programator USBASP).
• Podłączenie portu, programatora i kontrolera. Jeśli nie ma połączenia może być następujący komunikat.
• Ciągłość masy między kontrolerem, a portem LPT (programator typu STK200/300, BSD).
• Czy jest prawidłowe napięcie zasilania na układzie scalonym programatora. Sprawdzać należy na nóżkach układu. Układ programatora powinien być zasilany z płytki z kontrolerem, a nie z portu drukarkowego.
• Czy jest prawidłowe napięcie zasilania na kontrolerze. Sprawdzać należy na nóżkach układu.
• Czy jest ciągłość przewodów między układem 74HC244 (programatora „stk200/300”) lub ATmega8 (programator „USBASP”) a odpowiednimi nóżkami kontrolera (MISO, MOSI, SCK, RESET).
• Czy jest włączona zworka spowalniająca przebieg SCK, jeśli częstotliwość zegara programowanego mikrokontrolera jest mniejsza niż 1,5 MHz (programator USBASP).
• Czy nie ma zwarć lub przerw w obwodzie kwarcu (przy wyjętym kontrolerze!). Jeśli stosujemy rezonator.
• Czy budowany przez nas układ nie wymusza (przez dołączenie do masy lub do plusa zasilania poprzez element o małej rezystancji) stanów na nóżkach MISO, MOSI, SCK, RESET. Jeżeli tak, to na czas programowania należy odłączyć „podejrzane” elementy.
• Czy tasiemka od programatora do kontrolera nie jest zbyt długa.

Jeśli wszystko sprawdziłeś i uważasz, że to nie jest żaden z powodów wymienionych wyżej, a dalej nie działa, to sprawdź jeszcze raz albo dwa, programator i jego podłączenie.