Panel powitalny

[rafal.220]

Witam
Ostatnio na elektrodzie pojawił się temat z prezentacją wizytówki.
http://www.elektroda.pl/rtvforum/topic2441286.html

Elektroniczne wizytówki są fajne, dlatego też postanowiłem zaprogramować przykładową wizytówkę na panel przedni ministerownika, którego budowa jest oparta na ATmega32.
Oczywiście programowanie takich animacji zabiera sporo pamięci, zwłaszcza jeśli one powstają w graficznym środowisku programistycznym.
W Vamgrafie ta animacja zajęła ok. 45% pamięci flash (bardzo dużo)...
http://www.youtube.com/watch?v=tgr8TB9bPdI

Obraz jest trochę nie wyraźny. (ta kamera jest chyba uczulona na tego typu wyświetlacze)

[brun]

Niezły bajer

[traxman]

Pomysł ciekawy, ale wykonanie mocno uciążliwe - biegasz z takim pudlem? 45% FLasha - masakra, cztery ekrany? Sam kontroler LCD robi to od czapy, cztery zdefiniowane znaki nie powinny tak pochłaniać zasobów. Cały program powinien zmieścić się tiny2313, a może jeszcze by wysłał do wszystkich wizytówkę po Bluetooth. Jednak te środowiska graficzne prace przyspieszają, ale niestety zasobochłonność jest przerażająca. Można by zrobić mikro wizytówkę na Mega168/328 obsługująca mały OLEDowy ekran:
http://www.ebay.de/itm/3-3V-0-96-OLED-d ... 3a77594273
on pomimo niewielkich rozmiarów jest bardzo czytelny.

Dodano po namyśle:

A tu próbka, ale nie na OLED tylko na LCD z Nokia5110, nie jest zbyt drogi, ale fajny:

DSCF4995.jpg

bez bajerów, wyklikanie programu to 10minut, środowisko Energia dla MSP430 (G2553)

[rafal.220]

biegasz z takim pudlem? 45% FLasha - masakra, cztery ekrany? Sam kontroler LCD robi to od czapy, cztery zdefiniowane znaki nie powinny tak pochłaniać zasobów.

Ale to nie jest elektroniczna wizytówka, tylko panel powitalny, tak jak sama nazwa tematu wskazuje.
Co do zajętej pamięci, no cóż muszę przyznać iż głównie wiąże się to z animacją wyświetlanego tekstu.
Czyste wyświetlenie samego tekstu napisanego w Vamgrafie zajmuje groszowe sprawy...
Tak na marginesie dodam iż ta animacja zajęłaby o wiele mniej pamięci jeśli bym nie użył algorytmu lookup. (po prostu w pierwszej wersji nie zamierzałem programować przesuwających się liter po ekranie)

Co do tego "pudełka" to jest to ministerownik, a sam wyświetlacz 2*16 znaków w zupełności wystarczy.
To małe pudełeczko posiada:
-3 przekaźniki ze stykami przystosowanymi do zasilania napięciem fazowym
- odpowiednio zabezpieczone wyprowadzenia PA1, PA2, PA3, PD3, PD5, PD6,
- wyprowadzone Napięcie +5V
- wyprowadzona niezależna sygnalizacja niebezpiecznej temperatury wenętrznej oraz zabezpieczenie procesora
- 4 przyciski (Up, Dw, Ent, Esc)
- Wbudowany zegar RTC z potrzymaniem na super-kondensatorach
- Wejście USB

A tu krótka prezentacja sterownika. (oczywiście narysowałem tak na szybkiego prosty algorytm i dodałem do już istniejącej ów prezentacji)
Panel powitalny jest wyświetlany jednorazowo, tuż po podaniu zasilania. (oczywiście zmiana wartości zadanej powoduje natychmiastowe przerwanie animacji i wyświetlenie właściwego "ekranu")

http://www.youtube.com/watch?v=reL6qAB70pU

A tu przykładowe zdjęcie.
jak widać napisy mają wystarczającą ostrość. (rozmyty obraz jest winą nagrania)

[Josep1984]

Co do tworzenia takich ekranów powitalnych to bardzo dobry pomysł.
Prawda dużo miejsca zajmują w pamięci ale zawsze można użyć coś lepszego, bo czasami lepiej dołożyć 10 zł za lepszy niż potem się bić się swoimi myślami.

[rafal.220]

Co do tworzenia takich ekranów powitalnych to bardzo dobry pomysł.
Prawda dużo miejsca zajmują w pamięci ale zawsze można użyć coś lepszego, bo czasami lepiej dołożyć 10 zł za lepszy niż potem się bić się swoimi myślami.

