TLC5940 to układ scalony zawierający 16 wyjść PWM. Generator PWM układu ma rozdzielczość 12 bitów czyli 4096 stopni wypełnienia. Jedną z głównych zalet tego chipu jest możliwość podłączenia do jego wyjść bezpośrednio diod LED (bez rezystorów). Jego wyjścia mogą wytrzymać do 120 mA obciążenia.

Wyprowadzenia układu TLC5940

OUT0..OUT15 – 16 wyjść PWM generatorów układu. Wyjścia są typu “otwarty kolektor” czyli przewodzą albo stan niski, albo stan nieustalony. Wyjścia można obciążać maksymalnie od 5 do 120 mA. Prąd wyjść reguluje się za pomocą wyprowadzenia IREF i/lub specjalnych rejestrów “DC” układu.

VPRG – Wejście trybu programowania układu – podłączasz do GND w Arduino.
Stan niski to programowanie rejestrów wypełnienia PWM (GS), stan wysoki to programowanie rejestrów korekcji prądu wyjść (DC).

SIN – Wejście szeregowe  - podłączasz do pinu cyfrowego 11 w Arduino UNO

SCLK – Wejście szeregowe zegara zatwierdzającego bity danych – podłączasz do pinu cyfrowego 13 w Arduino UNO

XLAT – Wejście zatwierdzające wysłane dane – podłączasz do pinu cyfrowego 9 w Arduino UNO

BLANK – Wejście wyłączania wyjść i resetowania liczników generatora PWM – podłączasz do pinu cyfrowego 10 w Arduino UNO

GND – Wejście zasilania masa – podłączasz do GND w Arduino

VCC – Wejście zasilania +5 V – podłączasz do pinu zasilania 5V w Arduino

IREF – Wejście ustalania prądu na wyjściach OUT. Do wejścia podłączasz rezystor o oporze dostosowanym do prądu wyjścia, gdzie druga noga rezystora jest podłączona do GND.

Prąd wyjścia oblicza się ze wzoru:

Imax = (Vref / Rref) * 31,5 = (1.24 / Rref) * 31,5

Rref = Wartość oporu rezystora podłączonego między IREF i GND.

Przyjmując, że diody LED wymagają prądu 20 mA, to rezystor powinien mieć wartość 2 KOhm.

DCPRG – Wejście wybierania danych dokładnej regulacji prądu wyjścia – podłączasz do +5V

GSCLK – Wejście zegara, którego impulsy powodują zliczanie przez liczniki generatorów PWM układu – podłączasz do pinu cyfrowego 3 w Arduino UNO

SOUT – Szeregowe wyjście danych z układu. W konfiguracji wielu układów złączonych szeregowo to wyjście jest podłączone do SIN następnego układu.

XERR  - Wyjście błędów układu. Jeśli układ się przegrzeje, lub jakaś dioda LED podłączona do wyjść generatora PWM się przepali, na wyjściu pojawią się impulsy stanu niskiego. Wyjście jest typu “otwarty dren”, co powoduje, że ma albo stan niski, albo nieustalony.

Podłączenie układu TLC5940 do Arduino

Schemat przedstawia sposób podłączenia układu do Arduino. Połączenie zabiera 5 cyfrowych pinów Arduino. Do wyjść od OUT0 do OUT15 można podłączyć bezpośrednio diody LED, katodą do OUT, anodą do 5V (pod warunkiem zastosowania odpowiedniego rezystora IREF). W przykładzie podłączyłem diodę LED do wyjścia OUT1.

Podłączenie do Arduino MEGA

Ponieważ Arduino MEGA ma wyjście SPI w nieco innym miejscu, podłączenie do niego TLC5940 wymaga innego schematu elektrycznego.

Programowanie układu TLC5940

#include <Tlc5940.h>

void setup()
{
  Tlc.init();

  Tlc.set(1, 2048);

  while (Tlc.update());
}

void loop()
{
}

Społeczność Arduino napisała również dla układu TLC5940 odpowiednią bibliotekę. Przykład zapala diodę LED podłączoną do wyjścia OUT1 na połowę jasności.

Programowanie układu rozpoczyna się od załadowania odpowiedniej biblioteki poprzez “#include <Tlc5940.h>”. Następnie w funkcji “setup” biblioteka musi zostać zainicjowana za pomocą metody “Tlc.init();”. Metodę “Tlc.update()” umieściłem w pętli “while”. Metoda ta odpowiada za wysłanie danych do do układu i zaktualizowanie jego rejestrów. Trzeba wywoływać ja tak długo aż zwróci wartość 0. Jeśli nie jest to krytyczne, możesz umieścić też tą metodę w funkcji “loop”.

Za ustawianie poszczególnych wyjść PWM układu TLC5940 odpowiada metoda “Tlc.set”. Jej pierwszym parametrem jest numer wyjścia od 0 do 15, a drugim wartość wypełnienia generatora PWM od 0 do 4095.

Bibioteka wykorzystuje do swojej pracy układy Timer1 i Timer2 oraz SPI kontrolera Arduino, dlatego warto uważać, czy nie koliduje to z inną biblioteką w twoim projekcie.

Metody obiektu Tlc:

• Tlc.init() Uaktywnia działanie biblioteki i inicjuje komunikacje z układem TLC5940. Ma opcjonalny argument, który jest liczbą od 0 do 4095. Argument ustawia początkową wartość wypełnienia na wszystkich wyjściach układu. Wywołanie metody bez argumentu sprawia, że wyjścia ustawiają się na 0.
• Tlc.clear() Ustawia wszystkie wyjścia na wartość 0.

• Tlc.setAll(value) Ustawia wszystkie wyjścia na wartość wypełnienia podaną w argumencie (od 0 do 4095).

   

• Tlc.set(out, value) Ustawia wyjście określone w argumencie “out” (od 0 do 15) na wartość określoną w argumencie “value” (od 0 do 4095).
• Tlc.get(out) Zwraca wartość wypełnienia dla wyjścia podanego w argumencie “out” (od 0 do 15).
• Tlc.update() Wysyła dane do układu. Zwraca 0 jeśli dane zostaną zatwierdzone lub 1 jeśli jeszcze nie.

Wskaźnik diodowy

#include <Tlc5940.h>

void tlc_progress(word value, word prefix)
{
  byte out_num = value / 4096;
  word out_brg = value % 4096;

  for (byte out=0; out<16; out++)
  {
    if (out < out_num)
    {
      Tlc.set(out, prefix);
    }

    else if (out == out_num)
    {
      Tlc.set(out, out_brg);
    }

    else
    {
      Tlc.set(out, 0);
    }
  }
}

void setup()
{
  Tlc.init();
}

void loop()
{
  int value = analogRead(0);
  value = map(value, 0, 1023, 0, 65535);
  tlc_progress(value, 4095);
  Tlc.update();
}

Jako temat przykładu użycia biblioteki wykorzystałem pomysł na wskaźnik typu “linijka diodowa”. Zakłada on podłączenie do wszystkich pinów OUT układu TLC5940 diod LED. Działanie wskaźnika można opisać w ten sposób, że im program dostanie większe napięcie na pin Arduino Analog 0 tym więcej diod na kolejnych wyjściach się będzie świeciło. Przy napięciu 5V świecą się wszystkie diody. Dodatkową zaletą wykorzystania PWM jest to, że ostatnia zapalona dioda wskaźnika zapala się stopniowo wraz ze wzrostem napięcia na wejściu.

Najważniejszą funkcją programu jest “tlc_progress”. Steruje ona zapalaniem diod podłączonych do układu. Jej pierwszy arguement to wartość od 0 do 65535. Im większa liczba tym kolejne diody wskaźnika się płynnie zapalają. Kolejnym argumentem funkcji jest argument jasności świecenia lampek poprzedzających ostatnią zapaloną. Jeśli ustawisz mu wartość 0, to będzie paliła się na raz tylko jedna dioda – imitując wskazówkę.

Jeśli wstawisz tam wartość maksymalną, czyli 4095, to będą zapalały się kolejne diody aż do maksymalnej jasności.

W funkcji “loop” program odczytuje wartość z pinu Analog 0. Ponieważ funkcja “analogRead” odczytuje wartości z zakresu od 0 do 1023, to trzeba je przeskalować za pomocą funkcji “map” na wartości zakresu funkcji “tlc_progress”, czyli od 0 do 65535.

Wskaźnik diodowy ma zastosowanie tam, gdzie nie liczy się zbytnia dokładność, ale ważne jest szybkie zorientowanie się co do poziomu jakiegoś sygnału. Program możesz łatwo przerobić na fajny “analogowy” termometr, obrotomierz lub wskaźnik poziomu głośności w zestawie audio.

W nagraniu do wejścia analogowego 0 podłączyłem potencjometr.

Inne przykłady z biblioteki układu

Oprócz podstawowego nagłówka “Tlc5940.h”, biblioteka posiada jeszcze kilka ciekawych nagłówków z dodatkowymi funkcjami pomagającymi szybko rozwiązać pewne pomysły.

Fades

Pierwszym z nich jest “tlc_fades.h”, ułatwiający tworzenie płynnie zapalających się i gasnących efektów świetlnych.

#include <Tlc5940.h>
#include <tlc_fades.h>

void setup()
{
  Tlc.init();

  tlc_addFade(1, 0, 4095, 5000, 10000);
}

void loop()
{
  tlc_updateFades();
}

Użycie biblioteki rozpoczynasz od dodania nagłówka “#include <tlc_fades.h>”. Potem należy normalnie zainicjować układ w funkcji “setup”. W funkcji “loop” powinna być funkcja “tlc_updateFades();” odpowiedzialna za synchronizowanie działania całej biblioteki.

Za przygotowanie zapalania/gaśnięcia odpowiada funkcja “tlc_addFade”. Jej pierwszym argumentem jest numer wyjścia układu TLC5940 na którym ma się odbyć animacja. Kolejnym jest wartość początkowa jasności animacji (od 0 do 4095). Trzecim argumentem jest wartość końcowa jasności animacji o parametrach jak poprzednia.

Dwa ostatnie argumenty to czas w milisekundach liczony od chwili włączenia Arduino. Przedostatni mówi o tym w jakiej milisekundzie ma się rozpocząć animacja, a kolejny w jakiej ma się skończyć.

Funkcja w przykładzie tworzy animacje zapalenia się diody na wyjściu “OUT1” od wartości 0 do wartości 4095. Rozświetlenie ma się odbyć w czasie od 5 do 10 sekundy od chwili włączenia Arduino.

Można wykonać do 24 animacji na raz (wywołań funkcji “tlc_addFade”). Potem trzeba poczekać, aż któraś animacja się skończy. Pomocną przy tym funkcją jest “tlc_isFading”. Jej argumentem jest numer wyjścia, a zwraca 1 jeśli na danym wyjściu jest przewidziana jakaś animacja lub 0 jeśli nie jest.

Jest jeszcze funkcja “tlc_removeFades”. Jej argumentem jest numer wyjścia. Usuwa ona wszystkie animacje dla danego wyjścia.

#include <Tlc5940.h>
#include <tlc_fades.h>

void setup()
{
  Tlc.init();
}

void loop()
{
  if (!tlc_isFading(1))
  {
    unsigned long time = millis();
    tlc_addFade(1, 0, 4095, time+1000, time+1250);
    tlc_addFade(1, 4095, 0, time+1500, time+2000);
  }
  tlc_updateFades();
}

W tym przykładzie zrealizowałem animację mrugania diody LED na wyjściu OUT1. Warunek “if” sprawdza czy jest tam aktualnie animacja i jeśli nie ma to tworzy kolejną.

Animacja powstaje tak, że pobierany jest aktualny czas do zmiennej “time”. Sekundę po tym czasie rozpoczyna się rozświetlanie trwające 250 ms. Po 1.5 s zaczyna się gaśnięcie trwające 500 ms. Daje to ładny efekt płynnego mrugania.

Funkcja “tlc_updateFades” ma opcjonalny argument, którym są aktualne milisekundy. Jeśli nie odpowiada ci w animacji czas od chwili włączenia Arduino, możesz w argumencie dostarczyć swoją aktualną wartość czasu wyrażoną w milisekundach.

