mam pytanie, czy jest możliwość (bo mi nic nie przychodzi do głowy) realizacji różnych procedur przerwania od SPI dla odbioru i dla wysłania danej? Przerwanie jest tylko od zakończenia transmisji, a nie ma żadnego rejestru, z którego możnaby przeczytać, czy poprzednią operacją był odbiór czy wysłanie danej.
Konkretnie chciałbym przy odbiorze danej zapisywać ją w jakimś buforze cyklicznym, a przerwanie od wysyłania nie jest tak istotne, mogłoby go nie być.
To co teraz mi przyszło do głowy, to po prostu uaktywnienie przerwania tylko tam, gdzie będę odbierał dane. Czy jest jakieś inne rozwiązanie?

Akurat ta magistrala działa tak, że żeby odebrać trzeba wysłać
Tzn. jak jak wysyłasz to >równocześnie< odbierasz bajt.

_________________
Jestem początkujący i moje porady mogą być błędne

wiem, ale przeważnie te dane, które się odbiera przy wysyłaniu to są śmiecie. Choć z tego sposobu działania może wynikać fakt, że jest tylko jeden rodzaj przerwania

mieszasz troszkę pojęcia,

w SPI już tak jest że jeśli masz magistralę dwukierunkową to tak jak pisał kolega wyżej nadając jednocześnie odbierasz. I nie ma że przeważnie są to śmieci ? skąd taki pomysł z tym "przeważnie" - jak masz układ który się komunikuje po SPI w dwie strony to się zagląda do jego noty PDF i się sprawdza co się otrzymuje przy wysyłaniu.

Tu jest jedno przerwanie, ale transmisja SPI zwykle jest tak szybka, że rzadko kiedy organizuje się tu bufory cykliczne ... ja myślę, że bardziej by ci się to rozjaśniło gdybyś poćwiczył taką transmisję na czymkolwiek w praktyce niż rozważał to tylko teoretycznie

------------------------ [ Dodano po: kilkunastu sekundach ]

lepiej powiedz co chcesz zrealizować konkretnie zamiast wymyślać jak tu zrobić dwa przerwania ? szybciej uda się coś podpowiedzieć, pomóc itp

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

no dobrze, może nie przeważnie, akurat układ którego używam nie wysyła niczego podczas odbioru danych.
Mam zrealizować odbiór danych z SPI (wcześniej muszę ten układ zainicjalizować wysyłając mu coś, potem tylko wysyłam komendę STARTU i odbieram dane), tych danych jest dość dużo (w sumie pod 400kb) i przetransportować je od razu do zewn. pamięci EEPROM przez I2C, dlatego myślałem o zrobieniu jakiegoś niedużego bufora w pamięci RAM, do którego miałoby pisać SPI i z którego miałoby czytać I2c
Rozważania teoretyczne są mi potrzebne właśnie po to żeby to wymyślić i napisać, bo z podstawową wersją komunikacji SPI jestes zaznajomiony

No jeśli to ma być transmisja takich ilości danych (ok 400kb) to się z jednej strony nie dziwię że chodzi ci po głowie bufor cykliczny, rozumiem, że w trakcie przesyłania chcesz wykonywać jeszcze inne operacje ?

No ale to nadal nie zmienia faktu, że odbiór tych danych będzie się wiązał z wysyłaniem np pustych bajtów i tak ma być. Zastanawiam się tylko czy to urządzenie hmm scalak (nie wiem z czego masz zamiar to odbierać) ma jakąś czasówkę, wg której jest określony ściśle czas odbioru poszczególnych bajtów. Więc nawet tu zgadywać za bardzo nie można co i jak.

Generalnie masz przerwanie SPI i możesz je do tego spokojnie wykorzystać, przecież gdy zostanie ono wygenerowane to oznacza zarówno że wysłałeś pusty bajt a jednocześnie odebrałeś kolejny bajt danych. Po co więc tu jakieś dwa przerwania ?

Z drugiej strony jeśli np twoje urządzenie (procek) nie ma innych zadań po drodze to co za problem odebrać te dane w poolingu nawet bez udziału przerwań?

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

masz rację, jedno przerwanie w zupełności wystarczy
ten scalak to ADS1292 (Analog-front-end do EKG). Chciałem zrobić odbiór na przerwaniu a przesyłanie dalej przez TWI na pollingu (uC nie będzie miał nic innego do roboty w tym czasie). Wtedy w pętli while() w TWI będę mógł czekać na przyjście nowych danych do bufora i od razu przesyłać dalej .

No dokładnie tak można zrobić i to może dzięki temu zadziałać najszybciej i najsprawniej

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

