mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik RS232 mit dem AT91SAM7S256


Autor: Peter Pippinger (axis)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Peter Pippinger (axis)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stephan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Peter Pippinger (axis)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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?

Autor: Greg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Peter!

>DRXD Empfangen bedeutet und DTXD transfer
Genau so ist es.

Gruß,
Greg.

Autor: Peter Pippinger (axis)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn in den RS232 Buchsen Stifte sind dann brauchst
du ein Nullmodem-Kabel.

Autor: Peter Pippinger (axis)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Auf dem Board sind "weibliche" Anschlüsse und am PC habe ich einen 
"männlichen" Anschluss.

Autor: Peter Pippinger (axis)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :-)

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Peter Pippinger (axis)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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 !

Autor: Peter Pippinger (axis)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Peter Pippinger (axis)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 
:-(

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Peter Pippinger (axis)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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!

Autor: mthomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Peter Pippinger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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/

Autor: Peter Pippinger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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?

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.