AT89C4051 mit STK500 befummeln

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.

geht nicht.

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 ;)

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:
> 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.

... 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