Hi! ich muss mich in die C porgrammierung unter DOS einarbeiten; kennt jemand von euch gute Internetseiten, die hier ne hilfestellung bieten? oder ein buch? danke!
Hast du schon Erfahrung mit C? Wenn nicht, ist sicherlich der Klassiker: Kernighen und Ritchie immer eine Empfehlung wert. http://www.amazon.com/C-Programming-Language-2nd/dp/0131103628
Hi! hab die erfahrung, was ich in der uni damit gemacht habe, also net wirklich viel, aber auch nix; wir haben halt bisher eher die basics gemacht, aber jetzt muss ich unter dos echt arbeiten, register schreiben, lesen; am ende soll damit eine einsteckkarte über den PCI-Bus angesprochen werden;
Hi! ja, ist für meine diplomarbeit; da soll ich ein testsystem aufbauen, und das system hat zu dem zeitpunkt nur dos zur verfügung!
Was für eine Karte ist es denn? Eigenentwicklung oder gibt es da noch "andere" Treiber? Greifst du nur über IO-Register zu oder sind da noch memory mapped Bereiche möglicherweise in höheren (>1MB) Regionen. Ehrlich gesagt würde ich sowas vermeiden, wenn du wirklich nur den Hintergrund hast den du angibst. Wenn es eine Messkarte ist, schau mal bei Labview nach. Der Zugriff auf die Karte wird zumindest wesentlich einfacher, auch vom Debugging wenn Linux oder ein anderes 32Bit Betreibssystem vorhanden ist. Dos ist ein 16 Bit Betriebssystem und man sollte sich sehr klar über die Auswirkungen sein, wenn man 32 Bit Zugriff braucht und was dein C-Compiler macht. Also hier mal ein kleiner Einstieg: Ralph Browns Interrupt list Beschreibt Int 1A ,AX=B102 Find PCI Device Damit kannst du erstmal suchen wo sich die PCI Karte eingeordnet hat. (ja die kann unterschiedliche Adressen haben) Nimm die Hilfe des BIOS dafür in Anspruch, versuche nicht selbst über den PCI-Bus zu suchen. Einige PCI-Konfigurationsregister sind nur durch 32Bit Portzugriffe erreichbar. Bei 16Bit Portzugriffe werden sie nicht angesprochen. Du solltest also wissen WAS dein C-Compiler macht. (Assembler ist da nicht schlecht) Wenn du über 1MB rauswillst, solltest du wissen was der Protected Mode ist und in welchem Modus du bist. Da du nicht alles andere killen willst, ist die Zuhilfenahme von DPMI oder VCPI sehr angebracht. Das kann alles sehr umständlich werden. "PC-Intern" ist da ein guter Einstieg. Wenn es sich nur um eine IO-Karte handelt versuche die PORT Adresse rauszubekommen (Find PCI Device)/ oder teste halt alle Adressen an die sich die Karte im IO-Bereich mappt und probiere mal in DOS mit "debug" und "i" und "o" Befehlen, ob du die Karte ansprechen kannst. Wenn ja, wird es sehr einfach in C (outb/outw) und sollte schaffbar sein.
Hi! okay, ich versuche es mal, alles zu beantworten, soweit es schon steht; die karte ist ne eigendentwicklung; mit dem ganzen soll der steckplatz physikalisch überprüft werden, also ob alle pins des steckers angeschlossen sind / intakt sind; dazu sollen daten übertragen werden, anschliesend verglichen werden; es sollen nach möglichkeit alle pins getestet werden; der punkt mit DOS ist "nicht verhandelbar", da bin ich dran gebunden; das problem mit den 32 bit hab ich noch nicht gelöst, ist alles noch sehr weit am anfang und ich muss mich da erst noch "sortieren"; Wolfram wrote: >Also hier mal ein kleiner Einstieg: >Ralph Browns Interrupt list >Beschreibt Int 1A ,AX=B102 Find PCI Device >Damit kannst du erstmal suchen wo sich die PCI Karte eingeordnet hat. >(ja die kann unterschiedliche Adressen haben) >Nimm die Hilfe des BIOS dafür in Anspruch, versuche nicht selbst über >den PCI-Bus zu suchen. Einige PCI-Konfigurationsregister sind nur durch >32Bit Portzugriffe erreichbar. Bei 16Bit Portzugriffe werden sie nicht >angesprochen. >Du solltest also wissen WAS dein C-Compiler macht. (Assembler ist da >nicht schlecht) >Wenn du über 1MB rauswillst, solltest du wissen was der Protected Mode >ist und in welchem Modus du bist. Da du nicht alles andere killen >willst, ist die Zuhilfenahme von DPMI oder VCPI sehr angebracht. Das >kann alles sehr umständlich werden. "PC-Intern" ist da ein guter >Einstieg. das mus ich erst nochverabreiten; danke,
Besorg die ein altes TURBO C von Borland (so um 1990). Sehr einfach zu bedienen mit Hilfe-Funktion und Einzelschrittablauf, +++. Und dazu natürlich den K&R.
Es gab da mal ein CT-Projekt für einen Eprom-Brenner. Die Software für das Gerät gab es als Sorce-Code dazu. Das dürfte als Einstieg recht hilfreich sein um zu sehen, wie man die Hardware anspricht interrupts auslöst, abfängt ect.
Hi! @michael: genau den hab ich schon (borland von 1992); @tex: wo könnte ich das heute noch herbekommen?
Mal was Ketzerisches OT: Diplomarbeit hat mit Studium zu tun, Studium mit LERNEN. Was willst Du denn lernen bei solch einer Diplomarbeit? Dein zukünftiger potentieller Arbeitgeber lacht Dir doch ins Gesicht, wenn Du über Deine Diplomarbeit sprichts: C unter DOS, das ist ja der Knaller! Wer bietet denn solche Diplomarbeiten an? Die Arbeit selbst soll auf Tontäfelchen dokumentiert werden? Such Dir ne vernünftige Diplomarbeit, was Du machst ist Zeitverschwendung. Ja Cheers Detlef
> Such Dir ne vernünftige Diplomarbeit, was Du machst ist > Zeitverschwendung. Das sehe ich garnicht so. Schließlich soll Hardware verwurschtelt und nicht die Abartigkeiten von Windows/XP ergründet werden. Andernfalls könnte man die Forderung aufstellen, alle kleinen µPs generell nur noch mit einem Multitasking-Betriebssystem zu programmieren. Unter DOS kommt man erheblich besser an die Hardware heran. Wozu also aus dem Hügel ein Gebirge machen?
> Wozu also aus dem Hügel ein Gebirge machen?
Weil die Industrie am Gebirge interessiert ist.
Und zwischen dem Hügel und dem Gebirge ist ein
tiefer Graben.
Ist FreeDOS nicht 32Bit? Könnte dann ne bessere Alternative zum 16Bit Dos von ## sein.
>> Schließlich soll Hardware verwurschtelt [werden] <<
Was issn das für ne Retro-hardware, die sich nur unter DOS bedienen
läßt? Diese hardware ist mindestens 10 Jahre alt. Für nen angehenden
Dipl.Ing. (m/w) sollte man doch erwarten, daß er/sie sich mit modernem
Zeuch auseinandersetzen kann.
Schlimmer noch als die alte Technik ist die 'Denke' der
Bude/Institution, die so arbeitet. Wieso kriegen die denn kein Redesign
der hardware hin? Das zeugt von einiger Unbeweglichkeit, von sowas würde
ich als vorwärtsstrebender Diplomand die Finger lassen, die werden davon
nur staubig.
Cheers
Detlef
Ihr habt natürlich recht. Ein richtiger Programmierer beginnt mit XP und schreibt sich seine IO.DLL ebenmal schnell selber. Und wer das auf Anhieb nicht bringt, soll auch keine Freude bei der Arbeit haben. Erfolgserlebnisse, wozu das denn ? Habt Ihr auch so angefangen ? 1. Fahrstunde auf der Autobahn ? Um Hardware zu testen, braucht man kein Windows. Wozu also die übertriebenen Ansprüche ?
Das Ding ist zum Testen des PCI-Bus... ratet mal wie weit Windows beim booten kommt wenn da ein Fehler ist :D Wollt ihr bei jedem neuen Mainboard erstmal Windows installieren um dann den Bus zu testen. Bitte in Zukunft erst in den Protected Mode umschalten bevor ihr groß mit dem Denken anfangt. Da hat man gleich viel mehr Platz fürs Denken. Freedos ist auch nur 16bit. Zum Thema: Für 32bit gibt es den DOS-Extender DOS32A http://dos32a.narechk.net/index_en.html Open Watcom scheint der dazu passende Compiler zu sein: http://www.openwatcom.com/index.php/Main_Page
das ganze ist durchaus eine moderne diplomarbeit in einem modernen indurstriebetrieb; zu dem zeitpunkt wo getestet wird gibt es noch kein windows (produktionstechnischer hintergrund), also ist es auch keine alternative; womit wir wieder beim anfang wären! ich wäre etwas vorsichtiger damit, sachen als veraltet hinzustellen, bevor man nachdenkt oder alle fakten kennt! @ *.* danke
> Zum Thema: Für 32bit gibt es den DOS-Extender DOS32A > Open Watcom scheint der dazu passende Compiler zu sein: Ich habe irgendwo noch eine kommerzielle Version des alten Watcom. Damals hieß der DOS-Extender allerdings DOS4GW. Der Compiler war damals bei Spieleentwicklern sehr beliebt. > das ganze ist durchaus eine moderne diplomarbeit in einem modernen > indurstriebetrieb; > zu dem zeitpunkt wo getestet wird gibt es noch kein windows > (produktionstechnischer hintergrund), also ist es auch keine > alternative; Wie wäre es mit einem minimalistischen Linux, z.B. von einer Diskette bzw. einer Live-CD? Da braucht man dann auch keine Installation, aber man muss nicht gleich alles zu Fuß machen.
Ich weiss dass es total überholt ist, aber zu der Zeit, als ich dieses Teil aufgebaut habe, ist man zur Gewinnung solcher Informationen in die Bibliothek gegangen und hat sich die gebundenen CT-Jahrgänge rausgeben lassen, in denen man dann die benötigten Informationen rausgesucht und kopiert hat. Soweit ich weiss gibt es Bibliotheken immernoch nur die Suche ist inzwischen einfacher. Man blättert nicht mehr stundenlang nach den Informationen, man sucht sie im Artikelindex und schlägt dann gezielt das Gesuchte Jahrgangsheft auf.
Warum beantwortest du nicht mal die eigentlich relevante Frage: Musst du auf Bereiche jenseits von 1MB für die Karte zugreifen? Wenn nein, viel Spass mit deinem DOS auch wenn ich das recht angestaubt finde. Ist wahrscheinlcih die schnellste Lösung, auch wenn Linux da nicht so sehr hinterherhinkt. Wenn ja, würde ich mir das nochmal genau überlegen. DPMI, Protected Mode usw. braucht doch einiges an Zeit um sich da einzuarbeiten. Da würde ich auch eher zu Linux neigen, das Dir da einiges abnimmt, nämlich den Höhenunterschied zwischen "Hügel und Gebirge". Den darfst du nämlich in Dos zum grossen Teil selbst Programmieren. Das Testen von jedem Einzelnen PIN am PCI Bus kannst du vergessen. Wenn da was falsch ist fährt höchstwahrscheinlich weder DOS noch irgendwas anderes hoch. Bleibt der Funktionstest der Karte über die Kartenregister egal ob nun IO oder memorymapped.
Lass dich vorerst nicht von Linux, 32-Bit und sowas irremachen. DOS ist durchaus noch üblich in der embedded-Welt der Industrie. Mit Linux werden sich noch einige Entwickler wundern die naiv Linux in ihre Produkte gebracht haben (wenn es um GPL geht und man soetwas der Geschäftführung klarmachen muss). Ich kenne nicht nur aus meinem Arbeitsbereich genügend Beispiele für DOS auf PC104 Systemen, vor allem in Systemen wo es auf funktionale Sicherheit ankommt. Deine Diplomarbeit hat auf jedenfall ein guten Lerneffekt in Richtung Embedded-Entwicklung und/oder Treiberentwicklung für eigene Hardware. Aber mal zum Thema: auch wenn das Buch schon von Wolfram gennannt wurde: Versuche irgendwo "PC-Intern Systemprogrammierung" von Data-Becker zu bekommen. Da ist alles erläutert was du brauchst.
>auch wenn das Buch schon von Wolfram gennannt wurde: >Versuche irgendwo "PC-Intern Systemprogrammierung" von Data-Becker zu <bekommen. Da ist alles erläutert was du brauchst. Version 3.0 ist am Empfehlenswertesten allerdings fehlt DPMI Programmierung unter C mit Dosextender. Aber zumindest bekommst du eine Ahnung welcher Berg da auf dich zukommt.
Jaja die gute alte "PC-Intern" Bibel. Bei mir steht immer noch die 2.0 im Regal :) Das Ding war wirklich sein Geld wert. Letzte Version war meines Wissens 5. CU Frank PS: Der Autor war übrigens Michael Tischer.
Hi! also die bibl hab ich mir besorgt und bin am lesen; dann zurück zur frage: ich werde nicht auf den bereich jenseits von 1MB zugreifen, um die sache simpler zu halten; zurück zu dem test selbs: ich setzte einen funktionierenden bus voraus, der test soll den stecker validieren! daher muss es das ziel sein, alle pins zu testen, wie ist noch die frage
den zum pci-bus; es geht darum, mechanische fehler zu detektieren und rechtzeitig zu beseitigen..
>zurück zu dem test selbs: ich setzte einen funktionierenden bus voraus, >der test soll den stecker validieren das ist ein Widerspruch in sich, wenn der PCIbusanschluss fehlerhaft ist, hast du keinen funktionierenden Bus! Das knallt wahrscheinlich schon bei der Evaluierung der Karte durch das BIOS. Da kommt es eventuell erst gar nicht bis zum Dos oder anderen Sachen. Außerdem könntest du sowieso nicht alle PINS evaluieren mit einem DOS-Programm. Wenn du die Karte an ihrer Adresse findest kannst du eigentlich davon ausgehen das die PINS i.o sind.
das system hat 2 komponenten, das baseboard (voll funktionsfähig) mit einsteckplätzen und meine karte (+ software); also der bus auf dem baseboard selbst geht; was allerdings in "frage gestellt wird", ist, ob der stecker physikalisch okay ist; ich bin mir durchaus im klaren darüber, dass wenn die signale AD oder C/BE nicht angeschlossen sind / defekt sind, das ganze nix wird; was ist aber, wenn andere signale wie z.b GNT nicht angeschlossen sind? dann wird meine karte sehr wohl erkannt werden, und dass ist der hintergedanke;
Dazu verwendet man PCI-Bus-Analysatoren und nicht irgendwelche DOS-Programme.
>also der bus auf dem baseboard selbst geht Wenn die erste defekte Karte drin war wär ich mir da nicht mehr so sicher. Das einzige was du tun kannst, ist: Teste die Funktionalität der Karte in ihrer Anwendung. Wenn alles fkt. ist sie OK. sonst nicht. Ich glaube nicht das die spätere Anwendung unter DOS läuft. Nebenbei kommt man da auch Treiberfehlern auf die Spur. Das was du da mit den PIN's versuchst... da gibt es einen elektrischen Leitungstest und einen JTAG/Boundaryscan für sowas.
Das mindeste wäre ein Hot-plug-fähiger PCI-Test-Adapter , wie der hier: http://www.quancom.de/quancom/quancom01.nsf/home_prod_eng.htm?OpenFrameSet&Frame=unten&Src=http://www.quancom.de/qprod01/eng/produkte/uebersicht/bus_extender.htm sonst muß man für jede neue PCI-Karte wieder neu booten.
Das ist ein deutscher Hersteller, dt. Beschreibung hier: http://www.quancom.de/qprod01/deu/pb/pci_ext64.htm
Ja dann... nach genauerem Durchlesen seh ichs auch Für wieviele Steckzyklen ist der PCI-Stecker spezifiziert ? Schon die 96poligen DIN-Leisten VG... haben nur 200-300 Zyklen, und hier ist eine Seite nur eine vergoldete Platine, das sollte man nicht zu oft stecken.
für 100x; momentan sind die goldkontakte verstärkt, sollen 500x halten; allerdings ist für den spätern verlauf geplant, adapter zu verwenden, die die lebensdauer westenlich erhöhen, sonst ist das ganze ja recht unpraktikabel;
Bitte 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.