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

ATtiny12L jako zegar

migod 08 Maj 2005 12:35 1848 17
  • #1 08 Maj 2005 12:35
    migod
    Poziom 21  

    Witam,

    na ile jest sens wykorzystać uC (np. ATtiny12) jako układ czasowy?
    Jaką miałoby to stabilność/dokładność (przy pracy z wbudowanym oscylatorem 1.0MHz)?? Czy ktoś z Was zajmował się podobnym tematem i mógłby mi coś w tej kwestii doradzić?

    Chcę zbudować modulator 36kHz (do komunikacji IR-LED z TSOP1736) i zależy mi na możliwie małych gabarytach układu. Jak sie zorientowałem najlepiej użyć do tego celu zegar *555 (lub też układu opartego na kwarcu), ale on wymaga dodatkowych elementów, które powiększają płytkę.

    Mile widziane podpowiedzi bardziej doświadczonych Forumowiczów ;-)

    0 17
  • Pomocny post
    #2 08 Maj 2005 13:09
    Elektrooonik
    Poziom 29  

    migod napisał:

    na ile jest sens wykorzystać uC (np. ATtiny12) jako układ czasowy?
    Jaką miałoby to stabilność/dokładność (przy pracy z wbudowanym oscylatorem 1.0MHz)?? Czy ktoś z Was zajmował się podobnym tematem i mógłby mi coś w tej kwestii doradzić?
    ;-)

    Na tym scalaczku troszke by trzeba sie było nagimnastykować żeby zrobić jakiś timer - zawiera tylko 1 i to 8-bitowy timer i bardzo mało miejsca do umieszczania danych. No chyba że jakiś prosty układzić odmierzający krótkie czasy z małą dokładnością, stabilnosc wewnętrznego oscylatora jest mała.

    0
  • Pomocny post
    #3 08 Maj 2005 13:42
    marek_Łódź
    Poziom 36  

    Co do zasobów, to bez przesady - na 32 bajtach RAM i 1KB pamięci programu można zrobić całkiem niezły zegar, niestety:

    http://www.atmel.com/dyn/resources/prod_documents/doz1006.pdf

    Rysunek 64 strona 76 datasheet tego procesora.

    1. Zmiany termiczne - ok 1%/10°C to jest co najmniej kilkaset razy gorzej jak dla kwarcu.

    2.Zasilanie ok. 1% na 0.5V też kiepsko

    0
  • #4 08 Maj 2005 13:54
    migod
    Poziom 21  

    marek_Łódź napisał:
    Co do zasobów, to bez przesady - na 32 bajtach RAM i 1KB pamięci programu można zrobić całkiem niezły zegar, niestety:

    http://www.atmel.com/dyn/resources/prod_documents/doz1006.pdf

    Rysunek 64 strona 76 datasheet tego procesora.

    1. Zmiany termiczne - ok 1%/10°C to jest co najmniej kilkaset razy gorzej jak dla kwarcu.

    2.Zasilanie ok. 1% na 0.5V też kiepsko

    Co do RAMu, możliwe, że by się udało, natomiast te odchyły są faktycznie zniechęcające. Dzięki! ;-)

    Zamiast tego spróbuję po prostu transciever'a TFDU4100 po obu stronach. Rozumiem, że wtedy już nie będę potrzebował generatora 36kHz??

    0
  • Pomocny post
    #5 08 Maj 2005 14:09
    LordBlick
    VIP Zasłużony dla elektroda

    Jak procesorki bedą miały różne temperatury i zmieniające się napiecia zasilania, to mogą się rozjechać z komunikacją, chyba, że w protokole uwzględnisz to i na bierząco będzie kalibrowana częstotliwość (OSCCAL), na podstawie jakiegoś kontrolnego pakietu danych, wysyłanego co jakiś czas.

    0
  • Pomocny post
    #6 08 Maj 2005 14:26
    marek_Łódź
    Poziom 36  

    migod napisał:
    Zamiast tego spróbuję po prostu transciever'a TFDU4100 po obu stronach. Rozumiem, że wtedy już nie będę potrzebował generatora 36kHz??


    Pod warunkiem, że zrezygnujesz z modulacji. TFDU4100 nie ma wbudowanego generatoratora. Pytanie z czego chcesz sterować i czym odbierać?

    Wracając do wersji pierwotnej, z charakterystyki TSOP1736 wynika, że jest ona dość tolerancyjna na odchyłki częstotliwości, więc może aż tak duża precyzja nie jest niezbędna.

    0
  • #7 08 Maj 2005 15:21
    migod
    Poziom 21  

    marek_Łódź napisał:

    Wracając do wersji pierwotnej, z charakterystyki TSOP1736 wynika, że jest ona dość tolerancyjna na odchyłki częstotliwości, więc może aż tak duża precyzja nie jest niezbędna.


    Racja, nie napisałem dokładnie do czego tego potrzebuję.
    Chcę sterować z poziomu komputera (poprzez seriala) małym robotem.

    Aplikacja składa się z 2 części:
    1. max232 podpiętego do PC i.. układu z diodą IR-LED (nad którym obecnie dopiero pracuję),
    2. robota mobilnego, który ma uC (obecnie AT90S4433, docelowo zamienię na +/- kompatybilną ATmega8, ale to nieistotne) i TSOP1736 jako odbiornik.

    Docelowo potrzebuję 2 kanałów transmisji - do i z robota (do komputera np. odczyty z czujników zbliżeniowych etc.). Wchodzi więc w grę zbudowanie generatora zarówno po stronie PC jak i po stronie robota (na np. 36 i 38 kHz). Problem w tym, że mój robot ma już gotową obudowę i nie ma już fizycznie pod nią miejsca na dodatkowy układ generatora bazującego na *555. Stąd też narodził sie pomysł użycia timer'a z uC.

    Z drugiej strony (PC) chciałbym mieć rozwiązanie, które zapewni mi maksimum elastyczności tzn. poprzez samą konfigurację (zwarcie pinów?) uzyskam modulator na 36,38,40kHz (i stąd pomysł na zastosowanie uC, a ATtiny12 to chyba najmniejsza pchełka, zaś operacje jakie potrzebuję na nim wykonać nie wydają się specjalnie wyrafinowane..). Podobną filozofię można przyjąć w robocie (też kilka różnych częstotliwości nadawczych). Upraszcza to rekonfigurację w sytuacji, w której w danym pomieszczeniu znajdzie się więcej niż jedna taka zabawka. Oczywiście - potrzebna byłaby wtedy wymiana samych TSOP17xx, ale nic nie stoi na przeszkodzie, aby były one "luźno" powiązane z całym układem (wkładane w jakieś gniazdo?).

    To tyle w kwestii zastosowania.

    Oczywiście zabawy z TSOP1736 i pilotem TV mam już za sobą i wszystko działa Ok. Podobnie komunikacja PC <-> robot (po serialu, na uwięzi).
    Niestety, podpięcie pod MAX232 diody IR-LED nie wystarcza.

    Czy zatem dobrze rozumuję, że uC powinien w takim wypadku generować przebieg 3xkHz, dodatkowo na jednym ze swoich wejść "nasłuchiwać" aktualnego stanu linii Tx z MAX232, zaś na wyjście (do diody IR-LED) wysyłać "AND" obu tych sygnałów (z generatora i z MAX232)?? (W przypadku robota, AND byłby oczywiście zorganizowany sprzętowo, bo inaczej Tx należałoby chyba podpiąć na krótko do INT0(1), co jest raczej bez sensu).

    PS. Sorki za to na pewno trywialne pytanie, ale niestety jestem nemo z teorii kodowania i przesyłu informacji ;/

    0
  • Pomocny post
    #8 08 Maj 2005 16:10
    marek_Łódź
    Poziom 36  

    Temat transmisji IR nie jest mi specjalnie bliski, niemniej rozumiem, że będziesz operował modulowanym (na poziomie powiedzmy 36-40 kHz) sygnałem RS232, demodulowanym bezpośrednio przez TSOP1736 (tak to chyba działa?).

    W związku z tym pierwsze pytanie - po co te zmiany częstotliwości, skoro ewentualną selekcję robotów i ich kanałów możesz umieścić gdzieś w ramce danych, co da ci znacznie większą elastyczność sterowania.

    Pytanie drugie - skoro się przesiadasz na ATMega8, masz szansę wygospodarować dodatkowy port np. RESET (jeśli nie masz wolnych), nie wspominam już o liniach kwarcu, bo wracamy do problemu stabilności częstotliwości. Dlaczego nie wykorzystasz tej kości do bezpośredniego sterowania nadajnikiem IR bez dokładania dodatkowego modulatora?

    0
  • #9 08 Maj 2005 16:41
    migod
    Poziom 21  

    Masz absolutną rację - rozkazy mogą również zawierać identyfikator robota (podobnie dane z czujników). Zmniejsza to pojemność kanału, ale przy takich zastosowaniach to bez znaczenia. Nie uwzględniłem takiej możliwości, dzięki! :)

    Obecnie kombinuję jak podpiąć diodę IR na wyjście Tx MAX232 a następnie go zmodulować po to, aby TSOP1736 po stronie robota mógł go poprawnie zdekodować.. (chciałem do tego użyć ATtiny12, ale chyba mi to odradziliście, za co dziękuję, bo straciłbym pewnie masę czasu ;) )

    0
  • Pomocny post
    #10 08 Maj 2005 16:51
    Elektrooonik
    Poziom 29  

    Z tym generatorem 36kHz to proponuje zrobic generator 36kHz na układzie CMOS 4047 sterujący diodami nadawczymi IR, a przebieg modulujący podawac na wejscie zezwalający na generację - zrobić kluczowanie tego przebiegu.

    0
  • #11 08 Maj 2005 17:00
    migod
    Poziom 21  

    Elektrooonik napisał:
    Z tym generatorem 36kHz to proponuje zrobic generator 36kHz na układzie CMOS 4047 sterujący diodami nadawczymi IR, a przebieg modulujący podawac na wejscie zezwalający na generację - zrobić kluczowanie tego przebiegu.

    Ok, znalazłem coś takiego: http://stud.wsi.edu.pl/~sikrolb/schematy-czterokanalowe_zdalne_sterowanie.html, oczywiście do uproszczenia (mam jeden kanał, a nie 4 :) )

    Thnx :)

    0
  • Pomocny post
    #12 08 Maj 2005 17:10
    Elektrooonik
    Poziom 29  

    Przy budowaniu wszelkich generatorów mających współpracować z fabrycznymi odbiornikami podczerwnieni nastrojonymi na określoną częstotliwość bardzo ważna jest stabilność częstotliwości tych generatorów.

    Charakterystyka przedstawiająca zależnośc względnej częstotliwosći (f/f0) od względnej czułosci tych odbiornikówjest bardzo stroma - jesli czestotliwość zmieni się o 5% to czułość spadnie do 60% czułośći przy f0, natomiast jeśli zmieni się o 10% to czułość względna spadnie do 40%.

    Bardzo ciekawy artykuł na temat prostego zdalnego sterowania na podczerwień jest w EDW 6/2003. :)

    0
  • Pomocny post
    #13 08 Maj 2005 17:25
    marek_Łódź
    Poziom 36  

    Elektrooonik napisał:
    Z tym generatorem 36kHz to proponuje zrobic generator 36kHz na układzie CMOS 4047 sterujący diodami nadawczymi IR, a przebieg modulujący podawac na wejscie zezwalający na generację - zrobić kluczowanie tego przebiegu.



    Czyli tak (wersja jedna z możliwych wielu) - PC nadajnik MAX232>>TX na kluczowanie generatorka np na 4047>>do wzmacniacza nadajnika IR (scalony nadajnik)

    PC - odbiornik TSOP17xx>>na RXD do MAX232

    Robot - odbiornik TSOP17xx>>na RXD procesora

    Najgorzej z nadajnikiem robota- powiedzmy że wykorzystamy sprzętowy TXD z USART procesora, na wolnej nodze procesora programowo generujemy 36kHz.

    No i teraz problem modulacji (jeśli nadajnik IR nie ma wejścia bramkującego).

    1. W najprostszy sposób można to zrealizować w postaci funkcji AND na dwóch diodach. Katody do TXD i 36kHz, anody połączone razem, przez opornik do plusa i na wejście sterujące lub wzmacniacz zasilający nadajnik.

    2. Podajemy TXD na jeszcze jeden wolny PIN procesora i programowo modulujemy ten sygnał wystawiając gotowy, zmodulowany sygnał nadajnika.

    3. Cały zmodulowany sygnał nadajnika generujemy programowo.

    ps. precyzyjna generacja f - może zastosować jakiś kwarc z dzielnikiem (np. 4060, 4040)...

    Bardzo prosty i precyzyjny generator (mówimy o stronie PC, gdzie nie ma ograniczeń wymiarowych) mozna zrobic na małym atmelku (attiny2313) - stabilność i precyzja nastaw na poziomie 10ppm (czyli aż nadto). W tym przypadku można by pomyśleć o swoistym pilocie, który pracuje albo pod kontrolą PC, albo autonomicznie.

    0
  • #14 08 Maj 2005 18:03
    migod
    Poziom 21  

    marek_Łódź napisał:

    Bardzo prosty i precyzyjny generator (mówimy o stronie PC, gdzie nie ma ograniczeń wymiarowych) mozna zrobic na małym atmelku (attiny2313) - stabilność i precyzja nastaw na poziomie 10ppm (czyli aż nadto). W tym przypadku można by pomyśleć o swoistym pilocie, który pracuje albo pod kontrolą PC, albo autonomicznie.


    I to rozwiązanie podoba mi się najbardziej! Chociaż.. gdyby móc jako pilot wykorzystać dowolne urządzenie zgodne z IrDA 1.x i kawałek software'u.. a to umożliwia już praktycznie każda komórka.. ;-)

    Ale na początek zwykła IR-LED i testy.

    Dziękuję wszystkim za podpowiedzi i zaczynam eksperymentować :)

    0
  • Pomocny post
    #15 08 Maj 2005 18:48
    marek_Łódź
    Poziom 36  

    migod napisał:
    Chociaż.. gdyby móc jako pilot wykorzystać dowolne urządzenie zgodne z IrDA 1.x i kawałek software'u.. a to umożliwia już praktycznie każda komórka.. ;-)


    Tej opcji nie ruszaliśmy. W przypadku standardu IrDA strona PC i ewentualnego pilota się upraszcza. Jest jedynie problem modulacji/demodulacji na sterowniku robota, co przy prędkościach rzędu 2400..4800..??? baud da się zrobić programowo. W tym układzie wystarczy podłączyć do dwóch dowolnych portów procesora tylko transceiver TFDU4100 i after birds (po ptokach). W tym rozwiązaniu na sterowniku możesz programowo emulować dowolny standard transmisji, nie tylko IrDA (pod warunkiem, że Ci się procesor wyrobi).

    Niemniej (*)z parametrów łącz wydaje mi się, że modulacja na 36kHz pozwala na zwiększenie zasięgu/niezawodności transmisji. Fakt wprowadzenia nośnej pozwala selektywnym wzmacniaczem-detektorem wydzielić nawet bardzo słaby sygnał z mocno zaśmieconego tła. W przeciwieństwie do tego IrDA ma transmisję o charakterze impulsowym stosunkowo podatną na szumy i zaśmiecenie tła. W każdym razie układ jest taki, że dla typowej IrDy podaje się zasięg rzędu kilku (5m), natomiast w opisie TSOP17xx podają 35m (przy odpowiednim nadajniku).

    Oczywiście jest to czysta teoria, bo bawiłem się tylko trochę IrDą.

    Pozdrowienia i SUKCESÓW.

    Nic nie stoi na przeszkodzie żeby zrobić robota skomunikowanego w układzie multistandard, który by rozpoznawał standard transmisji pilota-hosta i uruchamiał odpowiednie procedury programowe komunikacji ;-)

    Idąc dalej układ mógłby dostosować prędkość i standard transmisji do właściwości kanału (tła), a w przypadku braku zasięgu roboty bliższe centrali mogłyby pracować jako przekaźniki ;-) ;-)

    ============================================
    (*) w zakresie niskich prędkości transmisji

    0
  • #16 08 Maj 2005 19:21
    migod
    Poziom 21  

    marek_Łódź napisał:

    W przypadku standardu IrDA strona PC i ewentualnego pilota się upraszcza. Jest jedynie problem modulacji/demodulacji na sterowniku robota, co przy prędkościach rzędu 2400 baud da się zrobić programowo. W tym układzie wystarczy podłączyć do dwóch dowolnych portów procesora tylko transceiver TFDU4100 i after birds (po ptokach). W tym rozwiązaniu na sterowniku możesz programowo emulować dowolny standard transmisji, nie tylko IrDA (pod warunkiem, że Ci się procesor wyrobi).

    Niemniej (*)z parametrów łącz wydaje mi się, że modulacja na 36kHz pozwala na zwiększenie zasięgu/niezawodności transmisji. Fakt wprowadzenia nośnej pozwala selektywnym wzmacniaczem-detektorem wydzielić nawet bardzo słaby sygnał z mocno zaśmieconego tła. W przeciwieństwie do tego IrDA ma transmisję o charakterze impulsowym stosunkowo podatną na szumy i zaśmiecenie tła. W każdym razie układ jest taki, że dla typowej IrDy podaje się zasięg rzędu kilku (5m), natomiast w opisie TSOP17xx podają 35m (przy odpowiednim nadajniku).

    Oczywiście jest to czysta teoria, bo bawiłem się tylko trochę IrDą.

    Hm.. IrDA prostsza? wow! nie przypuszczałem. Jak mi nie wyjdzie z IR-LED, to mam alternatywę :P

    Co do zasięgu - masz rację, że TSOP + dobra IR-LED deklasują TFDU4100. Doczytałem, że na tym przetworniku to jakieś 3m :(

    BTW: tutaj generują software'owo 36kHz, tylko że nie do komunikacji, a do pomiaru odległości (więc błędu transmisji mają mniejszy skutek)
    http://www.lutecki.republika.pl/sumo.htm

    Czyli nie jest to do końca tak szalony pomysł jak się na początku wydawał :-)

    Pozdro,
    migod

    0
  • Pomocny post
    #17 08 Maj 2005 19:30
    marek_Łódź
    Poziom 36  

    migod napisał:
    Hm.. IrDA prostsza? wow! nie przypuszczałem. Jak mi nie wyjdzie z IR-LED, to mam alternatywę :P


    Mam na myśli skorzystanie z gotowców od strony PC i programową emulację na sterowniku (można też rozważać wersję sprzętową, ale sam pisałeś, ze nie ma miejsca).

    Sorry, może to zboczenie ale dla mnie implementacja programowa prawie zawsze jest prostsza od kombinowania w sprzęcie (przy odpowiednim dobraniu zasobów mogę z góry przewidzieć, że coś ruszy, co nie zawsze wiem sklejając jakieś scalaki), chociaż czasem jest bardziej pracochłonna (zwłaszcza w prototypie).

    0
  • #18 08 Maj 2005 20:12
    migod
    Poziom 21  

    Jak by to powiedzieć.. mam podobne zdanie.
    I wygeneruję te 3x kHz, a co! :)

    PS. szczęście, że postujemy na forum dot. uC, bo inaczej poleciałyby gromy :D

    0