Arduino w modelarstwie kolejowym

[ethanak]

4 minuty temu, prezesedi napisał:

w panelu?

Nie, w rozkładzie jazdy. W panelu wystarczy ten co jest, poza tym w ESP trochę pinów by zabrakło. Fo tego potrzebny jakiś czytnik kart (bo ten go nie ma), ale wystarczy zwykły adapter microSD->SD (z reguły dodawane do kart) i lutownica.

Edytowano 23 sierpnia przez ethanak

[ethanak]

Ech - jak zwykle błędy wychodzą po jakimś czasie 🙂

Zauważyłem dziwne zachowanie rozkładu jazdy. Teoretycznie (takie były założenia) restart panela nie powinien wpływać na pozycję rozkładu: panel pyta zarówno o treść rozkładu, jak i aktualną pozycję. Jednak okazało się, że dość często (szczególnie po uploadzie nowej wersji programu) rozkład przeskakuje na pierwszą pozycję... ciekawe czemu?

Trochę drążenia - co się okazało: otóż rozkład co jakiś czas pobiera (tak na wszelki wypadek) dane z panela. Jeśli zapyta o dane za wcześnie (tzn. kiedy panel nie zna jeszcze pozycji) - dostanie zero...

Trzeba było uzależnić odpowiedź od stanu panela - i tu powstał mały problem: funkcje obsługi są identyczne dla rozkładu i dla semaforów (które zawsze są aktualne). Czyżby trzeba było wprowadzać jakieś dodatkowe funkcje?

Jednak problem okazał się dużo łatwiejszy do naprawienia. Ponieważ:

• istnieje tylko jeden rozkład jazdy
• rozkład zawsze ma ustalony adres MAC (ostatni oktet równy 0x30)

wystarczyła drobna modyfikacja metody onReceive:

