<?xml version="1.0" encoding="UTF-8"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="pl-pl">
<link rel="self" type="application/atom+xml" href="https://forum.atnel.pl/feed.php?f=4&amp;t=1920&amp;mode" />

<title>ATNEL tech-forum</title>
<link href="https://forum.atnel.pl/index.php" />
<updated>2012-12-13T22:42:37+01:00</updated>

<author><name><![CDATA[ATNEL tech-forum]]></name></author>
<id>https://forum.atnel.pl/feed.php?f=4&amp;t=1920&amp;mode</id>
<entry>
<author><name><![CDATA[SunRiver]]></name></author>
<updated>2012-12-13T22:42:37+01:00</updated>
<published>2012-12-13T22:42:37+01:00</published>
<id>https://forum.atnel.pl/viewtopic.php?t=1920&amp;p=21121#p21121</id>
<link href="https://forum.atnel.pl/viewtopic.php?t=1920&amp;p=21121#p21121"/>
<title type="html"><![CDATA[Re: Czy dobrze zrozumiałem odbiór w RS232C? str. 268]]></title>

<content type="html" xml:base="https://forum.atnel.pl/viewtopic.php?t=1920&amp;p=21121#p21121"><![CDATA[
W zasadzie można , ale to trochę takie bezcelowe jest ... przecież wygodniej jest testować połączenie AVR-&gt;PC <br />a i wygoda większa <img src="https://forum.atnel.pl/images/smilies/icon_e_smile.gif" alt=":)" title="Szczęśliwy" /><p>Statystyki: Napisane przez <a href="https://forum.atnel.pl/memberlist.php?mode=viewprofile&amp;u=58">SunRiver</a> — 13 gru 2012, o 22:42</p><hr />
]]></content>
</entry>
<entry>
<author><name><![CDATA[mirekk36]]></name></author>
<updated>2012-12-13T22:33:06+01:00</updated>
<published>2012-12-13T22:33:06+01:00</published>
<id>https://forum.atnel.pl/viewtopic.php?t=1920&amp;p=21119#p21119</id>
<link href="https://forum.atnel.pl/viewtopic.php?t=1920&amp;p=21119#p21119"/>
<title type="html"><![CDATA[Re: Czy dobrze zrozumiałem odbiór w RS232C? str. 268]]></title>

<content type="html" xml:base="https://forum.atnel.pl/viewtopic.php?t=1920&amp;p=21119#p21119"><![CDATA[
No ale przede wszystkim czy nie łatwiej te testy wykonać pomiędzy prockiem i terminalem w windows ? na to samo wyjdzie <img src="https://forum.atnel.pl/images/smilies/icon_e_wink.gif" alt=";)" title="Puszcza oko" /><p>Statystyki: Napisane przez <a href="https://forum.atnel.pl/memberlist.php?mode=viewprofile&amp;u=54">mirekk36</a> — 13 gru 2012, o 22:33</p><hr />
]]></content>
</entry>
<entry>
<author><name><![CDATA[mg101]]></name></author>
<updated>2012-12-13T20:38:26+01:00</updated>
<published>2012-12-13T20:38:26+01:00</published>
<id>https://forum.atnel.pl/viewtopic.php?t=1920&amp;p=21113#p21113</id>
<link href="https://forum.atnel.pl/viewtopic.php?t=1920&amp;p=21113#p21113"/>
<title type="html"><![CDATA[Re: Czy dobrze zrozumiałem odbiór w RS232C? str. 268]]></title>

<content type="html" xml:base="https://forum.atnel.pl/viewtopic.php?t=1920&amp;p=21113#p21113"><![CDATA[
Dzięki<br />Czyli z grubsza szedłem właściwą drogą.<br />Mam jeszcze jedno pytanie. Czy można zrobić doświadczenie np. takie że nadawany jest stan klawisza jednego mikrokontrolera który będzie odbierany przez drugi mikrokontroler i będzie zapalał diodę. Oczywiście że można. Ale np nie chcę się bawić w montaż drugiej płytki z 644p z kwarcem,fusebitami itd? Czy jest sens zasymulowania tego na 2 UART-ach tego samego 644p? Tzn. czy można traktować że sygnał wyjdzie na &quot;zewnątrz&quot; z jednego UART-u i i wejdzie do drugiego? I czy ten drugi UART będzie się zachowywał tak jakby był w osobnym 644p?<p>Statystyki: Napisane przez <a href="https://forum.atnel.pl/memberlist.php?mode=viewprofile&amp;u=683">mg101</a> — 13 gru 2012, o 20:38</p><hr />
]]></content>
</entry>
<entry>
<author><name><![CDATA[mirekk36]]></name></author>
<updated>2012-12-13T19:53:47+01:00</updated>
<published>2012-12-13T19:53:47+01:00</published>
<id>https://forum.atnel.pl/viewtopic.php?t=1920&amp;p=21111#p21111</id>
<link href="https://forum.atnel.pl/viewtopic.php?t=1920&amp;p=21111#p21111"/>
<title type="html"><![CDATA[Re: Czy dobrze zrozumiałem odbiór w RS232C? str. 268]]></title>

<content type="html" xml:base="https://forum.atnel.pl/viewtopic.php?t=1920&amp;p=21111#p21111"><![CDATA[
<div class="quotetitle">mg101 napisał(a):</div><div class="quotecontent"><br />Uważam bufor cykliczny ma sens tylko wtedy gdy:<br /></div><br /><br />Ja bym powiedział zdecydowanie inaczej. Bufor cykliczny ma zawsze sens, jest potrzebny w 99,999999999999% przypadków a ten, 0,0000000000000001% przypadków możemy pominąć w naszych rozważaniach.<br /><br />Przy czym ważna rzecz - mówię tu o buforze cyklicznym ODBIORCZYM ... !!! WAŻNE !!! ... bo nadawczy rzeczywiście w wielu przypadkach możemy pominąć.<br /><br />Dalsze twoje rozważania odnośnie działania opisanego mechanizmu są poprawne...<br /><br />Na koniec zadajesz typowe pytanie po przeczytaniu I-szej książki, ponieważ nagle urywa się opis transmisji UART, o ile jest i ładnie działa nadawanie to już z odbieraniem wielu ludzi ma problem. Na szczęście są dwa rozwiązania:<br /><br />1. tu na forum już kilku kolegów się pokusiło i z moją lekką pomocą napisali sobie odbieranie stringów ... jak znajdę ten wątek to go tutaj wkleję<br /><br />2. w II-giej książce - jest to już ABSOLUTNIE i pięknie do końca opisane jak odbierać stringi <br /><br />ale pytasz - skąd procesor ma wiedzieć, że już może zrobić uart_getc() ?<br /><br />no może zrobić kiedy mu się tylko spodoba ale trzeba sobie to dalej już jakoś właśnie oprogramować - bo tego pierwsza książka nie opisuje. Kończę w niej na wyjaśnieniach tak istotnych rzeczy jak prawidłowe podejście do odbioru w przerwaniach do buforów cyklicznych - co bardzo ładnie opisałeś swoimi słowami/przykładami<br /><br />a teraz podpowiedź - gdybyś dalej chciał sam tworzyć odbiór stringów - bo tak polecam podejść.<br /><br />1. Pomyśl sobie - skoro mowa o stringu np wysłanym z terminala to zwykle zakończony on będzie znakiem CR (enter)<br /><br />2. skoro wpadnie 17 bajtów do bufora to 17 albo 18 będzie właśnie Enter<br /><br />3. można więc już na etapie przerwania odbiorczego zliczać sobie ilość Enterów które wpadły do bufora  cyklicznego a w programie głównym sprawdzać. I jak jest ich więcej niż 0 to pobierać całą linię z bufora za pomocą getc() aż do znaku ENTER, który trzeba pominąć.<br /><br />Dzięki takiemu mechanizmowi - nie musisz się martwić przestojami w programie głównym - bo gdyby był czymś zajęty i nie zdążył odebrać jednego stringa i nagromadziłoby się ich tam (w zależności oczywiście od wielkości bufora cyklicznego) kilka czy kilkanaście - to jak w końcu się dorwiesz to możesz naraz je wszystkie obsłużyć<br /><br />Pisałeś też że inny mikrokontroler wolno nadaje ....<br /><br />to nie wynika z mikrokontrolera i jego chęci, bo tak samo może być z terminala. To wynika z prędkości baudrate, które są o wiele wiele wolniejsze niż możliwości wykonywania w tym samym czasie niezliczonych operacji przez mikrokontroler.<p>Statystyki: Napisane przez <a href="https://forum.atnel.pl/memberlist.php?mode=viewprofile&amp;u=54">mirekk36</a> — 13 gru 2012, o 19:53</p><hr />
]]></content>
</entry>
<entry>
<author><name><![CDATA[mg101]]></name></author>
<updated>2012-12-13T18:27:07+01:00</updated>
<published>2012-12-13T18:27:07+01:00</published>
<id>https://forum.atnel.pl/viewtopic.php?t=1920&amp;p=21100#p21100</id>
<link href="https://forum.atnel.pl/viewtopic.php?t=1920&amp;p=21100#p21100"/>
<title type="html"><![CDATA[Czy dobrze zrozumiałem odbiór w RS232C? str. 268]]></title>

<content type="html" xml:base="https://forum.atnel.pl/viewtopic.php?t=1920&amp;p=21100#p21100"><![CDATA[
Uważam bufor cykliczny ma sens tylko wtedy gdy:<br />- przez względnie dłuższy czas „napełnia się” bajtami z innego mikrokontrolera,<br />- potem bardzo szybko kawałek naszego programu opróżnia bufor cykliczny (czytając go)<br /><br />Czy zarys ewentualnego programu jest prawidłowy? <br />Albo inaczej - czy zależności czasowe między <strong>get(c)</strong> a <strong>ISR(USART_RXC_vect)</strong> mogą być np. takie?<br />….. tu program robi różne<br />….. rzeczy nie związane <br />….. z RS232C<br /><strong>Przeczytaj 17 bajtów z innego mikrokontrolera</strong>  tu program wpada na pomysł przeczytania 17 bajtów z innego mikrokontrolera. Wysyła więc żądanie po RS do innego mikrokontrolera i dalej robi swoje.<br />A teraz proszę Państwa po pewnym czasie zaczyna się dziać, gdyż inny mikrokontroler rozpoczął nadawanie 17 bajtów.<br /><strong>ISR(USART_RXC_vect)</strong> przerwanie bo przyszedł pierwszy z 17 bajtów W buforze cyklicznym  pokaże się „jednobajtowy” wąż składający się tylko z głowy. <br /><strong>ISR(USART_RXC_vect)</strong> przerwanie bo przyszedł drugi z 17 bajtów W buforze pokaże się „dwubajtowy” wąż  <br /><strong>ISR(USART_RXC_vect)</strong>przerwanie bo przyszedł trzeci z 17 bajtów W buforze pokaże się „trzybajtowy” wąż  <br />….. <br />…..  <br /><strong>ISR(USART_RXC_vect)</strong> przerwanie bo przyszedł ostatni z 17 bajtów W buforze pokaże się „siedemnastobajtowy” wąż <br /><br /><strong>getc() </strong>                      pierwsza instrukcja opróżniająca bufor cykliczny <br /><strong>zapisz_gdzieś</strong>         <br /><strong>getc()</strong>          druga instrukcja opróżniająca bufor cykliczny <br /><strong>zapisz_gdzieś</strong>…..<br />…...<br /><strong>getc()</strong>                        ostatnia instrukcja opróżniająca bufor cykliczny<br /><strong>zapisz_gdzieś</strong>                               <br />Bufor cykliczny jest znowu pusty i 17 bajtów zostało gdzieś zapisane<br />Oczywiście instrukcje ISR pojawiają się w tle. (nie piszemy ich 17 razy!) „Między nimi” program może robić różne inne rzeczy. 17 instrukcji getc() i 17 zapisz_gdzieś jest zwykle  zawarte w jednej instrukcji czytającej całego stringa. Przerwanie od pierwszego z 17 bajtów powstanie bezproblemowo – przecież UDR UART-u na początku jest puste!<br />Milcząco przyjąłem też założenie, że inny mikrokontroler dosyła nowe bajty stosunkowo wolno w porównaniu do szybkości zapisywania bufora cyklicznego. Czyli  zanim przyjdzie następny bajt z innego mikrokontrolera to poprzedni bajt zostanie błyskawicznie przepisany z UDR do bufora cyklicznego. Nie ma to nic wspólnego z getc()!<br />Powstaje pytanie. Skąd program ma wiedzieć kiedy zrobić pierwsze get(c)? Na pewno nie poprzez zapełnienie do końca bufora cyklicznego. Przecież ma on odebrać 17 a nie  32 bajty.  Idealnie byłoby przerwanie od ostatniego 17 bajtu. A może informacja że inny mikrokontroler zakończył transmisję? <br />Tak czy owak to wszystko pomiędzy <strong> Przeczytaj 17 bajtów z innego mikrokontrolera</strong>  a ostatnim<strong> getc()</strong> powinno być zawarte w jednej instrukcji która przeczyta 17 bajtów z innego  mikrokontrolera.<p>Statystyki: Napisane przez <a href="https://forum.atnel.pl/memberlist.php?mode=viewprofile&amp;u=683">mg101</a> — 13 gru 2012, o 18:27</p><hr />
]]></content>
</entry>
</feed>