Druckbare Version
Hi
einmal kurz eine Frage was benötige ich um über den PC was an den µC zu schicken und 2 Was benötige ich um was an den PC zu schicken das er es ausweten kann.
Das mit µC zu PC weiß ich das steht ja im Wiki gut beschrieben aber das andere weiß ich nicht.
Geht beides mit Delphi oder ?
MFG
Zwischen uC und PC muss eine Pegelanpassung. Da wird meistens ein max232 genommen, es gibt aber noch viel andere Möglichkeiten, die oft aber kein 100% Normkonformes Signal liefern. Fast alle PCs kommen aber damit klar, denn die Seriellen Mäuse haben das auch nicht anders gemacht.
ja µC zu PC weiß ich ja und das man das ohne Probleme mit Delphi auswerten kanna ber meine Frage ist wie ich es umgekehrt mache vom PC zum µC
Das geht mit fast jeder Programmiersprache. Aber da musst du schon in der Hilfe von deiner Programmier-Software oder im Internet (Foren für Leute die in dieser Sprache Programme entwickeln ect.) schauen, wie da die Befehle lauten.
Normalerweise muss man halt im Programm eine Serielle Schnittstelle öffnen, die Verbindungseinstellungen konfigurieren (Baudrate, Parität, Stoppbits ect.) und mit dem COM-Port vom PC verbinden. Dann kann man mit Befehlen wie "SerialPort.Write()" oder ähnlich, einen String oder irgendwelche Zahlen (Integer, Bytes...) senden.
Aber das ist wirklich individuell für jede Sprache und sogar Sprach-Version.
Im uC holt man sich dann (in BASCOM) z.B. mit einer Schleife über den "Inkey()"-Befehl die empfangenen Bytes rein und setzt sie wieder zusammen, falls es mehrere Bytes, z.B. ein String oder Integer sind die man sendet.
in delphi speziell weis ich es nicht , aber da kannst du auch einfach eine send befehl geben und dann im uC mit waitkey() lesen
brauchst übrigens nur den GND RXD und TXD die sosntigen pins kannst alle weglassen...
ne weitere frage wie lang darf das Kabel maximal sein ?
ne andere Frage die aber nichts damit zu tun hat das kabel für den Power Button des PC's wie lang darf das sein ? :D
naja desto länger desto shcelchter.. also vor dem pegelwandler kann es ruhig 2-3 meter sein.. das funktioneirt dann ganz gut.. nach dem pegelwandelr sollte es möglicsht kurz sien.. max 0,5 meter, also am besten den pegelwandler direkt an den uC und das kabel zwichen pc und max232 lang machen..
das an aus kabel kannst solang machen wie de willst.. das is völlig egal..
habe selber nochma gegoogelt bei der baud rate von 9600 darfs maximal 150 Meter oder so lang sein das reicht für Mein Vorhaben vollkommen xD bei 19k oder so nur 15 m wäre auch noch vollkommen ausreichend für mich aber thx
hui ok, dass es so lang geht wusste ich nicht.. :) dann musst du es aber schirmen.. hatte schon bei 3 metern probleme wenns nicht geschirmt war,.
Falls sie vill noch ein andere Mal Brauch :DCode:Baud M
19200 15
9600 150
4800 300
2400 900
also wenns einfach werden soll versuch dich lieber mit ner bibliothek/modul/package für die serielle schnittstelle, wenn ich die initialisierung in C ansehe könnte mir mein frühstück hochkommen (tschuldigung >_< zu viel information)
oder nimm gleich C#, damit gings am schnellsten bei mir, aber tricky wegen der thread-problematik, musste mich erstmal in die feinheiten von C# einfuchsen
im µC lesen geht auch interruptgesteuert, ich werf hier mal die begriffe ringpuffer, stack und "cue" (verdammt wie buchstabiert man das nochmal?) in den raum, so hab ich mal ne asynchrone kommunikation PC <-> µC gemacht
Darüber bin ich auch gestolpert - allerdings mit VB (nutzt ja auch das .NET 2.0-Framework).Zitat:
nimm gleich C#, damit gings am schnellsten bei mir, aber tricky wegen der thread-problematik
Solange man nur vom PC sendet ist es kein Problem, aber wenn man auch von der Seriellen Schnittstelle liest und mit den eingehenden Daten direkt irgendweche Änderungen z.B. an der Grafischen Oberfläche anstößt, meckert das Programm wegen den Sicherheitsrestriktionen vom .NET-Framework. Die Serielle Schnittstelle ist leider nicht "Thread-Sicher".
Ich habs gelöst, indem ich alle Änderungen die durch eingelesene Werte am GUI verursacht werden an andere Methoden deligiere und sie erst dort vornehme.
War aber ein ganz schönes "Rumgefrickel", weil ich erst wärend dem Programmieren auf diese Problematik gestoßen bin.
*klopft cairol auf die schulter* das kommt raus wenn man java mit c mischt ... früher war das alles einfacher, da hat man über c geflucht weils fizzelig iss und über java weils kryptisch oder unflexibel iss, nu hat man ne flexible sprache die kryptisch UND fizzelich iss (spass beiseite die vorteile überwiegen aber die probleme sind nich von der hand zu weisen)