Witam,

od kilku dni usilnie próbuje uruchomić kod z BB dotyczącego bufora cyklicznego na ATtiny4313. Jednak gdy próbuje odczytać dane, które wysyłam poprzez RealTerm czy też Putty, uC nic nie zwraca lub zwraca krzaki. Czy jest szansa na pomoc ze strony forum? Bardzo dziękuje za każdą pomoc.

A oto kod programu:
main.c


kod ukryto

}[/syntax]

Jeśli widzisz jakieś krzaki to jest pół sukcesu. Procesor coś wysyła ale prawdopodobnie nie masz ustawionych zgodnie parametrów transmisji i stąd krzaki. Zacząłbym od wysyłaniu jednego znaku i odebrania go na terminalu. Nie jest to może odkrywcza porada . Poza tym pod mam wrażenie że sei(); dałbym po zakończeniu wszystkich init_ szczególnie za inicjalizacją uarta.

_________________
Jestem na GG 31324
Nowy soft, nowa nadzieja.

Jeśli chodzi o wysyłanie danych na terminal to nie ma z tym najmniejszego problemu. Aktualnie przerobiłem trochę kod i wygląda on następująco:




Efekt uruchomienia programu jest widoczny na obrazku. Program zatrzymuje się ponieważ w buforze cały czas dostaje zera tak jakby zostawał cały czas w funkcji pobierającej jeden bajt z bufora.

Po pierwsze to obserwuj dane w hexie i w ascii - jest łatwiej. Po drugie polecam zakup prostego analizatora stanów logicznych, dzięki któremu będziesz miał możliwość sprawdzić m.in. z jaką tak naprawde prędkością nadajesz/odbierasz znaki +mnóstwo innych ciekawych funkcji przydatnych w codziennej pracy elektronika.

Niestety problem wciąż występuje... wygląda to tak jakby procesor był resetowany za każdym uruchomieniem USART.

Restart może występować gdy masz włączone jakieś przerwanie a wektor przerwania jest pusty.

_________________
Jestem na GG 31324
Nowy soft, nowa nadzieja.

Z tego co pamiętam to Mirek wspominał żeby właśnie po uruchomieniu przerwania umieścić choć pustą obsługę tego przerwania, żeby właśnie nie zachodziły dziwne rzeczy. Wrzuciłem ten program na ATMege328P i wciąż to samo.

No właśnie o tym pisałem. Czy masz te "puste" obsługi przerwań? Po gdy nie masz, to wektor takiego nie pustego przerwania wskazuje na restart.

_________________
Jestem na GG 31324
Nowy soft, nowa nadzieja.

Popatrz na ten zapis



Zapisujesz znak do Data_Buffer[0]
A wysyłasz znak z Data_Buffer[1]
Tylko że niewiesz jaki tam jest znak, bo nigdy nie zapisujesz do Data_Buffer[1] bo przed robisz cnt++

Jesli chodzi o niby zatrzymanie sie programu że śle same zera to patrz to



Zawsze zwraca zero jeśli bufor cykliczny pusty z funkcji pobierającej znak

A Ty na to zero nie reagujesz że pusty bufor i wysyłasz dalej same zera.

.

Poprawiłem składnie pętli która pobierała znaki (usunięcie cnt++), jednak jak w takim razie uniknąć tego zapychania zerami? Jeżeli chce przesłać dane, ale dopiero po uruchomieniu. Gdy tylko wyślę coś na terminal dostaję krzaki lub bezsensowne znaki. Co do przerwań to tak mają puste ciała jeśli są już wywoływane.

Zapychania zerami hmm,
to jest info że bufor pusty, a to jaki to będzie znak to już Ty decydujesz i jak będziesz na niego reagował żeby właśnie kiedy masz pusty bufor to kończysz odbieranie znaków z bufora cyklicznego.

.

Gdy wgrałem ten oto kod bufor kompletnie nie reaguje na dane wysyłane przez terminal, nie wysyła nawet zer które poprzednio się pojawiały.

Witaj,

Kolego, zacznij od najprostrzego kodu. Wywal te wszystkie PWM-y, i2c itp, itd i uruchom poprawnie samą transmisje UART.
Jaką wartość ma to _MYUBRR ?

Podepnij diodę pod jedną z wolnych nóżek procka. W funkcji przerwania UART od odbierania znaku, dopisz sobie przełączanie pinu z podpiętym LED-em i będziesz widział, czy przerwanie od odebranej danej z UART się w ogóle wykonuje. Ten fakt pokaże migający LED.

Co do kodu, zauważ, że wszystko, co jest w tym warunku:

się nie wykona, jeżeli nie wystąpi przerwanie od odebranej danej z UART-a.
Jeżeli nie wystąpi przerwanie od odebranej danej, to wskaźniki RX/TX położenia danych w buforze będą równe, co z kolei powoduje, że w tym miejscu:

do zmiennej Data_Flag zawsze będzie wpisywana wartość 0, jako wynik zwracany przez USART_Get_Rx_Byte();

Zacznij naukę od samego początku książki BB, bo widzę, że nie masz pojęcia co te kody, które wklejasz robią. Tak się nie da, nawet z pomocą kolegów z forum.

_________________
Pozdrawiam,
sq8mvy, Paweł

Tak jak kolega wyżej napisał robisz coś po omacku kopiuj wklej, miałeś _UBRR a potem zmieniasz na _MYUBRR i nie działa,

Kolega wyżej dobrze podpowiada idź tą ścieżka nauki

.

Po pierwsze to wynika to z tego że testuje róże wersje bibliotek na moim urządzeniu, nie ma fizycznej możliwość wpięcia się w układ ponieważ jest to gotowy układ na PCB. Po drugie gdy teraz umieściłem kody w tablicy a następnie przesłałem je przy pomocy funkcji PutC do bufora w rezultacie dostaję mniej danych niż zostało zadeklarowane.



Usunięcie pozostałych funkcji również nic nie zmienia.

A oto efekt działania pętli:


Wygląda to tak jakby wywołanie jakiejkolwiek funkcji związanej z USARTem powoduje częściowe zapełnienie bufora cyklicznego jednak, po jednokrotnym wykonaniu pętli while(1) cały program staje.

Co do wartości która podane jest jako _MYUBRR to obliczona jest ona następująco:
#define USART_BAUD 9600
#define _MYUBRR (((F_CPU + USART_BAUD*8UL)) / (16UL*USART_BAUD) - 1)

Natomiast jeśli usunę: USART_PutS("Start\r");
To na termialu otrzymuje:


Czyli tak jakby więcej danych niż powinienem oczekiwać.

Więc skup się na jednej wersji biblioteki, ale ze zrozumieniem, co ona robi, i ją w pełni uruchom.
Następnie wyrzuć z kodu to:

Bo to jest całkowicie nie potrzebne na razie.


Mam rozumieć, że cały układ jest zalany jakąś masą i masz wyprowadzony na zewnątrz tylko Rx i Tx ?
Nie można podejść do ścieżek, z miernikiem, jakimś analizatorem stanów logicznych czy oscyloskopem ?

Weź na boku, nawet na stykówce uruchom podstawowy układ z Atmegą i tam uruchamiaj komunikację z UART-em. Następnie działającą bibliotekę przenieś do docelowego układu.

_________________
Pozdrawiam,
sq8mvy, Paweł

Z całym szacunkiem, ale testujesz biblioteki których kompletnie nie znasz, nie wiesz co w nich się dzieje, jest czegoś za mało za dużo, niewiesz na jaką wielkość jest ustawiony bufor odbiorczy czy wysyłając.

Tak sie kończy właśnie szukanie cudu, a potem nie działa, albo działa, ale nie tak jak byś oczekiwał,

Znajomość bibliotek to podstawa żeby z nich umieć skorzystać.

Masz BB tam jest libs do uart, Mirek dobrze go opisał w BB i jeszcze są przykłady/objasnienia na YT korzystaj z pewniaków które działają 100/100, albo napisz swoją biblioteke.

.

Nie jest zalany masą, miałem na myśli brak możliwości ingerencji w strukturę układu, za chwilę zabieram się za napisanie tego od nowa miejmy nadzieję że z lepszym skutkiem.

------------------------ [ Dodano po: 15 minutach ]

Nie wmawiaj mi ze nie wiem jak działa ta biblioteka to po prostu kolejka FIFO, tylko ze znak CR ma za zadanie wykrycie końca ramki. Testuje z tego względu ponieważ układ się blokuje a skoro opiera się o przerwania to powinien działać swobodnie w tle. Napisze to jeszcze raz ale od zera tak jak wspomniałem wyżej.

Kolego forum Atnel to nie takie same forum jak elek... w której miałbyś odp że temat był wałkowany miliony razy poszukaj sobie zamykam temat i do kosza.

Przepraszam jeśli odebrałeś to jakoś opacznie, ja nie miałem złych intencji, poprostu widać że nie znasz "czyjeś" biblioteki do UART-a, odsyłamy do BB mega kopalnia wiedzy, do Mirkowego YT naprawdę to jest ogromna kopalnia wiedzy, a nie złośliwość że trzeba oglądnąć poradnik czy poczytać BB, to jest dobra rada nic złośliwego.

.

Ja również przepraszam, po prostu frustracja i brak snu nie pozwala mi myśleć racjonalnie, dziękuje za dotychczasową pomoc i zabieram się jeszcze raz do pracy.

Więc zacznij od wypoczęcia. Kiedy umysł jest zmęczony, nie wyspany, to nie funkcjonuje poprawnie. Wtedy banalnie proste rzeczy stają się wręcz nie do rozwiązania. A tak się nie da, bez względu ile kaw czy tigerów byś nie wypił, bedziesz stał w miejscu z rozwiązaniem problemu.

