logo elektroda
logo elektroda
X
logo elektroda
REKLAMA
REKLAMA
Adblock/uBlockOrigin/AdGuard mogą powodować znikanie niektórych postów z powodu nowej reguły.

[C]ATmega16 równoległa praca 2 funkcji

maly_elektronik 12 Sty 2011 09:18 1744 28
REKLAMA
  • #1 8994108
    maly_elektronik
    Poziom 23  
    Witam :)

    W czasie budowy urządzenia pojawił się pewien problem.
    Potrzebuje aby w czasie wykonywania pętli while w programie głównym wysłać coś po i2c aby nie przerywać powyższej pętli :)

    Jest to odtwarzacz muzyki w którym w czasie trwania utworu chce sterować głośnością (i2c lub TWI jak kto woli).
    Czy jest taka możliwość jeżeli tak to jak to zrealizować bo męczę się z tym od kilku nocy :(
  • REKLAMA
  • REKLAMA
  • #3 8994269
    markosik20
    Poziom 33  
    maly_elektronik napisał:
    Potrzebuje aby w czasie wykonywania pętli while w programie głównym wysłać coś po i2c aby nie przerywać powyższej pętli :)


    Bez przerwania pętli się nie da, AVR ma tylko jeden rdzeń :D
  • #4 8994977
    kaczart
    Poziom 14  
    ale można to zrobić w tak krótkim czasie w czasie obsługi przerwania, że "słuchający" nawet nie zauważy (usłyszy) że coś nie gra ;D
  • REKLAMA
  • #5 9000297
    PO.
    Poziom 20  
    markosik20 napisał:
    maly_elektronik napisał:
    Potrzebuje aby w czasie wykonywania pętli while w programie głównym wysłać coś po i2c aby nie przerywać powyższej pętli :)


    Bez przerwania pętli się nie da, AVR ma tylko jeden rdzeń :D


    Dobry pomysł, dwa rdzenie :P czyli dwa AVRy . Tylko jak komunikacja między nimi, zdaje się że któreś wyższe modele mają dma? Czy tylko xmega?

    No dobra, to żart był. Przyjrzyj się projektowi kraft - jak "jednocześnie" robić kilka rzeczy.
  • #6 9000392
    LordBlick
    VIP Zasłużony dla elektroda
    PO. napisał:
    Przyjrzyj się projektowi kraft - jak "jednocześnie" robić kilka rzeczy.
    Szczerze pisząc, sam też bym się przyjrzał, ale google nie są zbyt wylewne w tej kwestii... Masz może jakiegoś linka pod ręką ?
  • #7 9000492
    mirekk36
    Poziom 42  
    Dokładnie tak jak pisał tmf, zrobisz te dwie rzeczy naraz korzystając z przerwań i buforowania. Dokładnie na obraz i podobieństwo tego jak to np zapewne już nie raz realizowałeś na RS232 (UART)

    I nie ma co się przejmować, że nie ma 2 rdzeni ;) Będzie ładnie działać i śmigać.
  • #8 9001153
    maly_elektronik
    Poziom 23  
    Albo nie rozumie albo źle przedstawiłem idee :(

    Gdybym źle wyjaśnił o co chodzi to:

    Przez i2c wysyłane jest raptem 6b+ramka. I to kiedy będą wysłane i jaką będą miały wartość jest nie znane (micro-switch). Ale niezależnie od pracy i2c lub jej braku spi (w pętli while) musi ciągle wysyłać dane odczytane z karty SD.

    A jeżeli nie rozumie to proszę o bardziej łopatologiczne wyjaśnienie :(
  • #9 9001224
    markosik20
    Poziom 33  
    maly_elektronik napisał:
    ....musi ciągle wysyłać dane odczytane z karty SD.


    A ile to jest "ciągle"? Przecież jakoś musisz od czasu do czasu zmienić sektor, adres itp. Z jaką prędkością to SPI działa? Czy to samo SPI czyta dane z SD i je gdzieś tam wysyła?
  • #10 9001801
    janbernat
    Poziom 38  
    Łopatologicznie.
    Jest to oszukiwanie zmysłów człowieka.
    Klasyczny monitor śweci się tylko w jednym punkcie.
    Ten punkt się przesuwa tak szybko że wydaje się że cały monitor się swieci.
    Dźwięk jest słyszalny do 20kHz.
    Jak z dźwięku "wytniesz" mikrosekundy to tego braku nie usłyszysz.
    Procesor jest szybki- jak w trakcie odtwarzania dźwięku coś zrobi szybko to tego nie zauważysz.
  • #11 9002023
    PO.
    Poziom 20  
    Light-I napisał:
    PO. napisał:
    Przyjrzyj się projektowi kraft - jak "jednocześnie" robić kilka rzeczy.
    Szczerze pisząc, sam też bym się przyjrzał, ale google nie są zbyt wylewne w tej kwestii... Masz może jakiegoś linka pod ręką ?


    Proszę bardzo, tylko zanim otworzysz linka usiądź na czymś stabilnym i przygotuj podstawkę pod szczękę :P : http://www.linusakesson.net/scene/craft/
  • #12 9003126
    robik2
    Poziom 16  
    Nie ma co sie przewracać ani gubić szczęki to po prostu koder scenowy jeden z wielu :)
  • #13 9003356
    michalko12
    Specjalista - Mikrokontrolery
    Bufor dla "muzyki", "muzykę" do przerwań, a reszta do while()

    Dodano po 2 [minuty]:

    I napisałbyś jeszcze co rozumiesz pod pojęciem "odtwarzanie muzyki"
  • #14 9053464
    asembler
    Poziom 32  
    Jeżeli już sie upierasz przy rozwiązaniu pętli dla muzyki to można to zrobić albo na klasycznym przerwaniu lub na "sztucznym".
    Skoro boisz się że obsługa przerwania zakłóci ci "łomot" to w przerwaniu zamiast wysyłania całego bajtu po I2C możesz wysyłać poszczególne bity. Akurat tak się składa że przy I2C bedzie to tolerowało.
    Zwykłe przerwanie zabierze troche czasu ale sztuczne to już w atomowej wersji. Robię to tak ze w pętli "muzyki" umieszczam flage tego niby przerwania a reszta realizowana jest tak jak w zwykłym. Korzysci są takie że nie tracisz czasu na wywolanie przerwania (7) oraz na odkładanie SREG na stosie (6) lub w rejestrze (2). Obsługa wysłania 1 bitu po I2C to kilka uS więc nie sądze aby była słyszalna
  • #15 9060754
    MacGyver 7
    Poziom 21  
    Przecież M16 ma sprzętowy interfejs I2C (TWI).
  • #16 9060851
    asembler
    Poziom 32  
    Tak ale w tym wypadku przy odwróconych rolach niewyobrażam sobie kontroli programu na poziomie taktów.
    Ktoś wyżej mądrze napisal muzyczka do przerwań reszta w programie głownym. Przy takim założeniu ten post nie mialby prawa bytu.
  • #18 9061181
    asembler
    Poziom 32  
    dondu napisał:
    A ja poszedłbym w kierunku --> wszystko do przerwań i spanie między nimi w IDLE mode.

    miś: to jest dobra koncepcja. Ztym że nie wiem czy w C ogarniesz bo pamiętaj aby muzyka szła gładko inne przerwania muszą być na tyle krótkie lub od razu po wejsciu do nich musi nastąpic odblokowanie SEI co nie jest takie proste i wymaga niezłego przeliczania/wyliczania.
  • #19 9061521
    dondu
    Moderator na urlopie...
    Bez problemu - TWI na przerwaniach kod jest bez pętli oczekujących (w końcu po to jest sprzętowe przerwanie by z niego korzystać w takich sytuacjach jak ta).

    Niczego nie trzeba przeliczać - odwrotnie właśnie przerwania + bufor o jakim pisali TMF i Mirek załatwiają wszystko i zostaje sporo wolnego czasu.

    SEI - nie potrzebne kończy przerwanie i samo się włącza.

    Oczywiście TWI na przerwaniach to trochę pracy do wykonania, ale się opłaci bo TWI wykorzystujesz w wielu projektach i później okaże się, że nie musisz wcale kupować droższego czy większego procesora, bo przerwania załatwiają wielofunkcyjność.
  • #20 9061553
    asembler
    Poziom 32  
    Zle zrozumiałeś SEI nie na końcu przerwania ale na początku.
    Z mojego doświadczenia TWI w przerwaniach (szcególnie w C) bedzie zabierało wiecej czasu niz programowe wysyłanie jednego bitu.
  • #21 9061571
    dondu
    Moderator na urlopie...
    A w jakim celu skoro nie ma pętli oczekujących na odpowiedź TWI?
    Wysłanie kolejnego rozkazu po TWI jest tak krótkie, że nie ma powodu by SEI używać gdziekolwiek w przerwaniu TWI.

    Dajesz rozkaz do TWI, kończysz przerwanie i robisz coś innego.
    Gdy TWI skończy dany etap komunikacji zgłasza nowe przerwanie które oznacza następny krok do wykonania zgodnie ze statusem TWI.

    I tak aż do zakończenia transmisji po TWI.
  • #22 9061594
    asembler
    Poziom 32  
    dondu napisał:
    A ja poszedłbym w kierunku --> wszystko do przerwań i spanie między nimi w IDLE mode.

    Nie myslałem akurat o przerwaniu od TWI.
  • #23 9061607
    dondu
    Moderator na urlopie...
    A w którym przerwaniu i w jakim celu?


    asembler napisał:
    Zle zrozumiałeś SEI nie na końcu przerwania ale na początku.
    Z mojego doświadczenia TWI w przerwaniach (szcególnie w C) bedzie zabierało wiecej czasu niz programowe wysyłanie jednego bitu.


    To miałeś źle napisany kod.
  • #24 9061627
    asembler
    Poziom 32  
    No właśnie w którym, skoro mówisz że wszystko?
  • #26 9061648
    asembler
    Poziom 32  
    Kiedyś stwierdziłem że TWI na przerwaniach ma wiecej wad niz zalet, Szczególnie że nie można zadeklarować własnych pinow, a zysk jest minimalny.

    Dodano po 5 [minuty]:

    dondu napisał:
    asembler napisał:
    No właśnie w którym, skoro mówisz że wszystko?

    Możesz jaśniej?

    Bo to Ty pisałeś że trzeba SEI w przerwaniu patrz cytat powyżej?

    Nie znam całego projektu , bo tu fragmentaryczny problem. Podejrzewam że niejedno jeszcze autor będzie chciał upchnąć i wtedy każde z przerwań musi mieć możliwość zachowania jednakowych odstępów wysyłanych na PWM w celu odtwarzania muzyki, bo jak wiadomo ucho jest bardzo wrażliwe na nawet małe nierówności.
    Dlatego uważam, że przerwanie dla muzyki powinno byc jedno a reszta w programie głównym, nawet jakby miał być to programowy TWI.
  • #27 9061689
    dondu
    Moderator na urlopie...
    asembler napisał:
    Kiedyś stwierdziłem że TWI na przerwaniach ma wiecej wad niz zalet,...

    Każde rozwiązanie ma wady i zalety. TWi na przerwaniach ma wadę bo jest trudniejsze do pierwszego napisania własnych procedur - ale wielką zaletę gdy potem korzystasz w wielu projektach i nie musisz inwestować w większe procesory a to przekłada się na złotówki.

    asembler napisał:
    Szczególnie że nie można zadeklarować własnych pinow,
    To nie ma znaczenia bo pisząc TWI bez przerwań piny masz zjęte w takim samym stopniu.

    asembler napisał:
    ...a zysk jest minimalny.

    Zysk jest kolosalny - wielozadaniowość bez przerw i złotówki o których pisałem wyżej.
  • REKLAMA
  • #28 9061717
    asembler
    Poziom 32  
    Chodzi mi nie o zajętośc pinów ale o to że to muszą być konkretne piny.
    Zresztą dyskusja jest bezprzedmiotowa skoro autor postu wybrał jak wybrał uważam że jak mógł najgorzej
  • #29 9061759
    dondu
    Moderator na urlopie...
    Tak to jest drobny minus ale w ten sposób można podchodzić do tego, że Timery także nie są potrzebne skoro można zrobić je programowo.

    Autor wybrał rozwiązanie gorsze z punktu widzenia tematu postu i problemu jaki opisał.
    A wybrał je ponieważ otrzymuje rady jakie otrzymuje.
REKLAMA