www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik AT-Tastatur - PC - µC "einschleifen" -> RS232


Autor: MisterMime (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ich baue gerade ein Gerät, das ein Signal an eine Schaltung geben soll, 
wenn man eine "Num"(Zahlen)-Taste einer an den PC angeschlossenen 
Tastatur betätigt. Das UART dient mir aber derweil für Debug-Zwecke.

Die Scancodes der Tastatur werden auch richtig empfangen, aber es 
mischen sich auch Host -> KB-Kommandos dazu, zumindest nach einem 
ACK(FA) der Tastatur. Kann es sein, dass ein Kommandoparameter ohne 
vorheriges "loslassen"(High) der Clock-Leitung gesendet wird?

Wenn ich auf der Tastatur keine Taste betätige sendet sie in 
regelmäßigen Intervallen(1sec) FE == Resend. Es könnt aber auch vom 
Computer kommen.

Ansonsten funktioniert die Tastatur einwandfrei. Ich teste das Ganze 
aber auf einem Laptop, kann das der Grund sein?

Hier ein paar Links, die mir als Infirmationsquelle dienten:

http://www.computer-engineering.org
http://www.beyondlogic.org/keyboard/keybrd.htm
http://elektronik-kompendium.de/public/arnerossius...

Danke schon mal im Voraus,
Bei euch weiß sicher einer den Fehler :)

MisterMime