wszystko byłoby pięknie, ale przypomniało mi się, że przecież moduł SPI ATmegi generuje zegar na linii SCK tylko wtedy, gdy wysyła jakieś dane, czyż nie? ()
Więc żeby czytać coś ciągle przez 10s musiałbym uruchomić pętlę while() w której wysyłałbym przez cały ten czas "000...0". Na szczęście ten układ ma dodatkowe wyjście sygnalizujące pojawienie się ważnych danych więc mogę czytać to wyjście (a podłączyłem go u siebie do INT1), czyli da się to inaczej zrobić.
W każdym razie dzięki za pomoc, bo przez to lepiej zrozumiałem działanie SPI i doczytałem notę ATmegi o tym zegarze
edit:
przeglądam właśnie książę "Mikrokontrolery AVR..." i na stronie 294 mam funkcję do odbioru bajtu w trybie Mastera:

to w takim razie mam pytanie: jak ten odbiór bajtu tutaj miałby się odbyć, a konkretnie skąd się weźmie zegar na SCK, skoro do SPDR nic nie wpisałem.
To pytanie zadaje abstrahując od faktu, że parę linijek niżej mam funkcje, która naraz nadaje i odbiera

Coś mi się wydaje, że kolega popełnia typowy błąd wielu czytelników czyli czyta książkę na wyrywki. Albo drugi błąd - że przeczyta kolega do pewnego momentu i nie sięgnie dalej gdzie już jest rozwiązanie

no bo zobacz piszesz o funkcji ReceiveSPI() a przecież tuż zaraz za nią w następnych akapitach masz pokazane jak zrobić sobie



i dopiero to jest przykład właściwej końcowej funkcji a wcześniej starałem się rozbić na kawałki dla lepszego zrozumienia i zobrazowania. Zatem nietrudno sobie wyobrazić, że aby odebrać tą funkcją o którą pytasz to najpierw trzeba byłoby użyć tej wcześniejszej, czyli:



a po co skoro można zamienić je w jedną:



czy teraz jaśniej ?

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

zorientowałem się o co chodzi już wcześniej wydaje mi się, że w książce nie jest dość jasno napisane, że ta funkcja ReceiveSpi sama nie zadziała. Co jednak nie zmienia faktu, że książka jest bardzo dobra i bardzo dużo się z niej nauczyłem

Jak zwykle za szybko wyciągasz wnioski, albo inaczej najpierw coś powiesz nie do końca przemyślawszy, a potem dopiero się orientujesz

Ta funkcja ReceiveSPI() jak się uprzeć to zadziała sama .... wyobraź sobie pan że siedzi ona w układzie SLAVE i co teraz ?

W książce staram się przekazać pewną wiedzę, wg pewnego ściśle określonego sposobu. Ale jak mówię i wciąż powtarzam najpierw trzeba ją chociaż JEDEN RAZ przeczytać w całości a potem dopiero czytać poszczególne rozdziały a nie na wyrywki bo widać jak to się kończy ... wiem i zadaję sobie z tego sprawę, że z moim sposobem przekazywania wiedzy nie trafię do każdego, ale to nie oznacza że akurat SPI jest źle opisane. I być może nie doczytałeś nieco wcześniej w książce - gdzie BARDZO wyraźnie piszę, że dane po SPI są wysyłane JEDNOCZEŚNIE w dwie strony.

A to rozbicie może trochę sztuczne na dwie poglądowe funkcje SendSpi() i ReceiveSpi() miało m.in tobie i nie tylko tobie pokazać - to o co pytałeś m.in na samym początku tego wątku, że zarówno do nadawania jak i odbioru wystarczy jedno przerwanie. Gdy ty tymczasem próbowałeś wymyślić sposób żeby dało się zrobić dwa przerwania.

Dlatego proszę - jak czegoś nie wiesz jeszcze i się uczysz to dopytaj - ja (i nie tylko ja - jak widzisz na tym forum) chętnie pomogę. Zamiast pisać, że coś w książce jest źle opisane, tym bardziej, że widać iż jeszcze nie do końca rozumiesz działanie np SPI. OK?

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

no dobrze, pewnie zrobiłem błąd. Zwróć jednak uwagę, że nie krytykuję twojej książki z góry na dół, a raczej zaznaczyłem, że książka jest bardzo dobra błąd nie był złośliwy ani celowy, więc nie nie trzeba unosić się honorem od razu w każdym razie zostawmy przez chwilkę obsługę SPI.
Mam kolejne pytanie. Chcę utworzyć ten bufor kołowy, o którym wspominałem wcześniej. Będzie z niego korzystać zarówno SPI jak i TWI. Oba muszą znać początek i koniec bufora oraz jego rozmiar. Chciałem rozdzielić projekt na różne pliki, tzn. mieć przykładowo spi.h i spi.c oraz twi.h i twi.c (nazwy roboczo podałem). Zarówno w spi.c jak i w twi.c będę się odnosił do tych parametrów bufora. Te parametry chciałbym umieścić w jednym konkretnym pliku, który będą załączać zarówno spi.c jak i twi.c. Myślałem, żeby po prostu opatrzeć je modyfikatorem extern, ale chciałbym ich również zainicjować odpowiednimi wartościami, żeby funkcje z obu plików widziały, że koniec/początek zostały zmodyfikowane. Proszę o poradę jak to zrobić

