Hi Leute, ich habe eine Frage bezüglich älterer Computersysteme. Ich interessiere mich gerade sehr dafür, mal die rudimentäreren Rechnersysteme kennenzulernen und alles auf das wesentliche runterzubrechen. (Macht auch einfach Spaß, in diesen Retrothemen zu wühlen) Nun meine Frage: Ich möchte elektronische Schaltungen mit einem einfachen Computersystem steuern. Ich dachte an DOS. Da ich gerade C lerne und erstmal bei einer Sprache bleiben wollte, habe ich diesen C Compiler für DOS gefunden: "Turbo C" http://edn.embarcadero.com/article/20841 Kann ich mit dieser kombination relativ einfach irgendwie über seriellen, oder Druckerport mit einem Mikrocontroller kommunizieren? Damit ihr versteht was ich will: Ich möchte einfach ein super einfaches Computersystem, auf dem ich so einfach wie möglich mit einer Software einen Mikrocontroller steuern kann. Gut Strom! Oder wie auch immer man andere Bastler grüßt ^^ haha Ich war hier übrigens früher schon, hab aber mein Account vergessen..
Adrian L. schrieb: > Kann ich mit dieser kombination > relativ einfach irgendwie über seriellen, oder Druckerport mit einem > Mikrocontroller kommunizieren? Im Prinzip ja. Allerdings ist die Unterstützung für die Ansteuerung der seriellen Schnittstelle unter DOS sehr rudimentär, der Compiler selbst kennt so etwas gar nicht, und Du bist entweder auf die Nutzung der BIOS-Routinen angewiesen, die aufgrund ihrer primitiven Struktur nicht viel Freiraum lassen, oder aber Du musst einen "Treiber" selbst bauen bzw. einen irgendwo finden. Insofern ist ein DOS-Rechner kein "super-einfaches" System.
Okay, ich bin im Moment für alle Systeme offen, was könnte man denn als alternative empfehlen? (Um das ganze nicht zusehr einzuschränken müsste es auch nicht unbedingt C sein.. Basic wäre natürlich auch schön, weil es schnell zu erlernen ist)
Adrian L. schrieb: > Okay, ich bin im Moment für alle Systeme offen, was könnte man denn als > alternative empfehlen? (Um das ganze nicht zusehr einzuschränken müsste > es auch nicht unbedingt C sein.. Basic wäre natürlich auch schön, weil > es schnell zu erlernen ist) Linux... Vom Elektor-Verlag gibt es u.a. ein Englisches Buch, in dem über ein DSL (damn small linux) eine Hausautomation o.dergl. realisiert wird. Unter Linux darf man auch direkt auf die Ports zugreifen.
STK500-Besitzer schrieb: > Unter Linux darf man auch direkt auf die Ports zugreifen. Was, wenn es um die serielle Schnittstelle geht, absolut nicht zu empfehlen und im übrigen auch sinnlos ist.
Hi Adrian, meiner Meinung nach brauchst du dich nicht mit einem antiken Compiler unter einem antiken OS herumplagen, es sei denn du willst genau wissen was der PC da treibt. Du kannst mit einem modernen Compiler (z.B. die freie Visual Studio Express Edition) ganz einfach Konsolenprogramme (laufen im "DOS-Fenster") schreiben und über die die serielle Schnittstelle ansteuern. Von der parallelen Schnittstelle würde ich die Finger lassen. Fürs Erste brauchst du zum Testen des Programms auch keinen Mikrocontroller. Du kannst z.B. am PC zwei serielle Ports über ein Nullmodemkabel verbinden und mit dir selber sprechen (z.B. dein Programm auf COM1 und ein Terminal auf COM2). Das geht auch rein virtuell mit com0com, was bei Rechnern mit weniger als 2 COM Ports ganz praktisch ist. Wenn das funktioniert, kann man das dann einfach auf echte HW umstellen. Gruß, Reinhard
Ok, das klingt interessant. Wo finde ich jetzt Resourcen zum Ansprechen von COM Ports unter C ?
Mit Google. ;-) Das ist ein Standardproblem. Das Web geht förmlich über mit Informationen zu dem Thema. https://www.google.com/search?q=visual+c%2B%2B+serial+port Edit: Ignoriere aber am besten alle Ergebnisse in denen .NET vorkommt. Das ist dann kein reines C/C++ mehr. Besser wäre: https://www.google.com/search?q=visual+c%2B%2B+Win32+serial+port
OK danke :) Ich werde mich trotzdem paralel ein bisschen mit DOS beschäftigen, einfach aus Interesse, weil ich die alten Computer toll finde. Kannst du mir vielleicht etwas genauer erläutern, was unter DOS so rudimentär, bzw. eingeschränkt hinsichtlich der Seriellen Schnitstelle ist?
Rufus hat das oben schon angedeutet. Man muss unter DOS die Hardware mehr oder weniger "direkt" ansteuern. Das setzt dann auch voraus dass man weiß welche Art von Schnittstelle verbaut ist, meistens eine die zu einem bestimmten Standard kompatibel ist, z.B. zum 8250 oder 16550. Bei einer exotischen Schnittstelle muss man aber sein Programm entsprechend anpassen. Unter Windows ist das nicht mehr möglich. Das Betriebssystem erlaubt einem Programm gar nicht mehr den direkten Zugriff auf die Hardware. Dafür gibt es Funktionen die den Zugriff erlauben. Hinter diesen Funktionen verstecken sich dann die ganzen hardwarespezifischen Details, Zugriffskontrolle etc. Wenn du direkt unter DOS arbeiten willst ist das sicher lehrreich und interessant. In dem Fall spricht auch gar nichts dagegen den "steinigeren" Weg zu wählen.
OK, danke für die Erklärung. Da ich Programmier Anfänger bin sollte ich mich damit vielleicht nicht gleich übernehmen, auch wenn es tatsächlich sehr interessant klingt.
Serielle unter DOS kennt nur Hardware Handshake daher must du die Hardware selbst ansprechen. Druckerportfunktionen kennen mehr oder weniger nur Drucker. Das schöne an DOS ist das man einfach die gesamte Hardware ansprechen kann ohne irgendwelche Verenkungen.
skua schrieb: > Das schöne an DOS ist das man einfach die gesamte Hardware ansprechen > kann ohne irgendwelche Verenkungen. Und das unschöne ist, daß es keine Treiber gibt, die das für einen erledigen.
Etweder habe ich ein schlechtest Gedächtniss oder ihr? Klar kann man die Hardware direkt ansprechen oder das braucht man im normal fall nicht. Es gibt BIOS-routinen für den Zugriff auf den COM-Port. Dos konnte ja auch schon mit "type autoexec.bat > COM1" umgehen. http://www.i8086.de/dos-bios-interrupts/dos-bios-interrupts.html
An dieser Stelle möchte ich doch noch einmal ein schon etwas älteres Buch empfehlen: PC-Schnittstellen angewandt von Burkhard Kainka. Leicht verständlich und praxisorientiert, richtet es sich vor allem an Einsteiger, aber die kompakte Darstellung aller wichtigen Grundlagen an Beispielen war mir persönlich sogar in der Firma eine Hilfe, wenn auch vor etlichen Jahren. Ist allerdings Pascal / Basic - orientiert. Man kann entsprechende Portzugriffe unter DOS allerdings auch in C ausführen.
Schau mal hier rein. http://www.beyondlogic.org/serial/serial1.htm Howrdwarebeschreibung, Register, ein DOS C-Programm .....
Oh weh -> "Howrdwarebeschreibung" ich meinte natürlich "Hardwarebeschreibung" sorry.
skua schrieb: > Serielle unter DOS kennt nur Hardware Handshake daher must du die > Hardware selbst ansprechen. Wenn Du damit die BIOS-Routinen meinst, ja. Mit ein paar Lötbrücken im Stecker ist das aber kein Problem, anders als die anderen Einschränkungen. Peter II schrieb: > Es gibt BIOS-routinen für den Zugriff auf den COM-Port. Das habe ich auch nicht abgestritten. Nur können die nicht viel, da sie die Schnittstelle nicht interruptgesteuert ansprechen. Und so ist zwar das Senden mit hohen Baudraten möglich, das Empfangen aber geht "dank" Polling recht bald schief. Dazu kommt, daß die BIOS-Routinen nur mit Schnittstellen nutzbar sind, die an den Standard-I/O-Adressen liegen, womit PCI(e)-Karten und natürlich USB-Adapter gleich völlig ausfallen. Aus all diesen Gründen ist es deutlich ratsamer, serielle Schnittstellen mit einem Betriebssytem anzusprechen, das mit Devicetreibern arbeitet, ob das nun ein ernstgemeintes Windows oder Linux ist, ist dafür ziemlich egal.
Um als Threadersteller nochmal auf die Einfachheit der eigentlichen Frage zurückzukommen, sprich: Meine Ansprüche isnd wirklich niedrig. Ich möchte zwar mehr als nur And und Aus schalten über den COM Port, aber es reicht mir, wenn ich mehrere Werte an einen Mikrocontroller ausgeben könnte... zB LED 1 leuchtet Hell, LED 2 leuchtet mittel, LED 3 leuchtet schwach. In der nächsten Sekunde ist es wieder anders... Klar muss ich jetzt die ganzen Links erstmal durchwühlen, trotzdem wäre ich für anfängergerechte Tips offen, wenn sich jemand die Mühe machen will, mich auf den richtigen Pfad zu bringen ;)
Rufus Τ. Firefly schrieb: > Das habe ich auch nicht abgestritten. Nur können die nicht viel, da sie > die Schnittstelle nicht interruptgesteuert ansprechen. Und so ist zwar > das Senden mit hohen Baudraten möglich, das Empfangen aber geht "dank" > Polling recht bald schief. das liegt dann aber fast nur am Programmierer, bei DOS ist ja gerade der Vorteil das einen niemand in die Quere kommt. Wenn das Pogramm also nicht gerade extrem komplizierte quardratische gleichungen lösen muss, dann sollte da nichts schief gehen.
Peter II schrieb: > das liegt dann aber fast nur am Programmierer, Nicht bei Benutzung der BIOS-Routinen. Die sind, wie sie sind, und das Konzept ist lausig.
Rufus Τ. Firefly schrieb: > Nicht bei Benutzung der BIOS-Routinen. Die sind, wie sie sind, und das > Konzept ist lausig. ein guter Programmier kommt auch mit den lausig umgebungen zurecht. Es gabt genug software die ohne Probleme per COM-Port daten übertragen konnten. Ich glaube z.b. nicht das der NortonCommander eigene "treiber" für die hardware dabei hatte.
Adrian L. schrieb: > Ich werde mich trotzdem paralel ein bisschen mit DOS beschäftigen, > einfach aus Interesse, weil ich die alten Computer toll finde. Es gibt tolle alte Computer, aber auf keinem davon laeuft (MS-)DOS. Das ist so als wuerde man alte Autos toll finden und sich deswegen einen Audi 80 zulegen.
Peter II schrieb: > Ich glaube z.b. nicht das der NortonCommander eigene "treiber" > für die hardware dabei hatte. Aber sicher hatte der das, wie jedes andere erntgemeinte Programm auch, das unter DOS mit seriellen Schnittstellen herummachte. Der "Treiber" war kein separater Programmbestandteil, sondern bestand aus einer ISR, die die betreffenden Hardware-Interrupts bediente, sowie einer Handvoll von Routinen, die direkt auf die I/O-Adressen der 8250/16550 zugriffen. Mit reiner Nutzung der BIOS-Routinen war ein Empfang mit Datenraten jenseits der 9600 Baud praktisch ausgeschlossen, mit interruptgesteuerter und nicht zu ungeschickter Programmierung war auch auf lahmen Kisten das Maximum (115200 Baud) möglich. Das Problem bei diesem Konzept ist halt, daß jedes Programm die verwendeten I/O-Adressen und Hardwareinterrupts kennen muss, bei den ersten beiden Schnittstellen waren die auch noch klar definiert, aber bei weiteren dauerte es geraume Zeit, bis sich ein sinnvoller Standard etablierte. Bis dahin hatten die Programme ein paar vordefinierte Werte, die dem jeweiligen Programmierer halt am besten gefielen; wenn man als Anwender Glück hatte, entsprach einer dieser Werte der eingesetzten Hardware.
@ xXx Was sind denn so die alten Compiter deiner Wahl? Die es Spaß macht zu programmieren.. Ich fand zB dass ein Apple II (Mit dem DOS von Apple) sehr schön aussieht.
Peter II schrieb: > Es gibt BIOS-routinen für den Zugriff auf den COM-Port. Dos konnte ja > auch schon mit "type autoexec.bat > COM1" umgehen. Nur ist das Empfangen nicht per Interrupt gepuffert. Und wie willst du beim Senden einen Timeout Implementieren wenn der Empfänger per Handshake busy signalisiert ?
Peter II schrieb: > das liegt dann aber fast nur am Programmierer, bei DOS ist ja gerade der > Vorteil das einen niemand in die Quere kommt. Wenn das Pogramm also > nicht gerade extrem komplizierte quardratische gleichungen lösen muss, > dann sollte da nichts schief gehen Was ist mit schreiben auf Diskette oder Platte ? In der Zeit gehen im Zweifelsfall Zeichen verloren.
> Was sind denn so die alten Compiter deiner Wahl? Die es Spaß macht zu > programmieren.. > > Ich fand zB dass ein Apple II (Mit dem DOS von Apple) sehr schön > aussieht. da Du Dich ja für Retrocomputer und serielle Ansteuerung interessiert - hier ist ein nettes Bastelprojekt für Atari XL (Lauflichtsteuerung, "juego de luces" unter Projekte), fand ich irgendwie ganz nett :) http://www.atariware.cl/
Adrian L. schrieb: > Um als Threadersteller nochmal auf die Einfachheit der eigentlichen > Frage zurückzukommen, sprich: Meine Ansprüche isnd wirklich niedrig. Ich > möchte zwar mehr als nur And und Aus schalten über den COM Port, aber es > reicht mir, wenn ich mehrere Werte an einen Mikrocontroller ausgeben > könnte... soweit so einfach, nimm einen Com Port, beschäftige dich mit den Registern und dem verwendeten Baustein (16550) und leg los. Du mußt die Adresse wissen wo der Baustein steckt und welche Register welche Leitungen unter welchen Bedingungen schalten. > > zB LED 1 leuchtet Hell, LED 2 leuchtet mittel, LED 3 leuchtet schwach. Das ist dann aber kein einfaches digitales schalten mehr. Belass es bei ein/aus, sonst brauchst du zusätzliche externe Hardware zur Helligkeitssteuerung. > In der nächsten Sekunde ist es wieder anders... Klar muss ich jetzt die > ganzen Links erstmal durchwühlen, trotzdem wäre ich für anfängergerechte > Tips offen, wenn sich jemand die Mühe machen will, mich auf den > richtigen Pfad zu bringen ;) Hoffe das ist verständlich. Es gibt einen Baustein (ein Chip), der hat Softwareregister, dort setzt du einzelne bits per Software (C z.B.), diese bits steuern "Verstärker", Die Spannung kannst du dann an den Steckern messen.
Danke! Ich hatte auch mittlerweile das hier gefunden: http://www.franksteinberg.de/progss.htm http://www.o-bizz.de/qbtuts/com-port/index.htm Ist zwar ein bisschen kompliziert für Anfänger, aber man kapierts nach einer Weile.
Wenns nur ums Ein- und Ausschalten geht, dann nimm doch die parallele
Schnittstelle.
Die liegt standardmäßig auf 0x378.
Dann kannst Du mit
portoutb(word port, byte data);
also portoutb(0x378, 0x{was du willst}) die Datenleitungen schalten und
dort dranhängen, was du willst.
Ein bisschen zurücklesen müsste auch gehen mit portinb().
Das ist ein Dreizeiler. Recht einfach.
Ich habe mal eine serielle schnittstelle (ISA-Karte) selbst gebaut (auch
für DOS Zwecke). Da hat man einfach auch mit portout ein Byte
hingeschickt und das kam dann seriell dort heraus mit 115kbaud. Ums
timing hat sich ein Mega auf der ISA-Karte gekümmert. Zurücklesen hatte
ich damals nicht implementriert, da es nur um debug-ausgaben ging.
Werner
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.