Autor: MisterMime (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Tastatur ist übrigends an PB3 und 4 angeschlossen und ein MAX232(zum 
PC) an TXD(PD1) und der AVR ist ein Tiny2313

Autor: MisterMime (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Kann mir bitte Jemand mit einem Oszi so ein Bild machen?

http://www.computer-engineering.org/index.php?titl...

Zumindest an der Stelle, wenn die Tastatur eine Antwort (FA) geschickt 
hat und der Host einen Parameter schickt. Den Übergang zumindest. Werden 
da beide Leitungen kurz High?

Bei dem Einschalten einer Tastaturled wird ja:
zuerst E0 vom Host gesendet
FA von der Tastatur
eine Bitmaske für den Ledstatus
und noch ein FA

Wäre sehr nett.

Autor: TravelRec. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du mußt mit Deinem Gerät prüfen, ob der PS2-port gerade frei ist, also 
die interne Computertastatur gerade nicht ´rumdödelt. Dazu mußt Du den 
idle Zustand der Clock und Datenleitung, direkt bevor das Gerät senden 
will, nochmals überprüfen (beide müssen "High" sein). Es werden Timings 
in den Spezifikationen genannt, die einzuhalten sind, sonst gibt es 
Datensalat. Ist der Bus gerade nicht frei, muß Dein Gerät die Scancodes 
solange speichern können, bis der Bus wieder frei ist. Guck mal auch bei 
www.marjorie.de, da gibt´s ´ne schön kompakte Beschreibung.

Autor: MisterMime (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die interne Tastatur gibt nix an dem Keyboard-Anschluss aus. Ich seh da 
nur Teile der Initialisierungsdaten wenn ich die externe anstecke. Es 
wird nur z.B. ein "Numlock-led-ein"-Signal gesendet wenn ich auf der 
internen was drücke sonst nix.

Aber dass ich auf HIGH bei beiden Leitungen warten muss kann schon sein, 
ich schau mir das gleich nochmal an.

Autor: MisterMime (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn ich zusätlich noch ein wait für das andere beim Ende von Discard 
und Process einfüge kommen nur falsche Werte heraus. Es muss irgendwie 
an dem Übergang zum nächsten Byte liegen. Wenn der Host zusätzlich zum 
Kommando noch einen Parameter sendet.

Autor: MisterMime (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn man:
sbis Pin, DATA
rcall discard

am Ende von Process einfügt dann wir bei dem Einschalten der Num-Led das 
zweite FA durch ein E9(06 wird vom Host gesendet) oder FF ersetzt(wenn 
00 ges wird.)...

So:

(ein)FA E9 (aus)FA FF

so sollte es sein:

FA FA    FA FA

Die Parameter sollten nicht empfangen werden.
Mit denen:

FA 06 FA   FA 00 FA

Da rutschen dann die Parameter in das zweite ACK (FA) ??

Autor: TravelRec. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich versteh nur Bahnhof... Bei meinem Joystick-Adapter, den ich mal 
gebaut habe, habe ich einen externen Tastaturanschluß angefügt, um das 
Teil zwischen die PS/2 Leine hängen zu können. Was mein Adapter tut, ist 
diesen externen Anschluß zu kontrollieren, ob da beide Leitungen High 
sind. Die Tastatur hat als Vorrang vor den Joysticks. Wenn Die Leitungen 
Datenverkehr anzeigen, darf nichts vom Gerät auf den Bus gegeben werden, 
solange bis für mindestens eine Bytelänge Ruhe ist. Irgendwo stand 
dieser Mindestabstand mal beschrieben. Die Tastatur selbst kontrolliert 
auch den Idlezustand, wenn das Gerät sendet, muß sie die Daten 
speichern, bis der Bus wieder frei ist und darf dann erst wieder senden. 
Das funktioniert eigentlich sehr zuverlässig.

Autor: MisterMime (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich will mit meinem Gerät ja keine Daten senden sondern nur auf eine 
Übertragung von der Tastatur reagieren. Wenn man eine Taste am 
Ziffernblock drückt.

Bei meiner Routine kommen aber seltsamerweise Kommandos von der Tastatur 
zum Keyboard an.

Hier mal ein Beispiel: (Bei Betätigen der Caps-Lock Taste, 
großschreiben)

Erstmal ohne herausfiltern der Host -> KB- Kommandos.+

Tastatur:
58 - Betätigung der Capslock-Taste/Scancode

PC:
ED - Set Status Leds

Tastatur:
FA - Acknowledge/Verstanden

PC:
04 = 0b00000100 - Bitmaske für eingeschaltete Numlockled

Tastatur:
FA - -||-

Die Leitung ist kurz Idle

Tastatur: (Taste wird losgelassen)
F0 - "Loslass"-Code
58 - Der Scancode der Capslocktaste, wie oben

Fertig

Mein Code empfängt aber folgenes:
58 FA 04 FA F0 58

Das ED ist, wie es sollte nicht da, aber 04 sehrwohl, obwohl es vom PC 
gesendet wird.

Es sollte so sein:
58 FA FA F0 58

FA kann ich ja ignorieren und den auf F0 folgenden Scancode, dann hab 
ich nur mehr 58 -- So wie es sein soll, aber das wird ja später gemacht.

Kann es sein, dass (die Tastatur gibt ja CLK vor!) nach einem ACK von 
einem Befehl der einen Parameter hat, die Leitung zwischen ACK und 
Parameter nicht im Idle-Zustand ist?

Die Timings sind ja nicht wichtig, da der µC ja nur "lauscht" und nicht 
senden will.

Das war jetzt zwar lang, aber ich hoffe, dass es verständlich ist :)
Ich dachte mir schon, der Thread wird zum Selbstgespräch...

Danke, dass du mir helfen willst TravelRec.

...,
MM

Autor: TravelRec. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja nöö, das Timing ist schon wichtig, wenn der Controller alles 
mitbekommen soll. Außerdem muß der Controller schnell genug den Bus 
scannen und immer den Idle-Zustand checken. Daß das Gerät nichts senden 
soll, ist erstmal hilfreich. Vom Prinzip her kann Dein Gerät doch aber 
genau feststellen, was der PC sendet und was von der Tastatur kommt 
(siehe hier: http://www.marjorie.de/ps2/ps2_protocol.htm  die Diagramme 
unten). Demzufolge ist das Ausmaskieren nichtrelevanter Bytes doch kein 
Problem, oder?

Autor: MisterMime (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, bei den Kommandos ist es ja kein Problem, bei den Kommandos 
funktioniert es ja.

Aber nachdem ein FA von der Tastatur(ACK für das Kommando) kommt, wie es 
sollte sendet ja der PC eine Antwort. Diese Antwort bekommt mein Code 
auch, obwohl er ihn, indem er in der Hauptschleife wartet bis CLK oder 
DATA Low wird verwerfen.

Aber anscheinend ist die Leitung zwischen dem FA und dem Parameter nicht 
frei.

Übrigends ist die Seite die gleiche wie www.computer-engineering.org , 
nur halt übersetzt...

Die Links hab ich ja ganz oben schon gepostet.

Eigentlich sollten die Hostkommandos gar nicht stimmen, weil der Zustand 
bei CLK=High statt Low gelesen wird.(zumindest ist es nicht garantiert)

Autor: TravelRec. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Najaaa, aber bevor der PC etwas sendet, MUSS er doch einen langen 
Clock-Low Puls geben, der seine Daten quasi einleitet und die Tastatur 
zum Senden der Clocks animiert. Wenn dieser lange Puls von Deinem Code 
wahrgenommen wird, kann doch das kommende Gelaber getrost verworfen 
werden, bis der PC dann mal wieder fertig ist.

Autor: TravelRec. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andere Frage: hast Du ein Oszi oder einen Logic-Analyzer? Dann guck Dir 
doch mal die Schnittstellensignale an und das, was Dein Code daraus 
macht...

Autor: MisterMime (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Beim langen brauch ich doch wieder einen Timer oder zumindest eine 
Zählschleife...

Könntest du mal kurz in einen Chat mit mir gehen, dann können wir das 
schneller besprechen :)

Autor: MisterMime (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
also den Chat hier mein ich

Autor: MisterMime (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bin um 17:20 da...

Autor: MisterMime (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hab ich eben nicht.

Aber der Unterschied ist ja, dass CLK statt DATA LOW wird(beim Start) da 
brauch ich doch nicht schaun wie lang CLK low ist, oder?

Autor: Johannes A. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie kommst Du darauf? CLK timet doch die Übertragung!
http://de.wikipedia.org/wiki/PS/2-Schnittstelle

Autor: MisterMime (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schau mal bei der Überschrift Protokoll, beim Punkt 4:

Zuerst zieht die Tastatur Data auf low (Startbit), um den Beginn eines 
zu übertragenden Bytes zu kennzeichnen. Danach wird von der Tastatur 
Clock für eine Weile auf low gezogen.

Beim "Daten vom PC"-Bild ist CLK ja am Ende Low, kann es sein, dass es 
nicht HIGH geht sondern der Parameter( 02 ) ohne "Einleitung"(fallende 
Flanke an CLK) gesendet wird?

Autor: Johannes A. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Auch unter der Überschrift Protokoll, ganz zu Anfang steht für den 
Zustand CLK=0 "PC ist beschäftigt" bzw. "PC wird resettet". Und dann

"Grundsätzlich kommt der Takt von der Tastatur, sowohl zum Senden von 
Daten an den PC, als auch zum Empfang von Daten vom PC."

Also muss der Clock für jedes Zeichen erst wieder auf HIGH gehen, um das 
Startbit der nächsten Sendung zu übertragen. Allenfalls könnte der PC 
nach Erkennen des Acknowledge-Bits auf sein Busy verzichten und das 
DATA-Low übergangslos fortsetzen, aber ob das Praxis ist, weiß ich 
nicht.

Autor: Zeltner xD (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Maierhofer! (MisterMime)

Dun schreibtst so wirres Zeug das ich Kopfweh davon bekomm, hast du 
sonst nichts zu tun?

@ alle anderen:

Ihr seid genauso schlimm ;D

Autor: Zeltner xD (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ach nochwas,........

Blub.

Hier gibts ja nicht mal eine Editier-Funktion, tzzzzz.

Autor: Marco S. (masterof)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es gibt eine Editier-Funktion man muss nur regestriert sein.

Autor: MisterMime (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hat irgendwer ein Speicheroszi, und kann er mir eine Aufnahme von der 
Tastaturkommunikation machen?

Im ersten Post sind Links gepostet, auf denen die Pinbelegungen sind. 
Einfach die eingänge an DATA und CLK hängen, sind 
Opencollector/drain-Ausgänge(0-5V)

...

Autor: Johannes A. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was ist nun wirklich Dein Problem?

Wie das Protokoll geht, kann es inzwischen ja eigentlich nicht mehr 
sein. Oder?

Gruß Johannes

Autor: MisterMime (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das weiß ich eigentlich schon, ich versteh aber nicht warum mein 
"Programm" auch die Kommandoparameter empfängt und warum ein mal pro 
Sekunde Resend gesendet wird...

Vielleicht, eine "Überwachung", damit der Laptop weiß, dass die Tastatur 
nicht abgesteckt wurde.

Die CLK-Leitung wird seltsamerweise auch getoggelt, wenn keine Daten 
gesendet werden.

Wenn nur jemand mal versuchen würde den Code "nachzuvollziehen"......

...,

Mistermime

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Um das zu verifizieren, nimm einfach mal ´nen anderen Computer, 
meinethalben einen normalen Tower-PC. Und die Clock-Leitung kann NUR die 
Tastatur toggeln, niemand sonst (höchstens Dein Gerät....).

Autor: Johannes A. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es ist offenbar doch noch das Protokoll, wo Dein Verständnis klemmt.

Also fangen wir noch einmal ganz von hinten an :-)

Dass die CLK-Leitung auch getoggelt wird, wenn keine Daten gesendet 
werden, ist alles andere als seltsam, sondern das ganz normale "Busy" 
vom PC, das jederzeit und auch rein prophylaktisch vorkommen kann, da 
die Tastatur ja den Takt erzeugt und von sich aus halt nicht ahnen kann, 
wann der PC empfangen kann und wann nicht. Das ist wie mit dem berühmten 
"Bitte nicht stören"-Schild an der Hotelzimmertür: Das hängt man ja auch 
nicht erst dann auf, wenn das Zimmermädchen schon am (doppelt belegten) 
Bett steht...

Dann die zyklische "Rückversicherung" per Resend - ich denke, mit Deiner 
Vermutung liegst Du nicht daneben. Derlei hat übrigens einen eigenen 
Namen: Phantom.

Und schließlich ist die Sache mit den Kommandoparametern "in der 
Literatur" vielleicht nicht völlig klar beschrieben, aber doch streng 
logisch: Wenn ein bestimmtes Kommando ein Parameterbyte braucht, weiß 
das sowohl der Sender als auch der Empfänger. Von daher ist es 
überflüssig, die Sendung des Parameterbytes per RTS-Prozedur erneut 
anzumelden, sondern es reicht, wenn der Sender (PC) von sich aus nur 
erneut das Startbit vorgibt.

Im übrigen hab ich Deinen Code zwar nicht bis ins Letzte 
"nachvollzogen", aber immerhin soweit, um noch anzumerken, dass der 
AVR-DEC-Befehl durchaus mehr kann, als Du ihm zutraust. Ansonsten finde 
ich ihn etwas zu sehr "klein in klein" formuliert. Konkret ist er nicht 
in der Lage, mehrere Bytes zu überblicken - was zum Ausblenden der 
fraglichen Sendungen vom PC aber unbedingt nötig ist.

Ich hoffe, mal ein bisschen geholfen zu haben.

Gruß Johannes

Autor: Daniel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falls es noch interresse besteht, folgt hier ist mein Code.

Kommunikation in beide Richtungen möglich. Getestet mit Terminalprogramm 
Docklight.

Viel Spaß damit Gruß Daniel
/*****************************************************
This program was produced by the
CodeWizardAVR V1.25.2 Standard
Automatic Program Generator
© Copyright 1998-2006 Pavel Haiduc, HP InfoTech s.r.l.
http://www.hpinfotech.com

Project : PS2toRS232
Version : 1.0
Date    : 21.12.2006
Author  : Daniel xxx
Company :               
Comments: 


Chip type           : ATtiny2313
Clock frequency     : 7,372800 MHz
Memory model        : Tiny
External SRAM size  : 0
Data Stack size     : 32

Beschreibung siehe wiki->
http://de.wikipedia.org/wiki/PS/2-Schnittstelle
*****************************************************/

#include <tiny2313.h>
#include <io.h>
// Standard Input/Output functions
#include <stdio.h>

#define DATA        2    //INT0
#define CLOCK       3    //INT1
#define LED0        5
#define LED1        6     
#define UDRE        5
  
unsigned char recieve_bit;
unsigned char checksum;
unsigned char recieve_byte[10];
unsigned char keyboard_byte[10];
unsigned char todo;
unsigned char send_byte;
unsigned char rec_byte;
// External Interrupt 0 service routine
interrupt [EXT_INT0] void ext_int0_isr(void)
{
     while (PIND.CLOCK==1);   //Warten bis CLOCK=LOW
     while (PIND.CLOCK==0);   //Warten bis CLOCL=HIGH
     GIMSK = 0x80;            //INT0 sperren und INT1 aktivieren
     recieve_bit  = 0;     
     checksum     = 0;
}

// External Interrupt 1 service routine
interrupt [EXT_INT1] void ext_int1_isr(void)
{
     if(PIND.DATA==0){recieve_byte[recieve_bit]=0;PORTD.LED1=0;}
     if(PIND.DATA==1){recieve_byte[recieve_bit]=1;PORTD.LED1=1;}
     while (PIND.CLOCK==0);   //Warten bis CLOCL=HIGH
     recieve_bit++;
     if (recieve_bit==10)
     {
          GIMSK = 0x00;
          todo=1;
     }
}

// USART Receiver interrupt service routine
interrupt [USART_RXC] void usart_rx_isr(void)
{
     rec_byte=UDR;
     todo=2;
}

void READ_BYTE_FROM_KEYBOARD(void);
void WRITE_BYTE_TO_KEYBOARD(void);
void SEND_UART(void);

void main(void)
{
// Port D initialization
// Func6=Out Func5=Out Func4=In Func3=In Func2=In Func1=Out Func0=In 
// State6=1 State5=1 State4=P State3=P State2=P State1=0 State0=P 
     DDRD  = 0b01100000;
     PORTD = 0b01111101;

// Crystal Oscillator division factor: 1
     #pragma optsize-
     CLKPR=0x80;
     CLKPR=0x00;
     #ifdef _OPTIMIZE_SIZE_
     #pragma optsize+
     #endif
// Port D initialization
// Func6=Out Func5=Out Func4=In Func3=In Func2=In Func1=Out Func0=In 
// State6=1 State5=1 State4=P State3=P State2=P State1=0 State0=P 
     DDRD  = 0b01100010;
     PORTD = 0b01111001;
// USART initialization
// Communication Parameters: 8 Data, 1 Stop, No Parity
// USART Receiver: On
// USART Transmitter: On
// USART Mode: Asynchronous
// USART Baud rate: 115200
UCSRB=0x98;
UBRRL=0x03;
   
     todo=0;
  
// External Interrupt(s) initialization
// INT0: On
// INT0 Mode: Low level
// INT1: On
// INT1 Mode: Low level
// Interrupt on any change on pins PCINT0-7: Off
     GIMSK=0x40;
     MCUCR=0x00;
     EIFR=0xC0;
   PORTD &= ~(1<<LED0);
// Global enable interrupts
     #asm("sei")

     while (1)
     {
          if(todo==1)READ_BYTE_FROM_KEYBOARD();
          if(todo==2 && PIND.CLOCK==1 && PIND.DATA==1)WRITE_BYTE_TO_KEYBOARD();
     };
}

void WRITE_BYTE_TO_KEYBOARD(void)
{
     unsigned char command;
     unsigned char x;
     #asm("cli")
     command=rec_byte;
     for(x=0;x<8;x++)keyboard_byte[x]=0;
     if(command>=128){command = command - 128; keyboard_byte[7] = 1;}
     if(command>= 64){command = command -  64; keyboard_byte[6] = 1;}
     if(command>= 32){command = command -  32; keyboard_byte[5] = 1;}
     if(command>= 16){command = command -  16; keyboard_byte[4] = 1;}
     if(command>=  8){command = command -   8; keyboard_byte[3] = 1;}
     if(command>=  4){command = command -   4; keyboard_byte[2] = 1;}
     if(command>=  2){command = command -   2; keyboard_byte[1] = 1;}
     if(command>=  1)keyboard_byte[0]=1;
     keyboard_byte[8] = 1;
     keyboard_byte[9] = 1;
     for(x=0;x<8;x++) keyboard_byte[8]^= keyboard_byte[x];
     PORTD.LED0 = 0;
//100µs CLOCK auf LOW
     DDRD.CLOCK  = 1;      //CLOCK->AUSGANG
     PORTD.CLOCK = 0;
     TCNT0  = 0x00;
     TCCR0B = 0x03;
     while(TCNT0 <= 10);
     TCCR0B = 0x00;
//Request to send mit DATA auf LOW
     PORTD.DATA  = 0;      //Startbitsignalisieren
     DDRD.DATA   = 1;      //DATA->Ausgang 
     TCNT0  = 0x00;
     TCCR0B = 0x03;
     while(TCNT0 <= 2);
     TCCR0B = 0x00;
//CLOCK wieder als Eingang mit HIGH durch PULLUP
     DDRD.CLOCK  = 0;      //CLOCK->Eingang
     PORTD.CLOCK = 1;
//Daten werden bei LOW geschrieben und vom Eingabegerät mit HIGH übernommen
     while(PIND.CLOCK==1);
     while(PIND.CLOCK==0);
     while(PIND.CLOCK==1);
     for(x=0;x<9;x++)
     {
          if(keyboard_byte[x]==0) PORTD.DATA = 0;
          else PORTD.DATA = 1;
          while(PIND.CLOCK==0);
          while(PIND.CLOCK==1);
     }

     DDRD.DATA  = 0;      //DATA->Eingang
//     TCNT0  = 0x00;
  //   TCCR0B = 0x03;
    // while(TCNT0 <= 1);
     //TCCR0B = 0x00;
     while(PIND.DATA==1);
     while(PIND.CLOCK==1);
     while(PIND.CLOCK==0);
     while(PIND.DATA==0);
     todo=0;
     #asm("sei")
}
void READ_BYTE_FROM_KEYBOARD(void)
{
     unsigned char x;
     unsigned char chk=1;
     unsigned char note=0;
     DDRD.CLOCK  = 1;
     PORTD.CLOCK = 0;
     for(x=0;x<8;x++)chk^= recieve_byte[x];
     if(chk==recieve_byte[8])
     {
          if(recieve_byte[0]==1)note=note+  1;
          if(recieve_byte[1]==1)note=note+  2;
          if(recieve_byte[2]==1)note=note+  4;
          if(recieve_byte[3]==1)note=note+  8;
          if(recieve_byte[4]==1)note=note+ 16;
          if(recieve_byte[5]==1)note=note+ 32;
          if(recieve_byte[6]==1)note=note+ 64;
          if(recieve_byte[7]==1)note=note+128;
          send_byte=note;
          SEND_UART();
     }
     todo=0;
     DDRD.CLOCK  = 0;
     PORTD.CLOCK = 1;
     GIMSK = 0x40;
}


void SEND_UART(void)
{
     while(UCSRA.UDRE==0);
  UDR = send_byte;
}

Autor: MisterMime (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ein bischen sehr spät aber doch noch, die funktionierende Version vo dem 
ganzen. Danke für eure Hilfe, Leute! Schade, dass mir keiner eine 
Logikanalysator-"Aufnahme" gemacht hat... Aber ich habe sie dann mit 
einem Playstation SingStar-Mikrophonadapter, der Stereo hat aufnehmen 
können.

Autor: MisterMime (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Die Logikanalysator-"Aufnahmen"... ;)

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.