ATNEL tech-forum

Re: MK_MULTI_UART - odbieranie binarne z 9-bitami

2020-04-14T20:44:31+01:00

odpisałem na maila

Statystyki: Napisane przez mirekk36 — 14 kwi 2020, o 20:44

Re: MK_MULTI_UART - odbieranie binarne z 9-bitami

2020-04-14T20:28:22+01:00

wysłałem

Statystyki: Napisane przez Nef.ID — 14 kwi 2020, o 20:28

Re: MK_MULTI_UART - odbieranie binarne z 9-bitami

2020-04-14T20:04:03+01:00

hmmm podeślij mi na biuro@atnel.pl tę bibliotekę którą otrzymałeś od nas ? bo coś mi tu nie pasuje

Statystyki: Napisane przez mirekk36 — 14 kwi 2020, o 20:04

Re: MK_MULTI_UART - odbieranie binarne z 9-bitami

2020-04-14T20:07:49+01:00

Jeszcze raz napiszę odnośnie powyższego wpisu Mirka o "zmodyfikowanych" wersjach biblioteki przeze mnie:
Mam wersję biblioteki v.1.1
I taką informację w consoli:
[syntax=c]'Invoking: AVR Compiler'
avr-gcc -Wall -Os -fpack-struct -fshort-enums -ffunction-sections -fdata-sections -std=gnu99 -funsigned-char -funsigned-bitfields -mmcu=atmega1284 -DF_CPU=11059200UL -MMD -MP -MF"MK_MULTI_UART/mk_multi_uart.d" -MT"MK_MULTI_UART/mk_multi_uart.o" -c -o "MK_MULTI_UART/mk_multi_uart.o" "../MK_MULTI_UART/mk_multi_uart.c"
../MK_MULTI_UART/mk_multi_uart.c: In function '__vector_28':
../MK_MULTI_UART/mk_multi_uart.c:650:5: error: 'dataH' undeclared (first use in this function)
dataH = (UCSR1B & (1< 0;
^
../MK_MULTI_UART/mk_multi_uart.c:650:5: note: each undeclared identifier is reported only once for each function it appears in
../MK_MULTI_UART/mk_multi_uart.c:651:5: error: 'dataL' undeclared (first use in this function)
dataL = UDR1; //pobieramy natychmiast bajt danych z bufora sprzętowego
^[/syntax]
Natomiast w pliku multi_usart_c mam:
[syntax=c]ISR( USART1_RX_vect ) {

#if UART1_DATA_BITS == 9

register TUART_BUF_8_16 tmp_head;
register uint16_t data;

uarttab[1]->bin = 1;// wymuszenie obsługi binarnej

dataH = (UCSR1B & (1< 0;
dataL = UDR1; //pobieramy natychmiast bajt danych z bufora sprzętowego

// obliczamy nowy indeks „głowy węża”
tmp_head = ( uarttab[1]->rxHead + 1) & uarttab[1]->rxMask;

// sprawdzamy, czy wąż nie zacznie zjadać własnego ogona
if ( tmp_head == uarttab[1]->rxTail ) {
// możliwa własna reakcja na utratę nadmiarowych danych
uarttab[1]->rxHead = uarttab[1]->rxTail;
uarttab[1]->ascii_frame_cnt = 0;
} else {
uarttab[1]->rx9Buf[ uarttab[1]->rxHead ] = (dataH<<8) | dataL; // xxx[/syntax]
Dlatego też musiałem wprowadzić te zmiany(o których pisałem), żadnych innych, bo
a/ nie znam się na tyle, by czegoś nie spieprzyć
b/ nie wiem do końca, co autor miał na myśli.
Dlatego też podałem to wszystko, by upewnić się co do słuszności, bo widać, że plik nie zna zmiennych dataH i dataL.

Statystyki: Napisane przez Nef.ID — 14 kwi 2020, o 19:53

Re: MK_MULTI_UART - odbieranie binarne z 9-bitami

2020-04-14T15:35:44+01:00

Nef.ID napisał(a):

Zresztą co widać na załączonym obrazku - 1 bit =52 usek, 2 bity 104 usek, 3 bity to 157 usek.

Lubisz sobie utrudniać życie - toż masz w programie LOGIC za darmo pełno analizatorów w tym podstawowy do RS232, zobacz - a tu ja nadaję ramkę testową i gdybym zadawał pytanie na forum to bym pokazał taki przebieg z Saleaez włączonym analizatorem zamiast bawić się w czasówki - nie ważne jaka prędkość

więc u mnie nadaje sobie ATmega32 tak:

nic dodać nic ująć - widać wszystko jak BYK, na dłoni albo jak na patelni ... (i dlatego myśl Pan o takich testach NAJPROSTSZYCH i używaniu analizatorów protokołów) na przyszłość

zaraz sprawdzę odbieranie

------------------------ [ Dodano po: 34 minutach ]

proszę bardzo - a dla utrudnienia dodałem przesyłanie dwóch ramek jedna po drugiej co ok 500ms, tak wyglądają na analizatorze w saleae

no i proszę na dwóch zestawach ATB to śmiga, żeby było ciekawiej to nadawca jest na m32 zaś odbiorca na m1284P

------------------------ [ Dodano po: 37 minutach ]

pętla główna nadawcy:

[syntax=c]while(1) {
UART_RX_EVENT();

if( !Timer1 ) {
Timer1 = 50;
uart_put_9bit( 0, 0x0041 );
uart_put_9bit( 0, 0x0042 );
}
}[/syntax]

a u odbiorcy wygląda to tak:

[syntax=c]uart_reg_callback_bin9( 0, rx0buf9, 2, parse9 );

while(1) {
UART_RX_EVENT();
}[/syntax]

zaś sama funkcja parsująca "parse9"

[syntax=c]void parse9( void * buf, uint8_t size ) {

uint16_t * wsk = buf;

lcd_cls();
lcd_str("znaki: ");
lcd_char( wsk[0] );
lcd_char( wsk[1] );
lcd_locate( 1,0 );
lcd_str("size: ");
lcd_int( size );
}[/syntax]

------------------------ [ Dodano po: 39 minutach ]

więc jak widzisz wszystko śmiga, gra i buczy ... dlatego prosiłem cię zrób najprostsze testy jednostkowe - zrób tak jak ja tutaj ... i sprawdź czy ci to działa - a jeśli nie to znaczy, że gdzieś babola robisz ale gdzie ? tego nie wiem po tym opisie .... przetestuj na dwóch prockach i pokaż swoje rezultaty

------------------------ [ Dodano po: 40 minutach ]

aha na zakończenie dodam, że testy prowadziłem na tej bibliotece ze sklepu a nie na jakichś swoich nowszych zmodyfikowanych wersjach tej biblioteki - bo niedługo ukaże się nowa wersja i będzie miała DUŻO lepsze pracy z transmisją binarną.

Statystyki: Napisane przez mirekk36 — 14 kwi 2020, o 15:35

Re: MK_MULTI_UART - odbieranie binarne z 9-bitami

2020-04-14T15:01:25+01:00

Dobrze, urządzenie, które nadaje ramki 9-bit i wiem co nadaje, dokładnie obejrzałem analizatorem Saleae. I takie same tj. 9-bitowe nadaję. Zresztą co widać na załączonym obrazku - 1 bit =52 usek, 2 bity 104 usek, 3 bity to 157 usek.

Statystyki: Napisane przez Nef.ID — 14 kwi 2020, o 15:01

Re: MK_MULTI_UART - odbieranie binarne z 9-bitami

2020-04-14T14:37:51+01:00

No teraz to można popatrzeć na kod ... tylko na razie nie mam jak sprawdzić/potwierdzić - ale w międzyczasie zapytam bo pokazałeś tam na saleae czasy, zamiast pokazać wynik analizatora rs232 - dobrze zdekodował ramkę? jest poprawnie nadawana ?

i nie mówię o dwóch zestawach - nawet na stykówce niech jeden procek nadaje

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

a jak będę miał chwilkę to taki kodzik mogę wrzucić na przetestowanie i zobaczymy co i jak

Statystyki: Napisane przez mirekk36 — 14 kwi 2020, o 14:37

Re: MK_MULTI_UART - odbieranie binarne z 9-bitami

2020-04-14T13:29:23+01:00

Wysyłam, jak od samego początku piszę, tylko jedną ramkę. Oto ona, teraz to 0x0035:

Załączam jeszcze raz program testowy, ale już z powyrzucanymi wszystkimi dodatkowymi rzeczami, aby było prościej do analizy:
[syntax=c]#include
#include
#include

#include

#include "MK_MULTI_UART/mk_multi_uart.h"

#define SIZE_9BIT 32

char rx0buf[50];
uint16_t rx1buf[SIZE_9BIT];

void parsuj_uart0( void * buf, uint8_t size );
void parsuj_uart1( void * buf, uint8_t size );

int main( void ) {

DDRA |= (1<PORTA |= (1<
uart_init();
uart_reg_callback( 0, rx0buf, parsuj_uart0 );

uart_reg_callback_bin9( 1, rx1buf, 1, parsuj_uart1 );

sei();

while(1) {
UART_RX_EVENT();
}
}

void parsuj_uart0( void * buf, uint8_t size ) {

uint16_t *wsk;
wsk = rx1buf;

for( uint8_t i= 0; i
uart_put_9bit(1, 0x0035);
}

void parsuj_uart1( void * buf, uint8_t size ) {
uint16_t *wsk;
wsk = buf;

uart_putint( 0, *wsk , 16 );
send_crlf(0);
uart_putint( 0, size , 10 );
send_crlf(0);
}[/syntax]
W wyniku otrzymuję size=1, a z bufora 0.

Poprzednio pokazywałem też zawartość całego bufora odbiorczego, który przed odbiorem ramki zerowałem w całości, a po otrzymaniu jednego tylko znaku miałem w nim sieczkę, o dziwo zawsze taką samą.
PS. Mirek, rozumiem, drugi zestaw, ale moje urządzenie było już drugim urządzeniem, ale dobrze- zmontuję coś drugiego na testy.

------------------------ [ Dodano po: 16 minutach ]

Dodam tylko, że prędkość transmisji to 19200, jakby co.

Statystyki: Napisane przez Nef.ID — 14 kwi 2020, o 13:29

Re: MK_MULTI_UART - odbieranie binarne z 9-bitami

2020-04-14T09:48:35+01:00

Nef.ID napisał(a):

mam u siebie ATmege1284, a nie ATmege1284P

to po co ci inny procek - skoro ten też ma dwa UARTy ?

Nef.ID napisał(a):

3. wysyłam ramki 9-bitowe do urządzenia, urządzenie rozumie, przesyła właściwe odpowiedzi (oglądam na analizatorze Saleae).

zobacz jak nielogicznie piszesz i ciężko cię przez to zrozumieć - bo z tego pkt.3 wynika że niby ci wszystko działa

a tutaj:

Nef.ID napisał(a):

. tak jak pisałem, nie umiem odczytać zarówno odpowiedzi z urządzenia

no to o co chodzi ?

Po pierwsze jak spojrzałem na kod który pokazałeś to złapałem się troszkę za głowę - no bo jak można sprowadzić testy jednostkowe do czegoś takiego ?

Czy nie prościej napisać do TESTÓW najprostszy kod gdzie jeden procek będzie nadawał UWAGA! JEDNĄ i tylko JEDNĄ ramkę 9 bitową - a w drugim procku ją odbierać, czyli jedno słowo 16-bitowe ? No bo to co się dzieje u ciebie w tym parsowaniu .... to ... nie nie - to nie mam na tyle czasu żeby analizować tak dziwne rzeczy - tzn może nie dziwne ale nie mam czasu

Zrób prosty kod jak pisałem wyżej, sprawdź Saleae czy ramka ładnie wychodzi na drucie, a w funkcji parsującej odbierz słowo i w zależności od konkretnej wartości zapalaj albo gaś diodę LED, nie potrzebny do takiego testu nawet drugi UART i już można mieć PODSTAWY opanowane w 5 sekund albo zgłosić jakiś konkretny problem na najprostszym kodzie. Wtedy będzie można coś pomóc - ok ?

Statystyki: Napisane przez mirekk36 — 14 kwi 2020, o 09:48

Re: MK_MULTI_UART - odbieranie binarne z 9-bitami

2020-04-14T09:36:56+01:00

Dziękuję za odpowiedź,
1. oczywiście, że nie odbieram ramek z 9-bit terminalem, bo takiego nie mam i nawet nie mogę znaleźć.
2. mam drugie urządzenie, które wysyła te cholerne ramki, mam analizator Saleae i wszystko mogę podejrzeć.
3. wysyłam ramki 9-bitowe do urządzenia, urządzenie rozumie, przesyła właściwe odpowiedzi (oglądam na analizatorze Saleae).
4. mam u siebie ATmege1284, a nie ATmege1284P, ale to chyba nie stanowi (jeszcze sprawdzę czy mam pod ręką Atmege644P lub ATmege1584P, ale chyba nie).
5. tak jak pisałem, nie umiem odczytać zarówno odpowiedzi z urządzenia jak i jak i odpowiedzi gdy nadaję i odbieram (TXD2 do RXD2 bezpośrednio mostek).
6. gdzie tkwi mój błąd?

Statystyki: Napisane przez Nef.ID — 14 kwi 2020, o 09:36

Re: MK_MULTI_UART - odbieranie binarne z 9-bitami

2020-04-13T21:33:15+01:00

Ma tak być jak jest w bibliotece wszystko i nie zmieniaj bo wtedy narobisz sobie takiego bigosu - że ja na pewno nie pomogę bo jak?

Biblioteka DOSKONALE działa dla ramek 9-bitowych no ale trzeba takie mieć i nie spodziewaj się że to odbierzesz albo zobaczysz poprawnie w terminalu bo jak ? Na PC nie ma obsługi ramek 9-bit - więc coś bardzo mocno przekombinowałeś

zrób sobie dwa urządzenia tzn dwa procki i jeden niech do drugiego coś przesyła za pomocą 9-bit i będzie ci to ładnie śmigało. Albo weź sobie jednego procka z dwoma UART'ami np ATmega644P albo ATmega1284P i jednym UARTem gadaj sobie z drugim prockiem po 9-bit a drugim uartem wysyłaj sobie do terminala np wartości HEX odebranych ramek 9-bitowych

Statystyki: Napisane przez mirekk36 — 13 kwi 2020, o 21:33

Re: MK_MULTI_UART - odbieranie binarne z 9-bitami

2020-04-13T20:13:23+01:00

Chyba coś odkryłem w bibliotece:
[syntax=c]ISR( USART1_RX_vect ) {

#if UART1_DATA_BITS == 9

register TUART_BUF_8_16 tmp_head;
//register uint16_t data;MIREK-USUWAM
register uint16_t dataH, dataL;//MIREK-DOKLADAM

uarttab[1]->bin = 1;// wymuszenie obsługi binarnej

dataH = (UCSR1B & (1< 0;
dataL = UDR1; //pobieramy natychmiast bajt danych z bufora sprzętowego[/syntax]
Linia dataH =(UCSR1B & (1< 0; Co to jest? To chyba nie może działać.

------------------------ [ Dodano po: 2 minutach ]

To chyba tak ma być, bo w sumie w dataH jest jeden bit, 0 lub 1.

Statystyki: Napisane przez Nef.ID — 13 kwi 2020, o 20:13

MK_MULTI_UART - odbieranie binarne z 9-bitami

2020-04-13T15:13:48+01:00

Witam,
nie mogę poradzić sobie z odbiorem binarnym 9-bitów.
Układ:
zestaw z Atmega1284,
UART0 8,n,1,9600 -> komunikacja z terminalem
UART1 9,n,1,9600 -> komunikacja z urządzeniem

Dla testów podłączyłem TXD2 z RXD2 (pin PD2 z PD3). Wysyłam jeden znak i chcę go odebrać.

Jak wysyłanie jest OK, to z odbieraniem mam problem, nie umiem tego sparsować czy co.
Zrobiłem taki eksperyment:
Dla testów przed wysłaniem znaku zeruję bufor odbiorczy.
Po nadaniu sprawdzam zawartość tego bufora, a w nim pełno śmieci.

[syntax=c]#include
#include
#include

#include

#include "MK_MULTI_UART/mk_multi_uart.h"
#include "LCD/lcd44780.h"

char rx0buf[50];
uint16_t rx1buf[16];
uint8_t rx2buf[50];

void parsuj_uart0( void * buf, uint8_t size );
void parsuj_uart1( void * buf, uint8_t size );
void parsuj_uart2( void * buf, uint8_t size );

int main( void ) {

DDRA |= (1<PORTA |= (1<
// inicjalizacja UART
uart_init();
uart_reg_callback( 0, rx0buf, parsuj_uart0 );
//uart_echo( 0, 1 );

uart_reg_callback_bin9( 1, rx1buf, 1, parsuj_uart1 );
//uart_echo( 1, 1 );

//uart_reg_callback_bin( 1, rx2buf, 1, parsuj_uart2 );
//uart_echo( 1, 1 );

sei();

//tr_intro( 0 );
lcd_init();

while(1) {
UART_RX_EVENT();
}
}

void parsuj_uart0( void * buf, uint8_t size ) {

uart_flush_bin(1);

//zerowanie bufora odbiorczego UART2
uint8_t *wsk2;
wsk2 = rx2buf;
for( uint8_t i= 0; i<16; i++ ){wsk2[i]=0; }

lcd_cls();
lcd_str( buf);

//uart_put_9bit(1, 0x00FF);
uart_put_9bit(1, 0x00EE);
//uart_put_9bit(1, 0x00AA);

//uart_putc( 1, 0x15);
//uart_putc( 1, 0x28);
//uart_putc( 1, 0xff);

}

void parsuj_uart1( void * buf, uint8_t size ) {
//dla BIN 9,n,9600
static uint8_t licz;
uint16_t *wsk;

wsk = buf;
for(uint8_t i=0; i<16; i++){
if (wsk[i]>0){
uart_putint( 0, i , 10 );
uart_putc(0, ' ');
uart_putint( 0, wsk[i] , 16 );
send_crlf(0);
}
}
//uart_get_bin9(1,buf,1);
//wsk= (uint16_t *)buf;
//uart_putint( 0, *wsk , 16 );
//send_crlf(0);

lcd_locate( 1,0 );
lcd_int( licz );
licz++;
}

void parsuj_uart2( void * buf, uint8_t size ) {
//dla BIN 8,n,9600
//RXD2 polaczone z TXD2
//wchodzi po kazdym otrzymanym znaku, bo size=1
//0 15
//15
//0 28
//28
//0 FF
//FF
static uint8_t licz;
uint8_t *wsk2;
wsk2= buf;
//sprawdzenie
send_crlf(0);
for(uint8_t i=0;i<50;i++){
if (wsk2[i]>0){
uart_putint( 0, i , 10 );
uart_putc(0, ' ');
uart_putint( 0, wsk2[i] , 16 );
send_crlf(0);
}
}
//
wsk2= (uint8_t *)buf;
uart_putint( 0, *wsk2 , 16 );

licz++;
lcd_cls();
lcd_int( licz );
}[/syntax]
Dodam, że jedyną zmianę jaką zrobiłem w bibliotece z uwagi na bugi, to:
[syntax=c]ISR( USART1_RX_vect ) {

#if UART1_DATA_BITS == 9

register TUART_BUF_8_16 tmp_head;
//register uint16_t data;MIREK-USUWAM
register uint16_t dataH, dataL;//MIREK-DOKLADAM[/syntax]

Statystyki: Napisane przez Nef.ID — 13 kwi 2020, o 15:13