Shifts

Biblioteka “tlc_shifts.h” odpowiada za efekt przesuwania wartości wypełnienia z jednego wyjścia na kolejne.

#include <Tlc5940.h>
#include <tlc_shifts.h>

void setup()
{
  Tlc.init();
}

void loop()
{
  static byte counter = 0;
  if (counter % 4)
    tlc_shiftUp(0);

  else
    tlc_shiftUp(4095);

  counter++;
  Tlc.update();
  delay(100);
}

Przykład tworzy efekt “wąż świetlny”, który polega na złudzeniu, że światło w diodach ustawionych w linię pełza.

Funkcja “tlc_shiftUp” powoduje zapisanie do wyjścia OUT0 nowej wartości wypełnienia, podanej w argumencie, podczas gdy reszta wartości jest przesuwana do kolejnych wyjść (z OUT0 do OUT1, z OUT1 do OUT2 itp.). Ostatnia wartość, która była w rejestrze wypełnienia OUT15 jest zwracana przez tą funkcję (ułatwia to zapętlanie).

Jest też odwrotnie działająca funkcja o nazwie “tlc_shiftDown”, której argument zapisuje wartość wypełnienia do OUT15 i przesuwa wartości rejestrów w dół (z OUT15 do OUT14, z OUT14 do OUT13 itp.). Zwraca ona wartość rejestru OUT0 przed przesunięciem.

Dane z pamięci programu

Czasem zachodzi potrzeba przeniesienia na wyjścia PWM jakiś danych z pamięci. Kontroler AVR w Arduino ma kilka pamięci z których najbardziej pojemna jest pamięć Flash, gdzie przechowywany jest program. Pamięć RAM jest kilka razy mniej pojemna, dlatego najlepiej przechowuje się w niej aktualne zmienne, a nie tablice ze stałymi danymi. Dlatego autorzy biblioteki układu TLC5940 zadbali o możliwość współpracy z pamięcią programu.

#include <Tlc5940.h>
#include <tlc_progmem_utils.h>

byte pwm_data[24] PROGMEM = {
  GS_DUO(4095, 3839), GS_DUO(3583, 3327), GS_DUO(3071, 2815), GS_DUO(2559, 2303), 
  GS_DUO(2047, 1791), GS_DUO(1535, 1279), GS_DUO(1023, 767), GS_DUO(511, 255)
};

void setup()
{
  Tlc.init();

  tlc_setGSfromProgmem(pwm_data);

  while (Tlc.update());
}

void loop()
{
}

Biblioteka “tlc_progmem_utils.h” zawiera narzędzia do obsługi danych z pamięci programu.

Aby przygotować tablice wartości wypełnienia dla rejestrów PWM układu, trzeba ją zadeklarować w odpowiedni sposób. oprócz standardowego określenia typu “byte”, nazwy tablicy “pwm_data” i jej rozmiaru, trzeba jeszcze dodać odpowiednią dyrektywę informującą, że tablica ma być przechowywana w pamięci programu a nie w normalnej pamięci RAM. Ta dyrektywa to “PROGMEM”. Rozmiar tablicy określony jest przez ilość danych potrzebnych do zaprogramowania układu. Wynika on z tego, że układ potrzebuje szesnastu 12 bitowych wartości. W języku C nie ma typu, który by przechowywał dokładnie 12 bitowe wartości. Jest albo 16 bitowy “word”, albo 8 bitowy “byte”. Aby nie było niepotrzebnych strat danych biblioteka używa 8 bitowego “byte”. 24 elementy tablicy typu “byte” wynikają z tego, że 16×12 bitów /  8 (typ byte) = 24. Tablica jest poukładana od ostatniego rejestru GS OUT15 do pierwszego GS OUT0.

Aby było łatwiej układać dane, w bibliotece jest makro o nazwie GS_DUO, które ma dwa argumenty reprezentujące kolejne 2 wyjścia PWM (OUT15, OUT14 aż do OUT1, OUT0).

Wysłaniem danych z tablicy zajmuje się funkcja “tlc_setGSfromProgmem”. Jej argumentem jest nazwa tablicy z danymi do wyświetlenia.

Animacje z pamięci programu

Jeśli chciałbyś wysyłać do układu TLC5940 sekwencje danych np. w postaci animacji lub danych do wyświetlacza widmowego, możesz skorzystać z biblioteki “tlc_animations.h”, która działa podobnie do poprzedniej.

#include <Tlc5940.h>
#include <tlc_animations.h>

byte pwm_data[24*2] PROGMEM = {
  GS_DUO(4095, 0), GS_DUO(4095, 0), GS_DUO(4095, 0), GS_DUO(4095, 0), 
  GS_DUO(4095, 0), GS_DUO(4095, 0), GS_DUO(4095, 0), GS_DUO(4095, 0), 

  GS_DUO(0, 4095), GS_DUO(0, 4095), GS_DUO(0, 4095), GS_DUO(0, 4095), 
  GS_DUO(0, 4095), GS_DUO(0, 4095), GS_DUO(0, 4095), GS_DUO(0, 4095)
};

void setup()
{
  Tlc.init();
}

void loop()
{
  if (!tlc_onUpdateFinished)
  {
    tlc_playAnimation(pwm_data, 2, 500);
  }
}

Tym razem wielkość tablicy “pwm_data” musi być pomnożona o liczbę klatek animacji. W tym przykładzie stworzyłem 2 klatki animacji. Pierwsza klatka to maksymalne świecenie diod wyjść nieparzystych, a druga to maksymalne świecenie diod parzystych. Klatki rozdzieliłem pustą linia.

Za uruchomienie animacji odpowiada funkcja “tlc_playAnimation”. Jej pierwszy argument to tablica z danymi animacji, drugi to liczba klatek animacji, a ostatni to czas po jakim mają się wyświetlać kolejne klatki animacji. Czas jest wyrażony w cyklach licznika PWM, a jeden cykl trwa 1,024 ms. Zatem 500 oznacza, że klatki będą pojawiać się co około pół sekundy.

Ponieważ funkcja “tlc_playAnimation” nie zapętla animacji, dlatego po wyświetleniu ostatniej klatki animacji trzeba ją uruchamiać ponownie. Zmienna “tlc_onUpdateFinished” zwraca 0 jeśli animacja się skończyła i 1 jeśli wciąż trwa. Dlatego zastosowałem ją w “if” do zapętlania animacji.

Korekcja prądu wyjść układu TLC5940

Jeśli podłączasz do wyjść układu TLC5940 różnokolorowe diody LED, często ich światło nie jest jednakowo jasne. Można to ustawić tworząc skomplikowane wzory przeliczające wartość rejestru wypełnienia i ograniczając rozdzielczość kanałów PWM. Ten układ ma jednak dodatkowy sprzęt, który pomoże dokonać korekty jasność.

Rejestry DC (Dot Correct) odpowiadają za dokładniejszą regulację prądu na wyjściach PWM. Ich rozdzielczość jest 6 bitowa, czyli przyjmują wartości od 0 do 63. Dzielą one wartość maksymalnego prądu na wyjściu ustalanego przez rezystor na wejściu IREF.

Aby dobrać się do rejestrów DC należy dokonać drobnej zmiany w układzie elektrycznym i bibliotece programu.

Na schemacie dodałem kolejny przewód do cyfrowego pinu Arduino. Przewód prowadzi od wejścia VPRG (noga 27 układu TLC5940) do pinu cyfrowego 8 w Arduino. W Arduino MEGA należy podłączyć ten sygnał do cyfrowego pinu 50.

Potem w katalogu biblioteki układu znajdź plik “tlc_config.h”, który odpowiada za ustawianie parametrów biblioteki i znajdz w nim definicję “#define VPRG_ENABLED 0” i zmień na “#define VPRG_ENABLED 1”. Uaktywni to dodatkowe elementy biblioteki odpowiedzialne za rejestry DC.

#include <Tlc5940.h>
#include <tlc_progmem_utils.h>

byte DC_data[12] PROGMEM = {
  DC_QUARTET(3, 3, 3, 3), DC_QUARTET(3, 3, 3, 3), 
  DC_QUARTET(14, 14, 14, 14), DC_QUARTET(14, 14, 14, 14)
};

void setup()
{
  Tlc.init(4095);

  tlc_setDCfromProgmem(DC_data);

  while (Tlc.update());
}

void loop()
{
}

Rejestry najłatwiej obsługiwać za pomocą biblioteki “tlc_progmem_utils.h”.

Ustawianie rejestrów DC wygląda podobnie do opisywanej wcześniej funkcji ustawiania rejestrów wypełnienia z pamięci programu Flash. W tym przypadku potrzebna jest tablica w pamięci programu zawierająca 12 elementów typu “byte”. Do łatwego ustawiania poszczególnych rejestrów potrzebne są makra “DC_QUARTET”, które mają po 4 argumenty, reprezentujące poszczególne wyjścia w odwrotnej kolejności. Do ustawienia wszystkich rejestrów potrzeba czterech makr.

Za zapisanie danych z tablicy do układu TLC5940 odpowiada funkcja “tlc_setDCfromProgmem”, której jedynym argumentem jest nazwa tablicy z danymi rejestrów DC.

W przykładzie miałem do wyjść OUT0 – OUT7 podłączone diody zielone i do wyjść OUT8 – OUT15 diody czerwone. Diody czerwone były bardzo jaskrawe i dużo jaśniejsze od zielonych, dlatego dostały wartość 3, a diody zielone, mniej jaskrawe wartość 14.

Wszystko dlatego ma tak niskie wartości, aby nie raziło, a jednocześnie świeciło na tyle jasno by widzieć dokładnie które diody świecą.

Sterowanie serwomechanizmem

Jak dowidziałeś się z poprzedniego wpisu, kąt obrotu serwomechanizmu zależy od szerokości impulsu PWM. Do układu TLC5940 możesz też podłączyć 16 serwomechanizmów.

Wyjścia układu TLC 5940 są typu “otwarty kolektor” i przekazują tylko albo stan niski, albo nieustalony. Dlatego aby wysterować wejście sterujące sewomechanizmu, trzeba podłączyć rezystor PullUp. Rezystor ten wg. dokumentacji biblioteki powinien mieć od 2k do 5k Ohm.

#include <Tlc5940.h>

#define SERVO_MIN_WIDTH 177
#define SERVO_MAX_WIDTH 571

#include <tlc_servos.h>

void setup()
{
  tlc_initServos();
}

void loop()
{
  int value = analogRead(0);
  value = map(value, 0, 1023, 0, 180);

  tlc_setServo(1, value);
  Tlc.update();
}

Do używania serwomechanizmów przez układ służy specjalna biblioteka “tlc_servos.h”. Ponieważ biblioteka ma ustawione dość bezpieczne czasy minimalnego i maksymalnego impulsu serwomechanizmu, dlatego przed załadowaniem biblioteki trzeba zdefiniować własne ich czasy w makrach “SERVO_MIN_WIDTH” i “SERVO_MAX_WIDTH”. Wartości te są wyrażone w liczbie czasu wypełnienia w rejestrze PWM czyli od 0 do 4095. Pierwsza wartość wypełnienia jest przy serwie ustawionym na 0 stopni, a druga na 180 stopni. Czas wypełnienia dla 1000 mikrosekund to 204. Moje serwomechanizmy (HTX900) mają zakres od 870 do 2800 mikrosekund, dlatego dałem im wartości wypełnienia od 177 do 571. Wartości te można obliczyć ze wzoru:

GSvalue = czas_impulsu_us * 204 / 1000

W funkcji “setup” biblioteka wymaga wywołania funkcji “tlc_initServos();”, której opcjonalny argument to kąt obrotu serw podłączonych do wyjść.

Serwomechanizmy ustawia się za pomocą funkcji “tlc_setServo”, której pierwszym argumentem jest numer wyjścia, do którego podłączone jest serwo, a drugim kąt obrotu jego osi.

Na końcu należy oczywiście zatwierdzić wysłanie danych do układu za pomocą metody “Tlc.update();”

