Hallo,
kennt jemand freie (oder zumindest im unteren Preisbereich angesiedelte)
Assembler/Linker-Pakete für 8052er?
Den Assembler vom SDCC hab ich versucht ans Laufen zu bringen, bin aber
an der Doku gescheitert und hab's dann relativ schnell aufgegeben (zumal
der Assembler der Doku nach das letzte Mal in den 90ern angefasst
wurde).
Der ASEM-51 von plit.de kann keinen relokatiblen Code erzeugen, das
komplette Programm muss in einer Datei vorhanden sein.
Der Phyton CodeMaster sieht soweit gut aus, mit dem beschäftige ich mich
aktuell, da muss ich noch rausfinden, ob die kostenlose Version
kommerziell genutzt werden darf (und noch ein paar technische Details
klären, z.B. ein einfacher Weg um Overlaying zu realisieren).
Alle anderen (Keil, Raisonance, etc.) haben immer ihren C-Compiler mit
dabei und den kann ich mir grad nicht leisten :)
Ralf
moin moin,
>>Der ASEM-51 von plit.de kann keinen relokatiblen Code erzeugen, das
komplette Programm muss in einer Datei vorhanden sein.
Wozu ist "relokatiblen Code" notwendig?
Reicht es nicht aus, Quellen per Include einzubinden?
>>ob die kostenlose Version kommerziell genutzt werden darf
beruflich in der Firma nutzen?
Mit Gruß
Pieter
Hi Pieter,
> Wozu ist "relokatiblen Code" notwendig?> Reicht es nicht aus, Quellen per Include einzubinden?
Ich halte nichts davon, Quellcode per Include einzubinden, das ist m.E.
unsauber.
>> ob die kostenlose Version kommerziell genutzt werden darf> beruflich in der Firma nutzen?
Für einen Bekannten, der Bauteile/-sätze vertreibt. Ein kleines
Hobbyprojekt, welches er gerne ins Programm aufnehmen möchte. Ich hätte
zwar beruflich Zugriff auf Assembler oder C-Compiler, aber die laufen
eben auf meinen AG und nicht meinen Bekannten.
Ralf
Ich würde mal versuchen z.B. bei Analog Devices oder bei Atmel
noch einem kostenlosen ASM51 zu suchen. Beide Hersteller haben
µC mit dem 51-Kern im Programm. Früher gabs solche SW gratis
vom Chip-Hersteller. Ein Intel-Vertriebler sagte vor vielen Jahren
wir wollen Chips verkaufen und keine SW.
Hallo Ralf,
>>Ich halte nichts davon, Quellcode per Include einzubinden, das ist m.E.
unsauber.
so unterschiedlich sind die Ansichten, ich wiederum halte nichts davon
irgendwas vorassembliertes einzubinden.
Was sollte daran unsauber sein?
Zumal mein Assembler dann auch keine Optimierung machen könnte und der
SourceCodeSimulator auch Probleme damit hätte.
Mit Gruß
Pieter
Nebenbei: Mein Assembler (IDE) ist Marke Eigenbau.
> so unterschiedlich sind die Ansichten, ich wiederum halte nichts davon> irgendwas vorassembliertes einzubinden.> Was sollte daran unsauber sein?
Ich hab nicht gesagt, dass ich was vorassembliertes einbinden will :)
> Zumal mein Assembler dann auch keine Optimierung machen könnte und der> SourceCodeSimulator auch Probleme damit hätte.
Inwiefern Optimierung?
> Nebenbei: Mein Assembler (IDE) ist Marke Eigenbau.
Meinst du die Kombination IDE plus ein (nicht selbst geschriebener)
Assembler/Linker oder wirklich "selbstgemacht"? oO
Ralf
> der Assembler habe ich in Delphi geschrieben
Respekt :)
Und nachdem, was ich in deinem Link gesehen habe, noch mehr Respekt!
Dagegen komm ich nicht an, und ich dachte eigentlich immer, dass ich
schon gut dabei bin.
Auf welcher Grundlage basiert dein Assembler?
Ralf
Ralf schrieb:> (zumal> der Assembler der Doku nach das letzte Mal in den 90ern angefasst> wurde).
Das ist kein Zeichen für schlechte Qualität.
Da der 8051 seit 1980 existiert, sollten doch 30 Jahre später die Tools
schon lange ausgereift sein.
Wenn etwas funktioniert, muß man es nicht mehr anfassen.
Ich benutze auch noch einen Keil C51 von 1995, läuft wie dumm.
Peter
Hallo Ralf,
hast Du auch die 03.zip geladen, da ist ein Beispiel Simulator mit
virtueller LCD drin.
Den Assembler habe ich eigendlich nur so geschrieben, wie ICH arbeiten
möchte.
Z.B. in Delphi kann man Strukturen mit allem anlegen.
In SDCC und Turbo51 geht Bit aber nur als ByteBit.Warum diese
Beschränkung.
Im MASM51 geht das dann so wie in Delphi.
Ausserdem bin ich ein Fan von Macros.
Durch die Kombination von Macros und Datenstrukturen werden auch
Assemblerprogramme kurz und übersichtlich.
Ein weitere Vorteil: wenn jemand eine gute Idee hat...kann man einbauen.
Mit Gruß
Pieter
@Peter:
> Wieviel Code willst Du denn schreiben?> Die Wickenhaeuser Demo geht bis 8kB:
Vor'm Wickenhäuser schreck ich zurück. Einerseits weil hier und in
anderen Foren gemischte Aussagen von extrem gut bis grottenschlecht
gemacht wurden, und andererseits weil ich die Doku auch nicht so gut
finde. Das Feature, dass man 24-Bit-Adressen hat, über die man andere
Speicherschnittstellen (I2C, SPI, etc.) wie normale Variablen ansprechen
kann finde ich gut (kann der Keil auch), aber was bringt das, wenn das
alles nur halblebig dokumentiert ist... Ich hab mal versucht bei WH
anzurufen und ein paar Fragen zu klären, aber bin nie durchgekommen.
Und die 8kB darf man nicht kommerziell verwenden :) Wobei der Preis mit
ca.90€ ja kein Ding wäre.
> Das ist kein Zeichen für schlechte Qualität.> Da der 8051 seit 1980 existiert, sollten doch 30 Jahre später die Tools> schon lange ausgereift sein.
Das stimmt, aber wenn dokumentiert ist, dass der Assembler mit
Doppelpunkten o.ä. in Kommentaren evtl. Probleme haben könnte, weiss ich
nicht, ob's ausgereift ist bzw. ob's nicht einfacher wäre, das Problem
zu beheben. Ich möchte keinesfalls behaupten, dass man einen
Assembler/Linker/Compiler/etc. einfach aus dem Handgelenk schreibt. Aber
wenn man schon drauf achten muss wie man Kommentare verfasst hat das
auch sicher Nebeneffekte darauf, wie man den Code schreiben
sollte/muss...
> Wenn etwas funktioniert, muß man es nicht mehr anfassen.> Ich benutze auch noch einen Keil C51 von 1995, läuft wie dumm.
Das stimmt auch. Aber seit '95 gab's doch sicherlich jede Menge
Verbesserungen & neue Features, oder?
@Pieter:
> hast Du auch die 03.zip geladen, da ist ein Beispiel Simulator mit virtueller
LCD drin.
Nein, ich schau mir das alles heut abend nochmal in Ruhe an.
> Den Assembler habe ich eigendlich nur so geschrieben, wie ICH arbeiten möchte.
Das würd ich auch gern können :)
> Z.B. in Delphi kann man Strukturen mit allem anlegen.> In SDCC und Turbo51 geht Bit aber nur als ByteBit.Warum diese Beschränkung.
Ich würd's nicht als Beschränkung sehen, eher so, dass du eine
Erweiterung gemacht hast :)
> Im MASM51 geht das dann so wie in Delphi.
Das wird die Antwort sein: Du orientierst dich an Delphi, die
(damaligen) Programmierer der Assembler-Tools orientierten sich
vielleicht an anderen Sachen (oder es gab Delphi damals noch nicht).
> Durch die Kombination von Macros und Datenstrukturen werden auch> Assemblerprogramme kurz und übersichtlich.
Müsste ich mir angucken, ob mir das auch gefällt.
> Ein weitere Vorteil: wenn jemand eine gute Idee hat...kann man einbauen.
Stimmt. Hmmmm.... Ein Linker, Overlay-Segmente und Segmente mit 24- oder
32-Bit Adressierung wären nicht schlecht :) Wobei das letzte nur Sinn
machen würde, wenn oben drüber ein C-Compiler sitzt.
Ralf
Als reines Kommandozeilenprogramm (DOS, sollte auch unter XP laufen),
ist der ASM51 von MetaLink noch immer zu empfehlen. Eine Google-Suche
nach "ASM51" fördert schnell funktionierende Downloadquellen zu Tage,
und auch Dokumentation gibt es dazu. Ich gehe davon aus, daß diese
Quellen legal sind, auch früher wurde der ASM51 von Chipherstellern
Kunden kostenlos zur Verfügung gestellt, obwohl es sich um ein
kommerzielles Produkt handelt.
Wer eine IDE möchte, dem sei J. Rathlev's MC-51 nahegelegt, läuft unter
Windows und ist eigentlich zur Zusammenarbeit mit ASEM-51 vorgesehen.
Vielleicht läßt sich das aber an den ASM51 anpassen.
Sebastian schrieb:> Nachtrag: http://john.ccac.rwth-aachen.de:8000/as/index.html
Den verwende ich für Assemblersachen auch noch. Auch ich empfehle ihn
uneingeschränkt weiter!
Ob der jedoch Objektfiles linken kann, weiss ich im Moment gar nicht.
Ich binde auch Quelltexte über Include-Files ein. Saubere Sache, meiner
Meinung nach...
Gruß,
Thomas
Also, aktueller Stand ist, dass ich mir auch mal MikroC von
MikroElektronika anschauen werde.
Desweiteren hab ich nach etwas suchen die letzte Version des originalen
Intel Assemblers/Linkers gefunden - von Ende der 80er :)
Mal schauen, ob das MikroC was taugt.
Ralf
Ralf schrieb:> Den Assembler vom SDCC hab ich versucht ans Laufen zu bringen, bin aber> an der Doku gescheitert und hab's dann relativ schnell aufgegeben (zumal> der Assembler der Doku nach das letzte Mal in den 90ern angefasst> wurde).
Schwach, wirklich. Das mache ich Ü50 noch mit links. Schämt euch, ihr
Kids.
@Wilhelm:
Das hat nix mit 'Kids' etc. zu tun. Und als alter Hase darfst du mich
gerne an deinen Erfahrungen mit diesem Assembler teilhaben lassen :)
Ralf
Ralf schrieb:> Vor'm Wickenhäuser schreck ich zurück. Einerseits weil hier und in> anderen Foren gemischte Aussagen von extrem gut bis grottenschlecht> gemacht wurden, und andererseits weil ich die Doku auch nicht so gut> finde. Das Feature, dass man 24-Bit-Adressen hat, über die man andere> Speicherschnittstellen (I2C, SPI, etc.) wie normale Variablen ansprechen> kann finde ich gut (kann der Keil auch), aber was bringt das, wenn das
Äh. Der Keil macht Unterscheidung nach CODE, XDATA usw. Kann der
Wickenhäuser echt serielle Busse transparent einbinden? Oder
verwechselst du das mit schnöden Parallel-Speicher wie beim Keil auch
vorhanden??
Würde mich mal interessieren. Denn dann müßte der Wickenhäuser ja eine
virtuelle Maschine implementiert haben. Aber wie verträgt sich eine VM
mit C ?
moin moin,
>>Schwach, wirklich. Das mache ich Ü50 noch mit links. Schämt euch, ihr
Kids.
das sagt der junge Hüpfer Wilhelm!
Als Anmerkung: Als Geburtsjahr ist in meiner Fahrerlaubnis: 1 0 6 0
eingetragen.
Mit Gruß
Pieter
> Äh. Der Keil macht Unterscheidung nach CODE, XDATA usw. Kann der> Wickenhäuser echt serielle Busse transparent einbinden? Oder> verwechselst du das mit schnöden Parallel-Speicher wie beim Keil auch> vorhanden??
Nö, ich verwechsel da nix. Ließ mal das Handbuch zum Wickenhäuser, sie
schreiben, dass man Variablen im XDATA-Bereich im Prinzip ein Extra-Byte
spendiert, um zwischen den Speichern zu unterscheiden, somit kannst du
dann SPI/I2C/etc. per Pointer separat ansprechen. Das blöde ist nur,
dass es nur rudimentär beschrieben steht. Zwar wird noch auf irgendeinen
Beispielcode verwiesen, den sie angeblich bei ihrem Webserver drauf
haben, aber den Code hab ich nicht gefunden. Und wenn man sich die
entsprechenden Lib-Sourcen dazu anschaut, in denen das "Mapping"
umgesetzt wird, wird man auch nicht so recht schlau draus, weil mit
Code-Kommentaren gegeizt wurde.
Was heisst "schnöder Parallelspeicher beim Keil"? Beim Keil hab ich
schon mal den internen EEPROM eines AT89C8252 als ganz normale Variablen
(im far-memory-Bereich) angesprochen, das ist ne feine Sache - und lässt
sich dort auch auf alle anderen Schnittstellen (auch seriell wie I2C,
etc.) umbiegen.
> Würde mich mal interessieren. Denn dann müßte der Wickenhäuser ja eine> virtuelle Maschine implementiert haben. Aber wie verträgt sich eine VM> mit C ?
Wieso VM? Es geht nur darum, dem XDATA-Bereich ein drittes (n-tes)
Adressbyte zu spendieren, anhand dessen man mehrere (parallele)
XDATA-Bereiche unterscheiden kann. Beim Keil ist es dann so, dass das
zusätzliche Adressbyte definiert, mit welcher Funktion auf den Speicher
zugegriffen wird.
Ralf
Ja genau. Kann man diese Funktionen, die durchs 3.Adressbyte
angesprochen werden, einsehen bzw. ist das genauer dokumentiert? Würde
da z.B. eine Funktion existieren, die bei i2c-Tag dann den extern
seriell angeschlossenen i2c-Baustein ansteuert, dann könnte man diesen
Baustein einfach im Adressbereich ansteuern wie RAM in einem 24-Bit
Adressbereich.
Als ich das letzte Mal mit dem Keil zu tun hatte, konnte dieser nur
CODE, XDATA, IDATA oder wie das hieß. Ist schon Jahre her. Gibts nun ein
weiteres Tag a la I2C oder SPI? Und wie wird die Bausteinadresse dann
definiert? Es können ja mehrere Bausteine dranhängen.
Oder anders gefragt: Was schickt der Compiler bei Benutzung des I2C-Tags
auf den i2c-Bus? Ist die Bausteinadresse bereits ein Datenbyte?
Abdul K. schrieb:> Oder anders gefragt: Was schickt der Compiler bei Benutzung des I2C-Tags> auf den i2c-Bus? Ist die Bausteinadresse bereits ein Datenbyte?
Der Compiler ist natürlich kein Hellseher, er kann nicht wissen, wie ein
spezieller Speicher angesprochen werden muß.
Er stellt Dir deshalb nur eine Schnittstelle zur Vefügung.
Du kannst also ein Blablub-Segment definieren und mußt dann nur ein
Blablub-read und Blablub-write schreiben und dazulinken.
Ob es auch sinnvoll ist, z.B. einen I2C-EEPROM als normalen Speicher
anzusprechen, ist eine völlig andere Sache.
Ich lege für EEPROM-Daten immer eine Kopie im normalen SRAM an und kann
dort schnell lesen und schreiben. Und nur bei Bedarf wird wirklich in
den EEPROM zurück geschrieben.
Peter
> Kann man diese Funktionen, die durchs 3.Adressbyte angesprochen werden,> einsehen bzw. ist das genauer dokumentiert?
Ja, das findest du u.a. in der Doku zum C51:
http://www.keil.com/support/man/docs/c51/c51_ap_xbanking.htm> Würde da z.B. eine Funktion existieren, die bei i2c-Tag dann den extern> seriell angeschlossenen i2c-Baustein ansteuert, dann könnte man diesen> Baustein einfach im Adressbereich ansteuern wie RAM in einem 24-Bit> Adressbereich.
Ja, so ungefähr läuft das. Der Linker platziert die Variablen, und der
echte Zugriff erfolgt dann über die Zugriffsroutinen aus dem o.g. Link.
Ich hab das damals für ein internes EEPROM so gelöst, weil man auf diese
Art dann eben auch (komplexere) structs, etc. ganz normal ins EEPROM
schieben oder auslesen kann, der C-Code war dann eben nicht gespickt mit
Adressberechungen und Funktionsaufrufen, sondern mit ganz normalen
Operationen auf die Variablen, als lägen sie im RAM.
Ein I2C-EEPROM (oder generell I2C-Device) ist natürlich noch mal ne
Stufe komplexer, aber auch das ist möglich.
Ralf
> so ganz leuchtet mir der Vorteil(?) mit dem extra nicht ein.> Kannst Du bitte mal ein Beispiel dazu bringen?
extra -> extra was? Meinst du das zusätzliche Address-Byte? Der
"Vorteil" ist einfach, dass du beliebigen Speicher wie ganz normale
C-Variablen ansprechen kannst, ohne jedesmal spezielle Funktionen
(I2C_WRITE(), SPI_READ(), etc.) aufrufen zu müssen.
Im Prinzip ist es vom Konzept her ein bisschen wie die Sache mit printf
und putchar.c:
In der putchar.c kannst du deine Ausgabe vom seriellen Port auf ein
Display oder sonstwas umlegen, der printf-Aufruf bleibt (nahezu)
unangetastet.
Ich fand's halt praktisch, dass sich der Linker um die Adressvergabe im
EEPROM gekümmert hatte und ich da nicht selber drauf achten musste. Der
für mich bei weitem größte Vorteil aber war damals, dass ich eben mit
structs aus dem EEPROM ebenso arbeiten konnte wie aus dem RAM. Das geht
mit Funktionsaufrufen ála WRITE_EEPROM() nur bedingt, denn wer will
schon für jedes struct etc. eine eigene Zugriffsroutine schreiben?
Verstehst du, was ich meine?
Ralf
Interessant. Vor vielen Jahren hatte ich diese Idee auch, sah sie aber
nirgends realisiert. Schön zu hören, wenn es nun praktisch realisiert
wurde. Die Vorteile wurden ja genannt.
Der nächste von mir gedachte Schritt war dann auch andere Controller im
Adressbereich abzubilden, so daß man selbst über Kommunikationsnetze
eine einheitliche Oberfläche vorfindet.
Wo welche Daten wie abgelegt werden müssen, entzieht sich dann vollends
der Verwaltung durch den Programmierer.
Erinnert mich an den Apple Newton und seinem Backup-'Problem': Der
normale User wußte schlicht gar nicht, wo seine Daten gerade auf den
mehreren angeschlossenen Medien lagern.
Hi Pieter,
okay, ich versuche mal ein Beispiel zu erstellen. Relativ einfach
gehalten gehen wir jetzt mal von einem EEPROM aus (intern oder I2C sei
jetzt mal egal).
Beispielgrundlage ist, dass du a) Zugriffsroutinen hast (WRITE_EEPROM(),
READ_EEPROM(), etc.) und b) ein struct folgender Form:
1
struct_stX{
2
unsignedcharucA;
3
unsignedintuiB;
4
unsignedlongulC;
5
};
6
7
struct_stXstX;
Mit dem struct bildest du irgendwelche Werte/Einstellungen/etc. im
EEPROM ab. Wie würde nun der Zugriff aussehen? Etwa so (nicht ganz
c-konform):
1
WRITE_EEPROM(stX.ucA,uiAddress1);//write byte
2
WRITE_EEPROM(stX.uiB>>8,uiAddress2);//write high nibble
uiAddressx seien hier vom Programmierer berechnete/vorgegebene Adressen
im EEPROM.
Jetzt verwenden wir das o.g. Vorgehen:
1
struct_stXstX;// EEPROM settings, located in RAM
2
struct_stXfarstX_EEPROM;// EEPROM settings
3
4
stX_EEPROM.ucA=stX.ucA;
5
stX_EEPROM.uiB=stX.uiB;
6
stX_EEPROM.ulC=stX.ulC;
Wie funktioniert's? Es wird für jeden Zugriff auf eine
far-memory-Variable geprüft, welcher Typ (char, int, long oder Pointer)
zugrunde liegt und in Abhängigkeit davon eine Zugriffsroutine
aufgerufen. Diese "Typ"-Routinen prüfen, in welchem far-Segment (=
3.Adressbyte) die Variable liegt und machen den entsprechenden Zugriff,
wobei die Standardspeicherarten bereits implementiert sind (also data,
idata, etc.). Das alles passiert "ohne Zutun" des Programmierers (wenn
man davon ausgeht dass die Zugriffsfunktionen vorhanden und die
far-Segmente passend eingerichtet sind).
Man könnte nun also ein Segment für ein I2C-EEPROM anlegen, ein weiteres
für einen I2C-DAC, usw., die Zugriffsroutinen agieren entsprechend im
Hintergrund. Einmal implementiert macht der Programmierer dann nur ganz
normale Variablenzugriffe.
Ralf
Hallo Ralf,
ist das so, wie ich es für Speicher jetzt schon nutze?
Beipiel:
;Demo, Variablenzugriff auf verschiedene Speicherbereiche
Model C8051F340.MCU
;------------------------------------------------------------
ISEG
Org 30H
Lo_I: DS 1 ;1 Byt im IRAM reservieren
Org 80H
Hi_I: DS 1 ;1 Byt im IRAM reservieren
;------------------------------------------------------------
CSEG
Org 1000H
C_Data: DS 1 ;1 Byt im CodeSegment reservieren
; sinnvoll????
;------------------------------------------------------------
XSeg
Org 30H
Lo_X: DS 1 ;1 Byt im XRAM reservieren
;------------------------------------------------------------
CSeg
;------------------------------------------------------------
;Macro zum laden von A aus verschiedenen Segmenten
Mov_A_Variable Macro Value
Cond @Value = XSeg
Mov R0, #Value
MovX A, @R0
EndC
Cond @Value = CSeg
Mov DPTR, #Value
CLR A
MovC A, @A+DPTR
EndC
Cond (@Value = ISeg) & (Value<= 7CH)
Mov A, Value
EndC
Cond (@Value = ISeg) & (Value> 7CH)
Mov R0, #Value
Mov A, @R0
EndC
EndM
;------------------------------------------------------------
Org 0
Mov_A_Variable Lo_I
Mov_A_Variable Hi_I
Mov_A_Variable Lo_X
Mov_A_Variable C_Data
End
Als Programmiere kümmert man sich nicht mehr darum wo die Variable
deklariert, das mach hier das Macro.
So soll es dann auch mit Schnittstellen funktionieren?
Mit Gruß
Pieter
Hi Pieter,
> ist das so, wie ich es für Speicher jetzt schon nutze?
Ja, ich denke (zumindest nach einem schnellen Blick drauf), dass das
ähnlich ist.
In deinem Beispiel ist es ein Macro, wird also während der
Programmerstellung aufgelöst. Im Fall vom Keil Compiler ist es während
der Laufzeit.
Bei deinem Beispiel fehlt aber m.E. noch die Möglichkeit, die Segmente
parallel anlegen zu können. (Quasi die Erweiterung um das dritte oder
sogar n-te Addressbyte).
> Als Programmiere kümmert man sich nicht mehr darum wo die Variable> deklariert, das mach hier das Macro.
Genau (vorausgesetzt, der Programmierer hat einmal alles eingerichtet).
> So soll es dann auch mit Schnittstellen funktionieren?
Ich würde mich jetzt nicht unbedingt auf Schnittstellen festlegen (falls
das einen Unterschied macht).
Allgemein ausgedrückt geht's darum, den Zugriff auf Variablen in vom
Programmierer definierten Segmenten durch selbst programmierte
Zugriffsfunktionen kontrollieren zu können.
Ralf
Ralf schrieb:> @Wilhelm:> Das hat nix mit 'Kids' etc. zu tun. Und als alter Hase darfst du mich> gerne an deinen Erfahrungen mit diesem Assembler teilhaben lassen :)>> Ralf
Entschuldige Ralf, mir liegt es auch weit fern, ohrfeigen zu wollen.
Ich mußte mich im Detail mit den SDCC-Tools sehr lange herum schlagen,
Tage, Wochen, weil da ist nichts Ready To Use, wie wenn man einen
teueren Keil-Compiler in einer Firma kauft. Einige sehr umfangreiche
Manuals. Aber SDCC ist sonst unlimitiert, und das zählt, können den
vollen 8051-Speicherbereich ohne Codebeschränkungen.
Allerdings fehlen bei SDCC auch spezielle Libraries, die Profi-Anbieter
wiederum haben. Ich denke da beispielsweise an Floating-Point-Arithmetik
mit dem 80517, der eine spezielle 32 bit Hardware-MDU zum Rechnen hat,
die hundert mal schneller als Software ist. Das müßte ich in Tagen
Arbeit auch nachbasteln.
Was brauchst du? Ein Command-File (Batch), was dir alles automatisch
macht? Oder den Sourcecode mit den Definitionen? Da könnte ich mal
schauen, ob ich ein komplettes Projekt in Assembler habe.
Ich verwende Geany als Projekt-Oberfläche mit Syntax-Highlighting für
Programmiersprachen. Ausgezeichnet gut.
Die Nasen von SDCC wechselten im vergangenen Jahr mal die Dateinamen der
ausführbaren Programme Assembler und Linker, aber da muß ich dann was
hin biegen, damit es wieder funktioniert. Nicht nur fürs Forum, sondern
für mich selbst. Als ich die SDCC-Version vergangenen Monat updatete,
funktionierten erst mal meine alten Projekte nicht mehr. Aber ich habe
so einen Riecher, wo man da schnell was findet...
Also, Ralf, machen wir es kurz:
Wenn du möchtest, bekommst du von mir ein vollständiges
Assembler-Projekt für den SDCC. Wo Linker-Adressen definiert sind, und
Speicheradressen, Bitadressen Flags für den Bit-Bereich. Alles restlos
kenne ich indessen auch noch nicht. Ein alter 8051-Assembler hatte mal
die USING-Direktive, zur Registerbank-Deklaration im 8051. Das finde ich
beim SDCC nicht, mache mir aber Gedanken, wie ich es mit Defines und
bedingter Blockassemblierung lösen könnte. Mein Projekt enthält
sicherlich Funktionen, die nur meine eigene Hardware ansprechen, und
nicht weiter verwertbar sind. Beispielsweise die Kommunikation mit dem
Keyboard-Display-Controller 8279, den es schon 10 Jahre nicht mehr gibt.
Aber das spielt keine Rolle, man kann sich aus fertigem Code immer prima
was abschauen. So machte ich es meistens, sich was abschauen. Ich muß es
aber noch bearbeiten, und meinen Realnamen beispielsweise entfernen. ;-)
Aber ich komme inzwischen mit SDCC gut zurecht. Das beste, was ich
bisher fand, wenn man wenig Geld hat.
Wie man mehrere Assembler-Files assembliert und mit dem Linker bindet,
muß ich auch noch heraus finden. Die Notwendigkeit war noch nicht da.
Und dieses Projekt ist eben mal ein Nebenbei-Projekt auf Assembler, habe
sonst andere Hardware, die ich in C programmiere. Aber auch in C: Calls
zu Assemblerfiles. Zur absolut präzisen Nachladung eines Timers im
Timer-Interrupt.
> Entschuldige Ralf, mir liegt es auch weit fern, ohrfeigen zu wollen.
Keine Sorge, ich hab's keineswegs so aufgefasst :)
> Ich mußte mich im Detail mit den SDCC-Tools sehr lange herum schlagen,> Tage, Wochen, weil da ist nichts Ready To Use, wie wenn man einen> teueren Keil-Compiler in einer Firma kauft.
C mit dem SDCC ging eigentlich nach dem Anpassen der Headerfiles etc.
Nur war leider die Performance krüpplig. Daher entstand mein Wunsch das
ganze in Assembler machen zu wollen.
> Allerdings fehlen bei SDCC auch spezielle Libraries, die Profi-Anbieter> wiederum haben.
Ich benutze keine Bibliotheken sofern's nicht unbedingt sein muss (und
das war bisher auch nicht der Fall). Das Problem stellte sich also
bisher nicht.
> Was brauchst du? Ein Command-File (Batch), was dir alles automatisch> macht? Oder den Sourcecode mit den Definitionen? Da könnte ich mal> schauen, ob ich ein komplettes Projekt in Assembler habe.
Gute Frage. Meine Versuche scheiterten schon daran, überhaupt ein
Assemblerfile übersetzt zu bekommen.
Als Basis hatte ich ein Assemblerfile genommen, welches ursprünglich aus
einem C-File entstanden ist, und dachte, dass ich es anpassen kann. Ich
kann leider nicht mehr genau sagen, was dem Assembler nicht geschmeckt
hatte.
Zurück zur Frage: Ein Command-File brauche ich denke ich nicht, als IDE
verwende ich die SiLabs IDE, die sollte das alles handeln. Schaden kann
das File aber auch nicht, falls ich mal den Linker etc. manuell aufrufen
muss oder mit speziellen Parameter.
Mir würde für den Anfang schon ein Assemblerfile reichen, welches nicht
aus C-Code entstanden ist, sondern wirklich selbst erstellt. Den Rest
sollte ich mit dem Handbuch hinkriegen :)
> Ich verwende Geany als Projekt-Oberfläche mit Syntax-Highlighting für> Programmiersprachen. Ausgezeichnet gut.
Kenne ich leider nicht. Ich verwende wie gesagt die Silabs IDE. Sagen
wir, sie erfüllt ihren Zweck, es gibt sicherlich bessere. Allerdings
kann ich halt direkt das Programm runterladen und auch debuggen.
> Die Nasen von SDCC wechselten im vergangenen Jahr mal die Dateinamen der> ausführbaren Programme Assembler und Linker, aber da muß ich dann was> hin biegen, damit es wieder funktioniert. Nicht nur fürs Forum, sondern> für mich selbst. Als ich die SDCC-Version vergangenen Monat updatete,> funktionierten erst mal meine alten Projekte nicht mehr. Aber ich habe> so einen Riecher, wo man da schnell was findet...
Ja, ich hab da was gelesen, dass die Namen geändert wurden. Verwendet
wird doch dieser Assembler:
http://shop-pdp.kent.edu/ashtml/asxxxx.htm
Oder täusche ich mich da?
> Also, Ralf, machen wir es kurz:> Wenn du möchtest, bekommst du von mir ein vollständiges> Assembler-Projekt für den SDCC. Wo Linker-Adressen definiert sind, und> Speicheradressen, Bitadressen Flags für den Bit-Bereich.
Das hört sich nicht schlecht an. Wie gesagt, brauch eigentlich nur ne
Grundlage, die funktioniert, denn ich hab's nach mehrmaligem Hoch- und
Runterlesen des Handbuchs nicht geschafft, mein Assemblerfile ans Laufen
zu bekommen.
> Alles restlos kenne ich indessen auch noch nicht. Ein alter> 8051-Assembler hatte mal die USING-Direktive, zur Registerbank-> Deklaration im 8051. Das finde ich beim SDCC nicht, mache mir aber> Gedanken, wie ich es mit Defines und bedingter Blockassemblierung lösen> könnte.
Laut dem Handbuch des alten Intel-Assemblers, welchen ich
zwischenzeitlich im Web gefunden habe, sorgt die USING-Direktive nur
dafür, dass man anstatt Rn (n=0-7) die Bezeichnung ARn verwenden kann.
Aufgeführt wird als Verwendungsbeispiel PUSH/POP für die Register, was
durch die Verwendung Rn nicht möglich ist, sondern nur durch die
Verwendung der jeweiligen Adresse. Durch das USING kannst du somit
einfach PUSH AR3 anstatt PUSH 03 (oder 0B, etc.) schreiben.
Ich könnte mir vorstellen, dass es als Macro geht. Laut Handbuch gibt's
(siehe Link oben) gibt es die .define und .undefine Anweisungen. Wenn du
im Macro AR0-AR7 erst "undefinierst" und dann per conditional assembly
entsprechend mit .define AR0-AR7 zuweist könnte es doch klappen, oder?
> Mein Projekt enthält sicherlich Funktionen, die nur meine eigene> Hardware ansprechen, und nicht weiter verwertbar sind. Beispielsweise> die Kommunikation mit dem Keyboard-Display-Controller 8279, den es schon> 10 Jahre nicht mehr gibt.> Aber das spielt keine Rolle, man kann sich aus fertigem Code immer prima> was abschauen. So machte ich es meistens, sich was abschauen. Ich muß es> aber noch bearbeiten, und meinen Realnamen beispielsweise entfernen. ;-)> Aber ich komme inzwischen mit SDCC gut zurecht. Das beste, was ich> bisher fand, wenn man wenig Geld hat.
Das stimmt, aber was zum "Abgucken" muss auch erstmal gemacht sein :)
Und selbst wenn das Beispiel nur Treiber für eigene Hardware enthält,
selbst dann kann man trotzdem was lernen.
> Wie man mehrere Assembler-Files assembliert und mit dem Linker bindet,> muß ich auch noch heraus finden. Die Notwendigkeit war noch nicht da.
Kommt denke ich auf den persönlichen Stil an. Ich bevorzuge es
(mittlerweile), zumindest die grundlegenden Funktionen jeweils in
eigenen Sourcefiles zu haben. Funktionen, die applikationsspezifisch
sind, können durchaus mal in einem gemeinsamen Sourcefile stehen.
> Und dieses Projekt ist eben mal ein Nebenbei-Projekt auf Assembler, habe> sonst andere Hardware, die ich in C programmiere. Aber auch in C: Calls> zu Assemblerfiles. Zur absolut präzisen Nachladung eines Timers im> Timer-Interrupt.
Wieso eine C-Funktion zum Nachladen des Timers?
Ralf
moin moin,
wieder knappe Zeit...
USING ist die Krücke um die 4 Registebänke anzusprechen.
Im MC wird die Zuordnung über PSW gesteuert, im Assembler über eine
gleichlautende USING.
In meinem Simulator ist die aktuelle Registerbank gelb hinterlegt.
Zu Rn und ARn:
Es gibt kein Push/Pop Rn, daher die Hilfszuweisung A(bsolute)Rn.
Bei Änderung der Registerbank muß auch ARn geändert werden.
Am SDCC stört mich besonders das einige LIBs, die nicht in ASM
geschrieben sind, viel unnötigen Code erzeugen.
Schlimmstes Beispiel fabsf kann durch ein simples |CLR A.7| ersetzt
werden.
Mit Gruß
Pieter
Moin Pieter,
> Im MC wird die Zuordnung über PSW gesteuert, im Assembler über eine> gleichlautende USING.> <snip>> Bei Änderung der Registerbank muß auch ARn geändert werden.
Eigentlich wär's interessant zu wissen, ob der Assembler selbst
mitverfolgen könnte, welche RB gerade gewählt ist. Da SFRs nicht
indirekt adressiert werden können, wäre es ja "nur" das Merken der
Zustände der RS-Flags auf einem eigenen Assembler-Stack, oder?
Die von dir erwähnte 03.zip hab ich nicht gefunden, ich hab wohl Tomaten
auf den Augen.
Du hattest relativ weit oben geschrieben, dass dein Assembler keine
Optimierung machen könnte, wenn etwas "vorassembliertes" verwendet wird.
Wieso könnte er dann keine Optimierung machen?
Gibt's zu deinem Assembler ne Projektseite?
Ralf
moin Ralf,
anbei das LCD-Demo...nur für Dich!
1. MASM51 starten
2. Datei öffnen -> Verzeichnis Frank -> FRANK.MAC
3. Project -> Display auf P1 setzen
4. Käfer anklicken (Simulator starten)
5. zuschauen
>>der Assembler selbst mitverfolgen könnte
das tut er doch, den nach USING wird AR0 gesetzt( 0,8,10H,18H).
sorry, Mittagspause vorbei.
Mit Gruß
Pieter
Hi Pieter,
> anbei das LCD-Demo...nur für Dich!
Danke, schau ich mir an.
>> der Assembler selbst mitverfolgen könnte> das tut er doch, den nach USING wird AR0 gesetzt( 0,8,10H,18H).
Ja, das schon, aber USING muss ja durch den Programmierer erfolgen.
Ich hab mich gefragt, ob der Assembler das selbst herausfinden kann,
welche RB verwendet wird.
> sorry, Mittagspause vorbei.
Heut abend geht's weiter :)
Ralf
Ralf schrieb:>> Allerdings fehlen bei SDCC auch spezielle Libraries, die Profi-Anbieter>> wiederum haben.> Ich benutze keine Bibliotheken sofern's nicht unbedingt sein muss (und> das war bisher auch nicht der Fall). Das Problem stellte sich also> bisher nicht.
OK, meistens mache ich auch alles selbst, das ist bei Assembler eben so.
>> Was brauchst du? Ein Command-File (Batch), was dir alles automatisch>> macht? Oder den Sourcecode mit den Definitionen? Da könnte ich mal>> schauen, ob ich ein komplettes Projekt in Assembler habe.> Gute Frage. Meine Versuche scheiterten schon daran, überhaupt ein> Assemblerfile übersetzt zu bekommen.> Als Basis hatte ich ein Assemblerfile genommen, welches ursprünglich aus> einem C-File entstanden ist, und dachte, dass ich es anpassen kann. Ich> kann leider nicht mehr genau sagen, was dem Assembler nicht geschmeckt> hatte.> Zurück zur Frage: Ein Command-File brauche ich denke ich nicht, als IDE> verwende ich die SiLabs IDE, die sollte das alles handeln. Schaden kann> das File aber auch nicht, falls ich mal den Linker etc. manuell aufrufen> muss oder mit speziellen Parameter.> Mir würde für den Anfang schon ein Assemblerfile reichen, welches nicht> aus C-Code entstanden ist, sondern wirklich selbst erstellt. Den Rest> sollte ich mit dem Handbuch hinkriegen :)
Sowas wie du mit der SiLabs-IDE hatte ich auch mal, hatte die IDE aus
der Demo-Version von Keil. Auf Dauer wollte ich was neutrales,
unabhängiges, und stieß hier im Forum auf eine Empfehlung, Geany als IDE
zu benutzen. Die ist frei im Internet erhältlich, und die Oberfläche und
Editorfenster gefallen mir. Mit Geany bin ich als Hobbybastler mit
geringem Budget super zufrieden.
>> Also, Ralf, machen wir es kurz:>> Wenn du möchtest, bekommst du von mir ein vollständiges>> Assembler-Projekt für den SDCC. Wo Linker-Adressen definiert sind, und>> Speicheradressen, Bitadressen Flags für den Bit-Bereich.> Das hört sich nicht schlecht an. Wie gesagt, brauch eigentlich nur ne> Grundlage, die funktioniert, denn ich hab's nach mehrmaligem Hoch- und> Runterlesen des Handbuchs nicht geschafft, mein Assemblerfile ans Laufen> zu bekommen.
OK, ich specke ein bestehendes Projekt zur Übersichtlichkeit mal etwas
ab. Die BAT-Datei mußt du trotzdem verwenden, denn die erzeugt erst das
Linker-Skript. Ich habe es mir so eingerichtet, daß alles bequem
handhabbar ist.
Also: Du doppelklickst zum Assemblieren und Linken die BAT-Datei zur
Ausführung an, und dann kommt hinten die HEX-Datei im Intel- oder
Motorola-Format fertig zum Flashen heraus.
Man kann das, was in der BAT-Datei steht, natürlich auch nacheinander zu
Fuß machen, wenn man sich gerne viel Arbeit schafft. ;-)
Ich werde ein Testprojekt so weit her richten, daß es ohne Fehler
assembliert und linkt, und es dann in einem Zip-File verpacken, und hier
als Dateianhang hoch laden.
Heute werde ich es allerdings nicht mehr schaffen, das wird sicher
mindestens Samstag Nachmittag oder Abend.
>> Alles restlos kenne ich indessen auch noch nicht. Ein alter>> 8051-Assembler hatte mal die USING-Direktive, zur Registerbank->> Deklaration im 8051. Das finde ich beim SDCC nicht, mache mir aber>> Gedanken, wie ich es mit Defines und bedingter Blockassemblierung lösen>> könnte.> Laut dem Handbuch des alten Intel-Assemblers, welchen ich> zwischenzeitlich im Web gefunden habe, sorgt die USING-Direktive nur> dafür, dass man anstatt Rn (n=0-7) die Bezeichnung ARn verwenden kann.> Aufgeführt wird als Verwendungsbeispiel PUSH/POP für die Register, was> durch die Verwendung Rn nicht möglich ist, sondern nur durch die> Verwendung der jeweiligen Adresse. Durch das USING kannst du somit> einfach PUSH AR3 anstatt PUSH 03 (oder 0B, etc.) schreiben.> Ich könnte mir vorstellen, dass es als Macro geht. Laut Handbuch gibt's> (siehe Link oben) gibt es die .define und .undefine Anweisungen. Wenn du> im Macro AR0-AR7 erst "undefinierst" und dann per conditional assembly> entsprechend mit .define AR0-AR7 zuweist könnte es doch klappen, oder?
Das mit USING muß man eben zu Fuß erledigen, und vorher genau überlegen,
wie man die Registerbänke einsetzt. Z.B. RB0 im Hauptprogramm, und RB1
bis RB3 nur für Interrupts. Evtl. eines der drei noch für allgemeine
Funktionen, denn manchmal braucht man in einer Funktion mehr als 2
Register als Zeiger. Leider können pro Registerbank ja nur 2 Register R0
und R1 indirekt adressieren. Diese Woche überlegte ich mir schon, wie
ich USING mit Defines erledigen könnte. Da gibt es sicher Wege.
Manchmal muß man in einer Funktion eben auch die verwendeten Register
pushen und poppen. In meinem alten Assembler von Ashling Microsystems
konnte man das über USING und die Benennung der Register mit AR0 bis AR7
handhaben, dann wurden die richtigen Register der entsprechenden Bank
gewählt.
Wenn ich anderweitig fest gelegt habe, welche Funktion welche Bank
benutzen darf, dann kann ich die Register natürlich auch direkt mit der
Byteadresse ansprechen. Z.B. PUSH 8 für Register 0 in Bank 1.
Ich suche da noch nach einer Assembler-Direktive, wie z.B. SET, wo man
einen Wert im Programmverlauf neu definieren kann. Diesen Wert könnte
ich auch USING nennen, und ihm im Code an verschiedenen Stellen neue
Werte z.B. von 0 bis 3 zuweisen. Dann könnte man so eine Konstruktion
wie PUSH (0+USING*8) verwenden, um das richtige Register 0 zu pushen.
>> Und dieses Projekt ist eben mal ein Nebenbei-Projekt auf Assembler, habe>> sonst andere Hardware, die ich in C programmiere. Aber auch in C: Calls>> zu Assemblerfiles. Zur absolut präzisen Nachladung eines Timers im>> Timer-Interrupt.> Wieso eine C-Funktion zum Nachladen des Timers?>> Ralf
Ich hoffe, du weißt, wie man den Timer 0 im 16-bit-Modus manuell
nachladen muß, damit er präzise ist. Z.B. für eine Uhr. Wenn in der
DCF77-Uhr das Funksignal aus fällt, soll der ja absolut präzise,
zumindest quarzgenau, weiter laufen. In C direkt geht das nicht
zuverlässig, es sei denn mit Inline-Assembler. OK, beim 8052 kann man
den Timer 2 mit Autoreload noch verwenden, wenn man den nicht
anderweitig braucht.
moin moin,
>>Ich suche da noch nach einer Assembler-Direktive, wie z.B. SET,
ja, an so etwas habe ich auch schon gedacht. Bei EQU ist das wegen
folgendem Datenvergleich nicht möglich. Innerhalb eines Macros geht es
bei mir als Lokales-EQU, d.h. die in der MacroDefinition vorhandene
Parameterliste wird bei jedem Aufruf mit der aktuellen ParameterListe
uberschrieben.
Mal sehen, was das für ein Aufwand wird.
Mit Gruß
Pieter
Pieter schrieb:> Mal sehen, was das für ein Aufwand wird.
Pieter, ich werde nicht mehr so viel in Assembler programmieren.
Ich tat das nur eines 80535-Boardes wegen, was vor 22 Jahren nur 4kB ROM
hatte und 2kB RAM, da gehts nicht in C. Meine anderen Boards mit 80C515A
und 80C517A haben 32k bzw. 64k ROM und RAM. Das mache ich natürlich in C
und mit dem C-Compiler des SDCC, es geht prächtig.
Das einzige, wo ich da noch ein Assemblerfile mit einbinde, ist eben die
präzise Nachladung der Timer 0 und 1 als System-Timer, wenn sie nicht im
Autoreload-Modus laufen. Aber keine große Affäre.
moin moin,
so die Testversion MASM51 mit SET steht. War gar nicht so viel.
Muss nachher mal zum Test alle Progs durchlaufen lassen.
@Wilhelm
am SDCC stört mich die schlechte Handhabung der Parameter zwischen den
Funktionen.
In einigen LIBs wenden 16Bit Int definiert um 2 Bits zu speichern.
Bei meine Version von fabsf...da meckert SDCC immer.
@Ralf,
>>Bei deinem Beispiel fehlt aber m.E. noch die Möglichkeit, die Segmente>>parallel anlegen zu können. (Quasi die Erweiterung um das dritte oder
Meins Du, wie beim C8051F360, die mehreren Seiten SFR?
In der Definition der Register dann Page:Wert angeben und mit Macros
arbeiten.
so:
MovSFR Macro Target, Value
Cond Page <> (Target >> 8)
Mov SFRsel, #Target >> 8
Page SET (Target >> 8) ;neue SFR speichern
EndC
Mov Target, Value
EndM
Mit Gruß
Pieter
@Wilhelm:
>> Ich benutze keine Bibliotheken sofern's nicht unbedingt sein muss (und>> das war bisher auch nicht der Fall). Das Problem stellte sich also>> bisher nicht.> OK, meistens mache ich auch alles selbst, das ist bei Assembler eben so.
Ich mach das auch in C ohne Libs :)
Bisher hab ich glaub ich in keinem Projekt ne C-Lib gebraucht. Keine
Verwendung von printf, etc. alles selbstgemachte Funktionen.
> ... eine Empfehlung, Geany als IDE zu benutzen. Die ist frei im Internet> erhältlich, und die Oberfläche und Editorfenster gefallen mir.
Okay, ich denke mal sie erlaubt auch das Einbinden der Flashtools, aber
wie steht's mit dem Debuggen?
> Das mit USING...
Mein Vorschlag mit .define/.undefine hat nicht geklappt?
> Ich hoffe, du weißt, wie man den Timer 0 im 16-bit-Modus manuell> nachladen muß, damit er präzise ist.
Ja, weiss ich :)
Deswegen steht bei mir in der ISR ein bisschen inline-Assembler. Ich
lade nicht einfach den Reloadwert neu in den Timer, sondern addiere den
Reloadwert minus der benötigten Takte für die Addition und das drumrum
auf den aktuellen Wert und starte dann den Timer wieder. Funktioniert
einwandfrei.
> jetzt habe ich es. Viel Erfolg wünscht der Wilhelm.
Danke :)
@Pieter:
> so die Testversion MASM51 mit SET steht. War gar nicht so viel.
Wenn das so weiter geht steht dein Assembler den kommerziellen Produkten
in nichts nach :)
> am SDCC stört mich die schlechte Handhabung der Parameter zwischen den> Funktionen.
Liegt wahrscheinlich daran, dass der SDCC für unterschiedliche
Architekturen aufgezogen ist.
Ich wollte ein Projekt nach SDCC konvertieren, und das lief bei weitem
nicht so flüssig wie mit dem ursprünglichen Compiler. Ich weiss leider
nicht woran's liegt, bzw. ob man für den SDCC einige Sachen einfach
anders angehen muss.
>> Bei deinem Beispiel fehlt aber m.E. noch die Möglichkeit, die Segmente>> parallel anlegen zu können. (Quasi die Erweiterung um das dritte oder> Meins Du, wie beim C8051F360, die mehreren Seiten SFR?
Ähnlich. Ich meine das so: Der 8051 kann nur ein 64kB Segment Code/Daten
verwalten. Alles darüber hinaus muss per Banking gemacht werden (höhere
Adressbits manuell ansteuern, etc.).
Entsprechend können auch die meisten Assembler nur ein Segment
Code/Daten verwalten.
Wenn man nun beispielsweise die Möglichkeit hat, mehrere 64kB-Segmente
anzulegen, die alle parallel liegen und per zusätzlichem Adressbyte
unterschieden werden können, dann hat man das Overlay-Prinzip.
Für Datensegmente kann man sich dann das dritte (n-te) Adressbyte holen
und daran erkennen in welchem Segment die angesprochene Variable liegt.
Und damit hat man die Möglichkeit, nicht einfach durch ein z.B.
MOVX-Befehl zuzugreifen, sondern dass beispielsweise für dieses Segment
ein Zugriff auf die I2C-Schnittstelle, ein Display oder sonstwas gemacht
wird:
Segment XDATA 0x000000-0x00FFFF: normales XRAM
Segment XDATA 0x010000-0x01FFFF: I2C-EEPROM
Segment XDATA 0x020000-0x02FFFF: Display
In diesen Segment kann man dann seine Variablen anlegen.
Der Variablenzugriff geschieht dann nicht mehr direkt, sondern könnte
z.B. so aussehen (vereinfacht):
Wie bereits gesagt, eigentlich ist das mehr für Hochsprachen
interessant. Im Fall von reiner Assemblerprogrammierung könnte ich mir
vorstellen, dass es zumindest für das Abbilden der
EEPROM-Speicherstruktur o.ä. interessant ist, da man nicht mit EQUs etc.
arbeiten muss, sondern DS/DB/etc. verwenden kann.
Ralf
Pieter schrieb:> @Wilhelm> am SDCC stört mich die schlechte Handhabung der Parameter zwischen den> Funktionen.
Ach, dafür ist er kostenlos, und von der Codelänge unlimitiert. Das
zählt bei mir prioritätsmäßig erst mal mehr als alles andere. Ich
beklage mich doch gar nicht. Zeit habe ich sowieso auch reichlich. Für
eine Firma würde sich die Brasselei nicht lohnen, eben weil viel Zeit
drauf geht, bis man alles hat, wie man es will. Es sei denn, der
Entwickler kostet nur 3€ die Stunde brutto. Da ist ein teuerer
Profi-Compiler Ready To Use besser angebracht. Leute, freut euch doch.
Mit meinen Boards, die vollen Speicherausbau haben, kann ich mich mit
dem SDCC-Compiler so richtig voll auslassen, es klappt immer alles, was
ich möchte. Vor 20 Jahren, als ich mit dem 8051 begann, gabs so gut wie
gar nichts. Na ja, den Assembler auf Buchdiskette. Auch kein Internet,
wo man eine Frage stellen kann. Damals habe ich gelernt, mich auf Biegen
und Brechen durchzubeißen, weils anders nicht ging.
> In einigen LIBs wenden 16Bit Int definiert um 2 Bits zu speichern.> Bei meine Version von fabsf...da meckert SDCC immer.
Im Beispiel, was ich für den Ralf hoch geladen hatte, sind auch
Bitdefinitionen drin, also man kann im Bitsegment wirklich die einzelnen
Flags definieren und benutzen. So gehört sich das auch.
In C kann man mit "UNION" im Vergleich zum "STRUCT" ein Byte noch in
Bits zerlegen, für einen Prozessor, der keine Einzelbits kennt.
Allerdings geht das stark auf Kosten von Code. Die Bits sind eigentlich
nur Pseudo-Bits. Na ja, Flash Programmspeicher kostet heute auch nichts
mehr. Bei den LPC2000-ern (ARM7) machte ich sowas, zerstückelte einen
Long-Wert im RAM in 32 Bits, die ich im Programm als Flags benutzte.
Ralf schrieb:> Bisher hab ich glaub ich in keinem Projekt ne C-Lib gebraucht. Keine> Verwendung von printf, etc. alles selbstgemachte Funktionen.
Die COM-Ausgaben strickte ich mir alle selbst, machte sogar FIFOs für
Empfang und Sendung für die serielle Kommunikation, und
Interruptsteuerung der seriellen Schnittstelle, damit alles voll
automatisch läuft. Richtige Funktionen wie PUTCHAR und GETCHAR übers
FIFO wie in C.
Was ich vermisse, sind C-Libraries, die beim 80C517 für Arithmetik die
schöne schnelle Hardware-MDU verwenden, die besonders auf schnelle
Floating-Point-Rechnungen ausgelegt ist. Wenn ich das anpacke, dann
riecht es schwer nach viel Arbeit, dafür gehen Tage drauf. Ein
Profi-Compiler wie Keil hat das natürlich alles.
Bis jetzt ist der 80517 also auch in C bei Berechnungen ein Krüppel,
weil er da nichts anderes macht, als der Standard-8051 auch. Ich wollte
mich nämlich mal mit schnellen Regelalgorithmen beschäftigen, denn dafür
ist der Baustein spezialisiert. Sonst kann ich es eher vergessen.
Dann hat der 80C517 auch 8 Data Pointer. Da habe ich z.B. in der
Memcopy-Funktion schon was gemacht, damit er erheblich schneller wird.
Der Stein ist auch als 8-Bitter gar nicht so schlecht.
Ralf schrieb:>> ... eine Empfehlung, Geany als IDE zu benutzen. Die ist frei im Internet>> erhältlich, und die Oberfläche und Editorfenster gefallen mir.>> Okay, ich denke mal sie erlaubt auch das Einbinden der Flashtools, aber> wie steht's mit dem Debuggen?
Debuggen mache ich stets auf herkömmliche Art, mit Hilfe serieller
Ausgaben auf Terminal oder LCD-Display, oder LEDs. Man wird da immer
besser, auch Ü50 noch, ich vermisse keinen echten Debugger, wirklich.
Für Neueinsteiger ist ein Debugger aber heute normal, die könnten mit
den alten Methoden gar nichts richtig anfangen.
Es ist natürlich gut, daß es diese Tools gibt, dagegen spreche ich gar
nicht. Es ist eine Weiterentwicklung.
Noch nicht mal den Simulator brauche ich dringendst, aber er wäre nett.
Inzwischen bin ich einfach so gut, daß Programmteile auf Anhieb laufen,
wie z.B. den Bubble-Sort für beliebige Elementlängen, den ich vergangene
Woche in nur 20 Minuten in den Rechner tippte. Sogar eine Internetsuche
nach Bubble-Sort hätte mich mehr Zeit gekostet. Nach Aufzeichnung auf
Papier erkannte ich gleich, daß der Algorithmus im Verlauf diagonal
arbeitet, und für jeden Sortierlauf ein Element weniger benötigt. Sogar
das ist drinne.
Assembler- und Linkerfehler habe ich bei Fehlermeldungen binnen einer
Minute immer auch, checke sofort, was es ist, kein Problem. Deswegen
habe ich auch die BAT-Datei. Sie öffnet ein DOS-Fenster, und man sieht
alle Meldungen und Ausgaben. Am Ende habe ich noch den Pause-Befehl
drin, "Bitte eine Taste drücken", damit das Fenster nicht von selbst zu
geht.
>> Das mit USING...> Mein Vorschlag mit .define/.undefine hat nicht geklappt?
Ich habe mal versucht, einem Define-Symbol ein weiteres mal einen neuen
Wert zuzuweisen. Das klappt. Das könnte man für ein provisorisches USING
verwenden.
>> Ich hoffe, du weißt, wie man den Timer 0 im 16-bit-Modus manuell>> nachladen muß, damit er präzise ist.> Ja, weiss ich :)> Deswegen steht bei mir in der ISR ein bisschen inline-Assembler. Ich> lade nicht einfach den Reloadwert neu in den Timer, sondern addiere den> Reloadwert minus der benötigten Takte für die Addition und das drumrum> auf den aktuellen Wert und starte dann den Timer wieder. Funktioniert> einwandfrei.
Im von mir hoch geladenen Übungsprojekt ist aber auch genau das
Timer-Beispiel drin. Die 7 in der Reload-Formel berücksichtigt die
Takte, in denen der gestoppte Timer steht. Übrigens macht das überhaupt
nichts, den Timer für die Nachladung zu stoppen. In meiner DCF77-Uhr
läuft das so seit über 15 Jahren ununterbrochen, da passiert nichts.
>> jetzt habe ich es. Viel Erfolg wünscht der Wilhelm.> Danke :)
Ich hoffe, es hilft dir ein wenig. Die Assemblierung und Linkung liefen
einwandfrei. Du brauchst das jetzt nur noch mit Code zu füllen. Da kann
dir kaum jemand helfen. Aber zu Funktionen, egal welcher Art, kannst du
hier immer noch fragen.
Leider ist es im Assembler ja nicht so simpel wie in C, wo man einfach
mal hin schreibt: y=a-b. Da muß man dann ein Subtraktionsprogramm an die
Stelle einbauen, und für Ausgaben die Sache noch von BIN nach BCD
wandeln, und ASCII-Zeichen draus machen. Deswegen ist der Code des
printf() in C auch nicht gerade so klein, das ist dort alles drin. Denn
intern arbeitet ein C-Compiler nur mit Binärzahlen. So mache ich das in
Assembler auch. Nur zur Ausgabe wird was BIN zu BCD gewandelt.
Inzwischen, die letzten Tage, machte ich auf dem 80535 sehr viel in
32-bit-Arithmetik. Man muß sich daran gewöhnen, aber es macht mir sehr
viel Spaß.
Im Grunde müßte man so ein Testprojekt auch mal bei Sourceforge zur
Verfügung stellen, die die SDCC-Tools bereit stellen. Das sparte den
Usern viel Frust. Mit abstrakten Beschreibungen und Manuals alleine
kommt man nicht so sehr schnell voran.
In meinen C-Projekten verwende ich viele kleine Funktionen in separaten
Dateien, wie Pieter das vorschlug. Dort habe ich im BAT-File eine
FOR-Schleife, die immer alle C-Files compiliert und linkt.
Die FOR-Schleife in der BAT-Datei kann aber gefährlich sein: Ich hatte
sowas mal auf dem Firmen-PC, zur Löschung der nicht mehr gebrauchten
Listing-Dateien. Mir wurde damit mal fast die gesamte Festplatte
gelöscht. Frag mich nicht, was ich da genau falsch machte, es passierte
ein einziges mal. Die Syntax zur Auswahl der Verzeichnisebene stimmte
beim Test nicht ganz, es wurde dann die oberste Ebene, nämlich die
gesamte Platte, gewählt. Das ist noch krasser, als wenn man
versehentlich mal nur das Projekt löscht. ;-) Was in der BAT-Datei
gelöscht wird, erscheint nicht im Windows-Papierkorb. Gut, es gab eine
tägliche Sicherung auf dem Firmenserver.
So, Ralf, Code kannst du jetzt erstellen bis zum Abwinken. Wenn du
spezielle Fragen hast, zu Funktionen, die du realisieren willst,
vielleicht habe ich auch da was fertig, wie das Testprojekt, und schaue
gelegentlich noch mal hier vorbei.
@Wilhelm:
> Die COM-Ausgaben strickte ich mir alle selbst, machte sogar FIFOs für> Empfang und Sendung für die serielle Kommunikation, und> Interruptsteuerung der seriellen Schnittstelle, damit alles voll> automatisch läuft. Richtige Funktionen wie PUTCHAR und GETCHAR übers> FIFO wie in C.
Jopp, genau. So hab ich's vor ca. 10 Jahren auch gelernt - nix mit C und
Bibliotheken und so ^^
> Was ich vermisse, sind C-Libraries, die beim 80C517 für Arithmetik die> schöne schnelle Hardware-MDU verwenden, die besonders auf schnelle> Floating-Point-Rechnungen ausgelegt ist. Wenn ich das anpacke, dann> riecht es schwer nach viel Arbeit, dafür gehen Tage drauf. Ein> Profi-Compiler wie Keil hat das natürlich alles.> ...
Stimmt, die haben das. Derzeit brauch ich das nicht, auch nicht mehrere
Datenpointer, und wenn, dann eher für meine Cortex-Experimente. Aber
jetzt sind noch die ein, zwei 8052-Projekte angesagt.
> Debuggen mache ich stets auf herkömmliche Art, mit Hilfe serieller> Ausgaben auf Terminal oder LCD-Display, oder LEDs. Man wird da immer> besser, auch Ü50 noch, ich vermisse keinen echten Debugger, wirklich.
So hab ich's auch gelernt, und ein "debug equ 1" tut nicht weh, aber bei
Projekten, die keine serielle Schnittstelle oder ein Display vorgesehen
haben oder bei denen die serielle Schnittstelle das einzige Interface
ist und alles Ports belegt sind ist ein Debugger schon hilfreich.
> Für Neueinsteiger ist ein Debugger aber heute normal, die könnten mit> den alten Methoden gar nichts richtig anfangen.
Oh ja, das hab ich bei den Studenten gesehen, die das PS bei uns gemacht
haben :)
> Noch nicht mal den Simulator brauche ich dringendst, aber er wäre nett.
Hab gaaaanz am Anfang mal mit den Dingern gespielt, aber bin schnell
davon abgekommen. Eignen sich nur für den Test kleiner Routinen des
Gesamtprojekts, wenn überhaupt. Aber ein komplettes Projekt damit zu
testen macht keinen Sinn, weil man dann ständig irgendwelche SFR-Flags
manuell setzen muss, etc.
Ne ne ne, dann doch lieber auf der echten Hardware - wenn's sein muss
mit Debugger :)
> Assembler- und Linkerfehler habe ich bei Fehlermeldungen binnen einer> Minute immer auch, checke sofort, was es ist, kein Problem.
Das ist Erfahrung, daran sollte es nicht mehr mangeln.
> Das könnte man für ein provisorisches USING verwenden.
Okay.
> Ich hoffe, es hilft dir ein wenig.
Da bin ich sicher :) Muss allerdings gestehen, dass ich der Sonne heut
den Vorrang eingeräumt hab, und das wird auch morgen der Fall sein.
> Inzwischen, die letzten Tage, machte ich auf dem 80535 sehr viel in> 32-bit-Arithmetik. Man muß sich daran gewöhnen, aber es macht mir sehr> viel Spaß.
Das glaub ich, mir geht's nicht anders.
> Im Grunde müßte man so ein Testprojekt auch mal bei Sourceforge zur> Verfügung stellen, die die SDCC-Tools bereit stellen. Das sparte den> Usern viel Frust. Mit abstrakten Beschreibungen und Manuals alleine> kommt man nicht so sehr schnell voran.
Ja, das hab ich auch festgestellt :)
Wieso schreibst du den Jungs nicht und stellst dein Template zur
Verfügung?
> In meinen C-Projekten verwende ich viele kleine Funktionen in separaten> Dateien, wie Pieter das vorschlug. Dort habe ich im BAT-File eine> FOR-Schleife, die immer alle C-Files compiliert und linkt.
Dann muss ich mir dringend die BAT-Datei angucken, ich suche grad ne
Möglichkeit, den Linker automatisch zu füttern. Scheitert momentan
daran, dass ich mittels SET einer Variablen die Dateiliste zukommen
lassen will, aber die Variable bekomme ich nicht richtig gefüttert.
> Code kannst du jetzt erstellen bis zum Abwinken. Wenn du spezielle> Fragen hast, zu Funktionen, die du realisieren willst, vielleicht habe> ich auch da was fertig, wie das Testprojekt, und schaue gelegentlich> noch mal hier vorbei.
Besten Dank :)
Ralf
Ralf schrieb:>> Für Neueinsteiger ist ein Debugger aber heute normal, die könnten mit>> den alten Methoden gar nichts richtig anfangen.>> Oh ja, das hab ich bei den Studenten gesehen, die das PS bei uns gemacht> haben :)
Die Studenten in meinem 8051-Labor damals haben die Inputs brutal
vergewaltigt. Die bastelten sich da Widerstände, oder RC-Glieder,
unglaublich, wollten die Portpins sogar aktiv niederohmig gegen VCC auf
LOW schalten. Mit einem gedrückten Taster, der an VCC liegt, wenn der
Pin per Software auf LOW liegt. Tödlich für den µC. Nur ich, der aus den
Hobbybasteleien was wußte, sagte denen mal: Mach einfach einen Taster
gegen Masse, gar keine Bauteile, und setze die Input-Ports in der
Initialisierung auf 1, aber das haben sie nach Reset sowieso, mehr
nicht.
Die Anleitung im Labor war auch nicht besonders, die Studenten sich
selbst überlassen. Bis mal ein Bastler wie ich dazwischen kommt... Aber
das ist Zufall.
moin moin,
@Ralf,
>>Der Variablenzugriff geschieht dann nicht mehr direkt, sondern>>könnte z.B. so aussehen (vereinfacht):
Da hast Du ja schon das Programm, aber ob das so einfacher wird?
Im SDCC gibt es dazu schon _gptrput, _gptrget...also nur das Gerüst.
Derzeit kann ich mir auch nicht so recht vorstellen, wozu man das so
umständlich brauchen können sollte...
@Wilhelm
>>y=a-b
sieht bei mir in ASM so aus
PushVarF b ;lege Variable b auf Stack
MovArgVarF a ;lade Argument mit Variable a
Gosub _fssub ;das SUB
MovVarArgF y ;lade Variable y mit Argument
Die Anordnung und der Inhalt der Macros ist das, was auch SDCC (oft) so
macht. Quasi ein Handgestricktes C-Programm.
...nun gehe ich wieder meinen Simulator quälen...
Mit Gruß
Pieter
@Pieter:
> Da hast Du ja schon das Programm, aber ob das so einfacher wird?> Im SDCC gibt es dazu schon _gptrput, _gptrget...also nur das Gerüst.> Derzeit kann ich mir auch nicht so recht vorstellen, wozu man das so> umständlich brauchen können sollte...
Bei reinem Assembler macht's denke ich keinen Unterschied bzw. nur dann,
wenn sich die Adressen beispielsweise überlagern, und das umgeht man
dann eher mit einer OVERLAY-Direktive (sofern unterstützt).
Ralf
moin Ralf,
OVERLAY:
Bedeutet für mich, ich kann z.B. den Adressbereich 8000H..0FFFFH
mehrfach als Bank nutzen. Die Bankumschaltung kann z.B. per Port
erfolgen.
Bis auf die Trennung im Bin sollte das mit meinem Assembler gehen,
werden diese Programmmodule per Include eingebunden stellen auch die
internen Namen kein Problem dar. Werde ich mal testen.
Mit Gruß
Pieter
Hi Pieter,
> OVERLAY: Bedeutet für mich, ich kann z.B. den Adressbereich 8000H..0FFFFH> mehrfach als Bank nutzen. Die Bankumschaltung kann z.B. per Port> erfolgen.
Genau, aber das bezieht sich auf den Codespeicher. Bei
nicht-Assembler-Sprachen (z.B. C) gewinnt auch das Data-Overlaying an
Bedeutung: Lokale Variablen einer Funktion können mit lokalen Variablen
einer anderen Funktion überlagert werden, sofern die eine Funktion die
andere nicht aufruft. Der Vorteil: Es können wesentlich komplexere
Applikationen trotz relativ beschränktem on-chip-RAM geschrieben werden.
Selbst bei Assemblerprogrammen kann das sinnvoll sein, wenn ein
Datensegment OVERLAY unterstützt.
Und eine "Spezialform" des OVERLAYINGs ist das von mir o.g. Verfahren,
mit dem man Zugriffe auf jedwede Schnittstelle in Form von ganz normalen
Variablenzugriffen realisieren kann, indem die Zugriffsfunktion
"umgebogen" wird - von XDATA auf I2C, etc.
Ralf
moin Ralf,
also bei Variablen mache ich das schon lage so, ein Speicherplatz hat
mehrer Namen und so "teilen" sich verschiedene Funktionen den selben
Speicher.
Beim Codesegment müste das *.BIN geschlossen und ein neues z.B. mit
*.001 angelegt werden. In der derzeitigen Version müste man mit DS den
Bereich auffüllen und dann mit einer ORG xxx (wieder) neu Anfangen.
Mit Gruß
Pieter
Hi Pieter,
> also bei Variablen mache ich das schon lage so, ein Speicherplatz hat> mehrer Namen und so "teilen" sich verschiedene Funktionen den selben> Speicher.
Das heisst, es wird keine Warnung ausgegeben?
> Beim Codesegment müste das *.BIN geschlossen und ein neues z.B. mit> *.001 angelegt werden. In der derzeitigen Version müste man mit DS den> Bereich auffüllen und dann mit einer ORG xxx (wieder) neu Anfangen.
Okay, aber das liegt an der Arbeitsweise des Assemblers, oder?
Jedenfalls ist das ja nur für Code-Banking relevant. Oder gibt's auch
andere Anwendungsfälle?
Ralf
moin Ralf,
die Adresszuordnung lasse ich i.d.R. den Assembler machen, z.B. so:
Anmerkung: es gibt für jedes Segment einen eigenen PC:
;-----aus FPU.MAC----------
ISEG
_sin_cos_x:
_atan2f_x:
_tancotf_x:
_asincosf_x: DS 4
_tancotf_y:
_sincosf_y:
_asincosf_y:
_atan2f_y: DS 4
;-------------------------
Cond ?_bp
_bp: DS 1 ;wenn locale Variablen da sind
EndC
TabN: DS 1
;------------------------
BSEG
_isACoSin:
_isCoTan:
_isCoSin: DS 1
_tancotf_odd:
_asincosf_sign:
_atanf_sign:
_sincosf_sign: DS 1
;------------------------
CSEG
Da ich hier selber die Mehrfachnutzung angebe, warum soll eine Warnung
ausgegeben werden?
Da im ASM keine Typangaben möglich sind, woher soll der Assembler
wissen, ob sich Speichebereiche für Variablen überschneiden? Das würde
passieren wenn die Variablen per EQU auf bestimmte Werte "festgenagelt"
werden.
Da der Assemble mehrere Durchläufe macht, wird natürlich die Konstanz
der Adresswerte geprüft.
zum Overlay:
Bisher gibt es kein Overlay, alles Programm wird in eine Datei
geschrieben.
Mit Overlays sind die dann getrennt abzulegen.
Das mit Variablen..da tu ich mich schwer.
Mit Gruß
Pieter
Hi Pieter,
> Da ich hier selber die Mehrfachnutzung angebe, warum soll eine Warnung> ausgegeben werden?
An und für sich korrekt, aber falls mal jemand anders mit deinem Tool
arbeitet und aus Versehen überlagert, wäre eine Warnung evtl. hilfreich.
Da aufgrund der Arbeitsweise des Assemblers der komplette Sourcecode in
einem File steckt ist es denke ich nicht so kritisch wie bei einem
verteilten Sourcecode.
> Bisher gibt es kein Overlay, alles Programm wird in eine Datei> geschrieben.> Mit Overlays sind die dann getrennt abzulegen.
Versteh ich nicht, was hat Overlay mit "in einer Datei" zu tun?
> Das mit Variablen..da tu ich mich schwer.
Glaub ich, das ist bestimmt auch nicht einfach umzusetzen. Prinzipiell
wie gesagt eher für Hochsprachen, höchstens bei relativ großen
ASM-Projekten auch interessant.
Ralf
Pieter schrieb:>> @Wilhelm>>>>y=a-b>> sieht bei mir in ASM so aus> PushVarF b ;lege Variable b auf Stack> MovArgVarF a ;lade Argument mit Variable a> Gosub _fssub ;das SUB> MovVarArgF y ;lade Variable y mit Argument>> Die Anordnung und der Inhalt der Macros ist das, was auch SDCC (oft) so> macht. Quasi ein Handgestricktes C-Programm.>> ...nun gehe ich wieder meinen Simulator quälen...> Mit Gruß> Pieter
Ich hab noch mal das SDCC-Manual zum Assembler und Linker gelesen. Es
ist definitiv kein Macro-Assembler. Im Augenblick bastele ich mir
Konstrukte, um Registerbänke zu setzen, und automatisch die richtigen
Register in der verwendeten Bank zu pushen und zu poppen, und bei
Rückkehr die alte RB wieder herzustellen. Eine Menge Überlegungen.
Aber, was du kannst, kann ich auch:
Ein Makro aus dem ASM51:
Da blickt aber keine Sau mehr durch, noch nicht mal auf Anhieb ich
selbst, was ich vor 12 Jahren selbst erstellte. Es ist kaum wirklich
Assemblercode drin.
Diese Makro-Konstruktion füllt den restlichen leeren Speicher mit einem
Muster, was den Controller bei einem eventuellen Absturz in diesen
Speicherbereich wieder fängt. Der Standard-8051 hat keinen Watchdog,
aber es gibt viele andere Troubleshooting-Methoden. Die Idee hatte ich
von Profis, aber die Makros erstellte ich selbst.
Da ich durch meinen anderen Thread Simulator 8051 jetzt an die DOSbox
(DOS-Emulator) gekommen bin, überlege ich aber tatsächlich, auf meinen
alten schönen ASM51 wieder einzusteigen. Aber nur für Assembler-Projekte
mit dem 8051, und das werden so viele gar nicht mehr. Immerhin kann ich
durch DOSbox jetzt aber auch meinen uralten Code mit den alten Tools
warten und evtl. überarbeiten.
Thread beobachten
Seitenaufteilung abschalten