www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik 1k Grenze umgehen


Autor: Chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich nehme mal an die Grenze laesst sich mit einer entsprechenden Lizenz 
erweitern, was? Ansonsten schau Dich halt nach nem alternativen Compiler 
um.

Autor: timo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: E. B. (roquema) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der SDCC soll auch PIC-Controller unterstützen. Ob das taugt weiß ich 
nicht...
http://sdcc.sourceforge.net/index.php#News

Autor: Chris (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
tja... haben's die Begrenzung halt doch effektiv eingebaut, indem sie 
die groesse der Sektionen begrenzt haben, was auch das einzig sinnvolle 
ist.

Autor: Chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
...hmmm, also ich bin nach der Anleitung aus folgenden Link gegangen. 
http://www.mikrocontroller.net/attachment/15096/C_....
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

Autor: Jupp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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?

Autor: Unbekannter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> gibt es einen Compiler der nicht auf 1k Programmcode begrenzt ist.

Nein.

Alle Compiler die es auf der Welt gibt, sind auf 1k begrenzt!

Autor: Stefan B. (stefan) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Unbekannter wrote:
> Alle Compiler die es auf der Welt gibt, sind auf 1k begrenzt!

Das ist gelogen.

Autor: Stefan B. (stefan) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: 6637 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Chris,
jetzt heisst es abdruecken...

Autor: Sigint 112 (sigint)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stefan B. (stefan) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sigint 112 wrote:
> Für dich sollte es im HTML-Standard das <irony> - Tag geben.

Für dich auch ;-)

Autor: Chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
... 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.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Chris (Gast)

>ganz auf die Schnelle kann ichs mir momentan nicht leisten (finanziell),
>umzusteigen.

???
WinAVR ist kostenlos und sehr gut.

MfG
Falk

Autor: Chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  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

Autor: Chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
... 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....

Autor: Haudrauf (Klopf) (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
PIC Compiler gibt es bis zum Abwinken, auch fuer wenig Geld. Sind 100 
euro zuviel ?

Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: pic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hat der pic mehr als 1kb Speicher ?

Autor: Chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  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

Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Mark. K (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
... 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

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;)

Autor: Mark. K (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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

Autor: Michael König (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Anonymous (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie, gibt keinen gcc-pic?

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Mark. K (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Mark. K (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.