Dane do serwomechanizmu można też przekazywać za pomocą metody “Tlc.set”, pamiętając by nie przekraczać minimalnego i maksymalnego impulsu. Zanim poda się parametr wypełnienia dla tej metody, trzeba go odjąć od liczby 4095 (“Tlc.set(4095-imp_width);”).

Korzystając z biblioteki serwomechanizmów, do można do wyjść podłączyć też inne elementy, pamiętając o tym, że teraz generują impulsy z częstotliwością 50 Hz.

Program w przykładzie odczytuje wartość z wejścia analogowego i po przeskalowaniu ustawia oś serwomechanizmu proporcjonalnie do napięcia na wejściu.

UWAGA:

Biblioteka wymaga drobnej poprawki, gdyż wynik zakresu impulsu moich serwomechanizmów wywołał w niej błąd. W katalogu biblioteki w pliku “tlc_servos.h” funkcja “tlc_angleToVal” powinna wyglądać tak:

/** Converts and angle (0 - SERVO_MAX_ANGLE) to the inverted tlc channel value
    (4095 - 0). */
uint16_t tlc_angleToVal(uint8_t angle)
{
    return 4095 - SERVO_MIN_WIDTH - (
            ((uint32_t) (angle) * (uint16_t)(SERVO_MAX_WIDTH - SERVO_MIN_WIDTH))
            / SERVO_MAX_ANGLE);
}

Sterowanie silnikiem

Silnikiem elektrycznym steruje się jak w poprzednim wpisie za pomocą tranzystora MOSFET. Pamiętając oczywiście o zapewnieniu rezystora PullUp na wyjściu układu TLC5940.

#include <Tlc5940.h>

void setup()
{
  Tlc.init();
}

void loop()
{
  int value = analogRead(0);
  value = map(value, 0, 1023, 0, 4095);

  Tlc.set(1, value);
  Tlc.update();
}

Przykład nie różni się od poprzednich, nie wymaga specjalnej biblioteki. Steruje prędkością silnika w zależności od napięcia na analogowym wejściu 0 w Arduino, skalując wartość do poziomu zakresu wartości rejestru wypełnienia GS.

Łączenie wielu układów TLC5940

Aby zyskać kolejne wyjścia PWM należy podłączyć kolejny układ TLC5940. Nie trzeba do tego wykorzystywać żadnych dodatkowych pinów Arduino. Kolejne układy podłączamy tak samo jak ten pierwszy, przekazując kolejnym te same sygnały z jednym wyjątkiem. Sygnał SIN (noga 26) następnego układu łączysz z sygnałem SOUT (noga 17) poprzedniego. W ten sposób zyskujesz kolejne 16 wyjść PWM. Układów możesz tak łączyć dowolną ilość pamiętając, że przesadne ilości wymagają więcej modyfikacji w bibliotece sterującej.

Aby program mógł skorzystać z dodatkowych układów należy otworzyć plik z katalogu biblioteki o nazwie “tlc_config.h”. Jest w nim zdefiniowane makro “#define NUM_TLCS 1”. Liczba za nazwą odpowiada liczbie podłączonych układów TLC5940. W moim przypadku będzie to “#define NUM_TLCS 2”.

#include <Tlc5940.h>

void setup()
{
  Tlc.init();

  Tlc.set(1, 2048);
  Tlc.set(17, 2048);

  while (Tlc.update());
}

void loop()
{
}

W programie sterującym układami prawie nic się nie zmienia. Różnica polega tylko na tym, że kolejne wyjścia mają kolejne numery. Zatem czerwona dioda LED podłączona do OUT1 pierwszego układu ma numer 1, a zielona dioda LED podłączona do wyjścia OUT1 drugiego układu ma numer 17. Jest to bardzo proste rozwiązanie.

Podobnie jest z innymi elementami biblioteki układu. W każdej ilość wyjść zwiększa się o wielokrotność układów. Biblioteki korzystające z pamięci Flash muszą mieć powiększone tablice do ilości wyjść układów.

Zakończenie

TLC5940 to bardzo ciekawy układ scalony. Jego możliwości w połączeniu z Arduino są bardzo duże. Dzięki niemu możesz robić kroczące roboty, na których mięśnie składa się kilkanaście serwomechanizmów, lub zaskakujące efekty świetlne na przyszłoroczną choinkę. Zdecydowanie najciekawszym efektem jaki można zrobić przy pomocy tych układów jest wyświetlacz widmowy. Nie chciałem odbierać ci tej przygody i dlatego postaraj się zrealizować go sam :-). Tylko pamiętaj o solidnym przymocowaniu LED-ów najlepiej na płytce uniwersalnej.

Linki

• TLC5940NT do kupienia na Nettigo
• Biblioteka Tlc5940.h
• Opis biblioteki Tlc5940.h [en]

Wstęp

Wielu użytkowników Arduino zapewne zauważyło, że wśród pinów z grupy DIGITAL jest kilka oznaczonych jako “PWM” lub “~”. W tym artykule postaram się wyjaśnić co to znaczy i jak dokładnie działa. Napiszę też jak można to praktycznie wykorzystać.

PWM w teorii

PWM to skrót od angielskich słów “Pulse Width Modulation”, co oznacza po polsku “Modulacja Szerokości Impulsu”.

W życiu codziennym posługujesz się przełącznikami. One powodują, że włączasz jakieś urządzenie lub wyłączasz. Włączenie oznacza dostarczenie do urządzenia 100% energii elektrycznej, a wyłączenie zmniejsza tą ilość do 0%.

Jeśli masz w domu jakieś urządzenie z silnikiem to możesz zauważyć, że włączając i wyłączając je wiele razy w ciągu sekundy silnik nie zdąży się rozpędzić do maksymalnych obrotów. Wynika to z tego, że wolno się rozpędza. Zatem jeśli odetniesz mu prąd zanim osiągnie maksymalne obroty to będzie kręcił się wolniej i zwalniał do czasu, aż znowu go włączysz. W ten sposób można regulować jego prędkość.

Działanie PWM polega właśnie na tym, że im dłużej silnik jest włączony w ciągu sekundy, tym szybciej się kręci. A jeśli dłużej trwa czas wyłączenia tym wolniej. Czas włączenia to właśnie ten “Impuls” (“Pulse”) w nazwie, którego “Szerokość” (“Width”) regulujesz.

Fizycznie rzecz ujmując działanie PWM polega na dostarczeniu mniejszej ilości energii elektrycznej do urządzenia w przeciągu jakiegoś czasu. Czego skutkiem ubocznym są takie właśnie miłe efekty jak regulacja szybkości lub jasności.

Parametry PWM

W rzeczywistości urządzenia PWM są dużo szybsze. Te w Arduino działają z prędkością około 400 razy na sekundę, co pozwala regulować urządzenia mające dużo szybszy czas reakcji np. jasność żarówek lub diod LED.

Parametrów pracy PWM jest kilka. Najważniejsze z nich są 3.

• Szybkość działania: To częstotliwość w jakiej mieszczą się czasy włączenia i wyłączenia. 400 Hz oznacza, że PWM włącza i wyłącza coś 400 razy na sekundę. Od tego zależy płynność pracy urządzenia.

• Wypełnienie: Oznacza ile czasu na jeden okres włączenia/wyłączenia PWM jest w stanie wysokim. 50% oznacza, że pół czasu urządzenie jest włączone, a drugie pół wyłączone. 75% oznacza, że ¾ czasu urządzenie jest włączone.

• Czas impulsu: Jest parametrem pochodzącym od powyższych. Oznacza to ile czasu trwa impuls włączenia. Jeśli PWM pracuje z prędkością 400 Hz, to czas całej fali PWM (włączony/wyłączony) trwa 1/400 = 0,0025s. Jeśli wypełnienie zajmuje 25% to czas impulsu wynosi 0,0025 * 25% = 0,0025 * 0,25 = 0,000625 s czyli 625 mikrosekund.

PWM w praktyce

Działanie generatora PWM w urządzeniach cyfrowych polega na tym, że w rejestrze przechowującym jakąś liczbę trzymana jest wartość wypełnienia. Od wielkości tego rejestru zależy ile jest stopni wypełnienia. 8 bitowy rejestr może mieć 256 stopni wypełnienia, a 16 bitowy 65 tysięcy. Oznacza to z jaką dokładnością będzie można regulować długość impulsu.

1 / 256 * 100 = 0,39

Wynik ten podaje, że 8 bitowy rejestr PWM jest w stanie regulować wypełnienie z dokładnością 0,39%.

Oprócz rejestru w generatorze PWM jest też licznik. Licznik to urządzenie, które przechowuje liczbę i co jakiś czas dodaje do niej +1. Od szybkości dodawania tej wartości zależy szybkość z jaką pracuje PWM.

Ostatnim elementem generatora PWM jest układ, który porównuje wartość licznika z wartością rejestru wypełnienia. Jeśli te wartości są sobie równe to wyjście PWM zmienia się w stan niski czyli wyłącza urządzenie.

Po dojściu licznika do ostatniej wartości jaką może policzyć, stan wyjścia PWM zmieniany jest na wysoki – włączający urządzenie i licznik zaczyna liczyć od nowa.

Wykres działania generatora PWM dla wartości 10 w 8 bitowym rejestrze wypełnienia.

Wykres działania generatora PWM dla wartości 15 w 8 bitowym rejestrze wypełnienia.

Programowy PWM

Z pewnością mogłeś mi nie uwierzyć, że to jest takie proste ;-). Dlatego, aby ci to udowodnić napiszę program do Arduino, który będzie udawał działanie generatora PWM i regulował jasność wbudowanej w Arduino diody LED.

// numer pinu z wbudowaną diodą
#define LED_PIN 13

// Zmienna z wartością licznika
byte pwmCounter = 0;
// Zmienna z wartością rejestru wypełnienia
byte pwmValue = 10;

void setup()
{
  // Ustawienie pinu diody na wyjście
  pinMode(LED_PIN, OUTPUT);
  // Ustawienie pinu diody na stan niski
  digitalWrite(LED_PIN, LOW);
}

void loop()
{
  // Jeśli stan licznika się przekręci to ustaw pin w stan wysoki
  if (pwmCounter == 0)
  {
    digitalWrite(LED_PIN, HIGH);
  }

  // Jeśli stan licznika jest równy stanu rejestru to ustaw pin w stan niski
  if (pwmCounter == pwmValue)
  {
    digitalWrite(LED_PIN, LOW);
  }

  // Zwiększanie wartości licznika o 1
  pwmCounter++;
}

Działanie programu odpowiada temu co opisałem w zasadzie działania generatora PWM. Zmienna “pwmValue” reprezentuje rejestr regulujący szerokość impulsu czyli poziom wypełnienia. Wartość 10 odpowiada wypełnieniu 3,90%.

10 / 256 * 100 = 3,90

Zmienna “pwmCounter” to zmienna reprezentująca licznik generatora. Zarówno ta zmienna, jak i “pwmValue” są typu “byte”, zatem reprezentują wartości 8 bitowe, czyli mogą przechowywać liczby od 0 do 255. Jeśli licznik podczas dodawania przekroczy tą liczbę, to zaczyna liczyć od nowa od 0.

Cały mechanizm działania generatora PWM znajduje się w funkcji “loop”. W pierwszym warunku “if” sprawdzane jest czy licznik nie zaczął liczyć od nowa. Jeśli tak to wyjście PWM ustawiane jest w stan wysoki.

W drugim warunku “if” program sprawdza, czy wartość licznika jest równa wartości rejestru wypełnienia. Jeśli tak to zmienia stan wyjścia PWM na niski, który będzie utrzymany aż licznik zacznie liczyć od nowa czyli od 0.

Jeśli uruchomiłeś ten program to powinieneś zauważyć w Arduino, że wbudowana dioda świeci bardzo słabo. Zmieniając wartość zmiennej “pwmValue” możesz zmieniać jasność świecenia tej diody. Wartość 255 to maksymalne świecenie, a 0 to minimalne.