Odejdź od projektu, odpocznij, prześpij się z tematem.....

_________________
Pozdrawiam,
sq8mvy, Paweł

A więc tak kod obsługi wygląda dokładnie tak jak jest to opisane w BB:




Oraz plik main.c


A więc tak, założyłem że w pierwszej kolejności w sposób sztuczny umieszczę dane w buforze przy pomocy funkcji USART_PutC, następnie w pętli for umieszczonej przed pętlą while sprawdzę czy jestem w stanie cokolwiek odczytać. W pierwszej linii terminalu wyraźnie dostrzegam znaki ASCII które zostały prze zemnie zadeklarowane w tablicy Data_to_send[], jednak po zakończeniu odczytu z bufora wciąż otrzymuje jeszcze kolejne komunikaty o braku danych w buforze co jest prawdą ponieważ dane zostały opróżnione przy pomocy drugiej pętli for?



Czy w tym momencie transmisja przebiegła poprawnie? Według mnie tak, tylko należało by teraz zmusić układ do pracy kiedy tych danych jeszcze nie otrzymał, ponieważ przy braku zapełnienia bufora wstępnymi wartościami zera pochodzące z warunku poniżej zamazują bufor?

Nic w buforach nie nadpiszesz, bo taki jest mechanizm w bibliotece, której używasz. Nawet, jak bufor TX będzie miał 2 bajty, to wyślesz bez problemu całą tablicę -sprawdź sam.

W buforze RX, jak się cały zapełni ( nie będziesz odczytywał nadchodzących danych ) nie nadpisze już odebranych danych, tylko wyśle informację zwrotną do terminala o zapełnieniu bufora RX, a nadchodzące kolejne dane zostaną utracone. Taki stan będzie trwał do czasu, aż zaczniesz odczytywać dane z bufora odbiorczego.

Musisz zmienić trochę myślenie. Staram się zrozumieć, co chcesz uzyskać, ale nie potrafię.
Popatrz na spokojnie na bibliotekę od obsługi UART i przeanalizuj mechanizmy w niej zawarte, bo nie wiesz, co tam się dzieje.

Pętle wykonują się jedna po drugiej.
Najpierw wysyłasz - pierwsza pętla - widać, że wszystko zostało wysłane - pierwsza linia w terminalu, a następnie w drugiej pętli:
- sprawdzasz, czy jest coś do odebrania. Jak nic nie będzie w buforze odbiorczym ( nic nie wyślesz z terminala), to funkcja zwróci wartość "0" i wyśle na terminal tekst "Brak danych"
- ta wartość zwrócona zostanie zamieniona na liczbę jako tekst i wysłana na terminal.
Druga pętla wykona się 8 razy, co widać w terminalu i po zakończenio wejdzie w ostatnią pętlę nieskończoną while(1)

Wszystko działa, tak jak oprogramowałeś, biblioteka zachowuje się poprawnie.

_________________
Pozdrawiam,
sq8mvy, Paweł

RychuER, wrzucasz na forum biblioteki z BB?

Biblioteka nie jest taka sama jak w BB, nie wiedziałem że nie można umieszczać tych kodów.

EDIT:
Przekazałem już informację z prośbą o edycję lub usunięcie.

_________________
Zbuduj swój system [url=https://helion.pl/ksiazki/w-labiryncie-iot-budowanie-urzadzen-z-wykorzystaniem-ukladow-esp8266-i-esp32-andrzej-gromczynski,wlablo.htm#format/d]IOT[/url]

Pewnie jesteś na wyższym poziomie, ale dla relaksu rzuć okiem na http://jaktodziala.eu/jak-dziala-bufor-cykliczny/.

Dzięki pomocy gizmo udało się uruchomić poprawnie bufor cykliczny, jednak mam pewien problem ponieważ próbuje aktualnie dostosować bufor do swoich potrzeb a mianowicie, zależy mi na wysłaniu ramki danych w takiej postaci:
|Adres urządzenia| Kod funkcji do wykonania | Dane funkcji | Znak stopu = CR|

Jednak jak należy w sposób poprawny zdekodować ramkę aby móc przekazać jej odpowiednie pola danych do dalszych funkcji?

Próbowałem dokonać tego w taki sposób:


Jednak przy próbie wysłania danych przez RealTerm dostaje ramke uprzednio wypełnioną zerami a następnie dopiero moje dane np. 00000001APM255.

Z góry dziękuje za pomoc.

Zauważ, że jeżeli byte jest równe 0 to funkcja Frame_Check też Ci się wykona.
Może to dlatego?

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

Jeżeli dobrze myślę muszę w jakiś sposób najpierw wypełnić bufor danymi które przesyłam a dokładnie max 16 bajtów, ale zapisywać tylko w przypadku gdy coś się w nich znajdzie innego niż zero?