Hallo, mich würde mal interessieren, wie man größere Projekte in PIC asm am schönsten angeht. Konkret habe ich LCD-Routinen für einen PIC16F877A geschrieben und würde diese gern möglichst Modular einsetzen können. Das soll nur ein "Test im Kleinen" werden, dass es sich für diesen Fall noch nicht so sehr lohnt, ist mir klar. Nun liest man hier und da von Libraries und Objectfiles, doch steht nirgends mal ordentlich erklärt, wie man eine Library erstellt und sie einsetzt. Ich nutze MPLAB X und den MPASM assembler. Am schönsten wäre mal ein anschauliches Tutorial dazu, ich konnte allerdings bis jetzt keines finden. Folgende Fragen stelle ich mir zu dem Thema: 1) Ich habe bis jetzt absolut programmiert, müsste wohl für eine Library aber zu relocatable wechseln. Wie wechsle ich in MPLAB X überhaupt den Modus, in MPLAB gab es die Option unter 'Build-Options' im Reiter 'MPASM/C17/C18 Suite'. In MPLAB X habe ich in den 'Project Properties' unter 'mpasm (Global Options) zwar den Punkt 'Build in absolute mode [(N/A) ]', doch lässt sich das N/A nicht ändern (grau hinterlegt). 2) Wie sieht ein Library-Project aus, kann man auf den gewöhnlichen Templates aufbauen, die die MPASM-Suite mitbringt? 3) Wie funktioniert banking im relocatable Mode? Kann ich einfach mit 'banksel' arbeiten (bis jetzt spreche ich die RPx-Statusbits direkt an)? 4) Auf was muss man achten, wenn man die library einbindet? Wird sie einfach mit '#include "my.lib"' eingebunden? Kann man sie auch für andere Controller einbinden oder nur für den exakten Typ, für den sie assembliert wurde? 5) Wenn ich die Library beispielsweise für einen anderen Port nutzen möchte, wie geht man das an? Ersetzungen à la '#define LCDPORT PORTB'? Das müsste man dann ja direkt in der Library machen, macht das überhaupt Sinn? 6) Generell frage ich mich: nutzt man besser Libraries oder bindet man einfach zusätzliche .asm-Files über ein include im "main-File" ein? Oder arbeitet man lieber mit Spaghetticode in einem einzigen Sourcefile, auch wenn es sehr lang wird? Passt ihr euren Code (ich meine damit eure "Standardroutinen") wenn ihr ihn auf einen anderen Controler übertragen wollt immer komplett neu an, oder arbeitet ihr möglichst viel mit #define-directives? Viele Fragen, aber vielleicht kann ja mal jemand etwas Licht ins Dunkel bringen. Gruß, Stefan
niemand mit Verstand macht größere Projekte heutzutage noch in Assembler
@ttl: Es ist sicher deutlich zeitintensiver und umständlicher, kann sich aber meiner Meinung nach durchaus lohnen, sei es durch besseres Verständnis oder durch die höhere Performance. Zugegeben, größere Projekte in asm werden im kommerziellen Umfeld sicher erst in Massenproduktionen Sinn machen. Ist aber nicht meine Frage - es gibt sicher Leute, die "sich das antun" und wissen, wie man es am besten angeht. Gerade oft gebrauchte Snippets effektiv wieder zu verwenden - sei es in kleineren oder größeren Projekten - spricht ja eigentlich schon für die Verwendung von Libraries oder ähnlichem.
Hier findet sich ein (sehr) kurze Anleitung zu Projekten mit Library unter MPLAB X http://microchip.wikidot.com/mplab:how-to-create-a-library-project
@Chris B.: Das Tutorial ist aber leider für C. Ich habe mal versucht, eine asm-Library nach dem Vorgehen zu erstellen, allerdings bin ich mir - wie im Startpost erwähnt - nicht sicher, wie so ein Library-File aufgebaut sein muss. make wirft mir einen "No rule to make target"-error, es gibt für mich aber zu viele potentielle Fehlerquellen, als dass ich da groß probieren möchte. Vielleicht hat ja jemand ein Beispiel / Template oder ähnliches, wie man das Ganze angeht. Die Anleitung ist leider ziemlich oberflächlich und beantwortet meine Fragen nicht wirklich. Dennoch danke für den konstruktiven Beitrag. Gruß, Stefan
Bevor ich auf C umgestiegen bin hab ich größere Projekte so zerlegt, dass ich Teile davon über include an die entsprechende Stelle geladen haben. Das waren z.b. auch LCD Ausgaben, Tastaturroutinen, Konstanten, Initialisierung usw. Allerdings waren die einzeln nicht wirklich woanders zu gebrauchen, haben nur den Code etwas lesbarer gemacht.
Stefan S. schrieb: > 1) Ich habe bis jetzt absolut programmiert, müsste wohl für eine Library > > aber zu relocatable wechseln. Wie wechsle ich in MPLAB X überhaupt den > > Modus, in MPLAB gab es die Option unter 'Build-Options' im Reiter > > 'MPASM/C17/C18 Suite'. In MPLAB X habe ich in den 'Project Properties' > > unter 'mpasm (Global Options) zwar den Punkt 'Build in absolute mode > > [(N/A) ]', doch lässt sich das N/A nicht ändern (grau hinterlegt). Welche Version von MPLAB verwendest du? Habe es gerade mit MPLABX 1.60 und MPASMX 5.48 probiert. Bei NewProject ein "Library Project" auswählen..... Im ProjectWindow unter SourceFile das .asm-File einfügen. In ProjectProperties->mpasm(global options) "Build in absolute mode" das Häckchen wegnehmen. Templates: verwendet habe ich dieses Template aus MPASM Suite/Template/Object/16F819TMPO.ASM (umbenannt in testreloc.asm und ein bisschen Datendefinitionen und code eingefügt) BuildProject lief zumindest fehlerfrei durch und erzeugte die Dateien testreloc.o testreloc.o.d. !!!! Ich habe das aber nicht weiter ausgetestet, wollte nur wissen ob es tatsächlich nicht möglich ist ;-)
@Chris B.: Kaum macht mans richtig, gehts ;) Ich habe auf deinen Post hin gemerkt, dass meine MPLABX Version schon relativ alt war (1.10), also erst mal die 1.60 installiert. Nun habe ich in besagtem Feld kein [N/A] mehr stehen, sondern eine Checkbox, die ich auch aktivieren und deaktivieren kann. Build konnte ich nun bei einem Test ebenfalls erfolgreich ausführen. Damit bin ich schon mal einen ganzen Schritt weiter, vielen Dank! @Holger W.: Ich habe mir inzwischen einige fertige Projekte angeschaut, um ein Bild dafür zu bekommen, wie andere das angehen. Es wird oft, wie du beschreibst, in mehrere .asm-Files aufgeteilt. Projekte als asm-Libraries habe ich auf PIC-Projektseiten allerdings noch nicht gefunden. Das scheint allem Anschein nach relativ selten gemacht zu werden. Für bessere Übersicht macht das 'Zerhacken' des Projektes in mehrere .asm-Files durchaus Sinn (auch wenn man öfter liest, die #include-Direktive sei dafür nicht gemacht), bringt einem aber leider keine bessere Portabilität, wie du schon sagtest. Search&Replace kann doch nicht immer das Mittel der Wahl sein, oder? Gruß, Stefan
Mein letztes Projekt war in Assembler so groß und unübersichtlich geworden, dass ich es dann neu mit C angefangen habe. Nach einiger Zeit hab ich die Struktur von .h. und .c Files einigermaßen verstanden. Ich kann dir nur dazu raten. Es ist allerdings nicht verkehrt dass man sich mit dem Assembler beschäftigt, ich möchte es nicht missen. Versuch es einfach mal mit C Holger
Es ist nicht so, dass ich kein C könnte, sondern eher so, dass ich Assembler als Sprache mag und Hobbyprojekte, wo es mir auf Entwicklungszeit nicht ankommt, gerne damit realisiere. Wenn es schnell gehen muss oder das Projekt in Assembler zu "anstrengend" ist, greife ich natürlich auch zu C. Wenn man allerdings ein gewisses Repertoire an halbwegs Portablen Librarys hätte, würde das Programmieren in Assembler auch schneller von der Hand gehen. So muss man ja das Rad auf jedem Prozessor neu erfinden. Man liest mehr im Code vom letzten mal quer und schreibt ihn in Teilen ab, als dass man ihn mit nur kleinen Anpassungen kopieren und wieder verwenden könnte. Gruß, Stefan
Mit fertig kompilierten Libraries kommst du ja nicht weit. Ein '#define LCDPORT PORTB' funktioniert nun mal nur im Assembler. Am sinnvollsten erscheint mir ein simpler übersichtlicher Aufbau. Im Hauptprogramm am Anfang ein #include "../lib/lcd.inc". Da drinnen alle ifdefs für die unterschiedlichen Pics. Relocatable Code linken oder Asm includieren? Beim Include wird die Aufteilung der Page Boundaries übersichtlicher. LIB1 CODE 0x800 #include "../lib/lcd.code" LIB2 CODE 0x1800 #include "../lib/sd.code" Dabei kannst du das '#define LCDPORT PORTB' einfach an den Anfang des Hauptprogramm schreiben. Möchtest du lcd.asm getrennt assemblieren, einfach in jedem deiner Projekte ein hardware.inc anlegen und im lcd.asm ein #include "hardware.inc". Aber das eigentliche Problem: wenn ein kleiner Hack im lcd.asm genügen würde, trotzdem übersichtlich im lcd.inc und hardware.inc einbauen.
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.