Takie rozwiązanie programowe jest proste, ale ma kilka wad. Pierwszą jest to, że dodając nowe elementy do programu powodujesz, że szybkość działania generatora spada, bo musi się on dzielić czasem procesora z innymi elementami programu. Inną wadą jest to, że wyjście takiego generatora może być niestabilne, przez to, że na działanie głównego programu mogą wpływać przerwania. Jednym z nich jest np. komunikacja Serial.

Sprzętowy PWM

Arduino UNO posiada w grupie pinów “DIGITAL” 6 wyjść PWM. Oznaczone są one na płytce przez napisy “PWM” lub znaczek “~”. Generowane przez te wyjścia sygnały PWM są tworzone sprzętowo przez wbudowane w procesor Arduino liczniki/timery. Oznacza to, że program procesora ani ich nie zwalania, ani nie wpływa na zakłócenia ich pracy. Domyślnie pracują one z prędkością 490 Hz i przyjmują wartości 8 bitowe.

Funkcja odpowiadająca za działanie tych pinów nosi nazwę “analogWrite”. Jej pierwszym argumentem jest numer pinu PWM, a drugim wartość wypełnienia od 0 do 255.

Aby ta funkcja zadziałała pin musi być najpierw ustawiony jako wyjście.

#define PWM_PIN 3

void setup()
{
  pinMode(PWM_PIN, OUTPUT);

  analogWrite(PWM_PIN, 10);
}

void loop()
{
}

Jak widzisz w funkcji “loop” nie trzeba już niczego zamieszczać. Sygnał generuje się automatycznie po wywołaniu “analogWrite”.

Co można podłączyć do PWM?

Niestety nie ma sprzętowego wyjścia PWM do pinu 13 wbudowanej diody LED. Zatem aby sprawdzić działanie wyjścia możesz podłączyć do niego inną diodę połączoną szeregowo z rezystorem 220 Ohm. Jej anodę podłączasz do wyjścia PWM, a katodę do GND.

Można też w ten sposób podłączyć 3-kolorową diodę LED ze wspólną katodą, tak by każde wyjście PWM sterowało osobnym kolorem, co da płynną możliwość dobierania kolorów.

Taka dioda LED składa się z 3 niezależnych diod w jednej obudowie. Barwy emitowane przez diody są podstawowymi barwami składowymi RGB – Czerwony, Zielony, Niebieski. Każda z tych barw podłączona jest do innego wyjścia PWM (pin 3 – zielony, pin 5 – niebieski, pin 6 – czerwony) przez rezystor 220 Ohm. Wspólna katoda diod podłączona jest do GND. Takie połączenie powinno dać teoretycznie 16 mln barw (256 poziomów na składową czyli 256^3 = 16777216).

Do wyjścia PWM możesz podłączyć też silnik elektryczny i regulować prędkość jego wału. Ponieważ silnik pobiera znacznie więcej prądu niż może wygenerować cyfrowe wyjście Arduino, zalecam zastosowanie tranzystora MOSFET typu N. Tranzystory te wytrzymują znaczne prądy obciążenia i duże napięcia (w moim przypadku do 12A i 60V – tranzystor o oznaczeniu D12N06 (typu N) ze starej drukarki).

Bramkę (Gate) tranzystora podłączyłem przez rezystor 1 KOhm do wyjścia PWM pin 3. Źródło (Source) tranzystora podłączyłem do GND. Natomiast Dren (Drain) połączyłem z silnikiem. Drugie wyprowadzenie silnika podłączyłem z jego zasilaniem. Do tego może służyć osobny zasilacz silnika lub pin Vin Arduino, jeśli silnik nie pobiera zbyt dużej mocy.

W przypadku silnika, nie każda wartość wypełnienia impulsu PWM może wpływać na jego działanie. W moim przypadku silnik zaczął się kręcić dopiero od wartości 60 (wypełnienie 23,5%).

Serwomechanizmy są elementami zależnymi od czasu trwania impulsu PWM. Szerokość impulsu decyduje o tym jak będzie ustawiony kąt osi serwomechanizmu. Moje serwomechanizmy (HTX900) przyjmują szerokości impulsów od 580 (0 stopni) do 2800 (180 stopni) mikrosekund. Do ich obsługi stosuje się raczej bibliotekę “Servo.h”, która dobrze spełnia swoje zadanie.

Wyjście PWM może sterować też głośnikiem lecz wymaga generatora PWM o częstotliwości pracy w zakresie ultradzwięków (powyżej 20000 Hz). Częstotliwości niższe są słyszalne dla ucha człowieka i powodują, że zamiast sygnału jaki chciałeś wygenerować, słyszysz pisk sygnału PWM. W tym artykule nie napiszę o sposobach generowania takiego sygnału, ale pojawiło się już wiele takich projektów w społeczności Arduino i można je wyszukać.

Sterowanie głośnikiem przez PWM pozwala na wytwarzanie przez głośnik fal o dowolnych kształtach i głośności, a nawet odtwarzanie sampli. Eksperymentatorzy będą mieli zapewne wiele zabawy.

Zakończenie

Mam nadzieję, że tym wpisem rozwiałem twoje wątpliwości dotyczące tego jak działają i do czego służą wyjścia PWM. Jeśli masz jeszcze jakieś pytania dotyczące PWM, możesz zamieścić je w komentarzach pod artykułem.

W nastepnym wpisie przedstawię jak można uzyskać 16 kanałów PWM o rozdzielczości 12 bitów (4096 poziomów wypełnienia).

Linki

• Opis funkcji “analogWrite” [EN]
• Opis działania PWM na Wikipedii [Paskudne akademickie teoretyzowanie ;-)]
• Opis biblioteki “Servo.h” [EN]

Jeśli spojrzycie na kod tamtego sygnalizatora, możecie dostrzec następującą pętlę loop:

void loop()
{
  val = digitalRead(buttonPin);
  if (val == HIGH && prev == LOW) {
    next_status();
  }
  prev = val;
  display_status();
  delay(50);

}

Wykrywanie naciśnięcia odbywa się przez porównanie bieżącej wartości wejścia cyfrowego z poprzednią. Jeżeli aktualna wartość to HIGH a poprzednia to LOW, to wykonujemy akcję next_status(), która zmienia stan sygnalizatora. I wszystko działa. Ale nie ma problemów, tylko dzięki ostatniej linii kodu w loop: delay(50);.

Przycisk jest urządzeniem mechanicznym i włączenie lub wyłączenie nie jest jednoznaczne, jeżeli będziemy stan przycisku badać dostatecznie często. W momencie dociskania/zwalniania przycisku jest taki moment, w którym styk już łapie/puszcza przez co włączenie wyłączenie nie jest czystym przełączeniem między LOW a HIGH tylko migotaniem. Angielska Wikipedia przy haśle contact bounce (bo tak się zjawisko to nazywa) ma ten piękny obrazek ilustrujący ten problem:

Ilustracja migotania przełącznika (CC Wikipedia)

Opóźnienie w loop załatwia nam ten problem, bowiem jeżeli zauważymy zmianę stanu klawisza odczekanie 50 ms przed następnym odczytem zapewnia margines wykluczający błędny odczyt. Gdyby nie ono, wówczas w następnym przebiegach moglibyśmy odczytać migotanie jako kolejne przyciśnięcia. Rezultat? Z punktu widzenia użytkownika – on nacisnął przycisk jeden raz, a sygnalizator przeskoczył o 1 lub więcej stanów za jednym razem.

Rozwiązanie z użyciem delay nie zawsze jest dopuszczalne, bo może nasze Arduino musi robić coś więcej niż tylko czekać na naciśnięcie klawisza.

Jak się zabezpieczyć przed złymi odczytami?

Najlepszą metodą jest zapamiętanie czasu w którym odczytaliśmy zmianę stanu klawisza i przez następne kilkanaście, kilkadziesiąt milisekund nie reagować na zmiany stanu wejścia. Ale wówczas kod znacznie się komplikuje, a taki jest znacznie bardziej podatny na błędy. Na szczęście jest gotowe rozwiązanie w postaci biblioteki Bounce.

Instalujemy bibliotekę w sketchbook/libraries i teraz możemy korzystać z dobrodziejstw klasy Bounce. Zamiast odczytywać wartość przez digitalRead i samemu starać się rozszyfrować co znaczy odczyt w zależności od poprzedniej wartości i czasu który upłynął od ostatniej zmiany, definiujemy obiekt w naszym szkicu:

int buttonPin = 4;
Bounce button(buttonPin,20);

Od teraz cyfrowe wejście nr 4 będzie obsługiwane przez Bounce, z 20-sto milisekundowym marginesem. W czasie 20 milisekund od wykrycia zmiany stanu wejścia jego następne zmiany będą ignorowane. Dopiero po upływie tego czasu obiekt może zmienić swój stan.

Pierwszym krokiem jest uaktualnienie stanu przycisku przez funkcję update(). To właśnie w tym momencie jest odczytywana wartość na wejściu:

  button.update();

update zwraca wartość true lub false – w zależności czy stan przycisku uległ zmianie czy jest taki jak poprzednio.

Po tej operacji możemy sprawdzić czy przycisk jest wciśnięty lub nie (read()) albo jeżeli interesuje nas tylko czy został właśnie wciśnięty lub zwolniony informacji dostarczy nam risingEdge() lub fallingEdge(). W wypadku sygnalizatora nas interesuje kiedy został wciśnięty klawisz:

  if (button.risingEdge()) {
    next_status();
  };

next_status zostanie wywołany tylko kiedy zostanie wykryta zmiana ze stanu LOW na HIGH. W następnym przebiegu, jeżeli przycisk jest nadal wciśnięty, risingEdge() już zwróci false.

Biblioteka ma sobie jeszcze kilka przydatnych funkcji, pozwalających określić jak długo już przycisk jest w aktualnym stanie, albo przydatnych do generowania wirtualnych ‘przyciśnięć’ (to drugie świetnie się sprawdza do powtarzania akcji gdy przycisk jest ciągle wciśnięty).

To jeszcze nie koniec o sygnalizatorze, bo on nadal istnieje. Oczywiście kartonowy v1 został zastąpiony przez v2 ze spienionego PCW, które jest świetnym materiałem do budowy prostych konstrukcji. Sygnalizator dorobił się dodatku w postaci zapory napędzanej przez serwomechanizm, co widać też w kodzie.

O tym jak korzystać z serwomechanizmów na przykładzie zapory i tego szkicu postaram się napisać już niedługo.

Cały kod sygnalizatora v2.

Teoria związana z przepływem prądów w układach RLC (R – rezystory, L – cewki, C – kondensatory) jest cała najeżona wzorami, których nie chcecie widzieć :) (a jeżeli ktoś musi się przekonać to np zobaczcie to i wrócicie zaraz tutaj :) ).

Teraz podam kilka uproszczeń, które wystarczą do zmierzenia się z użyciem rezystorów w kontekście Arduino.

Ważną cechą układów elektronicznych jest to, że jeżeli mamy jakieś napięcie w układzie (coś je wytwarza), to jeżeli obwód jest zamknięty (nie ma żadnej przerwy), napięcie to się odłoży na wszystkich elementach w taki sposób, że sumując napięcia na każdym elemencie z osobna otrzymamy napięcie z naszego źródła. Jest to zgodne z intuicyjnym rozumieniem – napięcie nie bierze się znikąd i nie może nigdzie znikać.

Druga ważna informacja, to prawo Ohma – mówiące że napięcie (U) na danym elemencie jest proporcjonalne do prądu (I) przez niego płynącego, a jaka jest to konkretnie wartość mówi nam właśnie rezystancja (R):

Prawo Ohma

Oczywiście dotyczy to elementów o charakterze rezystancyjnym – właśnie rezystorów, sprawa np z diodą jest inna.

Może podłączmy sobie dwa rezystory do baterii:

Prosty układ z dwoma rezystorami

Zgodnie z tym co właśnie napisaliśmy napięcia U₁ i U₂ zsumowane dadzą napięcie równe napięciu baterii. Jeżeli bateria daje 5V to napięcia U₁ i U₂ po dodaniu wyniosą 5V.

Ważne – jest to połączenie szeregowe, czyli mówiąc po ludzku – rezystory są łączone po kolei. W takim wypadku rezystancja całego układu dwóch rezystorów jest sumą ich rezystancji.

