Regulator PID do ekspresu do kawy

Chciałbym zaprezentować projekt regulatora PID do ekspresu do kawy. Używany jest z ekspresem La Pavoni Domus Bar, ale w zasadzie może sterować dowolnym ekspresem lub jakimkolwiek obiektem grzewczym/chłodniczym o mocy do ~ 1.5kW.

Motywacją do wykonania urządzenia była spora histereza fabrycznego regulatora dwustawnego (prawie 10°C) i idące za tym problemy z powtarzalnością procesu parzenia.

W skrócie założenia projektowe:
- ograniczenie ingerencji w ekpres do minimum,
- bezpieczeństwo użytkowania,
- wbudowane sterowanie grzałką, bez żadnych zewnętrznych styczników i SSR,
- sterowanie zaworem szybkiego spustu - umożliwienie "pre-infussion",
- sterowania czasem załączenia pompy, możliwość profilowania ciśnienia w przyszłości,
- wbudowany sekundnik do odmierzania czasu ekstrakcji, zegar RTC,
- wizualizacja nastaw i parametrów procesu na wyświetlaczu ciekłokrystalicznym,
- zmiany nastaw z poziomu menu, w czasie rzeczywistym,
- stylistyka zbliżona do stylistyki ekspresu.

Hardware
Sterownik posiada 3 optoizolowane wyjścia AC z załączaniem w zerze, w tym jedno wysokoprądowe do sterowania grzałką, oraz 1 optoizolowane wejście 230V.

Człon pomiarowy oparty jest o układ MAX31855 i obsługuje termoparę typu K. W układzie zintegrowano część analogową z kompensacją zimnego końca oraz 14-bitowy przetwornik ADC z interfejsem SPI. Dodatkowo układ wykrywa przerwanie obwodu termopary oraz doziemienie i zwarcie do VCC, co okazało się dość problematyczne, o czym dalej.
Sercem układu jest mikrokontroler Atmega32A (na schemacie jest 16, ale różnią się w zasadzie tylko ilością pamięci). Główne kryteria przy wyborze to wbudowane SPI i I²C, dużo (względnie ) pamięci flash (czcionki, grafiki), zasilanie z 3.3V, timery w tym 1 z wyjściem PWM.
Układ zasilany jest z transformatora 6V, 2VA. 3.3V do układów scalonych brane jest ze stabilizatora LDO, a podświetlenie LCD zasilane jest prosto zza mostka, z dodatkową możliwością kluczowania PWM.

Schemat i PCB zrobione w Eagle (na schemacie jest Atmega16, ale różnią się w zasadzie tylko wielkością pamięci), dwustronne płytki wykonane metodą żelazkową. Z braku dostępu do HotAira, najtrudniejszym elementem do przylutowania było gniazdo wyświetlacza, odlutowane wcześniej z telefonu. Płytka panelu oraz cześć wysokonapięciowa zostały pocynowane pastą do lutowania rur miedzianych ogrzewaną palnikiem, reszta jest polakierowana. Nie obyło się bez pomyłek, stąd zwory na płytce. Zmiany są uwzględnione na schemacie.
Układ RTC DS1307 jak na razie nie jest wykorzystywany, ale część zmiennych można wynieść do RAMu podtrzymywanego bateryjnie.

Obudowa jest zrobiona z polerowanej blachy ze stali nierdzewnej, aby nie odróżniała się znacznie od ekspresu. Połączona jest z przewodem ochronnym/obudową samego ekspresu. Wszystkie przewody (poza TC) między ekspresem a regulatorem są wzięte ze starej płyty kuchennej, mają grubą izolację i są odporne na wysoką temperaturę. Jednym z głównych założen było niezniszczenie ekspresu, więc musiałem przecisnąć się istniejącymi otworami.

Software
Firmware napisany został w C (gcc + avr-libc), większość części kodu jest napisana jako nieblokująca, aczkolwiek ze względu na brak "bufora ramki" odświeżanie zawartości LCD zajmuje chwilę. Wyświetlacz LCD wzięty został z Nokii 5100, oparty jest na driverze PCF8833. Ze względu na to, że ramka ma 9bitów, pierwszy bit wysyłany jest programowo, a kolejne 8 leci już z wbudowanego SPI. Procesor chodzi na 7372800Hz, odświeżanie całego ekranu byłoby dość czasochłonne, więc gdzie tylko się da aktualizacje robione są fragmentami. Parametry procesu (u góry) oraz stan I/O (na dole) odświeżane są co 1s.

