Hallo, siehe Betreff, geht das irgendwie? Ich finde in meiner Beschreibung nichts zu diesem "Oldie". Google liefert fast immer diese Seite: http://www.pjrc.com/tech/8051/ aber so richtig werde ich da auch nicht schlau.
Was verstehst du denn unter befummeln? Drück' dich klar aus, dann muß auch niemand raten, was du meinst. Nach dem, was ich errate: Klares Nein. mfg.
Naja, kann ich den im STK500 löschen, programmieren wie alle modernen Typen oder geht das garnicht? Was muß ich besorgen damit das geht? So war das gemeint.
Egon schrieb: > Was muß ich besorgen damit das geht? 89Cx051 sind nicht In-Circuit-Programmierbar. D.h. du brauchst ein Programmiergerät. Oder du baust dir selbst eins. Ist gar nicht so schwierig. Die Befehle sind gut dokumentiert. Am besten nimmst du dafür einen AVR. Jetzt wird's schon langsam unsinnig... Wenn es nur darum geht, ein paar Chips, die du für zu Schade zum Wegwerfen befunden hast, für irgendwas zu benutzen, lass' es. Wirf' sie weg. Oder frag' hier im Forum, ob sie einer haben will. Ich will sie nicht haben. Hab' selbst noch welche liegen. Die Dinger sind nicht mehr zeitgemäß. Was die AT89Cx051 können, können die AVRs auch. mfg.
Oder nimm zumindest die 89SXXXX typen, denn die lassen sich mit ISP seriell programmieren und brauchen keinen Parallelprogrammer. Die berühmte Ausnahme ist mal wieder der 89S8253, der sich mit meinem AVRISPMKII nicht beschreiben lässt . Übrigens, abgesehen von der umgekehrten Reset Polarität scheint der ATTiny2313 völlig pinkompatibel zum 89C4051 zu sein.
Matthias Sch. schrieb: > Übrigens, abgesehen von der > umgekehrten Reset Polarität scheint der ATTiny2313 völlig pinkompatibel > zum 89C4051 zu sein. Korrekt. Bis auf Reset ein Volltreffer. Und 10x schneller. mfg.
Rein technisch könnte das STK500 den 89C4051 programmieren (parallel programming). Aber die Atmel AVR-ler werden wohl mit den 8051-lern im Clinch liegen und daher unterstützt es die STK500 Firmware nicht. Lustiger Weise saß auf dem ersten STK Board ein 89C2051, um die AVRs zu programmieren. Peter
... es ist immer wieder "lustig" den "Streit" um den "besseren" Controller zu verfolgen und auch immer wieder "lustig" eine Diskussion um die bessere Familie zu haben: Wie so oft festgestellt wurde: AVR und MCS-51 sind nicht vergleichbar, nicht mal im Ansatz. Oft ist schlicht für ein gestelltes Problem die MCS-51 die günstigere (preislich) Wahl. Viel zu oft wird mit Kanonen auf Spatzen geschossen. Ein Controller ist dafür da, um eine bestimmte Aufgabe zu erledigen, je preiswerter das bewerkstelligt werden kann umso besser (in Hinsicht auf Hard- und Softwareentwicklung). Viele kleine Dinge gehen schlicht auch mit einem 89Cx051. Wer also soooooo viele von den soooooo veralteten Dingern zu verschenken hat: ich nehme gerne alle ! Gruß, Ralph PS: ich hab einen Selbstbaubrenner für den AT89Cx051 in Betrieb der super an der RS-232 funktioniert (auch mit einem USB-RS232 Adapter). Herzstück ist ein AT89S52. Betriebsspannung 5V (aus dieser wird per Stepup-Wandler - realisiert mit NE555 - auch die benötigten 12V Brennspannung erzeugt) Wenn da Interesse an einzelnen besteht kann ich das gerne auch mal jemandem mailen !
Ich habe meine schon alle verschenkt, und der Depp hat nichtmal das Porto überwiesen...
:-( schade.... smile aber ich hab ja auch noch genügend und außerdem sind die ja bei Rei***** auch nicht teuer (imho 1,60 Eur).
Ich muss auch mal sagen, das ich lange Jahre die MCS51 Familie benutzt habe und damit alle Aufgaben prima lösen konnte. Aber die Programmiererei/Flasherei war kompliziert und die Rechenleistung vor der Erfindung der WARP Prozessoren war doch sehr begrenzt. Damals war auch immer noch ein externes Latch und ein EPROM erforderlich ( die älteren werden sich noch erinnern) welches einige Portbeinchen gekostet hat. Nun sind die AVRs in Vielfalt und Preis einfach die moderne Alternative und durch die ISP Programmierung doch viel bequemer und man kommt recht schnell zum Ziel. Und durch AVR-GCC und die vielen Tools musst du auch nicht mehr unbedingt Assembler nehmen, ( Ich konnte mir die Keil Compiler nie leisten) und SDCC gabs eben noch nicht. Das soll nicht bedeuten , das die MCS51 schlecht sind, wohlgemerkt, aber die Zeiten ändern sich eben.
Ralph S. schrieb: > Wie so oft festgestellt wurde: AVR und MCS-51 sind nicht vergleichbar, > nicht mal im Ansatz. Ich finde sie schon vergleichbar. Sie sind für den gleichen Anwendungsbereich konzipiert (Steuerungen). Die AVRs benötigen für die gleiche Aufgabe mehr Flash, haben ihn aber auch. Die AVRs können manches nen Tick schneller, als der classic 8051 (XTAL/12), das kann dieser aber mit Interruptprioritäten wieder rausreißen. Der 8051 läßt sich besser in C programmieren (AVR-GCC ist umständlich bei Flash-Daten). In der Summe sind beide annähernd gleich. Warum ich den AT89C2051 nicht mehr für neue Sachen verwende, sondern den ATtiny, hat nur einen Grund: Ich bin beim Layouten faul und bei den AVRs brauche ich keinen externen Takt und Reset, spare also schonmal 5 Bauteile ein. Peter
Peter Dannegger schrieb: > Die AVRs können manches nen Tick schneller, als der classic 8051 > (XTAL/12) Nahezu keiner der Aktuellen 8051er muss mit einen zwölftel des Taktes laufen, die meisten haben auch einen "X2" mode, das ist dann F/6 und bei vielen steht "highspeed mcu" mit dran, die können dann meist einen Zyklus in einem Quarz-Takt abarbeiten. z.B. DS89C430/450 33Mips@33Mhz. > Der 8051 läßt sich besser in C programmieren (AVR-GCC ist umständlich > bei Flash-Daten). So ein Quatsch, nur weil du nich auswendig gelernt hast, wie man PROGMEM, EEMEM benutzt, oder zu faul bist 5 Zeilen Code zu tippen, heisst das noch lange nicht, dass ein 8051er besser für C geeignet ist. Ganz im Gegenteil, eine 8bit-Akkumulator-Architektur bedeutet 1000 Tode für einen Compilerprogrammierer und für den Entwickler, der die Macken im Erzeugten Code finden und umgehen darf. Als diese Art Architektur erdacht wurde, hat man die Leute ausgelacht, die stur alles in C auf Controllern machen wollten, wenn es die da überhaupt schon gab. Der 8051er Befehlssatz und die ganze Architektur ist erheblich einfacher in Assembler zu handhaben, vorausgesetzt, man will etwas mehr als nur mit ein paar Portpins wackeln. Wirklich grosse Vorteile bringen Hardware Multiplizierer usw neuerer Controller mit sich, aber die meisten der 8051er sind standard-8051+PWM+I²C... und das wars. Wirklich stark ertweiterte Kerne findet man fast nur in Industriellen Controllern, die dann meistens entweder schwer erhältlich oder nur in TQFP-1231231 zu bekommen sind. //edit: Beim zweiten Drüberlesen kommt mir das etwas "scharf" vor, fühl dich nicht angemeckert, so seh ich das nunmal und lass es aber jetzt auch so stehen ;)
Nils S. schrieb: > So ein Quatsch, nur weil du nich auswendig gelernt hast, wie man > PROGMEM, EEMEM benutzt, GCC liefert damit wirklich keine Glanzleistung ab. Bei den 8051er Tools wie Keil oder SDCC ist das Handling mit XDATA und CODE erheblich einfacher. Pointerprobleme wie bei AVR/GCC hatte ich dort noch nie.
Matthias schrieb: > GCC liefert damit wirklich keine Glanzleistung ab. Bei den 8051er Tools > wie Keil oder SDCC ist das Handling mit XDATA und CODE Dass das nicht gerade der einfachste Weg ist, ist klar. Aber AVRs haben nunmal keinen durchgehenden Speicherbereich für Daten und Code, somit ist das Umsetzungssache vom Compiler, wie auch bei den 8051ern. Nur weil man sich da ein wenig Code und nachdenken sparen kann, ist das kein Argument für eine bessere "C-Programmierbarkeit". Viel wichtiger ist, dass ein ordentliches Programm daraus entsteht.
Nils S. schrieb: > Nur weil man sich da ein wenig Code und nachdenken sparen kann, ist das > kein Argument für eine bessere "C-Programmierbarkeit". Soweit würde ich auch nicht gehen. Aber was GCC abliefert, ist im Vergleich zu den 8051er Tools schon etwas gewöhnungsbedürftig.
Nils S. schrieb: > So ein Quatsch, nur weil du nich auswendig gelernt hast, wie man > PROGMEM, EEMEM benutzt, oder zu faul bist 5 Zeilen Code zu tippen, Ich bin nicht zu faul. Ich will nur nicht einen Haufen inkompatiblen und unleserlichen Code schreiben müssen. Versuche mal, das hier für den AVR-GCC umzuschreiben: Beitrag "Re: uShell - ein universeller Parser für uCs" Ich habs aufgegeben. Wenn nicht unbedingt nötig, lasse ich die Konstanten im SRAM und nehme lieber einen AVR mit mehr SRAM. Ich will die standard C-Syntax für Pointer, Arrays, Union Structs usw. benutzen können. Der C51 kann das ja, das Schlüsselwort "code" reicht aus, um ihn die Plazierung und Zugriffsart erkennen zu lassen. Peter
Nils S. schrieb: > Der 8051er Befehlssatz und die ganze Architektur ist erheblich einfacher > in Assembler zu handhaben Ich hab ihn jahrelang in Assembler programmiert und kann das nicht bestätigen. Was der Keil C51 ausgibt, ist sehr effizient. Da muß man schon ein sehr guter Assemblerprofi sein, um ähnlich kompakt zu sein. An dem C51 hat mich nur geärgert, daß ich ihn nicht schon eher benutzt habe, sondern mich so lange mit Assembler abgequält habe. Peter
Keil ist natürlich einer der besten Compiler inkl. IDE, die man für Controller finden kann, nur für privat schlicht nicht bezahlbar, ausser man kann mit der Demoversion leben. Ob ich nun DATA, XDATA, code, ...-Geschichten verwende oder pgmspace läuft aufs Selbe hinaus -> nicht 1:1 portierbar und nicht im C-Standard. Dafür lässt sich das ganze, zwischen sdcc und keil, relativ leicht über #defines lösen. Das nächste ist, die komplette Hardware spricht sich auf AVR und 8051 anders an und der Code muss sowieso geändert werden. Da abstrahiert man im Code einfach Port/Registerzugriffe und eben auch Zugriff auf Flash und man muss nicht mehr sämtlichen Code durchegehen. >Versuche mal, das hier für den AVR-GCC umzuschreiben: >Beitrag "Re: uShell - ein universeller Parser für uCs" >Ich habs aufgegeben. Wenn nicht unbedingt nötig, lasse ich die >Konstanten im SRAM und nehme lieber einen AVR mit mehr SRAM. Ich hab eine kleine Shell auf mehreren Dimmern laufen. Dort habe ich z.B. 16Bytes Buffer eingerichtet für Befehle und 32bytes für Argumente. Pseudocode:
1 | funktionspointer = NULL; |
2 | |
3 | for(;;) { |
4 | get_input(&buffer_eingabe); |
5 | lookup_command(buffer_eingabe, &funktionspointer); |
6 | copy_arg(buffer_eingabe, &arg); |
7 | funktionspointer(); |
8 | }
|
Klar, dass ich dann in der lookup-Funktion mit pgmspace hantieren muss, aber das ist ja auch kein Problem. Genauso würd ich das auch für 8051er, ARM oder sonstwas machen. >Ich will die standard C-Syntax für Pointer, Arrays, Union Structs usw. >benutzen können. Der C51 kann das ja, das Schlüsselwort "code" reicht >aus, um ihn die Plazierung und Zugriffsart erkennen zu lassen. Aber Standard wäre wohl eher z.B.
1 | unsigned short *pointer; |
2 | pointer = 0x3000; |
3 | *pointer = 0x1234; |
Fehlt natürlich der Speicher, der sich so ansprechen lässt, bzw. ein Compiler, der das so auch noch ordentlich umsetzt. Man kann auch nicht anfangen einen Open Source Compiler qualitativ mit einem komerziellen Compiler zu vergleichen, in den seit bald 30 Jahren Haufenweise Geldmittel gesteckt werden. Das Ergebnis interessiert einen und wenn ich auf einem AVR 5 Zeilen mehr Code brauche und vielleicht noch ein paar Bytes RAM für temporäre Daten um mit Flash-Inhalt was anzufangen, ist das noch lange nichts im Vergleich zu riesigen Codes, nur weil die CPU keinen ordentliches mul usw. kann. Eine CPU auf der sich der Compiler alle Nase lang behelfen muss, ist nicht für Compiler gedacht.
Peter Dannegger schrieb: > Aber die Atmel AVR-ler werden wohl mit den 8051-lern im Clinch liegen > und daher unterstützt es die STK500 Firmware nicht. Spassigerweise lassen sich der 89S51 und 89S52 sehr wohl mit meinem (USB) AVRISP MKII programmieren, allerdings erst nach einem EMail Wechsel mit Atmel Norwegen. Man benutze STK500.exe (!) im CLI modus per batch and schiebe das 89S52 device unter. Kommt mit der Reset Polarität und der Programmiererei bestens klar. Leider wird der 89S8253 nicht unterstützt und wirds wohl auch nie.
> Keil ist natürlich einer der besten Compiler inkl. IDE, die man für > Controller finden kann, nur für privat schlicht nicht bezahlbar, ausser > man kann mit der Demoversion leben. Eine bezahlbare Alternative zu Keil sind die Compiler von Raisonance(http://www.raisonance.com/).
... dafür ist die erzeugte Codegröße von Raisonance (Ride) deutlich größer als der von Keil... Witzigerweise erzeugt ein "Nichtstandard" an Programmiersprachen einen effizienten Code bei den 51ern: Pascal ... (nennt sich Turbo51) und funktioniert bis auf ein paar Macken richtig schön! Ein "größeres" Projekt hab ich damit schon gemacht: einen Thermometer (NE555 Monoflop an einem Portpin) wertet einen NTC aus. Kalibrierwerte (-10°C ... +^05°C) in einem I2C Rom... das ganze wird über einen AVR2313 zur USB-Schnittstelle transferiert! Windows Programm dazu "gebastelt" (Visual Studio) .. funktioniert gut! Wenn das jemand sehen mag kann ich mal Doku dazu machen. Privat läuft hier: Turbo51, ASEMW, SDCC und ein "Selbstbau"-ISP Adapter (über RS-232 und RS-232/USB Brücke von Logitech). Für AVR-Programmierung natürlich AVR Studio und ein DIAMEX - Flasher Stick (hmm... wollte das jemand wissen?). Im übrigen (um auf den Thread zurückzukommen: ich hab ewig versucht, dem DIAMEX Stick die AT89SXX beizubringen ==> erfolglos, deshalb hat es einen Selbstbau gegeben) Für die Auszubildende wird nun der Selbstbau-ISP-Flasher umprogrammiert, damit nicht das hierfür geschriebene Upload-Programm verwendet werden muß. Der Flasher wird das Protokoll des Bootloaders vom AT89C51ED2 erhalten. Somit wird es dann "doch möglich sein", mit FLIP einen ISP-Chip zu flashen! Ich bin neu hier, wie ist das eigentlich, wenn man seine Arbeiten hier zeigen will, einfach posten oder nur auf Anfrage? Gruß, Ralph
Nils S. schrieb: > bei > vielen steht "highspeed mcu" mit dran, die können dann meist einen > Zyklus in einem Quarz-Takt abarbeiten. > z.B. DS89C430/450 33Mips@33Mhz. Dachte ich auch, bis ich ihn hier hatte ... Die meisten Befehle benötigen 2Takte ... Gruß Jobst
Jobst M. schrieb: > Dachte ich auch, bis ich ihn hier hatte ... > Die meisten Befehle benötigen 2Takte ... Wieviele Takte die pro Befehl brauchen ist egal. Maschinenzyklen meine ich. Ein Maschinenzyklus wird von einem Original-8051 in 12 Quarz-Takten abgearbeitet. Wenn ein Befehl nun z.B. 2MZ braucht, dann braucht er 24 Takte vom Quarz. Bei 11.0592Mhz ist ein Quarz Takt 90ns lang. 12 Quarz Takte sind demnach 1.08µS. Der Befehl mit 2MZ braucht als 2.16µS bis er abgearbeitet ist. Ein 8051, der jeden MZ in einem Quarz Takt abarbeitet schafft demnach 2MZ in 180nS, 12x so schnell. Die mips-Angabe ist hier aber wirklich etwas irreführend in der Bedeutung „Million instructions per second“, wenn eine Instruction mehrere MZ braucht.
Nils S. schrieb: > Die mips-Angabe ist hier aber wirklich etwas irreführend in der > Bedeutung „Million instructions per second“, wenn eine Instruction > mehrere MZ braucht. Eben. Gruß Jobst
Thomas Eckmann schrieb: > Die Dinger sind nicht mehr zeitgemäß. Was die AT89Cx051 können, können > die AVRs auch. Die AVRs sind auch in die Jahre gekommen. Ich bin mal gespannt, wie Atmel die kleinen Cortex neben den (X)Atmega platziert. ;-) Die 8051 wird es noch geben, wenn die AVRs im Museum verstauben. Peter Dannegger schrieb: > Ich finde sie schon vergleichbar. Sie sind für den gleichen > Anwendungsbereich konzipiert (Steuerungen). Wenn es danach geht, darf es nur eine µC Familie geben. Steuern kann man mit jedem µC. ;-) Ich nutze beide Welten parallel. Bei 8051 gefällt mir mein Toolchain besser. Und man muss diesen Fuse-Sch... nicht beachten. Das ist die größte Katastrophe beim AVR.
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.