Hallo liebe Leute, zunächst mal muss ich sagen, dass ich mit dem PIC sehr gerne arbeite, was durchaus Gewohnheit ist, weil ich schon sehr lange mit ihm arbeite. Natürlich auch wegen der Bastler-freundlichen Bauformen (DIL). Nun will ich für ein kleines Projekt Anschluß an den USB. Daher habe ich mir den 18C445x gewählt. Schaltung ist soweit fertig, allerdings will ich keinen Treiber für Windows programmieren, somit will ich die RS232-Emulation mit der CDC-Firmware von Microchip nutzen. Soweit so gut. Leider gibt es CDC aber nur im C-Code, Assembler wäre mir lieber. Nun gut, also schaue ich nach dem C-Compiler und was sehe ich da: den soll ich bezahlen oder als Krüppelware für 60 Tage testen? Nun habe ich schon in Programmer und zahlreiche PICs investiert und meinen PIC-Programmer (älterer Bauart) umgerüstet, damit dieser 18C445x brennen kann und damit ich nun damit arbeiten kann soll ich nun nochmal in die Tasche greifen, für eine Software, die ich eigentlich gar nicht will? Dann wäre es in meinen Augen schon ehrlicher, wenn man für die USB-Software direkt zur Kasse gebeten würde und nicht so "hinten herum". Das würde mir zwar nicht gefallen, könnte ich aber verstehen. So jedoch ist es Beutelschneiderei. Schöne Grüße und Schöne Pfingsten an alle, Christian
Ich kenne jetzt die Microchip Firmware nicht. Aber wenn die nicht zu groß ist, übersetz den C-Code doch von Hand nach Assembler.
Hallo, recht klein ist die Firmware nicht, ca 5KB Maschinencode, da sitzt man schon ne Weile dran. Vielleicht hat jemand schon Erfahrung darin, mit der 60-Tage-Version des C-Cpompilers - den ich auf keinen Fall kaufe ;-) - den USB-Source in Assembler zu übersetzen. Dann bräuchte ich den Comipler anschließend nicht mehr und könnte mit Assembler weiterentwickeln. Gruß Christian.
> Leider gibt es CDC aber nur im C-Code, Assembler wäre mir lieber. CDC in Assembler? Meinst du das ernst? > Nun gut, also schaue ich nach dem C-Compiler und was sehe ich da: > den soll ich bezahlen oder als Krüppelware für 60 Tage testen? Richtig, dannach mußt du bezahlen, wenn du die volle Funktionalität weiter haben möchtest. Verständlich, Microchip ist ja kein Wohlfahrtsunternehmen. Allerdings wird der COmpiler nach 60 Tagen nicht unbrauchbar, es werden lediglich einige Optimierungsalgorithmen deaktiviert. Das ist nicht tragisch, dass Projekt lässt sich dnnoch kompilieren und benutzen. Probier's einfach mal aus.
Hallo Jupp, leider hast Du mich falschg verstanden. Es geht nicht darum NICH zu bezahlen, sondern die Art, wie. Hätte man für den CDC eine Obulus verlangt wäre das absolut einsichtig. Aber zunächst den Source kostenlos um dann den Compiler verkaufen zu können, ich habe Zweifel ob das so richtig ist. Ich würde gern in Assembler programmieren, da ich hierbei gut die Laufzeiten abschätzen kann und ich darin auch schon Erfahrung habe. Schöne Grüße Christian
Was wäre denn für dich einen Obulus? Ich völlig anderer Meinung. Der CDC-Code ist frei verfügbar => sehr schön Der Compiler ist für Privatpersonen/Studenten ebenfalls quasi kostenlos. Microchip gestattet die Nutzung auch nach den 60 Tagen und die genannten Optimierungen sind nicht zwingend notwendig. Naja und für Firmen sind die 500$ für den Compiler eher Nebensache. Ist doch nicht schlecht. Jeder hat somit die Möglichkeit, den Code als auch den Compiler kostenlos zu testet. Wäre doch Gülle, wenn ich "einen kleinen Obulus" (womoglich noch per PayPal LOL) bezahle und dann feststelle, dass irgendwas nicht so passt wie ich mir das vorstelle.
Guck doch mal, ob der Compiler eine Option hat, mit der der Assemblercode ausgegeben wird. Den kannst Du Dir dann an den Assembler anpassen und auf den C-Compiler in Zukunft pfeifen...
Christian Meurer wrote: > Dann wäre es in meinen Augen schon ehrlicher, wenn man für die > USB-Software direkt zur Kasse gebeten würde und nicht so "hinten herum". Fragt dochmal, ob Du für den Quellcode noch extra was bezahlen darfst. > Das würde mir zwar nicht gefallen, könnte ich aber verstehen. So jedoch > ist es Beutelschneiderei. Daran ist überhaupt nichts Beutelschneiderei ! Daß es manche Software als Freeware gibt, heißt noch lange nicht, daß sie Dir alles umsonst in den Hintern schieben müssen. Compilerbauer müssen auch ihre Familien ernähren ! Wenn Dir soviel daran liegt, nimm doch nen Freeware-Compiler. Ich benutze z.B. den 8051 und den AVR und dafür gibt es auch Freeware Compiler (SDCC, WINAVR). Es ist normal, daß ab einer bestimmten Codegröße die Quellen in C geschrieben werden. Z.B. beim 8051 mache ich Assembler bis höchstens 2kB. Darüber verliert man einfach den Überblick und die Wartbarkeit und Erweiterbarkeit sinkt gegen 0. Ich hatte zu Anfang mal 8kB in Assembler geschrieben. Nach 2 Jahren habe ichs komplett weggeschmissen, da ich nicht die Bohne mehr durchsah. Peter
Hallo Jupp, mir wäre ja geholfen, wenn ich einen geeigneten Weg finde, den C-Source in Assembler zu übersetzen. Ich will mich eigentlich gar nicht in C einarbeiten, zumindest nicht für meine Mikrocontroller-Aufgaben. Assembler für den PIC ist mir bereits vertraut und wäre genau was ich mir wünsche. Ich habe auch schon überlegt, die Custom-USB-Firmware zu benutzen. Allerdings hat das 2 entscheidende Nachteile für mich: )ich muss mich komplett in die USB-Spec einarbeiten und noch viel schlimmer )ich muss einen Windows Treiber schreiben. daher ist CDC (RS232 Emu) wahrscheinlich die beste Lösung, auch wenn das vom User verlangt, dass er einen COM-Port wählt. Nur ist das leider nicht in Assembler verfügbar. Aber ich bin mir sicher, irgendwie geht das... ;-) Gruß Christian
Handykaps deiner seits: 1. Gebrauchst du PIC 2. Kannst und willst du kein C 3. Bist du nicht bereit was zu investieren aber forderst wieder mal alles. 4. CDC in Assembler ist SICHER nicht ein sinnvoller Weg.
Hallo Peter, 8kB ist natürlich auch schon ein ganz großes Ding, für meine Zwecke komm ich mit weit weniger aus. So ein µP-Crack wie Du bin ich sicher nicht. Schöne Grüße Christian
>mir wäre ja geholfen, wenn ich einen geeigneten Weg finde, den >C-Source in Assembler zu übersetzen. Der Compiler kann definitiv ein Assemblerlisting erzeugen, ich hab dir im Anhang mal eins hochgeladen. Mußt du entscheiden, ob du damit was anfangen kannst.
Christian Meurer wrote: > 8kB ist natürlich auch schon ein ganz großes Ding, für meine Zwecke komm > ich mit weit weniger aus. So ein µP-Crack wie Du bin ich sicher nicht. Das hat nichts damit zu tun, ob man ein µP-Crack ist, sondern mit dem Umfang der Aufgaben, die man dem MC zu erledigen gibt. Ich hab auch viele AT89C2051 und ATtiny26 im Einsatz und die älteren Projekte darauf sind noch in Assembler. Natürlich ist man mit zunehmender Erfahrung besser in der Lage, einen einzigen MC besser auszulasten und ihm mehr Aufgaben aufzubürden. Peter
Danke an Jupp, ich werde mir wohl oder übel den Compiler installieren und versuchen in eine Lage zu kommen, die Schnittstelle des CDC von Assembler aus zu nutzen. Ich habe gesehen, dass der Compiler auch Objekt-Files erzeugen kann, die mit MPLINK weiterverarbeitet werden können, so müsste ich doch weiter kommen, denke ich. Oder? Gruß Christian
Wieso nimmst du nicht einfach einen PIC ohne USB und klebst draußen noch einen FT232 dran. Der Treiber ist schon vorhanden und vom Controller aus ist es nur eine normale UART-Schnittstelle. Der FTDI ist mit 5 Euro wesentlich billiger als der C-Compiler und den zusätzliche Aufwand, den du in die Übersetzung des C-Codes in Assembler stecken müsstest kannst du dir auch sparen.
So sonderlich ernst scheints Dir ja nicht zu sein, sonst wärst Du längst auf die durchaus brauchbaren Vorschläge eingegangen, die gemacht wurden. Also nur klagen auf hohem Niveau?
Hallo Kai, wäre eine denkbare Alternative, wenn alle Stricke reißen. Allerdings müsste ich die Schaltung dann wieder aufreißen. Ich war ja so optimistisch und hab schon auf PIC mit USB layoutet. ...und irgenwie geht es ich weiss es, auch ohne C ;-) Gruß
Hallo Uhu, leider verstehe ich nicht was Du meinst. Oder gibst Du immer direkt auf, wenn was nicht klappt? Gruß Christian PS. solche Kommentare erscheinenmir sinnlos, oder?
Also nochmal - wie Jupp und ich bereits geschrieben haben: Laß Dir den Assembleroutput des Programmes vom Compiler erzeugen und protiere den auf Deinen Assembler. Dann hast Du, was Du so sehr beklagst...
Uhu wrote: > Laß Dir den Assembleroutput des Programmes vom Compiler erzeugen und > protiere den auf Deinen Assembler. Ob man damit glücklich wird ? In der Regel erzeugen Compiler nicht lokalisierten Code, d.h. die Code und SRAM-Adressen löst erst der Linker auf. Assemblerprogrammierer schreiben aber meist festen Code und das geht dann schief, beides zu kombinieren. Außerdem muß man sich noch mit den C-Internas auseinandersetzen. also wie welche Funktionen ihre Parameter organisieren (Byteorder) und übergeben (Register, Stack oder SRAM). Ich habe mich daher vor dem Aufwand gescheut und entweder C oder Assembler geschrieben bzw. nur einzelne Zeilen Inline-Assembler. Peter
> Ich habe mich daher vor dem Aufwand gescheut und entweder C oder > Assembler geschrieben Also ist C doch ein paar Nummern komplexer, als hier immer behauptet wird? Ich scheue mich nämlich auch vor C, allerdings auf AVR. Ist mir einfach zu kryptisch. Ich kann auch Christians Unmut gut nachvollziehen, ich wehre mich schließlich auch dagen, den GCC zu installieren, denn in ASM weiß ich inzwischen, was ich mache (auch dank Deiner Hinweise, Peter), in C müsste ich Lotto spielen, dazu habe ich weder Lust noch Nerven. ...
>Also ist C doch ein paar Nummern komplexer, als hier immer behauptet >wird? Das kann man nicht ganz so pauschal sagen: Es liegt wohl eher an der komplexen Struktur eines PIC - beim AVR kann man viele Sachen von C quasi direkt in Assembler übersetzen. Grundlagen benenötigt man aber schon (auf beiden Programmierseiten). Ich würde aber sagen, dass Hannes auch ein C-Programm verstehen können sollte, wenn er die C-Bibel* zur Hand hat. In C zu Programmieren sollte dank des Tutoriums auch möglich sein... ;-) *Kernighan und Ritchie, "Die Programmiersprache C", in Deutsch ab der 2. Auflage als gute Übersetzung "anerkannt". Die vorherige ist was zur Belustigung...
> Ist mir einfach zu kryptisch.
LOL was bitte ist an C kryptisch???
/funein Echte Progammierer programmieren nur in Assembler :o))) /funaus
Jupp wrote: >> Ist mir einfach zu kryptisch. > > LOL was bitte ist an C kryptisch??? Das hilft zwar dem Threadstarter nicht weiter, aber: Ich programmiere keine anderen Controller als AVRs. Meine Programme sind vom Umfang her recht überschaubar und enthalten keine komplizierten Rechnereien, sind also eher "Bitschubserei". Die Programme laufen ja beim AVR direkt an der Hardware, also ohne OS. Unter diesen Randbedingungen empfinde ich AVR-Assembler als sehr eindeutig und logisch. Der AVR macht exakt das, was ich ihm programmiert habe, da pfuscht mir kein Compiler dazwischen, da habe ich volle Kontrolle über jedes Bit und Byte. Alle benötigten Informationen sind im Datenblatt zu finden und sind recht eindeutig. In einer Hochsprache wird sehr stark abstrahiert. Es wird mir zwar viel Arbeit abgenommen, aber damit auch der Blick auf's Detail. Da ich beim AVR aber am Detail (an der Hardware) programmiere, möchte ich darauf nicht verzichten. ASM ist eindeutig, bei einer Hochsprache lauert überall ein "ja, aber". In ASM fühle ich mich halbwegs sicher, in einer Hochsprache fühle ich mich verarscht, es gibt zu viele "Nebenwirkungen". Um das gleiche, was ich in ASM mache, in einer Hochsprache machen zu können, müsste ich diese Hochsprache schon verdammt gut beherrschen. Und das ist mir einfach zuviel Aufwand, mit Sprachen lernen tu ich mich sehr schwer. Das ist halt nicht jedermanns Sache. Jupp, es steht Dir aber frei, mich auszulachen, weil mir (mir persönlich) C zu kryptisch ist. Ich habe damit kein Problem. ...
Hannes Lux wrote: >> Ich habe mich daher vor dem Aufwand gescheut und entweder C oder >> Assembler geschrieben > > Also ist C doch ein paar Nummern komplexer, als hier immer behauptet > wird? Du hast mich völlig falsch verstanden. Ich habe mich nur davor gescheut, beides zu vermanschen. Ich mache jetzt fast nur noch C, geht einfach viel schneller zu schreiben. > in C > müsste ich Lotto spielen, dazu habe ich weder Lust noch Nerven. Wie kommst Du bloß darauf ? Ich kenne keinen C-Programmierer, der sich als Lottospieler ansieht. Als Assemblerfreak ist es auch kein Problem, sich zu Anfang den Output anzusehen, ob man es in C richtig gemacht hat. Allerdings sollte man erstmal aufm PC die C-Grundlagen ausprobiert haben, geht mit dem Debugger doch viel einfacher, als aufm MC. Peter
>Jupp, es steht Dir aber frei, mich auszulachen, weil mir (mir >persönlich) C zu kryptisch ist. Nein, ich möchte dich doch nicht auslachen, jeder hat halt andere Vorlieben. Ich hab auch mit Assembler angefangen und zwar deshalb, weil die ersten µCs, mit denen ich zu tun hatten, einfach noch keinen nennenswerten SRAM hatten und es auch gar keine freien C-Compiler gab. AT90S1200 und PIC16C(F)84 sei hier als Beispiel genannt. Aber mitlerweile sind die ATtinys und ATmegas so günstig und leistungsfähig und die Compiler wirklich brauchbar, dass ich auf Assembler getrost verzichten kann. Wenn ich mir vorstelle, CDC oder gar HID in Assembler zu programmieren...nein Danke. Dann mache ich es lieber in C und bin dreimal so schnell fertig und kann die restliche Freizeit genießen. Ich meine, es gibt auch Leute, die ganze Textverarbeitungen für Windows in Assembler schreiben. Schön, wenn jemand nichts anderes zu tun hat?!?
Lieber Hannes, wer hat Dir denn diese Schauergeschichten über C erzählt? > In einer Hochsprache wird sehr stark abstrahiert. Das mag für C++ gelten, aber keineswegs für C. Ich arbeite seit Anfang der 80er mit C und meine Meinung darüber ist bis heute unverändert: C ist ein Highlevel-Assembler Mit etwas Erfahrung weiß man recht genau, welchen Maschinencode der Compiler erzeugen wird - und daß der Compiler die ganzen Futzelarbeiten deutlich zuverlässiger und schneller ausführt, als der versierteste Assembler-Fuchs. Wenn man sich sehr gut in Assembler auskennt, ist die Lernkurve sehr steil; wenn man C-Programme mit einem kombinierten Quelltext- und Maschinencode-Debugger ablaufen läßt, gehts sogar noch schneller. Und die Parameterübergabekonventionen sind so einfach, daß man selbst im Frühstadium von Alzheimer damit zurecht kommen sollte, wenn man vorher kräftig Assembler geübt hat ;-) @Peter: > In der Regel erzeugen Compiler nicht lokalisierten Code, d.h. die > Code und SRAM-Adressen löst erst der Linker auf. Na ja, das ist aber ein komische Assembler-Stil, bei dem der Programmierer die Speicheradressen von Hand vergibt - einen Assembler braucht man dafür eigentlich nicht - ein Hex-Editor reicht da voll und ganz. Tatsache ist, daß größere Assembler-Programme üblicherweise aus mehreren Quelltext-Modulen zusammengesetzt werden und der Linker macht genau das, was er immer macht: Er wandelt die symbolischen Adressen in absolute um. Ob dabei ein Modul, den der Linker in das ausführbare Programm einbaut, aus dem Assembler kam, oder aus einem C- oder C++ - Compiler, ist völlig gleichgültig, so lange die Schnittstellen richtig gehandhabt werden.
Assembler ist ok solange du kleine überschaubare Programme hast, und nur einen Typ µC verwendest. Sobald du eine Codegröße von etwas 2 Kb überschreitest wird es sehr schnell sehr unübersichtlich. C-Code ist übersichtlicher , und wenn du dich etwas damit beschäftigt hast WIE du etwas in C programmierst, kommt da ein asemmblercode raus der deinem von HAND programmierten in nichts nachsteht. Wechselst du den µC, sogar innnerhlab einer µC Familie, musst du die Assemblerprogramme von Hand anpacken und Adressierungen, Sprünge, Befehle,.... anpassen. Schreibst du in C, tauschst du für eine andern µC die Headerdatei mit den Adressen(ROM, RAM Start und Endadresse, IRQ Vektor, Registeradressen) und die Compilesettings aus, lässt neu compilieren und fertig. In C musst du dich um die Speicherverwaltung nicht kümmern. Das heiß wo eine Variable im Ram steht, wie die Zugriffe darauf erfolgen macht der Compiler, du kannst dich um die Programmlogik kümmern. Christian: Du solltest dich mal mit C beschäftigen, nur auf Assembler zu setzen ist doch sehr einseitig. Und es gibt auch freie C-Comiler die für den PIC genutzt werden könnene. zb.: SDCC
Uhu wrote: > @Peter: >> In der Regel erzeugen Compiler nicht lokalisierten Code, d.h. die >> Code und SRAM-Adressen löst erst der Linker auf. > > Na ja, das ist aber ein komische Assembler-Stil, bei dem der > Programmierer die Speicheradressen von Hand vergibt Das ist der übliche Stil, wie es MC-Anfänger machen. Ich hab im Internet noch nie was anderes gesehen. > - einen Assembler > braucht man dafür eigentlich nicht - ein Hex-Editor reicht da voll und > ganz. Das ist doch nicht Dein Ernst. Hast Du alle Codes im Kopf und rechnest Sprünge und Calls selber aus ? > Tatsache ist, daß größere Assembler-Programme üblicherweise aus mehreren > Quelltext-Modulen zusammengesetzt werden und der Linker macht genau das, > was er immer macht: Er wandelt die symbolischen Adressen in absolute um. Tatsache ist, daß ich größere Programme grundsätzlich komplett in C schreibe. Ich bin allerdings nur ein Hobby-Programmierer, der hauptsächlich Hardware entwickelt, wo auch mal MCs drin sind. > Ob dabei ein Modul, den der Linker in das ausführbare Programm einbaut, > aus dem Assembler kam, oder aus einem C- oder C++ - Compiler, ist völlig > gleichgültig, so lange die Schnittstellen richtig gehandhabt werden. Sehr schön ist das beim Keil C51, wo die Schnittstellen je nach Memory-Modell und Compiler-Optionen unterschiedlich sind. Ne, geh mir weg, dazu ist mir meine Zeit einfach zu schade, sie mit solchem Unsinn zu verplempern. Auch kann der C51 dann keine objektübergreifende Registeroptimierung mehr durchführen. Wenn C, dann einfach alles in C und gut is. Peter
@Christian: Ich denke, die beste Lösung wäre der fertige 5€-Chip mit verfügbaren Windows-Treibern - zumindest, wenn Du keine Serienproduktion anfangen willst. Die zweitbeste Lösung wäre, den vom C-Compiler erzeugten Modul in Dein Assembler-Programm einzubinden - inclusive der C-Runtime-Bibliothek. Wie man die Funktionen aus dem Modul aufruft kann man auf verschiedenen Wegen herausfinden: Anaphabeten schreiben ein kleines C-Programm, das nur die Aufrufe enthält und sehen sich an, was der Compiler daraus macht und äffen das dann in ihrem Asm-Programm nach, während Cegastheniker ins Compilerhandbuch gucken und nach dem Kapitel über die Parameterübergabekonventionen suchen. Das mit dem PC-Treiber selber schreiben, schlag Dir mal aus dem Kopf; das überstiege die Komplexität Deines gesamten bisherigen Lebenswerkes um Größenordungen.
Angehängte Dateien:
-
programmierer_binary.gif
14 KB
> /funein > Echte Progammierer programmieren nur in Assembler :o))) Neeeee.... Echte Programmierer programmieren Binär! > /funaus
Hallo Leute, zunächst mal muss ich mich bei UHU entschuldigen, die weiteren Kommentare von Dir waren sehr gut und versiert. Ich will kurz erklären, was mich dazu veranlasst, lieber in Assembler zu programmieren. Es ist tatsächlich so, dass ich ein wenig C-Erfahrung habe, aber auf anderen Prozessoren, sprich x86 mit WIN-API. Allerdings sind meine µP-Programme immer recht klein gewesen, also ich glaube mein größtes Programm war 4kB. Meistens bewege ich mich aber unterhalb von 2kB. Ich scheue mich einfach davor C für PIC zu lernen, wo ich mich doch in Assembler recht sicher fühle und ich auch bisher nur selten etwas portieren musste. Den C-Compiler hätte ich zur Not auch gekauft, allerdings habe ich den Eindruck, dass ich mit dem Preis von ca. 600€ pro Lizenz eher die komplette MPLAB-IDE sponsore, die ja frei verfügbar ist. Ich werde den nämlich sicher länger als 60 Tage verwenden wollen ( das ist die Zeit, die die Demo-Version lauffähig ist). Und ... sich selbst zerstörende Programme ;-) installier ich nicht gern auf meinem PC. Daher finde ich es schade, dass es den CDC nicht als in Assembler einbindbares Projekt gibt, wohingegen der Custom-Treiber in Assembler ist. Der aber wirklich wohl nur für USB-Gurus taugt. Gruß Christian
@Peter: > Das ist der übliche Stil, wie es MC-Anfänger machen. > Ich hab im Internet noch nie was anderes gesehen. Das beruht wohl eher auf einem Mißverständnis Deinerseits über die Funktionsweise eines Linkers. Assembler erzeugen üblicherweise wenigstens drei Typen von Adressen: - Absolute: z.B. Peripherie- oder Interruptvektor-Adressen - Segmentrelative: die bestehen aus einer Segmentreferenz, dem symbolischen Namen und weiteren Informationen - Commonblock-Adressen Das passiert selbst dann, wenn das ganze Programm nur aus einem einzigen Quelltextmodul besteht. Der Linker baut aus den Eingabemodulen die Segmente zusammen - indem er für jedes Segment Code/Daten der einzelnen Module einfach hintereinandersetzt. Dann werden die Segmente angeordnet, sofern sie verschieblich sind und zum Schluß werden die absoluten Adressen der Symbole berechnet. In einem zweiten Durchlauf werden dann die relativen Referenzen in absolute umgewandelt und in Code/Daten eingetragen. > Das ist doch nicht Dein Ernst. Hast Du alle Codes im Kopf und > rechnest Sprünge und Calls selber aus ? Aber klar doch, ist das mein Ernst: Wenn man Assemblerprogramme schreibt, in denen alle Adressen absolut sind, dann kommt man ums Rechnen sowieso nicht herum. Wer so beknackt arbeitet, der braucht keinen Assembler, denn sein Programm ist weder pflegbar, noch auch nur innerhalb der Prozessorlinie, für die es geschrieben wurde, portabel. Von Lesbarkeit ganz zu schweigen. Wenn so einer einen Assembler benutzt, statt dem Hexeditor, dann ist er ein absolutes Weichei und soll sich was schämen. > Sehr schön ist das beim Keil C51, wo die Schnittstellen je nach > Memory-Modell und Compiler-Optionen unterschiedlich sind. Auf der x86-Linie ist das nicht anders. Dafür benutzt ein Assemblerexperte dann Macros, die je nach Speichermodell die passenden Codesequenzen absetzen. Die Assemblertechnologie war schon lange vor dem Aufkommen von Fortran, Cobol und Algol-60 sehr weit entwickelt und gerade die Macrotechniken waren so ausgefeilt, daß man damit eine sehr hohe Effizienz erreichen konnte. Sieh Dir mal dem MASM von M$ an - der hat viele dieser Techniken eingebaut, nur benutzt sie heute keiner mehr und das Wissen darüber stirbt langsam aus.
Hallo, @feadi: genauso isses! Und nehmen auch keinen PIC sondern einen Z80 mit PIO, SIO und statischem Speicher ;-) Die Codetabelle in der Linken, den Taschenrechner (auf hex geschaltet) für die Adressen in der Rechten. LOL Gruß Christian
> Die Codetabelle in der Linken, den Taschenrechner (auf hex geschaltet) > für die Adressen in der Rechten. Nein, falsch: In der Rechten halten sie eine Zigarette und mit dem linken Zeigefinger wird getippt. Die Codetabelle haben sie im Kopf und den Hex-Rechner auch -- selber schon gesehen!
Ralph schrieb: > Du solltest dich mal mit C beschäftigen, nur auf Assembler zu > setzen ist doch sehr einseitig. Die Umkehrung gilt genauso. Gerade bei hardware-naher Programmierung sind Assemblerkenntnisse für C-Programmierer sehr wertvoll. Ich selbst habe schon die Ursache für so manchen Programmfehler mit einem schnellen Blick ins Disassembly-Fenster des Debuggers gefunden, an dem ich anders wohl einige Zeit genagt hätte...
Christian: "Ich würde gern in Assembler programmieren, da ich hierbei gut die Laufzeiten abschätzen kann" Nur was kannst du da wirklich abschätzen? nimm zb eine IRQ routine. Du hast die routine in assmbler geschriben und ausgrechnet das sie (nur um mal eine Zahl zu nennen) 25 Taktzyklen benötigt. Gut, du weißt jetzt wie lange die Routine benötigt. Und jetzt kommen die Unbekannten ins Spiel. + Wie viele Taktzyklen werden benötigt um in die IRQ routine zu springen ? ( bei PIC sind es glaub ich 6 oder 7, aber bin nicht ganz sicher) + Wie viele Taktzyklen werden benötigt um vm IRQvektor zur richtigen IRQ routine zu springen ? ( der PIC hat nicht allzuviele IRQ vektoren) + Wie lange sind in der MAIN Schleife die IRQ gesperrt weil etwas läuft das nicht unterbrochen werden darf ? Also du weißt IRQ benötigt 25 Taktzyklen + 6 zum Einsprung in IRQ + n ( können leicht in die 100 gehen)Taktzyklen mit warten Ausführung deiner Routine. Also eine sehr präzise Abschätzung ...... Bei einer Funktion die in der Main läuft ist es noch schlimmer. Möglicherweise wird sie nicht unterbrochen, vieleicht von einem IRQ vielleicht von mehreren IRQ. Also Laufzeitabschätzung fast unmöglich. Ok die Nettolaufzeit deiner Routine kannst du immer ausrechnen, nur die Nettolaufzeit nutzt dir nichts. Du brauchst die Bruttolaufzeit, das heißt mit allen möglichen Unterbrechungen und Verzögerungen. Wenn du also deinen µC nach den berechneten Nettolaufzeiten auswählst, wirst du garantiert große Probleme bekommen. Je kritischer das zeitverhalten deiner Anwendung ist, desto mehr Reserve musst du in der µC Auslastung frei haben.
Zudem kann man die Nettolaufzeiten von C-Routinen genauso bestimmen: Man rechnet die Ausführungszeiten der einzelnen Befehle zusammen - die gibt praktisch jeder Compiler auf Wunsch aus - sofern man nicht sogar die Zyklenzahlen direkt bekommen kann. Ein Problem - neben ISRs - hat man allerdings: Es gibt Befehle, die je nach Daten verschieden lange brauchen - z.B. bedingte Sprünge. Dieses Problem hat der Asm-Programmierer aber auch, wenn der Prozessor solche Befehle hat...
Uhu: Niemand hat behauptet das er Assembler vergessen soll. Man muss um vernünftig arbeiten zu können assembler lesen und nachvollziehen können. Ohne das ist die Arbeit mit dem Debugger nahezu unmöglich. Und welcher Wert ein Debugger hat, ist wohl unumstritten. Nur in assmebler zu programmieren ist meiner Meinung nach viel zu umständlich und langsam. Es gibt auf einigen µC Registerzugriffe die nur per Assembler machbar sind, ok hier reichen ein paar Zeilen INLINE Assembler. In der Diskussion Assmbler oder C muss man eigentlich doch nur das Ziel des Projektes festlegen, dann ergibt sich die Antwort von allein. + Schreibt man die software um zu zeigen das man es kann ==> Assembler und dann eine Stunde eigene Schulter klopfen + Schreibt man die Software um zb eine Temperatur Regelung im Aquarium zu realisieren, dann ist die Software mittel zum zweck ==> C als Vergleich zur nicht Softwarewelt. Du bist in München und willst nach Hamburg a) du gehst zu Fuß weil du es kannst und nur so den kürzesten Weg (Luftlinie) nutzen kannst b) du fährst mit dem Auto, es sind vielleicht ein paar KM mehr, aber es geht viel schneller
Uhu wrote: > @Peter: >> Das ist der übliche Stil, wie es MC-Anfänger machen. >> Ich hab im Internet noch nie was anderes gesehen. > > Das beruht wohl eher auf einem Mißverständnis Deinerseits über die > Funktionsweise eines Linkers. Lies bitte richtig: Ich schrieb nicht "wie ich es mache", sondern "wie man es im Internet sieht" ! Sogar die Atmel, Intel und Philips Beispiele sind absolut adressiert. Wie ein Linker funktioniert, brauchst Du mir nicht zu erklären, ich benutze doch C. Ich hab auch schonmal einen C-Code nach Assembler übersetzt, um zu sehen, welcher Wasserkopf da erzeugt wird, damit alles relativ, extern und public ist. Ich habe aber trotzdem keine Lust, C mit Assembler zu mixen und auch nicht die Notwendigkeit. Ich weiß, wie es geht (einfach ne C-Dummy-Funktion nach Assembler übersetzen und dann den Assembler einfügen), aber wie gesagt, mir sind der Aufwand und die Nachteile zu groß. > Aber klar doch, ist das mein Ernst: Wenn man Assemblerprogramme > schreibt, in denen alle Adressen absolut sind, dann kommt man ums > Rechnen sowieso nicht herum. Quatsch, da muß man überhaupt nichts rechnen. Sprungmarken kann man auch in absoluten Code verwenden und die Variablen werden zu Anfang aufsteigend absolut positioniert:
1 | dseg |
2 | org 30h |
3 | var1: ds 1 |
4 | var2: ds 1 |
5 | ... |
6 | stack: ds16 |
7 | cseg |
8 | org 0000h |
9 | jmp init |
10 | ... |
11 | init: |
12 | ... |
Peter
>In der Diskussion Assmbler oder C muss man eigentlich doch nur das Ziel >des Projektes festlegen, dann ergibt sich die Antwort von allein. Ehrlich gesagt verstehe ich nicht was es da ueberhaupt zu diskutieren gibt. Im Hobbybereich (Altdeutsch: Liebhaberei) sollte doch jeder genau das machen was ihm Spass macht. Genau deshalb programmiere ich seit 20 Jahren in Assembler, auch jenseits von 8K ;) Hoeher, schneller, weiter... hab ich dabei nicht noetig. Ich muss schliesslch Niemandem etwas beweisen. just my 2 cents. juergen
Hallo liebe Leute, ich wußte gar nicht, dass ich in so ein Wespennest steche mit meiner Vorliebe für Assembler. Um Gottes Willen, ich will doch nicht die C-Programmierer diffamieren, ich hab doch selbst mein Geld damit verdient. Die Frage ist doch nur, wie ich meinen PIC programmieren will. Und dafür erscheint mir beim Umfang meines Programms und Wissens Assembler als die beste Lösung. C für PIC müsste ich erst lernen, und wenn ich es dann kann ist mein Compiler abgelaufen und "läuft nur noch auf 3 Pötten". Ne ne, kommt mir nicht ins Haus. Schönen Gruß Christian
@Peter: Und was ist daran absolut adressiert? > jmp init > ... > init: Garnichts. init ist eine symbolische Adresse. Das ORG 0 macht das Segment absolut und damit hat der Entwickler des Sprachpaketes die Wahl, ob der ASM die Relokation durchführt, oder ob der Linker - der das sowieso können muß - dafür zuständig ist. Letzteres wäre die aus Entwicklersicht ökonomischere Lösung, ersteres die zur Laufzeit schnellere. Daß das Problem nicht allgemein vom ASM lösbar ist - was stark für die generelle Lösung per Linker spricht -, zeigt folgendes Szenario: Modul 1: ORG 0x0000 extern init .... jmp init Modul 2: ORG 0x01000 public init ... init: ... Obwohl es sich um zwei absolute Segmente handelt, muß der Linker den 'jmp init' modifizieren, damit die Module zusammenpassen. @jjk: > Im Hobbybereich (Altdeutsch: Liebhaberei) sollte doch jeder genau > das machen was ihm Spass macht. Findest Du es nicht schön, wenn dabei so nebenbei etwas mehr, als nur ein solides Halbwissen rauskommt?
>@jjk: >> Im Hobbybereich (Altdeutsch: Liebhaberei) sollte doch jeder genau >> das machen was ihm Spass macht. >Findest Du es nicht schön, wenn dabei so nebenbei etwas mehr, als nur >ein solides Halbwissen rauskommt? Interessante Argumentation ;) Ich bin zutiefst beeindruckt wie gut Du mein Wisssen einschaetzen kannst obwohl ich Deiner Logik nicht ganz folgen kann. Muss ich aber auch nicht. juergen
@ Christian: > ich wußte gar nicht, dass ich in so ein Wespennest steche mit > meiner Vorliebe für Assembler. Nimms leicht... mir kommt das zuweilen auch vor, als würden sich Esel und Langohren gegenseitig bekämpfen. Für winzigkleine Hobby-Projekte ziehe ich auch ASM vor - macht einfach Spaß! Bei größeren Sachen, oder gar im Beruf geht das einfach nicht. Diejenigen, die das hier hobbymäßig betreiben, sind in der Beziehung natürlich keinen Zwängen unterworfen. Denen, die mit dem Gedanken spielen, beruflich in das Fach einzusteigen, empfehle ich sogar, mit ASM und einem ganz kleinen Prozessor zu beginnen - man lernt damit, wie das Maschinenmodell eines Prozessors funktioniert und dem Größenwahnsinn ist ein physikalischer Riegel vorgeschoben. Im Studium wird man von ASM nicht mehr viel mitbekommen, da kann man sich mit dem Hobby-Wissen einen 'Zugang von der anderen Seite' verschaffen, der im Zweifelsfall sehr nützlich sein kann.
Hallo liebe Leute, es kommt darauf an, was Gegenstand der Diskussion ist: die Frage, welche Programmiersprache die Beste ist - darüber kann man sich bis aufs Blut streiten- , oder doch was jeder für sich persönlich am Besten kann. Wenn man sich für den µP interessiert und dessen Arbeitsweise verstehen möchte ist Assembler eindeutig die Sprache der Wahl. Dieser Weg ist auch nicht unbeding der langsamste ( Fußgänger zu Auto ). Wenn ich den Prozessor samt seiner Register etc. kenne, kann ich aus Assembler programmieren. Zumal die PICs ja RISC sind, da muss man sich nicht so viele Befehle merken ;-) Gruß Christian
@jjk: Hab ich das auf Dich bezogen? Kommt mir eher nicht so vor...
Uhu wrote: > @Peter: > Und was ist daran absolut adressiert? > >> jmp init >> ... >> init: > > Garnichts. init ist eine symbolische Adresse. Doch. Absolut adressiert ist, wenn der Assembler schon die richtigen Adressen einträgt. Relativ adressiert ist, wenn er erstmal 0x0000 einträgt und dann der Linker ranmuß, um das aufzulösen. Perse müssen Programme, die aus mehreren Modulen bestehen, relative Adressen enthalten, da ja der Assembler Module getrennt übersetzt. Außerdem muß man den Assembler per extern/public besänftigen, sonst geben die nicht aufgelösten Adressen nen fetten Error. Aber wie gesagt, viele MC-Beispiele im I-net bestehen nur aus einem Modul und daher auch nur aus absoluten Adressen. Z.B.: http://www.nxp.com/files/products/standard/microcontrollers/download/80c51/examples/music750.asm http://www.atmel.com/dyn/resources/prod_documents/AADC.EXE Peter
Uhu: >@jjk: >Hab ich das auf Dich bezogen? Kommt mir eher nicht so vor... Ich hatte Ralph zitiert ;) juergen
Hallo liebe Leute, wie sieht es denn nun aus? Wenn ich mal Bilanz ziehe wurden mir 3 Möglichkeiten angeboten um mein Projekt zu realisieren: 1) C für PIC lernen -scheidet aus wegen Ablauf nach Zeit. 2) PIC ohne USB nehmen und UART-USB-Baustein anlöten -damit wäre mein schönes Layout dahin, war doch froh, dass es so schön einfach war und mit nur einem Layer auskam 3) CDC Firmware compilieren und mit den Objekt-Files im Assembler weiterarbeiten 3) ist für mich bisher die Beste Wahl. Was muss ich also tun, als "C-für-PIC-Ahnungsloser"? Gruß Christian
"1) C für PIC lernen -scheidet aus wegen Ablauf nach Zeit. " C ist auf jedem µC das gleiche, DAS ist ja der Vorteil von C. Also wenn du C kannst, dann kannst du auch C-Code für den PIC schreiben. Die unterschiede muss nur der Compiler kennen der aus dem C-Code den Assemblercode erzeugt. und zu Zeitablauf: Verwende den SDCC Compiler, der ist opensource und kann auch Code für den PIC erzeugen.
Hallo, @Ralph: ist dann dieser SDCC auch in der Lage mit der speziell für den C18 geschriebenen Firmware etwas anzufangen? Was muss ich beachten? Gruß Christian
@ Christian: Gleich vorweg: Ich kenne den SDCC nicht aus eigener Anschauung, kann also nur generelle Tipps geben. > ist dann dieser SDCC auch in der Lage mit der speziell für den C18 > geschriebenen Firmware etwas anzufangen? Was muss ich beachten? Aber ja. C ist genormt und die wenigen compilerspezifischen #pragmas und Optionen, in denen sie sich unterscheiden, kann man i.d.R. durch aufmerksames Lesen und Vergleichen der Handbücher finden und anpassen. Ob es sich um Firmware oder irgend ein Ballerspiel handelt, ist dem Compiler völlig Schnuppe; dem kommt es nur auf korrektes C an. Ob der SDCC für Deinen Zweck geeignet ist, stellt sich sehr schnell heraus. Die Frage ist, ob Du die von Deinem ASM erzeugten Module mit denen des Compilers überhaupt zusammenbinden kannst - also ob die Formate der Moduldateien kompatibel sind. Am einfachsten bekommst Du das heraus, indem Du ein kleines C-Programm schreibst, etwa mit folgendem Inhalt:
1 | void test() { |
2 | // Dies ist eine Funktion, die nicht macht.
|
3 | }
|
Dann schreibst Du einen ASM-Modul, in dem Du test etwa folgendermaßen - entsprechend den Vorschriften des Assemblers natürlich - als extern vereinbarst:
1 | extrn _test |
2 | call _test |
Der Unterstrich wird von C-Compilern üblicherweise vor den Namen gesetzt. Dann versucht Du Deinem Linker zu erklären, daß er den C-Modul zu Deinem ASM-Modul binden soll. Wenn er dabei mit einer Fehlermeldung über einen inkompatiblen Objektmodul aussteigt, oder sonst wie ausrastet, kann man diesen Weg höchstwahrscheinlich abhaken. Du könntest dann nachsehen, ob der Compiler vielleicht einen ASM mitbringt, der Deine ASM-Syntax versteht - wenn ja, hast Du gewonnen. Mach das erst mal und poste ggf. die Fehlermeldungen - dann werden wir weiter sehen...
Christian: Ich hab den SDCC bisher nur für 8051 er benutzt, hab aber gesehen das er auch eine Configuration für PIC enthält. Als IDE verwende ich da "Code:Blocks" Welchen Umfang der SDCC für PIC unterstützt kann ich dir nicht sagen, du kannst es aber auf der Homepage des SDCC leicht rausfinden. Dort gibt es ein Forum bei dem auch die Entwickler des SDCC erreichbar sind.
Schön das sich jeder dritte Thread in die Streitigkeit von Programmiersprachen entwickelt. C oder Assembler ---> Ihr solltet euch langsam entscheiden, es kann schließlich nur einen geben!
Ich nehme grundsätzlich nur LISP, es gibt nichts besseres und vor allem ist es schön kryptisch.
Hallo liebe Leute, so wie es aussieht kommt man bei der CDC-Firmware wohl nicht um C herum. Ginge es nur um Funktionsaufrufe, hätte man sicher auch mit Kenntniss der Schnittstelle, mit den Objekt-Files weiterarbeiten können. ABER: Es gibt dermaßen viele C-Makros im CDC, die erstmal umgeschrieben werden müssen, dass die Sache richtig in Arbeit ausartet. Notgedrungen werde ich wohl mal C für den PIC lernen. Genaugesagt den Umgang mit den Bibliotheken und Direktiven des Compilers. Zum Kampf der Sprachen: Was ist eigentlich aus Modula geworden? Achja, C++ mag ich überhaupt nicht. Und Java: pfui!! Gruß Christian PS: Nicht alles zu Herzen nehmen, es ist nicht so ernst!!
Erstens mal: Das es die Sache nur in C gibt, hat auch einen guten Grund, abgesehen davon dich zu ärgern: 1. Das ganze ist vermutlich komplexerer Natur. Und die Programmierer bei Microchip wollten auch nicht jahrelang dran arbeiten. Mit C entwickelt sichs einfach schneller, also wird das genommen. 2. die Software Entwickler benutzen zu 99% auch C, weil sie damit eben ihre Projekte schneller fertig bekommen, und weils portabel und übersichtlich ist. Man stellt eben seine Bibliotheken für die Hauptzielgruppe, und nicht für Randgruppen bereit. Sonst müsste man noch ne Bibliothek für Pascal und sonstiges entwickeln ... Außerdem lohnt sichs für Microchip wohl kaum viel Arbeitszeit (und damit auch Geld) in etwas zu stecken, was vermutlich keiner benutzt. Das eigentliche Problem ist doch, dass der C-Compiler Geld kostet. Nunja, die Firmen wollen halt auch Geld verdienen, und für Firmen ist der Compilerpreis eher gering. Fürs private Vergnügen aber halt doof. Da gibts dann noch die Möglichkeit einen frei verfügbaren Compiler zu nutzen (kenn mich bei PIC aber nicht aus) und notfalls die Plattform zu wechseln. Oder halt doch einen FT232 nehmen und sich das ganze sparen.
Uhu wrote: > Im Studium wird man von ASM nicht mehr viel mitbekommen, da kann man > sich mit dem Hobby-Wissen einen 'Zugang von der anderen Seite' > verschaffen, der im Zweifelsfall sehr nützlich sein kann. Blödsinn! pumpkin
@pumpkin: Ich nehme mir mal die Zeit, Deine wohlformulierten Argumente zu widerlegen: Quatsch... (Bin übrigens und tatsächlich voll und ganz Uhu's Meinung)
Hallo,
ich muss sagen, dass ich im Studium eine ganze Menge µP-Technik und auch
Assembler mitbekommen habe. Allerdings war das vor 10 Jahren
@Matthias
>Außerdem lohnt sichs für Microchip wohl kaum viel Arbeitszeit (und damit
auch Geld) in etwas zu stecken, was vermutlich keiner benutzt.
Also wenn USB für eine Randgruppe ist, dann weiß ich es auch nicht mehr.
Das Problem ist ja, das den heutiogen PCs fast jegliche
Legacy-Schnittstellen fehlen.
Übrigens was denkwürdig ist: Die Firmware für eine richtige
Treiberentwicklung (Custom-Treiber) für ein Gerät, dass sich z.B. nicht
als virtueller COM-Port ausgibt, ist komischerweise in Assembler
geschrieben.
Da ich mich aber auf Windows-Ebene - und den damit verbundenen
Verpflichtungen der Pflege neuer Versionen - nicht so weit herunter
wagen will, nutze ich die COM-Emulation.
Grundsätzlich ist der USB-Bus eine Krux für Entwickler. Wenn man es
recht einfach wünscht, kann man sich für eine RS232/COM - Emulation
entscheiden. Damit unterliegt man aber einigen Einschränkungen, etwa,
dass der Benutzer händisch einen COM-Port vergeben muss und die
geringere Datentransferrate.
Möchte man aber ein richtiges USB-Gerät bauen, dann wird es richtig
schwierig: Erstmal 500 Seiten USB-Spec verstehen, dann
Windows-Treiber-Programmierung und API-Programmierung sowie natürlich
auch die USB-Firmware des µP.
Gruß
Christian
Nochmal zur Anfangsfrage: Nimm den PIC C18 Compiler ! Die Einschränkungen nach 60Tagen sind kaum relevant. Ich benutze den beruflich den C18 Compiler und habe von den Einschränkungen bisher nichts gemerkt. Zumindest der freie TCP/IP-Stack von Microchip lässt sich damit problemlos verwenden. Ich habe zwar auch die Vollversion des Compiler im Schrank liegen, habe die aber bisher noch nie installiert.
naja, viel installieren brauchst du da nich. es hängt alles an einer kleinen datei. und sieh wie lang 60 tage werden können...
Thread beobachten
Seitenaufteilung abschalten
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.