Hallo, ich möchte von dem mySmartUSB MK2 die UART Bridge benutzen um mit meinem ATMega 644 und dem PC Daten auszutauschen. Dafür habe ich als PC-Programm die "USB Device - CDC - Basic Demo" von Microchip genommen. Das ist ein C# Demoprogramm welches beliebige Daten auf eine serielle Schnittstelle gibt und empfangene Daten anzeigt. Dieses Prog ist eigentlich für PIC µC der ein USB-Interface hat. Sollte jedoch das gleiche sein, wie ich es auch für den MK2 brauche. Im Mikrocontroller habe ich den UART initialisert und empfange und sende 2 mal Pro Sekunde ein Byte. Den myAVR MK2 habe ich per DIP Schalter auf "Datenmodus erzwingen (UART-USB-Bridge)" gestellt. Doch leider empfängt weder das Computerprogramm Daten vom µC noch andersrum. Wenn ich im PC Programm die Daten lossende sieht man auf dem MK2, dass Daten ankommen (rote LED blinkt beim Senden der Daten). Leider habe ich kein Scope um die Kommunikation auf den RX und TX Leitungen zu überprüfen. Hat jemand von Euch ne Idee wo der Fehler liegen könnte? Vielen Dank! Stefan
Hi- du brauchst kein wirkliches Skope nimm einfach eine LED(mit Vorwiderstand) und mess damit wie Spannungen anliegen etc- wenn du die Baudrate auf ca 4800 oder noch tiefer einstellst, dann kannst du problemlos sehen, ob da Datenfließen. Das LED fängt dann an zu Flackern. Habe das gestern noch selber mit einem max232 ausprobiert
Hi raketenfred, danke für deine Antwort! Bin um einiges weiter. Ich habe einfach die RX und TX Leitung der Brücke kurzgeschlossen und das PC Prog ausprobiert; Die versendeten Daten treffen wieder ein. :) Auf der AVR Seite funktioniert das Empfangen. Leider funktioniert das Senden nicht. In dem µC Programm habe ich einen zyklischen Interrupt (Uhr). Sobald ich jedoch das TX Enable Bit setzte bleibt die Uhr komischer Weise stehen. Auch das Empfangen auf der RX Leitung funktioniert dann nicht mehr. Der µC scheint sich aufzuhängen. So funktionierts: UCSR0B = (1<<RXEN0); So nicht: UCSR0B = (1<<RXEN0)|(1<<TXEN0); Was kann das sein?
Das Empfangen auf der Controllerseite funktioniert einwandfrei, die Bridge funktioniert auch. Leider habe ich das Problem nicht beheben können, dass er sich aufhängt sobald das TXEN Bit gesetzt ist. Das Problem gab es bereits 2005 Beitrag "Wie heißt SIG_UART_DATA beim ATmega8?" und vor ein paar Tagen: Beitrag "AtMega88P - UART" Leider jeweils ohne einer Lösung. Würd mich wirklich sehr freuen, wenn jemand die Lösung des Problems kennt oder vermutet. Vielen Dank nochmal! Stefan
>Würd mich wirklich sehr freuen, wenn jemand die Lösung des Problems >kennt oder vermutet. Im zweiten Link habe ich eine Vermutung geäussert: Das Projekt wird für den falschen Controller übersetzt. Dann kann es Probleme mit einem falsch gesetzten Stackpointer oder falschen Registerzugriffen geben. Oder das Problem liegt ganz woanders im Code.
Zeig Hardware und Software, jeweils vollständig(!), alles andere ist nur Rätselraten.
Zu der Hardware gibts nicht viel zu sagen. RX<->TX TX<->RX Es ist nichts weiteres an den Pins angeschlossen. Das Problem habe ich in folgendem abgespecktem Programm weiterhin:
1 | #include <avr/io.h> |
2 | |
3 | #include "lcd-routines.h" |
4 | |
5 | void USART_Init(void) |
6 | {
|
7 | /* Set baud rate: 9600 (20 Mhz OSC) */
|
8 | UBRR0 = 129; |
9 | |
10 | /* Enable receiver and transmitter */
|
11 | UCSR0B = (1<<RXEN0)|(1<<TXEN0); |
12 | |
13 | lcd_string("Init ready"); |
14 | while(1); |
15 | /* Set frame format: 8data, 2stop bit */
|
16 | UCSR0C = (1 << UCSZ01)|(1 << UCSZ00)|(1 << USBS0); // Asynchron 8N2 |
17 | |
18 | }
|
19 | |
20 | int main(void) |
21 | {
|
22 | lcd_init(); |
23 | USART_Init(); |
24 | }
|
Wenn ich dieses Programm starte bleibt das Display leer. Wenn ich "|(1<<TXEN0)" rausnehme gibt das Display "Init ready" aus. Der Controller hängt sich also tatsächlich in dieser Zeile auf. Ich hab das display mal den Wert "TXEN0" anzeigen lassen per "lcd_data(TXEN0+48)". Es wird eine 3 angezeigt, die laut Datenblatt auch richtig ist. Auch wenn ich es direkt schreibe: UCSR0B = (1<<RXEN0)|(1<<3); ... bleibt das Problem vorhanden. Wenn ich mir das Register UCSRnB im Datenblatt angucke, seh ich auch keine Möglichkeit den Controller durch irgend ein falsch gesetztes Bit zum Absturz zu bringen.
>Der Controller hängt sich also tatsächlich in dieser Zeile auf.
Also genau wie bei dem zweiten Link. Merkwürdig.
Eigentlich kann der sich da nicht aufhängen.
Was passiert beim aktivieren von TXEN0? Der Pin wird
zum Ausgang. Evtl. mal den Pin offen lassen.
Entsorg das LCD, entsorg die (fragwürdige) Endlosschleife in der Initialisierung, mach in main() sowas wie
1 | while (1) { uart_send_string("x"); _delay_ms(500); } |
Wenn das noch nichts hilft häng eine LED an einen freien Pin und toggel die an aussagekräftigen Stellen etwas rum (insbesondere beim Start!). Und überprüf die Hardware nochmals :-) HTH
Auch wenn ich die Brück abnehme und Spannung anschließe bleibt er bei der Zeile stehen. Hab vor der Zeile nochmal PORTD = 0x02; geschrieben... er bleibt weiterhin hängen. :(
1 | void USART_Init(void) |
2 | {
|
3 | UBRR0 = 129; |
4 | PORTD = 0x02; |
5 | lcd_string("Start"); |
6 | UCSR0B = (1<<RXEN0)|(1<<TXEN0); |
7 | lcd_string("Ende"); |
8 | UCSR0C = (1 << UCSZ01)|(1 << UCSZ00)|(1 << USBS0); // Asynchron 8N2 |
9 | }
|
Das Display gibt "Start" aus. Das LCD ist eine einfache möglichkeit um zu überprüfen in welcher Zeile er hängen bleibt. Die fragwürdige Endlosschleife entstand bei einem Test um das Programm dort erstmal anzuhalten. Habe sie rausgenommen, keine Besserung. Da das Projekt in SMD gelötet ist, ist es nicht ganz so einfach mal eben eine LED ranzuhängen. Ich wüsste auch nicht wieso das LCD das Problem sein sollte.
> Das LCD ist eine einfache möglichkeit um zu überprüfen in welcher Zeile > er hängen bleibt. Schon klar - nur was nicht reincompiliert wird kann auch keine Probleme verursachen :-) > Da das Projekt in SMD gelötet ist, ist es nicht ganz so einfach mal eben > eine LED ranzuhängen. Ok, das ist ein Argument. Dann eben ein Mulimeter dranfrickeln :-) > Ich wüsste auch nicht wieso das LCD das Problem sein sollte. Isses vielleicht nicht (siehe oben). KISS halt. Und ich hab eine ganz andere Vermutung: Deine Kiste macht einen Reset beim TXEN - warum auch immer. Deswegen der Hinweise mit 'rumtoggeln beim Start'. Behelfsweise (bevor Du zum Mulimeter greifst) kannst noch sowas einbauen wie
1 | lcd_init(); |
2 | lcd_string("hallo welt"); |
3 | _delay_ms(1000); |
4 | uart_init(); |
5 | lcd_string("foo bar"); |
HTH
Mach das mal so _delay_ms(200); lcd_string("Start"); UCSR0B = (1<<RXEN0)|(1<<TXEN0); flackert das Display dann? >Auch wenn ich die Brück abnehme Welche Brücke? Du hast doch nicht etwa Rx und Tx am uC bei angeschlossenem MAX232 verbunden? Dann hast du zwei Ausgänge kurzgeschlossen.
Es gibt keinen Neustart. Folgendes Programm lässt 800 ms "Hallo Welt" anzeigen, danach "Start", es gibt keinen Neustart.
1 | #include <avr/io.h> |
2 | #include <util/delay.h> |
3 | |
4 | #include "lcd-routines.h" |
5 | |
6 | |
7 | |
8 | void print(char *string) |
9 | {
|
10 | lcd_clear(); |
11 | lcd_home(); |
12 | lcd_string(string); |
13 | }
|
14 | |
15 | void USART_Init(void) |
16 | {
|
17 | uint8_t temp; |
18 | UBRR0 = 129; |
19 | PORTD = 0x02; |
20 | print("Start"); |
21 | UCSR0B = (1<<RXEN0)|(1<<TXEN0); |
22 | print("Ende"); |
23 | UCSR0C = (1 << UCSZ01)|(1 << UCSZ00)|(1 << USBS0); // Asynchron 8N2 |
24 | |
25 | }
|
26 | |
27 | int main(void) |
28 | {
|
29 | lcd_init(); |
30 | print("Hallo Welt!"); |
31 | _delay_ms(800); |
32 | print("800 ms gewartet"); |
33 | USART_Init(); |
34 | print("Initialisiert"); |
35 | while(1); |
36 | }
|
Holgers Programm lässt das Display nicht flackern. Holger: Mit Brücke mein ich die UART <=> USB Brücke. Der MK2 ist eigentlich ein Programmer der jedoch als Zusatz eine UART <=> USB Brücke beinhaltet. Mit Brücke abnehmen meinte ich, dass ich den Programmer nicht angeschlossen habe und eine externe Spannung als Versorungsspannung anlege. Die TX Leitungen sind und waren nie miteinander verbunden.
>Es gibt keinen Neustart.
Dann sind wir wohl wieder am Anfang;)
Irgendwas stimmt doch da mit dem TX Pin nicht.
Sicher das da kein Kurzschluss zu VCC, GND oder einem
Nachbarpin drauf ist?
Schade, kein Reset :-( Fuse mal auf den internen Oszillator um auszuschließen dass der TX den Takt 'abwürgt'.
Hi Leute, danke für eure Geduld. Meine ist erstmal zu Ende und ich werd erstmal zum Sport gehen. ;) Meld mich heut abend oder morgen wieder. Vielen Dank nochmal! Stefan
Auch wenn der interne Oszillator aktiviert ist, hängt sich der Controller auf. Ich habe vom TX Pin zu seinen Nachbarn sowie zu V+ und GND gemessen: kein Kurzschluss. Nun habe ich mal den PD1 Pin (= TX Pin) jede Sekunde toggeln lassen: Funktioniert. Muss mich also mit ner Software UART abfinden. Nochmals vielen dank an Euch.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.