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

Skomplikowany projekt, SPI i kilka urządzeń

Ch.M. 21 Sie 2007 13:19 2771 13
  • #1 21 Sie 2007 13:19
    Ch.M.
    Poziom 27  

    Witam

    Procesor: M128L
    Język:ASM
    Peryferia:
    A) 1-2 LCD Siemens S65 series (SPI)
    B) drukarka (pewnie transmisja szeregowa po RS232)
    C) silnik 12V/2-4A (I/O), 2-4elektrozawory 12V/0,06A
    D) 2-3 czujniki ciśnienia (pomiar ADC)
    E) pomiar temperatury oraz naładowania trzech ogniw Li-Poli (ADC)
    F) klawiatura membranowa (1-3 przerwania, 6-12 przycisków)
    G) ze dwa PWMy do ładownaia ogniw i podświetlania wyświetlacza
    Ogółem dużo rzeczy

    Wiem ze mega ma 2xSPI ale nie wiem czy korzystanie z obu nie jest utrudnione, moze lepiej zastosować dwa 74VHC244 do rozdzielenia wyswietlaczy podłaczonych na jednej szynie? (oczywiście nie wyświetlają tego samego więc nózki sterujące trybem pracy wyświetlaczy będa oddzielne)

    Moje pytanie: Jak najlepiej zrealizować obsługę 2 wyświetlaczy LCD po SPI oraz komunikacji danych (być może tez SPI, a może nie... pomysły jakieś?) z drukarką (prosta, termiczna, będzie wyświetlać to co nada jej protokół szeregowy)

    Pozdrawiam

    0 13
  • Arrow Multisolution Day
  • #2 21 Sie 2007 15:14
    lelekx
    Poziom 29  

    Jeżeli wyświetlacze mają sygnał CS# (SS# ?), użyj jego do wyboru wyświetlacza zamiast używać dwóch SPI. Używając drugiego SPI blokujesz sobie jeden z USARTów.
    Szczerze mówiąc nie za bardzo mam ochotę szukać dokumentacji do tego wyświetlacza, za to chętnie pomogę jak dasz link do takowej.

    0
  • Arrow Multisolution Day
  • #4 22 Sie 2007 08:59
    markosik20
    Poziom 33  

    Powiem tak , że uC jaki chcesz wykorzystać może nie poradzić sobie z tym wszystkich (braknie Ci mocy obliczeniowej). Do obsługi (płynnej) tego LCD potrzeba dużo "czasu uC" (a są dwa :wink:), chyba że będą to zwykłe teksty, czy prosta grafika bez szybkiej zmiany wyglądu. No chyba że masz do dyspozycji ze 50kB RAMU :wink:.
    Na wygenerowanie czegoś takiego
    link
    potrzeba całej "mocy" podkręconej Atmegi.

    0
  • #5 22 Sie 2007 09:03
    lelekx
    Poziom 29  

    Nie odpalaj drugiego SPI, nie będzie Ci potrzebne. Połącz równolegle linie obydwu wyświetlaczy - wszystkie za wyjątkiem CS. Sygnały CS podłącz do dwóch różnych wyprowadzeń mikrokontrolera, tymi wyprowadzeniami będziesz wybierał, z którym wyświetlaczem będzie MCU rozmawiać.
    Nie pamiętam, czy M128 ma tak samo rozwiązane drugie SPI jak mniejsze odpowiedniki, ale...
    Jeżeli chcesz koniecznie użyć dwóch SPI, obsługuje się je zupełnie inaczej. Nie będą ze sobą kolidować - jeden z SPI obsługuje się klasycznie, drugie za pośrednictwem jednego z USARTów.

    0
  • #6 22 Sie 2007 09:19
    Dr_DEAD
    Poziom 28  

    markosik20 napisał:

    Na wygenerowanie czegoś takiego
    link
    potrzeba całej "mocy" podkręconej Atmegi.

    Chcesz powiedzieć że na wygenerowanie tego nie "zmarnowałeś" ani jednego cyklu procesora czekając w pętli softwearowej, lub czekając na flagę konca transmisji lub też na flagę timera?

    0
  • #7 22 Sie 2007 09:32
    markosik20
    Poziom 33  

    Cytat:
    Chcesz powiedzieć że na wygenerowanie tego nie "zmarnowałeś" ani jednego cyklu procesora

    "Zmarnowałem" 16 taktów zegara :wink: podczas czekania na flagę końca wysyłania. Gdyby zrobić to na przerwaniu to sama obsługa przerwania z SPI zajełaby dodatkowe "takty" (jak nie wiecej) i dochodzi jeszcze obsługa buforów w RAM. Odpaliłem ten LCD na ARM'ie z zegarem 63 Mhz i widać wyraźnie róźnice :wink:.

    0
  • #8 22 Sie 2007 09:36
    Ch.M.
    Poziom 27  

    Wyjaśnienie:

    Dwa wyświetlacze są, ale nie do wyświetlenia filmów tylko obrazy statyczne-informujące o odczycie z czujnika itp (1-2fps przy niewielkich, kilkanaście procent powierrzchni LCD, zmianach obrazu)
    Po za tym sa to obrazy 1bitowe kodowane 1bit=1piksel w pakietach po 1bajcie, więc dekodowane bardzo prędko.
    Mega kręci się na 12MHz/5V i tyle jest już i tak nadmiarem (kolejny prototyp będzie na 3,3V z 8MHz zegarem)

    Na chwilę obecną rozumiem, że wyświetlacze łącze równolegle, prócz linii Cheap Select. Mam niezbyt wyśrubowaną prędkość komunikacji (a jeszcze ją obniżę) więc zwiększenie impedancji nie powinno przeszkodzić niczemu.


    Drugie SPI chce wykorzystać do transmisji danych do drukarki. Dlatego się pytam czy nie będzie problemów z włączeniem dwóch SPI. Nie czytałem jeszcze o tym i nie wiem czy nie korzystają z wspólnych rejestrów albo inne udziwnienia komplikujące życie mogą sie przydarzyć.

    Pozdrawiam

    0
  • #9 22 Sie 2007 12:47
    lelekx
    Poziom 29  

    M128 ma 1 SPI i 2 USARTy. Każdy ma swoje rejestry i nie będą kolidować w żaden sposób.

    0
  • #10 23 Sie 2007 17:24
    Jdsoul
    Poziom 23  

    Projekt rzeczywiście wielki , wygląda na sterownik przemysłowy.
    Bardzo ciekawy.

    Z tego co widzę do wyświetlanie chcesz realizować w głównej pętli :)
    Powinno dać radę.

    Zwróć jednak uwagę na klawiaturę i jeszcze na obsługę ogniw i ich ładowania.
    To też da ci spore obciążenie w głównym wątku.

    Może wywalić to do zewnętrznego kontrolera i wystawić przerwanie :)

    Co do drukarki :) zalecam pracę na buforze FIFO i jakiś mnemoniczny język opisu .

    Wiesz podprocedury formatowania tekstu itp.

    To trochę uprości pisanie programu obsługi na PC oraz obsługę drukarki :)
    Możesz zaimplementować znaki sterujące z KAFKI lub EPSONA FX, chociaż fajna też jest drukarka igłowa OKI.

    0
  • #11 27 Sie 2007 13:16
    Ch.M.
    Poziom 27  

    Jdsoul:
    Można powiedzieć, że przemysłowy... a tak na prawde to medyczny :)
    Obsługa wyświetlania sprowadza sie do do aktualizacji wartości 2 lub więcej rejestrów lub podczas nacisniecia przycisku. Z wyświetlaniem nie ma problemu, nawet duże cyfry rysuje tak, szybko, ze nie widać jak to robi.
    Klawiatura jest sprawdzana w petli głównej (chociaz może później zostaną uruchomione przerwania, bo przewiduje włącznik zasilania jako microswitch i usypianie procka)
    Ładowanie ogniw to nie problem, bo procesor wiekszość czasu się nudzi. Problemem byłoby zawieszenie procka... więc na pewno nie będzie on kontrolował ładowania a jedynie stan naładowania i ewentualnie zezwolenie na dalsza pracę lub uruchomienie urządzenia.

    Drukarka będzie służyć tylko i wyłącznie do wydrukowania przebiegu pracy (kilkanaście wierszy odczytów czujników i innych zmian stanu np. na przyciskach czy naładowania akumulatora), więc jej obsługa to oddzielny program (jeszcze tym sie nie zająłem) Drukarka musi być jak najmniejsza i pewnie wybiorę taką, do której będzie niezła dokumentacja. Raczej nie przewiduje uzywania USB bo to juz zbyt wiele jak na obecne moje możliwości
    Pozdrawiam

    0
  • Pomocny post
    #12 31 Sie 2007 16:26
    Jdsoul
    Poziom 23  

    Jeśli to co mówisz rzeczywiście sprowadzi się do danych standardowych
    to wystarczy Kafka - ma port RS-232 (UART) i reaguje właściwie wprost na ASCII - można zmienić kształt czcionki etc.
    Typowa drukarka termiczna do central alarmowych i pożarowych - tania w eksplotacji prosta w podłączeniu, samodzielna i raczej bezawaryjna zasilanie 12V/1A.

    Co do ilości wyświetlanych danych to mnie troszkę rozczarowałeś:(
    Po co do tego wyświetlacze graficzne to nie bardzo wiem, ale bajer nie z tej ziemi. Miałem nadzieję na jakieś wykresy, wizualizację, oscylogramy a tu mówisz o wynikach tekstowych, czy panelu z cyferkami :) żartuję oczywiście.

    No to rzeczywiście ARM się będzie marnował :) a wyglądało tak niesamowicie :)

    Co do nadzoru baterii - to mam dla ciebie rewelacyjne rozwiązanie - zastosuj baterię od jakiegoś lapka, notebooka - ma już w środku kopmletny kontroler i ładowarkę i wystawia najczęściej na i2c lub SPI dane o rzeczywistym stanie baterii, ilości cykli ładowania, aktualnej i docelowej pojemności i etapach ładowania. Są to rzeczy bardzo trudne do analizy szczególnie przy akumulatorach LiON więc po co masz się z tym ostro męczyć , a z tego co napisałeś to masz kilka zabawek do zasilenia - troszkę mocy dla systemu będzie potrzeba :( te nieszczęsne podświetlenia i przekaźniki ;)

    Co więcej jest tam również pamięć EEPROM, więc bateria się sama kontroluje i ładuje i jeszcze pamięta co się z niądziało i ile ma lat i krzywdy sobie nie da zrobić :).

    A ty możesz te dane sobie obrabiać w ARMIE jak chcesz i dodać analizę wszystkich możliwych rzeczy łącznie z estymacją czasu pracu na bateriach, no i procka to napewno nie zawiesi :).

    Skoro w mądrym Windowsie mogą dokładnie prognozować ile sprzęt na baterii pojedzie to i tobie się uda. Niestety nie znając całkowitych wymagań systemu nie doradzę ci konkretnej baterii :(

    W każdym razie cel szczytny :) , maszynka medyczne co robi plum... plum ...., plum ..... ta najdroższa na sali :) :) :) :) :)

    Dodano po 4 [minuty]:

    Sorki z ARM miało być AVR M128L :) :) - a zabawka wygląda na jakąś pompę krwi czy cóś takiego :)

    0
  • #13 01 Wrz 2007 08:56
    Ch.M.
    Poziom 27  

    Nie no nie krwii tylko powietrza. Zużycie energii jest małe, praktycznie to najwięcej prądu zeżre podświetlenie wyświetlacza, a po co graficzny? Bo duzy i umiem go oprogramować oraz tani. To są duże zalety. No jeszczre sporo energii pochłonie sam kompresor, ale on relatywnie rzadko będzie się włączać (tylko by w akumulatorze utrzymać ciśnienie z zakresu 1-2,5Bar.
    Co do bateri od lapka to fajna rzecz... tylko jest 1 problem, a w zasadzie dwa: wymiary i cena :)
    Po za tym stosuje lepsze ogniwa (większy prąd, duuużo większy) takie jak w nowoczesnych komórkach, a dokładnie w modelarstwie :)
    Pomiar czasu podtrzymania mam opanowany bo napięcie na ogniwach maleje w 75% zakresu liniowo (pojemność od napięcia) i sie prosto je ładuje (ograniczony prąd i napięcie)

    Piszesz o drukarce... chyba przeglądałem jej schematy :)
    Drukarka nie ma byc wbudowana tylko jako opcja dołączana kablem. Poszperam o niej jak skończę obsługę RTC

    Pozdrawiam

    0
  • #14 03 Wrz 2007 09:02
    Jdsoul
    Poziom 23  

    No to przynajmniej sprawę drukarki ci ułatwię załączam pdf. :)

    Jeśli chodzi o akumulatory, to pamiętaj, że potrzebujesz troszkę więcej informacji i musisz je chronić przed przeładowaniem.

    Fabryczne baterie mają zabudowany kontroler, po to aby uniknąć kilku zjawisk grożących wybuchem ogniw.

    1. Przeładowanie;
    2. Rozładowanie zwarciowe - najczęściej bezpiecznik polimerowy lub ogranicznik prądu;
    3. Spadek pojemności do 80% wartości ogniwa - sygnalizowany jest przez odpowiedni zapis w pamięci sterownika :) jako utrata sprawności i wydajności ogniw - czytaj czas wymienić ogniwa na nowe - lub całą baterię.

    Jeśli zadanie które wykonujesz ma mieć znamiona profesjonalne lub być urządzeniem lojalnościowym (np. funkcja chronienia życia) powinieneś jeszcze określić ilość cykli ładowania, ilość i czas rozładowania etc. etc. To wszystko ma zasadniczy wpływ na jakość i czas życia ogniw, a co za tym idzie na niezawodność urządzenia jako całości :).

    Nie sądzę żebyś dysponował pełną gamą charakterystyk ogniw w funkcji ilości cykli, punktu skoku (ładowanie) etc. Zazwyczaj takie dane uzyskują profesjonalni producenci baterii do urządzeń przenośnych i to stanowi punkt wyjścia do zaprogramowania sterowników "opiekujących" się "gołymi"ogniwami. Do tego dochodzi jeszcze pomiar temperatury ogniw, pomiar prądu ładowania i rozładowania, kupa różnych ciekawych parametrów.

    Ale jeśli już kupiłeś ogniwa to klops :)

    Co do uzasadnienia wyboru wyświetlacza to gratuluję :)
    Po co się krygować , jeśli można krótko stwierdzić , że ten najbardziej się podoba lub ten jest najbardziej znany :) :) :) :).

    Osobiście uważam, że kolorowe wyświetlacze TFT to super wynalazek , ale ciągle jeszcze nie do zastosowań przenośnych :) dziwne - ich pobór energi wciąż jest jeszcze kilka razy wyższy niż LCD.

    Co do podświetlenia to bardzo mi się podobają podświetlacze polimerowe ich pobór energi w funkcji świecącej powierzchni jest naprawdę dobry :)





    Jeśli chodzi o ostatnią sprawę którą poruszasz to cena urządzenia.

    Odnoszę wrażenie że starasz się wykonać jakieś urządzenie o wysokiej niezawodności, własnym autonomicznym zasilaniu oraz samodzielnym oprogramowaniu, współpracujące dodatkowo z urządzeniami peryferyjnymi takimi jak drukarka, czy komputer.

    Spełnienie tych wszystkich wymagań przy użyciu amatorskich rozwiązań może być dość trudne, żeby nie powiedzieć nieekonomiczne. Co przez to rozumiem np. wyświetlacz z twojego punktu widzenia tani, w skali produkcji masowej może się okazań bardzo drogi, ogniwa modelarskie również.
    Nie wspominam już o nakładzie pracy jaki będziesz musiał włożyć w samo debugowanie i testowanie oprogramowania , żeby !!zagwarantować!! niezawodność pracy urządzenia jako całości. Uwzględnienie wszystkich możliwych najgorszych wypadków wynikających z pracy wszystkich elementów składowych etc.

    Przeanalizuj to dokładnie, do jakiego momentu "opłaci" ci się brać na siebie odpowiedzialność za "niezawodność" urządzenia, a do którego lepiej byłoby ją rozłożyć na "specjalizowanych" i "doświadczonych" podwykonawców poszczególnych modułów :).Oni już o swoich komponentach zazwyczaj wiedzą wszystko, a ty musiałbyś się dopiero stać ekspertem :)

    W końcu całość sprzętu jest tak dobra jak najgorszy element systemu.

    Skup się na tym co sprawia ci najwięcej radości i na czym naprwadę się znasz :) :) :) :) :)

    0
    Załączniki: