Hi, ich such n Tutorial in dem das gemeinsame Verwenden von C- und Assemblerfiles in einem Projekt erklärt wird. Oder hat jemand was Selbstgeschriebenes das er mir borgen kann? Joachim
Hallo Joachim, das Thema ist schon sehr oft und erschöpfend besprochen worden. Wenn du trotzdem hier im Forum nichts findest, schau doch mal im PIC-Mikrocontroller-Forum vorbei: http://fernando-heitor.de/ Weiterer Tipp: In der C18 (oder C30) Hilfedatei nach "Mixing C with ASM" suchen. Da ist das Wesentliche erklärt. Gruß, Edson
Meine Erfahrungen vom 8051 und AVR sind: Laß es sein. Man vereint damit nur die Nachteile von beiden, also unportabler, unleserlicher Code des Assembler und mehr Flashverbrauch des C. Nach etwas Einarbeitung in C merkt man schnell, man kann alles in C machen, Assembler ist völlig unnötig. Beim PIC wird es auch so sein, es sei denn, der C-Compiler taugt nichts. Peter
Peter Dannegger schrieb: > Man vereint damit nur die Nachteile von beiden, also unportabler, > unleserlicher Code des Assembler und mehr Flashverbrauch des C. Das ist sicher richtig, aber es gibt Ausnahmen. Interrupts, bzw. ISR-Definitionen lassen sich immer schlecht portieren, ich finde es in dem Fall klarer ein eigenes ASM-Modul mit der ISR* zu erstellen. Es gibt vieles zu beachten wenn man ein C-Projekt portiert, da kommen vollkommen unterschiedliche Anforderungen dazu - je nachdem, ob man den Code für ein anderes Target oder (ggf.zusätzlich) mit einem anderen Compiler kompilieren muss. Kein Entwickler wird übersehen, wenn Assembler-Module verwendet wurden und er weis wie viel Arbeit beim Portieren auf ihn zukommen wird. (Vorausgesetzt, das zugehörige C-Programm ist bereits portabel) Peter Dannegger schrieb: > Nach etwas Einarbeitung in C merkt man schnell, man kann alles in C > machen, Assembler ist völlig unnötig. Bis auf die Ausnahmen ;) Gruß, Edson * bei PIC12 und PIC16 gibt es nur einen Interrupt-Vektor und keine IVT, daher benötigt man in zeitkritischen Anwendungen besonders schmalen ISR-Code und verzichtet soweit wie möglich auf calls zu untergeordneten ISRs. Es herrscht quasi "Spaghetti-Code-Gebot".
>das Thema ist schon sehr oft und erschöpfend besprochen worden.
Ich habe nach zwei Tagen Netz absuchen das Gegenteil festgestellt. Es
geht ja eigentlich nicht um das eigentliche Portieren (16f auf 18F)
sondern um das Gedöns mit dem Linker, der 'Globalifizierung' beim
Austausch von Daten (C-Funktion schickt zur Asm-Routine u. zurück). Hab
an dieser Stelle einfach viel zu wenig Erfahrung. Alles andere ist ja
nur Fleißarbeit und nicht der Rede wert.
Dem Ganzen steht ca 2,2kB zeitkritischer Assemblercode fehlerfrei nach C
zu übersetzten gegenüber. Und ob die Ferdinand-Heitor-Lauflicht-Webseite
welche die Programmierung von Zeitschleifen am liebsten mit delay();
durchführt für das alles die richtige Instanz ist, wage ich jetzt nicht
weiter zu erfragen.
Joachim ... schrieb: > Und ob die Ferdinand-Heitor-Lauflicht-Webseite > welche die Programmierung von Zeitschleifen am liebsten mit delay(); > durchführt für das alles die richtige Instanz ist, wage ich jetzt nicht > weiter zu erfragen. Weis jetzt nicht wie du darauf kommst. Genau wie hier auch tummeln sich da jede Menge Anfänger (die haben nunmal die meisten Fragen), Bastler und Profis. Aber wenn du schon die Doku zu deinem Compiler nicht lesen magst, welche Art Hilfe erwartest du denn? Ich kann dir auch nur sagen, was dort steht solange du keine konkrete Frage hast. Gruß, Edson
Hier zwei passende Links von der "Lauflicht-Webseite" ;) http://fernando-heitor.de/index.php/forum/index.php/topic,2573.0/ http://fernando-heitor.de/index.php/forum/index.php/topic,4372.0/ Gruß, Edson
Näheres dazu findest Du im C18 User's Guide
("Calling Assembly Functions from C").
Tatsächlich. Ein Treffer. Also gut, hast gewonnen. Jetzt wo ich's seh'
erinnere ich mich auch wieder das ich das ca 2004 mal las.
Hatte mich auf den Linker konzentriert, in der zugehörigen Dok war
nichts zu finden.
Peter Dannegger schrieb: > Nach etwas Einarbeitung in C merkt man schnell, man kann alles in C > machen, Assembler ist völlig unnötig. > > Beim PIC wird es auch so sein, es sei denn, der C-Compiler taugt nichts. Der C-Compiler als Allheilmittel? Wahrscheinlich hast du nur wenig Erfahrungen mit PIC's, um sowas zu schreiben. Mit der gleichen Logik könnte ich schreiben: "Man kann auch alles mit CLIPPER machen, C ist völlig unnötig". Das ist natürlich eine heftige Übertreibung meinerseits - aber daran siehst du sicherlich selbst, was für einen Unsinn man beim Generalisieren (DER_ _Pic) verzapft. Jede Programmierweise, egal ob mit einer Programmiersprache oder ohne (ja, sowas gibt's auch, denk mal an Schematics versus VHDL) hat ihren sinnvollen Anwendungsbereich - und außerhalb dessen ist sie eben nicht mehr so sinnvoll bzw. angemessen. Bei den PIC's gibt's große, kleine und winzige. Welche meinst du denn, wenn du "Beim PIC wird es.." schreibst? Was bitte sehr soll man mit C bei einem Controller im winzigen SOT23-Gehäuse mit maximal 512 Programmschritten anfangen? Da kommt man nicht weit. Und portabel? WOZU portabel? PIC's sind fast immer die erste Wahl für echte Spezialanwendungen, die man SO mit anderen Controllern nicht hinbekommt. Nee, bei solchen kleinen Controllern ist schlichtweg Assembler angesagt. Bei größeren Exemplaren, wo man reichlichst Ressourcen hat, sieht das wiederum anders aus. Die Wahl des Programmier-Mittels sollte eigentlich durch die Aufgabe bestimmt werden - und nicht durch das Maß der Fähigkeit des Entwicklers. Allerdings sehe ich, daß die Anzahl derer, die tatsächlich Assembler können und bereit sind, die Hardware mit der sie umgehen sollen zu verstehen, mittlerweile klein geworden ist. Die überwältigende Mehrheit unserer tollen jungdynamischen Ingenieure kann außer C kaum noch etwas - und damit man sich nicht mit Hardware befassen muß, benötigt man Treiber-Libs. Oh ja, es gibt schon einige Arbeitgeber, wo derartige Ingenieure noch nicht zu abgehoben sind. Aber eben nur einige. W.S.
W.S. schrieb: > Was bitte sehr soll man mit C > bei einem Controller im winzigen SOT23-Gehäuse mit maximal 512 > Programmschritten anfangen? Was willst Du denn mit einem 6-Pinner programmieren, doch nicht etwa MP3, USB, NTFS? Damit macht man doch nur kleine Steuerungen und die gehen sehr gut in C mit 512 Worten. Ich benutze z.B. den ATtiny13 (512 Worte, 8 Pins) und ausschließlich in C. Z.B. für einen Dimmertaster mit Phasenanschnittsteuerung und kapazitivem Qtouch-Sensor. Allerdings benutze ich keine PICs, sondern AVRs. Und die AVRs haben den großen Vorteil, daß die 6- und 8-Pinner genau die gleiche Architektur haben, wie die großen 100-Pinner. D.h. aus Compilersicht muß man keinerlei Abstriche machen oder gar einen anderen Compiler nehmen. Der ATtiny10 im SOT23 hat z.B. 512 Worte Flash, 1*16Bit Timer, 4Kanal-8Bit-ADC, 2*PWM, 10 Interruptquellen (Vektoren). W.S. schrieb: > Nee, bei solchen kleinen Controllern ist schlichtweg > Assembler angesagt. Beschreib dochmal ne Aufgabe, wofür man bei einem SOT23 Mikrocontroller unbedingt Assembler benötigen sollte. Und wenn Du hier schon ne Weile mitliest, wirst Du bestimmt wissen, daß mir in puncto 8051- oder AVR-Assembler keiner so leicht was vormachen kann. Peter
Peter Dannegger schrieb: > Und wenn Du hier schon ne Weile mitliest, wirst Du bestimmt wissen, daß > mir in puncto 8051- oder AVR-Assembler keiner so leicht was vormachen > kann. Wenn du bekennenderweise garnicht in Assembler programmierst, ist das ja wohl reine Angabe. Oder sprichst du von einem früheren Leben? Rein theoretisch kann ich auch alles Mögliche, auch Mongolisch. Ich halte es bloss für überflüssig. Gruss Reinhard
Reinhard Kern schrieb: > Wenn du bekennenderweise garnicht in Assembler programmierst, ist das ja > wohl reine Angabe. Seit wann darf ein C-Programmierer kein Assembler können? Als ich 1990 mit 8051 angefangen habe, da waren C-compiler selten oder schweineteuer. Und auch als 1997 der AVR das Licht der Welt erblickte, sah es mit Compilern düster aus. Ich habe also beide über Jahre hinweg in Assembler programmiert. Daß ich heutzutage Assembler nur mit der Kneifzange anfasse, spricht wohl sehr dafür, daß C deutliche Vorteile hat. Man kommt wesentlich schneller voran mit seinen Projekten. Natürlich ist es nicht von Schaden, wenn ein C-Programmierer Assembler kann. Man kann dadurch den Compiler viel besser verstehen und optimaleren Code schreiben. Man weiß, welche Konstrukte teuer sind und vermeidet sie, soweit möglich. Und wenn man mal ehrlich ist, staunt man oft, wie clever der Compiler manche Sachen macht. Ich hab z.B. beim 8051 mit der 32Bit-Division wochenlang rumoptimiert, um dann später festzustellen, daß die Compilerroutine doppelt so schnell ist und nur halb soviel Flash benötigt. Es ist also nicht unwarscheinlich, daß ein Assemblerprogramm nach dem Umschreiben in C sogar schneller und kleiner ist. Wie gesagt, meine Erfahrungen betreffen konkret den 8051 und den AVR. Wie gut die Compiler beim PIC sein können bzw. sind, kann ich natürlich nicht beurteilen. Man liest allerdings oft, daß die meisten PICs dem Compiler die Arbeit sehr schwer machen und man besser PIC18 und höher nehmen soll. Peter
Peter Dannegger schrieb: > Ich hab z.B. beim 8051 mit der 32Bit-Division wochenlang rumoptimiert, > um dann später festzustellen, daß die Compilerroutine doppelt so schnell > ist und nur halb soviel Flash benötigt. Ja, glaube ich ja sofort, aber das liegt ja daran, dass derjenige, der das in Assembler programmiert hat, besser war oder vor allem länger und sorgfältiger dran gearbeitet hat und/oder Spezialist war für Rechenalgorithmen. Das spricht also ganz und garnicht gegen Assembler. Deine Argumentation läuft ja bloss darauf hinaus, die schwierigen Sachen anderen zu überlassen. Im übrigen bin ich der Meinung, dass solche Primitiven wie Schiebe-Operationen und Maskierungen in Assembler viel übersichtlicher sind als mit den kryptischen C-Operatoren. Wenn ich eine Routine für den Empfang eines ASCII-Zeichens per UART schreibe, ist die in Assembler viel verständlicher (Und mehr Zeit kostet mich das auch nicht). Was dagegen garnicht zu bezweifeln ist, ist die Tatsache, dass man ganz ohne Mühe sowohl in C als auch in Assembler grottenschlechte Software schreiben kann. Gruss Reinhard
Reinhard Kern schrieb: > Ja, glaube ich ja sofort, aber das liegt ja daran, dass derjenige, der > das in Assembler programmiert hat, besser war oder vor allem länger und > sorgfältiger dran gearbeitet hat und/oder Spezialist war für > Rechenalgorithmen. Nö, das ist eben keine 1-Mann Aktion, der das nur nebenbei macht, sondern ne Firma mit einem Team, die damit Geld verdient. Reinhard Kern schrieb: > Deine Argumentation läuft ja bloss darauf hinaus, die schwierigen Sachen > anderen zu überlassen. Nö, der Applikations-Programmierer wird ja vom Kunden nicht dafür bezahlt, den Urschleim nachzuentwickeln, sondern für das Lösen der Aufgabe. Es ist die Ehre eines jeden Programmierers, die Zeit und damit das Geld des Kunden nicht zu vergeuden. Die Frage nach Assembler + C zu vermanschen, kommt auch fast nur von Anfängern und deren Assembler-Programmier-Versuche wird ein Compiler oft spielend übertrumpfen. Reinhard Kern schrieb: > Im übrigen bin ich der Meinung, dass solche Primitiven wie > Schiebe-Operationen und Maskierungen in Assembler viel übersichtlicher > sind als mit den kryptischen C-Operatoren. Das mag sein, aber Du vergißt den Prolog/Epilog. In Assembler schreibt man ja nicht nur den Schiebebefehl hin, sondern auch das PUSH/POP der Arbeitsregister und Laden der Variablen. Ein C-Ausdruck benötigt schonmal leicht 5 Assemblerzeilen und das ist dann überhaupt nicht übersichtlicher. Wenn ich so an Assembler zurück denke, wie oft hat mich ein falsches PUSH/POP schon fast zur Verzweiflung getrieben. Peter
Ach Reinhard, laß den Peter Dannegger sein. Er versteht nichts von PIC's, meint aber, seine Meinung über das Programmieren von PIC's sei die ultimative Weisheit. Ich entsinne mich noch an seine völlig unqualifizierten Bemerkungen in einem anderen Thread, wo es um die maximale Zählfrequenz ging, die man an einem mit dem Systemtakt synchronisierten Portpin eines uC messen kann. Auch so ein PIC versus AVR Streit, bei dem er nichts begreifen wollte. Ich kenne einige Leute, die mit gerümpfter Nase sagen "So ein PIC hat ja nur ein W-Register und mein AVR hat viel mehr Register, deswegen ist PIC Mist und AVR gut". Diese Leute werden PIC's nie begreifen und für sie sind klassisch aufgebaute Registermaschinen genau richtig, weil das die einzige Architektur ist, die solche Trolle zu begreifen imstande sind: Lade Register, verknüpfe Register, speichere Register. Irgendwie sind die AVR's von Atmel clever gemacht: Ihre Architektur ist zwar altbacken (Registermaschine, RAM-Bereich, I/O-Bereich), aber sie entsprechen genau den Wertvorstellungen von C-Programmierern, die sich mit Hardware eigentlich nicht befassen wollen. Ist auch ein Erfolgsrezept, wie man sieht. Also, laß mal, es ist vergeblich. W.S.
Peter Dannegger schrieb: > Man liest allerdings oft, daß die meisten PICs dem > Compiler die Arbeit sehr schwer machen und man besser PIC18 und höher > nehmen soll. Zumindest wurde ab PIC18 mit einer "für C-Compiler optimierten" Architektur geworben. Den Spruch kennst du ja von den AVRs. Aber es ist wohl richtig, dass die Architektur der PIC10/12/16 so speziell ist, dass sich kein vorhandener C99-Compiler wie der GCC für die AVRs einfach darauf umkonfigurieren lässt. Erst ab PIC24/dsPIC gibt es GCC-Derivate. Peter Dannegger schrieb: > Wenn ich so an Assembler zurück denke, wie oft hat mich ein falsches > PUSH/POP schon fast zur Verzweiflung getrieben. Das kann auf dem in Hardware ausgeführten CALL/RETURN-Stack eines PIC10/12/16/18 schlecht passieren bzw. ist relativ leicht aufzuspüren. Für den High-Priority Interrupt der PIC18 gibt es sogar Schattenregister, die automatisch das Sichern und Wiederherstellen der sogenannten Kontext-Register übernehmen (in der Regel sind das nur 3 Register). Gruß, Edson
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.