Płynność działania zapewnia podzielenie zadań rysowania i minimalizacja ich występowania. Obsługa wyświetlacza, I/O, filtracji i PID zajmuje zawsze sporo mniej niż 1 tick systemowy ~10ms.
Większość pamięci flash zajęły czcionki (8x8 i 8x16). Sporo zjada też obsługa liczb zmiennoprzecinkowych z avr-libc. W tej chwili używane są przy filtracji dolnoprzepustowej, a sam regulator operuje na int16_t, w planie jest przeróbka na stałoprzecinkowe.
Wszystkie ustawienia można zmieniać w wielopoziomowego menu, co widać na filmiku. Ze względu na typ zmiennych, w tej chwili K i Ti są typu całkowitego, co wpływa na zakres nastaw, jednak wystarcza do ustawienia stabilnego regulatora o zadowalających parametrach.

Soft + źródła będzie zamieszczony jak tylko uporam się z kwestiami licencyjnymi - część procedur obsługi LCD znalazłem w necie, ale daleko mu obecnie od wersji pierwotnej.


Wnioski, napotkane problemy
"Wszystkomający" MAX31855 okazał się trochę problematyczny, po podłączeniu uziemionego laptopa układ wykrywa doziemienie termopary, która jest przymocowana do bojlera (goła termopara - dwa zgrzane druty). Ekspres oczywiście też jest uziemiony i obwód się zamyka.
W kolejnej wersji mam zamiar optoizolować układ termopary, chyba że znajdę pasującą termoparę w obudowie z gwintem M4.

Mimo pełnej izolacji galwanicznej od sieci, wyświetlacz czasami potrafi się zawiesić od szpilek podczas wyłączania silnika pompy/młynka. Nie pomogły 2x 0,8mm blachy stalowej , skrócona do 40mm taśma między płytą główną a panelem, rozdzielenie żył sygnałowych masą, zasilanie z zewnątrz ani względnie duże pojemności przed i za stabilizatorami. Sam procesor nadal działa. Zdarza się to losowo raz na ~ 2tyg, restart załatwia sprawę. Cykliczny reset wyświetlacza z poziomu programu powoduje miganie, więc odpada.

Stała czasowa obiektu jest dość spora, a pomiar odbywa się na zewnątrz bojlera. O ile przy braku zakłóceń (parzenia kawy i napływu zimnej wody) regulacja jest na poziomie ±0.75°C wartości zadanej, to w czasie ekstrakcji zanim regulator włączy grzałkę mija kilka sekund. Ponieważ to "zakłócenie" sami świadomie powodujemy w znanym momencie, rozważam dodanie predyktora Smitha albo regulację adaptacyjną PID albo połączenie PID z regulatorem rozmytym.

Zapraszam do zapoznania się z dokumentacją, liczę na ciekawe pomysły które będzie można wdrożyć w wersji 2.0.
Więcej zdjęc, filmik z działania i bardziej szczegółowy opis urządzenia.

Film na vimeo

PID zawsze kojarzyło mi się z rzeczami ogromnymi typu kotłownia, ale nigdy z ekspresem do kawy

Taka uwaga ode mnie: trochę niedbale elementy frontu zrobione, a tak to całkiem całkiem.

Z czego wyświetlacz?

szczodros napisał:

Z czego wyświetlacz?

Wyświetlacz jest wyciągnięty z Nokii 5100 lub bardzo podobnej. W środku siedzi PCF8833 a w niektórych partiach Epson. Większość opisów w sieci dotyczy Nokii 6100/6610, jako że te modele były znacznie bardzie popularne.

Mógłbyś opisać dokładnie implementacje programową PID? Parametry regulatora PID dobrałeś metodą „prób i błędów” czy urządzenie posiada opcję samo nastrajania (jeżeli ma opcje samo nastrajania to też prosiłbym o opis)?

Możesz dokładniej opisać jak zrobiłeś PID, jak to działa w wersji programowej jak wyznaczyłeś nastawy? Na uczelni mieliśmy jedynie mega skomplikowane obliczenia, z których nikt na sali nic nie kumał

AVE...

