mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik vom µC zum PC


Autor: klausi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo,
bin auf der suche nach infomaterial zur µC programmierung. habe im net
gesucht aber nichts richtiges gefunden. habe mir auch hier auf der
seite das avr-tutorial angeschaut aber nichts was mich weiter
informiert.
und zwar möchte ich durch das parallelport daten vom µC zum PC
übertragen, z.Z. ist das alles neuland für mich, finde wahrscheinlich
nicht mal die passenden stichwörter um was in google zu finden was mich
zufrieden stellen würde bzw bischen klarheit schaffen würde. kann mich
jemand aufklären, was mich da erwartet, was ich zu beachten habe, wie
ich vorgehen sollte......?
habe noch nie was mit datenübertragung gemacht.

danke jetzt schon für eure hilfe

klausi

Autor: thkais (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wieso soll es unbedingt der Parallelport sein?
Erstmal die Frage: Wieviele Daten pro Zeiteinheit möchtest Du
übertragen? Falls das mit der seriellen Schnittstelle möglich ist,
würde ich es mit dieser machen, da wesentlich einfacher und
störungssicherer.
Ansonsten schau Dir mal die Übertragungsprotokolle von Druckern an, die
können seit einiger Zeit auch bidirektional übertragen.

Autor: Jens123 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
wuerd ich auch sagen..
Bei der Paralelen schnitstelle musst du dir die ganzen dinnge selbst
zusammensuchen ist auch nicht gelaeufig diese schnitstelle zu nutzen
sprich du muesstest dir das gesammte protokoll selbst schreiben..

Wenn es nur ein paar messwerte etc sind kannst du ohne Probleme die
RS232 nehmen oder USB mit einem standart FTDI Chip.. (ist ein USB nach
RS232 Converter).

Gruss Jens

Autor: klausi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
moin,
also es soll ein parallelport sein, weil eine grosse datenmenge
übertragen werden soll. und somit muss ich das Übertragungsprotokoll
selber machen, wie kann ich da am besten anfangen?
es gibt doch bestimmt schon fertige (in basic) oder?
vielleicht könnte ich mir daraus meine benötigten informationen saugen.
habe über handshake usw. gelesen aber wie das programmiert wird stand
niergends.


>Ansonsten schau Dir mal die Übertragungsprotokolle von Druckern an,
>die können seit einiger Zeit auch bidirektional übertragen.

habe nach solchen Übertragungsprotokoll im net gesucht aber nicht
wirklich was dazu gefunden.

mfg
klausi

Autor: Alex (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie groß ist denn die Datenmenge? Kann mir kaum vorstellen, dass
115kBaud nicht ausreichen.
Handshake ist eigentlich nicht mehr gebräuchlich, eher stellt man die
Daten in einem Frameformat zur Verfügung.
Header + Daten + CRC
So kann der PC die ankommenden Daten auf Richtigkeit prüfen.

Autor: thkais (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Poste doch bitte mal genau, was Du vor hast. Dann kann man Dir
wesentlich besser helfen. Bislang ist alles nur vage ausgedrückt,
"große" Datenmengen etc... das ist alles Ansichtssache.
Wenn man mal ganz ehrlich ist, überträgt man große Datenmengen
heutzutage per USB oder Firewire.
Das nächste Problem ist der µC. Wo bekommt der seine Daten her? Wenns
wirklich schnell gehen soll, ist der innerhalb von millisekunden
leergesaugt. Abgesehen von den Problemen, die Du Dir mit einer
parallelen Schnittstelle einhandeln kannst (Abstrahlung, Einkopplungen
etc.)

Autor: Weihnachtsmann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo

Leute schiessen häufig übers Ziel hinaus. Zuerste sollte man sich
überlegen wieviele Daten will ich pro Zeit erfassen. Es macht keinen
Sinn z.B. doppel soviele Daten zu er fassen wenn die hälfte reicht.
Ich bin auch ziemlich sicher das bei dir die RS232 völlig reicht.

Gruss

Weihnachtsmann

Autor: peter dannegger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Leute schiessen häufig übers Ziel hinaus."


Ich würde eher sagen: "Leute machen sich keine Gedanken"

Die meisten Projekte scheitern an einer ungenügenden oder fehlenden
Projektvorbereitung und nicht an geringen Programmierkenntnissen.

Wer als Anfänger sofort drauflos programmieren will, muß zwangsläufig
scheitern.


Peter

Autor: klausi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo,

Also die 115kBaud werden nicht ganz ausreichen.
den ich möchte mit  2 sensoren messen, die eine abtastrate von max
50kHz haben, das wären dann max 100kHz insgesamt, oder?
nach meiner berechnung:
-pro abtastung 2 byte (16 bit wert) -> 200kbyte/s insgesamt.

dann würde ich beim parallelport eine baudrate von 200kbyte*8 =
1 600 000Baud brauchen, oder?
Bin schon ganz verwirrt.


>Handshake ist eigentlich nicht mehr gebräuchlich, eher stellt man die
>Daten in einem Frameformat zur Verfügung.
>Header + Daten + CRC
>So kann der PC die ankommenden Daten auf Richtigkeit prüfen.

also so habe ich es auch vor mit einem crc check usw. aber der
handshake ist bei mir auch wichtig, denn sonst könnten mit daten
verloren gehen. und so könnte ich die daten puffern, und irgendwie dann
verwalten mit den handshake (kein überlauf usw.). weiss noch nicht wie
habe nach solchen beispielen gesucht auch nach protokoll vom drucker
aber ich finde nichts, habe wirklich nachgeschaut.

das system soll so funktionieren das ich mit hilfe des µC die daten vom
sensor verwalte und per parallelport zum pc übertrage.

@peter&Co
mache mir schon gedanken nur man kann nicht alles in einer kurzen zeit
verstehen, und man sitzt manchmal in einer sackgasse und kommt in
dieser für mich komplexen welt der daten übertragung nicht weiter.

hoffe  ihr könnt mich jetzt besser verstehen.

mfg
klausi

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Obacht. Der Parport klingt bloss schnell. Und mag es auch sein, wenn Du
auf Device-Driver Ebene im Windows rumbasteln willst (viel Spass
dabei).

Von einem Anwendungsprogramm aus kommt man da da jedoch von Haus aus
unter WinXP garnicht ran, da braucht's immer einen Treiber dazwischen
(z.B. GiveIO). Wieviel Performance bleibt bei der Konstruktion noch
übrig? Ausprobieren.

Unschön auch, dass evtl. schon die nächste Rechnergeneration garkeinen
Parport mehr haben wird. Und auch dir üblichen USB-Varianten mit
serieller Emulation machen oft vorher schlapp. Wird also "echtes" USB
fällig, was nun aber auch wieder auf Windows Device-Driver rausläuft.

Bei dieser Rate solltest Du mal ernsthaft in Richtung Ethernet
nachdenken. Ist natürlich 1-2 Komplexitätsklassen höher.

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Apropos Komplexität. Mir spukt da eine verrückte Idee im Kopf
rum.Vielleicht kommt das bloss daher, dass ich damit etwas auskenne (if
all you have is a hammer then everythink looks like nail), aber was
dafür durchaus in Frage kommt und recht wenig Aufwand bereitet: SCSI.
Und zwar das schöne alte SCSI-1 asynchron. Adapter gibt's für wenig
Geld bei eBay (Scanner-Adapter dürfte reichen), das Protokoll ist
harmlos, schnell genug ist es und es ist kein speziellen Treiber in
Windows oder Linux nötig.

Autor: Quark (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"-pro abtastung 2 byte (16 bit wert) -> 200kbyte/s insgesamt.

dann würde ich beim parallelport eine baudrate von 200kbyte*8 =
1 600 000Baud brauchen, oder?
Bin schon ganz verwirrt."

der Par. Port würde ja schon 8 Bit pro Schritt übertragen.
200KB * 1024 = 204800 Byte/sek

hier sind es ja nur 200kB also 200000 Byte/sek

habe ich mich jetzt völlig vertan?

Grüße

Quark

Autor: klausi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo,

>der Par. Port würde ja schon 8 Bit pro Schritt übertragen.
>200KB * 1024 = 204800 Byte/sek
>hier sind es ja nur 200kB also 200000 Byte/sek

verstehe deine rechnung nicht!
würde sagen:
200kBaud *1024 = 204 MByte/s

wieso eigentlich die baudrate mit 1024 multiplizieren?

ist nicht Byte/s = Baudrate/8bit(beim parallelpoort)????????

welche berechnung ist nun richtig bin jetzt schon total verwirrt!
ist die berechnung mit der abtastfrequenz usw. s.o. richtig?

danke schon jetzt für die aufklärung

der verwirrte klausi

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Deine Rechnung war schon richtig. Du hast 200KByte/s an Daten.

Autor: Philipp Burch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

Also für die Datenmenge würde ich mal sagen:
200000Byte/s / 8Bit = 25kHz
Allerdings würde ich nicht darauf wetten, dass der ParPort so schnell
ist. Sowas würde ich in jedem Fall mit dem USB machen.

Autor: Lord Witty (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Ihr Künstler!

Nochmal zu Eurer Rechnung...
16 Bit x 50.000 1/s = 800.000 Bit/s

Eine Serielle Schnittstelle schafft, wie oben bereits erwähnt 115KBit/s
-> (115 x 1024)Bit/s = 117760Bit/s an Reindaten zu übertragen
(theoretisch). - Da gehen dann noch ein wenigstens ein Start- und ein
Stopp-Bit mit.
Für eine Halbwegs sichere Übertragung zwischen den recht schnellen AVRs
und einem WinPC kann man aber nicht mehr als 38.400 Bit/s empfehlen.
Viel mehr schafft man trotz Übertaktung solch eines µC sowieso nicht.
Es ist außerdem noch zu überlegen, wo ich mit den Daten hin will, und
über welchen Zeitraum ich sie aufzeichne (Gesamtmenge der Daten).
- Die serielle Schnittstelle ist also gänzlich ungeeignet, wenn ich
wirklich jedes Bit brauche.

Klausi! Überdenke, ob Du die von den Sensoren erhaltenen Meßwerte vor
der Übertragung runterrechnen kannst (z.B. Mittelwertbildung).

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Philip:
Du teilst Byte durch Bit.
200.000 Byte/s / 8 Bit = 200.000kHz.

@Lord Witty:
Er hat zwei Sensoren, also 200 KByte/s bzw. 1.600.000 Bit

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Lord Witty:
Die serielle Schnittstelle macht 115200 Baud, nicht 117760.

Und mir ist auch nicht klar, warum ein Microcontroller die 115200 Bits
pro Sekunde kaum schaffen sollte. Jeder etwas bessere MC hat heutzutage
doch einen Hardware-UART, womit sich das Senden eines Bytes (10Bit) auf
das setzen einiger Register beschränkt. Damit sind das etwa 11000 Bytes
die man pro Sekunde senden muß. Ein AVR mit 16MHz hat dabei 1600 Takte
Zeit um ein einzelnes Byte zu senden. Das ist ja wohl mehr als
ausreichend. (Hilft Klausi aber natürlich trotzdem nicht weiter).

Es gibt übrigens auch USB-RS232-Kabel, die mehr als 115200bps fahren
können, teilweise muß man dazu den Treiber im PC patchen. 460800bps
habe ich damit zu meinem Handy stabil zum laufen bekommen und da ist
schließlich auch nur ein Microcontroller drin.

Aber auch diese 46KByte/s reichen Klausi natürlich noch nicht, aber ein
paraller USB-Chip wie der FT245 sollte eigentlich schnell genug für
sowas sein.

Markus

Autor: klausi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
moin,
freut mich ja das meine rechnung richtig war.

also wird ein usb empfohlen!
wieso besteht eigentlich eine abneigung gegen das parallelport?
wegen dem protokoll das man beim parallelport selbst machen muss?
wieviel an daten und kanälen kann ich mit usb max übertragen?

wieviel kann denn ein parallelport maximal an baudrate haben?

mfg
klausi

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Parport ist ein Auslaufmodell und man kommt in WinNT/2000/XP nur
schlecht an den Port ran.

Autor: Johannes Raschke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich finde Lord Wittys Vorschlag sehr gut...
Warum nicht eine ADPCM  - Übertragung über den seriellen Port? Oder
schwanken Deine Daten so extrem? Damit kannst Du locker die Daten aud
die Hälfte reduzieren, mit geringem Aufwand auf dem Controller.

Autor: klausi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo,
ist schon eine gute idee, aber meine daten schwanken und ich möchte mir
doch die messung online anschauen. sonst kann ich auch die serielle
nehmen, daten rüberziehen und angucken, aber es sollte schon so und so
funktionieren.

ist ein SCSI port = Parallel port???
ja, oder?

mfg
klausi

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
SCSI ist althergebracht parallel, neuerdings auch seriell, aber hier
interessiert allenfalls die parallele 8-Bit Variante. Und als
Parallelport bezeichnet mal i.A. den Druckerport, auch
Centronics-Schnittstelle genannt. Die haben ungefähr soviel gemeinsam
wie USB und RS232 (beide sind seriell, aber das war's auch schon).

Autor: Thomas Forster (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich habe in GFA-Basic eine Abfrage von 2 8-Bit AD-Wandlern am Par-Port
geschrieben. Auf einen Athlon XP1900 schafft man damit ca. 40.000
Byte/s. Also nicht wirklich schnell. Um richtig schnell zu werden, wie
Klausi es will, braucht es schon Assembler. Dann sind evtl 1MByte/s
drin, wobei man dann sicher Probleme unter WinXP und gleichzeitigem
direktem Portzugriff bekommt. USB scheint der richtigere Weg.

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Assembler als Allheilmittel?

Erinnert mich an jemanden, der in heutiger Zeit mit
Assembler-Programmierung versucht, ein Interface-Programm für ein
ISA-Bus-Gerät zu beschleunigen. Und dabei vergisst, dass der ISA-Bus
grob gerechnet eine Mikrosekunde für einen Buszyklus braucht. In dieser
Zeit hat der Prozessor im Gegenwert von mehreren tausend Befehlen
Däumchen gedreht. Ob's da wirklich drauf ankommt, ob er diese Däumchen
in Assembler oder Hochsprache dreht?

Autor: Thomas Forster (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Klausi wollte in Basic programmieren. Wie ich schrub, schaffte ich damit
seine gewünschte Datenemenge bei weitem nicht. Ich glaube also nicht,
dass er es schafft.
Die Spec des EPP-Par-Port gibt über 500.000 Byte/s her. Selbst bei
einer alten 8-Bit-ISA - du schreibst von 1us - sind also rein
rechnerich knapp 1.000.000 Byte/s drin. Oder irre ich jetzt.

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Thomas Forster:
Ich muß AK hier aber unbedingt beipflichten. Ich kann mir nicht
vorstellen, daß Dein Basic 40.000 Takte braucht, um ein einzelnes Byte
vom Parallelport zu lesen. Da wird wohl irgendetwas anderes der
begrenzende Faktor sein.

@Johannes Raschke:
Klausi hat 200KByte/s an Rohdaten, die serielle Schnittstelle macht
etwa 11KByte/s, d.h. er müsste ungefähr 1:20 komprimieren. Das ist
schon recht heftig.

Markus

Autor: thkais (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sehe ich auch so. Man darf die heutigen verfügbaren Basic-Compiler nicht
mehr mit Interpretern vergleichen, PureBasic beispielsweise kann es ohne
weiteres mit anderen aktuellen Hochsprachen aufnehmen.
Hauptbremsklotz ist Microsoft (wie so oft). Die Bequemlichkeit, nur
Bilder herumschieben zu müssen, anstelle Befehle einzugeben, muß man
sich mit einigem Overhead erkaufen. Wer mir nicht glaubt, der möge mal
DOS auf einem 1GHz-Prozessor installieren (sofern mans zum Laufen
kriegt) und staunen, wie schnell so ein PC doch sein kann.
USB ist auch kein Allheilmittel. Bei 200KB/sek. kommt man nicht mehr
mit den einfach anzuwendenden Lösungen aus, da muß man einen guten
Treiber bekommen oder selber schreiben. Und dann kommt dazu, daß USB
von Haus aus nicht synchron ist, weil man nie weiß, wann das
Betriebssystem sich gerade bequemt, den Puffer zu leeren. Bei
Dateiübertragungen ist das wurscht, aber bei Daten, die zeitkritisch
sind, kannst Du es vergessen.
Die parallel-Schnittstelle ist für solche Anwendungen nach wie vor
ideal - auch wenn sie (leider) ausstirbt.

Autor: klausi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hat den jemand schon so ein parallel port protokoll programmiert? und in
welcher sprache? ist das eigentlich egal? wo gibt es diese treiber(ist
der treiber quasi das protokoll?)?

wieviel schafft den jetzt ein parallel port maximal? 1MByte/s  ???

den µC werde ich in assambler programmieren müssen, wird doch nicht
allzu schwer hoffe ich, habe noch keine erfahrung in assambler.
wenn jemand so was schon mal gemacht hat bzw. was ähnliches und mir ein
beispiel code, oder rat geben könnte, auf was ich achten sollte usw.
bitte her damit.

mfg
klausi

Autor: Johannes Raschke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Markus
Oops, da ist ja noch der Faktor 10, den ich übersehen habe... So wird
das mit Komprimierung natürlich nichts...

Ich habe mir gerade mal eine Beschreibung der SCSI - Schnittstelle
angesehen - das ist nicht gerade trivial, was da passiert. Es gibt acht
Phasen der Kommunikation auf dem Bus. Wenn man Controller-unabhängig
sein will, muß man wohl einigen Overhead programieren...
Am einfachsten wäre wahrscheinlich tatsächlich der LPT-Port oder eine
ISA-Karte und direkte Programmierung unter DOS...
Der Paralelport kann ohne Erweiterungen wie EPP ca. 100kbyte/s
übertragen.

Autor: Johannes Raschke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie man das Ding programmiert, steht z.B. in "PC Hardware" von
Hans-Peter Messmer. Im einfachsten Fall ständig ein Register auslesen
(Status) und wenn was kommt, ein anderes Register lesen (Daten). Unter
DOS mit C oder ASM sehr einfach, unter Linux habe ich es auch mal
hinbekommen (eigenes Kernelmodul), aber unter Windows... geht es
sicherlich auch irgendwie. Viel Spaß.

Autor: klausi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Johannes Raschke
kannst du mir die links zu deinen posting schicken:

-Beschreibung der SCSI - Schnittstelle
-"PC Hardware" von Hans-Peter Messmer
zum letzteren finde ich nur bücher die ich bestellen könnte!

mfg
klausi

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei SCSI würde ich mich auf SCSI-1 asynchron beschränken und den ganzen
Zirkus mit den Message-Bytes und Disconnect/Reconnect in die Tonne
kippen. Viel bleibt dann m.E. nicht mehr übrig.

Autor: Johannes Raschke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Klausi

Das Buch besteht tatsächlich aus Papier, früher war sowas mal modern...
Von daher ist es schlecht mit einem Link...
Die SCSI - Geschichte ist darin auf ca. 20 Seiten beschrieben, das
würde aber wohl sowieso nicht reichen, um eine Hardware dafür zu
bauen.
Die Seiten mit der Parallelport - Beschreibung könnte ich evtl. mal
einscannen, falls Du nirgendwo anders diese Information finden
solltest.

Autor: Quark (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ist schon alles richtig so.
habe mich ja auf diese Aussage bezogen:

"dann würde ich beim parallelport eine baudrate von 200kbyte*8 =
1 600 000Baud brauchen, oder?
Bin schon ganz verwirrt."

@klausi
"200kBaud *1024 = 204 MByte/s"

meinte für KByte/s in in Byte/sek, da stimmt die 1024 schon.
Du hast ja das gleiche raus, ist ja korrekt. Ich bezog mich nur auf die
"1 600 000Baud " am Par. Port.
Quark

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.