Elektroda.pl
Elektroda.pl
X
Computer ControlsComputer Controls
Proszę, dodaj wyjątek dla www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

Moduł wykonawczy dla systemu Domoticz.

epoxer 01 Sty 2020 12:49 2862 16
  • Jakiś czas temu zbudowałem układ z myślą o automatyce budynkowej.
    Miał być to kolejny PLC DIY oparty tym razem o ARM Cortex-M0 LPC1114, który coś nawet działał.
    Wytyczne nie były wygórowane:
    - Zasilanie 24V
    - 4x Wejścia cyfrowe 24V
    - 4x Wyjścia cyfrowe 24V
    - RS485
    - Dostęp przez ETH (po kablu)
    - Montaż na szynę DIN
    - Możliwość pisania prostych instrukcji (wbudowany interpreter) - opcja porzucona

    Urządzenie zaprojektowane, wykonane i działa. Kod z początku pisany w C (uVision 5).
    Podczas pisania programu wpadały do głowy co chwila nowe pomysły. I tak kod C napisany został strasznie chaotycznie, zawiesza sterownik co jakiś czas :D (pierwsze próby obsługi TCP/IP dla ENC28J60 pod kilka połączeń na raz).
    Przyszły jednak zmiany w życiu i przesiadka na system Linux. A tam chęć odkrywania możliwości legendarnego Pascala w systemach wbudowanych (ARM + Pascal i tu oszalałem).
    Przysiadłem trochę czasu i napisałem nowe oprogramowanie do sterownika w tym właśnie języku (bo czemu by nie).
    Do sedna...
    Może komuś przyda się projekt PCB stworzony w EAGLE.
    Dodatkowo udostępniam źródła projektu napisane w FreePascal'u.

    Obecnie możliwości sterownika okrojone i przystosowane do odbioru poleceń z Domoticz'a.
    Być może kiedyś wrócę do projektu budowy sterownika PLC bardziej programowalnego, jednak na okres świąt/zimy sterownik robi robotę w stylu:
    - włącz/wyłącz oświetlenie zewnętrzne domu
    - włącz/wyłącz oświetlenie świąteczne na zewnątrz

    Oprogramowanie umożliwia do 10 (możliwość zwiększenia w kodzie) połączeń na raz. Obsługa ARP/ICMP(Ping)/TCP bez fragmentacji max 1460B / pakiet. Zużywa 3.5kB RAM i 23kB FLASH.

    IP sterownika domyślnie to 192.168.1.200

    Źródeł C poprzedniego projektu aż wstyd udostępniać.
    Parę fotek (wersja jeszcze z zew. pamięcią EEPROM i brakiem RS485).
    Moduł wykonawczy dla systemu Domoticz. Moduł wykonawczy dla systemu Domoticz. Moduł wykonawczy dla systemu Domoticz. Moduł wykonawczy dla systemu Domoticz.

    Filmik z działania oprogramowani w C

    Link


    Źródła (FreePascal) oraz pliki Eagle, na github.
    Link

    Fajne! Ranking DIY
    Potrafisz napisać podobny artykuł? Wyślij do mnie a otrzymasz kartę SD 64GB.
    O autorze
    epoxer
    Poziom 13  
    Offline 
    epoxer napisał 80 postów o ocenie 17, pomógł 1 razy. Mieszka w mieście Bełchatów. Jest z nami od 2006 roku.
  • Computer ControlsComputer Controls
  • #2
    khoam
    Specjalista - ESP32, ESP8266
    epoxer napisał:
    Przyszły jednak zmiany w życiu i przesiadka na system Linux. A tam chęć odkrywania możliwości legendarnego Pascala w systemach wbudowanych (ARM + Pascal i tu oszalałem).

    Może trochę ;) Poza tym bardzo porządnie wykonany projekt. Oby więcej takich w tym dziale.
  • Computer ControlsComputer Controls
  • #3
    krisRaba
    Poziom 29  
    Hehe, tak patrzę po miniaturkach i myślę sobie "WOW, ale fajnie wpasowany wyświetlacz LCD!" :lol: Potem powiększam, a to wydrukowana kartka, przez którą przebijają diody LED, hahaha :lol: Ech ta wyobraźnia :D

    Fajny projekt. Możesz dorzucić PDFy dla osób, które niekoniecznie używają Eagle'a? ;)
  • #4
    khoam
    Specjalista - ESP32, ESP8266
    krisRaba napisał:
    Hehe, tak patrzę po miniaturkach i myślę sobie "WOW, ale fajnie wpasowany wyświetlacz LCD!"

    Też w pierwszej chwili pomyślałem, że taki jakiś trójkolorowy e-paper :) Lepsza byłaby chyba, jakaś przesłona z półprzezroczystej pleksi.
  • #5
    krisRaba
    Poziom 29  
    Kiedyś przymierzałem się do podobnego "klocka", to rozważałem ciekawy wynalazek jako frontowa "szybka". Był to półprzezroczysty materiał pokryty od spodu nieprzezroczystą warstwą. Można było z pomocą znakowania laserowego wykonać od spodu zaprojektowany wzór, czyli odsłaniasz to, co ma prześwitywać. Idealne właśnie pod takie rzeczy, że diodka podświetla jakiś symbol. Z wierzchu pozostaje gładkie :)
  • #7
    Dariusz Goliński
    Poziom 22  
    Cześć

    Czy aby zmienić ip trzeba ponownie przekompilować źródło ?
    Czy możesz opisać ustawienia domoticza do komunikacji z twoim sterownikiem ?

    Pozdrawiam.
  • #8
    tmf
    Moderator Mikrokontrolery Projektowanie
    Niezłe wykonanie i za to pełna pochwała. Ale mam kilka uwag do schematu:
    1. Transceiver RS485 - DE/RE - masz stan nieustalony w momencie włączania układu/resetu procka. Powinien tam być rezystor ustalający stan.
    2. Transoptory - zupełnie niepotrzebne w konfiguracji w jakiej ich użyłeś. Skoro nie masz separacji galwanicznej, a nie masz, bo masz wspólne masy, to te transoptory na wejściu, a także na wyjściu kompletnie nic nie dają. Myślałem, że może idea była taka, aby wejścia sterować prądowo, ale te sumarycznie 2k2 na wejściu temu przeczy. Przy wyjściach transoptory sterujące MOSFETami też są zbędne - zwykły tranzystor by tam wystarczył.
    3. Sterowanie bramką MOSFETów - jeśli transoptor jest wyłączony to na bramcve masz 24 V i tranzystor jest wyłączony. Ale jeśli transoptor jest włączony to na bramce masz 24V/2 (dzielnik z dwór rezystorów 10k), a w praktyce napięcie jest jeszcze wyższe, bo optotranzystor też ma jakiś spadek i w efekcie MOSFET może nie być w pełni otwarty. Co prawda przy -kilku woltach będzie otwarty w znacznym stopniu, jednak może to powodować ineptrzebne grzanie się tranzystora przy większym prądzie wyjściowym.
    4. Trochę ubogo z kondensatorami odsprzęgającymi. A chociażby przy transceiverze jakiś powinien być, bo tam impulsowo znaczne prądy mogą płynąć.
  • #9
    epoxer
    Poziom 13  
    Dziękuję za cenne uwagi, postaram się wstawić poprawki do schematów w krótkim czasie.
    1. Czy rezystor podciągający w MCU nie wystarczy do ustalenia stanu szyny DE/RE ? domyślnie jest Pull-up.
    2. Transoptory zadanie miały odizolować napięcie 3V3 od 24V w przypadku zwarcia "tranzystora sterującego MOSFET'em" takie swego rodzaju zabezpieczenie przed napięciem wstecznym, brak masy to mój błąd przyznaję się (ale czy przy 24V DC potrzebna jest 100% izolacji?), ostatecznie można to rozdzielić.
    3. Dla wybranego NTD25P03L Vgs jest na poziomie 15V i 20V w piku (<10ms). dzielnik robi średnią 12V, każdy spadek rzędu 0.7V napięcia podwyższy te 12V w granice ~13V co da nam różnicę otwarcia na poziomie 11V (czyli >5 a <15 i to jest akceptowalne). A należy wziąć pod uwagę, że jest to tranzystor Logic Level, który startuje już od 5V na bramce.
    4. Tak to błąd niewielkiego doświadczenia mej osoby w projektowaniu.

    Na chwilę obecną większy problem u mnie istnieje ze wzmacniaczem OP na wejściu. Idea była taka, aby móc podłączyć NTC w prosty sposób, jednak obecny schemat komplikuje tę opcję.
  • #10
    krisRaba
    Poziom 29  
    epoxer napisał:
    1. Czy rezystor podciągający w MCU nie wystarczy do ustalenia stanu szyny DE/RE ? domyślnie jest Pull-up.

    Zanim wystartuje procek ten pull-up nie działa, więc linia sobie lata w powietrzu ;)
    To samo, gdy procek się zresetuje z jakiegoś względu i musi ponownie wstać...

    Dodano po 6 [minuty]:

    Generalnie wszystkie linie typu /CS, ENABLE/DISABLE itp., które wpływają na zewnętrzne podzespoły i mogą wywołać dziwne stany przejściowe, jeśli nie są dobrze ustawione, należy konfigurować przez zewnętrzne podciąganie. Wszystkie (no może większość, i tak trzeba je przemyśleć) rzeczy typu wejście przycisku, enkodera itp. których obsługa znajduje się wewnątrz MCU i to program odpowiada za ich konfigurację i działanie funkcji można zostawić na wewnętrznych podciąganiach, bo i tak konfigurujesz GPIO zanim skonfigurujesz wewnętrzny blok i zaczniesz używać danego sygnału...
    Chodzi o to, że urządzenia pracujące poza mikrokontrolerem mogą startować dużo szybciej i brak wysterowania ich linii (lub losowe wysterowanie przez wiszącą przez chwilę w powietrzu linię) może je wprowadzić w dziwny stan, coś załączyć, wygenerować jakiś przebieg itp.
  • #11
    tmf
    Moderator Mikrokontrolery Projektowanie
    ad 1. Ale czy ten pullup jest stale, czy dopiero w chwili konfiguracji pinu IO przez software? Niektóre ARMy mają możliwość zapamiętania konfiguracji i wtedy jest ok. Jeśli jednak dopiero software konfiguruje ten pull up masz stan nieustalony do momentu aż zostanie on skonfigurowany, czyli potenc jalny glitch na magistrali RS485. Nie jest to wielkim problemem i protokół wymiany danych sobie z tym poradzi. To raczej uwaga kosmetyczna.
    ad 2. Uszkodzenie typu przebicie do bramki jest małoprawdopodobnym scenariuszem uszkodzenia MOSFETa. Nawet jakby, to tranzystor sterujący tą bramką, plus rezystor na bazie tego tranzystora ochronią resztę układu. Możesz zresztą w charakterze tranzystora sterującego dać kolejny MOSFET.
    ad 3. Transoptor raczej przesunie potencjał pbramki w kierunku 24V a nie masy.
    Gewneralnie powyższe uwagi są natury kosmetycznej, układ działa poprawnie i to jest najważniejsze.
  • #12
    epoxer
    Poziom 13  
    krisRaba napisał:
    epoxer napisał:
    1. Czy rezystor podciągający w MCU nie wystarczy do ustalenia stanu szyny DE/RE ? domyślnie jest Pull-up.

    Zanim wystartuje procek ten pull-up nie działa, więc linia sobie lata w powietrzu ;)

    Jest to wartość po RESECIE natychmiast. Start programu nie jest tu brany pod uwagę.
    Problem zaczyna się gdy chcemy zmienić taki domyślny Pull-up na inną wartość (dostajemy efekt piku na tym pinie w momencie podawania napięcia na układ). W tym przypadku tego efektu nie ma.
  • #13
    krisRaba
    Poziom 29  
    epoxer napisał:
    2. Transoptory zadanie miały odizolować napięcie 3V3 od 24V w przypadku zwarcia "tranzystora sterującego MOSFET'em" takie swego rodzaju zabezpieczenie przed napięciem wstecznym, brak masy to mój błąd przyznaję się (ale czy przy 24V DC potrzebna jest 100% izolacji?), ostatecznie można to rozdzielić.

    Jak się tego boisz, to można w szeregu (między tranzystorem a pinem MCU) dać diodę, która zablokuje napięcie wsteczne ;). Ale zwykle się tak nie robi. Jak dasz np. NMOSa logic level, na bramce 100k do masy, między MCU a bramkę dasz np. 10k, to w przypadku jakiegoś błędu montażowego czy uszkodzenia masz 2,4mA, które będzie chciało się przecisnąć przez pin MCU, jeśli tranzystor wisiał bezpośrednio na zasilaniu. A zwykle tak nie jest ;) Bo np. sterując PMOSa masz jeszcze tam 2x10k, czyli łącznie 30k pomiędzy zasilaniem 24V a pinem MCU... będzie żył :D

    Dodano po 2 [minuty]:

    epoxer napisał:
    Jest to wartość po RESECIE natychmiast. Start programu nie jest tu brany pod uwagę.

    A co to za MCU, który na starcie ma GPIO z pull-upem? Wiem, że nie wszystko jeszcze w życiu widziałem, stąd pytam :)

    Dodano po 3 [minuty]:

    O, zajrzałem do tego LPC i faktycznie ma jakieś piny, które po resecie są w PU :D Człowiek się całe życie uczy. Tylko pytanie, czy to serio działa od razu w każdych warunkach :)

    Dodano po 3 [minuty]:

    W sumie ciekawe, bo z tego co widzę, to chyba wszystkie jego linie tak startują... a to może rodzić problemy w drugą stronę, że podciągamy coś, co nie powinno być podciągnięte :lol:
  • #14
    epoxer
    Poziom 13  
    krisRaba napisał:
    O, zajrzałem do tego LPC i faktycznie ma jakieś piny, które po resecie są w PU Człowiek się całe życie uczy. Tylko pytanie, czy to serio działa od razu w każdych warunkach :)


    Tworząc inny projekt już sprawiało mi to problemy. Zanim program się uruchomił do miejsca konfiguracji pinu miałem drobne piki na tych pinach. Od tamtego czasu biorę to pod uwagę również stosując piny jako wejścia/wyjścia układu. Jednak z logicznego pkt. widzenia dodatkowe podciąganie pinów (ustalanie stanu) polepszy układ, nie pogorszy. Ustali stan pinów w momencie (awaryjnego wciskania RESET dla procesora, czy programowania układu). Dziękuję za cenne uwagi na przyszłość się bardzo przydadzą.
  • #16
    Slawek K.
    Poziom 32  
  • #17
    epoxer
    Poziom 13  
    Poszła aktualizacja kodu i wstępna obsługa takiej mojej implementacji języka 'IL' (instruction list) zaczerpniętego troszkę ze sterowników Si***s ;P
    Kod nie jest optymalny, ale jest w fazie produkcyjnej (Duża część kodu się powtarza, ale jeszcze tego nie optymalizuję z prywatnych powodów).
    Rozumiem, że może być problem z tym, że to pisane w Pascalu. Jednak jest to kod z przeznaczeniem dla społeczności FPC i tamtego forum.
    Co ten kod robi?
    A to co widać na filmie z youtub'a przedstawionym w Pierwszym poście.
    https://github.com/devport/LPC1114/commit/99639d55c4d938cd456836feb9fcff8a252fcbb1