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

Wyświetlacz 6 LED 1wire

dejmos 14 Lis 2013 21:51 15810 18
  • Wyświetlacz 6 LED 1wire

    Witam wszystkich
    Chciałbym tu zaprezentować swoją konstrukcję sześciocyfrowego wyświetlacza LED z interfejsem 1wire. O tym że 1wire jest chronione patentem dowiedziałem się już po zlutowaniu płytki w trakcie pisanie program. Mam nadzieję, że zmiana protokołu komunikacji pozwoli uniknąć złamania prawa patentowego. Jeżeli nie... to jednak wykonanie 1 urządzenia i publikowanie na ten temat jest dozwolone :D.
    Więc zacznijmy od początku. Stwierdziłem, że czasami podczas projektowania jakiegoś urządzenia na uC zaczyna brakować nam pinów lub urządzenie wykonuje krytyczne zadania, które utrudnią obsługę wyświetlacza LED. Można w takim przypadku zastosować większy procesor, szybszy zegar itd. Można też zostawić wyświetlanie dla zewnętrznego urządzenia a dane mu przesyłać tylko w chwili kiedy jest to konieczne. I z tych założeń wyszedłem. Tak powstał 6-cyfrowy wyświetlacz z interfejsem 1wire na procesorze ATtiny2313. Początkowo projekt zakładał 7 wyświetlaczy a procesor miał pracować na wewnętrznym zegarze. Jednak komunikacja mi się ciągle rozjeżdżała i po kilku dniach walki z tym zagadnieniem stwierdziłem że 6 wyświetlaczy spokojnie wystarczy do większości zastosowań a procesor został wyposażony w zewnętrzny rezonator 8MHz. Płytka została zaprojektowana tak aby można ją było spokojnie wykonać w warunkach domowych. Podczas projektowania płytki schemat był ciągle modyfikowany przeze mnie tak aby jak najbardziej uprościć wzór ścieżek.
    Komunikacja między masterem a wyświetlaczem wygląda tak:
    Master wykonuje reset linii, który trwa 480us.
    Wyświetlacz po tym czasie generuje impuls obecności również o długości 480us.
    Master wysyła 10 bajtów z czego 6 pierwszych to cyfry do wyświetlenia.
    7 i 8 bajt - rezerwa na przyszłość.
    9 bajt - adres wyświetlacza.
    10 bajt - crc.
    Jak widać wyświetlacz nie jest kompatybilny z układami Dallasa.
    Układ po odebraniu danych sprawdza crc. Jeżeli crc się zgadza sprawdzany jest adres (max 256 urządzeń), jeżeli jest to jego adres wyświetla na wyświetlaczu 6 pierwszych bajtów, które muszą odpowiadać tablicy znaków zadeklarowanej w programie. Jeżeli crc jest błędne wyświetlacz zwiera linię na 480us co master odbiera jako prośbę o ponowne wysłanie danych.
    W przypadku gdybyśmy mieli kilka wyświetlaczy podłączonych do jednej linii, procedura wygląda następująco (przynamniej jest takie założenie bo nie testowałem tego na większej ilości wyświetlaczy) Wszystkie odbierają wysyłane przez mastera dane. Wszystkie obliczają crc. Dana zostaje wyświetlona tylko przez wyświetlacz o adresie z 9 bajtu. Jednak wystarczy że tylko jednemu (niekoniecznie temu do którego jest adresowana dana) nie zgodzi się crc wtedy linia jest zwierana przez niego na 480us a master jest zmuszony do ponownego wysłania danych.
    Multipleksowaniem wyświetlaczy steruje timer0, który jest ustawiony w tryb CTC z częstotliwością 180Hz czyli każdy wyświetlacz zapala się na około 5,5ms 30 razy na sekundę. Odbiór danych zrealizowany jest na przerwaniu z INT0, które po wykryciu zbocza opadającego (impulsu reset generowanego przez master) jest blokowane na czas odbioru danych. W programie wykorzystana jest instrukcja ISR_NOBLOCK dzięki której wyeliminowane jest miganie wyświetlacza podczas odbioru danych. Czas trwania jednego bitu wynosi 120us a cała ramka wraz z impulsem reset i ewentualnym błędem crc trwa 11,04ms z czego wynika że w tym czasie występuje dwu lub trzykrotne przerwanie od timera0 i wywołanie funkcji obsługującej wyświetlanie. Czas wykonywania funkcji obsługującej wyświetlacze to około 6,5us co przy trzykrotnym wywołaniu podczas odbioru danych przesuwa moment próbkowania linii o jakieś 20us. Dlatego przyjąłem tak długu czas trwania jednego bitu (120us) aby transmisja się nie rozjechała. Układ do testów który działał przez 1 000 000 cykli (układ testowy co 10 ms wysyłał wartość licznika zwiększanego za każdym razem o 1) przy takich czasach opóźnień nie zarejestrował ani jednego błędu crc. Dlatego aby upewnić się że wszystko jest poprawne napisałem też programik, który co jakiś czas wysyłał błędne crc i wszystko było tak jak powinno. Ilość błędów transmisji zgadzała się z ilością błędnych crc wysłanych przez master.
    Postaram się umieścić kiedyś projekt urządzenia wykorzystującego ten wyświetlacz.
    Koszty:
    Wyświetlacze około 3zł sztuka co razem daje 18zł
    uC 5zł
    rezonator 2,5zł
    płytka + drobnica niech będzie 8zł
    Co daje razem 33,5zł. Myślę że nie jest to porażająca kwota :D
    Poniżej kilka zdjęć i filmik ( robione komórką) oraz pełna dokumentacja wyświetlacza +schemat układu testowego wraz z jedną z wersji programu na którym testowany był wyświetlacz.
    Jednocześnie chciałbym zastrzec, że układ powstał w celach edukacyjnych i nie ma mowy o komercyjnym wykorzystaniu go w jakimkolwiek stopniu.
    Zapraszam do komentowania i zgłaszania merytorycznych uwag :D

    Wyświetlacz 6 LED 1wire Wyświetlacz 6 LED 1wire Wyświetlacz 6 LED 1wire Wyświetlacz 6 LED 1wire Wyświetlacz 6 LED 1wire Wyświetlacz 6 LED 1wire Wyświetlacz 6 LED 1wire Wyświetlacz 6 LED 1wire Wyświetlacz 6 LED 1wire

    Załączniki:

    Fajne! Ranking DIY
    Potrafisz napisać podobny artykuł? Wyślij do mnie a otrzymasz kartę SD 64GB.
    O autorze
    dejmos
    Poziom 23  
    Offline 
    dejmos napisał 450 postów o ocenie 146, pomógł 69 razy. Mieszka w mieście Nowa Dęba. Jest z nami od 2004 roku.
  • IGE-XAO
  • #2
    houk
    Poziom 10  
    Nie naruszasz patentu jeśli wykorzystujesz go na własny użytek.
  • #3
    markoz7874
    Poziom 31  
    Ciekawy projekt - kliknąłem fajne:)
    Mam jednak uwagi do jakości publikowanych zdjęć - wystarczyło oświetlić fotografowany obiekt jakąś lampką a zdjęcie zrobić przy użyciu samowyzwalacza aby to było wyraźne i nieporuszone - polecam :)
  • IGE-XAO
  • #4
    Zielonka
    Poziom 21  
    Witam
    Projekt ciekawy. Osobiście wykorzystał bym wbudowany w procesor port szeregowy.
    W jednej ramce można umieścić adres (3-bity) do pozycji wyświetlacza oraz wartość jaka ma być na nim wyświetlona (5-bitów). Druga ramka może być adresem do konkretnego wyświetlacza. No i co najważniejsze program robi się banalnie prosty.
    Pozdrawiam
    W.B.
  • #5
    n6210
    Poziom 16  
    Ogólnie fajny projekt mimo, że nie przepadam za 1-wire. Rozumiem, że ten interfejs był tu celem samym w sobie, bo prawdę mówiąc też zastanawiałem się nad tym czemu nie użyłeś UART-a.
    PS
    Jakbyś mógł zamieścić trochę lepsze jakościowo zdjęcia :)
  • #6
    Pokrentz
    Poziom 21  
    W jednym bajcie mogłeś zakodować spokojnie 2 cyfry (nawet szesnastkowe, po 4 bity na cyfrę) i wtedy informację zmieścisz w 3-ch bajtach zamiast w 6-ciu.
  • #7
    dejmos
    Poziom 23  
    Dzięki za zainteresowanie tematem. A teraz odpowiedzi:

    @houk

    Też tak sądzę ,że nie narusza się praw patentowych jeżeli wykorzystuje się urządzenie na własny użytek.

    @markoz7874

    Postaram się dodać kilka fotek dziś wieczorem w lepszej jakości. Tak na marginesie płytka była cynowana lutownicą więc jakość cynowana może budzić zastrzeżenia :D

    @Zielonka

    Można wykorzystać port szeregowy, jednak założeniem edukacyjnym projektu było zapoznanie się z techniką 1wire. Poza tym port szeregowy to już dwa piny w związku z tym, że w uC wykorzystane są wszystkie dostępne wyjścia musiałbym zrezygnować albo z pinu reset i możliwości programowania ISP albo z zewnętrznego zegara.
    Pozycję wyświetlanej cyfry określa master w wysyłanej tablicy więc nie ma potrzeby przesyłania adresu konkretnej cyfry. Chyba, że czegoś nie rozumiem :/ 9 bajt w tablicy jest adresem całego urządzenia i dlatego napisałem że do jednej linii mamy możliwość podłączenie 256 wyświetlaczy (całych urządzeń). Mógłbyś napisać dokładnie co miałeś na myśli proponując rozwiązanie z adresem 3bitowym i dwoma różnymi ramkami?

    @n6210

    Tak był celem samym w sobie.

    @Pokrentz

    Takie rozwiązanie jest możliwe tylko dla 16 znaków ale jak zauważyłeś na filmiku wchodzą jeszcze liczby z przecinkiem których adres w tablicy znaków już się nie mieści na 4bitach. A w przyszłości może zajść potrzeba wyświetlania liter z systemu szesnastkowego lub innych np. „o”, „L” itd. w zależności od potrzeb. Dlatego dla jednego znaku zarezerwowany jest cały bajt.
  • #8
    snnaap
    Poziom 25  
    Witam

    Rozumiem, że efekty przewijania cyfr generowane są przez mastera?

    Proponował bym dodać kilka funkcji do programu tak właśnie aby takie efekty jak przewijanie długich ciągów itp rzeczy było generowane przez slava.

    Tak jak kolega wyżej pisał proponował bym zastosowanie wewnętrznej tablicy o rozmiarze większej niż ilość wyświetlaczy. Master wpisywałby znaki do tablicy, a slave by się wszystkim już zajmował. Do tego zdefiniowanie podstawowych rozkazów i master będzie wolny.

    Pozdrawiam

    PS. Ale projekt bardzo fajny.
  • #9
    Zielonka
    Poziom 21  
    Przepraszam za skróty myślowe :)
    Chodzi mi o to, że w porcie szeregowym masz zdefiniowana długość ramki (8-bitów).
    W związku z tym w jednej ramce umieszczasz adres pozycji na której chcesz wyświetlić dane z tablicy Digits[]. Tablica ma 21 pozycji w związku z tym potrzebujesz 5 bitów aby zaadresować całą tablicę. Pozostałe 3 bity wykorzystujesz do wskazania na którą pozycję wyświetlacza (np. DS1) mają być wysłane dane z tablicy. W drugiej ramce wysyłasz adres wyświetlacza (gruba sześciu LED-ów podłączonych do jednego kontrolera). Czyli nadajnik nadaje dwa bajty z adresem grupy, adresem pozycji i wartością do wyświetlenia). Nie ma potrzeby podłączania Rx i Tx USART jest transmisja asynchroniczną. Nadajnik i odbiornik działają niezależnie. Ja bym na ślepo wysyłał dane na Rx-a z kontrolą parzystości bitów.
    Pozdrawiam
    W.B.
  • #10
    tmf
    Moderator Mikrokontrolery Projektowanie
    Podstawową zaletą z wykorzystania 1-wire zamiast USART jest brak konieczności stosowania kwarcu (w przypadku ATTiny lub ATMega). 1-wire jest na tyle tolerancyjnym protokołem, że zmiany timingów związane z niestabilnością wewnętrznego generatora są bez znaczenia. Tu autor zamiast wykryć przyczynę problemów, zastosował ominięcie pod postacią kwarcu.
    Ale jest jeszcze druga zaleta zastosowania 1-wire. Protokół ten określa także sposób komunikacji z urządzeniem, a co najważniejsze sposób enumeracji urządzeń. Zrobienie enumeracji na USART już takie proste nie jest. Dopóki na magistrali mamy znaną liczbę znanych urządzeń nie ma problemu, ale jeśli dopuszczamy elastyczną konfigurację to OW jest idealne.
    Projekt bardzo fajny, tak trzymać.
    Co do patentów - wystarczy tego nie nazywać 1-wire (tak jak Atmel nazywa interfejs I2C interfejsem TWI) i problem zasadniczo znika.
  • #11
    Szymon Tarnowski
    Poziom 27  
    tmf napisał:
    Podstawową zaletą z wykorzystania 1-wire zamiast USART jest brak konieczności stosowania kwarcu (w przypadku ATTiny lub ATMega). 1-wire jest na tyle tolerancyjnym protokołem, że zmiany timingów związane z niestabilnością wewnętrznego generatora są bez znaczenia.
    Pozwolę się tu nie zgodzić, projektowałem urządzenia z USARTem taktowane wbudowanym generatorem RC. Urządzenia bez potrzeby kalibracji poprawnie komunikowały sie z komputerem. Dodatkowo UART ma taką zaletę że nie potrzeba mocy obliczeniowej do odbierania znaków, robi to moduł fizyczny i generuje przerwanie po każdym znaku. Dzięki temu można pozostałą obliczeniową moc wykorzystać do np animacji, czy np pulsowania jasnością wyświetlacza.

    tmf napisał:
    Ale jest jeszcze druga zaleta zastosowania 1-wire. Protokół ten określa także sposób komunikacji z urządzeniem, a co najważniejsze sposób enumeracji urządzeń.
    A mógłbyś napisać na czym polega ta zaleta w przypadku tego wyświetlacza? Przecież i tak wcześniej czy później musisz zaszyć w programie (albo konfiguracji urządzenia) automatycznie wykryte adresy. Nawet w przypadku jeśli chciałbyś automagicznie wyświetlać to samo na wszystkich wyświetlaczach, to ten sam efekt osiąga przez adresowanie rozgłoszeniowe.

    Nie neguję projektu, jako projekt edukacyjny jest ok, mam tylko zastrzeżenia do użyteczności projektu, bo to samo można osiągnąć przy pomocy transmisji asynchronicznej (UART) jak i sychronicznej (2 kabla i rejestr przesuwny za 50gr).
  • #12
    tmf
    Moderator Mikrokontrolery Projektowanie
    Zacznę od końca - otóż nie można. Transmisja synchroniczna będzie bez specjalnych nadajników/odbiorników linii działać tylko na małe odległości. 1-wire działa na odległości setek metrów.
    Napisałem też, że zalety z enumeracji urządzeń pojawiaja się jeśli mamy elastyczną sieć, do której możemy wpinać i wypinać urządzenia.

    Dodano po 7 [minuty]:

    Szymon Tarnowski napisał:
    tmf napisał:
    Podstawową zaletą z wykorzystania 1-wire zamiast USART jest brak konieczności stosowania kwarcu (w przypadku ATTiny lub ATMega). 1-wire jest na tyle tolerancyjnym protokołem, że zmiany timingów związane z niestabilnością wewnętrznego generatora są bez znaczenia.
    Pozwolę się tu nie zgodzić, projektowałem urządzenia z USARTem taktowane wbudowanym generatorem RC. Urządzenia bez potrzeby kalibracji poprawnie komunikowały sie z komputerem. Dodatkowo UART ma taką zaletę że nie potrzeba mocy obliczeniowej do odbierania znaków, robi to moduł fizyczny i generuje przerwanie po każdym znaku. Dzięki temu można pozostałą obliczeniową moc wykorzystać do np animacji, czy np pulsowania jasnością wyświetlacza.


    Cieszę się, że ci to działało, ale wystarczy zaglądnąć do noty procesora i zrobić parę prosty obliczeń, żeby przekonać się, że ci USART taktowany wewnętrznym generatorem w ATMega działał wyłącznie przez przypadek. Atmel zaleca w takiej sytuacji zastosowania kwarcu, dopiero dla serii XMEGA firma stwierdza, że stabilność wewnętrznego generatora jest wystarczająca do wykorzystania go do realizacji transmisji asynchronicznej USART.
    Do realizacji slave 1-wire nie potrzeba żadnej wielkiej mocy obliczeniowej - chociażby dlatego, że transmisja 1-wire jest wolna - do kilku tysięcy bitów na sekundę - to pochłania ułamek mocy obliczeniowej ATMegi. Poza tym 1-wire (zarówno master jak i slave) można łatwo zrobić w oparciu o USART, różnica jest wtedy taka, że stosując ramkę USART transmitujesz na raz 5-9 bitów, stosując USART do realizacji 1-wire nadajesz/odbierasz jednorazowo 1 bit, co zresztą jest uwarunkowane protokołem, który nie określa co ile kolejne bity mają być wysyłane. Wykorzystując USART do realizacji 1-wire narzut obliczeniowy jest żaden.
  • #13
    dejmos
    Poziom 23  
    @snnaap

    Tak efekty generowane są przez mastra. Dodanie kilku funkcji które realizowałby wyświetlacz jest ciekawym pomysłem i w wolnej chwili postaram się nad tym pochylić. Zastanawiam się tylko czy realizować tak że podczas uruchamiania wyświetlacz jest konfigurowany (ustawiany na stałe na np. miganie, pokazywani kursora, wyświetlanie poprzez przesuwanie itp.) czy też przy każdym wysłaniu danych wysyłany by był także bajt konfiguracyjny mówiący wyświetlaczowi co ma z nią zrobić.

    @Zielonka

    W takim przypadku master miałby dużo roboty bo w praktyce trzeba byłoby wysłać 6 paczek po dwa bajty. Master w każdej paczce musiałby określać adres cyfry i jej wartość oraz adres urządzenia. Myślę że to rozwiązanie nie za bardzo by się sprawdziło.

    @tmf

    Walczyłem z zagadnieniem wewnętrznego generatora kilka dni i poległem . Nie pomagało konfigurowanie bitu kalibracyjnego. Układ zachowywał się tak, że jednego dnia po kilku godzinach pracy wszystko wyglądało obiecująco, transmisja prawie bezbłędna. Następnego dnia po włączeniu układu nie działa komunikacja i cały czas występuje błąd crc. Dlatego zastosowałem rezonator zewnętrzny.
    Jak pewnie zauważyłeś komunikacja w tym przypadku jest praktycznie jednostronna wyświetlacz tylko zgłasza swoją obecność i błąd crc poprzez zwarcie linii na 480us. Czyli brak jakiejkolwiek kompatybilności z układami Dallasa dlatego w trakcie pracy nad wyświetlaczem protokół miałem ochrzcić nazwą "my_wire" jednak ostatecznie zostało 1wire.

    @Szymon Tarnowski

    Jak napisałem wyżej transmisja jest praktycznie jednostronna i nie ma możliwości odczytu adresu konkretnego wyświetlacza tak jak jest to w przypadku układów Dallas. Układ powstał na własny użytek i protokół, który jest zaimplementowany tylko bazuje na 1wire. Udostępniłem pełną dokumentację wraz z kodem aby każdy kto chciałby wykonać ten wyświetlacz mógł sobie ingerować w program według własnych potrzeb. A to że protokół jest trochę inny to wyjaśniłem w pierwszym poście.



    Widzę, że koledzy tmf i Szymon Tarnowski dysponują obszerną wiedzą w tym temacie i aż się oczy cieszą jak czytają merytoryczną dyskusję popartą ogromnym doświadczeniem. Moja wiedza jak na razie ciągle kiełkuje więc każda uwaga, sugestia bądź wniosek będzie przeze mnie bardzo uważnie analizowana.

    Na prośbę kolegi markoz7874 dodałem do pierwszego postu kilka fotek w lepszej jakości. Od razu chciałbym zaznaczyć że na schemacie są rezystory 330Ω a w układzie jak widać na zdjęciach 270Ω. Takie akurat miałem :D
  • #14
    Zielonka
    Poziom 21  
    Ilość transmitowanych danych można ograniczyć. To co zaproponowałem to rozwiązanie czysto akademickie. Rozumiem, ze w założeniu układ ma mieć jakieś konkretne zastosowanie. Można wiedzieć jakie ?
    Pozdrawiam
    W.B.
  • #15
    dejmos
    Poziom 23  
    W 90% projekt ma mieć wartość edukacyjną. Ale nie zostanie odłożony na półkę tylko na pewno powstanie jakieś urządzenie oparte o ten wyświetlacz. Często potrzebuję mierzyć czasy różnych zdarzeń z dokładnością kilkudziesięciu us, więc prawdopodobnie powstanie czasomierz w którego konstrukcji wykorzystam ten wyświetlacz. Wiem, że prostszym rozwiązaniem byłoby wykorzystanie zwykłego wyświetlacza LCD lub większego procka, który od razu miałby zaimplementowaną obsługę wyświetlaczy. Ale jak już na początku napisałem celem jest edukacja. Na pewno gdy już powstanie takie urządzenie to zostanie zamieszczone na elektrodzie.
  • #16
    Wojtek001
    Poziom 15  
    Jednym z prostszych ,skutecznych i najtańszych rozwiązań byłoby użycie dedykowanych scalaków (ja używam np. SCT) i wpisywanie danych po SPI, ale jeśli chodziło walory edukacyjne to rozumiem.
    Tutaj widzę że bezpośrednio z Attiny(przez rezystory) sterujesz segmentami a w SCT masz źródła prądowe na wyjściach, nie trzeba dawać żadnych dodatkowych rezystorów (jednym ustawiasz stałe natężenie prądu i to wszystko).
  • #17
    Szymon Tarnowski
    Poziom 27  
    tmf napisał:
    Cieszę się, że ci to działało, ale wystarczy zaglądnąć do noty procesora i zrobić parę prosty obliczeń, żeby przekonać się, że ci USART taktowany wewnętrznym generatorem w ATMega działał wyłącznie przez przypadek.
    Tak na szybko ja znalazłem dwa przykłady obliczeń:
    http://www.maximintegrated.com/app-notes/index.mvp/id/2141
    http://electronics.stackexchange.com/questions/5850/how-critical-are-uart-frequencies
    Stabilność oscylatora RC rzędu 1% wydaje się aż za nadto dobra w komunikacji z komputerem PC, oczywiście zgodzę się że w skrajnych wypadkach rozrzutu tolerancji może być problem.

    tmf napisał:
    Atmel zaleca w takiej sytuacji zastosowania kwarcu, dopiero dla serii XMEGA firma stwierdza, że stabilność wewnętrznego generatora jest wystarczająca do wykorzystania go do realizacji transmisji asynchronicznej USART.
    Większość producentów zaleca kwarce, ale to nie znaczy że są obowiązkowe. Bardzo mało aplikacji wymaga pracy w pełnym zakresie temperatur.

    tmf napisał:
    Do realizacji slave 1-wire nie potrzeba żadnej wielkiej mocy obliczeniowej - chociażby dlatego, że transmisja 1-wire jest wolna - do kilku tysięcy bitów na sekundę - to pochłania ułamek mocy obliczeniowej ATMegi.
    Popatrzny, w przypadku urządzenia, master generuje impuls i w czasie poniżej 15us trzeba odpowiedzieć zwierając magistralę (jeśli odpowiadamy 1 logiczną), impulsy (bity danych na magistrali) mogą przychodzić co 60us. Jakby wziąć procesor który ma powiedzmy 10MHz, to w przypadku RISC jedna instrukcja trwa 100ns. Załóżmy sobie że chcemy żeby nasze urządzenie było w stanie zewrzeć magistralę po 10us, a przy pomocy przerwania od pinu wejściowego realizujemy wykrywanie to by dawało 100 instrukcji od momentu "przyjścia" przerwania do momentu kiedy trzeba już znać "odpowiedzieć", bo albo jest jedynka (i trzeba już zwierać), albo nie zwieramy. 100 instrukcji wydaje się sporo, ale w przypadku napisanego kodu w C który wykorzystuje adresowanie tablicowe, może to trochę potrwać. Analizując dalej, jeden bit danych przychodzi co 60us, co daje nam 600 instrukcji (włącznie z tym na decyzję czy reagujemy czy nie), ale trzeba jeszcze w tym czasie zrobić coś z danymi odebranymi, porównać adres i instrukcję, itp. Sytuację trochę ratują sygnały Reset-Presence które są dość "jałowe" i nie trzeba wtedy nic robić, każde rozpoczęcie komunikacji daje 480us = 4800 instrukcji. Oczywiście wszystko zależy od "obciążenia" magistrali i charakteru przesyłanych danych, oczywiście zawsze można wziąć szybszego procka, pytanie jest czy warto.

    tmf napisał:
    Poza tym 1-wire (zarówno master jak i slave) można łatwo zrobić w oparciu o USART, różnica jest wtedy taka, że stosując ramkę USART transmitujesz na raz 5-9 bitów, stosując USART do realizacji 1-wire nadajesz/odbierasz jednorazowo 1 bit, co zresztą jest uwarunkowane protokołem, który nie określa co ile kolejne bity mają być wysyłane. Wykorzystując USART do realizacji 1-wire narzut obliczeniowy jest żaden.
    Tak racja, to jest dobre rozwiązanie na ulepszenie komunikacji
  • #18
    tmf
    Moderator Mikrokontrolery Projektowanie
    Szymon Tarnowski napisał:
    tmf napisał:
    Cieszę się, że ci to działało, ale wystarczy zaglądnąć do noty procesora i zrobić parę prosty obliczeń, żeby przekonać się, że ci USART taktowany wewnętrznym generatorem w ATMega działał wyłącznie przez przypadek.
    Tak na szybko ja znalazłem dwa przykłady obliczeń:
    http://www.maximintegrated.com/app-notes/index.mvp/id/2141
    http://electronics.stackexchange.com/questions/5850/how-critical-are-uart-frequencies
    Stabilność oscylatora RC rzędu 1% wydaje się aż za nadto dobra w komunikacji z komputerem PC, oczywiście zgodzę się że w skrajnych wypadkach rozrzutu tolerancji może być problem.


    Problem w tym, że tolerancja RC dla ATMega dalece przewyższa owy 1%. Tolerancję 1% dla RC z AVR mają dopiero XMEGA.

    Szymon Tarnowski napisał:
    tmf napisał:
    Atmel zaleca w takiej sytuacji zastosowania kwarcu, dopiero dla serii XMEGA firma stwierdza, że stabilność wewnętrznego generatora jest wystarczająca do wykorzystania go do realizacji transmisji asynchronicznej USART.
    Większość producentów zaleca kwarce, ale to nie znaczy że są obowiązkowe. Bardzo mało aplikacji wymaga pracy w pełnym zakresie temperatur.


    Nie tylko temperatura wpływa na stabilność kwarcu, warto przejrzeć noty procesora. Atmel wprost pisze, żeby nie korzystać z RS232 jeśli procesor jest taktowany RC.


    Szymon Tarnowski napisał:
    tmf napisał:
    Do realizacji slave 1-wire nie potrzeba żadnej wielkiej mocy obliczeniowej - chociażby dlatego, że transmisja 1-wire jest wolna - do kilku tysięcy bitów na sekundę - to pochłania ułamek mocy obliczeniowej ATMegi.
    Popatrzny, w przypadku urządzenia, master generuje impuls i w czasie poniżej 15us trzeba odpowiedzieć zwierając magistralę (jeśli odpowiadamy 1 logiczną), impulsy (bity danych na magistrali) mogą przychodzić co 60us. Jakby wziąć procesor który ma powiedzmy 10MHz, to w przypadku RISC jedna instrukcja trwa 100ns. Załóżmy sobie że chcemy żeby nasze urządzenie było w stanie zewrzeć magistralę po 10us, a przy pomocy przerwania od pinu wejściowego realizujemy wykrywanie to by dawało 100 instrukcji od momentu "przyjścia" przerwania do momentu kiedy trzeba już znać "odpowiedzieć", bo albo jest jedynka (i trzeba już zwierać), albo nie zwieramy. 100 instrukcji wydaje się sporo, ale w przypadku napisanego kodu w C który wykorzystuje adresowanie tablicowe, może to trochę potrwać. Analizując dalej, jeden bit danych przychodzi co 60us, co daje nam 600 instrukcji (włącznie z tym na decyzję czy reagujemy czy nie), ale trzeba jeszcze w tym czasie zrobić coś z danymi odebranymi, porównać adres i instrukcję, itp. Sytuację trochę ratują sygnały Reset-Presence które są dość "jałowe" i nie trzeba wtedy nic robić, każde rozpoczęcie komunikacji daje 480us = 4800 instrukcji. Oczywiście wszystko zależy od "obciążenia" magistrali i charakteru przesyłanych danych, oczywiście zawsze można wziąć szybszego procka, pytanie jest czy warto.


    Wyliczenia słusze, ale co z tego? Zrobiłem pełnego slave na procesorze taktowanym 1,2 MHz. Kilka prostych tricków, jak np. przygotowanie kolejnego wysyłanego bitu w trakcie wysyłania bieżącego załatwia sprawę. W efekcie odpowiedź można zrobić w 6-8 taktach po detekcji zbocza (przerwania). Ponieważ okres bitu to 60-120 us, więc ma się sporo czasu na obróbkę danych.
  • #19
    bajcik
    Poziom 12  
    Ciekawy projekcik, wcale nie akademicki bo już wymyśliłem dla niego zastosowanie:
    http://forum.muratordom.pl/showthread.php?742...-ciep%C5%82a&p=6338186&viewfull=1#post6338186

    Dla niewtajemniczonych: budujemy sobie bufory, robimy pomiary, wykresy. To mając już 1-wire można by poumieszczać takie wyświetalcze zamiast analogowych