HC-05 Arduino - stabilne połączenie Bluetooth krok po kroku

Połączenie Arduino z modułem HC-05 przez Bluetooth to jeden z najprostszych sposobów na bezprzewodową komunikację szeregową w małym projekcie. W praktyce liczą się trzy rzeczy: poprawne okablowanie, zgodna prędkość transmisji i sensowny wybór portu, bo wtedy moduł działa jak kabel bez kabla, a nie jak źródło losowych błędów. Poniżej pokazuję, jak spiąć to stabilnie, jak skonfigurować szkic i jak od razu wyłapać najczęstsze pułapki.

Jak działa komunikacja przez HC-05

HC-05 nie jest „uniwersalnym Bluetooth do wszystkiego”. To klasyczny moduł Bluetooth, który najczęściej pracuje jako interfejs szeregowy SPP, czyli zachowuje się podobnie do kabla UART, tylko bez przewodu. Jeśli potrzebujesz prostego sterowania, wysyłania komend, logów albo krótkich ramek tekstowych, to bardzo wygodne rozwiązanie. Jeśli planujesz bardziej nowoczesną komunikację mobilną, niskie zużycie energii albo współpracę z aplikacjami opartymi na BLE, to jest już inna kategoria sprzętu.

Tak właśnie patrzę na ten moduł w praktyce: nie jako na zamiennik każdej odmiany Bluetooth, tylko jako na prosty most między Arduino a terminalem, telefonem albo drugim mikrokontrolerem. Kiedy ten model myślenia się zgadza, łatwiej przejść do przewodów bez zgadywania.

Jak podłączyć przewody do Arduino bezpiecznie

Najczęściej zaczynam od prostego układu: zasilanie z 5 V na płytce breakout, wspólna masa i komunikacja szeregowa na dwóch pinach cyfrowych. Na Arduino Uno wygodnie jest użyć SoftwareSerial, bo sprzętowy UART zostaje wolny dla USB i monitora portu szeregowego. Najważniejsza zasada brzmi: nie podawaj 5 V bezpośrednio na wejście RX modułu, jeśli masz goły HC-05 albo płytkę bez ochrony poziomów logicznych.

Jeśli masz popularny breakout z wbudowanym stabilizatorem, zasilanie 5 V zwykle działa poprawnie, ale linia RX nadal wymaga ostrożności. W tańszych klonach różni się też wyprowadzenie przycisku, KEY albo napisu na płytce, więc przed podłączeniem dobrze jest spojrzeć na konkretny model. Gdy przewody są już pewne, można dopiero przejść do szkicu i obsługi portu.

Jak napisać pierwszy szkic do testu komunikacji

W kodzie trzy rzeczy muszą się zgadzać: piny, prędkość i kierunek danych. W konstruktorze SoftwareSerial najpierw podajesz pin odbioru Arduino, a dopiero potem nadawania, i to właśnie tam początkujący najczęściej się mylą. Ja zaczynam od prostego mostka: wszystko, co przychodzi z telefonu, ląduje w Serial, a wszystko z monitora portu wraca do modułu.

#include 

SoftwareSerial bt(10, 11); // RX, TX

void setup() {
  Serial.begin(9600);
  bt.begin(9600);
  Serial.println("Start");
}

void loop() {
  if (bt.available()) {
    Serial.write(bt.read());
  }

  if (Serial.available()) {
    bt.write(Serial.read());
  }
}

To wystarcza do pierwszego testu i od razu pokazuje, czy komunikacja działa w obie strony. Na Uno i Nano taki układ jest zwykle najpraktyczniejszy, a na Mega 2560 lepiej użyć Serial1, bo wtedy nie musisz dokładać programowego UART-u i mniej obciążasz procesor. Przy projektach, które mają jeszcze obsługiwać czujniki, przekaźniki albo silniki, to naprawdę robi różnicę.

Gdy ten test przechodzi, masz już potwierdzenie, że problem nie leży w samym module ani w kodzie do odczytu znaków. Następny krok to uporządkowanie ustawień w trybie AT, bo właśnie tam zmienia się parametry, które później decydują o wygodzie pracy.

Kiedy użyć trybu AT i jakie parametry ustawić

Tryb AT przydaje się wtedy, gdy chcesz zmienić nazwę modułu, PIN, rolę master/slave albo prędkość połączenia. Na wielu płytkach KEY albo EN trzeba ustawić przed zasileniem modułu, a dopiero potem uruchomić komunikację z prędkością właściwą dla komend. Z mojego doświadczenia najwięcej nieporozumień bierze się z tego, że ktoś wysyła komendy do modułu, który nadal pracuje w trybie danych.

• AT - sprawdza, czy moduł odpowiada w trybie komend.
• AT+NAME=Robot - zmienia nazwę widoczną podczas parowania.
• AT+PSWD=1234 - ustawia PIN.
• AT+UART=9600,0,0 - ustawia prędkość trybu danych.
• AT+ROLE=0 / AT+ROLE=1 - przełącza rolę slave/master.

Nie traktuję tych komend jako absolutnego standardu dla każdego egzemplarza, bo klony HC-05 potrafią mieć różne firmware. Jeśli odpowiedź nie przychodzi, pierwsze podejrzenia kieruję na tryb pracy, zakończenie linii i baud rate 38400 b/s używany przez komendy na wielu modułach. Dopiero potem szukam problemu w samym szkicu. Jeżeli nadal coś nie działa, najwięcej mówią już same objawy, więc warto je rozdzielić zamiast zgadywać.

Najczęstsze objawy błędów i co one zwykle znaczą

W praktyce większość problemów da się zawęzić do trzech warstw: zasilania, poziomów logicznych i ustawień portu. Gdy to rozdzielisz, diagnostyka robi się zaskakująco krótka. Ja zwykle zaczynam od objawów, bo one szybciej prowadzą do przyczyny niż przypadkowe przekładanie przewodów.

Moduł paruje się, ale nic nie dochodzi

• Sprawdź, czy TX i RX nie są zamienione.
• Upewnij się, że bt.begin() ma tę samą wartość co moduł.
• Na Arduino Uno nie podłączaj HC-05 do pinów 0 i 1, jeśli używasz USB do testów.
• Sprawdź, czy masa Arduino i modułu jest wspólna.

W terminalu widzisz losowe znaki

• Zwykle winna jest różnica w baud rate.
• Kolejny podejrzany to zbyt wysokie napięcie na RX modułu.
• Na słabym zasilaniu potrafią pojawić się pojedyncze błędy ramek.
• Jeśli używasz dłuższych przewodów, skróć je i sprawdź połączenia jeszcze raz.

Przeczytaj również: Demodulator FM - Jak działa i dlaczego jest kluczowy?

Nie możesz wejść w tryb AT

• KEY lub EN musi być ustawione przed startem zasilania na wielu wersjach modułu.
• Sprawdź, czy monitor portu wysyła zakończenie linii \r\n.
• Upewnij się, że moduł nie jest już aktywnie połączony z innym urządzeniem.
• Na niektórych płytkach przydaje się prosty reset z pełnym odłączeniem zasilania.

Jeśli projekt zasila silniki, serwa albo przekaźniki, problemem bywa nie sam HC-05, tylko spadki napięcia na całej płytce. Wtedy moduł gubi łączność, a na pierwszy rzut oka wygląda to jak błąd kodu. Gdy te symptomy są już opanowane, warto ustawić projekt tak, aby dało się go później rozbudować bez przepisywania wszystkiego od zera.

Co ustawić od razu, żeby nie przepisywać projektu po pierwszych testach

Jeśli układ ma wyjść poza eksperyment na stole, zaplanuj od razu prosty format danych. Do sterowania pojedynczymi poleceniami wystarczy krótki znak albo słowo zakończone enterem; do odczytu czujników lepiej działa linia tekstowa z separatorem, na przykład CSV. Taki format jest banalny do debugowania i dobrze znosi rozwój projektu.

• Ustal jeden prosty protokół, zanim dołożysz kolejne funkcje.
• Testuj najpierw w terminalu szeregowym, dopiero potem w aplikacji własnej.
• Jeśli potrzebujesz tylko sterowania, trzymaj się krótkich komend, na przykład ON, OFF, LEFT, RIGHT.
• Jeśli chcesz przesyłać dane z czujników, dodaj separator i końcówkę linii, żeby łatwo je parsować.
• Przy większym projekcie od razu zaplanuj zasilanie osobno dla silników i dla logiki.

Najrozsądniejsza kolejność pracy jest zwykle taka: najpierw terminal szeregowy, potem własna aplikacja albo panel sterowania, a dopiero na końcu dopracowanie obudowy i okablowania. W praktyce oszczędza to najwięcej czasu, bo od początku wiesz, czy problem leży w radiu, protokole, czy w samym projekcie.