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

Interface równoległy do GPS.

rpal 19 Wrz 2009 01:55 9142 22
  • Interface równoległy do GPS.


    Jestem na etapie budowy dość skomplikowanego urządzenia do samochodu i trafiłem na barierę jakim był brak wystarczającej ilości portów do transmisji po RS232. Z atmela można uzyskać ich co najwyżej dwa a mi potrzeba ich trzy. Dość długo kombinowałem przy UART-ach tak równoległych jak i pracujących na SPI. Generalnie ich wadą jest głownie cena jak i sama dostępność. W końcu kiedy to udało mi się odpalić równoległego UART-a XR68C681 zwróciłem uwagę że procek dość mocno będzie się musiał "napracować" przy obsłudze samego układu a przecież zadanie jakim miało być odczytanie informacji z odbiornika GPS to tylko znikoma część tego co ma do roboty. Doszedłem więc do wniosku że najtaniej i najprościej będzie zaprzęgnięcie do pracy jakiegoś małego Atmega aby przeprowadzić operację zmiany odbieranych informacji z postaci szeregowej na równoległą, przy okazji zamiany jej na prostą do odczytania postać czyli wyłowienie, czasu,daty i współrzędnych geograficznych z pośród informacji wysyłanych przez sam odbiornik. Dodatkowo odciążyłem główny układ od pracy związanej z tą konwersją oraz użyłem "małego" Atmega do wyznaczania odcinków drogi jako impulsy występujące po przejechaniu każdych 100m. Niestety dopiero Atmega64 w górę dysponuje 2 licznikami 16-bitowymi które do tego celu były mi potrzebne a potrzebne są akurat dwa. Jeden na prędkość drugi na drogę. Sygnał z piasty samochodu pobieram z czujnika ABS. W moim przypadku na każdy obrót koła (ok 2m obwodu) przypada 100 impulsów o amplitudzie 12V. Zatem licznik ma co zliczać w dość szerokim zakresie a dodatkowo należało zrobić jakiś prosty układ kształtowania impulsów. Ktoś się pewnie zapyta po co mi postać równoległa i nie zadowalam się tym co daje mi odbiornik GPS w transmisji RS232. Chodzi głownie o szybkość pracy a także ograniczoną ilość pinów w zasadniczym procku bo to tylko Atmega16, więc z tąd ten pomysł. Zamieszczam schemat, opis i fotografie tego co w konsekwencji powstało mając świadomość że sam program obsługi został napisany na kolanie i w dodatku w AVRStudio którego raczej nie dażę sympatią (a co za tym idzie nie orientuję się za mocno w tym środowisku) bo wygodniej mi z CodeVision, jednak nie każdy to ma. Zatem będę wdzięczny za ew. wskazówki bo trochę to jeszcze trzeba udoskonalić od strony programowej. Na fotografiach widać podstawkę na PCB jak i kabelki przylutowane od programatora. To akurat prototyp. Choć aby go odpalić musiałem dodatkowo zrobić symulator który udawał Atmega8 bo całość sprawdzałem przy użyciu JTAG-a którego obsługi oczywiście nie ma w Atmega8. Udającym był oczywiście Atmega16 :) Więc o ile komuś się taka zamiana przyda do czegoś może sobie zaczerpnąć pomysł i samo wykonanie :)
    Interface równoległy do GPS. Interface równoległy do GPS. Interface równoległy do GPS.
    Chodzi to wszystko z zewnetrznym odbiornikiem HOLUX M1000 który ma tę zaletę że ma dość szybką transmisję 38400 bodów i dodatkowo Bluetooth którego używa akurat mój telefon :). Sam w sobie odbiornik też nie jest jakoś specjalnie drogi. Ponieważ interface można programować w zakresie transmisji szeregowej w zasadzie dopasuje się do każdego odbiornika, ważne aby miał wyprowadzone sygnały RS232 w napięciach CMOS-TTL. W załączniku jest schemat, PCB oraz opis rejestrów i samej istoty działania. Taki a nie inny sposób montażu wybrałem z racji ogólnej ciasnoty w obudowie :)
    A tutaj program jeśłi komuś się nie będzie chciało czytac tego w Wordzie.


    Reg. wew. pkt.3, 2
    (joy_pl)

    Fajne! Ranking DIY
    Potrafisz napisać podobny artykuł? Wyślij do mnie a otrzymasz kartę SD 64GB.
    O autorze
    rpal
    Poziom 27  
    Offline 
    chemia dla przemysłu www.ecosolv.pl
    rpal napisał 1447 postów o ocenie 39, pomógł 72 razy. Mieszka w mieście warszawa. Jest z nami od 2006 roku.
  • flexghzflexghz
  • #2
    M. S.
    Poziom 34  
    Cytat:
    ... barierę jakim był brak wystarczającej ilości portów do transmisji po RS232 ...

    Nie lepiej było zastosować UART programowy.
    Moja Atmega 8 z wewnętrznym zegarem 8 MHz komunikuje się bezbłędnie z telefonem przez UART sprzętowy i z GPS'em przez UART programowy. W Bascomie obsługa UART'u programowego jest równie prosta jak sprzętowego.
  • flexghzflexghz
  • #3
    rpal
    Poziom 27  
    W zasadzie to kolega ma rację tylko że pisałem o restrykcjach jakie mam nałożone t.j. brak wolnych pinów, także w liniach dotyczących przerwań sprzętowych. Tak czy inaczej miałem założoną transmisję równoległą więc tylko do tego się dopasowałem poprzez interface. Druga sprawa to kwestia nadążenia procesora dla wszystkich "procesów" przebiegających w kompletnym urządzeniu. Dla przykładu podam że jeden z kanałów transmisji szeregowej ma ganiać z podwojoną prędkością 115200 bodów, drugi dotyczący obsługi GSM wymaga z kolei wolnych linii na obsługę linii sterujących przepływem. Tak na moje oko doszedłem do wniosku że dołożenie programowej transmisji RS232 może wprowadzać już niezłe zamieszanie w tym mini-systemie.
  • #4
    michalko12
    Specjalista - Mikrokontrolery
    rpal napisał:

    Z atmela można uzyskać ich co najwyżej dwa a mi potrzeba ich trzy.


    Z jakiego atmela? Widzę że lubujesz się w AVR

    ATmega640 - 4xUART
    ATmega1280 - 4xUART
    ATmega2560 - 4xUART

    Nie wspomnę już o rodzinie ATxmega gdzie uartów możesz mieć 8, ale wątpię żeby były dostępne


    I jeśli uważasz że procesor może mieć problemy z obrobieniem danych to myślisz że dokładanie kolejnych procesorów jest dobrym rozwiązaniem? To nie te czasy. Trzeba było pomyśleć nad jakimś procesorem z wydajniejszej rodziny
  • #5
    psine.pl

    Poziom 29  
    Witam. Projekt fajny i estetycznie wykonany brakuje tylko solder maski.
    Przydatny konwerter. Sam takiego kiedyś szukałem ... w końcu zrobiłem sam ... ale to inna historia.

    Mogłeś zastosować np ATMEGA324 ... ten procek ma 2 niezależne porty szeregowe.
    I więcej nóżek niż ATMEGA8 :-)

    Ale jak już powiedziałem na wstępie projekt bardzo fajny i przydatny.

    Pozdrawiam

    Marek
  • #6
    rpal
    Poziom 27  
    Miałem na myśli np. atmega162 cena za szt.7 pln. Czy cena tych procków o których kolega wspominał na poziomie 33 pln czyni je mało konkurencyjnymi a zasoby pamięci zostaną użyte może w 20 %. Fakt końcówek by starczyło bo mają już ich 100 ale przy PCB do prototypu to raczej się trochę namęczę. Dołożyłem zatem atmega8 za 5 pln. Chiałem po prostu aby było to tanie ot tyle. Zaś w kwestii zwiekszania wydajności przez dołożenie kolejnego procesora zamiast użycie innego o lepszych parametrach to zdanie mam następujące. Przede wszystkim nie ma narzędzi do np. Arm-ów mimo ich atrakcyjnej ceny, to jest to co mnie ogranicza więc lubię to co mam :) Zatem jesli "możliwości" technologiczne mam takie jakie mam oraz koszty takich poczynań są niskie to w czym tu jest problem ? :) W końcu dla jednego prototypu nie będę ponosił nakładów na całą resztę czyli np. nowy zestaw uruchomieniowy, programator i środowisko projektowe ? Ale to dyskusja która co raz wzbudza tutaj emocję więc nie będę szedł i ja na manowce :) Solder maskę można robić dla serii idącej w setki ale dla 3 układów scalonych i 3 kondensatorów + 1 dławik myślę że nie warto tego robić. Niestety nie mam w domu urządzeń do sitodruku czy też druku tamponowego więc solder maska w przypadku 2stroneggo PCB odpada w czasie lutowania i tak się zniszczy gdybym to robił termotransferem.

    Dodano po 3 [godziny] 30 [minuty]:

    Rocket_93 napisał:
    Witam!

    Nie można "multipleksować" UART sprzętowego, tj. przełączać urządzenia z którymi chcemy się komunikować przy pomocy buforów trójstanowych (74HC125)? No chyba, że konieczne jest obsłużenie wszystkich urządzeń na raz, chociaż wątpię. Mówisz o ograniczonej ilości pinów, a przecież UART potrzebuje ich znacznie mniej niż ten interfejs równoległy.

    Sama płytka jest mała, dobrze zaprojektowana i wykonana, ale przy lutowaniu w niektórych miejscach używasz trochę zbyt dużo cyny.

    Pozdrawiam

    - zakładam obsługę na raz chociaż coś takiego jak "na raz" nie występuje w przyrodzie :)
    Istotnie mam mało pinów ale i tak z góry określiłem transmisję równoległą z innymi podzespołami więc ona już jest czy mi się to podoba czy też nie. Portów rs232 jak pisałem wczesniej potrzeba 3 a dodatkowo szkoda mi było poświęcać "głowny" procesor tylko po to aby co sekundę przeszukiwał bufor odbiorczy tylko po to aby wyłowić z niego pozcyję GPS oraz zajmować mu kolejne przerwanie obsługą odczytu bufora transmisji szeregowej tym bardziej że już dwie takie transmisje ma do załatwienia na portach od rs232 które istnieją (jak pisałem jedngo brak).
    Co zaś się tyczy multiplekserowania to tego nie skomentuję jako pomysłu nieco fantastycznego.
    Ja sobie tak odpowiadam a tym czasi zniknał post którego odpowiedź dotyczyła ?
  • #7
    Użytkownik usunął konto
    Użytkownik usunął konto  
  • #8
    rpal
    Poziom 27  
    W swoim czasie także myslałem o tym co kolega, nie przemawia zatem przeze mnie złośliwość. Jest tylko mały problem bo atmegi nie mają standartowo zimplementowanegosterowania przepływem więc nie ma na czym badać co się dzieje aktualnie na liniach RS232. To dopiero trzebaby było zrobić tak aby kilka nadajników mogło kolejować swoje strumienie danych.Poza tym GPS nie będzie czekał aż drugi nadajnik nada sobie coś tam i wówczas on zajmie się transmisją. A druga sprawa to jesli by tak bezkrytycznie przełączać linie np.rxd to co się stanie się stanie jeśli jedna akurat będzie miała poziom niski a druga wysoki ? Moim zdaniem zostanie to zinterpretowane jako zmiana bitów w ramce i cały pomysł skończy się błędami transmisji.
    Jeszcze trochę w tym pogrzebałem, wywalając błędy i dokładając zapamiętanie ustawień w wewnetrznym eeprom. W zasadzie więcej w tym nie mam już nic do roboty. Tak mi się przynajmniej zdaje :)
  • #9
    Svavo
    Poziom 23  
    rpal napisał:
    ...Przede wszystkim nie ma narzędzi do np. Arm-ów mimo ich atrakcyjnej ceny, to jest to co mnie ogranicza więc lubię to co mam :)...


    Narzędzi do ARM'ów jest bardzo duży wybór (w tym darmowe), do tego prosty programator (ISP) i debuger (wiggler).
  • #10
    Użytkownik usunął konto
    Użytkownik usunął konto  
  • #11
    rpal
    Poziom 27  
    Z całego serca dziękuję za komentarze jako autor postu tylko że dwa ostatnie są nie na temat :) Zrobiłem to co zrobiłem na atmega8 i to wszystko. Może jakiś życzliwy skomentował by sam program obsługi wyhaczając tam jakieś błędy nawet opinia że to jest do d... jest pożądana bo ... że tak powiem w temacie :)
  • #12
    grzeniu_pl
    Poziom 14  
    Czy zaimplementowanie RS485 w twoim projekcie nie było by znacznie ciekawsze i trochę tańsze ?
  • #13
    nelik1987

    Poziom 31  
    michalko12 napisał:
    rpal napisał:

    Z atmela można uzyskać ich co najwyżej dwa a mi potrzeba ich trzy.


    Z jakiego atmela? Widzę że lubujesz się w AVR

    ATmega640 - 4xUART
    ATmega1280 - 4xUART
    ATmega2560 - 4xUART

    Nie wspomnę już o rodzinie ATxmega gdzie uartów możesz mieć 8, ale wątpię żeby były dostępne


    I jeśli uważasz że procesor może mieć problemy z obrobieniem danych to myślisz że dokładanie kolejnych procesorów jest dobrym rozwiązaniem? To nie te czasy. Trzeba było pomyśleć nad jakimś procesorem z wydajniejszej rodziny


    XMega można już kupić w Polsce, czytałem o nich ostatnio są bardzo interesujące ale cena niestety jeszcze odstrasza. Mam zamiar kupic jednego po to by go przetestować

    http://www.seguro.pl/sklep/?podkat=208 cena 24zł
  • #14
    Użytkownik usunął konto
    Użytkownik usunął konto  
  • #15
    rpal
    Poziom 27  
    Odpowiadam koledze olosie. Optymalizację kompletnie wyłączyłem więc może istotnie dla kosmetyki można dodać to volatile natomiast co do rejestrów to przerwanie odkłada w zasadzie wszystko oto co się dzieje przy wejściu w przerwanie:
    Code:
    +000001BB:   921F        PUSH      R1             Push register on stack
    
    +000001BC:   920F        PUSH      R0             Push register on stack
    +000001BD:   B60F        IN        R0,0x3F        In from I/O location
    +000001BE:   920F        PUSH      R0             Push register on stack
    +000001BF:   2411        CLR       R1             Clear Register
    +000001C0:   932F        PUSH      R18            Push register on stack
    +000001C1:   933F        PUSH      R19            Push register on stack
    +000001C2:   934F        PUSH      R20            Push register on stack
    +000001C3:   935F        PUSH      R21            Push register on stack
    +000001C4:   936F        PUSH      R22            Push register on stack
    +000001C5:   937F        PUSH      R23            Push register on stack
    +000001C6:   938F        PUSH      R24            Push register on stack
    +000001C7:   939F        PUSH      R25            Push register on stack
    +000001C8:   93AF        PUSH      R26            Push register on stack
    +000001C9:   93BF        PUSH      R27            Push register on stack
    +000001CA:   93EF        PUSH      R30            Push register on stack
    +000001CB:   93FF        PUSH      R31            Push register on stack
    +000001CC:   93DF        PUSH      R29            Push register on stack
    +000001CD:   93CF        PUSH      R28            Push register on stack
    +000001CE:   920F        PUSH      R0             Push register on stack
    +000001CF:   B7CD        IN        R28,0x3D       In from I/O location
    +000001D0:   B7DE        IN        R29,0x3E       In from I/O location

    Mam z tym więc spokój :), Chciaż przyznam się że nie bardzo mi to pasi bo odkładane jest wszystko na zasadzie marginesu głupoty czy trzeba czy też nie jakby nie patzreć kosztem czasu wykonania inna sprawa że użycie assemblera dałoby lepszą nad tym kontrolę tylko czy warto się bić z tymi mnemonikami ? Prowadzoen już były tutaj boje co lepsze kod maszynowy czy C ze skutkiem .... znanym. Użycie tablic to rozmiem że kwestia gustu taka konwencja jaka tam jest powiedzmy bardziej mi wpada w oko :) Choć przyznam się z początku kompletnie mi to nie leżało. Użyłem oczywiście AVR GCC aby było to dostępne dla każdego bo to darmocha chociaż mam "kupny" CodeVision którego lubię ale ten z kolei potrafi przy debugowaniu płatać figle czyli co innego na ekranie co innego w pamięci uP a co innego się wykonuje.
    Co się zaś tyczy RS485 to najzwyczajnie nie wiem jak to chodzi choć robiłem rozeznanie w samych układach scalonych do tego MAX coś tam i generalnei cena mnie jakoś nie odstraszyła choć była dość wygórowana. Kalkulacja wyszła mi mniej więcej taka że wartość jednego specjalizowanego ukłądu do RS485 który jest obsługiwany przez SPI to te same pieniądze co Atmega8 + Atmega162 suma sumarum mają do kupu 3 UART-y. Więc ekonomiki tutaj nie widziałem żadnej ale to co mnie zmiejsca zniechęciło to rodzaj obudów tych Max-ów które oferowano w tak miniaturowej wersji że tylko mikroskop i PCB na zamówienie, sam temu bym nie podołał. Więc nie pasowało mi nijak ponosić wszystkie koszty przygotowania PCB dla 1 szt prototypu (przejściówki zaś nie wchodzą w rachubę z racji braku miejsca) albo też liczyć się z loterią wyjdzie PCB czy nie wyjdzie (stosując gotowy laminat pokryty emulsją) Takie życie wybiera się zwykle mniejsze zło :) Jest jeszcze jeden aspekt czemu rs232 a nie RS485 mam jeszcze do tego wszystkiego zrobiony "programowy symulator" czegoś czego jeszcze nie było a ten moduł jest akurat tego składnikiem. Ponieważ PC ma tylko RS232 więc i to zaważyło że jest to a nie co innego .Volatile istotnie można by było poprawić choć kompilator tłumaczy to jak należy ale tak dla zasady ....
    Acha jeszcze taka uwaga, ja wiem że są lepsze procesory, szybsze i w ogóle fajniutkie jest tego mnóstwo. Może to z mojej strony urojenie ale mam tak że skoro oszacowałem niezbędne zasoby pamięci dla programu, określiłem szybkość pracy oczywiście na oko to tylko szacunki bo alfa i omegą nie jestem i wyszło mi że daje to wszystko radę pociągnąć to po co wsadzać procka któremu użyje się 10 % zasobów pamięci a samo wykonanie programu będzie powiedzmy , dłubaniem w nosie. To coś tak jakby za pomocą ferrari wozić kartofle na stragan. Oczywiście mogę się mylić.
    Dzięki za uwagi czekam na jeszcze :)
  • #16
    Użytkownik usunął konto
    Użytkownik usunął konto  
  • #17
    rpal
    Poziom 27  
    O widzisz kolego olosie na coś się przydała dyskusja, ja sie przyznaję bez bicia, że opcje kompilacji są mi praktycznie nieznane w AVR GCC nie miałem nigdy na tyle zapału aby to dokładnie przestudiować, jest gdzieś spolszczony opis tego zagadnienia ?
  • #18
    Użytkownik usunął konto
    Użytkownik usunął konto  
  • #19
    rpal
    Poziom 27  
    olosie napisał:
    Optymalizację możesz włączyć dodając flagę do wywołania kompilatora np.:
    -O1
    -O2
    -O3
    -Os
    O1 to najmniejsza optymalizacja. O3 to najlepsza ale może czasami powodować niezamierzone efekty i zalecana jest raczej optymalizacja O2. Os to optymalizacja obejętości kodu, czyli będzie się starać spowodować aby kod wynikowy był jak najmniejszych rozmiarów. Ja używam O1 lub O2. Jeśli chodzi o dokładniejszy opis to jak poszukasz w google to pewnie coś znajdziesz ale będzie sie to tyczyć raczej ogólnie gcc niż avr-gcc.
    Kiedyś jak się przyjżałem tej O3 co ona wyprawia to po prostu odpuściełm sobie optymalizowanie w ogóle bo potrafił mi kompilator powycinać całe funkcie czy wręcz pomilał o ile dobrze pamietam pętle stąd moja niechęć do tego produktu. Trzeba przyznać że codevision to taki produkt że nie trzeba zbyt mocno przy nim się zastanawiać, ogranicza ilość opcji kompilacji programu czasem bywa dość wygodna :)
    Pozwoliłem sobie sprawdzić rady kolegi no i niespodzianka bez względu na rodzaj optymalizacji wynik wejścia w przerwanie jest identyczny, bez względu na "moc" tego zabiegu odkłądane są na stos wszystkie rejestry.Porównałem tez kod generowany przez Codevision i ten odkłada na stos tylko te rejestry które uywane są w przerwaniu. Miła niespodzianka :)
  • #20
    Użytkownik usunął konto
    Użytkownik usunął konto  
  • #21
    rpal
    Poziom 27  
    Masz rację kolego bzdury tu napisałem opotymalizuje tylko coś tam naknociłem przy kompilacji.
  • #22
    czuker
    Poziom 25  
    witam,

    a czy ten holux m-1000 ma wyprowadzanego seriala na port usb? tego właśnie nie pamiętam, napewno usb służy do ładowania akumulatora i nie ma na nim komunikacji w sensie usb, ale czy jest transmisja szeregowa na poziomach cmos? I drugie pytanie: czy orientujecie się jk najlepiej wyłączyć bluetooth w tym urządzeniu? zastanawiam się nad odcięciem anteny, da mi to tyle że urządzenie być może nie bedzie widziane przez inne urządzenia, ale bluetooth moc będzie pobierać więc nie jest to optymalne rozwiązanie.

    pozdrawiam
  • #23
    rpal
    Poziom 27  
    Tam USB nie ma jest zwykły serial mino ze złącza są od USB. W datashecie jest to rozpisane. Natomiast czy mozna odciąć Bluetooth to nie wiem, Działa to równolegle z serialem. Możliwe że poprzez wysłanie jakis komend do odbiornika można to zrobić ale do taklich informacji nigdy się nie dokopałem a poza tym działający bluetoot nigdy mie nie przeszkadzał. Z drugiej strony w gotowym urządzeniu nie używam zasilania bateryjnego więc nie muszę oszczędzać na energii.