W teorii układów RLC jest kilka twierdzeń, które w wielkim uproszczeniu można zastąpić zdaniem, że z punktu widzenia baterii jest obojętne czy podłączymy jeden rezystor 10k czy 2 rezystory 5k połączone szeregowo – prąd płynący w takim układzie będzie taki sam.

Inaczej – dowolny układ rezystorów możemy zastąpić jednym o rezystancji będącej wypadkową rezystancji składowych przeliczonych w zależności od tego jak połączone są te rezystory (jak dotąd była mowa o połączeniu szeregowym, może być jeszcze równoległe i wszelkie kombinacje tych dwóch)

Kolejną intuicyjnie rozumianą rzeczą jest, że prąd płynący przez elementy w połączeniu szeregowym jest taki sam w każdym elemencie.

Przypomnijmy sobie prawo Ohma – jeżeli przyłożymy napięcie z baterii wówczas przez oba rezystory popłynie jednakowy prąd równy napięcie baterii/sumaryczna rezystancja. Skoro prąd jest taki sam w obu rezystorach to napięcie na każdym z nich będzie wynosić rezystancja tego jednego rezystora * prąd.

Na przykład weźmy układ dwóch rezystorów połączonych szeregowo o sumarycznej rezystancji 10 Ohm. Podłączmy je do baterii 20V – prąd płynący przez rezystory (wyliczony z prawa Ohma) to 2A – bo 20V/10Ohm = 2A. Teraz jeżeli są to dwa rezystory po 5 Ohm (suma rezystancji wynosi 10 Ohm), prąd nadal jest 2A. Napięcie na każdym z rezystorów to 5 Ohm * 2 A = 10V. W sumie – 20V, czyli wszystko się zgadza.

Jeżeli jednak weźmiemy rezystor o różnych wartościach – na przykład 1 Ohm i 9 Ohm (suma nadal 10 Ohm) to mamy na pierwszym 1 Ohm * 2A = 2V a na drugim – 9 Ohm * 2A = 18V. Suma napięć – nadal 20V, czyli tyle ile daje nasza bateria. Ale w tym wypadku rozkład napięć U₁ U₂ jest zupełnie inny. Powiedzmy że na naszym schemacie górny rezystor to 1 Ohm a dolny to 9 Ohm. Napięcie na górnym rezystorze to 2V, na dolnym 18V.

Mierząc napięcie między minusem baterii (tutaj jest to tak zwana masa) a punktem pomiędzy rezystorami otrzymamy 18V – 90% wartości napięcia baterii. 9 Ohm stanowi 90% sumarycznej rezystancji układu. Zmieniając proporcje rezystancji, w tym punkcie otrzymamy odpowiednio zmienione napięcie. Gdy dolny rezystor będzie stanowił 30% sumarycznej rezystancji obu rezystorów, napięcie w punkcie pomiędzy rezystorami będzie wynosiło 30% napięcia baterii. Widzicie zależność? Właśnie poznaliście zasadę działania dzielnika napięcia, bo tak taki układ rezystorów się nazywa.

W rzeczywistym zastosowaniu trzeba pamiętać o jednym – nie możemy pobierać (dużo) prądu z punktu pomiaru pomiędzy rezystorami. Bo powyższe rozumowanie zakładało, że przez oba rezystory płynie równy prąd, prawda? Czyli nadaje się to uzyskania jakiegoś napięcia odniesienia, ale nie bardzo aby uzyskać napięcie zasilające.

Do czego jeszcze może się nam przydać rezystor?

Kolejnym podstawowym zastosowaniem oporników (jak też są nazywane rezystory) jest ograniczanie (czy raczej wymuszanie) wartości prądu w gałęzi układu. Jeżeli wiemy jakie napięcie zostanie odłożone na oporniku to dobierając odpowiednią wartość rezystancji możemy określić jaki prąd będzie płynął w gałęzi. Jeżeli wiemy, że na rezystorze będzie napięcie 1.7V to jeżeli użyjemy rezystora 220 Ohm, prąd płynący w gałęzi będzie wynosił 1.7/220 = 7.73 mA. Wartość tę wyliczyliśmy dzięki przekształceniu prawa Ohma – zależność prądu od napięcia i rezystancji:

Inny zapis prawa Ohma

Ma to zastosowanie np przy podłączaniu diod LED, ale bardziej szczegółowo o tym wkrótce.

Gdy pojawiło się Arduino UNO, przez chwilę pojawiła się chęć przetestowania klawiaturowego firmware dla ATmega8u2 w ramach tego właśnie hacku, ale projekt nie wystartował. Co UNO zmieniało? Otóż z nowym firmware, podłączone do komputera widziane jest jako klawiatura więc odpada cała komplikacja z odczytem seriala i wysyłania komunikatów do gry. Po prostu Arduino może ‘wciskać klawisze’ przez port USB i całość wydaje się znacznie prostsza.

Ale gdy tylko zobaczyłem Gameduino wiedziałem że to jest to czego potrzebowałem. Ostatnie dni deszczowe były, tak więc – do dzieła!

Najpierw – jedno z dem dołączonych do biblioteki to Asteroids – lecisz statkiem przez pole asteroidów i strzelasz do nich. Proste. Rozpakować bibliotekę do sketchbook/libraries, uruchomić Arduino IDE, menu File/Examples/Gameduino/Demos/asteroids. Kompilacja, upload i mamy. Tyle, że nie mamy żadnego kontrolera do sterowania statkiem. Ja do pierwszych testów użyłem Nettigo Keypada, bo go pod ręką miałem.

Wystarczy zmienić kod w controller_sense i zamiast domyślnego kodu przeznaczonego dla game controllera od SparkFun użyć swojego. Ale to mało pasjonujące naciskać na klawisze, byle konsola to ma :)

Czas na Level 2

Podłączyć czujnik przyspieszenia i zrobić jakąś platformę, na której stojąc będzie się sterować statkiem. Przechył w lewo – obrót w lewo. Przechył w prawo – obrót w prawo. Przechył do przodu – lecimy. W tył – strzelamy. Taki Segway. No może bez tego strzelania :)

Pierwsza rzecz jak zrobić samą platformę? Miałem pod ręką kawałek panela podłogowego. Do niego przyklejona płytka stykowa 170 (dzięki swojej taśmie samoprzylepnej). Na niej czujnik przyspieszenia, kabelki zgodnie z opisem w dokumentacji czujnika i możemy ustalić położenie panela. Interesują nas dwie osie – X i Y, Z na razie nam niepotrzebne :)

Czujnik przyspieszenia na płytce stykowej

Pozostaje teraz rozwiązać konstrukcję modułu wychylnego. Musi to być coś co pozwoli naszemu panelowi kiwać się na wszystkie strony, jednocześnie nie za bardzo, tak aby gracz nie spadał z niego. Po wielu testach różnych materiałów i różnych rozwiązań mocowań konsultowanych z NASA nasze finalne rozwiązanie wygląda tak:

Źródło: NASA (just joking)

Jak widać wybór padł na starą poduszkę :) Panel położony na niej ma dość swobody aby poruszać się w dwóch osiach na tyle aby czujnik mógł odczytać położenie.

Hard za nami, teraz soft

Teraz trochę kodu, czyli w zasadzie jedyna zmiana w kodzie dema, to nowa funkcja controller_sense:

#define LR_NEUTRAL 330
#define UD_NEUTRAL 345

#define LR_DELTA 8
#define UD_DELTA 7
static byte controller_sense(uint16_t clock)
{
int rd,a1,a2;

rd = 0;
a1 = analogRead(3);
a2 = analogRead(4);

  if (a1 < LR_NEUTRAL - LR_DELTA){
//    Serial.println("Lewo");
    rd = rd | CONTROL_LEFT;
  }  
  else if (a1 > LR_NEUTRAL + LR_DELTA)
  {
    rd = rd | CONTROL_RIGHT;
//    Serial.println("Prawo");
  }
  if (a2 < UD_NEUTRAL - UD_DELTA){
    rd = rd | CONTROL_DOWN;
//    Serial.println("Jazda");
  }  
  else if (a2 > UD_NEUTRAL + UD_DELTA)
  {
    rd = rd | CONTROL_UP;
//    Serial.println("Ognia");
  }
  return rd;

Teraz kilka słów wyjaśnienia. LR_NEUTRAL to wartość jaka jest odczytywana w osi X w pozycji neutralnej. LR jest od Left Right, bo przechył w osi X w naszym ułożeniu czujnika oznacza przechył w lewo/prawo. LR_DELTA to jest margines o jaki może się w każdą stronę zmienić odczyt od pozycji neutralnej zanim zostanie uznany za wciśnięcie lewo lub prawo.

Podobnie jest z UD (od up i down). Oznaczenia te pochodzą od oznaczeń używanych w kodzie dema, nie od kierunku ruchu panela :)

rd jest na początku ustawiane na zero i jeżeli wychył od pozycji neutralnej jest dostatecznie duży odpowiednia wartość CONTROL_ jest ORowana. O co chodzi? Jeśli spojrzeć na definicję wartości CONTROL_ :

#define CONTROL_LEFT  1
#define CONTROL_RIGHT 2
#define CONTROL_UP    4
#define CONTROL_DOWN  8

są to kolejne potęgi 2. W zapisie binarnym odpowiada to kolejnym bitom. 1 to 0001, 2 to 0010, 4 to 0100, itd. Logiczne OR dwóch liczb (w C to symbol tzw pałki | ) zwraca wartość gdzie bity są ustawione na 1 wszędzie tam gdzie choć w jednej z liczb była jedynka. Na przykład:

• 0000 OR 0001 = 0001
• 0000 OR 0010 = 0010
• 0100 OR 0010 = 0110
• 0100 OR 0100 = 0100

W ten sposób wiedząc że 1 na ostatnim bicie to CONTROL_LEFT a 1 na pierwszym to CONTROL_DOWN, można w jednej liczbie całkowitej przekazać informację, że wciśnięte zostały dwa klawisze jednocześnie: 1001 czyli 9 dziesiętnie. Bardzo często stosowana metoda przekazywania stanu różnych rzeczy przez jedną liczbę całkowitą.

A jak potem łatwo można odczytać czy bit jest ustawiony? Ano z wykorzystaniem AND (znak &):

• 1001 AND 1000 = 1000
• 1001 AND 0100 = 0000
• 1001 AND 0010 = 0000
• 1001 AND 0001 = 0001

Teraz już chyba jest jasne w jaki sposób przez rd jest zwracana informacja o równocześnie naciśniętych przyciskach.

Co do naszego czujnika – wartości _NEUTRAL oraz _DELTA zostały dobrane eksperymentalnie – obserwując odczyty z czujnika, które na ten czas wysyłane były na Serial. Po ich ustaleniu komendy Serial.print zostały usunięte, bo zajmują cenne takty procesora ;)

Jak to wychodzi w praktyce można zobaczyć na tym krótkim filmiku (nie wiem jak go odwrócić, aparat było mi wygodniej trzymać w pionie):

Ze względu na dynamikę całości :) niezbędne jest osłonięcie czujnika aby zabezpieczyć przed przypadkowym zgnieceniem:

W obudowie

Raport Millera – czyli co można poprawić

Położenie neutralne zmienia się nieco (tzn odczyt z czujnika), w zależności od zasilania Arduino (np mój notebook zamiast 5V na USB ma 4.9, co przy niewielkich zmianach napięcia na wyjściu czujnika może mieć znaczenie – punkt odniesienia się zmienia to i odczyt zwracany przez analogRead się zmienia). Również z czasem czujnik może minimalnie zmienić odczyt. Wówczas zostaje ręczna zmiana wartości w kodzie, kompilacja i wgranie do Arduino.

Lepszym rozwiązaniem byłaby kalibracja – otóż specjalny tryb, zamiast grania wyświetli polecenie: Wychyl się w lewo. Potem odczytuje wartość z czujnika. Następnie Wychyl się w prawo i znowu. W ten sposób szkic jest sam w stanie wyznaczyć sobie wartości _NEUTRAL i _DELTA.

Druga uwaga – dynamika gry jest duża i chyba taki kontroler byłby lepszy dla jakiejś sportowej niż strzelanki. Ale to już lepiej byłoby jednak użyć klawiaturowego firmware i komputera, może innym razem…

System RFID w uproszczeniu składa się z dwóch elementów – czytnika i tokenów. Token to fizyczna rzecz, mająca w sobie trochę elektroniki. Każdy token ma swój unikalny numer. Gdy token zostanie zbliżony do drugiego elementu – czytnika, ten będzie w stanie odczytać ten numer.

Jakie ma to zalety? Po pierwsze – token nie musi mieć swojego zasilania (wbudowanej baterii). Może być mały, lekki i odporny na wodę. Po drugie – nie jest potrzebny fizyczny kontakt tokena i czytnika – wystarczy token zbliżyć na kilka, kilkanaście centymetrów aby go odczytać.

Na rynku dostępnych jest kilka standardów, jeden z pierwszych to standard działający na częstotliwości 125 kHz. Urządzenia i tokeny do niego są proste a co za tym idzie niedrogie.

Jak skorzystać z RFID?

Pokażę teraz jak wygląda odczytywanie tokenów. Zestaw RFID sprzedawany przez Nettigo składa się z czytnika oraz 5 tokenów – 2 kart oraz trzech breloczków. Przyjrzyjmy się jednemu.

Token RFID

Jest na nim numer. Ale to nie numer, który zostanie odczytany przez czytnik. Dlaczego? Gdyby numer nadrukowany na tokenie oraz ten ‘w środku’ były takie same, łatwo byłoby sklonować token, a tak aby poznać jego numer trzeba go odczytać – nie jest to jakiś duży problem, ale zawsze utrudnienie.

Teraz – jak go odczytać. Przyjrzyjmy się czytnikowi. Jak napisałem ma interfejs UART, czyli można go podłączyć do Arduino korzystając z portu szeregowego, lub do komputera za pomocą konwertera USB/Serial.

Czytnik ma trzy złącza: 2, 3, i 5 pinów. Złącze dwu-pinowe jest przeznaczone na antenę dołączoną do zestawu. Nie ma znaczenia jak ją podłączymy. Pozostałe dwa złącza pozwoli opisać to zdjęcie:

Wyprowadzenia czytnika RFID

Zaznaczyłem na czerwono piny nr 1 i tak złącze trzy-pinowe:

1. LED – podłączenie dla diody sygnalizującą pracę czytnika (świeci ciągle gaśnie na chwilę w momencie odczytania tokena)
2. +5V – wyprowadzone napięcie zasilania
3. GND – masa

Jak widać rola jego jest informacyjna – można podłączyć diodę, która będzie ludziom sygnalizować że został odczytany token.

Złącze 5-cio pinowe to jest to co nam jest potrzebne aby uzyskać informację od czytnika:

1. TX – czyli to co odczytuje czytnik
2. RX – dane wysyłane do czytnika (ten model nie jest konfigurowalny, więc nie ma pożytku z tego)
3. NC – nie używany
4. GND – masa
5. +5V – zasilanie

Zademonstruję podłączenie czytnika do komputera z wykorzystaniem konwertera USB/Serial – FTDI Friend. Podłączamy TX (pin 1) czytnika do RX na FTDI Friend, masę i zasilanie 5V – i gotowe:

Podłączenie czytnika RFID do FTDI Friend

Po wsadzeniu kabla USB do komputera i podpięciu monitora portu szeregowego (Hyperterminal na Windows, gtkterm lub minicom na Linuxie, lub monitor z Arduino IDE, parametry portu 9600,8,N,1) dostaniemy np taki ciąg:

0041DEF392FE

Najpierw – bajt o wartości 0×02 – symbol startu numeru karty, potem 5 bajtów zapisanych w ASCI w kodowaniu szesnastkowym (tutaj to 00-41-DE-F3-92), dwa znaki sumy kontrolnej (XOR 5 bajtów, tutaj to FE), bajt o wartości 0×03 – znak końca transmisji.

W dużym skrócie – to tyle. Podłączyć do Arduino można ‘tak samo’. Czyli podłączamy zasilanie i masę, oraz RX na Arduino (D0) z TX na czytniku i korzystając z Serial.read() można odczytywać dane.

Cały układ podłączony via FTDI Friend wygląda tak:

Caly uklad

Gdy Arduino często sprawdza stan klawisza takie migotanie może zostać odczytane jako wielokrotne naciśnięcia i zwolnienia danego przycisku, mimo że został naciśnięty tylko raz.

Jak temu zapobiegać?

Potrzebny jest tak zwany debouncing. Można po odczycie stanu klawisza poczekać chwilę używając delay. Proste i skuteczne.

Pseudokod realizujący to wygląda tak:

obecny_stan_klawisza = odczytaj_klawisz();
if (obecny_stan_klawisza != poprzedni_stan) {
  poprzedni_stan = obecny_stan_klawisza;
  zrob_cos_po_zmianie_stanu();
  delay(50);
}

Taki kod po wykryciu zmiany stanu klawisza zapisuje jego nową wartość , wykonuje co trzeba po naciśnięciu/zwolnieniu klawisza i czeka 50 milisekund, zanim podejmie dalsze wykonywanie programu. Jeżeli więcej nic specjalnie szkic nie ma do roboty to zapobiegnie to odczytaniu migotania w następnym przebiegu loop.

Takie rozwiązanie, choć proste ma jednak jedną niezaprzeczalną wadę – Arduino nic nie może innego robić w czasie gdy czeka korzystając z funkcji delay. Nie zawsze jest to dopuszczalne. Jeżeli nasz szkic robi coś co wymaga szybkiej pracy, lub ścisłych zależności czasowych (generowanie obrazu, programowe implementacje różnych protokołów) takie rozwiązanie jest wykluczone.

Co zostaje? Trzeba zignorować wszystkie zmiany stanu klawisza w krótkim czasie po zaobserwowaniu jego wciśnięcia. Zapamiętujemy czas wciśnięcia klawisza i jeżeli zmiany stanu następują w krótkim czasie po tym – są ignorowane. Znowu – pseudokod:

obecny_stan_klawisza = odczytaj_klawisz();
if (obecny_stan_klawisza != poprzedni_stan && millis() - czas_ostatniego_wcisniecia > timeout) {
  poprzedni_stan = obecny_stan_klawisza;
  czas_ostatniego_wcisniecia = millis()
  zrob_cos_po_zmianie_stanu();
}

Oczywiście, na starcie szkicu musimy ustawić wartość czas_ostatniego_wcisniecia i timeout – zostawione bez nadanej wartość mogą stwarzać problemy. Czas jaki trzeba czekać ignorując zmiany stanu zależy od przełącznika. W wypadku mikroprzełączników 50 ms wystarcza w zupełności.

Dla wejść cyfrowych są gotowe biblioteki do obsługi debouncingu np Bounce, jednak dla naszego keypada ona się nie nadaje.

Dlatego biblioteka do Nettigo Keypada ma od wersji 0.3 domyślnie debouncowane klawisze. Domyślnie timeout jest ustawiony na 50 ms. Można go odczytać/zmienić przez funkcje getDebounceDelay i setDebounceDelay.

Dla uproszczenia całego procesu, zakładamy, że każdy plik który ma zostać poddany obróbce jest nam znany. Tzn rejestrujemy każdy taki plik (URL) za pomocą addCommand.

Następnie jak to ma działać? Idea jest taka, że mamy swoje funkcje w kodzie szkicu i których wynik działania ma zostać wklejony w wybrane miejsca kodu HTML. Czyli chcemy mieć plik HTML z takim kawałkiem kodu:

<p>
Wynik odczytu czujnika 1: MAGIA1<br/>
Wynik odczytu czujnika 2: MAGIA2<br/>
</p>

Na skutek działania naszego parsera chcemy MAGIA1 i MAGIA2 mieć zastąpione przez wynik działania funkcji w szkicu.

Najlepiej zacząć od magii!

Czyli jak zapisać w HTMLu że ma nasz parser wsadzić w to miejsce inny tekst. Dla uproszczenia przyjmujemy następującą formułę: #{X} zostanie zastąpione przez wywołanie odpowiedniej funkcji. X to jest jednoliterowy mnemonik określający którą funkcję chcemy wywołać.

Funkcje muszą mieć określoną definicję i nie mogą przyjmować argumentów. Dlaczego? Przyjmowanie argumentów komplikuje parser i na tym etapie nie jest chyba potrzebne.

Wybraliśmy sposób zapisu w HTML. Teraz, jak nasza funkcja ma przekazać wynik działania? Otóż zakładamy że przykładowa funkcja ma mieć następującą definicję:

void timeReport(char *buf) { itoa(millis()/1000, buf, 10); };

Funkcja ma nie zwracać danych (void) a przyjmować wskaźnik na bufor tekstowy. W tym buforze ma umieścić wynik swojego działania, który następnie zostanie wstawiony w odpowiednie miejsce HTML. Funkcja sama musi pilnować, żeby nie przepełnić tego bufora. Jego rozmiar jest definiowany przez P4A_MAX_FUNCTION_RESPONSE_LENGTH.

Jak widać powyższa funkcja zwraca liczbę pełnych sekund które minęły od uruchomienia lub resetu Arduino.

Jak parsować plik? Dzięki prostemu znacznikowi naszej magii jest to względnie proste. Czytamy plik znak po znaku. Jeżeli natkniemy się na # wówczas czytamy następny znak i sprawdzamy czy jest to klamra { tworzące w sumie sekwencję otwierającą naszej magii. Póki nie natkniemy się na # znaki nas nieinteresujące wysyłamy do bufora, który zostanie w końcu wysłany do przeglądarki.

Jeżeli następny znak po # nie jest klamrą wysyłamy do przeglądarki oba znaki # i następny – w tym miejscu nie mamy nic do robienia, czekamy na następny #.

Gdy jednak drugi znak to była klamra, wówczas czytamy kolejny znak – jest to nasz mnemonik! Wywołujemy odpowiednią funkcję w zależności od mnemonika, wysyłamy wynik do przeglądarki.

Następnie czytamy plik aż do zamykającej klamry i skanujemy dalej plik szukając kolejnego #.

Pozostaje nam kwestia przypisania funkcji do mnemoników. Posłuży nam do tego

Tablica wskaźników do funkcji

Pomówimy teraz o trochę bardziej zaawansowanym temacie, czyli o wskaźnikach do funkcji. Otóż jak się dobrze zastanowić, funkcja po skompilowaniu jest adresem pod którym znajduje się kod ją realizujący oraz pewien kontrakt określający jak przekazywane są dane do funkcji i jak z niej są zwracane.

Jeżeli kontrakt jest taki sam w wypadku wielu funkcji (czyli lista typów argumentów oraz zwracana wartość), funkcje takie można zapisać w postaci samego wskaźnika i trzymać w tablicy. Wówczas możemy wywołać taką funkcję używając zapisanego wskaźnika, nie musimy znać jej nazwy w kodzie.

To właśnie nam posłuży jako mechanizm tłumaczący mnemoniki na wywoływane funkcje. Teraz wiemy czemu wszystkie nasze funkcje muszą mieć taki sam interfejs/kontrakt (jak ustaliliśmy będzie do void jeżeli chodzi o zwracane dane oraz char * jako argument) – dzięki temu możemy je trzymać w jednej tablicy, której indeks będzie literą. Ale po kolei:

void (*_fcts['z'-'a'])(char *);

Definiujemy tablicę wskaźników na funkcje. void z przodu określa typ zwracany przez funkcję, to co w nawiasie na końcu oznacza jakich argumentów spodziewa się funkcja. W środku znajduje się deklaracja tablicy. Jej rozmiar 'z'-'a' może wydawać się dziwny, ale w takim kontekście znaki przez kompilator traktowane są jako bajty. Czyli od kodu ‘z’ odejmujemy kod ‘a’ – różnica to liczba liter. Dzięki temu mamy tablicę mogącą pomieścić tyle wskaźników na funkcje ile jest małych liter w alfabecie łacińskim (lub raczej w standardzie ASCII).