void Transceiver::onReceive(const uint8_t *data, int len)
{
    if (data[0] == ENOW_GIMMA_DATA) {
      // dodany warunek
        if (_macadr[5] == 0x30 // to jest transceiver rozkładu jazdy
            && !rozklad.validPos ) // i nie zna aktualnej pozycji
          return; // ignoruję pytanie o pozycję
      // a dalej już jak było...
        if (debugging) printf("Wysyłam nowe dane dla %02x\r\n",_macadr[5]);
        _sendAll = 1;
        return;
    }
...

Oczywiście to prowizorka i w kolejnej wersji (która powoli powstaje) będzie to poprawione porządnie. Ale chciałem tu pokazać, że czasem w prosty sposób można zmusić do prawidłowego działania program, w którym czegoś ktoś (znaczy ja) nie przewidział 🙂

 

 

 

[ethanak]

Cóż - trzeba wrócić do tej całej makiety 🙂

Dzisiaj krótko - jako że czas mnie goni tylko kilka słów.

Obecna wersja to prawdopodobnie finalna dla tej konfiguracji sprzętowej. Zmiany w stosunku do poprzednich wersji to:

• rozszerzony rozkład jazdy (stacja początkowa i docelowa, nazwa przewoćnika, nazwa pociągu);
• możliwość podłączenia wyświetlacza ST7789 (240 x 135, trochę bardziej wymiarami pasującego do skali H0, a przy okazji mającego nieco większą rozdzielczość;
• rozszerzone komunikaty słowne (zróżnicowanie w zależności od tego, czy stacja początkowa/końcowa to nasza stacja czy nie).

Format rozszerzonego rozkładu jest kompatybilny z poprzednią wersją, Kolejne pola w linii to:

• Typ pociągu - obowiązkowy, jeden znak O, S, P lub E;
• Nazwa przewoźnika i pociągu - opcjonalny: znak '@', do trzech liter skrótiu nazwy przewoźnika, opcjonalnie /nazwa_pociągu. Nazwa nie może zawierać spacji, należy w ich miejsce użyć znaku podkreślenia;
• Stacja docelowa - obowiązkowa, nazwa lub znak '-' jeśli pociąg kończy bieg na naszej stacji;
• Peron/tor - obowiązkowe, jednocyfrowe;
• Godzina odjazdu - obowiązkowa jeśli pociąg nie kończy biegu na naszej stacji, w przeciwnym razie zabroniona, w formacie HH:MM lub H:MM
• Godzina przyjazdu - obowiązkowa jeśli pociąg nie rozpoczyna biegu na naszej stacji, w formacie HH:MM lub H:MM;
• Stacja początkowa - obowiązkowa jeśli pociąg nie rozpoczyna biegu na naszej stacji.

Przykładowo:

Ekspres Intercity "Marynarzyk", przyjazd ze Szczecina Głównego 10:30, odjazd do Katowic 10:40, tor 4 peron 2

E @IC/Marynarzyk Katowice 4/2 10:40 10:30 Szczecin Główny

Osobowy TLK, 12:00 z Częstochowy, 12:10 do Bielska-Białej, tor 1 peron 1

O @TLK Bielsko-Biała 1/1 12:10 12:00 Częstochowa

Pospieszny Przewozy Regionalne, przyjazd z Mamłągowic 12:20, tor 2 peron 1, kończy bieg

P @PR - 2/1 12:20 Mamłągowice

#kspres Intercity "Górnik Dołowy", 15:40 do Katowic, tor 4 peron 2, rozpoczyna bieg

E @IC/Górnik_dołowy Katowice 4/2 15:40

Osobowy 16:10 do Pcimia, tor 2 peron 1

O Pcim 2/1 16:10

Na początku można dodać rozwinięcia skrótów użyte w komunikatach słownych, w formacie # skrót = rozwinięcie, przykładowo:

#IC = Intercity
#PR = Przewozy Regionalne

W załączniku oba programy (dla panela oraz dla rozkładu). Oba muszą być wgrane na odpowiednie urządzenia. Biblioteki - w poprzednim poście.

Aby podłączyć ST7789 należy odkomentować pierwszą linię w pliku display.cpp w programie rozkładu, czyli zamienić:

//#define USE_7789

na

#define USE_7789

O tym jednak więcej następnym razem.

Obiecany załącznik: kolejpan5.zip

No i oczywiście - stay tuned!

 

[ethanak]

No i errata... jako że w załączniku zabrakło pliku rozkładu do wgrania na kartę, podaję przykładową (nieco bezsensowną, ale działającą) zawartość:

# KS = Koleje Śląskie
# IC = PKP Intercity
# PR = Przewozy Regionalne
E @IC/Marynarzyk Katowice 4/2 10:40 10:30 Szczecin Główny
O @TLK Bielsko-Biała Komorowice 1/1 12:10 12:00 Częstochowa
P @PR - 2/1 12:20 Mamałygowice
S @TLK Český Těšín 2/1 13:50 13:40 Warszawa Wsch.
S @KS Żywiec 1/1 13:52 13:44 Katowice
E @IC/Riverator Šibenik 3/2 14:30 14:10 Warszawa Wsch.
E @IC/Górnik_dołowy Katowice Piotrowice 4/2 15:40
O @KS Bielsko-Biała Główna 1/1 16:10
E @IC/Zemsta_Brunnera Berlin Östbahnhoff 2/1 16:50
P @PR Kraków 1/1 16:52
P Tychy Lodowisko 3/2 17:30
E @IC/Havranek Hradec Králové 4/2 18:40 18:25 Gdańsk Główny
P @TLK Szczecin Dąbie 1/1 19:10
P @TLK Częstochowa 2/1 19:50
S @TLK Zamość 1/1 19:52 19:50 Żywiec
P @KS Tychy 3/2 20:30 20:25 Czeladź

Przypominam, że powinien być wgrany pod nazwą rozklad1.txt w głównym katalogu karty!

 

[Polecacz 101]

Produkcja i montaż PCB - wybierz sprawdzone PCBWay!
   • Darmowe płytki dla studentów i projektów non-profit
   • Tylko 5$ za 10 prototypów PCB w 24 godziny
   • Usługa projektowania PCB na zlecenie
   • Montaż PCB od 30$ + bezpłatna dostawa i szablony
   • Darmowe narzędzie do podglądu plików Gerber
Zobacz również » Film z fabryki PCBWay

[ethanak]

No, pora kończyć pewien etap. Program jest uruchomiony, sprawdzony, działa... jest tylko jeden problem. Otóż zastosowany w rozkładzie jazdy wyświetlacz nie ma wbudowanego czytnika kart.

Rozwiązania są dwa. Najprostsze to wgranie pliku bezpośrednio do pamięci flash ESP8266. Nie chcę się tu rozpisywać - jest bardzo dobra strona pokazująca jak to się robi: https://randomnerdtutorials.com/install-esp8266-nodemcu-littlefs-arduino/

Czyli rozwiązanie sprawdzone, ma tylko jedną drobną wadę: mianowicie chcąc zmienić rozkład jazdy trzeba podłączyć się do komputera - a nie zawsze jest to wygodne czy nawet możliwe.

Oczywiście można podłączyć czytnik kart dedykowany dla Arduino, pamiętać tylko należy, że pin CS ma być połączony z pinem GPIO15 (alias D8) naszego ESP8266. Czyli po prostu:

ESP8266 - czytnik

GPIO15 (D8) - CS
GPIO14 (D5) - SCK
GPIO13 (D7) - MOSI
GPIO12 (D6) - MISO
3.3V        - VCC
GND         - GND

Jednak nie zawsze mamy czytnik pod ręką, poza tym typowy moduł jest większy niż WEMOS!. Możemy natomiast zrobić czytnik w bardzo prosty sposób: jako że operujemy tu napięciem 3.3V (takim, jakiego wymaga karta microSD) nie musimy bawić się w żadne rezystory czy stabilizatory - możemy podpiąć kartę bezpośrednio do mikrokontrolera.

Jeśli dysponujemy gniazdem karty microSD możemy podłączyć je w następujący sposób:

ESP8266 - microSD

15 (D8) CS   - 2 (CD/DAT3)
13 (D7) MOSI - 3 (CMD)
3.3V         - 4 (VDD)
14 (D5) CLK  - 5 (CLK)
GND          - 6 (VSS)
12 (D6) MISO - 7 (DAT0)

Można również wykorzystać adapter microSD/SD (który z reguły leży gdzieś w rupieciach bo był w komplecie z kartą microSD). Przykładowy sposób lutowania można znaleźć np. na Instructables - oczywiście chodzi tylko o lutowanie pinów do adaptera, cała zabawa z rezystorami i dzielnikami jest konieczna tylko dla 5-voltowych mikrokontrolerów!

ESP8266 - SD

15 (D8) CS   - 1 (CD/DAT3)
13 (D7) MOSI - 2 (CMD)
GND          - 3 (VSS1)
3.3V         - 4 (VDD)
14 (D5) CLK  - 5 (CLK)
12 (D6) MISO - 7 (DAT0)

I tu jeszcze ciekawostka: szukając w sieci źródeł, na które mógłbym się powołać natrafiłem wielokrotnie na opinie, że zrobione z adapterów czytniki sprawuję się doskonale z ESP i nie sprawiają żadnych problemów - natomiast te dedykowane dla Arduino czasem działają niestabilnie albo w ogóle...

I jeszcze drobiazg. Ponieważ istnieją różne typy płytek wyświetlaczy, czasem trzeba obrócić obraz. W kodzie display.cpp w obu sekcjach (dla ST7735 i ST7789) są definicje takie, jak:

#define _SROT 1
 

W przypadku konieczności obrócenia obrazu należy zamienić 1 na 3.

I to na razie wszystko. Teraz muszę znaleźć trochę czasu aby pobawić się panelem (zarówno lutownicą, jak i klawiaturą), ale obiecuję ciąg dalszy. Tak że jak zwykle - stay tuned!

 

[ethanak]

Trochę czasu minęło... ale doba ma tylko 24 godziny 😞

Na wstępie uwaga: ponieważ wzmacniacz audio wraz z głośnikiem pobiera dość duży prąd, zasilanie z USB przestaje wystarczać. Najprostszym sposobem jest podłączenie zewnętrznego zasilacza 5V. Sposób podłączenia powinien być taki jak poniżej:

Dioda ma dwa zadania. Po pierwsze, ma odciąć zasilanie od wzmacniacza kiedy zasilamy urządzenie wyłącznie z gniazda USB na płytce ESP (np. w trakcie programowania), Wzmacniacz wtedy co prawda nie działa, ale przy zasilaniu z USB prawdopodobnie i tak nie zadziała. Po drugie - jeśli zasilacz jest odłączony od sieci i podłączony do płytki, ma nie dopuścić do podania mu napięcia na wyjście (niektóre zasilacze - jak się ostatnio przekonałem - bardzo tego nie lubią).

Cóż, pora brać się za konkretne przeróbki.

Zacznę może zrzędzenie od tego, że miniaturowy wyświetlaczyk OLED nadaje się jak najbardziej do odczytywania godziny na zegarku (pod warunkiem ustawienia wielkości tekstu co najmniej 3x4, a nie jako monitor (nawet monitorek) do czegoś bardziej skomplikowanego. Szczególnie czytanie miniaturowych literek o wielkości poniżej milimetra może być nieco frustrujące... że o rozdzielczości pozwalającej na zmieszczenie 21 ściśniętych znaczków w linii nie wspomnę.

Teoretycznie można zastosować większy wyświetlacz (128 x 64), ale to niewiele poprawi. Poza tym wyświetlacze OLED mają tendencję do wypalania pikseli, czyli powinny być zapalane jedynie na żądanie.

Niestety, na podłączenie większego wyświetlacza działającego na magistrali SPI a nie I2C po prostu nie mamy już wolnych pinów. Co można zrobić?

Przede wszystkim osiem pinów zajmuje klawiatura. A gdyby tak podłączyć ją w inny sposób?

W grę wchodzą dwie możliwości. Na przykład klawiatura rezystancyjna zajmuje dokładnie jeden pin analogowy (a te mamy akurat wolne). Stosowałem takie rozwiązanie kilkakrotnie, sprawdziło się, tyle że taka klawiatura wymaga oprócz rezystorów o konkretnych wartościach jeszcze kalibracji. Poza tym jak wiadomo, przetworniki ADC w ESP32 nie grzeszą dokładnością, co prawda i na to są sposoby ale program zacząłby się zbytnio komplikować.

Druga możliwość to podłączenie klawiatury przez interfejs I2C. Ponieważ szyna I2C jest i tak użyta w programie, nie potrzebujemy żadnych dodatkowych pinów! Jedyną wadą jest konieczność zastosowania ekspandera PCF8574 (lub PCF8575, ale o tym później). Wybrałem to rozwiązanie.

Zacząłem więc od elektroniki (to taka szumna nazwa na wlutowanie jednego scalaka do płytki prototypowej). Podłączenie PCF8574 jest bardzo proste: SCL i SDA do właściwych pinów (tam już powinny być podpięte ekspandery semaforów i display OLED), zasilanie też we właściwe miejsca (Vcc go 3.3V, GND do GND). Linie adresowe w moim przypadku podłączyłem po prostu do Vcc aby nie kolidowały z semaforami, (użyta przeze mnie wersja N zgłasza się na tych samych adresach co ekspandery semaforów). Klawiaturę podłączyłem do pinów P0...P7 - i to wszystko!

Wygląda to mniej więcej tak:

Dla PCF8575 układ będzie podobny, tyle że trzeba pamiętać o jednym: o ile PCF 8574 ma wyjścia typu push-pull (umożliwiające podciągnięcie wejścia do Vcc, konieczne przy klawiaturze), o tyle PCF8575 to open drain (czyli pin albo jest zwierany do masy, albo wisi sobie w powietrzu). Stąd konieczność zastosowania dodatkowych rezystorów na liniach kolumn:

Jeśli chodzi o wartości rezystorów nie bardzo mam jak sprawdzić (nie mam takiego scalaka), ale moim wydaje mi się, że jakieś 4.7k powinny być OK. Zresztą - kolega @prezesedi za chwilę pewnie będzie to sprawdzać i napisze jakie rezystory zastosował.

Tyle w sprawie kabelkologii. Zadowolony z siebie zacząłem pisać prosty program do testowania klawiatury. Skaner I2C po prostu skopiowałem z innego rozwiązania, przyszła kolej na bibliotekę obsługi klawiatury.

No i tu się zaciąłem. Chciałem, aby była jak najprostsza i jak najmniej się różniła z punktu widzenia programu od uzytej biblioteki Keypad. Okazało się, że miałem za duże wymagania... dostępne biblioteki albo nie obsługiwały PCF8575, albo obsługiwały tylko PCF8575, a jeśli już znalazła się taka, co działała z oboma typami ekspanderów nie miała najmniejszego zamiaru skompilować się na ESP32. Co prawda jakąś tam znalazłem, ale wymagałaby zbyt dużych zmian w programie, a tego chciałem uniknąć. Postanowiłem więc zajrzeć do wnętrza biblioteki Keypad_I2C - kiedyś stosowałem ją w małym Arduino i sprawdziła się znakomicie.

Cóż się okazało?

Biblioteka jest dość stara, w każdym razie jeszcze z czasów kiedy ESP32 istniało tylko na chińskim papierze. Dlatego autor założył, że istnieje tylko jedna szyna I2C i przy okazji fajnie będzie jak się ją zainicjalizuje. Dlatego klasa Keypad_I2C jest pochodną nie tylko używanej już w programie klasy Keypad, ale również TwoWire (czyli I2C). Trzeba było tę ostatnią zależność wywalić. Magistralę I2C trzeba będzie co prawda zainicjalizować (co akurat nie jest wielkim problemem, gdyż i tak jest w programie używana), ale trzeba pozwolić na podpięcie dowolnej magistrali.

Przerobiona klasa wygląda tak:

class Keypad_I2C : public Keypad {
public:
    Keypad_I2C(char* userKeymap, byte* row, byte* col, byte numRows, byte numCols, byte address, byte width = 1) :
        Keypad(userKeymap, row, col, numRows, numCols) { i2caddr = address; i2cwidth = width;}    
    

    // Keypad function
    void begin(void);
    void begin(TwoWire *MyWire);
    
    void pin_mode(byte pinNum, byte mode) {}
    void pin_write(byte pinNum, boolean level);
    int  pin_read(byte pinNum);
    // read initial value for pinState
    word pinState_set( );
    // write a whole byte or word (depending on the port expander chip) to i2c port
    void port_write( word i2cportval );

private:
    // I2C device address
    byte i2caddr;
    // I2C port expander device width in bytes (1 for 8574, 2 for 8575)
    byte i2cwidth;
    // I2C pin_write state persistant storage
    // least significant byte is used for 8-bit port expanders
    word pinState;
    TwoWire *_Wire;
};

Jak widać, doszła tylko jedna zmienna prywatna, służąca do trzymania instancji magistrali. Oprócz tego wszystkie metody begin(cośtam) zostały usunięte, w ich miejsce zastosowałem dwie dużo prostsze:

void Keypad_I2C::begin(void) {
    _Wire = &Wire;
    pinState = pinState_set( );
}

void Keypad_I2C::begin(TwoWire *MyWire) {
    _Wire = MyWire;
    pinState = pinState_set( );
}

Do tego trzeba było zmienić wywołania metod TwoWire wewnątrz biblioteki, ale to już była czynność czysto mechaniczna zrezlizowana za pomocą wbudowanego w edytor mechanizmu "znajdż i zamień wszystkie": trzeba było zamienić wszystkie wystąpienia TwoWire:: ma _Wire-> - czyli np. fragment oryginalnego kodu:

    TwoWire::requestFrom((int)i2caddr, (int)i2cwidth);
    word pinVal = TwoWire::read( );

wygląda po przeróbce tak:

    _Wire->requestFrom((int)i2caddr, (int)i2cwidth);
    word pinVal = _Wire->read( );
   

 
Przerobione pliki Keypad_I2C.cpp i Keypad_I2C.h wrzuciłem po prostu do folderu ze szkicem i zabrałem się do dalszej pracy.

Przy okazji pomyślałem sobie, że w kodzie czasem coś trzeba pozmieniać zależnie od naszej kabnelkologii. Aby nie komplikować życia, postanowiłem utworzyć jeden plik, który następnie będzie kopiowany (po ustawieniu w nim odpowiednich wartości) do kolejnych szkiców. Plik config.h (ustalający wartości dla klawiatury i wyświetlacza) wygląda tak:

#ifndef INPUTCFG_H
#define INPUTCFG_H

// odkomentuj dla PCF8575!
// #define KBD_PCF8575

// odkomentuj dla ILI9341
// #define USE_ILI9341

// odkomentuj dla odwróconego ekranu
//#define SCREEN_ROTATE

#ifdef KBD_PCF8575

#define I2C_KBDADR 0x27
#define KBWIDTH 2

#else

#define I2C_KBDADR 0x27
#define KBWIDTH 1

#endif

#define ROWS 4
#define COLS 4

#define ROW_PINS {0, 1, 2, 3}
#define COL_PINS {4, 5, 6, 7}


/* piny SPI */
#define DISP_CS 4
#define DISP_RST 5
#define DISP_DC 18
#define DISP_MOSI 19
#define DISP_SCK 13
#define DISP_MISO 12
#define DISP_CS2 14
#define DISP_IRQ2 27


#endif

Plik chyba nie wymaga większego opisu, z jednym wyjątkiem...

Otóż zamiast zamówionego ILI9341 omyłkowo przysłano mi wyświetlacz z układem ST7789. Z propozycji wymiany nie skorzystałem (stwierdziłem, że za dużo z tym zachodu, wyświetlacze różnią się poza tym tylko rozstawem otworów na śrubki mocujące), za to przystosowałem program do współpracy z oboma typami wyświetlaczy. Dla ST7789 należy pozostawić tak jak jest, dla ILI9341 po prostu odkomentować linię:

// #define USE_ILI9341

Teraz przeróbki samego programu... no i jak wspomniałem, wszystko miało być jak najprostsze (tak, aby było jak najmniej zmian w programie). Tak więc pomijając dostosowanie do włączania pliku config.h w pliku getcommand.cpp mamy następujące zmiany:

zmieniły się dyrektywy #include, wyglądają teraz tak:

#include <Arduino.h>
#include "Makieta.h"
#include "config.h"
#include "Keypad_I2C.h"

Doszła funkcja inicjalizacji klawiatury (wywoływana z funkcji setup() w głównej części programu):

void initKeyboard()
{
    keypad.begin();
}

i zmieniła się deklaracja klawiatury:

static Keypad_I2C keypad = Keypad_I2C( makeKeymap(keys),
    (uint8_t *)rowPins,
    (uint8_t *)colPins,
    ROWS, COLS,
    I2C_KBDADR, KBWIDTH );

Pomijając odpowiednie dopiski w Makieta.h i głównym pliku *.ino to już wszystko!

Kod jak zwykle w załączniku:kolejpan6.zip

Następnym razem spróbuję podłączyć wyświetlacz SPI, tak że: stay tuned!
 

[ethanak]

Ech, zapomniało mi się... programik do testowania klawiatury: kolkbdtest.zip

Trzeba tak poustawiać w config.h, aby kody wciskanych klawiszy wyświetlane na monitorze Serial były zgodne z tym, co jest w pliku ino, czyli:

    {1,2,3,11},
    {4,5,6,12},
    {7,8,9,13},
    {42,10,35,14}

Najprawdopodobniej do poprawienia będzie na razie tylko adres I2C_KBDADDR, chyba że ktoś inaczej podłączy piny PCF-a.