Ja miałbym taką drobną sugestię jeno: obsługę wyświetlacza/menu przenieś do drugiego mikrokontrolera. W ten sposób oba będą mogły pracować z maksymalną wydajnością, unikniesz migotania i problemów z aktualizacją zawartości. Próbowałeś dać filtr LC dolnoprzepustowy w zasilaniu? Pojemności też duże być nie muszą, byle LowESR i do tego jakiś kondensator ceramiczny równolegle...

Olo999 napisał:

Mógłbyś opisać dokładnie implementacje programową PID? Parametry regulatora PID dobrałeś metodą „prób i błędów” czy urządzenie posiada opcję samo nastrajania (jeżeli ma opcje samo nastrajania to też prosiłbym o opis)?

leonow32 napisał:

Możesz dokładniej opisać jak zrobiłeś PID, jak to działa w wersji programowej jak wyznaczyłeś nastawy? Na uczelni mieliśmy jedynie mega skomplikowane obliczenia, z których nikt na sali nic nie kumał

Implementacja jest tak prosta jak sam wzór - średnia ważona z 3 elementów. W literaturze spotyka się trochę wariantów samego wzoru, i dla każdego inaczej wyglądają nastawy i to może powodować zamieszanie.
Próbowałem różne algorytmy, tu dość fajnie opisane są typy regulatorów. Zasadnicza różnica polega na sposobie uwzględniania wartości zadanej przy wyliczaniu błędu dla poszczególnych członów. Główną trudnością było takie przeskalowanie danych, aby nie było dużych błędów zaokrągleń przy mnożeniu i dzieleniu, więc dane wejściowe mnożę razy stałą, a wynik dzielę. Niestety zmiana stałej wpływa na wartości nastaw. Same parametry też skaluję, np K.r to int16_t, ale dziele go przez 10 aby mieć 1 miejsce po przecinku, stąd podejście do regulatora z danymi w typie "double" (32bit na AVR). To jednak zjada olbrzymie ilości pamięci i jest w fazie testów.

W tej chwili zaimplementowałem książkowy przykład, o ile dobrze pamiętam z Teorii Sterowania Janusza Kowala. Wzór był na regulator ciągły, oczywiście działania trzeba doprowadzić do postaci dyskretnej żeby dało się to liczyć numerycznie.




Nastawy dobieram metodą "prób i błędów". Zaczynałem od metod Z-N i innych znalezionych, ale ze względu na wpływ skalowania na nastawy oraz to, że przykłady w książkach dotyczą regulatorów ciągłych na razie porzuciłem tą drogę. Zapewne w przyszłości dodam automatyczne strojenie, w tej chwili takiego nie ma.

Urgon napisał:

Ja miałbym taką drobną sugestię jeno: obsługę wyświetlacza/menu przenieś do drugiego mikrokontrolera. W ten sposób oba będą mogły pracować z maksymalną wydajnością, unikniesz migotania i problemów z aktualizacją zawartości. Próbowałeś dać filtr LC dolnoprzepustowy w zasilaniu? Pojemności też duże być nie muszą, byle LowESR i do tego jakiś kondensator ceramiczny równolegle...

I tak nie jestem w stanie szybciej odświeżać ekran niż kilka FPS, nawet gdyby to było jedyne zadanie tego procesora, chyba że zapiąłbym to tego jakiegoś ARMa, co trochę mija się z celem. Sama obsługa LCD zajmuje relatywnie dużo czasu, ale nie wpływa negatywnie na obsługę procesu zbierania, filtrowania i sterowania.
Filtr LC rozważę, nie próbowałem. Układ na początku testowałem z zasilacza zewnętrznego zanim wlutowałem trafo, problem też się pojawiał - nawet częściej.

Drobne uwagi:
- C15 z drugiej strony L1.
- w przyszłości nie żałuj kondensatorów dla poszczególnych pinów zasilających, bo grosze kosztują, a pewność pracy urządzenia znacznie zwiększają.

Za cenę MAX31855 można kupić cały kompletny chiński kontroler PID na ebayu.
Do twojego zastosowania spokojnie wystarczyłby lm358 + adc atmegi czy choćby tak jak w chińskich PIDach przemiana V na F i licznik w procesorze.

Maxa można mieć z sample ze free



Można prosić o kod?

Kod postaram się wrzucić w najbliższych dniach, tylko muszę w nim zrobić porządki.

rasz napisał:

Za cenę MAX31855 można kupić cały kompletny chiński kontroler PID na ebayu.
Do twojego zastosowania spokojnie wystarczyłby lm358 + adc atmegi czy choćby tak jak w chińskich PIDach przemiana V na F i licznik w procesorze.

