Forum: Mikrocontroller und Digitale Elektronik Migration von AT89C51CC03 nach AT90CAN128 - wie?


von C. L. (calle)


Angehängte Dateien:

Lesenswert?

Hallo,

Ich habe in angehangener AN-PDF Datei gelesen, das man Programme von 
AT89c51cc03 nach AT90CAN128 konvertieren kann. Dazu muss man einige 
Restriktionen einhalten.

Leider habe ich nur die Unterschiede in der PDF gelesen, nicht die 
Migration selbst.
Auch bei Atmel selbst habe ich nichts gefunden.
G***le gibt da auch nichts richtig brauchbares aus.

Hat das schon mal jemand gemacht oder weiß wie es geht?

Danke

Carsten

von Stefan W. (dl6dx)


Lesenswert?

C. L. schrieb:
> Leider habe ich nur die Unterschiede in der PDF gelesen, nicht die
> Migration selbst.
> Hat das schon mal jemand gemacht oder weiß wie es geht?

Hallo Carsten,

ich bin mir nicht ganz im Klaren, wohin deine Frage geht.
Aber falls einfach nur die Bäume den Wald verdecken:

Die Migration besteht, ganz grob gesagt, aus diesen Schritten:

0. Feststellen der Unterschiede der Zielplattform  (dafür ist die 
diff-Liste in der AN!)
1. Quelltexte anpassen (z.B. das #define für den Zielprozessor ändern, 
ggf. F_CPU und andere hardwareabhängige Makros anpassen, 
hardwareabhängige Module an die geänderten Hardwarefunktionen anpassen.)
2. Alle Module neu übersetzen.
3. Verbleibende Compile-Fehler durchsehen.
4. Wenn alles sauber compiliert und linkt, Test der hardwareabhängigen 
Module
5. Wenn man alles sofort richtig gemacht hat: Freuen.
   Wenn nicht: Gehe zurück zu Schritt 1 bis 4...

Grüße

Stefan

von Peter D. (peda)


Lesenswert?

Das CAN ist vermutlich ähnlich. Alles andere (Ports, Timer, PCA usw.) 
aber nicht.

Auch muß man beachten, daß der AVR keine 4 Interruptprioritäten hat. 
Wenn das 8051-Programm sie nicht benutzt, hat man Glück. Ansonsten muß 
man tief ins Programm einsteigen, ob es Konflikte geben kann.

Das kann also durchaus sehr aufwendig sein.


Peter

von Stefan W. (dl6dx)


Lesenswert?

C. L. schrieb:
> von AT89c51cc03 nach AT90CAN128

Was ich vergessen habe: Je nach dem für die MCS51-Plattform verwendeten 
Compiler fallen natürlich auch noch Anpassungen an die Unterschiede der 
"C-Dialekte" (Modifier für Speichermodelle etc.) an.

Peter Dannegger schrieb:
> Das kann also durchaus sehr aufwendig sein.

Du hast natürlich recht. Ich hatte übersehen, dass er nicht nur zwischen 
zwei Modellen der selben CPU-Familie migriert, sondern komplett die 
Plattform wechselt. Da könnte es sogar schneller sein, die 
hardwareabhängigen Module komplett neu zu schreiben.

Grüße

Stefan

von C. L. (calle)


Lesenswert?

Hi!

Ok, teilweise verstanden!
Glaube aber doch, das ich da noch einen Denkfehler habe, deswegen werde 
ich das nochmal konkretisieren.

IST:
Ich schreibe ein Programm für AT89C51CC03 mit uC51 C-Compiler
=> habe HEX Datei
=> 8051 Struktur

SOLL:
Konvertierung/Migration wie auch immer, so das das Programm für den CC03 
lauffähig gemacht wird, um es mit dem AT90CAN128 zu verwenden.
Vermutet habe ich ein PC Programm, welches das CC03 HEX File übergeben 
wird und raus kommt das HEX File für den AT90CAN128.
Oder in einem CC03 läuft eine Konvertersoftware die dann direkt den AT90 
flasht. Irgendsowas dachte ich. Recht primitiv gedacht!
=> AT90 RISC Struktur
=> teilweise andere Register usw.
=> nicht mit uc51 programmierbar

Stefan Wagner schrieb:
> z.B. das #define für den Zielprozessor ändern
=> der hat doch eine andere Struktur

Liege ich mit der Sichtweise denn falsch?

Danke

Carsten

von Stefan W. (dl6dx)


Lesenswert?

Hallo Carsten,

eine Umwandlung auf Binärebene oder auf der Ebene der Maschinensprache 
ist beim Wechsel zwischen zwei Prozessorfamilien (in deinem Fall von 
MCS51 zu AVR) in aller Regel nicht möglich, da sich die Befehlssätze, 
Register- und Speichermodelle und die Peripherie doch fast immer 
deutlich unterscheiden.

Eine der seltenen Ausnahmen war der 8086/8088, der von Intel bewusst so 
sehr an den 8080 angelehnt wurde, dass 8080-Assemblercode mit nur 
wenigen Änderungen übersetzbar war. (Das war aber 1979.)

C-Code kannst du in der Regel auf Quelltextebene portieren, wobei 
compilerspezifische oder hardwareabhängige Anteile angepasst bzw. neu 
erstellt werden müssen. (Aus diesem Grund sollte man alles 
hardwareabhängige in wenigen Modulen konzentrieren.)

Es läuft also auf teilweises Neuschreiben hinaus...

Grüße

Stefan

PS: Das mit dem "#define für den Zielprozessor" bezog sich auf die 
(Fehl-)Annahme, dass du zwischen zwei AVR-Modellen portieren willst.

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
Noch kein Account? Hier anmelden.