Hallo zusammen, gibt es einen Compiler der nicht auf 1k Programmcode begrenzt ist. Ich verwende den CC5X Compiler zur Programmierung von PIC´s. Danke für die Infos. Chris
Ich nehme mal an die Grenze laesst sich mit einer entsprechenden Lizenz erweitern, was? Ansonsten schau Dich halt nach nem alternativen Compiler um.
hallo, ich bin mir nicht ganz sicher, aber ich meine mal gehört zu haben, dass wenn man den quellcode auf mehrere c-dateien verteilt, die nicht größer sein dürfen als 1 k, kann die begrenzung aufgehoben werden. gruß timo
Wenn der Linker keine Begrenzung hat ist die Begrenzung auf 1000 Instruktionen pro Uebersetzungseinheit kaum wirksam, dann teilst Dein Programm nur auf mehrere Uebersetzungseinheiten auf und die Sache ist erledigt, das ist dann aber wie gesagt sehr dumm begrenzt.
Der SDCC soll auch PIC-Controller unterstützen. Ob das taugt weiß ich nicht... http://sdcc.sourceforge.net/index.php#News
Angehängte Dateien:
-
Fehler.JPG
58 KB
danke schon mal für die Tipps. ich habe mich für die Version den Code auf mehrere Dateien zu verteilen, aber so ganz will das noch nicht laufen. Zum Testen habe ich eine Datei mit dem Hauptprogramm, eine in der eine Fkt aufgerufen wird und die Hader-Datei aufgebaut. Anschließend Assambliert, bei dem auch die nötigen *.ASM Dateien entstanden sind. Bloß als ich dies zu einer .HEX zusammen fügen wollte (MPLAB), kamm ne Fehlermeldung (ANHANG) und ich weiß nicht genau was die aussagt. Vielleicht könnt ihr mir dabei helfen. Danke
tja... haben's die Begrenzung halt doch effektiv eingebaut, indem sie die groesse der Sektionen begrenzt haben, was auch das einzig sinnvolle ist.
...hmmm, also ich bin nach der Anleitung aus folgenden Link gegangen. http://www.mikrocontroller.net/attachment/15096/C_fuer_PIC.pdf. Da wird nichts über irgend welchen Zusatzbegrenzungen, ausser die 1k Umgehung, erzählt. Außerdem besteht mein Code nur aus einigen Zeilen. vielleicht könnt ihr mir konkret eine Lösung nennen wie ich trotzdem an meinem Ziel kommen könnte. Danke
>Ansonsten schau Dich halt nach nem alternativen Compiler >um. Genau nach dieser Alternative hat er ja gefragt. Was ist dir an seiner Frage jetzt unklar?
> gibt es einen Compiler der nicht auf 1k Programmcode begrenzt ist.
Nein.
Alle Compiler die es auf der Welt gibt, sind auf 1k begrenzt!
Unbekannter wrote:
> Alle Compiler die es auf der Welt gibt, sind auf 1k begrenzt!
Das ist gelogen.
Stefan "stefb" B. wrote: > Unbekannter wrote: >> Alle Compiler die es auf der Welt gibt, sind auf 1k begrenzt! > > Das ist gelogen. Für dich sollte es im HTML-Standard das <irony> - Tag geben. @Chris: Mein Tipp wäre es SDCC zu testen, eine Vollversion von CC5X zu kaufen oder gleich alles richtig zu machen und auf AVR mit AVR-GCC umzusteigen. Nur die PIC18 - Reihe ist für C wirklich gut geeignet... aber erst mit den AVRs macht C wirklich spass. Gruß, SIGINT
Sigint 112 wrote:
> Für dich sollte es im HTML-Standard das <irony> - Tag geben.
Für dich auch ;-)
... grundsätzlich wäre ich nicht abgeneigt auf AVR umzusteigen. Allerdings habe ich die gesamte Infrastruktur auf PIC´s aufgebaut und so ganz auf die Schnelle kann ichs mir momentan nicht leisten (finanziell), umzusteigen. Deshalb wäre ich euch sehr verbunden wenn ihr mir bei meinem kleinen Problem doch noch behilflich sein könnt. Ich denke das das Zusammenfügen von einigen .ASM-Dateien zu einer .HEX-Datei auf der PIC16 Basis möglich sein dürfte. Nur Wie??? In der Zwischenzeit werde ich es mit dem SDCC probieren. Mal sehen... danke noch mal.
@ Chris (Gast) >ganz auf die Schnelle kann ichs mir momentan nicht leisten (finanziell), >umzusteigen. ??? WinAVR ist kostenlos und sehr gut. MfG Falk
Hallo Falk, wie es der Name schon sagt. WinAVR ist doch nur für AVR-Mikrocontroller gedacht und nicht für PIC´s, oder habe ich da etwas falsches verstanden. ich hätte kein Problem damit WinAVR einzusetzen wenn es mit den PIC´s laufen würde und ich damit an meinem Ziel kommen würde. MfG. Chris
@ Chris (Gast) >wie es der Name schon sagt. WinAVR ist doch nur für AVR-Mikrocontroller >gedacht und nicht für PIC´s, oder habe ich da etwas falsches verstanden. Nein. Aber du hast doch in Erwägung gezogen auf AVR umzusteigen. Also Hard- und Software. MfG Falk
... na klar, aber nicht von heut auf morgen. Es braucht ein wenig mehr als nur den winavr runter zu laden und los zu legen. Außerdem hilft mir das bei meinem jetzigen Problem nicht weiter....
cc5x compiler ist auf 1K objektgröße limitiert, welche jedoch mittels unlimitiertem Linker auf größere Hexfiles zusammengelinkt werden können. Nochmals, das Limit ist 1K für obj, die Hex sind unlimitiert. Hoffe, das hilft
@ Haudrauf (Klopf) (Gast) ja 100,- ist wirklich viel Geld. ich würde gerne mit dem weitermachten was schon da ist und nicht noch zusätzliche Investitionen starten. @ chris (Gast) ich habe weiter oben eine Datei angehängt, in der gezeigt wird wo der Fehler liegt. Wie kann ich zwei .Asm Dateien zu einer .HEX-Datei zusammenfüge. Eine konkrete Lösung würde mir dabei mehr helfen. MfG. Chris
@chris hallo, leider kann ich die Datei nicht sehen, sehe nur eine Fehlermeldung, welche besagt, daß kein SHRAM (shared RAM) in der LKR datei definiert ist, nehme ich mal an, denn das shared-Ram ist 16bytes und laut linker braucht du nur 6byte, oder bräuchte der Linker die 6byte mehr, insgesamt 22 bytes ? das weiss ich nicht, da mußt du dir schon die lst datei ansehen. Jedenvalls ohne ASM/LKR, ev LST dateien keine weitere Diagnose möglich. Auch wäre der Source-Code hilfreich.
SDCC kann man glaub ich nicht in MPLAB IDE einbinden. Falls jemand nen guten Tip für nen C-Compiler hat, der sich hier einbinden lässt, dann immer raus damit ;-) Der CC5 ist schon was feines, damit kann man auch die kleinen 16Fxxx sehr schön programmieren. Wenn nur die 1k Grenze nicht wäre. Einen Umstieg von PIC auf AVR ist sicher mit größerem Aufwand verbunden. Den Aufbau einer neuen CPU (neuer Hersteller) durchzuarbeiten ist sicher nicht mal eben kurz gemacht. Was macht die AVRs im Gegensatz zu PICs besser für C-Compiler geeignet? Ist doch auch nur ne Harvard Architektur.
... also ich werde vorerst mal bei den PICs bleiben. @chris um durch mich evtl. gemachten Fehler zu vermeiden, habe ich in der Zwischenzeit mit der Anleitung die unter diesem Link beschrieben wird (http://www.cc5x.de/Crack.html) es ausprobiert. Selbes ergebnis. Die .ASM-Dateien werden compiliert bloß wenn es ans zusammenfügen zu einer HEX-Datei geht, wird der o. g. Fehler angezeigt. Gibt es evtl. Voreinstellungen die man im MPLAB machen muss?? MfG Chris
Wenn ich mir die Preise fuer die Compiler anschaue... und dann teilweise nichtmal ANSI-C und sicherlich nur fuer Windows. Naja PIC ist alleine deswegen nichts fuer mich... und dann so Krankheiten wie "far pointer" urgs... uebel ;)
Naja, für Bastler ist ein AVR sicher besser geeignet. Kostenlose C-Compiler, günstiger Anschaffungspreis,... Wenn man aber -so wie ich- Assembler mit PICs gelernt hat, dann lohnt sich die Umstellung auf AVR eben nicht. Kostet zu viel Zeit.
@ Mark. K (Gast) >Wenn man aber -so wie ich- Assembler mit PICs gelernt hat, dann lohnt >sich die Umstellung auf AVR eben nicht. Kostet zu viel Zeit. Du verweigerst dich dem Seelenheil mein Sohn. Der Satan hat dich gepackt. Gib mit deine Hand, auf dass ich dich errette! Amen. Falk
Hängt auch vom verwendeten Controller ab. Es gäbe beispielsweise PICC-Lite, das aber nur ausgewählte Controller unterstützt: http://microchip.htsoft.com/products/compilers/PICClite.php Wenn ich mich nicht irre, ist das jetzt auch beim neuen MPLAB dabei.
Soweit mir bekannt ist AVR die einzige 8-Bit Architektur, für die es eine (offizielle) GCC Version gibt. Wenn man schon auf PICs festgelegt ist: ist PIC18 auch pfui? Dessen Compiler gibts bei Microchip für lau, jedenfalls wenn man damit kein Geld verdienen will.
Wieso teilst du dein Programm nicht in mehrere c-Dateien, die werden dann extra kompiliert und jede für sich darf nicht mehr als 1k Objektgröße erzeugen. Der Linker setzt das dann zusammen. hab ich damals so gemacht, klappt bestens. asm Dateien einfach zusammen kopieren wird nicht klappen. Wenn da noch Fehler auftauchen trotz obiger Methode liegts nicht an der 1k-Grenze. Ansonsten kannst du den SDCC mit Eclipse benutzen, 10 mal besser als das MPLAB.
Wieso sollten PICs pfui sein? Wesentliche Unterschiede zwischen 16Fxxx und 18Fxxx: - 18Fxxx laufen mit bis zu 40MHz - 8Bit*8Bit Hardware-Multiplikation - RAM,Flash, EEPROM gibt es größere als beim 16Fxxx - Interne 16Bit Struktur (aber 8Bit Datenstruktur), daher können die 18er mehr Befehle verwalten. Das Bank-Umschalten entfällt hier - Umfangreichere Hardwareausstattung (z.B. CAN, USB, Motor-PWM,...) - Bis zu 80 Pins - ... Sind im Endeffekt schon einiges Leistungsstärker als die 16er - aber halt auch teuerer. Kommt immer drauf an, was man mit machen will. Für kleinere Projekte ist man mit den 16Fxxx und CC5 gut bedient. Bei umfangreichen Projekten reichen die 1k (oder mit der Umgehung auch 2k) Code (welcher beim CC5 relativ kompakt in ASM umgewandelt wird) nicht aus. Der C18 Compiler von Microchip erzeugt leider keinen solch kompakten Code. Allerdings stehen dafür ja auch PICs mit bis zu 64KB Programmspeicher im DIL Gehäuse zur Verfügung. Die Preise sind zwar etwas höher, als die der AVRs aber in der Regel benötigt der Bastler ja auch keine großen Stückzahlen. Die DSPICs sind im Gegensatz zu den 18Fxxx nochmals deutlich stärker. Leider benötigen diese schon eine Spannung von 3,3V. Der Trend geht bei Neuentwicklungen leider in diese Richtung.
Mark. K wrote: > Wieso sollten PICs pfui sein? Was die 18er angeht: Solange man auf C Ebene bleibt sind sie einigermassen ok. Nur sollte man sich nicht den vom C18 erzeugten Code ansehen, das ist schmerzhaft. Und Microchips Vorliebe für ausgiebige Erratasheets mit teils schwer bis garnicht umgehbaren Bugs teile ich nicht (hier im Vergleich zu AVR zu sehen). An sich finde ich den 18F258 ja durchaus praktisch. Klein und mit CAN drin. Nur leider die Bugs... Ok, gibt ja eine neue Version, den 18F2580. Einer der beiden dicken Bugs vom CAN Controller ist weg, hurra. Dafür sind ein paar neue dicke Bugs drin, und der zweite von den alten Bugs ist auch noch drin (Interframe-Gap, der findet sich in fast allem von Microchip, ausser MCP2515 und PIC30F601xA). Fazit für mich: der neue 2580 ist schlimmer als der alte 258, und beide sind schlimmer als ATMega168+MCP2515, auch wenn das mehr Platz braucht.
Hast du zufällig ne Bug-Liste parrat? Was bewirken die Bugs? Sie werden die Hardware wohl nicht funktionsuntüchtig machen, oder? Vom C18 bin auch alles andere als begeistert. Da ist der CC5 deutlich besser.
Mark. K wrote: > Hast du zufällig ne Bug-Liste parrat? Schon, aber Microchip hat die gleiche, und die ist nicht geheim. > Was bewirken die Bugs? Sie werden die Hardware wohl nicht > funktionsuntüchtig machen, oder? Was beim 18F258 sofort auffällt, ist der Bug in der Adressierung vom CAN-Modul. Was Restriktionen in der Nutzung der CAN-Register zur Folge hat und einige Bytes aus dem globalen RAM-Block unbenutzbar macht (mithin einen Blick ins Map-File erfordert, weil das nur Compiler und Linker entscheiden). Ein auffallend dickes Ei, aber der harmloseste Bug davon, weil relativ leicht handhabbar. Der andere gefällt mir weniger, derjenige der fast die ganze Microchip-Linie durchzieht. Wenn in der interframe gap eine Störung kommt, oder einer der Teilnehmer einen falschen Takt hat, kann der darauf folgende gesendete Frame eine defekte Adresse enthalten, ohne dass dies am Frame erkennbar ist (passende CRC). Sicher handhabbar ist das nur, indem man auf einen bestimmten Adressraum verzichtet. Was schlecht geht, wenn man sowas in ein existierendes System integriert. Beim 18F2580 wiederum sind beispielsweise die error counter defekt. Damit kann man zwar umgehen, aber um in der Hinsicht sicher zu sein, muss man mehr Tests zum Zeitverhalten des Programms unter allen Betriebszuständen machen als mir lieb ist. Wenn man sich den dann doch mal eingefangen hat ist ein Hardware-Reset fällig. Dass ein Überlauf des receivers zu einer defekt gesendeten Nachricht führen kann, auch hier mit passender CRC, ist auch nicht vertrauenerweckend. Auch der lässt sich vermeiden, aber ein workaround von der Art "Überlauf vermeiden" ist leichter gesagt als unter allen Umständen sichergestellt.
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.