Elektroda.pl
Elektroda.pl
X
Please add exception to AdBlock for elektroda.pl.
If you watch the ads, you support portal and users.

Termometr z pamięcią pomiarów

linuxtorpeda 10 Oct 2021 13:42 3486 12
phoenixcontact
  • Pewnego razu żona wystraszyła się, że mogę mieć koronawirusa i nie pozwoliła mi przez tydzień wracać do domu, taka krótka kwarantanna. Tydzień ten okazał się być bardzo owocny, gdyż w tym czasie miałem okazję zbudować termometr. Czemu zbudowałem akurat termometr? Z dwóch powodów:
    - mam małe dziecko i czasem nie wiadomo, jak należy je ubrać do snu - termometr pokazuje temperatury z ostatnich 12 godzin, więc nadaje się do tego doskonale,
    - miałem na stanie kilka starych bezużytecznych mikroprocesorów PIC16F628A i nie wiedziałem, co z nimi zrobić.

    Szczegóły konstrukcji
    Termometr zbudowany w oparciu o wspomniany wyżej PIC16F628A, czujnik temperatury DS18B20 oraz wyświetlacz z kontrolerem PCD8544 lub kompatybilnym (czyli taki, jaki podobno znajdował się w starych Nokiach 5110). Do tego kilka elementów pasywnych. To tyle jeśli chodzi o elektronikę.
    Jeśli chodzi o obudowę, to mój autorski design wydrukowany na drukarce 3D (zmodyfikowany Anet A8, jeśli to kogoś interesuje). Pierwsza iteracja projektu zawsze zawiera jakieś niedociągnięcia (o nich wspomnę za chwilę), natomiast na pierwszej się skończyło, gdyż sam nie posiadam drukarki i na każdy wydruk od kolegi czekam kilka dni.

    Wrażenia z projektowania, montażu i użytkowania
    Narzekać nie mogę, działa jak należy. RAMu w mikrokontrolerze jest mało, więc rozdzielczość pomiarów w czasie wynosi godzinę (+/- kilka minut, ze względu na wybór wbudowanego generatora RC jako źródła referencyjnego czasu i design programu). Można to było zrobić lepiej, np. czas odmierzać na timerze, nie musiałbym wtedy uwzględniać zgrubnych poprawek ze względu na opóźnienia z powodu transmisji danych z czujnika temperatury, ale po pierwsze obecne rozwiązanie jest wystarczające, po drugie było najszybsze w implementacji, a po trzecie nie wiem, czy bardziej dokładna wersja zmieściłaby mi się w pamięci programu, jako że obecny program zajmuje prawie 100% ROMu.
    Montaż nie był zbyt kłopotliwy, choć trzeba przyznać, że kable wewnątrz obudowy są ułożone chaotycznie. Połączenia między wyświetlaczem a płytką bazową są zrealizowane za pomocą przewodów do płytek stykowych, reszta połączeń znajduje się na uniwersalnej PCB, gdzie zamontowany jest mikrokontroler i czujnik temperatury. Kabelki są trochę za długie, więc lekko rozpierają od środka obudowę - na szczęście śrubki trzymają całość w kupie.
    Wspominałem wcześniej o problemach z obudową - po części wynikają one z doraźnego projektowania poszczególnych części projektu, jednak część z nich można by było zrobić lepiej przy aktualnym projekcie elektroniki. Otwory na śrubki mogły by być trochę mniejsze, obecnie śrubki wchodzą w nie moim zdaniem trochę ze zbyt dużym luzem. W udostępnionym projekcie ten element już poprawiłem. Drugą kwestią jest też fakt, że luty na płytce wyświetlacza napierają na przedni panel obudowy - w tej sytuacji należałoby zmienić kształt wycięcia na wyświetlacz lub zmienić grubość przedniego panelu w miejscu, gdzie luty go dotykają.
    Urządzenie nie posiada żadnych przycisków, co jest dla mnie zaletą - lubię bezobsługowość. Zasilane jest napięciem 5V z jakiejś starej ładowarki, których sporo wala mi się po mieszkaniu.
    Nie polecam stosowania PIC16F628A i innych opartych o architekturę PIC16 do nowych urządzeń. Architektura jest przestarzała i jej wady widać od pierwszych chwil programowania na ten sprzęt (np. zachowanie w pamięci ROM pojedynczego bajtu wymaga poświęcenia 14 bitów). Płatne kompilatory Microchipa również nie powalają jakością, w dodatku ich wersje darmowe mają ograniczone możliwości optymalizacyjne, co dodatkowo pogarsza kompaktowość kodu. Do kupna też nie zachęcam, -Os (optymalizacja względem rozmiaru dostępna w komercyjnej wersji XC8) daje co najwyżej kilkuprocentową oszczędność ROMu w porównaniu do -O2 (najwyższy stopień optymalizacji w darmowej wersji).

    Termometr z pamięcią pomiarów Termometr z pamięcią pomiarów Termometr z pamięcią pomiarów

    Dokumentacja projektu (źródła, projekt obudowy)
    Wszystkie pliki projektu potrzebne do zbudowania własnej kopii znajdują się na GitHubie. Obudowa została zaprojektowana w SolveSpace, jeśli ktoś ma ochotę ją wydrukować, to w pierwszej kolejności należy wyeksportować modele do formatu STL. Kod źródłowy firmware'u został napisany w C i mogę zaświadczyć, że buduje się poprawnie w Microchip MPLAB XC8 C Compiler V2.31. Schemat ideowy narysowałem w KiCADzie, ale wyeksportowałem go też do PDFa, więc na potrzeby montażu nie ma konieczności instalacji KiCADa.

    Kosztorys
    Trudno mi szacować koszt wykonania, gdyż sporo komponentów kupowałem kilka lat temu bądź są z odzysku. Myślę, że 50 zł wystarczy do złożenia duplikatu, w razie wątpliwości zachęcam do przejrzenia dokumentacji projektu i sporządzenia kosztorysu na własną rękę.

    Cool? Ranking DIY
    About Author
    linuxtorpeda
    Level 26  
    Offline 
    Has specialization in: zbrojarz betoniarz
    linuxtorpeda wrote 715 posts with rating 151, helped 88 times. Been with us since 2014 year.
  • phoenixcontact
  • phoenixcontact
  • #4
    pier
    Level 24  
    Jaki jest sens wypuszczania całej ramki wyświetlacza na front? Nie Mogłeś zmniejszyć okna wyświetlacza do rozmiaru samego szkła? To samo ze śrubkami mocującymi, Mogłeś zrobić mocowanie od wewnątrz.
  • #5
    linuxtorpeda
    Level 26  
    pier wrote:
    Jaki jest sens wypuszczania całej ramki wyświetlacza na front?

    Chyba to głównie kwestia estetyki, mi nie przeszkadza, a nawet mi się podoba. Poza tym wyświetlacz jest stabilniejszy w poziomie w tej pozycji, śrubki jedynie go dociskają do spodniej części obudowy.

    pier wrote:
    Nie Mogłeś zmniejszyć okna wyświetlacza do rozmiaru samego szkła?

    Chyba mogłem, ale po co. Poza ww. wadami dochodzą jeszcze problemy z tym, że sam wyświetlacz w ramce jest ruchomy (taki urok tego modułu) oraz że wyświetlacz z ramką nie lubią być dociskane od góry, niby można by było temu jakoś zaradzić, ale projektując obudowę "na czas" chciałem mieć jak najmniej krytycznych wymiarów w projekcie.

    pier wrote:
    To samo ze śrubkami mocującymi, Mogłeś zrobić mocowanie od wewnątrz.

    Śrubki mocują głównie spód obudowy do frontu. Moim zdaniem musiały być poprowadzone albo z przodu, albo z tyłu obudowy, ale zawsze po zewnętrznej części, jak inaczej złożyć obudowę w całość? Mógłbym zastosować zatrzaski, ale j.w. - im mniej krytycznych wymiarów tym lepiej. Zatrzaski nie wychodzą zbyt dobrze przy takich tolerancjach, jakie gwarantuje druk 3D FDM, a powtórzę raz jeszcze - chciałem uniknąć kolejnych iteracji.
  • #7
    linuxtorpeda
    Level 26  
    Zakładam, że śrubki byłyby wkręcane od strony czerwonej. Powyższe rozwiązanie ma wadę, o której już wspominałem, mianowicie i tak potrzebowałbym kolejnych śrubek do złączenia dwóch części obudowy.
    Gdyby jednak zmienić trochę powyższy pomysł i wkręcać śrubki od frontu, to musiałbym używać dłuższych śrubek niż obecnie - niby nie problem, ale musiałbym je kupić. Krótsze śrubki są powszechniejsze, więc miałem kilka wcześniej.

    Generalnie zgadzam się, że mogłoby to być wszystko zrobione estetyczniej, trwalej itd., więc jest tu pole do popisu jeśli chodzi o poprawę obudowy czy elektroniki. Osobiście wolałem ograniczyć koszty i czas potrzebny na stworzenie urządzenia, nie wspominając o tym, że pierwsza funkcjonalna wersja mnie zadowoliła. Jeśli ktokolwiek miałby ochotę na dalszy rozwój czy inne modyfikacje, to zapraszam.
  • #9
    linuxtorpeda
    Level 26  
    Ale za to masz 2x więcej śrubek potrzebnych do złożenia i tył obudowy nie jest płaski, co może utrudnić zawieszenie na ścianie (po to jest ta dziura z tyłu). Tego ostatniego nie jestem pewien, bo na rysunku chyba widać, że zrobiłeś wpusty na główki śrubek, tyle że albo te wpusty będą poziome, co spowoduje problemy podczas wydruku, albo pod kątem do tylnej powierzchni obudowy, więc śrubki nadal będą wystawać, tyle że mniej.
    Możesz powiedzieć, że w takim przypadku można dać wkręty ze stożkową główką i będziesz mieć rację, ale musiałbym te wkręty kupić.

    Ogólnie miło, że chce Ci się prezentować swoje pomysły w formie renderów.
  • #10
    Chivo
    Level 25  
    Super projekt, wielkie dzięki za soft. Czy kod do obsługi DS18B20 jest w miarę uniwersalny. Próbowałem go uruchomić na PIC16F872 według przykładów z książki o PIC16F ale program nie działał.
  • #11
    linuxtorpeda
    Level 26  
    Chivo wrote:
    Czy kod do obsługi DS18B20 jest w miarę uniwersalny.

    Powinien taki być, natomiast nawet taki prosty kod może wymagać poprawek zależnych od architektury mikrokontrolera. Na używanym w tym projekcie też spodziewałbym się problemów, gdybym wykorzystywał pozostałe piny portu B - zauważ, że pin do 1-wire to jedyny pin używany na tym porcie. Powodem jest mechanizm RMW (Read-Modify-Write) przy dostępie do portu, bezpośrednia manipulacja bitami jak na np. AVR jest wtedy w zasadzie niemożliwa. Stąd też manipulując pinami na porcie A korzystam ze zmiennej "shadowA" pośredniczącej w operacjach. Poza tym kod do inicjalizacji pinów też będzie customowy.

    Z tego co zdążyłem zauważyć, PIC16F872 jest podobny (tj. ta sama architektura CPU i większość peryferiów), więc to, co napisałem powyżej, też się do niego stosuje.
  • #12
    Chivo
    Level 25  
    Cześć. Piszesz o wadach PIC16F. Chciałbym poznać trochę mikrokontrolery PIC. Jakie modele i środowisko IDE polecasz?
  • #13
    linuxtorpeda
    Level 26  
    Model mikrokontrolera, niezależnie od producenta, dobiera się pod konkretny projekt, biorąc pod uwagę jego możliwości i budżet. Nie przywiązywałbym się więc do konkretnego modelu.
    Gdybym chciał poznać każdą rodzinę mikrokontrolerów PIC (tak, to są odrębne rodziny z odmiennymi zestawami instrukcji), kupiłbym po jednym przedstawicielu każdej z nich. Listę rodzin masz chociażby na wiki.
    To powiedziawszy, ciekawym następcą/zastępcą PIC16 jest PIC18, z normalnym (tj. 16-bitowym zamiast 14-bitowym) słowem pamięci kodu programu, rozkazami do odczytu i zapisu pamięci kodu programu oraz przede wszystkim szerszym asortymentem peryferiów. Nie czuję się na tyle kompetentny, by polecać konkretne modele, ale możesz zerknąć na PIC18F4550, PIC18F25K80 czy PIC18F14K50 i porównać z modelami PIC16, które znasz. W zasadzie to PICów nie polecam w ogóle poza specyficznymi zastosowaniami związanymi z ultra niskim poborem energii (np. można je spotkać w domofonach), chociaż nawet i w tym przypadku mają konkurencję w postaci STM8.

    Nie korzystam z żadnego IDE do PICów, choć raz zdarzyło mi się z MPLAB (stara wersja bez X w nazwie) przy zabawie z PIC24F. Amatorsko używam Geany i Scite jako edytorów tekstu i GNU Make + XC8 jako toolchaina do budowania. Zdarzało mi się używać SDCC, ale generuje kod o niskim stopniu optymalizacji, poza tym nigdy nie mam pewności, czy generuje w 100% poprawny kod, jako że miałem przygody z SDCC w tym zakresie. Binarki flashuję za pomocą pk2cmd i PicKit 2. Pracuję na Linuxie.