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

Włącznik 230V sterowny pilotem IR

Ty-grysek 01 Sty 2020 18:16 2865 23
  • Swojego czasu zrobiłem sobie nastrojowe oświetlenie za telewizorem i stwierdziłem że wygodnie byłoby je włączać i wyłączać za pomocą tego samego pilota, którym obsługuję sprzęt RTV (w moim przypadku jest to programowalny pilot uniwersalny, gdzie kilka przycisków jest nieużywanych). Tak powstał ten oto prosty projekt. Oczywiście urządzenie jest bardziej uniwersalne i może służyć do sterowania dowolnym urządzeniem, np. lampkami choinkowymi :-)
    Z premedytacją nie implementowałem opcji regulacji natężenia światła bo chciałem aby urządzenie było uniwersalne i pracowało przed zasilaczem/źródłem światła/innym odbiornikiem – bezpośrednio na linii 230V.

    Założenia:
    - uniwersalność - praca bezpośrednio na linii 230V,
    - możliwość „nauczenia” dowolnego kodu pilota IR,
    - możliwość „nauczenia” dwóch osobnych przycisków do włączania i do wyłączania lub jednego przycisku włącz/wyłącz.
    - możliwość włączania/wyłączania przyciskiem, bez użycia pilota.

    Realizacja
    Urządzenie zostało wyposażone we własny zasilacz - wykorzystałem gotową przetwornicę. Elementem wykonawczym jest przekaźnik. Źródła C++ zostały napisane w Atmel Studio z wykorzystaniem biblioteki IRMP. Ktoś pewnie zauważy że biblioteka nie jest podłączona „książkowo” - cóż, mimo (krótkiej) walki nie udało mi się. Tym niemniej wszystko kompiluje się i działa poprawnie.

    Włącznik 230V sterowny pilotem IR Włącznik 230V sterowny pilotem IR Włącznik 230V sterowny pilotem IR Włącznik 230V sterowny pilotem IR

    Koszt:
    - mikrokontroler ATmega88PA – 5 zł
    - przekaźnik HF118F 005-1ZS1T(136) – 6 zł
    - przetwornica 230V -> 5V – 11 zł
    - odbiornik TSOP4836 – 2 zł
    - pozostała „drobnica” – 5 zł
    Łącznie ok 30 zł + kosz wykonania PCB.

    Obudowa – wydruk 3D – jest w trakcie realizacji.

    Fajne! Ranking DIY
    Potrafisz napisać podobny artykuł? Wyślij do mnie a otrzymasz kartę SD 64GB.
    O autorze
    Ty-grysek
    Poziom 10  
    Offline 
    Matematyk z wykształcenia, informatyk / programista z zawodu i elektronik (technika cyfrowa) z zamiłowania.
    Ty-grysek napisał 136 postów o ocenie 197, pomógł 0 razy. Mieszka w mieście Wrocław. Jest z nami od 2010 roku.
  • TermoPasty.plTermoPasty.pl
  • #2
    Tumiwisizm
    Poziom 25  
    Projekt fajny, ale pokaż jak to działa :).
  • #3
    Ty-grysek
    Poziom 10  
    Tumiwisizm napisał:
    Projekt fajny, ale pokaż jak to działa :).

    To znaczy mam wrzucić filmik? Urządzenie jest tak proste że nie ma czego tu pokazywać... Chyba że Kolega nie wierzy że urządzenie działa :-) Mamy Nowy Rok a nie Prima aprilis :-)
    Nie ma sprawy, spróbuję coś nagrać i wrzucić.
  • #4
    Tumiwisizm
    Poziom 25  
    Ty-grysek napisał:
    To znaczy mam wrzucić filmik?
    No dokładnie. Pewnie dzieli nas kilka dekad wiekowych i mnie już takie rzeczy nie kręcą żeby składać, ale chętnie zobaczę jak to działa.
  • #5
    simw
    Poziom 23  
    Ty-grysek napisał:
    Ktoś pewnie zauważy że biblioteka nie jest podłączona „książkowo” - cóż, mimo (krótkiej) walki nie udało mi się. Tym niemniej wszystko kompiluje się i działa poprawnie.

    Jeśli ktoś użyje Eclipse z wtyczką dla AVR to wystarczy zmienić
    Kod: c
    Zaloguj się, aby zobaczyć kod

    na
    Kod: c
    Zaloguj się, aby zobaczyć kod

    Wszystko będzie poprawnie i "książkowo" :)
    IRMP jest "wieloplatformowe" i potrzebuje odpowiednich flag rozpoznających uK, Eclipse z wtyczką AVR dodaje wszystkie odpowiednie. Oczywiście można własnoręcznie zrobić Makefile, ale to już nieco trudniejsze.
  • #6
    Ty-grysek
    Poziom 10  
    simw napisał:
    Jeśli ktoś użyje Eclipse z wtyczką dla AVR to wystarczy zmienić
    Kod: c
    Zaloguj się, aby zobaczyć kod

    na
    Kod: c
    Zaloguj się, aby zobaczyć kod



    Czy Kolega próbował to zrobić?

    W pliku irmp.c jest:
    Kod: c
    Zaloguj się, aby zobaczyć kod

    natomiast plik irmp.h nie inkluduje (ani bezpośrednio ani pośrednio) pliku irmp.c. Jeśli więc użyję:
    Kod: c
    Zaloguj się, aby zobaczyć kod

    to skąd kompilator będzie wiedział że trzeba użyć irmp.c?
  • TermoPasty.plTermoPasty.pl
  • #7
    simw
    Poziom 23  
    Oczywiście, że sprawdziłem. To była pierwsza rzecz :) Gdy będę w domu to podrzucę gotowy projekt.

    Kompilator będzie wiedział, bo w Eclipse "jest automat", który kompiluje każdy plik .c do pliku obiektowego .o.
    Inaczej pisząc "znajduje" wszystkie pliki .c w katalogu głównym projektu i również podkatalogach, "robi" z nich pliki obiektowe .o a potem "podaje" do linkera. W ten sposób powstaje wiele plików .o, w Twoim przypadku powstaje tylko jeden plik main.o z tego powodu, że "wrzucasz" cały irmp.c do pliku main.c, a pliku irmp.c nie podajesz do kompilacji - inaczej dostałbyś błędy o powtarzających się "obiektach", jeśli używasz Eclipse to pewnie irmp.c masz wyłączony z kompilowania, ale to tylko moje domysły.
    No chyba, że coś jest "pochrzanione" w Eclipse, uszkodzona instalacja czy workspace. Pod tym względem Eclipse potrafi być uciążliwy.

    Warto sobie zdać sprawę co robi kompilator i linker, ważne jest to co robi dyrektywa #include, która po prostu wkleja plik, który ma w "parametrze". Warto poznać co to jest "extern", zasięgi zmiennych, co to jest zmienna i funkcja statyczna. Będzie łatwiej później połapać jak dzielić projekt na pliki etc.
    Najlepiej z tego wszystkie nauczyć się jak robić proste "skrypty" makefile.
  • #9
    tmf
    Moderator Mikrokontrolery Projektowanie
    Ty-grysek napisał:

    to skąd kompilator będzie wiedział że trzeba użyć irmp.c?


    Bo ten plik dodajesz do projektu.
    simw napisał:
    Kompilator będzie wiedział, bo w Eclipse "jest automat", który kompiluje każdy plik .c do pliku obiektowego .o.

    O ile Eclipse nie jest jakimś dziwolągiem (nie znam Eclipse), to ten automat to jest Makefile tworzony przez IDE na podstawie stworzonego projektu. Czyli plik c trzeba najpierw do tego projektu wstawić i dopiero wtedy się "magicnzie" skompiluje. Niesądzę, aby Eclipse kompilowało i linkowało z automatu wszystkie pliki w danym katalogu, bo byłoby to lekko bez sensu.
  • #10
    simw
    Poziom 23  
    tmf napisał:
    O ile Eclipse nie jest jakimś dziwolągiem (nie znam Eclipse), to ten automat to jest Makefile tworzony przez IDE na podstawie stworzonego projektu.

    Wg mnie właśnie tak się dzieje, ale specem od Eclipse tez nie jestem, jedynie użytkownikiem
    tmf napisał:
    Czyli plik c trzeba najpierw do tego projektu wstawić i dopiero wtedy się "magicnzie" skompiluje. Niesądzę, aby Eclipse kompilowało i linkowało z automatu wszystkie pliki w danym katalogu, bo byłoby to lekko bez sensu.

    Wg mnie dokładnie tak robi - "włożenie" dowolnego pliku, choćby przez kopiuj-wklej do katalogu głównego projektu "dodaje" plik .c do kompilacji. Jak dla mnie to duże ułatwienie, istniej oczywiście opcja "Exclude", która pozwala każdy plik .c "wyrzucić" z kompilacji, a zarazem linkowania. Niemniej jednak domyślnie co wrzucimy .c do katalogu głównego i dowolnego podkatalogu to jest poddawane kompilacji i linkowaniu.

    Dodano po 54 [minuty]:

    simw napisał:
    Oczywiście, że sprawdziłem. To była pierwsza rzecz Gdy będę w domu to podrzucę gotowy projekt.

    Sprawdziłem też jak zadziała z plikiem makefile, prosto z "szablonu"
    Kod: c
    Zaloguj się, aby zobaczyć kod

    Jeśli zrobię po swojemu, to muszę określić jakie pliki biorę pod uwagę przy kompilacji:
    Kod: c
    Zaloguj się, aby zobaczyć kod


    Jeśli chiałbym po Twojemu to mamy:
    Kod: c
    Zaloguj się, aby zobaczyć kod


    Plik main.hex wychodzi dokładnie taki sam co do wielkości, ale mamy po "książkowemu", a lepiej pisząc "po prostu zgodnie ze sztuką i sensem programowania w C"
  • #11
    Ty-grysek
    Poziom 10  
    [quote="simw"]
    tmf napisał:

    Wg mnie dokładnie tak robi - "włożenie" dowolnego pliku, choćby przez kopiuj-wklej do katalogu głównego projektu "dodaje" plik .c do kompilacji. Jak dla mnie to duże ułatwienie, istniej oczywiście opcja "Exclude", która pozwala każdy plik .c "wyrzucić" z kompilacji, a zarazem linkowania. Niemniej jednak domyślnie co wrzucimy .c do katalogu głównego i dowolnego podkatalogu to jest poddawane kompilacji i linkowaniu.


    Nie rozumiem idei takiego rozwiązania, w którym biblioteki nie są podłączane jawnie w kodzie programu lecz w pliku konfiguracyjnym charakterystycznym dla danego kompilatora. Jest to rozwiązanie:
    1. niezgodne ze strukturą języka C++ (!),
    2. słabo przenośne pomiędzy różnymi kompilatorami.
    Ktoś znający język C++ a nie znający danego kompilatora jako narzędzia nie będzie w stanie przeanalizować takiego programu, chyba że się domyśli że dany plik ".c" też należy do projektu - wszak to, że plik należy do projektu, nie wynika z kodu programu a z pliku konfiguracyjnego kompilatora.

    Zapewne mój tok rozumowania jest nieco łopatologiczny. Poprawcie mnie jeśli się mylę.
  • #12
    simw
    Poziom 23  
    Ty-grysek napisał:
    Nie rozumiem idei takiego rozwiązania, w którym biblioteki nie są podłączane jawnie w kodzie programu lecz

    A ja chyba rozumiem, po co dodawać plik źródłowy skoro ktoś nie chce z niego korzystać, dlatego domyślnie jest poddawany kompilacji i linkowaniu. Dzięki właśnie plikom źródłowym łatwiej dzielić projekt na "podprojekty" i tworzyć tzw. "biblioteki", aby łatwiej je przenosić między projektami.
    Wg mnie mylisz w tym momencie pojęcie "biblioteki". Generalnie z punktu widzenia C, tak myślę, biblioteka to nie jest wcale para ".c i .h". To takie dość popularne nazewnictwo, ale niezgodne z założeniami C. Biblioteka to wstępnie skompilowany "obiekt", który należy dołączyć do "projektu" przy pomocy linkera, ale nie w ten sposób jak konsolidowane są obiekty .o. Dlatego w opcjach gcc są takie jak, daję z głowy - "-L" czy też "-l", które tyczą się "opcji bibliotecznych".

    Dodatkowo podział na pliki nagłówkowe oraz źródłowe to "czyste założenie języka C", choć czasami mam wrażenie jakby ta "idea" powstała dopiero na etapie ewolucji C - oczywiście to tylko moja hipoteza, raczej sam jej nie potwierdzę ani nie zaprzeczę :)
    W takim Pascalu to chyba nawet nie ma takiej możliwości - ale mogę oczywiście się mylić.

    Co do reszty Twojego postu, to niestety programowanie, nazwę je "rozmyślne" ma właśnie na tym polegać, że programista wie co ma robić, jakie ma podać pliki, jakie opcje, katalogi biblioteki itd.
    Niestety w tym temacie chyba pokutuje "casus arduino", gdzie standardowy użytkownik (specjalnie nie napisałem programista) właściwie to nie wie co się dzieje pod spodem, a takie "wszystkomające IDE" niestety zwykle tylko rozleniwiają i ogłupiają nieco.

    Niezgodne z C/C++ to chyba właśnie jest to dołączanie plików źródłowych do źródłowych, ale nie podam dlaczego "niezgodne ze strukturą C++" - bo nie wiem :)
  • #13
    tmf
    Moderator Mikrokontrolery Projektowanie
    simw napisał:
    Wg mnie dokładnie tak robi - "włożenie" dowolnego pliku, choćby przez kopiuj-wklej do katalogu głównego projektu "dodaje" plik .c do kompilacji.

    Ale co rozumiesz pod pojęiem katalogu głównego projektu? Jeśli jest to struktura tworzona przez IDE to jest to dokładnie to o czym mówię, czyli dodanie projektu do IDE.
    Ty-grysek napisał:
    Nie rozumiem idei takiego rozwiązania, w którym biblioteki nie są podłączane jawnie w kodzie programu lecz w pliku konfiguracyjnym charakterystycznym dla danego kompilatora.

    Nie ma czegoś takiego jak plik konfiguracyjny charakterystyczny dla kompilatora. Standardem jest Makefile, które jest interpretowane przez make lub jego odmiany, w efekcie czego kompilator kompiluje poszczególne pliki. Kompilator na raz widzi tylko jeden plik, poskładanie tego w całość to funkcja linkera.
    W efekcie IDE generuje Makefile na podstawie np. własnego pliku przechowującego konfigurację projektu, utworzonego i charakterystycznego dla IDE.
    Ty-grysek napisał:
    1. niezgodne ze strukturą języka C++ (!),
    2. słabo przenośne pomiędzy różnymi kompilatorami.

    Po pierwsze, mówimy o c, a nie C++, chociaż akurat dla tych rozważań nie ma to znaczenia. Język nie definiuje struktury logicznej projektu, jeszcze raz - trzeba odróżnić kompilator od konsolidatora i IDE.
    2. Tak, plik projektu charakterystyczny dla IDE jest kompletnie nieprzenośny. Jest to cena, którą płacimy za wygodę. To co jest przenośne to makefile generowany przez IDE w celu kompilacji i konsolidacji projektu.
    Ty-grysek napisał:
    Ktoś znający język C++ a nie znający danego kompilatora jako narzędzia nie będzie w stanie przeanalizować takiego programu, chyba że się domyśli że dany plik ".c" też należy do projektu - wszak to, że plik należy do projektu, nie wynika z kodu programu a z pliku konfiguracyjnego kompilatora.

    Jeszcze raz - nie ma czegoś takiego jak plik konfiguracyjny kompilatora, przynajmniej w sensie o w jakim piszesz. Makefile ma się nijak do kompilatora, podobnie jak plik konfiguracji projektu tworzony przez IDE.
    Reasumując:
    - pliki c należy dodać do projektu w IDE, a wtedy zostaną skompilowane i zlinkowane w całość.
    - nie należy robić #include "plik.c" - include służy do załączania plików nagłówkowych, a nie plików źródłowych c. Takie nadużywanie tej dyrektywy prekompilatora jakkolwiek dorażnie rozwiązuje niektóre problemy, tworzy inne i tak się po prostu nie robi.
  • #14
    simw
    Poziom 23  
    tmf napisał:
    Ale co rozumiesz pod pojęiem katalogu głównego projektu? Jeśli jest to struktura tworzona przez IDE to jest to dokładnie to o czym mówię, czyli dodanie projektu do IDE.

    Tak to struktura projektu Eclipse, która pozwala na automatyzm, o którym pisałem.
  • #15
    Tumiwisizm
    Poziom 25  
    Ty-grysek napisał:
    Na życzenie @Tumiwisizm film demonstrujący działanie:
    No i super. Fajne urządzonko. Podziwiam osoby, którym chce się coś takiego programować. Płytkę to jeszcze zaprojektuję i złożę, ale żeby to oprogramować to wątpię żebym dał radę. I do tego @Ty-grysek zrobił to na pilota (a to też wymagało sparowania), bo można by do takiego oświetlenia użyć jedynie Sonoff Basic Wi-fi i telefonu - pójść na łatwiznę. Ode mnie ponownie plus!
  • #16
    Ty-grysek
    Poziom 10  
    @tmf - dzięki za obszerne wyjaśnienie. Wychowałem się na Borland Delphi i chyba stąd wynika moje "skrzywienie".

    A tak na swoje usprawiedliwienie - źródła tak jak załączyłem są gotowe do uruchomienia nawet dla kogoś niedoświadczonego. Patrzę ze swojej perspektywy - gdybym dostał tego typu kod programu przygotowany zgodnie ze sztuką - miałbym poważny problem żeby go uruchomić. Konkretnie w opisywanym programie: poprawa #include "irmp.c" na zgodne z dokumentacją #include "irmp.h" powoduje że Atmel Studio nie kompiluje projektu i zgłasza błędy braku definicji zawartych w pliku irmp.c. A w makefile stoi wyraźnie: "Automatically-generated file. Do not edit!", więc zapewne biblioteki trzeba podłączyć do projektu w jakiś inny magiczny sposób i tutaj właśnie odpadłem... Ale i tak nie przekonacie mnie do Eclipse :-)
  • #17
    tmf
    Moderator Mikrokontrolery Projektowanie
    Ty-grysek napisał:
    Patrzę ze swojej perspektywy - gdybym dostał tego typu kod programu przygotowany zgodnie ze sztuką - miałbym poważny problem żeby go uruchomić. Konkretnie w opisywanym programie: poprawa #include "irmp.c" na zgodne z dokumentacją #include "irmp.h" powoduje że Atmel Studio nie kompiluje projektu i zgłasza błędy braku definicji zawartych w pliku irmp.c. A w makefile stoi wyraźnie: "Automatically-generated file. Do not edit!", więc zapewne biblioteki trzeba podłączyć do projektu w jakiś inny magiczny sposób i tutaj właśnie odpadłem...

    I poprawnie pisze, gdyż w nagłówku są tylko deklaracje, w pliku c (źródłowym) są ich definicje. Skoro nie dodałeś do projektu pliku c, to nie został on skompilowany (nie ma go też w automatycznie utworzonym makefile). Czyli w AS musisz dodać ten plik c do projektu (add files) i sprawa się rozwiąże. Wtedy tez powstanie prawidłowy makefile. W efekcie możesz załączyć cały projekt dla AS, a dla osób, które nie używają AS wystarczy, że wpiszą make <Makefile> i też im się to skompiluje poprawnie bez AS. Generalnie jeśli AS nie jest w stanie poprawnie skompilować projektu, a makefile odzwierceidla strukturę projektu, to znaczy, że dopóki nie poprawisz projektu, to i makefile będzie błędny.

    Dodano po 2 [minuty]:

    Ty-grysek napisał:
    więc zapewne biblioteki trzeba podłączyć do projektu w

    Też tak dla jasności - to o czym piszesz to nie są biblioteki. Biblioteką w c, jak już napisano, jest prekompilowany kod - plik obiektowy, który jest zamieszczony w bibliotece o rozszerzeniu lib. Biblioteka nie jest więc ponownie kompilowana, a jedynie konsolidowana z resztą programu. W związku z tym dodaje się do wywołania linkera. Przykłądem jest np. libm zawierająca funkcje matematyczne.
  • #18
    Ty-grysek
    Poziom 10  
    simw napisał:
    niestety programowanie, nazwę je "rozmyślne" ma właśnie na tym polegać, że programista wie co ma robić, jakie ma podać pliki, jakie opcje, katalogi biblioteki itd.
    Niestety w tym temacie chyba pokutuje "casus arduino", gdzie standardowy użytkownik (specjalnie nie napisałem programista) właściwie to nie wie co się dzieje pod spodem, a takie "wszystkomające IDE" niestety zwykle tylko rozleniwiają i ogłupiają nieco.


    Tu się nie zgodzę. Podłączając plik nagłówkowy biblioteki, która zapewne jest już skompilowana programista może nawet nie zobaczyć źródeł na oczy i nie musi wiedzieć co się dzieje w środku. Wcale nie mówię że to jest złe. Podłączenie irmp.c po mojemu wymagało z moje strony przejrzenia i pobieżnego zrozumienia zawartości. Tutaj właśnie wiedziałem co robię ja i co robi kompilator* i miałem nad tym kontrolę. W razie potrzeby mógłbym nawet ingerować w kod irmp. Podkreślam jeszcze raz - nie twierdzę że tak jest lepiej!

    *i zachodziłem w głowę dlaczego w dokumentacji IRMP każą podłączyć plik nagłówkowy...
  • #19
    simw
    Poziom 23  
    Ty-grysek napisał:
    Tutaj właśnie wiedziałem co robię ja i co robi kompilator* i miałem nad tym kontrolę.

    Jednak z toku "sedna opisu problemu" ciężko wywnioskować, że jednak "kontrolowałeś temat". Na pewno nie pod kątem AtmelStudio, skoro był problem z jednym plikiem, który kładł poprawność działania w ogólności, bardziej to wyglądało jak "na chybił trafił" z tym #include - oczywiście to tak z perspektywy czytającego wątek - a no i bagaż z Delphi raczej nie pomagał.

    Mam nadzieję, że przećwiczysz to co na koniec podpowiedział tmf, żeby jednak udało się stworzyć poprawny projekt dla AtmelStudio. Myślę, że w takiej formie kod źródłowy jaki zaproponowałeś będzie "obciążeniem" dla "przeciętnego zjadacza C". W tym temacie sam nie pomogę, bo parafrazując Ciebie "Ale i tak nie przekonacie mnie do AtmelStudio". :)
  • #20
    Darek0026
    Poziom 19  
    Cześć, bardzo fajny projekt podoba mi się.

    A teraz sprowadzamy na ziemie. Zrobiłeś trochę tak jak chińczyk. Wysokie napięcie - a ścieżki blisko siebie.
    Jeżeli chcesz użyć tego w domu to prosisz się o pożar, powinieneś zastosować złącza o rozstawie nóżek 7.5mm minimum.
    Plus oczywiście wycięcia w PCB.
    Zabezpiecz przynajmniej miejsca wysoce niebezpieczne lakierem takim jak np: Plastik 70.

    Włącznik 230V sterowny pilotem IR

    Pozdrawiam.
  • #21
    Ty-grysek
    Poziom 10  
    Darek0026 napisał:
    Zabezpiecz przynajmniej miejsca wysoce niebezpieczne lakierem takim jak np: Plastik 70.


    Tak, cała płytka została spryskana lakierem PVB 16.
  • #23
    Ty-grysek
    Poziom 10  
    kilioo napisał:
    Jaki masz clearance na 230V?

    Chodzi o odstęp pomiędzy ścieżkami? Nie mniej niż 1,3 mm.
    Chyba trochę mało, powinno być ze 2 mm? Od zawsze mam przesadną manię miniaturyzacji...