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
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.
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
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
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.
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.)
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
"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
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
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.
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.
"-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
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
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.
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).
@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
@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
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
Parport ist ein Auslaufmodell und man kommt in WinNT/2000/XP nur schlecht an den Port ran.
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.
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
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).
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.
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?
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.
@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
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.
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
@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.
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ß.
@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
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.
@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.
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
Thread beobachten
Seitenaufteilung abschaltenBitte 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.