Jeśli będziemy mieli jakiś kod litery wystarczy od niej odjąć kod litery a a dostaniemy indeks z tablicy. Zresztą zobaczmy:

				if (_fcts[c[0]-'a'] == NULL) {
					bufferedSend(server,"n/a");
					continue;
				} else {
					//Call function from table
					_fcts[ c[0]-'a'](buf);
					//Write response to client
					bufferedSend( server, buf );
				}

c[0] zawiera znak naszego mnemonika. Jeżeli tablica nie ma wartości (tzn ma wartość NULL) pod indeksem c[0] - 'a' wówczas w HTML jest wstawiane n/a – nasz sposób na sygnalizowanie złych mnemoników.

'a' w ASCII ma kod 97. Jeżeli nasz mnemonik to też 'a' 97-97 = 0, czyli pierwszy element tablicy. Jeżeli mnemonik to 'b' to 'b'-'a' = 98 – 97 = 1 czyli drugi element tablicy, itd. Przydałoby się sprawdzać czy mnemonik jest we właściwym zakresie, bo inaczej możemy próbować wywołać funkcję z losowym adresem (jeżeli indeks tablicy jest poza zakresem, wówczas pamięć RAM spoza tablicy zostanie odczytana i procesor spróbuje zinterpretować wartość spod tego adresu jako adres funkcji do wywołania – gwarantowane zawieszenie się programu).

W powyższym kodzie widać też, jak należy wywoływać funkcje w tablicy:

_fcts[ c[0]-'a'](buf);

Do analizy pliku wykorzystujemy zmienną status, dzięki której wiem w jakim stanie nasz parser się znajduje. Może to być:

• P4A_PARSE_REGULAR – stan w którym szukamy znaku #
• P4A_PARSE_HASH – stan w którym czekamy na klamrę otwierającą
• P4A_PARSE_COMMAND – stan w którym szukamy mnemonika

Dzięki tym stanom łatwiej kontrolować co robi nasz parser. W zależności od bieżącego stanu oraz kolejnego znaku można podejmować decyzje co dalej. Wysyłać dane do przeglądarki czy wywoływać funkcję na podstawie mnemonika.

Dla zainteresowanych całość funkcji parseP4A:

//Reads HTML file, parses looking for our macro and sends back to client
int parseP4A( char * filename, WebServer &server ) {
	//simple status
	short int STATUS = P4A_PARSE_REGULAR;
	char c[2];
	c[1] = 0;

	//buffer to hold response from functions - there is no boundary checking, so
	//function has to not overwrite data
  char buf[P4A_MAX_FUNCTION_RESPONSE_LENGTH];

  if (! file.open(&root, filename, O_READ)) {
		return -1;
  }
  while ((file.read(c,1) ) > 0) {
		if (STATUS == P4A_PARSE_REGULAR && c[0] == '#')
		{
			//hash was found we need to inspect next character
			STATUS = P4A_PARSE_HASH;
			continue;
		}

		if (STATUS == P4A_PARSE_HASH) {
			if (c[0] == '{') {
				//go to command mode
				STATUS = P4A_PARSE_COMMAND;
				continue;
			} else {
				//fallback to regular mode, but first send pending hash
				STATUS = P4A_PARSE_REGULAR;
				bufferedSend(server, "#");
			}

		}

		if (STATUS == P4A_PARSE_COMMAND) {
			if(c[0] == '}') {
				STATUS = P4A_PARSE_REGULAR;
				continue;
			};
		  if (c[0] >= 'a' && c[0] <='z') {
				//Command found
				if (_fcts[c[0]-'a'] == NULL) {
					bufferedSend(server,"n/a");
					continue;
				} else {
					//Call function from table
					_fcts[ c[0]-'a'](buf);
					//Write response to client
					bufferedSend( server, buf );
				}
			}

		}

		if (STATUS == P4A_PARSE_REGULAR)
			bufferedSend(server, c);
  }

  //force buffer flushing
  flushBuffer(server);
	file.close();
  return 0;
}

P4A czyli PHP for Arduino w akcji

Załóżmy, że chcemy zrobić ładny wirtualny barometr, ale pokazujący prawdziwe ciśnienie. Skorzystamy z BMP085 – jest to poręczny adapter (breakout board) czujnika ciśnienia i temperatury  produkowany przez SparkFun. Rezultat ma być następujący:

Wygląd wirtualnego barometru

Wskazówka ma pokazywać wartość odczytaną z czujnika, a symbol prognozowanej pogody ma się zmieniać w zależności od wartości ciśnienia.

Jak sobie poradzimy z tym, że jak pisaliśmy w poprzednim odcinku, serwer WWW na Arduino, nie jest najlepszym rozwiązaniem, gdy trzeba serwować wiele plików jednocześnie (obrazki!)? Ano, skoro całość i tak ma być dostępna z sieci, czemu nie udostępnić statycznych zasobów z serwera sieci? Na swoje potrzeby mam taki serwer i wszystkie potrzebne elementy graficzne są na nim umieszczone. Czyli tarcza barometru, obraz wskazówki i symbole pogody.

Na Arduino znajduje się sam plik HTML, na karcie SD. W szkicu umieszczamy funkcję wywołującą parser dla tego pliku:

void index(WebServer &server, WebServer::ConnectionType type, char *, bool){
  server.httpSuccess();
  if (!parseP4A("BARO.HTM", server)) {
		Serial.println("P4A: -1");
	}
};

parseP4A to funkcja, która parsuje podany plik i wysyła rezultat korzystając z obiektu serwera Webduino. Pozostaje zarejestrować naszą funkcję jako domyślną komendę:

webserver.setDefaultCommand(&index);

Sam HTML wykorzystuję JaveScript i obiekt canvas do narysowania samej tarczy. Robi to funkcja draw, która jako argument przyjmuje ciśnienie w hektopaskalach. Gdy strona jest gotowa do wyświetlenia (tzn załadowała się) przez atrybut onload wywołujemy funkcję draw, ciśnienie jest wstawiane przez nasze P4A:

<body onload="draw(#{p});"

Mnemonik p trzeba skojarzyć z właściwą funkcją. W szkicu, w setup ustawiamy funkcję dla p:

  _fcts['p'-'a'] = pressureReport;

A samo pressureReport ma wygląd:

void pressureReport(char *buf) {
	bmp085_read_temperature_and_pressure (&temperature, &pressure);
	itoa(pressure/100.0, buf, 10);
	Serial.print ("temp & press: ");
	Serial.print (temperature/10.0);
	Serial.print(" ");
	Serial.println (pressure/100.0);

};

Serial jest używany do sprawdzania czy wartości są jak się spodziewamy i nie ma wpływu na działanie barometru. bmp085_read_temperature_and_pressure to funkcja z kodu obsługi BMP085 zaczerpnięta z fińskiego bloga.

Całość kodu do ściągnięcia tutaj. Jest to szkic napędzający nasz serwer, plus plik HTML i grafiki. Tarcza barometru, grafika i kod HTML/JS autorstwa Sprae.

Instalacja

Ściągnąć, rozpakować w sketchbook. Zawartość podkatalogu html wrzucić w główny katalog na karcie SD, wsadzić ją w shielda. Szkic poprawić podając właściwy MAC i IP adres. Po otwarciu strony głównej powinniśmy zobaczyć barometr, o ile posiadamy BMP085 ;)

Kilka uwag na koniec

Kod jest wersją beta :) tzn – działa na tyle ile moje testy to potwierdzają, może być (i na pewno jest) kilka błędów o których nie mam pojęcia :)

Kod należałoby uporządkować – np funkcje związane z buforowanym wyjściem powinny zostać przeniesione do kodu Wbeduino. Planuję to zrobić i wszystkie zmiany jakie w Webduino zostały wprowadzone wysłać do developerów Webduino – może coś z tego znajdzie się bezpośrednio w bibliotece.

Jestem ciekaw waszych opinii. Czy coś takiego jak P4A ma w ogóle sens i może być przydatne?

Najpierw trochę historii. Ethernet Shield był początkowo kompatybilny z małym Arduino. Dlaczego nie z Mega? Otóż do komunikacji z układem W5100 będącym sercem shielda wykorzystywany jest protokół SPI – na cyfrowych wejściach nr 10, 11, 12 i 13. W Arduino Mega SPI jest na innych wejściach. Można to obejść wyginając nóżki shielda i podłączając je do właściwych wejść cyfrowych kabelkiem.

Ale to dotyczy starszych shieldów. Obecnie sprzedawane przez Nettigo Ethernet Shieldy są kompatybilne zarówno z małymi Arduino (UNO, Duemilanove) jaki i Mega (te z procesorami ATmega1280 i ATmega2560) . Po czym poznać takiego shielda? Jeżeli jest na nim gniazdo kart microSD – znaczy to, że to jest nowsza wersja.

Ethernet Shield z gniazdem kart microSD

Wspomniany już został W5100 – układ scalony koreańskiej firmy WIZnet, napędzający Ethernet Shielda. Różni się tym od wielu innych kontrolerów Ethernet, że stos TCP/IP jest zaimplementowany bezpośrednio w układzie scalonym.  Co to znaczy dla użytkownika? Że biblioteka, którą musisz wykorzystać aby komunikować się ze światem potrzebuje mniej pamięci RAM i zajmuje mniej pamięci flash w porównaniu z układami nie mającymi na sobie stosu TCP/IP.

Jak korzystać z Ethernet Shielda?

Jest wiele przykładów w sieci jak tworzyć strony WWW wyświetlające dane z Arduino. Jednak, jeżeli masz już większe  doświadczenie z programowaniem Arduino to pewnie wiesz, że wszystkie łańcuchy znakowe, nawet te zdefiniowane w kodzie zajmują RAM, którego w ATmedze zawsze mało.

Weźmy oficjalny przykład z Arduino Tutoriala. Kod:

 client.println("HTTP/1.1 200 OK");
 client.println("Content-Type: text/html");
 client.println();

Zajmie nam 40 bajtów RAMu (15 znaków w HTTP… + kończące zero i 23 w Conte… + kończące zero). Łatwo sobie wyobrazić co to znaczy gdy mamy 2kB do dyspozycji w ogóle. Strona HTML nie może być zbyt rozbudowana.

Istnieje pewne rozwiązanie, które może nam pomóc – czyli przechowywanie stringów w pamięci Flash. Pozwala to zmniejszyć użycie pamięci RAM, ale często kosztem dodatkowego kodu. Dostęp do stringów tak definiowanych wymaga użycia specjalnego makra i kompilator nie pozwoli nam korzystać z tego makra w wywołaniu funkcji oczekującej char * jako argumentu. Na dodatek – każda zmiana w kodzie HTML, który chcemy wysłać oznacza, że trzeba zmodyfikować szkic i wgrać go w Arduino.

Zaraz, przecież Ethernet Shield od dwóch wydań ma na sobie gniazda na karty microSD – nie można jakoś wykorzystać przestrzeni jaką dają karty SD? Można, ale trzeba się trochę postarać.

Najpierw – Ethernet Shield musi zostać skonfigurowany do pracy w sieci – oznacza to ustawienie adresu MAC oraz IP. Można to zrobić tak:

byte mac[] = { 0xDE, 0xAD, 0xBE, 0xEF, 0xFE, 0xED };
byte ip[] = { 192,168,1, 177 };

Ethernet.begin(mac, ip);

Adres MAC najlepiej, zamiast wymyślać samemu odczytać z naklejki jaka znajduje się na spodzie shielda. Adres IP zależy od konfiguracji sieci. Powyższa sekwencja Ethernet.begin będzie działać tylko w sieci lokalnej – tzn gdy wszystkie adresy IP znajdują się w jednej podsieci. Jeżeli shield ma się łączyć z hostami w innych sieciach (zarówno jako klient lub gdy ma służyć jako serwer) musicie podać jeszcze jeden argument – tablice z 4 liczbami – adres IP domyślnej bramki (default gateway). Więcej w opisie biblioteki Ethernet.

