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.
>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.
>>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.