Masz rację, ale chiński czy też inny gotowy PID, pomijając walory edukacyjne, nie da możliwości realizacji dodatkowych funkcji, które wymieniłem w założeniach projektowych, a chciałem wszystko zmieścić w jednym urządzeniu, aby uniknąć spotykanego w sieci obudowywania ekspresu o baterię PIDów, SSRów i zegarków

MAX31855 dostępny jest (był) w samplach Maxima, poza tym do jednostkowej produkcji jego cena nie jest jakaś odstraszająca (43zł netto w sklepie internetowym). Jest też tańszy MAX6675, ale nie jest zalecany do nowych konstrukcji.
Gdybym miał dostęp do termometru referencyjnego na potrzeby kalibracji, to może próbowałbym robić tor pomiarowy na własną rękę, a tak to ilość pośrednich stopni wprowadzających błąd pomiaru jest na tyle spora, że trudno byłoby nawet określić jaka jest dokładność pomiaru. Co prawda można kalibrować dwupunktowo w wodzie z lodem i gotującej się, ale wyliczenie poprawek na wysokość npm i ciśnienie też nie jest obarczona błędem.
Potencjalny błąd kompensacji zimnego końca, wzmacniacza, wbudowanego ADC i obliczeń wewnątrz uC spowodował, że wybrałem gotowe urządzenie o znanych parametrach.

Taki wyświetlacz który zastosowałeś, pewnie zajmuje sporo pamięci.

Osobiście dałbym zwykły wyświetlacz 2*16 znaków do tego ATmega32, oraz algorytm regulatora ASP (to taki bardzo inteligentny regulator)

Podoba mi się Twój projekt. Porządne wykonanie.
Jednak uważam, że wyświetlacz jest nietrafnie dobrany do konstrukcji. Mógł być spokojnie czarno-biały. W jakim trybie (ilu bitowym) sterujesz wyświetlacz?
Druga sprawa to prowadzenie masy. Wylewka masy nie załatwia wszystkich problemów. Zwracaj uwagę w jaki sposób przecinasz poligon masy ścieżkami.
Więcej kondensatorów odsprzęgających zasilanie też nie zaszkodzi. Szczególnie bardzo blisko mikrokontrolera nic nie ma.
O prowadzeniu masy bardzo dobre artykuły są na elektrodzie.
Stosowanie dodatkowych procesorów często nie ma sensu. Jeden, a dobrany prawidłowo.

Powodzenia w realizacji kolejnych konstrukcji. Pozdrawiam.

kedzi1 napisał:

Jednak uważam, że wyświetlacz jest nietrafnie dobrany do konstrukcji. Mógł być spokojnie czarno-biały.

Kolor wyświetlacza to rzecz gustu.

kedzi1 napisał:

W jakim trybie (ilu bitowym) sterujesz wyświetlacz?

Masz zaznaczone na schemacie i dodatkowo autor napisał:

tomekgl napisał:

Wyświetlacz LCD wzięty został z Nokii 5100, oparty jest na driverze PCF8833. Ze względu na to, że ramka ma 9bitów, pierwszy bit wysyłany jest programowo, a kolejne 8 leci już z wbudowanego SPI.

Dobrymi układami do obsługi termopar są też kostki serii LMP90100 National Semiconductor (TI). Można do jednego podłaczyć 3 termopary + jakiś czujnik typu LM35 do kompensacji zimnego końca. Tylko temperaturę trzeba wyliczyć na procesorze (mały problem, albo tablica wartości albo wiwlomiany NIST). Również dostępne jako sample.

Analog Devices również produkuje specjalizowany układ AD7715, sprawuje się bardzo dobrze.
BTW, co to za regulator ASP wiecie może, pierwszy raz słyszę ?

Chodzi o to, że wyświetlacz kolorowy bardzo obciąża procesor 8 bitowy. Mógł by być graficzny tylko cz-b. Np. podobny do tego z Nokii 3310. Różnica w wydajności jest kolosalna.

Druga sprawa dotyczy tego, że ramka dla zastosowanego wyświetlacza jest zawsze 9-bitowa. Natomiast jednemu pikselowi może odpowiadać 8, 12 lub 16 (jak dobrze pamiętam) bitów. Oczywistym jest, że praca w trybie 8 bitów na piksel zwiększa wydajność.

konrad.nowik napisał:

