Hi,

Zitat : DonComi hat am  2 Apr 2008 16:07 geschrieben :

Hallo? Wofür mache ich mir eigentlich die Arbeit?

keine Angst bin noch da, ich habe mir die Empfehlung zu herzen genommen und schraube mir noch einen alten 586 400 MHz PC mit Parallelport zum testen zusammen. Wenn der die "Hufe" reist ist es ja nicht so schlimm.

Gibt es auch ein feritgen Bausatz oder kaufmodul für die LPT mit Optokoppler oder und auch Relais dran?

Gruß.

Moin Moin,

Dann ist ja alles klar .

-----
Um dir mal die Angst zu nehmen: Wenn du mit Transistoren arbeitest, und entsprechende Vorwiderstände nutzt, dann kannst du praktisch nichts zerstören.
Da musst du also keine Panik haben. Nur, da du eine weitere Spannungsversorgung haben musst, solltest du vorsichtig sein, diese nicht verpolt oder anders falsch anzuschließen. Aber selbst dann heißt das noch nicht, dass der Port / einzelne Pins davon elektrisch Schaden nehmen.

Es gibt natürlich auch Bausätze, aber für soetwas triviales braucht man das meiner Meinung nach nicht.

Wenn ich da an meine allerersten Experimente denke... 9V-Blockbatterie, Holzbrett mit verzinnten Nägelköpfen und dicker Draht... Da kannst du also kaum was kaputtmachen, wenn du auch nur ein wenig sauber arbeitest

Zum Rechner:
Ich kann dir Arch linux empfehlen - läuft bei mir mittlerweile auch seit einigen Monaten und der Kernel ist innerhalb weniger Minuten/einige 10 Minuten installiert samt Minimalsystem.
Faktisch habe ich da nichtmal X drauf, aber laufen tut die Schüssel einwandfrei.

Darauf lief mein Programm auch, auf allen anderen auch ... .

_________________

Hi,

eigentlich möche ich das ganze dann auf einem embeddet Linux System laufen lassen. Wenns geht mit Optokopplern galvaisch getrennt.

Einmal um einzelne Verbraucher ein / auszuschalten.
Dann für Zustandsmesung, also ist Tür zu oder auf.

Dann Schrittmotorenansteuerung. Wobei ich jetzt nicht weiß ob das mit wenigen MHz geht.

Dann würde ich gern wissen ob auch USB zu 25 Pin LPT Adaoter auch gehen?

Gruß.

Dafür würde ich nicht den Druckerport nutzen, sondern andere Wege beschreiten.
Was ist denn das für eine Umgebung, das könnte man mit Embedded Linux dann auch anders machen.
Du könntest z.b. diverse Ein-/Azusgabebausteine mit an den Systembus hängen und die im Speicherbereich mappen.
Je nach Komplexität musst du aber den Kernel um einen eigenen Treiber erweitern, damit du darauf auch Zugriff hast.

Galvanisch sowas zu trennen ist fast Pflicht.

Du kannst aber genauso einen Mikorcontroller an den Computer anschließen, der ja nach Ausstattung sehr, sehr viel kontrollieren kann.
Den schließt du dann entweder per USB, oder per LPT (wenn vorhanden) an; oder wie gesagt gleich an den Systembus, was ja bei so hardwarenahen Sachen am naheliegendsten ist. Ein kleiner Daemon kann dann z.b. Ereignisse auswerten und entsprechende Sachen verursachen.
Oder du implementierst das als Gerätetreiber, dann übernimmt das alles der Kernel.


