Steuerung externer Geräte (eigenbau)

[Fussel9]

Was ich mich schon seit langem Frage: Wie werden eigentlich externe Geräte von Programmen angesprochen, sei es ein Plotter dessen Motoren bewegt werden, ein LCD-Display dessen Segmente erleuchten oder einfach nur eine LED-Leiste bei der man die einzelnen Lampen an- und ausschalten könnte...
Nun habe ich mich vergangene Tage mit jemandem unterhalten der in einem solchen Bereich arbeitet und der hat mir irgendwas von Assembler erzählt und mir jede Menge begriffe um die Ohren geschleudert die ich natürlich nicht kannte ;D .
Nu hab ich mich mal schlau gemacht (Wikipedia) und Assembler scheint eine Sprache zu sein die für solche Dinge gedacht ist, aber wie es aussieht greift die Sprache immernoch auf ein Betriebssystem oder zumindest auf das DOS zurück (Falls die Architektur mit DOS arbeitet, sonst eben auf Entsprechendes):

Code:

Hello World in Assemblersprache (NASM für MS-DOS) [Bearbeiten]

ORG 100h ; Startoffset auf 100h setzen (Startpunkt für COM-Programme)
 
mov ax, cs ; Wert des Codesegmentregisters in Register ax übertragen
mov ds, ax ; Datensegment auf Wert von ax setzen
 
mov ah, 09h ; DOS-Funktion zum Schreiben von Text
mov dx, Meldung ; Adresse des Textes
int 21h ; DOS-Funktion ausführen
 
mov ax, 4C00h ; DOS-Funktion um das Programm zu beenden
int 21h
 
Meldung: db "Hello World" ; Unser Text
         db "$"             ; Markiert das Ende der Zeichenkette

ich gehe mal davon aus das man daher eine platine braucht die einen prozessor oder sowas hat die diese befehle oder parameter auflösen kann...