Taki wyświetlacz który zastosowałeś, pewnie zajmuje sporo pamięci.

Jeżeli chodzi o flash, to poszło na czcionki ~4KB.
RAMu nie zajmuje prawie w ogóle, poza kilkoma zmiennymi w których trzymam ostatnią pozycję kursora itp. Wszystkie obiekty rysuję w trakcie obsługi powiązanej funkcjolności, cały ekran czyszczony jest tylko przy starcie. Aby zaimplementować bufor ramki potrzebaby 128*128*12/8=24,5kB RAMu, na co oczywiście nie ma miejsca.
Ewentualnie w pamięci trzymać 16*16 znaków 8x8 pikseli w trybie tekstowym, co daje 256B + informacje o kolorze, jednak tracimy możliwości rysowania grafiki.
Osobiście dałbym zwykły wyświetlacz 2*16 znaków do tego ATmega32, oraz algorytm regulatora ASP (to taki bardzo inteligentny regulator)
W praktyce jednym z powodów dla których odrzuciłem wyświetlacze 2x8/2x16 to to, że nawet te z małymi ekranami mają duże ramki dookoła i duże PCB. Nie dałoby się tego wcisnąć do takiej obudowy wraz z przyciskami obok.Ekran z telefonu ma marginesy rzędu 5mm.
Odnośnie regulatora ASP, możesz podać jakieś linki? Wyniki na frazę 'regulator ASP' lub 'ASP controller' w większości prowadzą do podstron napisanych w .asp

kedzi1 napisał:

.. Mógł być spokojnie czarno-biały. W jakim trybie (ilu bitowym) sterujesz wyświetlacz?

Czarno-biały mógłby też być, ale miałem akurat kolorowy Poza tym chciałem zachować sobie możliwości rozwoju, a nuż się przyda. W gotowych PIDach SP jest innym kolorem a PV innym, też chciałem to rozróżnić.
Steruję w trybie 12bitowym. Zapewne 8bitowy dałby 33% wzrostu szybkości, ale nie jest w tej chwili tak źle.

@Olo999:
Tryb transmisji to jedno, on jest 9bitowy (bit oznaczający dane/komendy + 8bitów danych).
Tryb kodowania kolorów to inna sprawa, ten wyświetlacz obsługuje tryb 8/12/16bitów. Ja używam 12bitowego, każdy kolor ma 4bity.

kedzi1 napisał:

Druga sprawa to prowadzenie masy. Wylewka masy nie załatwia wszystkich problemów. Zwracaj uwagę w jaki sposób przecinasz poligon masy ścieżkami.
Więcej kondensatorów odsprzęgających zasilanie też nie zaszkodzi. Szczególnie bardzo blisko mikrokontrolera nic nie ma.

Zazwyczaj daje kilka 100n przy uC i do każdego układu. Tu przy uC to chyba przeoczenie, lub wynik problemów przy układaniu ścieżek aby przelotki nie wyszły pod układami, gdyż robie je z drutu. W drugiej wersji raczej zamówie gotowe PCB, więc będzie można bardziej zaszaleć. A póki co 0603 spróbuję dolutować w istniejące ścieżki.

kedzi1 napisał:

Druga sprawa dotyczy tego, że ramka dla zastosowanego wyświetlacza jest zawsze 9-bitowa. Natomiast jednemu pikselowi może odpowiadać 8, 12 lub 16 (jak dobrze pamiętam) bitów. Oczywistym jest, że praca w trybie 8 bitów na piksel zwiększa wydajność.

Nie wiem jak to jest w przypadku AVRów, ale na STM32 użyłem USARTa, który ma właśnie 9 bitów (dwie linie: dane i zegar) i nadaje się do wysterowania tego wyświetlacza. Najlepiej mają ARMy od Texasa - można skonfigurować SPI od 4 do 16 bitów z krokiem co bit.

kubx napisał:

kedzi1 napisał:

Druga sprawa dotyczy tego, że ramka dla zastosowanego wyświetlacza jest zawsze 9-bitowa. Natomiast jednemu pikselowi może odpowiadać 8, 12 lub 16 (jak dobrze pamiętam) bitów. Oczywistym jest, że praca w trybie 8 bitów na piksel zwiększa wydajność.

Nie wiem jak to jest w przypadku AVRów, ale na STM32 użyłem USARTa, który ma właśnie 9 bitów (dwie linie: dane i zegar) i nadaje się do wysterowania tego wyświetlacza. Najlepiej mają ARMy od Texasa - można skonfigurować SPI od 4 do 16 bitów z krokiem co bit.

Ciekawy pomysł z użyciem synchronicznego uarta. W ATmedze bitów też może być 9. Niestety w AVR dla UART maksymalna częstotliwość to f_osc/8, a dla SPI f_osc/4, więc szybciej nie będzie.

Poprawka, dla trybu asynchronicznego jest f_osc/8, ale dla synchronicznego f_osc/2 - więc jest o co walczyć

Też sterowałem z STMa ten wyświetlacz przez UART. Pewien dyskomfort może dawać fakt, że przez UART bity lecą odwrotną kolejnością. Nieszczęsne SPI nie ma trybu 9bitów. Sytuacja zmieniła się w wyższych modelach. Na pewno STM32F3 ma dużo bardziej elastyczne SPI.

Co do projektu naj ważnejsze, że wszystko działa tak jak założył autor. Porady dotyczące zwiększenia wydajności na pewno się przydadzą jeżeli autor zdecyduje się rozwijać projekt.

kedzi1 napisał:

Też sterowałem z STMa ten wyświetlacz przez UART. Pewien dyskomfort może dawać fakt, że przez UART bity lecą odwrotną kolejnością. Nieszczęsne SPI nie ma trybu 9bitów. Sytuacja zmieniła się w wyższych modelach. Na pewno STM32F3 ma dużo bardziej elastyczne SPI.

Bodajże Cortex-M3 posiada instrukcję rbit, która zamienia kolejność bitów. Łącząc ją z przesunięciem bitowym można w łatwy sposób naprawić tą niedogodność. Niestety popularne Cortex-M0 (np. stm32f0discovery) nie mają tej instrukcji, a ręczna zamiana kolejności bitów jest zabójcza dla wydaności.
Cortex-M3 z tego co pamiętam ma tak samo ograniczone SPI.

tomekgl napisał:

Ciekawy pomysł z użyciem synchronicznego uarta. W ATmedze bitów też może być 9. Niestety w AVR dla UART maksymalna częstotliwość to f_osc/8, a dla SPI f_osc/4, więc szybciej nie będzie.

Słuszna uwaga, ale SPI można puścić z prędkością f_osc/2 (Bit 0 – SPI2X: Double SPI Speed Bit w SPSR)

Czemu nie dał zwykłego PID nawet noname tak samo się sprawują.

opamp napisał:

Czemu nie dał zwykłego PID nawet noname tak samo się sprawują.

