Uzytkownik "Marcin Wasilewski" <j...@a...pl> napisal w wiadomosci
news:innq9l$4mg$1@news.onet.pl...


> A kto Ci powiedzial, ze FIFO musi byc szeregowe? Traktuj to jako
> urzadzenie I/O z dwubajtowym FIFO.

Nie czytacie dokladnie co sie tu pisze.

Oba te rejestry tworza hybryde FIFO. OK. Ale ja caly czas poruszam
problem tylko jednego rejestru Transmit Shift Register który rejestrem
FIFO nie jest. Jest zwyklym rejestrem przesuwnym. Dopiero polaczony z
rejestrem UDR linia 8 bitowa tworza razem hubryde FIFO.

Rejestr Transmit Shift Register nawet nie miesci dwóch bajtów bo to
rejestr 8 bitowy jest. Przesuwny ale nie FIFO.


Marek

do góry

Użytkownik "Michoo" <m...@v...pl> napisał w wiadomości
news:innqat$4ri$1@news.onet.pl...

>> Czy trudno ci to zrozumieć że ja cały mówię o rejestrze przesuwnym
>> 'TRANSMIT SHIFT REGISTER'
> Bardzo trudno. Zaczęło się od "UDRE: USART Data Register Empty". To
> tobie się uroiło, że odpowiedź o FIFO dotyczyła shift register.

Bo dopiero później spojrzałem na ten rysunek i zobaczyłem że UDR to
nie jest jedyny rejestr a zarazem nie przesuwny. To tylko bufor.

>> Te dwa rejestry razem wzięte, czyli rejestr równoległy UDR oraz
>> rejestr
>> przesuwny TRANSMIT SHIFT REGISTER tworzą coś ala hybrydę rejestru
>> przesuwnego FIFO z ładowaniem równoległym i wyjściem szeregowym.
> UDR nie jest w tym rozważaniu do niczego potrzebny - równie dobrze
> TSR mógłby być ładowany bezpośrednio. Natomiast jak zauważyłeś pełni
> on rolę "jakby FIFO" - dane ładowane są równolegle ale opuszczają
> bufor szeregowo wg starszeństwa bitów. Tylko, że pisząc o FIFO AK
> miał na myśli od początku UDR a Tobie się to pokręciło z TSR.

Mój błąd jest że od razu nie spojrzałem na rysunek. Wtedy
prawdopodobnie nie było by tej dyskusji
bo efekt był taki że zamiast się poprawić ustosunkowywałem się do
nowego pojęcia nie poprawiwszy tego co powiedziałem wcześniej i stąd
nieporozumienie.


Marek

do góry

Użytkownik "4CX250" <t...@p...onet.pl> napisał w wiadomości
news:innqv9$tcd$1@news2.ipartners.pl...
> Mój błąd jest że od razu nie spojrzałem na rysunek. Wtedy
> prawdopodobnie nie było by tej dyskusji
> bo efekt był taki że zamiast się poprawić ustosunkowywałem się do
> nowego pojęcia nie poprawiwszy tego co powiedziałem wcześniej i stąd
> nieporozumienie.

A dokładnie to po przeczytaniu datasheta w głowie miałem obraz tylko
jednego rejestru który nalezy załadować równolegle i z niego wysuwane
sa po kolei bity jak z rejestru przesuwnego.
To napewno nie jest FIFO pomyślałem. Potem spojrzałem na rysunek i
okazało się że oprócz niego jest jeszcze jeden rejestr który jest
rejestrem przesuwnym ładowanym z tego UDR. No dobra ale on sam w sobie
nie jest FIFO tylko zwykłym rejestrem przesuwnym. Kilka osób uważa
jednak oba te rejestry za całość jako FIFO jednocześnie używając nazwy
Transmit Shift Register.
No dobra teraz się wyjasniło. Mowa nie o jednym rejestrze ale dwóch,
co widać na rysunku i nie bez powodu nazywają się różnie.
Nie mam więcej nic do powiedzenia w tym temacie.

Marek

do góry

Uzytkownik "4CX250" <t...@p...onet.pl> napisal w wiadomosci
news:innql6$tb9$1@news2.ipartners.pl...

> Uzytkownik "Marcin Wasilewski" <j...@a...pl> napisal w wiadomosci
> Rejestr Transmit Shift Register nawet nie miesci dwóch bajtów bo to
> rejestr 8 bitowy jest. Przesuwny ale nie FIFO.

Ale z twojego punktu widzenia co to za róznica?
Przyklad z programowania obiektowego, masz jakis obiekt, masz jakies metody
których uzywasz. Ale wazny dla Ciebie jest tylko to co tam wrzucisz na
wejscie i jaki uzyskasz skutek. To w jaki sposób uzyskujesz ten skutek, to
problem osoby piszacej klase. Co wiecej wcale nie jest powiedziane, ze
zawsze bedzie sie to odbywalo tak samo, wazne jest tylko to aby wejscie i
wynik dzialania byl zgodny z oczekiwaniami.

do góry

