Hallo zusammen, Ich weiss dass es hier schon X-Mal diskutiert und gefragt wurde aber trotzdem stelle ich die frage nochmal : Ich möchte mit einem uC daten an einen Computer senden und ggf. wieder empfangen. Ich bin erstmal einfach auf der Suche nach einem sehr simplen Programm das einige bytes per rs 232 dem computer übergibt. Jedoch ist mir noch einiges unklar : - wie speichert man die empfangenen daten auf der festplatte? - mit welchem programm arbeitet man am besten bzw. wie gibt man vom pc am besten daten auf die schnittstelle ( geht das mit visual C#) ? - wieviele frames kann man hintereinander senden / wann muss man ein break einfügen ? wie schon gesagt hab ich schon viele libraries gefunden jedoch meistens nur für das uC seitige programm. vielen dank im voraus hannes
Auf dem PC kann man machen, was man will, solange es mit dem Programm auf dem controller zusammenpasst. Ja, man kann etwas mit C# zusammenkloppen, oder Visalbasic, oder Delphi, oder irgendwas. Ich weiss, es ist moeglicherweise nicht das Erwartete.
Hannes schrieb: > Hallo zusammen, > Ich weiss dass es hier schon X-Mal diskutiert und gefragt wurde aber > trotzdem stelle ich die frage nochmal : Super Idee! > Ich möchte mit einem uC daten an einen Computer senden und ggf. wieder > empfangen. Ich bin erstmal einfach auf der Suche nach einem sehr simplen > Programm das einige bytes per rs 232 dem computer übergibt. > Jedoch ist mir noch einiges unklar : > - wie speichert man die empfangenen daten auf der festplatte? Ein Programm empfängt sie und speichert sie. > - mit welchem programm arbeitet man am besten bzw. wie gibt man vom pc > am besten daten auf die schnittstelle ( geht das mit visual C#) ? Das ist völlig egal. Du kannst ein Terminalprogramm zu testen nehmen. Und mit jeder beliebigen Programmiersprache kannst du ein programm schreiben welches mit deinem Controller kommuniziert. > - wieviele frames kann man hintereinander senden / wann muss man ein > break einfügen ? Unendlich viele und man muss keine breaks einfügen. Das Protokoll und die Geschwindigkeit legst du fest. Kommt auf dein Programm an. > wie schon gesagt hab ich schon viele libraries gefunden jedoch meistens > nur für das uC seitige programm. Was für libs suchst du denn? Wie man die serielle Schnittstelle ansteuert solltest du in der Referenz zu deiner Programmiersprache nachlesen können. Den Rest musst du selbst machen. Diese Frage kommt sehr oft. Ich weiß nicht was hier als Antwort erwartet wird. Man muss selber ein Protokoll definieren und dann auf beiden Seiten ein Programm schreiben, welches dieses Protokoll spricht. Entweder man kann das oder man muss eben kleinere Brötchen backen. Die serielle Schnittstelle kann Bytes hin und her senden, das wars. Alles andere muss man selbst überlegen und umsetzen. Vielleicht erhellst du uns mal und sagst uns was du genau für Infos suchst. Das ist alles sehr vage. Was erwartest du als Antwort vom Forum? gruß cyblord
Hannes schrieb: > Jedoch ist mir noch einiges unklar : > - wie speichert man die empfangenen daten auf der festplatte? > - mit welchem programm arbeitet man am besten Dasjenige, das du am PC beherrscht (bzw. die Programmiersprache die du am PC beherrscht) und welches dir Zugang zur Seriellen Schnittstelle gestattet (also alle Programmiersprachen, es geht aber auch zb mit Excel auf die Serielle zuzugreifen) > - wieviele frames kann man hintereinander senden / wann muss man ein > break einfügen ? kann man nicht pauschal sagen. Auf dem PC hast du ja haufenweise Speicherplatz. Wenn also dein PC-Programm erst mal alles im Speicher zwischenspeichert, kann der µC schon eine Menge generieren, bis es am PC eng wird. > wie schon gesagt hab ich schon viele libraries gefunden jedoch meistens > nur für das uC seitige programm. Logisch. Es gibt kein Standard- 'Überwache die Serielle und speichere alles was da rein kommt' Programm. Das wirst du wohl selber schreiben müssen, wenn dir die Möglichkeiten zb eines Terminalprogramms, welche eine Sitzung abspeichern kann, nicht ausreichen. Aber: Im Regelfall will man ja nicht einfach nur das Empfangene abspeichern, sondern man will damit auf dem PC etwas tun. Zb anzeigen, zb dem Benutzer in Form einer Grafik präsentieren, zb dem Benutzer den Status mit irgendwelchen Controls anzeigen etc. etc. D.h. da programmiert man sich dann sowieso auf dem PC eine Applikation dafür.
Konkret: In dem von dir angesprochenen C#, gibt es eine Klasse "SerialPort". Damit kannst du Daten über die serielle Schnittstelle senden und empfangen. Schaust du im MSDN nach, dort steht alles zu dieser Klasse und wie man sie benutzt. Das wäre z.B. ein Ansatzpunkt für ein eigenes C# Programm. gruß cyblord
danke schonmal für die antworten. ich hab vor 8 dmx kanälen über den pc deren werte ( 8bit ) zu übergeben. Im Programm (vermutlich C#) soll man über eine trackbar den wert für jeden kanal einstellen können. diese sollen dann hintereinander über den seriellen port rausgesendent werden. @Karl Heinz Buchegger dann könnte ich ja die verbindung nach dem 8ten gesendeten byte schon abbrechen und wieder von vorne angangen oder ? wenn ja : erzeugt man den break auch hier mit einer veränderung der baudraten und einem gesendeten nullbyte?
Hannes schrieb: > wieder von vorne angangen oder ? wenn ja : erzeugt man den break auch > hier mit einer veränderung der baudraten und einem gesendeten nullbyte? Die Gegenstelle (also der µC) kann nicht unterscheiden, wie genau du dafür sorgst, dass die Datenleitung die geforderte Mindestzeit Low bliebt. Von daher: Ja, sicher. So kann man das machen: Baudrate auf langsamer stellen und 0-Byte ausgeben.
Bewährt haben sich für sowas Frames. Ein Frame kann dann z.B. bestehen aus: Ein Startbyte, 8 Datenbytes, ein Endbyte und dann noch ne CRC Checksum ans Ende. Das ganze kann man gut mithilfe kurzer Pausen zwischen den Frames syncronisieren und mit der CRC ist man relativ sicher dass alles ok ist. gruß cyblord
Lass das mal mit dem Break, das ist ein sehr seltener Sonderfall. Mit würde es nicht wundern, wenn zahlreiche serielle Übertragungsmodule/Adapter das gar nicht können. "Verbindung Trennen" geht bei einer RS232 Schnittstelle nur, indem man das Kabel absteckt. Solange ein RS2323 Kabel an zwei Geräte angesteckt ist, sind sie verbunden. Und zwar ständig. Du musst Dir ein Protokoll ausdenken. 8 Werte nacheinander zu übertragen ist schonmal ein guter Anfang. Aber Du musst auch irgendwie übertragen, wo Anfang und Ende eines solchen 8er Blockes ist. Im einfachsten Fall kann die Zeit dazu verwendet werden. Wenn z.B. für mindestens 100ms nicht übertragen wurde, dann ist das eine Pause, und nach der Pause kommt immer der Wert für den ersten Kanal, dann der zweite kanal usw. Oder man verpackt die acht Werte in Pakete, deren Anfang eindeutig erkennbar ist und die eventuell sogar noch durch eine Prüfsumme abgesichert werden. Bei Modems fangen zum Beispiel alle Befehle mit "AT" an und enden mit einem Zeilenumbruch. So erkennt das Modem stets Anfang und Ende eines Befehls. Da kannst Du natürlich auch drauf aufbauen. Anstatt binäre Datenwerte zu übertragen, könntest Du Befehle mit Parametern als Text codiert übertragen, so wie Modem-Befehle. Dieses Protokoll musst Du Dir schon selbst ausdenken. Es sei denn, für genau Deinen Anwendungsfall gibt es schon ein Standard-Protokoll, dann würde ich das verwenden. Ein allgemein universelles Standardprotokoll, wonach Du fragts, kann es nicht geben.
Wenn DMX gefordert ist, dann hat er aber keine große Wahl. Allerdings erhebt sich die Frage, warum man DMX benutzt, wenn man selber sowohl den Sender als auch den Empfänger programmiert. Ohne Not würde ich mir dieses
1 | Ein DMX-Paket beginnt mit mindestens 88 µs (22 Bitlängen) |
2 | niedrigem Pegel (logisch 0) - dieser Abschnitt wird „Break“ genannt. |
nicht antun. Und ehrlich gesagt ist mir nicht wirklich klar, was sich die Macher von DMX dabei gedacht haben. Das hier
1 | Dies ermöglicht eine einfache Erkennung des Paketanfangs, da quasi |
2 | jeder handelsübliche UART den Break als ungültiges Datenbyte mit |
3 | fehlenden Stoppbits meldet. |
klingt zwar gut, ist es aber bei genauerem Hinsehen nicht. Paketanfang erkennen, indem man beim Empfänger einen Fehler generiert? Nein danke.
Karl Heinz Buchegger schrieb: > Wenn DMX gefordert ist, dann hat er aber keine große Wahl. Ach ist DMX auf der seriellen Schnittstelle gefordert. Ja dann siehts anders aus. > klingt zwar gut, ist es aber bei genauerem Hinsehen nicht. Paketanfang > erkennen, indem man beim Empfänger einen Fehler generiert? Nein danke. Naja, Coderegelverletzungen werden dafür oft hergenommen. Schon die Start- und Stop Bedingung bei I2C sind eigentlich solche Regelverletzungen.
Meine idee ist es gewünschte werte im pc abspeichern zu können und dann über irgendein protokoll rauszugeben . dieser datenstrom soll von einem attiny empfangen werden und per spi an einen anderen atmega übergeben werden. dieser leist dann noch ein paar taster und analogwerte ein , packt die gemessenen werte mit den über den attiny empfangenen werte zusammen und sendet das ergebnis als dmx signal aus.
cyblord ---- schrieb: > Karl Heinz Buchegger schrieb: >> Wenn DMX gefordert ist, dann hat er aber keine große Wahl. > > Ach ist DMX auf der seriellen Schnittstelle gefordert. Ja dann siehts > anders aus.
1 | >ich hab vor 8 dmx kanälen über den pc deren werte ( 8bit ) zu übergeben. |
> Naja, Coderegelverletzungen werden dafür oft hergenommen. Schon die > Start- und Stop Bedingung bei I2C sind eigentlich solche > Regelverletzungen. OK. Aber I2C wird auch eher selten auf der Bühne eingesetzt, bei der auch schon mal wer über Kabel stolpert. Ihr kennt meine Einstellung: Eine UART Verbindung muss so ausgelegt sein, dass die Putzfrau den Stecker ziehen kann, wieder einsteckt und alles muss ohne Fehlfunktion weiterlaufen.
Karl Heinz Buchegger schrieb: > cyblord ---- schrieb: >> Karl Heinz Buchegger schrieb: >>> Wenn DMX gefordert ist, dann hat er aber keine große Wahl. >> >> Ach ist DMX auf der seriellen Schnittstelle gefordert. Ja dann siehts >> anders aus. > >
1 | >>ich hab vor 8 dmx kanälen über den pc deren werte ( 8bit ) zu übergeben. |
2 | > |
Ja ich dachte die Daten stammen aus einer DMX Verbindung, sollen aber einfach nur an den PC gesendet und dort angezeigt werden. > Ihr kennt meine Einstellung: Eine UART Verbindung muss so ausgelegt > sein, dass die Putzfrau den Stecker ziehen kann, wieder einsteckt und > alles muss ohne Fehlfunktion weiterlaufen. Ist ja auch richtig so.
Ah, neue Entwicklung in der Causa RS232 Sieht so aus, als ob cyblord recht hat Hannes schrieb: > Meine idee ist es gewünschte werte im pc abspeichern zu können und dann > über irgendein protokoll rauszugeben . dieser datenstrom soll von einem > attiny empfangen werden und per spi an einen anderen atmega übergeben > werden. Wozu der Tiny? .... > dieser leist dann noch ein paar taster und analogwerte ein , > packt die gemessenen werte mit den über den attiny empfangenen werte > zusammen und sendet das ergebnis als dmx signal aus. .... es gibt auch Megas mit mehr als einer USART. Mehrere Prozessoren vereinfachen ein Design eher selten. Meistens verkomplizieren sie nur alles. D.h. die Verbindung PC-Mega hat erst mal nichts mit DMX zu tun?
cyblord ---- schrieb: > Ja ich dachte die Daten stammen aus einer DMX Verbindung, sollen aber > einfach nur an den PC gesendet und dort angezeigt werden. Ich hab den Mega als das 'DMX' Device gesehen, an dem die Scheinwerfer hängen.
@Karl Heinz Buchegger welchen controller würdest du mir dafür empfehlen ? das mit dem dmx hat erstmal nix mir der rs232 übertragung zu tun... sehe ich es jetzt richtig dass ich den pc UART anch meinen vorstellungen initialisierten muss ( z.b 1 startbit,1 stoppbit,8 datenbits) und dann das zu sendene protokoll implementieren muss ( z.b. sende erst die kanalnummer danch den wert). und dazu den uC einfach als empfanger anpassen . richtig ?
Hannes schrieb: > sehe ich es jetzt richtig dass ich den pc UART anch meinen vorstellungen > initialisierten muss ( z.b 1 startbit,1 stoppbit,8 datenbits) und dann > das zu sendene protokoll implementieren muss ( z.b. sende erst die > kanalnummer danch den wert). und dazu den uC einfach als empfanger > anpassen . richtig ? Ja.
Hannes schrieb: > @Karl Heinz Buchegger welchen controller würdest du mir dafür empfehlen > ? Such dir bei den Megas AVR Typen einen aus, der 2 USART hat > sehe ich es jetzt richtig dass ich den pc UART anch meinen vorstellungen > initialisierten muss ( z.b 1 startbit,1 stoppbit,8 datenbits) und dann > das zu sendene protokoll implementieren muss ( z.b. sende erst die > kanalnummer danch den wert). und dazu den uC einfach als empfanger > anpassen . richtig ? Ganz genau.
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.