Jeżeli dobrze rozumiem pytanie, to odpowiedź padła parę postów wyżej (#11). Urządzenie, oprócz funkcji regulatora ma też kilka innych, m.in. dodatkowe wyjścia na pompę i elektrozawór aby umożliwić wstępne zaparzanie (ang. pre-infussion).

Funkcja ta wymaga w tym ekspresie zablokowania zmian położenia zaworu, gdyż jest on sterowany razem z pompą z tego samego wyłącznika. Fabrycznie po każdym wyłączeniu pompy elektrozawór się otwiera i wyrównuje ciśnienie w obiegu bojlera do ciśnienia atmosferycznego wypuszczając nadmiar do zbiornika pod spodem. W przypadku zaparzania wstępnego przez pierwsze kilka sekund uruchamiamy na krótko pompę, aby lekko podnieść ciśnienie do kilku barów, a dopiero następnie włączamy ją non-stop do końca ekstrakcji.

Poza tym, w gotowych pidach noname nie ma możliwości zmiany algorytmu na inny, a tu w zasadzie można zrobić wszystko, co tylko da się zapisać w postaci kodu w C.

Sterownik ładnie komponuje się z ekspresem , dla mnie rewelacyjne wzbogacenie funkcjonalności.

Co do wyświetlacza, są wyświetlacze 2x16 Chip On Glass bez ramki i PCB . Kolega ostatnio przedstawiał tu w projekcie - https://www.elektroda.pl/rtvforum/topic2441286.html

Sam ich używam od tego czasu bo łatwiej osadzić w obudowie także polecam.

Podoba mi się to w jaki sposób zaprojektowałeś PCB.

Mogłeś trochę więcej SMD użyć i w mniejszych rozmiarach, ale to oczywiście kwestia gustu i ograniczenie pod względem trawienia.

Muszę się jednak doczepić do triaków. Przy leżącym triaku środkowy pad wysuwa się np o 0,1" i dzięki temu masz większe odległości pomiędzy ścieżkami. Przy stojącym triaku można zrobić to samo. W tym momencie pomiędzy padami masz pewnie około 0,5mm.

Jakby ten twój panel postawić w pionie to wyglądałby jak telefon

R-MIK napisał:

kubx napisał:

Niestety popularne Cortex-M0 (np. stm32f0discovery) nie mają tej instrukcji, a ręczna zamiana kolejności bitów jest zabójcza dla wydaności.

Tablica 512 bajtów załatwia sprawę.

W przypadku o którym pisaliśmy wyżej - czyli sterowanie wyświetlaczem, nawet nie trzeba odwracać bajtów podczas zapisu, wystarczy inaczej zdefiniować stałe kolorów i komend, jedynie trzeba odwrocić bity we współrzędnych. Zatem pomysł wart zaimplementowania.

krzycho123 napisał:

Co do wyświetlacza, są wyświetlacze 2x16 Chip On Glass bez ramki i PCB.

Rozważałem, faktycznie ciekawy pomysł i łatwo to zamontować, ale chciałem mieć do dyspozycji więcej wierszy niż 2.
Stąd wyświetlacz matrycowy, a taki telefon akurat miałem.

narasta napisał:

Mogłeś trochę więcej SMD użyć i w mniejszych rozmiarach, ale to oczywiście kwestia gustu i ograniczenie pod względem trawienia.

Z wyjątkiem złącz i sekcji 230V to większość jest już w SMD. To co nie jest, to głównie dlatego, że chciałem wykorzystać zapasy magazynowe
Rozmiar całej płytki determinuje głównie rozmiar złącz, gdyby nie one, na pewno dałoby się to upchnąć dużo bardziej. W kolejnej rewizji port szeregowy planuję wystawić w standardzie TTL za ADUM1201 i zastosować mniejsze złącze do ISP.
Wtedy część cyfrową wraz z prockiem można wrzucić na płytkę panelu przedniego. To pozwoli na zwiększenie odstępów miedzy elementami sekcji 230V.

narasta napisał:

Muszę się jednak doczepić do triaków. Przy leżącym triaku środkowy pad wysuwa się np o 0,1" i dzięki temu masz większe odległości pomiędzy ścieżkami. Przy stojącym triaku można zrobić to samo. W tym momencie pomiędzy padami masz pewnie około 0,5mm.

Słuszna uwaga, używałem gotowych bibliotek z Eagle.

narasta napisał:

Jakby ten twój panel postawić w pionie to wyglądałby jak telefon

Ostatnio widziałem w sieci sterownik ekspresu do kawy, z GUI na Androida. Czego to ludzie nie wymyślą...

Problem zakłóceń spróbuj rozwiazać poprzez filtr RLC na wyjściu triaków. Po 2 nie widzę warystorów. Może i teraz nie ma żadnych problemów z tym , ale w innej konstrukcji już tak.

Tak jak napisano wyżej, SPI w AVR da się puścić max z prędkością połowy zegara.
I wbrew pozorom da się uzyskać płynny obraz na wyświetlaczach graficznych kolorowych z AVR.

Dla przykładu filmik z mojej pracy inżynierskiej:
http://www.youtube.com/watch?v=-eq9wk1fJ_M
Układ napędzany przez AtMega168 20MHz, LCD w trybie 16bit, rozdzielczość 120x160.
Co lepsze, wszystkie czcionki sa zapisane na zewnętrznej pamięci 6kB pracującej na szynie I²C z prędkością 400kHz (w czasie wyświetlania czcionki są pobierane z pamięci).
Dla testu obniżyłem zegar AVR do 8MHz, tak to wygląda:
http://www.youtube.com/watch?v=GMLG1uqfi5A
Jak widać nieco straciło na płynności ale wciąż jest nieźle, tym bardziej że wąskim gardłem w tym przypadku jest zewnętrzny EEPROM.

No i jeszcze coś takiego:
http://www.youtube.com/watch?v=W6BvcwyjaUo
Tutaj rysowany jest okrąg z wypełnieniem (okrąg jest renderowany ze wzoru za każdym razem) i przesuwany co jakiś czas wraz ze zmianą koloru.
Więc jak widać niby 8bit ale da się co nieco w nich wycisnąć (ten wyświetlacz ma już rozdzielczość 160x240)