Większość klocków mamy prawie gotowych. Biblioteka Ethernet, wchodząca w skład Arduino IDE, nie jest tym co nam najbardziej będzie pasować. Ułatwia ona tworzenie m.in. serwera TCP, ale do serwera HTTP jeszcze trzeba kawałek. Dlatego przyda się nam Webduino – na bazie biblioteki Ethernet, ktoś za nas wykonał spory kawałek pracy budując serwer HTTP.

Normalnie ściągnęlibyśmy ze strony Downloads bibliotekę i rozpakowalibyśmy w sketchbook/libraries. Na nasze potrzeby będziemy modyfikować trochę Webduino,  będzie do ściągnięcia na końcu tego mini-tutoriala, więc na razie nic nie trzeba instalować.

Webduino – jak zaczać?

Na początek musimy wiedzieć, że za pomocą

void addCommand(const char *verb, Command *cmd);

możemy zarejestrować dowolną funkcję wywoływaną gdy URL będzie pasował do verb. Przykład:

webserver.addCommand("blob.htm", &blob);

Jeżeli URL będzie się zaczynał (tzn porcja po adresie Arduino) od blob.htm, wówczas wywołana zostanie funkcja blob, która musi przyjmować argumenty zgodnie ze zdefiniowanym typem Command:

typedef void Command(WebServer &server, ConnectionType type,

                       char *url_tail, bool tail_complete);

server to obiekt WebServer, dla którego nastąpiło wywołanie metody, type to rodzaj połaczenia (INVALID, GET, HEAD, POST), url_tail to jest to co zostało w URLu po dopasowanym blob.htm. Jeżeli URL został obcięty ze względu na niewielki bufor używany przez Webduino (ehh ta pamięć), to ostatni parametr tail_complete bedzie miał wartość false.

OK, ale to mało wygodne musieć rejestrować każdą funkcję, zwłaszcza, że chcemy serwować dane z karty SD, której zawartości nie znamy. Przyda się nam teraz setFailureCommand, która pozwoli zarejestrować funkcję w naszym kodzie wywoływaną, gdy nie nastąpiło żadne inne dopasowanie do zarejestrowanych funkcji przez addCommand.

Czyli jeżeli URL nie pasuje do żadnej zgłoszonej wcześniej funkcji, wówczas zostanie wywołana funkcja podana do setFailureCommand.

Teraz wystarczy w niej sprawdzić czy url_tail jest nazwą pliku na karcie SD (ponieważ nie nastąpiło żadne dopasowanie, url_tail zawiera pełny URL włącznie z pierwszym znakiem / za adresem Arduino). Gdy pliku nie ma – wyświetlamy HTTP 404, jeżeli jest – wystarczy go wysłać do klienta.

Jak odczytać plik z karty SD?

Podobnie jak z serwerem HTTP nie musimy robić wszystkiego sami. Dobrą pomocą do stworzenia tego szkicu był tutorial przygotowany przez Limor Fried czyli – LadyAda. Korzysta on z biblioteki SdFatLib, która ma wsparcie dla systemów plików FAT16 i FAT32 (czyli tego co zwykle na kartach SD i SDHC jest).

Kod inicjalizacji i obsługi plików w zasadzie został wzięty z tego tutoriala. Omówię tutaj funkcję fetchSD, która została zarejestrowana przez setFailureCommand. Jej zadaniem jest znaleźć plik na karcie i wysłać go do przeglądarki:

P(CT_PNG) = "image/png\n";
P(CT_JPG) = "image/jpeg\n";
P(CT_HTML) = "text/html\n";
P(CT_CSS) = "text/css\n";
P(CT_PLAIN) = "text/plain\n";
P(CT) = "Content-type: ";
P(OK) = "HTTP/1.0 200 OK\n";
void fetchSD(WebServer &server, WebServer::ConnectionType type, char *urltail, bool){
	char buf[32];
	int16_t  readed;

	++urltail;
	char *dot_index; //Where dot is located
	if (! file.open(&root, urltail, O_READ)) {
		//Real 404
		webserver.httpNotFound();
  } else {
	if (dot_index = strstr(urltail, ".")) {
		++dot_index;
		server.printP(OK);
		server.printP(CT);
		if (!strcmp(dot_index, "htm")) {
				server.printP(CT_HTML);

		} else if (!strcmp(dot_index, "css")) {
				server.printP(CT_CSS);

		} else if (!strcmp(dot_index, "jpg")) {
				server.printP(CT_JPG);

		} else {
				server.printP(CT_PLAIN);
		}
		server.print(CRLF);
	}
	readed = file.read(buf,30);
	while( readed > 0) {
		buf[readed] = 0;
		bufferedSend(server,buf,readed);
		readed = file.read(buf,30);
	}
	flushBuffer(server);
	file.close();
	}
}

Na samym początku mamy zarejestrowanych kilka stałych znakowych przechowywanych w pamięci flash.

P(CT_PNG) = "image/png\n";

Makro P jest częścią Webduino, które służy do zapisywania stringów na pamięci flash a nie w RAM. A stałe te to są nazwy różnych formatów danych, tzw MIME Type, jakie chcemy obsługiwać. O co chodzi? Przeglądarka nie wie jakie dane zostaną wysłane przez serwer. Czy to będzie HTML czy obrazek dowiaduje się ona właśnie z nagłówka Content-Type, o którym za chwilę.

Następnie ‘pozbywamy’ się wiodącego ukośnika: ++urltail;, potem próbujemy otworzyć plik na karcie SD – jeżeli nie udaje się – to wyświetlamy błąd HTTP 404 (Not Found):

	if (! file.open(&root, urltail, O_READ)) {
		//Real 404
		webserver.httpNotFound();
  } else {

jeżeli się udało otworzyć plik, to w else spróbujemy go odczytać i wysłać do klienta.

Teraz kilka uwag. Po pierwsze – SdFatLib obsługuje tylko krótkie nazwy w formacie 8.3. Jeżeli spróbujesz użyć dłuższych nazw (które FAT32 dopuszcza) to pamiętaj, że nazwa widziana przez SdFatLib będzie inna od tej, którą zobaczysz po podmonotwaniu karty w twoim komputerze. I jeżeli zrobisz plik index.html (cztery znaki w rozszerzeniu), wówczas nazwa będzie dla SdFatLib ind~1.htm. Cóż, nawet jeżeli teraz w komputerze zmienisz nazwę na index.htm, wpis w katalog będzie w rozszerzonej formie. Musisz skasować plik i utworzyć go na nowo z nazwą w formacie 8.3.

Druga uwaga jest taka – z oczywistych względów (FISI :) ) nie będziemy się przejmować katalogami i zakładamy że wszystkie pliki są w głównym katalogu. Może w późniejszych wersjach kodu dodam obsługę trochę bardziej skomplikowanych struktur.

OK, wracamy do kodu fetchSD. Skoro udało się nam otworzyć plik, to szukamy kropki w nazwie pliku i jeżeli ją znajdziemy to sprawdzamy czy pozostała część (w domyśle – rozszerzenie) będzie pasować do znanych nam rozszerzeń. Bo nie wystarczy nam wysłać danych do klienta HTTP – musimy wysłać nagłówek z informacją o właściwym Content-Type (mówiliśmy o tym już wcześniej), inaczej dane mogą zostać błędnie zinterpretowane przez przeglądarkę.

Słowo o tym jak wygląda odpowiedź serwera WWW. Podzielona ona jest na dwie części. Pierwsza to tak zwane nagłówki. Przeglądarka jako nagłówek traktuje wszystko to co na początku, aż natrafi na pustą linię tekstu (linie są oddzielane znakami CR LF). Reszta to właściwa odpowiedź. Jak co ona zostanie zinterpretowana, będzie zależało od nagłówków. Serwer może pomóc przeglądarce przez ustawienie nagłówka określającego typ danych:

Content-type: text/html

Do pierwszego dwukropka jest nazwa nagłówka (tutaj Content-Type) potem wartość nagłówka. Tutaj używane są tak zwane typy MIME. I tak może to być np image/png dla obrazka PNG, image/jpg dla JPG czy text/html dla pliku HTML.

Obowiązkowym nagłówkiem jest status – czyli czy żądanie klienta zostało obsłużone, czy wystąpił błąd a może przekierowanie. HTTP/1.0 200 OK znaczy – jest dobrze, będzie żądna treść. Najpierw jest protokół i jego wersja (HTTP w wersji 1.0) a następnie sam kod 200 – w świecie HTTP znaczy to że jest dobrze. Inne częste kody to 404 – nie znaleziono zasobu (sławne Not Found), 301 i 302 – przekierowania.

Wiedząc to, staramy się rozpoznać rozszerzenie pliku i wysłać odpowiedni nagłówek:

	if (dot_index = strstr(urltail, ".")) {
		++dot_index;
		server.printP(OK);
		server.printP(CT);
		if (!strcmp(dot_index, "htm")) {
				server.printP(CT_HTML);

		} else if (!strcmp(dot_index, "css")) {
				server.printP(CT_CSS);

		} else if (!strcmp(dot_index, "jpg")) {
				server.printP(CT_JPG);

		} else {
				server.printP(CT_PLAIN);
		}
		server.print(CRLF);

Funkcje z dużym P na końcu oczekują nie char * ale const prog_uchar *.

Mamy już wysłany nagłówek HTTP (zakończony pustą linią server.print(CRLF)), więc wyślemy same dane:

	readed = file.read(buf,30);
	while( readed > 0) {
		buf[readed] = 0;
		bufferedSend(server,buf,readed);
		readed = file.read(buf,30);
	}
	flushBuffer(server);
	file.close();

Czytamy po 30 bajtów, wysyłamy do klienta przez funkcję buforującą wysyłane dane. Po co? Otóż jeżeli użyjemy najprostszego rozwiązania i będziemy wysyłać dane znak po znaku, wówczas każdy znak będzie w odrębnym pakiecie TCP. Bardzo (naprawdę, uwierz, naprawdę) nieefektywne rozwiązanie. Po prostu server.write wysyła od razu dane.

Dlatego napisałem funkcję bufferedSend, która jako argumenty bierze obiekt serwera WWW, wskaźnik na bufor z danymi i rozmiar bufora. Czemu nie korzystamy z funkcji określających rozmiar bufora znakowego takich jak strlen? Bo działać to może tylko gdy dane są tekstowe. Jeżeli dane są binarne (obrazki) to znacznik końca łańcucha może pojawić się w legalnym strumieniu danych.

W C i C++ znakiem końca łańcucha jest znak 0 (nie cyfra, tylko bajt o wartości 0). Jeżeli w naszym strumieniu danych mogą pojawić się zera, wszystkie funkcje związane z łańcuchami znakowymi, a oferowane przez standardową bibliotekę nie przydadzą się nam

Z tego powodu musimy wprost określić ilość danych wysyłanych do bufora.

I w zasadzie to tyle. Mamy na Arduino serwer WWW wysyłający dane z karty SD.

Czy to ma sens?

Wystarczy kilka testów z bardziej złożoną stroną WWW (nie jeden plik HTML ale do tego jakieś CSS i obrazki), żeby przekonać się, że rozwiązanie to ma swoje ograniczenia. Arduino jest jednowątkowe, więc każdy element z naszego serwera WWW jest ściągany po kolei. Oznacza to, że z punktu widzenia użytkownika strona się wolno ładuje.

Więc po co to? Arduino może prezentować dane zbierane z czujników w przyjaźniejszej formie jeżeli nie będzie ograniczeniem ilość pamięci RAM potrzebnej bardziej rozbudowanej stronie WWW. Trzymając kod HTML na karcie SD pozbywamy się tego ograniczenia. Ale jak w HTMLu trzymanym na karcie SD umieścić dane zebrane z czujników przez Arduino?

Potrzebujemy czegoś, co pozwoli nam wstrzyknąć dane do HTMLa pomiędzy ‘odczytem’ a ‘wysłaniem’. Czyli coś jak:

PHP dla Arduino

OK, to jest na wyrost :) potrzebujemy czegoś co bardziej przypomina szablony niż pełne PHP, ale na początku PHP też nie powalało funkcjonalnością :)

O tym jak zrobić taki parser (i pełny kod szkicu) – w następnym odcinku. Stay tuned.