Ich geh jetzt mal wirklich vom einfachsten Beispiel aus:
Ich habe 5 LED's die ich über ein Programm steuern möchte.
Kann mir jemand erklären wie sowas funktionieren würde,
welche Bauteile ich benötige und
wie der Computer signale von externen Sensoren empfangen kann?
(zu letzterem: z.B. ein Bewegungssensor um die LED's zu steuern)

[Bernhard Geyer]

Zitat von Fussel9:

... aber wie es aussieht greift die Sprache immernoch auf ein Betriebssystem oder zumindest auf das DOS zurück (Falls die Architektur mit DOS arbeitet, sonst eben auf Entsprechendes)

Windows ME war das letzte Windows das einen DOS-Kern hatte. Ab NT/2000 wirst du nicht mehr direkt ohne einen Treiber zurecht kommen.

Für spielereien in diese Umfeld bieten Conrad&Co. fertige Platinen mit denen man relativ einfach PC-SW schreiben kann um selbst zusammengestellt Elektronik steuern kann.

[Fussel9]

Hey, ja sowas wäre natürlich super,
wonach genau muss man den da so suchen um nicht in der Flut von angebotenen Platinen unterzugehen.

Sind bei sowas Anleitungen dabei oder gibt es empfehlenswerte Seiten im Netz?

Zitat:

...fertige Platinen mit denen man relativ einfach PC-SW schreiben kann...

was genau ist den PC-SW ... da findet die Wikipedia auch nix...

[himitsu]

Innerhalb des PCs isses egal, da man in der Regel fast ganicht mehr direkt mit der externen Hardware "redet".
Oftmals werden Schnittstellen-DLLs und Treiber angesprochen und das geht mit jeder Sprache (C++ C# Delphi BASM ......).

Wie in der externen Hardware gearbeitet wird, hängt von dieser ab und ob da z.B. ein Mikrocontroller drin steckt.

Manchmal schaltet man extern auch nochmal eine µC dazwischen, welcher vom PC die Befehle bekommt und die eigentlich Hardware anspricht.


Diese µC kann man mit vielem befüllen.

Also die Programme innerhalb des PC-Programmierprogramms können Vieles sein.
Von ASM, über C++, sogar Basic, Pascal und Anderes existert ... je nach µC oder ob es sogar eine größere CPU, ala x86-er Architektur.

[jfheins]

Das Zauberwort heißt Microcontroller

Wenn es nicht nur ein paar LED's sind, sondern etwas mehr Logik ausgelegert werden soll, kannst du einen Mikrocontroller programmieren der das übernimmt. Den programmiert man üblicherweise mit C (oder Assembler) und kann mit einem Computer über RS232 kommunizieren.

[Fussel9]

Zitat von himitsu:

Innerhalb des PCs isses egal, da man in der Regel fast ganicht mehr direkt mit der externen Hardware "redet".
Oftmals werden Schnittstellen-DLLs und Treiber angesprochen und das geht mit jeder Sprache (C++ C# Delphi BASM ......).

Nur wenn ich selbst ein Element baue, dann kann kein Treiber dafür existieren oder?

Zitat von jfheins:

Das Zauberwort heißt Microcontroller

Wenn ich mir jetzt den kaufen würde (Link) was müsste ich den dann damit machen?

Ich hab ja keine Ahnung wie sowas funktioniert...
Sagen wir mal, um die Logik komplexer zu machen, Ich bau mir jetzt einen Bilderrahmen voll mit LED's und mit einem Lichtsensor ja nach Helligkeit soll er andere Bilder zeigen.

wie muss der Mikrocontroller verbaut werden, was muss man haben um den controller mit einem rechner zu beschreiben ect ect

[ulilüding]

HI Fussel9,
eine Möglichkeit ist, Deine LEDs in Spalten und Zeilen aufzuteilen und dann über PWM in der Helligkeit anzusteuern. Das kann ein Mikrocontroller sehr leicht, wenn er genug Ports hat. Über eine Schnittstelle (z.B. RS-232, Danke jfheins) kannst Du dem Mikrocontroller sagen, welche LED wie hell leuchten soll. Die Programmierung dazu = Daten berechnen und über COMx ausgeben ist Pipikram. Die Schwieriglkeiten liegen im Timing des Mikrocontrollers. Der ist mit einer akzeptablen Bildfolge und Taktrate für das PWM schnell am Ende, wenn Du viele Spalten und Zeilen hast. Da wird dann mehr Elektronik nötig, z.B. Latches für col oder row. Wieviel LEDs und wie schnell hast Du denn so gedacht?
LG Uli

[himitsu]

Zitat:

Nur wenn ich selbst ein Element baue, dann kann kein Treiber dafür existieren oder?

Wieso?

Also, RS232 (serieller Anschluß) unterstützen viele µC .. dann braucht man nur noch ein Kabel.

USB und Co. kann man heutzutage auch relativ leicht nehmen.

PS: Es gibt dann PC-intern Serial-zuUSB-Brücken, welches praktisch Treiber sind, die Daten über den USB-Anschluß auf einen seriellen Port weiterleiten.

User es gibt DLLs/Treiber, welche die Kommunikation über USB und einen externen IC zu einem µC bereitstellen.

Man könnte auch über PCI, FireWire, WiFi, Bluetooth oder sonstwie gehn.

Was nun geeignet ist, das hängt davon ab, was für Möglichkeiten zur Verfügung stehen, wie der Geldbeutel aussieht, wie schnell die Übertragung sein muß und über welche Entfernung es gehn soll.
Außerdem ist wichtig was und wie es gesteuert werden soll.

[Fussel9]

@Uli: Puh... das war nur nen simpless beispiel wo man einen eingabewert für die ausgabe verarbeiten müsste
wenn ich sowas in der richtung mal wirklich bauen würde dann liefe es eher auf ne doppelhelix oder nen würfel raus
also bei der doppelhelix zwei stränge mit ka 4 zwischen Strängen (72 LED's
oder bei nem würfel vielleicht so keine Ahnung 12 streifen fürs grundgerüsst und 16 zwischen streifen die ein gitter über und durch das gerüsst ziehen ( so 8 Led's pro Strang---224 LED's)

und dann ginge es bei der Helix eher darum das das Teil Bewegungen darstellen kann wie einen Aufwärtsstrom bis zu einer On/Off- Geschwindigkeit von 1/6 bis 1/8 Sekunde

Bei dem Würfel ging es dan eher um die Farbspiele oder langsame Bewegungen aber eben auch die Möglichkeit jedes einzelne LED steuern zu können. Ich denke du kannst dir vorstellen wie so ein Teil aussehen würde... (ja ich weiß das es die Dinger fertig zu kaufen gibt, aber das würde ja keinen Spaß machen)

PS: @himitsu: Wäre schon cool wenn ein programm auf meinem Rechner dem Qube die Befehle über Funk oder Bluetooth oder wie auch immer senden würde aber mit nem Mikrocontroller würde das teil selbstständig arbeiten (hab ich jetz zumindest so verstanden)

[ulilüding]

Nehmen wir als Beispiel einen PIC im 40-pol-Gehäuse. Der kann problemlos über 2 Ports 8x8 = 64 LEDs steuern. Weitere pins werden zwar für serialCom und Deinen Lichtsensor (?? AD-Wandler mit Fotozelle über I2C, SSI oder sowas) gebraucht, lassen aber den Rest auf 72 LEDs wohl zu. Die Kommunikation ist über einen virtualComPort an USB einfach zu gestalten. Dein Programm sendet an den PIC die Helligkeitswerte für die LEDs und bekommt als Antwort den Meßwert des Lichtsensors. Da Du an 8 Bilder pro Sekunde denkst ist das vom Timing her recht unkritisch. Wie die Werte im PC-Programm verknüpft werden sollte keine Schwierigkeit darstellen. Für den Zeitablauf rate ich aber vom mmTimer (oder gar der Timer-Komponente) ab, das läuft nicht rund. Am besten ein eigener thread mit Hardware-Zeitmessung über QueryPerformanceFrequency und ..Counter.
Leider wirst Du Dich ordentlich in die microcontroller-Programmierung reinknien müssen. Da gibt es zwei Philosophien. Hochsprache: leicht zu schreiben und zu debuggen, der Kerl (compiler) macht aber gerne auch schon mal das, was er will = schlechte timing-Kontrolle. Maschinencode im Texteditor (assembler): ggf. nicht portierbar, debuggen am ehesten mit Oszi per pin und überhaupt recht hardware-nah, nicht jedermanns Sache. Vielleicht findest Du speziell für diese Aufgabe ja jemanden, die molzitec GmbH in Münster z.B. (www.molzitec.de) macht sowas sehr professionell. Ansonsten Handbücher wälzen und in kleinen Schritten viel ausprobieren. Viel Erfolg
LG Uli