Witam wszystkich.
Mam taki problem na którym stoję już kilka dni.
Mianowicie tak:
Posiadam przejściówkę USB-RS opartą o układ PL2303x przez którą to chcę się komunikować z ATmegą16. Przejściówka była dorzucona do zakupionej na wiadomym serwisie aukcyjnym płytki testowej do mikroprocesora.
Po podłączeniu przejściówki do portu usb w PC generalnie wszystko wygląda OK:
wycinek lsusb -v
dmesg po odłączeniu i podpięciu urządzenia:
Tak więc chcąc sprawdzić czy kabelek w ogóle działa, zwieram Tx i Rx odpalam CuteCom podpięty pod /dev/ttyUSB0 i patrzę czy jest echo, echo jest więc OK. Dla pewności sprawdzam też pod GTKterm, echo działa.
W ten sposób chyba mam pewność, że z kabelkiem mimo, że pewnie chiński wyrób wyrobopodobny, to jednak wszystko jest ok ?
No to podłączam kabelek do ATMegi, Tx z kabelka do PD0 (Rx), a Rx z kabelka do PD1 (Tx), no i masa oczywiście.
Ładuję do procesora taki program:
Skopiowany z tutoriala na avrfraks (bo doszedłem do wniosku, że może ja sam coś źle napisałem i stąd nie działa).
Jak widać program ma zwracać echo. To co dostał w UDR ma wysłać z powrotem, nic wielkiego.
No i tu jest problem bo i owszem wysyła z powrotem to co dostał ale wysyła też bardzo dużo znaków NUL (0x00). Bez znaczenia czy coś wysyłam z PC czy nie, zaraz po resecie ATMega zaczyna wysyłać non stop NUL, czasem dorzuca jeszcze jakiś losowy bit. Udaje się co jakąś chwilę zwrócić wysłany z klawiatury znak, no ale to nie za bardzo mnie zadawala
Jak program miał na celu tylko wysyłanie znaku to było podobnie, cały czas wysyłane były znaki NUL, a ten znak który miał być wysłany był przekłamany (znaczy przy odbiorze nie był tym znakiem)
Dodam, że fuses są dobrze ustawione: na RC 8MHz.
Inne bity były domyślnie z płytką więc nie zmieniałem (lowF: 0xE4 highF: 0xC1 zgodnie z http://palmavr.sourceforge.net/cgi-bin/fc.cgi
).
Baudrate ustawiony na taki sam w PC jak i w procesorze, transmisja 8n1.
Wygrzebałem (http://koti.mbnet.fi/lonnberg/pl2303x.html), że do pl2303x w kernelach do 2.6.8 bodajże włącznie potrzebny był patch na driver, no ale w kolejnych kernelach już niby nie było problemu, stąd wykluczam błąd w sterowniku.
Wszelkie sugestie mile widziane, bo mi już się skończyły pomysły
Mam taki problem na którym stoję już kilka dni.
Mianowicie tak:
Posiadam przejściówkę USB-RS opartą o układ PL2303x przez którą to chcę się komunikować z ATmegą16. Przejściówka była dorzucona do zakupionej na wiadomym serwisie aukcyjnym płytki testowej do mikroprocesora.
Po podłączeniu przejściówki do portu usb w PC generalnie wszystko wygląda OK:
wycinek lsusb -v
Bus 001 Device 004: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x067b Prolific Technology, Inc.
idProduct 0x2303 PL2303 Serial Port
bcdDevice 3.00
iManufacturer 1
iProduct 2
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 39
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xa0
(Bus Powered)
Remote Wakeup
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 3
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x000a 1x 10 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
dmesg po odłączeniu i podpięciu urządzenia:
[46572.937508] usb 1-2: USB disconnect, address 4
[46572.937718] pl2303 ttyUSB0: pl2303 converter now disconnected from ttyUSB0
[46572.937735] pl2303 1-2:1.0: device disconnected
[46581.496600] usb 1-2: new full speed USB device using ohci_hcd and address 6
[46581.602918] usb 1-2: configuration #1 chosen from 1 choice
[46581.604366] pl2303 1-2:1.0: pl2303 converter detected
[46581.604554] usb 1-2: pl2303 converter now attached to ttyUSB0
Tak więc chcąc sprawdzić czy kabelek w ogóle działa, zwieram Tx i Rx odpalam CuteCom podpięty pod /dev/ttyUSB0 i patrzę czy jest echo, echo jest więc OK. Dla pewności sprawdzam też pod GTKterm, echo działa.
W ten sposób chyba mam pewność, że z kabelkiem mimo, że pewnie chiński wyrób wyrobopodobny, to jednak wszystko jest ok ?
No to podłączam kabelek do ATMegi, Tx z kabelka do PD0 (Rx), a Rx z kabelka do PD1 (Tx), no i masa oczywiście.
Ładuję do procesora taki program:
#include <avr/io.h>
#define USART_BAUDRATE 9600
#define F_CPU 8000000UL
#define BAUD_PRESCALE (((F_CPU / (USART_BAUDRATE * 16UL))) - 1)
int main (void)
{
char ReceivedByte;
UCSRB |= (1 << RXEN) | (1 << TXEN); // Turn on the transmission and reception circuitry
UCSRC |= (1 << URSEL) | (1 << UCSZ0) | (1 << UCSZ1); // Use 8-bit character sizes
UBRRL = BAUD_PRESCALE; // Load lower 8-bits of the baud rate value into the low byte of the UBRR register
UBRRH = (BAUD_PRESCALE >> 8); // Load upper 8-bits of the baud rate value into the high byte of the UBRR register
for (;;) // Loop forever
{
while ((UCSRA & (1 << RXC)) == 0) {}; // Do nothing until data have been recieved and is ready to be read from UDR
ReceivedByte = UDR; // Fetch the recieved byte value into the variable "ByteReceived"
while ( (UCSRA & (1 << UDRE)) == 0 ) {}; // Do nothing until UDR is ready for more data to be written to it
UDR = ReceivedByte; // Echo back the received byte back to the computer
}
}
Skopiowany z tutoriala na avrfraks (bo doszedłem do wniosku, że może ja sam coś źle napisałem i stąd nie działa).
Jak widać program ma zwracać echo. To co dostał w UDR ma wysłać z powrotem, nic wielkiego.
No i tu jest problem bo i owszem wysyła z powrotem to co dostał ale wysyła też bardzo dużo znaków NUL (0x00). Bez znaczenia czy coś wysyłam z PC czy nie, zaraz po resecie ATMega zaczyna wysyłać non stop NUL, czasem dorzuca jeszcze jakiś losowy bit. Udaje się co jakąś chwilę zwrócić wysłany z klawiatury znak, no ale to nie za bardzo mnie zadawala
Jak program miał na celu tylko wysyłanie znaku to było podobnie, cały czas wysyłane były znaki NUL, a ten znak który miał być wysłany był przekłamany (znaczy przy odbiorze nie był tym znakiem
)
Dodam, że fuses są dobrze ustawione: na RC 8MHz.
Inne bity były domyślnie z płytką więc nie zmieniałem (lowF: 0xE4 highF: 0xC1 zgodnie z http://palmavr.sourceforge.net/cgi-bin/fc.cgi
).
Baudrate ustawiony na taki sam w PC jak i w procesorze, transmisja 8n1.
Wygrzebałem (http://koti.mbnet.fi/lonnberg/pl2303x.html), że do pl2303x w kernelach do 2.6.8 bodajże włącznie potrzebny był patch na driver, no ale w kolejnych kernelach już niby nie było problemu, stąd wykluczam błąd w sterowniku.
Wszelkie sugestie mile widziane, bo mi już się skończyły pomysły