Nie unoszę się, a spokojnie tłumaczę jak jest.

Jeśli chodzi o bufor cykliczny i jego realizację to mogę polecić ci zapoznanie się z buforami cyklicznymi dla RS232 bo można to zorganizować wręcz identycznie.

tyle tylko że będziesz musiał sobie rozbudować sygnalizację pomiędzy procesami gdy bufor będzie pełny. To jedno, a drugie .... tak się zastanawiam - co da ci tutaj bufor cykliczny jeśli mowa o tak ogromnych ilościach danych 400kb to nie w kij dmuchał jak to się mówi. Więc jaki bufor zastosujesz? tzn jakiej wielkości w procesorze AVR ? co on ci da? chyba tylko to, pewne przesunięcie o kilka ms zapisu i odczytu całego pliku 400kb. Co więcej czy nie będzie tak że urządzenie na I2C będzie dużo wolniejsze niż SPI ? jeśli tak to zdecydowanie o wiele szybciej będą się dane pakować do bufora z SPI a o wiele wiele wolniej będą pobierane żeby wysłać na I2C ---- a jeszcze jak mówisz o zapisie do EEPROM ... ooo jej to już w ogóle potrzeba czasu jeszcze na zapis stron w takim EEPROM. Chyba że użyjesz jakichś szybkich pamięci FRAM.

Oczywiście taki bufor dałby oddychać nieco procesorowi w tym sensie, że gdyby były inne operacje do wykonywania - to właśnie w tym czasie oczekiwania aż I2C prześle - mogłyby się wykonywać. Ale jeśli tak jest jak pisałeś że procesor w tym czasie nie będzie nic innego robił - to właśnie sposób z poolingiem byłby najbardziej efektywny.

No ale to już twój wybór - bo rzeczywiście może na razie nie masz nic innego do roboty w pętli głównej ale jak projekt się rozrośnie to może przyjdą pomysły wtedy

reasumując - zobacz jak jest zorganizowana obsługa RS232 na buforach cyklicznych - jest to dosyć szeroko opisane w książce, bo tu przy o wiele wolniejszej komunikacji i to asynchronicznej - taki bufor to wręcz konieczność.

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

hmm, urządzenia na SPI to jak przedtem wspomniałem, front-end do EKG, na jego wyjściu pojawiają się dane do odczytanie powiedzmy co 1ms (bo co tyle (upraszczając) są pobierane próbki). Do EEPROMU mogę na pewno szybciej wysyłać dane, z tym że na zapis strony potrzebuję typowo 3ms. Wydaje mi się, że w takiej sytuacji bufor kołowy miałby jednak sens (gdzieś muszę zapisać dane wtedy, gdy zapisuję stronę w EEPROMIE. Jego rozmiar nie musiałby być duży, np. 64B). O buforze kołowym w USARCIE czytałem i właśnie na nim się wzoruje, bardzo spodobało mi się rozwiązanie. Chodzi mi o inną rzecz, mianowicie jak to rozdzielić na pliki. Jak to wcześniej sformułowałem:

I właśnie nie wiem jak to napisać.

No dobrze - to spójrz jak to jest zrobione w tym RS232. Generalnie masz tam np funkcję uart_getc() - zobacz jak ona pobiera pojedyncze bajty z bufora cyklicznego. Przecież ona może być twoim "pobieraczem" na potrzeby I2C ....

Tylko teraz zastanów się - ty robisz nietypową rzecz / bibliotekę. Nie będzie ona albo do I2C albo do SPI, ale do obydwu rzeczy. Więc ja bym zrobił sobie to w ramach jednej biblioteki takie wspólne nietypowe funkcje, np:

spi_i2c.c
spi_i2c.h

i to w nich pisał obsługę bo tak będzie chyba logicznie - prawda? Oczywiście tak na prawdę możesz skorzystać z całkiem oddzielnych standardowych bibliotek zawierających najbardziej niskopoziomowe funkcje dla SPI i I2C, wtedy możesz je zainkludować (*.h) w tej swojej bibliotece, która będzie z nich korzystać a sama zawierać już będzie tylko obsługę buforów cyklicznych i wyższych funkcji do komunikacji z twoim programem głównym.

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

rzeczywiście, tak chyba zrobię
Dzięki za pomoc i świetnie, że jest takie forum wsparcia oprócz książki

nie ma sprawy, jak będziesz w trakcie robienia a zrodzi się jeszcze jakieś pytanie to śmiało dawaj

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]