Masz zupełną rację, i to w 100%
W końcu taki ATtiny2313 kosztuje ok 6zł, a ATmega32 ok 16zł => czyli różnica w koszcie wynosi tak jak napisałeś 10zł.
Czy 10zł to aż tak dużo?
Przecież za 10zł to jedynie mogę sobie zafundować śniadanie w przerwie od pracy, lecz gdzie sens i logika oszczędzać złotówki na sterownikach? (bez względu na ich stopień rozbudowania)
Osobiście, tak jak większość automatyków wolę zastosować "mocny" mikro-kontroler do prostego sterownika, niż później na wypadek zmian w programie "gryźć paznokcie" za zaoszczędzone 10 zł (śniadanie)

Skrupulatny dobór mikro-kontrolerów pozostawiam producentom lampek choinkowych, sterowników prostych piecy, pralek itp. (w automatyce taka oszczędność nie ma większego sensu)

[r-mik]

(...)oparta na ATmega32.
Oczywiście programowanie takich animacji zabiera sporo pamięci, zwłaszcza jeśli one powstają w graficznym środowisku programistycznym.
W Vamgrafie ta animacja zajęła ok. 45% pamięci flash (bardzo dużo)...

Faktycznie katastrofa. Na taki pierdół 8kB!
Środowiska graficzne (jak widać) nadają się do bardzo prostych zastosowań (np migania diodą zużywające 1kB pamięci ). Bascom (na psa urok) do prostych zastosowań (można zamigać diodą zużywając 500B). W C potrzeba jakieś 100..200B, a w ASM około 30-50B.
Najlepszym kompromisem pomiędzy zużyciem pamięci a czasem pisania aplikacji jest C.

[rafal.220]

Środowiska graficzne (jak widać) nadają się do bardzo prostych zastosowań (np migania diodą zużywające 1kB pamięci ). Bascom (na psa urok) do prostych zastosowań (można zamigać diodą zużywając 500B). W C potrzeba jakieś 100..200B, a w ASM około 30-50B.

A mógłby kolega dokładniej opisać na czym polega to mignięcie diody?
Osobiście od czapy napisałem prosty program w Vamgrafie który miga diodą. (generator sekund 500ms świeci, 500ms ciemna)
Program zajął ok. 170B flasza (jest to wartość dość odległa od tej którą kolega "sypnął")

Faktycznie katastrofa. Na taki pierdół 8kB!

Nie wiem jak inne środowiska, ale Vamgraf nie posiada żadnych akceleratorów graficznych, także proszę mi wierzyć iż zaprogramowanie animacji wiąże się ze zużyciem pamięci... (najwięcej chłoną animacje z przesuwającymi się znakami po ekranie)

Co do C to nie wiem czy w moim przypadku jest sens zmieniać środowisko, w końcu powstają coraz mocniejsze mikro-kontrolery a same środowiska graficzne są coraz bardziej dopracowane.

[r-mik]

Co do C to nie wiem czy w moim przypadku jest sens zmieniać środowisko, w końcu powstają coraz mocniejsze mikro-kontrolery a same środowiska graficzne są coraz bardziej dopracowane.

A łatwo taki kod przenieśc na zupełnie inny mikrokontroler?

[rafal.220]

A łatwo taki kod przenieśc na zupełnie inny mikrokontroler?

Bardzo łatwo, jednak z całą przykrością muszę stwierdzić iż Vamgraf programuje jedynie dwa mikro-kontrolery.

Przeniesienie logiki z ATmega168 na ATmega32 to żaden problem. (należy jedynie pamiętać o konfiguracji samych portów We/Wy)

Natomiast jeśli przenosimy program z ATmega32 na ATmega168 to należy pamiętać o zasobach oraz o tym co ATmega168 jest w stanie zrealizować. (jeśli mowa o mrugnięciu diodą, to nie będzie problemu z przeniesieniem programu w obydwie strony)

Tak po za tematem, to mam nadzieję iż znajdą się inni użytkownicy którzy tak jak ja zakupią oryginalne produkty firmy Vamond (jest to jedyna droga na rozwój tej polskiej firmy która o nas dba, ciągle rozwijając swoją ofertę)
Vamgraf jest w stanie dorównać C, jednak to już od nas zależy co wybierzemy. (rynek zagraniczny, czy może nasz produkt z polską obsługą klienta, która będzie rozwijać branże ku naszemu komfortowi oraz zapotrzebowaniu )