Uzytkownik "Marcin Wasilewski" <j...@a...pl> napisal w wiadomosci
news:innvsl$pgq$1@news.onet.pl...
> Uzytkownik "4CX250" <t...@p...onet.pl> napisal w wiadomosci
> news:innql6$tb9$1@news2.ipartners.pl...
>
>> Uzytkownik "Marcin Wasilewski" <j...@a...pl> napisal w
>> wiadomosci Rejestr Transmit Shift Register nawet nie miesci dwóch
>> bajtów bo to rejestr 8 bitowy jest. Przesuwny ale nie FIFO.
>
> Ale z twojego punktu widzenia co to za róznica?
> Przyklad z programowania obiektowego, masz jakis obiekt, masz jakies
> metody których uzywasz. Ale wazny dla Ciebie jest tylko to co tam
> wrzucisz na wejscie i jaki uzyskasz skutek. To w jaki sposób
> uzyskujesz ten skutek, to problem osoby piszacej klase. Co wiecej
> wcale nie jest powiedziane, ze zawsze bedzie sie to odbywalo tak
> samo, wazne jest tylko to aby wejscie i wynik dzialania byl zgodny z
> oczekiwaniami.

Sprawa sie juz wyjasnila. W sumie sprawca zamieszania bylem ja gdyz
najpierw myslalem ze to tylko UDR a potem
przekonalem sie ogladajac rysunki ze nie tylko ale nie zmienilem
"zeznan" i wyszlo co wyszlo.
Oczywiscie dla mnie jest to bez róznicy. Chodzilo tylko o zasade co do
nazwania jakiegos fragmentu funkcjonalnego w atmedze
aby ta nazwa byla adekwatna do sprawowanej funkcji:)
Nie mniej jednak dyskusja byla dla mnie pozyteczna gdyz bez poruszenia
tego tematu nie przeanalizowalbym szczególowo tego dziala datasheeta
:) po to aby wyjasnic zagadke rejestrów UDR oraz przesuwnego.
Co do samego programu to dziala od poludnia juz po pierwszym czytaniu
datasheeta. Wszystko mi ruszylo i mam komunikacje GPSa z atmega.

Marek

do góry

Uzytkownik "4CX250" <t...@p...onet.pl> napisal w wiadomosci
news:ino0ij$104r$1@news2.ipartners.pl...

> Oczywiscie dla mnie jest to bez róznicy. Chodzilo tylko o zasade co do
> nazwania jakiegos fragmentu funkcjonalnego w atmedze
> aby ta nazwa byla adekwatna do sprawowanej funkcji:)

Wiesz atmegi to dosc dziwne procki i przy wielu rzeczach mozna sie
zastanawiac czym sa w istocie.
Ot chocby takie rejestry danych procesora. Czym jest rejestr wszyscy wiemy,
ale w zasadzie mozna je traktowac tez jako komórki pamieci, bo jak wpiszemy
cos do komórki pamieci np. o adresie $0007, to o dziwo pojawi sie to nie
gdzie indziej jak tylko w rejestrze R7. Wiec jeden powie, ze zapisal bajt do
pamieci, ktos inny powie, ze do rejestru i obaj beda mieli racje.

W innym zas miejscu czesc rejestrów I/O procesora obsluguje sie typowo jak
dla obszaru I/O, czyli instrukcjami in, out, inna czesc rejestrów I/O jak
zwykle komórki pamieci i znowu jeden powie, ze to pamiec, ktos inny, ze to
rejestr i znowu w zasadzie kazdy bedzie mial troche racji.

do góry

Uzytkownik "Marcin Wasilewski" <j...@a...pl> napisal w wiadomosci
news:ino1bu$vag$1@news.onet.pl...

> Ot chocby takie rejestry danych procesora. Czym jest rejestr wszyscy
> wiemy, ale w zasadzie mozna je traktowac tez jako komórki pamieci,
> bo jak wpiszemy cos do komórki pamieci np. o adresie $0007, to o
> dziwo pojawi sie to nie gdzie indziej jak tylko w rejestrze R7. Wiec
> jeden powie, ze zapisal bajt do pamieci, ktos inny powie, ze do
> rejestru i obaj beda mieli racje.

Wczesniej siedzialem w starszych C'51. Tam jest to samo.
Obszary adresowane bitowo lub bajtowo a w nich rejestry.

> W innym zas miejscu czesc rejestrów I/O procesora obsluguje sie
> typowo jak dla obszaru I/O, czyli instrukcjami in, out, inna czesc
> rejestrów I/O jak zwykle komórki pamieci i znowu jeden powie, ze to
> pamiec, ktos inny, ze to rejestr i znowu w zasadzie kazdy bedzie
> mial troche racji.

Ja dotychczas tylko w asemblerze sie tluklem i tylkow starych C51 oraz
takich wynalazkach jak np.8055, 8042, 8039.
Od paru tygodni jednak postanowilem zmienic procki na atmega no i
przejsc na C.
Nie wiem dlaczego i czym to idzie ale jak analizuje listingi w asm to
mi szybciej idzie zrozumiec co mial na mysli autor niz w C.
Dochodzilo do takich nieraz sytuacji ze potrafilem np. zdesasemblowac
program telefonu NMT450 po to aby sie dowiedziec jak programuje sie
liczniki petli PLL której akurat datasheetu nie moglem zdobyc.
Jedyne co tylko bylo upierdliwe dla mnie w asm to arytmetyka
zmiennoprzecinkowa. Robilo sie na rózne zamienne sposoby.
No ale trzeba isc z duchem czasu stad moje parcie na avr gcc. Wiem ze
sa lepsi programisci ale ja uparty jestem.

Marek

do góry