Nostalgie Frage zum Elektor 80535 Board und Keil C51 Compiler

Harald K. OP #7603071
Lesenswert?
• ▲
▼

Hallo allerseits,

Ich habe kürzlich in meinem früheren Kinderzimmer mein altes Elektor 80535 Compuboard ausgegraben. Da ich ein bisschen nostalgisch angehaucht bin, wollte ich wissen, ob diesen über 30 Jahre alte Board noch läuft. Dank ein gut funktionierendem Backup Konzepts habe ich auch noch alle Sourcen von damals, inklusive aller Programme der Elektor Diskette. Die exe-Dateien laufen zwar heutzutage nicht mehr, aber glücklicherweise waren damals auch die Pascal Sourcen dabei, die ich gemeinsam im ChatGPT recht schnell nach Python konvertiert habe.

Und siehe da, das Board funktioniert noch einwandfrei. Ich habe es mit einigen Beispiel HEX Dateien (aus Assembler generiert) von damals probiert und die laufen auch.

Jetzt möchte ich den Keil C51 verwenden, um zumindest ein Hello World zum Laufen zu bringen. Und da habe ich jetzt aber ein Problem. Ich hoffe ich kann das einigermaßen erklären.

Das Board ist so aufgeteilt

1
 
ROM 0x0000 – 0x3FFF

2
 
RAM 0x4000 – 0x7FFF

3
 
ROM 0x8000 – 0xBFFF

4
 
RAM 0xC000 – 0xFFFF

Mein Code muss also an der Stelle 0x4000 starten. Die Einstellungen vom Compiler bzw Linker sind in dem Bild ersichtlich.

Das generierte HEX Programm läuft aber nicht. Der Code könnte banaler nicht sein:

1
 
#include <reg515.h>

2
 
#include <stdio.h>

3
 


4
 
void ser_init()

5
 
{

6
 
  SCON = 0x52;    /* SCON */

7
 
  TMOD = 0x20;    /* TMOD */

8
 
  TCON = 0x69;    /* TCON */

9
 
  TH1 =  0xf3;    /* TH1 */

10
 
}

11
 


12
 
int main() {

13
 
  ser_init();

14
 
  while(1) { 

15
 
    printf("Hello world\n");

16
 
  }

17
 
}

Das HEX File schaut so aus:

1
 
:0D541E0048656C6C6F20776F726C640A003B

2
 
:0D541100759852758920758869758DF32294

3
 
:0C542B0091117BFF7A54791E116280F60B

4
 
:0300000002543770                       <------   Warum hier 0000 ???

5
 
:0C543700787FE4F6D8FD75812102542B2B

6
 
:10500000E517240BF8E60517227808300702780B1D

7
 
:10501000E475F0011253B402535C2000EB7F2ED2F2

8
 
:10502000008018EF540F2490D43440D4FF30040B88

9
 
:10503000EF24BFB41A0050032461FFE51860021585

usw...

Das Problem ist die markiert Zeile. Hier will er in die Adresse 0x0000 schreiben. Vielleicht weil normalerweise das Board nach dem Einschalten hier startet. Wenn ich hier manuell 0x4000 eintrage, das manipulierte HEX File hochlade und dann das Programm an der Adresse 0x4000 starte, funktioniert es wie es soll. Aber ich finde einfach keine Einstellung, wie ich den Compiler dazu bringen kann, nicht bei 0x0000 zu starten.

Ich hoffe ich konnte mich einigermaßen verständlich ausdrücken? Vielleicht kann sich ja jemand von euch an damals erinnern und hat einen Tipp für mich?

Würde mich sehr freuen, auch wenn es natürlich nicht sonderlich sinnvoll ist 😉 Aber es sind einfach schöne Erinnerungen an meine Kindheit...

Liebe Grüße aus Wien Harald

Angehängte Dateien:
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden
Harald K. OP #7603147
Lesenswert?
• ▲
▼

Ich verwende die aktuelle Eval Version vom Keil Compiler. Ich dachte, der ist nur bei der Code Größe eingeschränkt?

Und noch mal. Es geht nicht darum, dass es Besseres gibt. Das ist mir schon klar. Ich arbeite sonst nur mit ESP32. Ich würde nur gern das alte Teil wieder zum Laufen bekommen...

Wenn ich mein Programm (das bei 0x5000 startet) manuell bei dieser Adresse starte, funktioniert es leider nicht. Irgendwas passiert scheinbar in dieser einen Zeile :0300000002543770 das wichtig ist? Ich weiß es einfach nicht...

Antwort Zitieren Bearbeiten Löschen Beitrag melden
Michael B. #7603166
Lesenswert?
• ▲
▼

Harald K. schrieb:

Wenn ich mein Programm (das bei 0x5000 startet) manuell bei dieser Adresse starte, funktioniert es leider nicht.

Wel der Initialisierungscode bei 5437 nicht ausgeführt wird.

Ab 4000 linken, bei 4437 starten sollte gehen.

Harald K. schrieb:

Alternativer C-Compiler für MCS-51:

Drecksding.

Sigint 112 schrieb:

Du musst dir für dein Board das passende Linker-Script schreiben

Wird wohl so sein. Vielleicht kann man den LJMP init auch so an den Anfang schummeln.

Antwort Zitieren Bearbeiten Löschen Beitrag melden
Harald K. OP #7603180
Lesenswert?
• ▲
▼

Peter D. schrieb:

Harald K. schrieb:

Wenn ich mein Programm (das bei 0x5000 startet) manuell bei dieser Adresse starte, funktioniert es leider nicht. Irgendwas passiert scheinbar in dieser einen Zeile :0300000002543770 das wichtig ist?

Die Zeile ist ein LJMP 0x5437, dahin mußt Du springen. An 0x5000 steht eine Unterfunktion.

Langsam mach es Sinn:

1
 
            * * * * * * *   D A T A   M E M O R Y   * * * * * * *

2
 
            REG     0000H     0008H     ABSOLUTE     "REG BANK 0"

3
 
            DATA    0008H     0014H     UNIT         _DATA_GROUP_

4
 
                    001CH     0004H                  *** GAP ***

5
 
            BIT     0020H.0   0001H.1   UNIT         _BIT_GROUP_

6
 
                    0021H.1   0000H.7                *** GAP ***

7
 
            IDATA   0022H     0001H     UNIT         ?STACK

8
 


9
 
            * * * * * * *   C O D E   M E M O R Y   * * * * * * *

10
 
            CODE    0000H     0003H     ABSOLUTE     

11
 
                    0003H     4FFDH                  *** GAP ***

12
 
            CODE    5000H     035CH     UNIT         ?PR?PRINTF?PRINTF

13
 
            CODE    535CH     008EH     UNIT         ?C?LIB_CODE

14
 
            CODE    53EAH     0027H     UNIT         ?PR?PUTCHAR?PUTCHAR

15
 
            CODE    5411H     000DH     INBLOCK      ?PR?SER_INIT?FIB

16
 
            CODE    541EH     000DH     UNIT         ?CO?FIB

17
 
            CODE    542BH     000CH     INBLOCK      ?PR?MAIN?FIB

18
 
            CODE    5437H     000CH     UNIT         ?C_C51STARTUP

Unter dieser Adresse ist das C_C51STARTUP. Aber die ändert sich halt leider mit jeder Änderung.

Jetzt muss ich nur noch herausbekommen, wie ich den Compiler dazu bringe, nicht bei 0x0000 zu starten, sondern einer von mir definierten Adresse...

Antwort Zitieren Bearbeiten Löschen Beitrag melden
Thomas Z. #7603269
Lesenswert?
• ▲
▼

es gibt in ..\keil\c51\lib\ das File STARTUP.a51. Du solltest eine Kopie davon in dein Projekt aufnehmen damit nicht die lib version benutzt wird.

Normalerweise fragt uVision beim Anlegen eines Projekts ob der startupcode dazu genommen werden soll.

In der Kopie änderst du cseg at 0 einfach in cseg at 5000h

damit wird dein Programm nach 5000h gelinkt und ist auch startfähig. Ob das mit der Demo Version geht must du ausprobieren. [c] .... EXTRN CODE (?C_START) PUBLIC ?C_STARTUP

1
 
            CSEG    AT      5000h

?C_STARTUP: LJMP STARTUP1 [/C]

Beim SDCC hättest du übrigens genau das das gleiche Problem auch der linkt per default nach 0x000.

Antwort Zitieren Bearbeiten Löschen Beitrag melden
Harald K. OP #7603342
Lesenswert?
• ▲
▼

Thomas Z. schrieb:

In der Kopie änderst du cseg at 0 einfach in cseg at 5000h

damit wird dein Programm nach 5000h gelinkt und ist auch startfähig. Ob das mit der Demo Version geht must du ausprobieren. [c] .... EXTRN CODE (?C_START) PUBLIC ?C_STARTUP

1
 
            CSEG    AT      5000h

?C_STARTUP: LJMP STARTUP1 [/C]

Danke Thomas! Funktioniert auch in der Demo perfekt!! :-)

Mein Workaround wäre diese BL51 Einstellung gewesen:

Bei Code Segments dieser Eintrag: ?C_C51STARTUP (0x4000) Hätte das eigentliche Problem nicht gelöst, aber ich wüsste zumindest wo ich das Programm starten muss...

Antwort Zitieren Bearbeiten Löschen Beitrag melden
Philipp Klaus K. #7611952
Lesenswert?
• ▲
▼

Peter D. schrieb:

Harald K. schrieb:

Alternativer C-Compiler für MCS-51:

https://sdcc.sourceforge.net/

Wird aktiv gepflegt (letzte Version ist grad' mal zwei Wochen alt)

Aber nur andere Targets. Die 8051 Portierung dürfte schon uralt sein und nicht zum Keil vergleichbar otimiert. Dabei gibt es durchaus leistungsfähige 8051, z.B. AT89LP51RD2 (20 MIPS).

Einerseits stimmt das: beim mcs51-Backend gibt es einiges Verbesserungspotential, insbesondere in der Codegenerierung. Und lange Zeit ist beim mcs51-Backend nicht viel passiert. Erst vor kurzem (zwischen SDCC 4.3.0 und SDCC 4.4.0) gab es dort wieder etwas mehr Aktivität.

Andererseits: Auch die Nutzer des mc51-backends profitieren von Verbesserungen in den maschinenunabhängigen Teilen von SDCC. Beispielsweise hat SDCC 4.4.0 halbwegs brauchbare Unterstützung aktueller C-Standards bis ISO C23, was Keil nichtmal ansatzweise versucht.

Antwort Zitieren Bearbeiten Löschen Beitrag melden
Thread beobachten

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

Bestehender Account

oder

Mit Google-Account einloggen

Noch kein Account?

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren