Hallo, liebe Leute, hat mal jemand eine Idee, ob es fürs Hobby auch einen einfachen Freeware-C-Compiler für den 80C517A (bzw. 8051, würde sicher reichen) gibt, der mehr als 2 kB Code macht? Habe aus den 1990-er Jahren noch ein paar Mikrocontroller-Boards mit Siemens (Infineon) 80C515A- und 80C517A-Controllern hier herumliegen. Diese möchte ich für ein Hobby-Projekt mal wieder zum Leben erwecken. Hatte diese Boards früher mal auf Assembler programmiert, aber man entwickelt sich ja weiter und steigt auch mal auf eine Hochsprache wie C um, die ich mittlerweile recht gut beherrsche. Fürs Hobby, bekommt man höchstens mal eine Demo-Version eines Compiler-Herstellers, die auf 2 kB Code begrenzt ist. Da ist kurz nach "Hello World" schon Ende. Und eine Vollversion, ist fürs Hobby zu teuer. Floating Point, denn dadurch sind die Compiler oft begrenzt, brauche ich auch nicht unbedingt. Eine Windows-Oberfläche mit Projekt-Tree wäre nicht unbedingt erforderlich, da ich auch unter DOS mit Makefiles prima zurecht komme. Einen alten 486-Rechner habe ich noch, worauf auch der EPROMMER läuft, und auch genügend EPROMs. Ich wäre für jeden Hinweis sehr dankbar.
Hallo, nimm die IDE µC/51 von Wickenhäuser, damit haben wir gute Erfahrungen gemacht: in der kostenlosen Demo-Version bis 8 kByte Codegröße (incl. float), Vollversion für weit unter 100,00 Euro erhältlich. www.wickenhaeuser.de Gruß Carlos
Danke schon mal an alle für die wertvollen Tips! Selo: Sicher werde ich mir erst mal den SDCC anschauen, den ich vor längerer Zeit auch schon mal für den PIC herunter geladen hatte. Carlos: Wickenhäuser, mit 8 kB kann man schon mal ein kleineres Projekt anfangen. Und 100 Euro für mehr, wären auch noch im Rahmen des Normalbürgers. lontano: 88 Euro mit Floating Point, auch nicht schlecht!
Hallo nochmal, habe mir letztens den von Mathi genannten sdcc herunter geladen. Die Datei heißt "sdcc-src-2.7.0.tar.bz2". Irgendwie kann ich damit nichts anfangen, einfach entzippen ist auch nicht. Was muß ich denn hier noch tun? Hat mal jemand einen Tip?
Das ist eine bz2 Datei. Die "normalen" Packprogramme können das nicht entpacken. Für welche Plattform willste das denn benutzen? Wenn Windows, lade Dir doch lieber ein zip oder die exe. Unter Linux benutzt Du das Kommandozeilenprogramm bzip2.
Mathi: >Wenn Windows, lade Dir doch lieber ein zip oder die exe. Ja, es soll unter Windows oder DOS laufen. Ich war auf der Seite: http://sourceforge.net/project/showfiles.php?group_id=599 Dort kann man nur dieses Format downloaden. Für einen Link zu einem Zip-Format wäre ich natürlich sehr dankbar. Ich habe auch "sdcc-2.7.0-setup.exe" gedownloaded. Scheint aber was anderes zu sein, Simulator und/oder Debugger, oder? Na ja, ich probiere es morgen mal aus. Wenns nicht geht, frage ich nochmal. Danke.
Gehe am Besten über http://sdcc.sourceforge.net/ Da unter download das win-package wählen... Das bz2 unter dem Link den Du gepostet hast, ist nur die Linuxvariante. Die neueste Datei heißt sdcc-20071209-4976-setup.exe
@Rumpel: Du warst schon auf der richtigen Seite http://sourceforge.net/project/showfiles.php?group_id=599 allerding hast du dir den Quellcode heruntergeladen (src steht für source). Als Windowsbenutzer ist es für dich einfacher, wenn du dir das Package mit dem Titel sdcc-win32 holst. Hier ein direkter Link zu dem Package: http://sourceforge.net/project/showfiles.php?group_id=599&package_id=28921 Dort musst du jetzt nur noch die Datei sdcc-2.7.0-setup.exe herunterladen. Dieses ist die aktuellste Version zu dem Zeitpunkt als ich diesen Text geschrieben habe.
Mathi, tom: Danke euch nochmals für die schnelle Hilfe. Dann war mein zweiter Download "sdcc-2.7.0-setup.exe" sicher doch richtig. Kann es trotzdem erst bei Tagesanbruch wieder testen, da heute schon etwas spät. Meine Batterien sind leer! Gute Nacht!
Ja, die Installation hat prima geklappt. Nun, da ich keine Oberfläche habe, was aber auch kein Schaden ist: Hat mal jemand für SDCC und 8051 ganz einfache Demo-Files, z.B. startup.asm, main.c, und dazu ein Linker Script, wegen der Syntax? Vielleicht ein makefile.bat? Ich möchte ja zunächst nur mal eine LED blinken lassen. Aus Zeiten von DOS erinnere ich mich, daß es da auch DOS-Steuerzeichen im Linker-Script-File gab, z.B. Zeilenverlängerung. Normalerweise, würde ich Assembler und Compiler zeilenweise in einem Batch-File makefile.bat abarbeiten lassen, wie aus DOS gewohnt. Mein Betriebssystem ist das alte WIN-ME. Das wäre nur zum abgucken, um nicht tagelang ins offene Messer zu laufen, um mir die Neugestaltung etwas zu vereinfachen. Denn, alleine mit der Syntax, kann man auch schon mal locker 3 Tage verbringen. Von "Hello World" bin ich noch etwas entfernt.
Benutze als grafische Oberfläche MIDE-51, da brauchst Du nur noch den Pfad zu SDCC einzustellen. Die Linkereinstellungen können nicht verallgemeinert werden, da diese vom konkreten 8051-Typ bzw. den externen Speicherausbau abhängig sind. http://www.opcube.com/home.html
Matthias:
>Grafische Oberfläche MIDE-51
Ich hatte in einer Firma mal mit Keil µVision gearbeitet, das war
natürlich schon sehr komfortabel, ist aber ein High-End-Tool.
So ne grafische Oberfläche wäre natürlich sehr genial. Eventuell mit
Project-Tree, Output-Window, und und mit Editor, der die Sprachelemente
aus C noch highlighted???
An sowas, hatte ich zunächst gar nicht gedacht.
Ich schau mir das mal an.
Danke für den Link!
Der Keil ist kostenfrei bis 4kB (8?) Codesize. Ich kann den wärmstens empfehlen.
Keil ist zurecht der Marktführer, was die Vollversion angeht. Aber nicht gerade billig, gut 2.500 Euro mußt Du schon anlegen. Die Demoversion hingegen hat einige Einschränkungen. Besonders negativ ist der erzwungene 2K Offset, womit kleinere Controller praktisch ausgesperrt werden. Float-Support fehlt ebenfalls. Es soll ein kostenloses Paket von Cypress (incl. Keil) geben, was nicht soviele Einschränkungen hat. Probiert habe ich es noch nicht. http://www.cypress.com/portal/server.pt?in_hi_opt_comm_community=223&in_hi_space=SearchResult&in_hi_control=bannerstart&in_tx_query=Keil SDCC erzeugt zwar nicht so effizienten Code wie Keil, ist jedoch völlig ausreichend und SDCC ist sehr gut dokumentiert. Es gibt keine Code-Beschränkungen. Zusammen mit der MIDE-51 eine brauchbare Entwicklungsumgebung.
Hallo, was spricht denn eigentlich gegen µC/51 von Wickenhäuser: alles dran und alles drin, keine Einschränkungen in der Demo, nach der Installation sofort lauffähig, muß nicht erst zusammengebaut werden, in der Demo bis 8 kByte, Vollversion für ca. 80,00 EURO Carlos
>was spricht denn eigentlich gegen µC/51 von Wickenhäuser
Eigentlich nichts, wenn man es erstmal zum laufen gebracht hat.
Einige Nachteile gibt es doch. µC51 ist ein guter C-Compiler. An die
Effektivität von Keil kommt er jedoch nicht heran. Hauptproblem ist die
umständliche Bedienung über den MakeWiz. Eine ordentliche IDE fehlt
ganz, die haben die Programmierer vergessen. Damit wird das ganze Paket
Benutzerunfreundlich. Bei Keil sind alle Funktionen in die µVision
integriert und ist damit sehr leicht zu bedienen.
Was bitteschön ist denn an der Entwicklungsumgebung von Keil so überragend gut, dass der doch erhebliche Preis gerechtfertigt wäre? Ich "durfte" vor einigen Wochen mehrere 8051 Projekte (Atmel 89C55, Silabs 8051F005 und ein Dallas Derivat) übernehmen, die unter Keil PK51 als Mischmasch aus Assembler und C realisiert sind. Der älteste Code stammt aus 1996 und alle weiteren Projekte bauen darauf auf. Die ersten Gehversuche haben mir nichts wesentliches offenbart, was ich nicht von dem seit 6 Jahren benutzten Microchip MPLAB schon kennen würde.
Der Preis von Keil für die C51-Produkte sind sehr hoch, da hast Du recht. Das war schon vor 15 Jahren so. Offenbar ist das für kommerzielle Anwender kein Problem. C-Compiler und Assembler sind in die µVision integriert. Natürlich geht auch alles noch auf Kommandozeilenebene, dann aber viel Einstellungsarbeit.
Hallo, bei µC/51 starte ich einmalig am Anfang des Projekts den MakeWiz, mache 4-5 Einstelllungen, die bei Keil auch notwendig sind, danach speichere ich diese Projektdaten ab und brauche ab dann nie mehr mit MakeWiz zu arbeiten, der Rest läuft komplett über den Editor ab, der dann eben meine "kleine" IDE ist. Gerade als Anfänger oder als "One Man-Programierer" benötige ich doch keine riesige Projektverwaltung, die für 2,3,5,... Programmierer geeignet ist, die an einem Projekt arbeiten. Und die wirkliche Effektivität eines C-Compilers in "allen" Situationen zu beurteilen und zu bewerten, ist auch nicht ganz trivial. Carlos
Matthias wrote: > Natürlich geht auch alles noch auf Kommandozeilenebene, dann > aber viel Einstellungsarbeit. Dem muß ich heftigst widersprechen! Ich arbeite mit nem 1995-er Keil C51 auf der Kommandozeile und muß genau Null,nix einstellen. Einfach C,Enter drücken, fertig: Beitrag "MAKEFILE vs. BAT" Peter
Hallo, also wenn ich mir als Anfänger anschauen würde, wie solch ein mak- bzw. bat-File zusammenzubauen ist, dann doch lieber ein Paar Klicks z.B. in MakeWiz: wo man auch noch verstehen kann, warum das so ist und das End-Ergebnis (Intel-HEX-File) dann auch noch (fast) das Gleiche ist. Carlos
Carlos wrote: > Hallo, > also wenn ich mir als Anfänger anschauen würde, wie solch ein mak- bzw. > bat-File zusammenzubauen ist Da ist auch nix zusammen zu bauen, es ist fertig, man muß es nur ausführen. Peter
Peter schrieb: >> Natürlich geht auch alles noch auf Kommandozeilenebene, dann >> aber viel Einstellungsarbeit. ... >Ich arbeite mit nem 1995-er Keil C51 auf der Kommandozeile und muß genau >Null,nix einstellen. >Einfach C,Enter drücken, fertig: Das man die Einstellungsarbeit auch in einer .BAT zusammenfassen kann ist klar;-) Ich habe noch eine Keil-Version 3.2 von 1991. Die läuft immernoch problemlos. Der hierbei erzeugte Code ist bei entsprechender Optimierungseinstellung kompakter als bei SDCC in der aktuellen Version. µVision gabs damals noch nicht.
T.H.: >Der Keil ist kostenfrei bis 4kB (8?) Codesize. Ich kann den >wärmstens empfehlen. Na, wo ich doch schon mit 2 kB und Hello World gegen die Wand fahre, sind 4 kB auch nicht der Renner. Meine 80C517A-Boards sind speichermäßig voll ausgebaut, haben 64 kB Codespeicher und 64 kb Datenspeicher. In Assembler, so wie früher, möchte ich die nicht "nur" mehr programmieren. Mein alter Assembler ASM51 von Ashling Microsystems ist zwar nicht codelimitiert, verlangt jedoch einiges an Know-How in der Codegestaltung, z.B. bei AD-Wandler-Umrechnungen, da muß man BIN-BCD-Wandlungen selbst von Hand und zu Fuß erstellen und scalieren, und nur für den einen festen Zweck, das kostet sehr viel Zeit. Funktioniert, hat es schon. An Codegrößen um einige wenige kB kann man da schon Wochen arbeiten. Portierbar ist der Code auch nicht so leicht. Eine effektive Programmierung in Hochsprache spart also sehr viel Zeit und ist wiederverwendbar. Über den SDCC hab ich noch nichts in Bezug auf Codelimitierung gefunden. Wahrscheinlich hat er auch keine. Hatte vor einiger Zeit auch mit dem unter Keil µVision supporteten GCC-Compiler für ARM gearbeitet, der ist in Codegröße nicht limitiert. Damit entwickelte ich z.B. den kompletten CAN-Bus-Treiber inclusive FIFOs und eine kundenspezifische Protokollumsetzung, bevor auf den Keil-Compiler umgestellt wurde. Spürbare Unterschiede in der Performance gab es da nicht. Die 16 kb Limitierung für den ARM in der Demo-Version, gelten nur für den Debugger, übertreffen damit die generelle Codelimitierung auf 2 kB für 8051 um ein Vielfaches. Matthias: >Keil ist zurecht der Marktführer, was die Vollversion angeht. Aber nicht gerade billig, gut 2.500 Euro mußt Du schon anlegen. Nee, in High End Tools, sind die natürlich unschlagbar, aber der Preis, für einen Hobby-Anwender??? >Die Demoversion hingegen hat einige Einschränkungen. Besonders >negativ ist der erzwungene 2K Offset, Reicht nämlich nur für "Hello World"... Meinetwegen, kann so ein SDCC gerne mal 30 Prozent mehr Code erzeugen, wenn er sonst nicht eingeschränkt ist? GCC für ARM, funktionierte auch reichlich gut, obwohl nicht so optimiert wie von einem kommerziellen Compilerhersteller. Carlos: >Wickenhäuser, hattest du vor ein paar Tagen schon erwähnt, und ich hab es nicht vergessen. Werde ich natürlich auch im Auge behalten. 80 Euro ist normalerweise absolut nicht die Welt, aber bin zur Zeit leider arbeitssuchend und nicht so reichlich flüssig... Dieter Werner: >Was bitteschön ist denn an der Entwicklungsumgebung von Keil >so überragend gut, dass der doch erhebliche Preis gerechtfertigt >wäre? Wenn man ein Projekt in µVision konfiguriert hat, und schon etwas mit µVision zu tun hatte, geht es in der Regel aber ganz gut. Alte, nicht selbst erstellte, und womöglich schlecht dokumenierte, Software, zu warten, die Suche nach der Stecknadel im Heuhaufen, ist natürlich eine ganz eigene Geschichte. Und den Preis des Entwicklungstools, den schreiben die Firmen doch eh als Betriebsmittel ab, zahlen doch du und ich, nämlich doch der Steuerzahler. Carlos, Peter: >...also wenn ich mir als Anfänger anschauen würde, wie solch ein >mak- bzw. bat-File zusammenzubauen ist, ... Ja, das war auch eine meiner Fragen, ob ein .bat oder .cmd -File heute unter meinem alten WIN ME genau so funktioniert wie früher zu DOS-Zeiten... Wenn man nicht schon in alten Zeiten unter DOS mit Stapelverarbeitungsdateien gearbeitet hat: Kann ich verstehen, da ist manches Grundverständnis nicht so da. Optimierungen, wollte ich nicht mal sprechen. Darum kümmere ich mich, wenn ich mal bei 48 kB Code angelangt sein sollte, dann weiß ich ohnehin mehr, vorher nicht. Ich werde mich jetzt doch mal so um die veranschlagten 3 Tage mit den Manuals zum SDCC beschäftigen, bis ich "Hello World" schreiben oder eine LED blinken lassen kann, den alten 486 mit dem EPROMMER wieder in Gang setzen. Wenn das denn alles ist ... Im Grunde, scheint SDCC sowas zu sein wie GNU bzw. GCC, wie ich von den Downloadseiten und den Manuals her feststellte. Es lohnt sich dann sicher, sich damit zu beschäftigen.
Mann, was ist das ein Kreuz mit dem SDCC! Im Forum finde ich beim Suchbegriff zum SDCC oft auch 0 Antworten zu relevanten Threads aus den letzten Jahren. Ich hatte es geahnt, hunderte Seiten Manuals lesen, bis man das Teil mal einigermaßen konfigurieren kann. Dabei will ich komplett unabhängig von einer Bedienoberfläche sein, und bearbeite gerade ein DOS-Batch-File als Make-File. Seit heute, und einer Woche Konfigurierung, funktioniert das Teil ein klein wenig, aber mehrfach von hinten durch die Brust ins Auge. Zunächst, macht SDCC aus dem Code ein wild durcheinander geratenes Intel Hex File, welches kein Format-Converter mehr versteht. Am Ende, bin ich durch das Manual noch an den Hinweis geraten, bei sourceforge.net ein weiteres Format Converter Tool zu downloaden, um das Intel Hex File in ein vernünftiges Format zu bringen, wo die Adressierung eine kontinuierlich aufsteigende Reihenfolge hat, so daß das Intel Hex File von Format-Convertern gelesen werden kann. Das hilft ein wenig, aber es funktioniert nach wie vor nichts, obwohl das Format des Intel Hex Files OK zu sein scheint. Nach tagelangem Probieren, bin ich denn mal auf die Idee gekommen, das Intel Hex File genauer anzuschauen, da ich auch Anfang 1990 schon mal mit 8051 Maschinencode anfing, und diesen deshalb ein wenig interpretieren kann. Und siehe da, das Hex-File ist Bullshit, da steht eine überflüssige Zeile drin, die dort nichts zu suchen hat. Habe ich diese Zeile, die erste Zeile, einfach gelöscht, sieht das Intel Hex File gesund aus. Da funktioniert auch mein Format-Converter nach Motorola S1F, S2F, oder S3F, denn nur diese Formate versteht mein alter EPROMMER. Das ist doch nicht wahr, oder??? Jetzt, blinkt an meiner Hardware wenigstens mal eine LED in einer for-Schleife. Welch ein enormer Fortschritt! Ich wollte schon immer mal LED-Blink-Programmierer werden:-) Konkret, brauche ich vom SDCC-Compiler für das Hex-File ein Motorola-Format S1F, S2F, oder S3F. Die Format-Tools von sourceforge.net machen wiederum nur Motorola S19, das ist schon wieder was ganz anderes für mich völlig unbrauchbares. Nun ja, die Sache ist immer noch vielversprechend, da ich immer näher ans Ziel komme, aber verdaaaaaammmmmmmtttttttt laaaannnggssaaammm. Wenn jemand eine Idee hat, wäre ich wiederum sehr dankbar.
Ich habe SDCC + MIDE-51 installiert und konnte sofort arbeiten. Auch hatte ich noch kein Problem, das Hex-File zu laden. Es gibt beim HEX-Format meines Wissens keine Festlegung, dass die Daten aufsteigend sortiert sein müssen. FLIP, ATMELISP, Dybkrowski, hex2bin ... haben keine Verarbeitungsprobleme damit. Vielleicht liegt es an Deinen Formatkonvertern. Was hast Du für einen Prommer, der kein hex-Format laden kann?
Rumpelstilz wrote: > Zunächst, macht SDCC aus dem Code ein wild durcheinander geratenes Intel > Hex File, welches kein Format-Converter mehr versteht. > > Am Ende, bin ich durch das Manual noch an den Hinweis geraten, bei > sourceforge.net ein weiteres Format Converter Tool zu downloaden, um das > Intel Hex File in ein vernünftiges Format zu bringen, wo die > Adressierung eine kontinuierlich aufsteigende Reihenfolge hat, so daß > das Intel Hex File von Format-Convertern gelesen werden kann. Was isn das fürn komisches Ding, dieser Format-Converter? Ein Hex-File muß nicht sortiert sein, dazu hat ja extra jeder Record seine Adresse. Der Keil C51 sortiert seine Records auch nicht. Wenn man so komische Programme hat, die ein normales Intel-Hex nicht lesen können gibts von NXP hex2hex zum Umwandeln: http://www.nxp.com/files/products/standard/microcontrollers/download/80c51/utilities/hexutils.zip > Und siehe da, das Hex-File ist Bullshit, da steht eine überflüssige > Zeile drin, die dort nichts zu suchen hat. Dann zeig dochmal die Zeile. Peter
Nach ein paar Tagen, bin ich wieder etwas weiter: Matthias: Der alte EPROMMER funktioniert jetzt am Windows-Hyperterminal einwandfrei, der hat eine Art Befehlssatz wie ein MODEM. Das hat eine Weile gedauert, auf dem alten 486-er hatte ich eine Bedienoberfläche, die seit Windows ME auf dem P3 auch im DOS-Fenster nicht mehr funktionierte und den Rechner komplett abstürzte. Ohne die Bedienoberfläche ist das jetzt etwas mühsamer, aber es geht einwandfrei, und nach etwas Gewöhnung auch genau so schnell! Am Hyperterminal kann ich jetzt die Programmierparameter setzen, Dateien uploaden und EPROM-Inhalte downloaden. Was ich herausgefunden habe: Das Motorola s1f-Format ist beim EPROMMER ein etwas anderes als das bei SDCC. Für den EPROMMER, muß die letzte Zeile des s1f-Formates mit S9 beginnen und danach die nächste Adresse folgen. Habe diese Formate vom Rechner ins EPROM gebrannt, zurückgeladen, gespeichert, aus der gespeicherten Datei wieder EPROM gebrannt, also, das Hin- und Herspielen funktioniert fabelhaft. In der Anleitung des EPROMMERS, ist das Motorola s1f-Format genauestens beschrieben. Deshalb wundert mich so manches. SDCC macht sogar direkt ein Motorola s1f-File, dessen letzte Zeile jedoch nicht mit S9... und der folgenden Adresse beginnt, sondern mit S5 und einer Zahl, die nichts mit nachfolgender Adresse zu tun hat. Und hier spinnt der EPROMMER, und meldet Format-Error. Werde jetzt im Internet nochmal nach Motorola-Formaten suchen. Na ja, die Chose geht weiter, ich werde sicher wieder berichten... Peter: Irgendwo ist bei SDCC sonst noch ein Haken: Vom SDCC Format Converter bekomme ich folgende Meldung: SREC_CAT-EXE: main.hex: 3: warning: data records not in strictly ascending order. expected = 0x006C, got 0x0003 Das sind die unsortierten Zeilen im Intel Hex-Record, was anderes habe ich dazu nicht gefunden. Vor der Format-Konvertierung, bekomme ich vom Compiler selbst keine Fehlermeldung, und List- und Map- Files sehen gut aus. Wie das Intel-Hex-File aussieht, siehe Dateianhang.
>Der alte EPROMMER funktioniert jetzt am Windows-Hyperterminal >einwandfrei, der hat eine Art Befehlssatz wie ein MODEM. Das kenne ich, habe noch ein DATIO 2900 vom Anfang der 90ziger. Da hatte der PC auch nur die Terminalfunktion. Das kommt jedoch mit allen Formaten klar. Was hast Du für einen EPROMMER?
Matthias: >Was hast Du für einen EPROMMER? Ein uraltes Teil, 1992 bei Conrad gekauft, verträgt aber nur Mororola-S-Dateiformate. Nun, das ist dank Fileconvertern ja nicht weiter schlimm. Hersteller ist die niederländische Firma COMDIS. Nachdem die bequeme Bedienoberfläche mit Hex-Editor (auf dem 486-er für DOS und Windows 3.10) unter neueren Rechnern leider nicht mehr funktioniert, betreibe ich den dank der sehr guten Bedienungsanleitung mit exakter Beschreibung aller Programmierparameter, jetzt am Windows HyperTerminal wie ein Modem, denn es gibt sowas wie einen Makro-Befehlssatz. Und externe Hex-Editoren gibt es ja auch. Ansonsten: Hurra, nachdem ich euch nun genug zum SDCC strapaziert habe, funktioniert mittlerweile auch einiges: Es ist etwas mühsam, wenn man mal eben keine 2000 Euronen für ein professionelles Tool hat, welches auf Anhieb funktioniert, aber es lohnt sich auf jeden Fall, sich mit dem SDCC-Compiler zu beschäftigen. Mit teuren High-End-Produkten war ich auch etwas verwöhnt. Es soll auch eher für den Hobby-Bereich sein. Ich habe jetzt einen Freeware-C-Compiler für zunächst 8051, und meinen speziellen Siemens 80C517A, SDCC, der wunderbar funktioniert!!! Da funktioniert mittlerweile ein Timer-Interrupt, welcher noch mit einem reinen Assemblerfile und Übergabeparametern zum präzisen Reload interfaced ist. Auch die serielle Ausgabe auf Schnittstelle 2 des 80C517A. In den Libraries findet man ein FIFO zu den seriellen Schnittstellen, sehr komfortabel! Weiter hab ich noch nicht getestet, wie z.B. Floating Point oder Code- und Datengrößen. Mittlerweile hab ich das bei Sourceforge.net geladene Formatkonvertierungsprogramm sreg_cat wieder aufgegeben. Es erzeugt Motorola Start- und End- Records, mit denen weder ich noch der EPROMMER was anfangen kann. Nach ständig wiederholtem Lesen des Manuals und Suche nach bestimmten Beschreibungen, denn man kann so ein Manual ja nicht vom Anfang bis zum Ende wie einen Roman lesen und merken, fand ich eine Möglichkeit, dem Compiler bzw. Linker zu sagen, daß er anstatt des Intel-Hex-Files sofort ein Motorola-S1-File erzeugen soll. Und siehe da, der alte EPROMMER von 1992 frißt es, da dieses Motorola-Format mit dem alten EPROMMER kompatibel ist, alle Zeilen mit S1 beginnen und die letzte Zeile mit S9. So stellte ich es mir auch vor. Ich habe immer noch keine Oberfläche und arbeite mit einem selbst erstellten Make-File. Einmal Enter-Taste drücken, das Ding wühlt ein paar Sekunden, und fertig. Die Konfigurierung für den Compiler und den alten EPROMMER funktioniert mittlerweile prächtig, hat mich aber insgesamt jetzt 1 Monat Zeit gekostet: Täglich zwischen 1 und 2 Stunden, und auch mal Pause. Einen Editor oder IDE, wo C-Syntax highlighted wird, werde ich auch noch finden. Es gab hier ein paar Vorschläge für eine IDE, die werde ich auch noch mal durchgehen. Wie ich die speziellen Features des 80C517A noch implementiert bekomme (Hardware-MDU, für superschnelle Floating Point Arithmetik, oder Multiple Data Pointer), und wie weit das nötig ist, na, das muß ich noch sehen. Denn das bietet der SDCC nicht. Meine Hardware (OptoNetMini von Feger&Co.) hat 2 ROM-Bänke und 2 RAM-Bänke alle je 32 kB, also Vollausbau, und auch noch konfigurierbar (z.B. 1 RAM-Bank als ROM bei Adresse 0x8000). Mein nächster Schritt ist ein Basis-EPROM, in dem alle Vektoren stehen, ein Mapping derer ins RAM, und eine Download-Routine für Motorola-S-Files ins RAM. So ähnlich machen das auch die Monitor-Programme. Da muß ich auch auf alter Hardware ohne Flash, nicht immer neue EPROMs brennen, und kann Testprogramme auf einfache Weise über Windows HyperTerminal ins RAM laden. Und es ist ebenso komfortabel wie mit Flash. ...
Lass die Finger vom µC51 von Wickenhäuser. Das Ding ist voller Fehler und wenn man dem Herren Hersteller einen Fehler mitteilt, bedankt er sich zwar dafür, aber er ändert meistens nichts. Ich habe mit dem Ding nur negative Erfahrungen gemacht, die mich schon bald Wochen gekostet haben. Ich verwende den SDCC und bin sehr sehr zufrieden damit.
>"Lass die Finger vom µC51 von Wickenhäuser.
Das Ding ist voller Fehler und wenn man dem Herren Hersteller einen
Fehler mitteilt, bedankt er sich zwar dafür, aber er ändert meistens
nichts."
Ich kann nur das Gegenteil davon behaupten: wir setzen den µC/51 schon
seit einiger Zeit in verschiedenen Projekten ein und bisher haben wir
noch keine Probleme gehabt.
Wenn was nicht funktioniert hat, haben wir gute Hilfe vom Hersteller
bekommen und bis her hatten wir selber eigentlich die Probleme mit C und
nicht der Compiler.
Dieser Compiler für 8051er bietet dennoch mehr als SDCC, zumal auch
floating-point problemlos läuft.
Carlos
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.