Ich habe hier z.b. einen Dämon in C geschrieben, der sich an Init vererbt, also selbstständig im Speicher bleibt und arbeitet. Der überwacht den Druckerport, mit dem kann ich jetzt bestimmte Sachen im System machen (aktuell brauch ich nur einen von diesen Sensorschaltern zu berühen, und es öffnet sich mein Fernsehprogramm (, was ich zwar nie brauche, aber nett ist es ).

Unter Windows würde man das als Dienst oder Service bezeichnen.
zu deinem Adapter: das kann ich dir nicht sagen! Grundsätzlich kommt es drauf an, ob du den Gerätetreiber dafür hast und ob das Sinn ergibt, ich glaube nicht, dass die so eine gute Performance haben, wie ein richtiger LPT. Und so ein embedded System läuft auch nur dann wirklich perfekt, wenn die Software gut läuft, und keine Flaschenhälse entstehen. Da aber über die Zeit gemittelt fast keine Daten tranferiert werden, sollte das ohne weiteres nöglich sein. Nur: Treiber muss vorhanden sein. Weiter wäre zu klären, ob der Treiber ein paar 1000 mal in der Sekunde die Statusports abfragt. Bei PCs der heutigen Generation kein Performanceproblem. Bei eingebetteten System kanns dir die Auslastung hochtreiben. Dafür sind die ja so zu gestalten, dass sie sehr effizient sind. Wenn der Treiber dies also tut, und davon ist leider auszugehen, würde ich das nicht machen.
Ich pers. würde es nicht machen. Entwickelst du die Hardware um das Linux selbst? wenn ja, dann kann man die andere Steuerung da gleich implementieren - wenn nicht, nimm den Adapter oder RS232.

_________________


[ Diese Nachricht wurde geändert von: DonComi am  5 Apr 2008 20:26 ]

[ Diese Nachricht wurde geändert von: DonComi am  5 Apr 2008 20:28 ]

Hi,

Zitat : DonComi hat am  5 Apr 2008 20:21 geschrieben :

Ich habe hier z.b. einen Dämon in C geschrieben, der sich an Init vererbt, also selbstständig im Speicher bleibt und arbeitet. Der überwacht den Druckerport, mit dem kann ich jetzt bestimmte Sachen im System machen (aktuell brauch ich nur einen von diesen Sensorschaltern zu berühen, und es öffnet sich mein Fernsehprogramm (, was ich zwar nie brauche, aber nett ist es ).

hast du dein Projekt irgendwo im www beschrieben mit Fotos usw? Klingt sehr interessant.

Gruß.

Ich habe nicht das Bedürfnis, meine Projekte sorgfältig zu dokumentieren .

Das Interface ansich hatte ich ja bereits fotographiert, ist hier irgendwo im Thread.
Der Dämon ist auch nicht sonderlich schwierig.
Es gibt da einige Möglichkeiten, zunächst erstmal die einfachste mit der Shell:

daemon &

Bedeutet: Das Programm deamon wird gestartet und die Kontrolle wird der Shell übergeben. Der Prozess läuft dennoch weiter! Wenn das Programm Ausgaben auf die Standardausgabe macht, sieht man sie, obwohl man keine Kontroller mehr über das Programm hat.

Zweite Möglichkeit:

daemon & exit

Bedeutet: Das Programm wird gestartet, die Shell beendet. Damit wird der Prozess als Kindprozess an init vererbt. Sollte init irgendwo Daten hinschreiben, und zwar nicht Fehlermeldungen, dann erbt das Programm diesen Deskriptor, und seine Ausgaben werden ebenfalls dahin umgeleitet.

Die Lösung, das Programm sich selbst zu vererben und den Vaterprozess zu killen, geht in etwa so: (fork)

int main(das übliche)
{

int i=fork(); /* Kopie vom Programm erstellen, dabei wird ein neuer Prozess erzeugt, Daten werden übernommen */

if (i>0){


printf("So, ich, der Papaprozess, kill mich\n");
return 0;


}
else if(i==0){ /* Kindprozess */


printf("Ich bin der Kindprozess\nMein Vaterprozess ist tot, daher gehöre ich jetzt initn");
...


}
else if(i<0){


fprintf("Konnte keine Kopie von mir erzeugen!\n");
return 1:


};
return 0;

};


Das Programm macht natürlich mehr, das ist hier nur der Daemonkram.
Das ist aber eben sehr sinnvoll. Dabei schläft der Prozess eh die meiste Zeit, braucht also neben Speicher keine Rechenzeit. Noch effizienter wäre es, den Interrupt des LPTs zu nutzen, da erhält dann der schlafende Dämon einen System Call, dass sich was am LPT tut. Das sollte man auf jeden Fall in embedded Systems machen, da die Ressourcen dort knapp sein können.

_________________


[ Diese Nachricht wurde ge&auml;ndert von: DonComi am &nbsp;5 Apr 2008 21:47 ]

[ Diese Nachricht wurde geändert von: DonComi am  5 Apr 2008 21:49 ]