Hallo NG, ich habe zwar jetzt ein HD44780 Display an meinem ARM7 am laufen, das hat aber leider nur 2x16 Zeichen. Für Programmablaufinfos möchte ich gerne längere Texte und Werte ausgeben. Diese wiederum würde ich gerne über RS232 an ein Terminalprogramm schicken. Wieviele und welche Datenleitungen brauche ich denn, um nur eine der beiden RS232-Buchsen zu verwenden? Kann mir jemand ein paar Infos / Links für diese Datenübertragung geben? Am besten einfach nur ein Zeichen in eine Richung SAM7 -> PC. Vielen Dank, Peter
Hallo, ich bins nochmal :-) wollte nur noch kurz erwähnen, dass ich gerade versuche ne SD-Card zu lesen und deshlb die Ausgabe auf RS232 benötige, damit ich mich Schritt für Schritt vorarbeiten kann. Wäre mir schon ne rießen Hilfe, wenn mir jemand sagen könnte, ob auf dem AT91SAM7S256 der SD-Karten-Leser UND RS232 parallel hinhaut, oder ob sich die Pins "überschneiden". Der Schaltplan zum Board: http://www.olimex.com/dev/images/sam7-p64-sch.gif Vielen Dank für jeden Tip! Gruß, Peter
Hi, du hast alle Informationen im Schaltplan! Über den MAX3232 (U2 Mitte oben) laufen die RS232-Signale und auf dem Board hast du zusätzlich den SD-Karten-Leser angeschlossen am SPI-Port (MOSI, MISO usw.) Beide Schnittstellen (RS232 und SPI) laufen unabhängig von einander! Ich hab die DEBUG-Informationen bei meinem Board über den DRXD/DTXD laufen lassen und die anderen beiden Schnittstellen (RXD0/TXD0 und RXD1/TXD1)benutze ich für externe Geräte. Bei deinem Board musst du dich entscheiden ob du RXD0/TXD0 (Schnittstelle 0) oder DRXD/DTXD haben willst. (Jumper-Einstellung! rechts oben von U1) mfg Stephan
@Stephan >Bei deinem Board musst du dich entscheiden ob du RXD0/TXD0 >(Schnittstelle 0) oder DRXD/DTXD haben willst. (Jumper-Einstellung! >rechts oben von U1) Vielen Dank für Deine Antwort! Sehe ich das richtig, dass DRXD Empfangen bedeutet und DTXD transfer?
Hallo Peter!
>DRXD Empfangen bedeutet und DTXD transfer
Genau so ist es.
Gruß,
Greg.
So, jetzt habe ich das Programm - so denke ich - fertig, um Zeichen via RS232 zu schicken. Kann mir jemand sagen, was für ein Kabel ich brauche, um Daten vom AT91SAM7S256-Board an meinen PC zu senden? Am besten auch nen Link, wo die Verdrahtung beschrieben ist. Habe zwar noch ein Plotterkabel rumliegen, aber mit dem haut es nicht hin :-( Tausend Dank! Peter
Wenn in den RS232 Buchsen Stifte sind dann brauchst du ein Nullmodem-Kabel.
Auf dem Board sind "weibliche" Anschlüsse und am PC habe ich einen "männlichen" Anschluss.
Wenn das Kabel, das ich für den Plotter verwende "one-way" ist, dann müsste es doch gehen, wenn ich das Kabel einfach "umdrehe"? Da müsste ich mir halt was wegen der Anschlüsse einfallen lassen. Hat hier niemand ein RS232 Kabel im Einsatz, damit ich mal die Belegung weiß? Danke Jungs (und Mädels :-)
http://www.ulrichradig.de/site/infos/pdf/RS232PC.pdf Deine Buchsen sind als Nullmodem vorverdrahtet. Was du brauchst ist eine simple Sub-D 9pol Verlängerung Stecker-Buchse.
Hallo NG, so, jetzt habe ich mal ein 1:1 Kabel (alle Leitungen durchgeschliffen) gelötet. Leider haut es nicht hin, und ich sehe den Fehler nicht :-( Habe den Code mal angehängt. Vielleicht kann ja jemand von euch was sehen? Achso: Gegenstelle = Windows Hyperterminal 9600 Baud-8-N-1 MfG Peter
>so, jetzt habe ich mal ein 1:1 Kabel (alle Leitungen durchgeschliffen) >gelötet. Leider haut es nicht hin, und ich sehe den Fehler nicht :-( Hast du mal mit einer Lupe auf die Sub-D Verbinder gesehen ? Hinten stehen die Pin Nummern drauf. Vorne auch manchmal. Die Buchse ist gegenüber dem Stecker gespiegelt !
Also ich bin so vorgegangen: 1. Stecker in Buchse gesteckt 2. Die jeweiligen Farben an der selben Stelle angelötet. 0 0 0 0 0 0 0 0 0 | | | | | | | | | Was auch noch ne Geschichte wäre: hat vielleicht jemand ein Binary, das ich irgendwo ins RAM vom ARM7 laden kann und das irgendwelche Zeichen (z.B. Hallo Welt) an RS232 schickt? Dann könnte ich sehen, ob mit dem Kabel alles passt. Danke!
Ach - sorry Leute. Ich bin echt total gefrustet. Wo soll das nur Enden? Ich will doch nur ne serielle Verbindung, damit ich ein paar Statusmeldungen ausgeben kann. Jetzt habe ich mich schon so gefreut, dass das mit den Tastern und LEDs und dem Display hinhaut, aber so ne blöde One-Way-Verbindung bekomme ich einfach nicht gebacken! Man darf doch ein bischen Komfort beim Arbeiten voraussetzen, oder ist das zu viel verlangt? PS.: die Meldungen auf dem Display auszugeben finde ich total doof, weil man da nicht zurückscrollen kann, und der Platz mehr als Beschränkt ist :-(
>Also ich bin so vorgegangen: >1. Stecker in Buchse gesteckt >2. Die jeweiligen Farben an der selben Stelle angelötet. Gute Idee ! Dann ist dein Kabel in Ordnung. Zu deinem ARM Problem: Du programmierst ARM in ASM. Da kann dir kaum einer folgen ! Probier es doch einfach mal mit C. Ist nicht so schwer. Da können dir auch wesentlich mehr Leute helfen.
@holger >Zu deinem ARM Problem: >Du programmierst ARM in ASM. Da kann dir kaum einer folgen ! >Probier es doch einfach mal mit C. Ist nicht so schwer. Dass es nich so schwer ist kann ich mir gut vorstellen. Habe bisher immer mit PHP, C#, Perl usw. gearbeitet. Das mit 6510 / 68000 - Assembler ist schon ne ganze weile her :-) Ist halt nur so, dass ich, wenn das jetzt dann mal mit der SD-Card hinbekommen habe, einen 6510-Emulator, den ich in C# geschrieben habe (schon fertig) auf den ARM7 portieren möchte. Dazu wäre es mir halt ganz recht genau zu wissen, wieviele ARM-Befehle für die Emulation der einzelnen 6510-Befehle "draufgehen". Das Ganze soll ja idealerweise auch halbwegs Zyklengenau sein. Mir wäre es auch recht, das Ganze bei den 18MHz zu belassen (wg. Stromverbrauch). Deswegen an dieser Stelle die beharrlichkeit auf ASM. Das mit der SD-Card wird aber wahrscheinlich sau-schwer, wenn ich nicht irgendwo eine vernünftige Möglichkeit habe, einen (auch mal langen) Log-File auszugeben. Dazu wollte ich halt eine serielle Verbindung zu meinem PC. Naja, was mir heute Nacht noch eingefallen ist: Wenn ich das mit der seriellen Verbindung so nicht hinbekomme (habe kein Oszi zum Prüfen, was da Seriell so produziert wird und kenne mich auch mit Oszis nicht aus): Vielleicht sollte ich auf dem PC ein Programm schreiben, das auf den Parallelport "lausch" und da Zeichen empfängt, so wie ich sie sende. Da kann ich dann wenigstens mit meinen LEDs vorher checken, was auf der Leitung los ist. Wäre nur ne absolute Notlösung! Am liebsten wäre es mir, wenn mir jemand mit der Seriellen Verbindung einen wichtigen Hinweis geben könnte (vielleicht auch nur in Form eines Ablaufplans (grobe Beschreibung), was zu tun ist)! Wäre ewig schade darum, wenn auf dem Board schon alles vorhanden ist, was man braucht. Dankeschön!
Bevor man an verschiedenen Baustellen (Hardware/Software) herumwurschtelt kann mit einem getesteten Beispiel-Code für UART in C zumindest einen Hardware- oder Anschlussfehler ausschliessen und sich zudem noch von dem vom C-Compilers erzeugten Assembler Code inspirieren lassen. Wie soll die Emulation von C64-Hardware neben dem 6510-Prozessor wie VIC, SID, Floppy etc. "zyklengenau" aussehen? Eine Speicherkarte hatte der C64 nicht, welche "Zyklengenauigkeit" sollte die Emulation dafür einhalten sollen? Auch wenn das das Thema schon durch ist und bisher auf reinem ASM beharrt wurde: Ein mixed language-Ansatz dürfte viel Zeit, Frust und "Notlösungen" sparen. Vieles in C implementieren (es gibt für SAM7 u.a. einiges an fertigem SD-Karten-Code in C) und nur wenn es sein muss, "zyklen"-optimierten Assemblercode in Form von Inline-Assembler oder Assembler-Funktionen nutzen. "Ablaufplan" UART SAM7 pooling-mode: Init: - UART Clock aktivieren (PCER) - Pin-Funktionen auf UART (PDR) - UART Modus einstellen (MR) - UART Baudrate einstellen (BGBR) - Receiver/Transmitter einschalten (CR) Senden: - warten bis TXRDY-Bit gelöscht (CSR) - Zeichen schreiben (in THR) Empfangen: - warten bis RXRDY-Bit gelöscht (CSR) - Zeichen lesen (aus RHR) Hoffe, es hilft Martin Thomas
@mthomas zunächst mal vielen herzlichen Dank, für die ausführliche und informative Antwort! >Wie soll die Emulation von C64-Hardware neben dem 6510-Prozessor wie >VIC, SID, Floppy etc. "zyklengenau" aussehen? Dass der 6510 gleich einen Kompletten C64 mit Floppy und Pi-Pa-Po assoziert finde ich amüsant :-) Ne im Ernst: Es geht mir ganz am Ende um einen SID-Player, der den original SID anspricht (natürlich gesockelt :-). Das mit dem Zyklengenau ist nicht ganz so wild, weil in der Geschwindigkeit, in der der SID angesprochen wird davon wohl wenig zu hören ist. Aber prinzipiell möchte ich mich schon daran halten... Ja, ich weiß, dass es schon jemand gibt, der sowas in der Art mit nem ATMEGA gemacht hat. Ist mir aber wurst, weil ich es halt auch probieren möchte. Der SAM7S256 bietet sich IMHO auch geradezu als Herz an, weil er 64KB RAM hat :-) Das Projekt wird noch ne Ewigkeit dauern, aber das macht nicht. Ist halt nur ein Hobby, für das ich nebenbeigesagt nur sehr wenig Zeit übrig habe... Für diejenigen, die es interessiert: http://www.pippinger.de/content/view/16/30/
@mthomas >Init: >- UART Clock aktivieren (PCER) >- Pin-Funktionen auf UART (PDR) >- UART Modus einstellen (MR) > UART Baudrate einstellen (BGBR) >- Receiver/Transmitter einschalten (CR) > >Senden: >- warten bis TXRDY-Bit gelöscht (CSR) >- Zeichen schreiben (in THR) ...eine Frage hätte ich da noch: Kann ich dann dieses Zeichen mit Hyperterm empfangen, wenn ich wie beschrieben vorgehe?
Thread beobachten
Seitenaufteilung abschalten
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.