Hallo!
Hat jemand eine Empfehlung für einen 8051 uC?
Unterstützung, Support, Verfügbarkeit von Tutorials sollte gut sein.
Idealerweise ein ISP-Programmierbarer mit internem Flash.
eventuell auch breadboard-tauglich.
Kurz, ein idealer Chip für den Einstieg.
Danke schon mal im Voraus!
Schau mal bei Atmel die 8051er mit ISP Flash an.
Viele Typen gibt es noch im Bastelfreundlichem DIL Gehäuse.
Mit der FLIP (auch Atmel) Software, ein paar Kabeln am Parallelport oder
über RS232 kann man viele (alle ?) AT89xxxx über den Integrierten
Bootloader im System programmieren.
Alles wirklich sehr gut benutzbar.
Auch andere bauen gute 51er Derivate (z.B. Silabs) aber bei Atmel hat
man das rundum sorglos Paket.
Viele Typen können deutlich mehr als das Original.
Da ist für jeden was dabei.
Ich bin mit SDCC (open source C Compiler) und Flip ganz gut gefahren,
aber man kann auch die Atmel Toolchain gut verwenden.
Bei Silabs gibt es eine größenbeschränkte Keil Version dazu, die auch
nicht so toll ist.
Die Silabs IDE ist eine Beleidigung und stürzt ständig ab.
Die Chips sind gut, aber m.E. als blanker Chip nicht im DIL zu bekommen.
Sehr gute Wahl übrigens !
Der 8051 macht Spaß und ist ein sehr schöner Einstieg.
Für den Einstieg sollte man unbedingt einen Chip heraus suchen, der auch
Debugger-Tauglich ist. Also damit kannst Du nicht nur einen Chip
programmieren (ISP) sondern anschauen was in den Registern drin steht
und die einzelnen Befehle durch steppen, schritt für schritt und somit
genau nachvollziehen welcher Befehl welche Änderung der
Variablen/Register bewirkt (JTAG).
Ohne Debugger tut man sich als Einsteiger schwer im "Blindflug" das
alles heraus zu finden.
Folgende Artikel empfehle ich zu lesen:
Entscheidung MikrocontrollerMikrocontroller VergleichSTM32 für Einsteiger
Wenn Du schreibst:
- Was Du schon mit Elektronik gemacht hast
- Ob Du schon einen PC programmiert hast
- Welche Schule Du besuchst
- Was Deine Ziele sind
- Dein Budget, was es in etwa kosten darf (30€, 100€ oder mehr?)
- Berufliche Absichten
- Lötkenntnisse
dann kann ich Dir sicher einen guten µC empfehlen.
Jedoch einen 8051 für den Einstieg halte ich etwas zu altmodisch. Es
gibt weitaus bessere.
@mmvisual
Kannst du das missionieren denn nicht mal sein lassen? Der TE hat
konkret nach einem 8051 gefragt, von dir kommt ein Fragenkatalog zur
Person und Werbematerial zum STM32 zurück. Findest du das nicht selbst
ein bischen blöd?
> dann kann ich Dir sicher einen guten µC empfehlen.
Lass mich raten...
Für den Einstieg sollte der MCU meiner Meinung lieber zu stark sein als
zu schwach. STM32 hat man sicher einiges an Möglichkeiten und einen
deutlich leichteren Einstieg.
Beispiel: Wenn Du Autofahren lernen willst, lernste ja auch nicht auf
dem ersten Mercedes.
Hi
>Für den Einstieg sollte der MCU meiner Meinung lieber zu stark sein als>zu schwach. STM32 hat man sicher einiges an Möglichkeiten und einen>deutlich leichteren Einstieg.
Der TO hat nichts zur Programmiersprache gesagt. Würdest du bei
Assembler auch den STM vorschlagen?
MfG Spess
Och Markus und Michael, nun kommt schon ...
Nicht die 3732te 'mein Controller ist besser als Deiner' Diskussion.
Der 8051 ist ein sehr schöner und übersichtlicher Controller.
Natürlich ist der etwas älter und hat manche Dinge nicht von denen heute
alle so schwärmen, die meisten ohne es je benutzt zu haben.
Die fehlende Komplexität ist aber genau der Vorteil und mit dem
altmodischen 'PIN debugging' kommt man oft viel weiter als mit on chip
debugging.
Der 8051 Core wird auch heute noch massenhaft eingesetzt weil er einfach
seine Aufgabe gut erledigt.
Warum man heute für alles einen kraftstrotzenden 32bitter braucht was
früher ein 1Mhz 8bitter gelöst hat kann ich nicht nachvollziehen.
Der Assembler gehört mit zu dem besten und übersichtlichstem was ich
kenne.
Ich empfehle den AT89C51CC03UA.
Er hat AD-Wandler und ist über die UART programmierbar, man braucht also
keinen extra Programieradapter.
Im PLCC-44 kann man ihn auch bequem auf eine Rasterplatine setzen.
spess53 schrieb:> Hi>>>Für den Einstieg sollte der MCU meiner Meinung lieber zu stark sein als>>zu schwach. STM32 hat man sicher einiges an Möglichkeiten und einen>>deutlich leichteren Einstieg.>> Der TO hat nichts zur Programmiersprache gesagt. Würdest du bei> Assembler auch den STM vorschlagen?>> MfG Spess
Ein 8051 ist schon ziemlich alt und es gibt heutzutage deutlich bessere
für den Einstig, aber wie kann ich dem TO einen µC empfehlen wenn ich
überhaupt nicht SEINE Randbedingungen kenne?
Ich habe in diesem Thread noch keine einzige Empfehlung ausgesprochen
und schon werden wieder irgend welche fadenscheinliche Vermutungen
angestellt.
Wie kann überhaupt hier irgend wer Sinnvoll irgend was empfehlen - außer
einen 8051 derivat?
Michael H. schrieb:> STM32 hat man sicher einiges an Möglichkeiten und einen> deutlich leichteren Einstieg.STM32 bietet zweifellos tolle Möglichkeiten und (im Vergleich zu
8051-Derivaten oder 8-Bit AVRs) wesentlich komplexere und ausgefeiltere
integrierte Peripherie...
Aber, gerade durch die höhere Komplexität bedingt, gibts auch einiges an
Fallstricken für einen Einsteiger. Bis man da seine erste LED am blinken
hat, muß man einiges mehr konfigurieren und programmieren (z.B.
Clock-System), als in 'nem 8051.
Ich finde die STM32 toll, kann sie aber als "Erstcontroller" für den
Einstieg nicht unbedingt empfehlen.
Da ist ein 8051-Derivat oder 8-Bit AVR einfacher zu erlernen.
> Beispiel: Wenn Du Autofahren lernen willst, lernste ja auch nicht auf> dem ersten Mercedes.
Schönes Beispiel, für dich aber eher ein Eigentor. ;-)
Man lernt Autofahren schließlich auch nicht auf 'nem 400PS-Sportwagen,
sondern i.d.R. auf einem gutmütigen und weitverbreiteten, halbwegs
aktuellen Fahrzeugtyp, der eher in die Kategorie "Familienkutsche" paßt.
Außerdem hatte der TE explizit nach einem 8051er gefragt und
nicht nach einer Empfehlung zu für den Einstieg geeigneten
Controllerfamilien allgemein.
mknoelke schrieb:> Ich bin mit SDCC (open source C Compiler) und Flip ganz gut gefahren,> aber man kann auch die Atmel Toolchain gut verwenden.> Bei Silabs gibt es eine größenbeschränkte Keil Version dazu, die auch> nicht so toll ist.
??? http://pages.silabs.com/lp-keil-pk51.html
"Keil PK51 Professional Developer's Kit, including the
compiler/linker/assembler for use with Silicon Labs' 8-bit
microcontrollers and Studio. This free tool comes without a time or code
size limit!"
Ähnliches gibt's auch von Cypress für deren 8051er
> Die Silabs IDE ist eine Beleidigung und stürzt ständig ab.
Hier nicht, dafür stürzt hier Keils uVision regelmäßig ab
> Die Chips sind gut, aber m.E. als blanker Chip nicht im DIL zu bekommen.
Als DIL nicht, aber z.T. als SO mit 1.27 mmm oder QFP-32 mit 0.8 mm
Pinabstand.
> Sehr gute Wahl übrigens !> Der 8051 macht Spaß und ist ein sehr schöner Einstieg.
Darüber ließe sich streiten
Markus Müller schrieb:> Wenn Du schreibst:> - Was Du schon mit Elektronik gemacht hast
Grundlagenwissen
> - Ob Du schon einen PC programmiert hast
in Basic, Pascal, Java, C/C++, bisschen Assembler
> - Welche Schule Du besuchst
bin Chemiker, Elektronik/Programmieren ist ein Hobby
> - Was Deine Ziele sind
keine konkreten, Lernen um zu Lernen
> - Dein Budget, was es in etwa kosten darf (30€, 100€ oder mehr?)
je weniger desto besser (Hobby)
> - Berufliche Absichten
keine
> - Lötkenntnisse
vorhanden
Halte ja persönlich nicht so viel von Fragebögen ;-)
Wegen der anderen Systemvorschläge. Ich beschäftige mich auch mit STM32,
TivaC, AVR und anderen. Ich will keine Meinungen zu anderen Systemen
haben, sondern konkrete Vorschläge zu 8051.
Die leidigen Diskussionen welche Systeme besser sind, interessieren mich
nicht wirklich.
Ich lerne nicht aus einem konkreten Grund, sondern um zu Lernen. Einfach
aus Interesse, sonst nichts.
Aber danke schon mal für die tollen Vorschläge. Scheint so, als ob ATMEL
auch bei 8051 vorne dabei ist.
> Ein 8051 ist schon ziemlich alt und es gibt heutzutage deutlich bessere> für den Einstig, aber wie kann ich dem TO einen µC empfehlen wenn ich> überhaupt nicht SEINE Randbedingungen kenne?>
Die hab ich doch genannt. Wegen der Programmiersprache habe ich deswegen
nichts angegeben, weil ich Assembler und C programmieren will bzw. die
Programmiersprache egal ist...
8051 µC gibt es auch von NXP (LPC900/LPC700), da kannst Du vorbeischauen
Von Cypress gibt es z.B. den CY7C68013A. Der hat USB mit dabei und lässt
sich über diesen auch programmieren (USB Bootlaoder). Das
Vorgängermodell hatte ich viel Jahre genutzt, hatte aber nur 8K RAM.
Programmiert hatte ich damals mit dem Keil Compiler.
Da Du Dich ja schon ganz gut auskennst brauche ich ja auch nichts
empfehlen ;-)
Der einfachste Einstieg wären IMHO die Cypress EZ-USB Controller.
Das sind sehr verbreitete USB-2.0 Highspeed Controller. Auf eBay bekommt
man Breakout-Boards für 8-9 Euro. Einfach mal nach
"EZ-USB FX2LP CY7C68013A USB Development Core Board"
suchen.
Die werden überigens gerne als Logic-Analyzer eingesetzt, weil Sie bis
zu 48 MB/s übertragen können. Falls du also fertig mit dem Board bist,
kannst du es z.B. mit der Sigrok-Software als LA verwenden!
Drinnen wird alles von einem ein 8051 gesteuert. Nett ist dabei, daß der
Programmspeicher in einem 8 oder 16kb grossen SRAM liegt, der Chip kann
entweder von einem EEPROM sein Program einlesen oder man lädt die
fertige Firmware einfach über USB hoch.
Cypress bietet ein komplettes SDK mit KEIL Unterstützung an und so, aber
der Chip kann auch per Assembler und SDCC "von Hand" programmiert
werden. Eine Einführung findest du hier:
http://www.triplespark.net/elec/periph/USB-FX2/
Die größten Hersteller von 8051-Derivaten sind Atmel und Silicon
Laboratories.
Wenn Du Breadbord-Kompatibilität brauchst, bleibt nur Atmel übrig, da
Silicon Laboratories alle DIP-Versionen aus dem Programm genommen hat.
Wenn Du auch mit SOIC- oder SSOP-Gehäusen leben kannst, dann findest Du
auch was passendes bei Silicon Laboratories.
Nachteil der Atmel-Chips: Eval-Boards sind ziemlich teuer.
Bei Silicon Laboratories findest Du dagegen für kleines Geld die
Toolstick Boards (für den F850 10€ bei Digikey).
Es gibt auch kostenlos die Keil-Tools für den C8051.
Nachteil:
Es gibt die Teile (zumindest die im SO- oder SSOP-Gehäuse) eigentlich zu
annehmbaren Preisen nur über digikey oder Mouser, Eibtron hat einzelne
im Programm, allerdings zu Schweinepreisen (C8051F988-GU: Eibtron 3,78€,
Mouser und digikey: 0,71€).
Die Teile sind zum Teil so billig, dass Du über 100 Stück kaufen musst
um die 20€ Versandkosten nicht bezahlen zu müssen.
Also nach abwägen wird's wohl ein Atmel werden...
Und seid nicht beleidigt. Ich suchte Einstieg in 8051 und nicht Einstieg
in uC. Dachte dass war in der Fragestellung deutlich formuliert.
Ein Ur-8051 ist zum Einstieg und für erste Basteleien immer noch gut,
und im Steckgehäuse auch mal auswechselbar. Man kann aber gerne mal CMOS
nehmen, nicht die Ur-Typen in NMOS.
Allerdings macht man mit dem Baustein alleine nicht viel, denn es bedarf
eines EPROM und einem Programmer dafür.
Manchmal gibt es aber noch alte Boards, wo ein Monitor-EPROM drauf ist,
also auch ein Ladeprogramm für Downloads vom PC zum Board. Damit kann
man an der seriellen Schnittstelle eines PC sofort los legen.
Hier im Marktforum wurden schon mal solche Boards von Leuten verschenkt,
und zwar sogar mit einem 80C517A drauf. Das war ein schöner
High-End-Baustein aus dem Hause Siemens/Infineon, der aber auch genau
wie ein Standard-8051 benutzt werden kann, weil voll abwärtskompatibel.
Ich arbeite heute noch damit, einfach weil es daran auch noch ADC und
PWM und einiges andere gibt.
Mit den modernen SiLabs-Typen kann man sich mal anfreunden. Es sind aber
Pipelined-Typen mit teils geänderten Taktzyklenzahlen bei manchen
Befehlen. Da funktioniert der Simulator für den Standard-8051 dann nicht
mehr korrekt, die Taktzyklenzählung. Jedoch 2-Cycle-Core, was nicht
schlecht ist. Ältere bestehende Software vom Ur-8051 muß aber angepaßt
werden, wenn sie irgend wie mit Taktzyklen rechnet, z.B. Zeitschleifen.
Für den Einsteiger auch in Assembler ist der Befehlssatz nicht so von
hinten durch die Brust ins Auge, wie z.B. bei einem PIC. PIC-Einsteiger
mit Assembler hatte ich jaulend weg rennen sehen, und sich danach nie
mehr mit sowas beschäftigen. Im Studium mußten sie aber den PIC und
Assembler nehmen, und konnten nicht wählen. Das Labor als Wahlfach wurde
dann halt nicht mehr belegt, und das Thema für die Jungs für alle Zeiten
begraben.
Keil µVision o.ä. habe ich fürs Hobby nicht. Da reicht der
Freeware-SDCC-Compiler, und ein Terminalprogramm wie z.B. TeraTerm auf
dem PC, Geany als Bedienoberfläche Editor. Den Programmer habe ich nur
noch für den Fall, wenn ich wirklich mal ein endgültiges EPROM für ein
Board brennen möchte, oder mal das Monitor-EPROM mit dem Lader etwas
ändern.
Zum Einstieg würde ich heute etwas nehmen, was dem 8051 am ähnlichsten
kommt, z.B. mit nur internem Flash anstatt externem EPROM, um den
Programmer einzusparen. Die Atmel 89C51 sind glaube ich was in der Art,
kommen dem am nächsten. Denn ich glaube, hier will jemand einsteigen,
und nicht gleich mit dem Handstand auf einer Hand. Die SiLabs sind schon
wieder aufwändiger, und brauchen zum Betrieb ein paar Konfigurationen
mehr, wie z.B. die Pinkonfiguration, woran sich manch einer schon schwer
tut.
@Wilhelm F. (ferkes-willem)
>Ein Ur-8051 ist zum Einstieg und für erste Basteleien immer noch gut,
Einstieg worin? ICs braten im Kilopack?
>Allerdings macht man mit dem Baustein alleine nicht viel, denn es bedarf>eines EPROM und einem Programmer dafür.
Alter Mist! Heute kauft man sich was aktuelles und fertig! AVR, PIC,
MSP430 oder in Dreigottesnamen einen STM32. Alles andere soll in Frieden
ruhen.
Ausser für nostalgische Träumereien ist das Zeug heute zu nix mehr gut,
in Anbetracht der modernen Alternativen! So wie alte Röhrenradios!
Naja, so ein Ur-8051 muss wirklich nicht sein. Auf Flash sollte man
heute nicht mehr verzichten. An einfachen 8051-Clones mit Flash gibt's
aber eine gute Auswahl, und der Einstieg ist z.B. mit sdcc auch sehr
einfach.
> Alter Mist! Heute kauft man sich was aktuelles und fertig! AVR, PIC,> MSP430 oder in Dreigottesnamen einen STM32. Alles andere soll in Frieden> ruhen.> Ausser für nostalgische Träumereien ist das Zeug heute zu nix mehr gut,> in Anbetracht der modernen Alternativen! So wie alte Röhrenradios!
Das siehst du so. Ich WILL aber 8051 programmieren. Hab ich auch oben
schon geschrieben. Mir ziemlich egal ob alt, unnütz oder was auch immer.
Btw, sie würden nicht mehr produziert werden wenn niemand damit arbeiten
würde!?
Ich versteh nicht warum einem hier immer wieder irgendwelche Meinungen
aufgezwungen werden obwohl das in keinster Weise irgendwas mit der
Fragestellung zu tun hat.
Falk Brunner schrieb:> Ausser für nostalgische Träumereien ist das Zeug heute zu nix mehr gut,
Diese 8051 stecken heutzutage praktisch überall drin: SD-Karten,
USB-Sticks, als Controller in irgendwelchen SoCs. In den CC1100 Modulen,
den nRF24LU1+ Funkdingern, in den WebCams der meisten MacBooks: Überall
8051 Cores, die moderne Hardware dirigieren. Darum finde ich die Idee
gar nicht so abwegig sich mit diesen alten Dingern zu beschäftigen.
Markus Müller schrieb:> aber wie kann ich dem TO einen µC empfehlen wenn ich> überhaupt nicht SEINE Randbedingungen kenne?
Die Randbedingung war 8051, aber Du hast sie ignoriert.
Also: ISP und Steckbretttauglich ... Also DIP ... also 40-Pinner ...
Dallas DS89C450 - Via UART zu programmieren
2-Takter mit 33MHz, 64k Flash, 1k SRAM, 2 UARTS
Als PLCC (also nicht mehr so recht Steckbretttauglich :-/)
Atmel AT89C51ED2 - Via UART zu programmieren
12-Takter bei 60MHz (oder6-Takter mit 30MHz), 64k Flash, 2k SRAM, 2k
EEPROM
NXP P89LPC935FA - Via ICP/ISP/IAP zu programmieren
2-Takter mit 18MHz, 8k Flash, 256+512Byte RAM, 512Byte EEPROM, 8Bit DAC
+ ADC, 23Bit Timer, I²C, 2,4-3,6V !, kann LEDs direkt treiben, uvm.
Gerne habe ich mit dem SAB80C535/7 gearbeitet - aber den gibt es ja
nicht mehr ...
Gruß
Jobst
greg schrieb:> Ich schmeiß hier auch noch mal meinen anderen Thread> www.mikrocontroller.net/topic/320336 in den Raum. Wenn einen Chinglish> nicht abschreckt...
Das wäre dann die Geschichte mit Support und Unterstützung... Hin mir
sicher, dass die eine günstige Alternative sind --- wenn man sich
auskennt.
Da hast du natürlich recht. Wobei die Dinger natürlich erst einmal 99%
kompatibel zu dem Ur-8051 sind. Da kann man ohne spezifische Kenntnisse
über die STC-Controller anfangen. Jedenfalls unter Windows.
Die Toolsticks von Silabs sind in der Tat gut und günstig.
Mit JTAG ist das Debuggen kein Problem.
Für dem Einstig ist das 8051 Thema finde ich den VIDEO-Kurs von
ET-Tutorials gut: http://ET-Tutorials.de/Mikrocontroller
Wenn du schon mit AVR etwas gemacht hast, vielleicht mit dem 90S8515,
ATmega162..?
Dann kannst du die gleiche Hardware verwenden beim 89S8252.
Ein paar kleine Änderungen wie Reset sind nötig.
@ Harald (Gast)
>Das siehst du so. Ich WILL aber 8051 programmieren. Hab ich auch oben>schon geschrieben.
Dagegen hab ich nichts. Ich meinte den alten Mist von 8051, wo man noch
EEPROMs und Programmer braucht. Eine moderne Flash-Variante ist schon OK
(wenn gleich ich AVR vorziehen würde)
Man lernt eben nie aus!
Als Atmel anfing, so 1999 hat es auf beide Schienen gesetzt.
Der AT89C2051 ist fast pinkompatibel zum AT90S2313, Attiny2313.
Der AT89S8252 ist fast pinkompatibel zum AT90S8515.
Der AVR hat das Rennen gemacht, obwohl die etwa gleichwertig waren.
Die AT89C51CC03 f.f. werden sehr of eingesetzt.
Michael_ schrieb:> Der AT89S8252 ist fast pinkompatibel zum AT90S8515.
Anders herum wird ein Schuh draus, denn der AT89S8252 ist incl. Pinout
ein 8051. Und der AT90S8515 ist 'fast' pinkompatibel zum 8051.
> Der AVR hat das Rennen gemacht, obwohl die etwa gleichwertig waren.
Aber nur bei Atmel hat der AVR das Rennen gemacht. Vielleicht. Kennst Du
Umsatzzahlen?
Gruß
Jobst
Sowohl der AT89S51 als auch der AT89S52 sind 100% pinkompatibel zum
UR-MCS8051/52 und auch z.B. mit dem AVRISP MkII per ISP zu
programmieren. Eine unrühmliche Ausnahme bildet der 89S8253, der leider
nur per FLIP zu flashen ist.
Wer also einen AVRISP MkII schon da hat, ist mit einem der beiden o.a.
MCs gut beraten.
Ich versteh auch nicht, warum sofort auf MCS51 rumgebasht wird. Es gibt
nur wenige MC mit einem so klaren und logischen Befehlssatz. Er hat
keinerlei Errata oder Anomalien und wird nach wie vor in der Industrie
gerne eingesetzt. Kontext Switching ist mit seinen 4 Registersätzen eine
wahre Freude. Anbinden externer Peripherie ist durch seine /WR und /RD
Pins ein Spaziergang, er kann locker mit externem Speicher ausgerüstet
werden usw.
Matthias Sch. schrieb:> Eine unrühmliche Ausnahme bildet der 89S8253, der leider> nur per FLIP zu flashen ist.
Whot!? SPI (MOSI, MISO und SCK) und parallel! FLIP hingegen gar nicht.
Gruß
Jobst
Jobst M. schrieb:>> Der AVR hat das Rennen gemacht, obwohl die etwa gleichwertig waren.>> Aber nur bei Atmel hat der AVR das Rennen gemacht. Vielleicht. Kennst Du> Umsatzzahlen?
Natürlich bei Atmel. Die Leute wollten eben nicht die 89S...
Vielleicht, weil es erst die schwerer zu programmierenden 89C... gab.
Und der 90S2313 war damals für mich ein Wunderding. Besser als der
89C2051.
Vor einigen Jahren hatte ich noch mit der MCS51 Serie gebastelt, zuletzt
mit dem AT89C2051 gebastelt. Für mich war der integrierte Flash Speicher
damals wahnsinnig praktisch - heute inzwischen eine
Selbstverständlichkeit.
Ich fand' auch den 80C535 interessant, nur leider hatte der kein Flash.
Das "SAB 80C535 users manual" ist dennoch sehr empfehlenswert, denn es
erklärt die Programmierung der Peripherie und den Assembler Befehlssatz
äußerst detailliert.
> Der Assembler gehört mit zu dem besten und übersichtlichstem was ich kenne.
Jo, sehe ich auch so. Ich hatte damals zu DOS Zeiten sogar meinen
eigenen Assembler in pascal geschrieben - nur so zum Spaß.
@Harald:
Was andere bereits erwähnt haben, möchte ich ebenfalls behaupten:
bei kaum einem anderen Controller dürfte die Assemblersprache so sauber
und klar strukturiert und damit angenehm zu lernen sein, wie bei dieser
bewährten Controllerfamilie. Vergleich das mal spaßeshalber mit den
(durchaus tollen!) PICs, v. a. den "kleineren" Familien - ein
kryptischer, umständlicher Assembler-Graus :-)
In C sieht das dann schon wieder anders aus, aber dafür ist der 8051
nicht entwickelt worden.
Ich finde, das allerbeste an den 8051ern ist die sehr "geradeaus"
konzipierte Einzelbitverarbeitung, wie Du sie z.B. für
Steuerungsaufgaben benötigst. Da ist der 8051 nach wie vor einfach große
Klasse und gerade in Assembler hochkomfortabel und beinahe intuitiv zu
programmieren.
Besorg Dir die modernen Flashtypen, dann brauchst Du maximal Quarz- und
Resetzeug extern, und (E)EPROM, Adress-Latch und Co sind überflüssig.
Wenn Du mal experimentieren willst, dann kannst Du das später natürlich
trotzdem alles dranhängen.
Hier noch weitere Bezugsquellen für Atmel, NXP, Silicon Labs, Silicon
Storage... (unter sonstige):
http://www.ju-tec.de:
http://www.tme.eu
(Lieferbarkeitsabfrage nicht vergessen)
Bitte ein Bit schrieb:> http://www.ju-tec.de:> http://www.tme.eu
Danke für die Empfehlung. Aber ich bleib dann doch bei Reichelt. Da
halten sich die Versandkosten in vernünftigen Grenzen - vor allem nach
Österreich.
www.ju-tec.de €16,90 Versand nach Österreich???? Ist das
Over-Night-Express?
Harald schrieb:> www.ju-tec.de €16,90 Versand nach Österreich???? Ist das> Over-Night-Express?
Ne, da hat der Seehofer Horscht gleich seine Maut draufgehauen ;-)
Stefanus schrieb:> Ich fand' auch den 80C535 interessant, nur leider hatte der kein Flash.> Das "SAB 80C535 users manual" ist dennoch sehr empfehlenswert, denn es> erklärt die Programmierung der Peripherie und den Assembler Befehlssatz> äußerst detailliert.
Wenn z.B. einer wie ich noch diese alten Boards besitzt, und auch von
damals noch über einen EPROMMER verfügt, dann braucht man die Boards
keineswegs einzustampfen.
Die Boards bei mir haben auch alle die Von-Neumann-Schaltung mit dem RAM
als Codespeicher, so daß man sie mit einem Monitor-EPROM bzw. nur
Ladeprogramm im EPROM betreiben kann, ohne ein EPROM brennen zu müssen.
Letztendlich kann ich zu einem Zeitpunkt mal ein endgültiges EPROM
brennen, wenn ich ein Board wirklich mal in einer festen Anwendung
verwurstele.
Falls man irgendwie mal an so ein altes Board dran kommt, muß man aber
darauf achten, daß man die Dokus zu Monitor-ROM und den Schaltplan mit
erhält. Letztens schoß hier einer aus dem Forum so ein Board in der
Bucht, wo GALs als Adreßdekodierer z.B. Chipselektor drauf waren, und
keinerlei Doku dabei, das ist dann ziemlich für die Tonne. Ein
geschenktes Board ohne jegliche Doku klingelte ich auch mal mit dem
Ohmmeter aus, es hatte kein GAL, aber z.B. Keyboard und Display,
glücklicherweise nur zweilagige Platine, und war auch schon einen halben
Tag Arbeit. Aber so kann ich es verwenden. Wegen der Tastatur und des
Displays konnte ich da ohne weiteres schon mal ein paar Spielereien
drauf programmieren. Das Board muß ursprünglich mal eine direkte
Codeeingabe gehabt haben, so daß man ohne PC direkt darauf kleine
Testprogramme in Maschinencode eingeben konnte, aber dazu gab es eben
keine Doku mehr. Manche Tasten hatten noch Bezeichnungen wie Go, Step,
Return, Ins, Clr, Int, Break, usw..
Der externe Speicherbus mit dem EPROM ist natürlich manchmal wie ein
Kropf, wenn man mal schnell eine kleine Schaltung aufbauen will. Ich
verknüpfte da schon mal das böse mit dem guten, und hing an den Bus noch
eine größere I/O-Erweiterung mit je 32 In- und Outputs an, so daß die
Ports 1 und 3 dann sogar völlig frei waren.
Im Augenblick habe ich sogar einen 8048 mit diesem gleichen externen Bus
Adreßmultiplexer und EPROM auf einem Steckbrett. Das läuft sogar völlig
einwandfrei, trotz mehr als 10 Meter (etwas wackeligen) Schaltdrähten
als Busleitungen, aber mit weniger als 1 MHz, also was an die 100 kHz
Busfrequenz. Für ein paar Testprogrämmchen brauchte ich genau genommen
sogar nur einige kHz Taktfrequenz. Mein 8048-Derivat 80C382 hat voll
statisches Design, ein normaler 8048 und 8051 nicht. Die Atmels sind,
glaube ich, auch wieder voll statisch.
Der 8048 machte gegenüber dem 8051 noch so einige Problemchen. Z.B. war
ein Tabellenzugriffsbefehl im Befehlssatz nicht mehr so ausreichend gut
dokumentiert, daß ich ihn fehlerfrei anwenden konnte. Tabelle muß
zusammen mit dem Zugriffsbefehl in einer Page zu 256 Bytes liegen, und
darf niemals eine Pagegrenze überschreiten. Das war wirklich noch etwas
mittelalterlich. Da half dann statt Doku aber ein Simulator, der mir
genau zeigte, was im Augenblick passiert. Beim 8051 spielen Pagegrenzen
schon keine Rolle mehr.
Die Atmel sind sicherlich eine gute Wahl.
Der 89S51 ist günstig und hat mit 8K eine brauchbare Flashausstattung.
Nur der RAM ist mit 256Byte für C- Programmierung etwas knapp bemessen
und ADC fehlt auch. Als Programmieradapter solltest du dir einmal den
MKII anschauen. Mit AVRDUDE kannst du die Teile flashen und bist
nebenbei auch noch für die ATMEGA Serie gerüstet. Allerdings musst du
dir die Konfig anpassen, da diese Typen in der Konfig fehlen. Ist aber
keine Raketentechnologie. Einfach die Konfig eines vorhandenen 89ers
kopieren und anpassen. Die Parameter findest du in den Datenblättern.
Ich habe hier selber noch einige 89S2051, 89S4051 und 89S51 liegen. Wenn
du mit Einzelstücken auskommst, dann melde dich mal PM und ich schicke
dir dann ein oder zwei zu. Eventuell kannst du von mir am WE auch eine
gültige DUDE - konfig bekommen.
Marek Walther schrieb:> Die Atmel sind sicherlich eine gute Wahl.> Der 89S51 ist günstig und hat mit 8K eine brauchbare Flashausstattung.> Nur der RAM ist mit 256Byte für C- Programmierung etwas knapp bemessen> und ADC fehlt auch.
Da siehste mal! Es wird aber immer auf dem externen EPROM und internen
Flash herum geklopft, und dann fehlt das RAM. Aber das interne RAM geht
für einiges noch, wenn man keine riesigen Datenfelder verarbeitet.
2k XRAM auf dem Chip hatten wiederum die 80C517A, dann aber wiederum
kein Flash.
Mein olles Opto-Net-Mini Eval-Board mit 80C517A hat je 64k RAM und ROM,
wenn auch extern. Aber da kommt dann deswegen keine Spaßbremse auf.
Uhhh - ich sehe gerade, Reichelt hat nun auch in seinem Chaos Atmel
1Takter: AT89LP2052 und AT89LP4052
Leider den AT89LP6440 nicht - den habe ich in freier Wildbahn allerdings
auch noch nicht lieferbar gesehen ...
Bei Reichelt wirst Du wohl beim AT89S8253 hängen bleiben. Oder Du nimmst
einen PLCC-Sockel in kauf und es wird ein AT89C51ED2.
Gruß
Jobst
Hi
>Weiter oben war ja nur die Rede vom MK2...
Das ist auch nicht eindeutig:
JTAG ICE MKII -> Debugger/Programmer
AVR ISP MKII -> Programmer, ca. 10x billiger als der ICE
MfG Spess
Funktionieren dann Programmer wie der DIAMEX USB ISP, der ja quasi für
alle aktuellen Atmel AVR funktioniert, auch mit den ISP-programmierbaren
8051 Bausteinen von Atmel?
Harald Nagy schrieb:> (haraldn)
Ach, der Harald ...
Hättest Du nicht was sagen können!? Dann hätte ich Dir noch ein paar
8051er mit in den Umschlag gesteckt ...
Gruß
Jobst
Hi,
Markus Müller schrieb:> Weiter oben war ja nur die Rede vom MK2...
Also ich lese da ganz klar auch das "AVRISP" vor MKII.
Matthias Sch. schrieb:> Sowohl der AT89S51 als auch der AT89S52 sind 100% pinkompatibel zum> UR-MCS8051/52 und auch z.B. mit dem AVRISP MkII per ISP zu> programmieren.
Und damit ist das konkrete Produkt bereits ganz klar umrissen und man
muss gar nicht mehr darüber diskutieren das "MKII" alleine oft, wenn
auch nicht 100% korrekt da uneindeutig, als Synonym für die ISP
verwendet wird.
Also einfach mal die FanboyBrille etwas häufiger absetzen!
Im Moment übertriffst du ja sogar die AVR Fanboys um Meilen!
Aber BTT:
Sofern es nur um Erfahrung mit dem 8051 geht und keine konkrete
Anwendung dahintersteht ist der Genaue µC ja absolut egal. Da würde ich
wirklich nur darauf achten das dieser möglichst einfach zu programmieren
und einigermaßen für Hobbyisten verfügbar ist.
Wenn bereits ein "AVR ISP MKII" (Ob andere AVR Programmer auch
funktionieren weiß ich nicht) vorhanden ist könnten die AT89 da durchaus
in Frage kommen.
ISt kein AVRISP vorhanden könnte ein CY7C68013 vielleicht doch die
bessere Wahl sein da hier die Firmware bei jedem Start über USB in den
RAM des µC geladen wird. Allerdings ist die Verfügbarkeit (für Privat)
hier in DL schlechter, aus China bekommt man entsprechende
Experimentierboards aber recht einfach und günstig. Für echte
(wiederkehrende) verwendung in Projekte halte ich das beziehen aus China
allerdings für zu umständlich - nur für mal in die 8051 Welt
hereinschnuppern allerdings völlig OK.
Gruß
Carsten
Jobst M. schrieb:> Whot!? SPI (MOSI, MISO und SCK) und parallel! FLIP hingegen gar nicht.
Wenn das missverständlich war, der AT89S8253 kann nicht mit dem AVRISP
MkII programmiert werden, wohl aber über Flip mit ein paar Drähten am
Parallelport und über ISP (MOSI,MISO, etc)oder einem Tool namens
AT89ISP. FLIP kann auch ISP. Allerdings hat der AT89S8253 Anomalien,
und das gerade an der ineressantesten Erweiterung, nämlich dem internen
EEPROM.
Windows Fanboys können auch nur mit STK500.exe aus AVR Studio und dem
AVRISP MkII die AT89S51/52 programmieren.
Meine Drag&Drop Batchdatei für den 89S52 sieht so aus:
War der FLIP nicht dieses Bootloader-Tool? Oder ist der da tatsächlich
so universell?
Matthias Sch. schrieb:> Allerdings hat der AT89S8253 Anomalien,
Die haben alle Anomalien!
Wenn man das Protokoll vom AT89S51/52 verwendet und SCK invertiert, kann
man den AT89S8253 damit gaaaanz langsam programmieren. (~ 200 Bytes/s)
Gruß
Jobst
Hallo erstmal ...
Die MCS-51 wird bspw. in Berufsschulen immer noch verwendet um den
Umgang mit MC's zu lernen. (So verwenden meine Auszubildenden diese
Familie in der Berufsschule immer noch und zum Einstieg finde ich den
absolut nicht schlecht).
Programmiert wird der (in der Berufsschule) mit dem Demokit von Ride
(welches ich persönlich - das Demokit - schlecht finde, da die Codegröße
auf 4 kByte beschränkt ist und damit öfters etwas nicht realisierbar
ist).
Praktikabler (und für die Lernzwecke besser ist IMHO) ist hier:
Für "C" : SDCC (im Netz zu finden)
Für Assembler : A51 (ebenfalls im Netz zu finden).
Auch auf die Gefahr hin, dass ich wieder einen auf die Mütze bekomme:
Wenn absolut nichts an Hardware vorhanden ist, eignet sich der
AT89C51ED2
der mittels serieller Schnittstelle und dem Atmel Tool Flip
programmierbar ist, allerdings ist der mittlerweile exoribitant teuer
geworden (bei Reichelt im Moment 8,30 €).
Bei Bedarf kann ich hier eine Schaltplan "liefern" und eine Anleitung
wie ein Programm auf den ED2 geflasht werden kann.
---------------------------------------------------------
Für Versuche und den Einstieg in die Microcontrollerwelt verwenden wir
den AT89S52 (im 40 pol. DIP Gehäuse... bei Reichelt für 0,95 Euro).
Allerdings ist dieser NICHT über Flip programmierbar. Mit Hängen und
Würgen (und invertieren der Resetleitung) war dieser mit einem Diamex
Flasher (der eigentlich für die AVR-Serie gedacht ist) flashbar.
Aus diesem Grund gab es einen Eigenbauflasher für die Mikrocontroller:
AT89S51
AT89S52
AT89S8253
AT89S2051
AT89S4051
(Dateien im Anhang).
Für diesen Flasher wird jedoch ein bereits programmierter AT89C2051 oder
AT89S2051 benötigt.
Schaltung und Programme sind im Anhang.
Die Programme dürften selbsterklärend sein, Programme benötigen zum
Betrieb ein installiertes DOT.NET4
Wird der Flasher an der seriellen Schnittstelle angeschlossen (ein
Betrieb über einen USB2RS232 Wandler ist problemlos möglich) wird bei
Benutzung eines Terminalprogramms erst einmal nichts angezeigt (es soll
ja in Zusammenarbeit mit dem im gepackten Zip-File funktionieren).
Wird "5" an den Flasher gesendet, erscheint auf dem Terminalprogramm ein
Menü mit diversen Möglichkeiten des Flashers um einzelne Funktionen auf
der ISP der angeschlossenen, zu programmierenden, Microcontrollern zu
testen).
Dieses dürfte die wohl preiswerteste Möglichkeit sein, um mit MCS-51 zu
hantieren, in der Praxis hat sich dieser Flasher bei uns hervorragend
bewährt.
Sollte der Threadersteller hier Interesse haben und niemanden finden,
der ihm einen 89C2051 flashen kann kann ich evtl, einen bereits
geflashten Chip schicken.
-----------------------------------
Btw.: Die Maschinensprache der MCS-51 Familie empfinde ich im vgl. zu
AVR-ATmega und ATtiny oder STM32 als ausgesprochen angenehm und extrem
einsteigerfreundlich, von daher ist es vielleicht gar nicht so schlecht,
mit der 8051-Familie anzufangen !
Gruß,
R. Seelig
@ Ralph S. (jjflash)
Wir haben damals im Studium auch ei 8051 Praktikum gemacht, alles in
ASM. War OK. Ist auch heute noch OK. Aber die Architektur ist schon
etwas ergraut. Es gibt gute, moderne Alternativen.
>Btw.: Die Maschinensprache der MCS-51 Familie empfinde ich im vgl. zu>AVR-ATmega und ATtiny oder STM32 als ausgesprochen angenehm
Was ist denn an AVR Assembler unangenehm? Der ist doch klar und
geradlinig strukturiert, man hat haufenweise Register. STM32 ist klar,
das ist ne andere Liga, kenn ich nicht, würde man praktisch auch
seltenst in ASM programmieren. Aber selbst 68000 als 16/32 Bit CPU ist
in ASM recht angenehm programmierbar.
So, Brief (fast ein Päckchen) mit Bauteilen ist raus. Sollte spätestens
Anfang nächster Woche bei dir eintreffen. Viel Spass damit, schön
einteilen und nicht alle auf einmal (ab)rauchen. ;)
Falk Brunner schrieb:> Was ist denn an AVR Assembler unangenehm? Der ist doch klar und> geradlinig strukturiert, man hat haufenweise Register.AVR Assembler ist eine Katastrophe, wenn man vorher jahrelang MCS51
programmiert hat.
IN, OUT, LDI, LD, ST, MOV ... beim MCS51 alles MOV
In Kombination mit unteren und oberen SFR dazu noch eine Falle.
Man muss bei AVR für Rechenoperationen immer alles in den Registern
liegen haben. Beim MCS51 kann man direkt den Inhalt des RAMs oder eines
SFRs zum Akku addieren oder gar direkt in-/decrementieren.
Dann dieses dusselige tmp-Register, welches man bei AVR ständig
benötigt.
Oder Bitoperationen, Bitadressierbarer Speicher.
Bei den bedingten Sprüngen muss ich beim AVR jedes Mal nachsehen ...
Oder MOVC A, @A + DPTR (Addiere A zum Pointer und hole den Inhalt der
ROM-Adresse in A) - beim AVR erst mal eine 16-Bit-Addition, bevor man
was bekommt.
MCS51 kann teilen.
MCS51: Decrementiere und springe, wenn nicht 0 (DJNZ) - super für
Schleifen!
Und die Register empfand ich immer ehr als beengend im Gegensatz zum RAM
des MCS51. Register braucht man da ja nicht so viel.
> Aber selbst 68000 als 16/32 Bit CPU ist> in ASM recht angenehm programmierbar.
Wieso selbst? 68k ist großartig - sehr sauber!
Und der Programmierer hat immer eine 32-Bit Maschine vor der Nase - egal
ob 68008 oder 68060. Ist allerdings auch ehr als Prozessor, als als
Controller gedacht gewesen.
Den kann man sogar direkt mit dem Code programmieren, weil selbst der
total aufgeräumt ist. 4e75 = RET - weiß ich heute noch :-)
Gruß
Jobst
Jobst M. schrieb:> Falk Brunner schrieb:>> Was ist denn an AVR Assembler unangenehm? Der ist doch klar und>> geradlinig strukturiert, man hat haufenweise Register.>> AVR Assembler ist eine Katastrophe, wenn man vorher jahrelang MCS51> programmiert hat.
Ich glaube, so führt die Diskussion in die falsche Richtung. Das ist
doch alles sehr subjektiv. Alle Assembler sind klar und geradlinig, wenn
man sie so sehen will - oder eben auch nicht. Ich habe mit MOS6210, bei
Mikrocontrollern dann PIC16 angefangen und außer dem Rest der
Microchip-Familie noch ATMega8, ATTiny und auch den STM32 mit Assembler
gefüttert. Bei allen ist es in der Regel so, dass ich das InstructionSet
bereithalte um im Zweifel zu überprüfen, was ich mache. Aber ich habe
mich nie über einen speziellen Assembler aufgeregt, der ist halt wie er
ist.
Jobst M. schrieb:> AVR Assembler ist eine Katastrophe, wenn man vorher jahrelang MCS51> programmiert hat.
Ist naturgemäss ungewohnt, wenn man vorher speicherorientierte
Programmierung gewohnt war. Ist nicht weiter bemerkenswert, wenn man
vorher schon RISCs kannte.
Hast du 51er mal mit viel Speicher verwendet? Und zwar solche Programme,
bei denen nicht alle wesentlichen skalaren Variablen in den ersten 128
Bytes Platz fanden? Wenn man viele Variablen nur verwenden kann, indem
man sie indirekt über den (im Original) einzigen Datapointer anspricht.
Macht keinen Spass.
> Dann dieses dusselige tmp-Register, welches man bei AVR ständig> benötigt.
R0 wird bei genau einer einzigen Befehlsgruppe implizit verwendet, die
du natürlich alle 3 Zeilen nutzt: den Multiplikationbefehlen.
> Und die Register empfand ich immer ehr als beengend im Gegensatz zum RAM> des MCS51. Register braucht man da ja nicht so viel.
Wenn man sich dran gewöhnt hat und verstanden hat, dass man Registern
Namen geben kann, dann stellt man fest, dass man in Assembler mit
AVR-Registern so umgehen kann wie 51er mit RAM. Eine ISR braucht 3
Register? Kriegt sie, fest zugeordnet.
AVR ist zudem die wohl einzige 8-Bit Mikrocontroller-Familie, bei denen
von vorneherein C-Compiler eingeplant waren. Und die können mit
Registern durchaus etwas anfangen. Inbesondere wenn man nicht nur mit
8-Bit Daten arbeitet. Akku-Architekturen sind schaurig umständlich,
sobald die zu verarbeitenden Daten breiter sind als der Akku.
Aber wenn man Assembler-Programmierung so sehr liebt, dass man alles auf
µCs damit macht, dann kann es lohnen, sich mal andereswo umzusehen.
MSP430 ist sehr elegant, auch die Renesas R8C/M16C/M32C sind sehr gut in
Assembler programmierbar.
Ralph S. schrieb:> Btw.: Die Maschinensprache der MCS-51 Familie empfinde ich im vgl. zu> AVR-ATmega und ATtiny oder STM32 als ausgesprochen angenehm und extrem> einsteigerfreundlich, von daher ist es vielleicht gar nicht so schlecht,> mit der 8051-Familie anzufangen !
Naja. Einige Sachen sind nett und praktisch für die
Assemblerprogrammierung. Andere sind... Müll. Beispielsweise die
verschiedenen Addressräume für den RAM und die Überlagerung von SFRs mit
RAM.
Das Ding stammt aus einer Zeit, als die 128 Bytes direkt adressierbares
RAM als Speicher für skalare Daten in den weitaus meisten Fällen locker
ausreichten. Die zweiten 128 Bytes vom 52er waren dann eher für
Pufferspeicher interessant, den man sowieso indirekt adressiert.
Das heutige Problem der 51er Familie ist, dass sie ihren angedachten
Einsatzzweck bei weitem überlebt hat, während dem viel eleganteren
Nachfolger (96er Familie) kein allzu langes Leben beschieden war.
Das ist mir klar. Du redest hier aber von Einsteigerfreundlichkeit. Ich
halte es nicht unbedingt für einsteigerfreundlich, einen Anfänger mit 4
verschiedenen RAM-Adressräumen zu verwirren.
greg schrieb:> Das ist mir klar. Du redest hier aber von Einsteigerfreundlichkeit. Ich> halte es nicht unbedingt für einsteigerfreundlich, einen Anfänger mit 4> verschiedenen RAM-Adressräumen zu verwirren.
Von denen er nichts mitkriegt. Ein Anfänger wird mit einem Programm zu
tun haben, das mit 128 Bytes RAM auskommt. Ergo: ein Adressraum für
Daten, einer für Code/Tabellen.
Das Problem ist eher die Zukunft. Wenn sich das als Lernprojekt in
Lehranstalten darstellt, dann bleibt es dabei und was Jahre später kommt
ist offen. Wenn man aber weiter machen will, dann gibts bessere
Möglichkeiten als 51er.
Zilog hatte es übrigens ähnlich erwischt. Der Z8 µC ist sehr angenehm in
Assembler zu programmieren - solange man nicht mehr als 256 Bytes für
RAM und I/O-Ports braucht. Beim Nachfolger eZ8 wurde das auf 4KB
aufgebohrt, die Eleganz musste dabei etwas Federn lassen.
Für Win32 gibt es eine IDE, die ASEM51 enthält, einige Simulatoren und
eine Option auf SDCC, womit die Programmierung von MCS51 proktisch
komplett erschlagen wird. Heisst MIDE51:
http://www.opcube.com/home.htmlJobst M. schrieb:> Matthias Sch. schrieb:>> Allerdings hat der AT89S8253 Anomalien,>> Die haben alle Anomalien!
Bei den AT89S51/52 waren für mich jedenfalls keine zu bemerken, die
haben sich im Programm wie die original Intel, mit denen ich Mitte der
80er zu tun hatte, verhalten, natürlich bis auf internes Flash statt
EPROM im 87C51.
Für eines der letzten Projekte, die ich vor ca. 7 Jahren mit MCS51
anfing, hätte ich gerne den internen EEPROM des 82S8253 benutzt, bis ich
dann mitkriegte, das ausgerechnet dies Feature völlig verbuggt war.
Letztlich lief es dann auf einen 89S52 mit externem 9346 EEPROM hinaus.
http://www.schoeldgen.de/bassalizer/index.html
Ich denke nicht, dass diese Diskussion weiter führt.
Der OP hat entschieden sich mit der MSC51 auseinander zu setzten, da
helfen auch die ganzen gut gemeinten Ratschläge für andere Architekturen
nichts. Ist doch OK, wenn er davon genug hat, schaut er sich vielleicht
auch noch mal was anderes an. Außerdem kennen wir den Kontext nicht,
warum es der MSC51 sein muss.
Ich habe damals mit Motorola 6800, 6502 und 6510 angefangen. Das war
einer der Gründe, warum ich mir damals einen c64 angeschafft hatte, da
die Input64 (Heise Verlag, wer kennt die noch?) dafür einen
Makroassembler herausgebracht hatte und man sich für den Expansionsport
einfach einen ROM-Emulator bauen konnte.
Danach kam die MSC48 und MCS51 Serie und der 68000. Später dann die
Intel 8080, 8085, etc.
Ganz ehrlich, heute wird auf einem sehr hohem Niveau gejammert. Heute
programmieren und debuggen wir unsere System mit JTAG und ISP. Wir haben
System mit mehren MHz teilweise sogar mehreren 100er MHz und wir haben
Funktionsgruppen nach denen wir uns damals die Finger geleckt hätten.
Und wofür nutzen wir das? Wir programmieren heute mit der
Holzhammermethode und über fünf Abstraktionsschichten Funktionen, die
man lieber andersweitig in Hardware gegossen hätte. In ein paar Jahren
wird, Raspberry sein dank, wohl keiner mehr ohne ein vollständiges OS
und Phyton auskommen. Ich freue mich dann schon auf die Fragen wie "Mein
PI ist für die XYZ-Steuerung zu langsam, wie kann man das beschleunigen
...". Antwort wird dann wohl sein: "Übertakten oder kaufe dir den PI XXL
2020 mit Octacore und 5GHz Systemtakt.".
Und wisst ihr was das schönste ist!
Wenn wir jemals wieder zurück auf die Bäume müssen, kommen wir da nie
wieder runter.
Also ich finde es gut, wenn mal jemand die alten MCS51 entstaubt und
diese mal wieder anfasst. Was für Gründe da auch immer hinter stecken.
@ Jobst M. (jobstens-de)
>AVR Assembler ist eine Katastrophe, wenn man vorher jahrelang MCS51>programmiert hat.
Naja, der Mensch ist ei Gewohnheitstier.
>IN, OUT, LDI, LD, ST, MOV ... beim MCS51 alles MOV
Stimmt, ist unglücklich. Hätte man locker im Assembler mit MOV machen
können und daraus intern verschiedene OpCodes.
>In Kombination mit unteren und oberen SFR dazu noch eine Falle.
Ja, ist auch eine Anfängerhürde.
>Man muss bei AVR für Rechenoperationen immer alles in den Registern>liegen haben.
Ist halt ne RISC Maschine.
> Beim MCS51 kann man direkt den Inhalt des RAMs oder eines>SFRs zum Akku addieren oder gar direkt in-/decrementieren.
Dafür braucht er im Original auch schlappe 12 Takte pro Maschinenzyklus!
>Dann dieses dusselige tmp-Register, welches man bei AVR ständig>benötigt.
???
>Oder Bitoperationen,
Was ist damit?
> Bitadressierbarer Speicher.
Ist nett bei 8051, stimmt. Aber nicht kriegsentscheidend.
>Bei den bedingten Sprüngen muss ich beim AVR jedes Mal nachsehen ...
Ich nicht. Das ist reine Übungssache.
>Oder MOVC A, @A + DPTR (Addiere A zum Pointer und hole den Inhalt der>ROM-Adresse in A) - beim AVR erst mal eine 16-Bit-Addition, bevor man>was bekommt.
Siehe RISC.
>MCS51 kann teilen.
Schön, aber kostet halt Silizium.
>MCS51: Decrementiere und springe, wenn nicht 0 (DJNZ) - super für>Schleifen!
Wieder RISC. Sind halt zwei Befehle, dec und brne
>Und die Register empfand ich immer ehr als beengend im Gegensatz zum RAM>des MCS51. Register braucht man da ja nicht so viel.
Und ob. Eben WENN man mal ein paar größere Daten zusammenbasteln will.
VErschachtelte Schleifen etc. Die Realität verlangt nach vielen
Registern. Schau dir diverse aktuelle Prozessoren an. Große wie kleine.
Die Akku-Maschinen haben nur nur in Einzelfällen überlebt, sonst nix.
>Wieso selbst? 68k ist großartig - sehr sauber!>Und der Programmierer hat immer eine 32-Bit Maschine vor der Nase - egal>ob 68008 oder 68060. Ist allerdings auch ehr als Prozessor, als als>Controller gedacht gewesen.
Stimmt. Schön war die Zeit ;-)
>Den kann man sogar direkt mit dem Code programmieren, weil selbst der>total aufgeräumt ist. 4e75 = RET - weiß ich heute noch :-)
SOO hart war ich dann doch nicht drauf. Maschinencode hab ich mir
praktisch nie angesehen.
Hallo!
Diese Diskussion driftet ja gaaaanz langsam von meiner
Ausgangsfragestellung ab ;-)
Ich kann nur nochmal betonen, dass es sich um ein Hobby handelt. Ich
mache das nicht weil ich mir dies und das bauen will oder mit den
topaktuellsten Sachen arbeiten will, obgleich mich diese auch
interessieren. Ich mache das alles allein deswegen, weil es mich
interessiert und da ist mir ziemlich egal welche Meinung jemand anders
über Controller/Prozessor XYZ hat (ich denke doch, dass es meine
Entscheidung ist, womit ich meine Freizeit verbringe). Lernen um zu
Lernen und je verschiedenartiger und vielfältiger desto besser. Ich
finds halt interessant. Leider hatte ich in meiner Jugend nicht die
Möglichkeiten in die Elektronik und die Frühzeit der Computer- und
Controllertechnik einzusteigen. Quasi hole ich das jetzt nach...
Aber egal, es waren ja auch sehr viele hilfreiche Hinweise dabei! Und
dafür möchte ich mich nun nochmal bei allen bedanken!
BTW warum soll man einen supertollen, ach so schnellen ARM verwenden,
wenn es anders auch geht? Vielleicht ein schlechter Vergleich, aber in
meinem eigentlichen Beruf (ich bin Biochemiker) habe ich festgestellt,
dass je umfangreicher man über die Möglichkeiten bescheid weiss, die
existieren und die man zur Verfügung hat, desto
schneller/einfacher/praktikabler kommt man zum Ziel. Und ich denke
grundsätzlich, je mehr man weiss desto besser.
Edson schrieb:> Ich glaube, so führt die Diskussion in die falsche Richtung.
Ich denke, die Diskussion ist schon längst beendet :-)
A. K. schrieb:> Hast du 51er mal mit viel Speicher verwendet? Und zwar solche Programme,> bei denen nicht alle wesentlichen skalaren Variablen in den ersten 128> Bytes Platz fanden? Wenn man viele Variablen nur verwenden kann, indem> man sie indirekt über den (im Original) einzigen Datapointer anspricht.> Macht keinen Spass.
Es hält sich aber in Grenzen. So schlimm wie von Dir beschrieben
empfinde ich das nicht.
A. K. schrieb:> R0 wird bei genau einer einzigen Befehlsgruppe implizit verwendet, die> du natürlich alle 3 Zeilen nutzt: den Multiplikationbefehlen.
Ich meine nicht R0. Ich meine R16 aufwärts, damit man Konstanten in ein
SFR schieben kann.
A. K. schrieb:> Wenn man sich dran gewöhnt hat und verstanden hat, dass man Registern> Namen geben kann, dann stellt man fest, dass man in Assembler mit> AVR-Registern so umgehen kann wie 51er mit RAM.
Man hat nur weniger davon ...
> Eine ISR braucht 3> Register? Kriegt sie, fest zugeordnet.
?? Ja ... und?
A. K. schrieb:> Akku-Architekturen sind schaurig umständlich,> sobald die zu verarbeitenden Daten breiter sind als der Akku.
Das ist allerdings wahr.
A. K. schrieb:> MSP430 ist sehr elegant,
Stimmt, nur 27 Befehle - aber z.T. eben auch für C-Compiler optimiert.
Einige Befehle muss man sich 'bauen', oder der Compiler macht das ...
> auch die Renesas R8C/M16C/M32C sind sehr gut in> Assembler programmierbar.
Die kenne ich nicht, habe ich allerdings auch schon häufiger gehört.
greg schrieb:> Das ist mir klar. Du redest hier aber von Einsteigerfreundlichkeit. Ich> halte es nicht unbedingt für einsteigerfreundlich, einen Anfänger mit 4> verschiedenen RAM-Adressräumen zu verwirren.
4? Selbst wenn dem so sein sollte, dann kann man wenigstens 3 mit MOV
erreichen. Problem für den Anfänger erledigt. Beim AVR muss man für den
richtigen Adressraum auch noch den richtigen Befehl wählen. Wenn man
Pech hat und den falschen erwischt, gibt es nicht einmal eine
Fehlermeldung.
Gruß
Jobst
@ Marek Walther (ma_wa)
>Der OP hat entschieden sich mit der MSC51 auseinander zu setzten, da>helfen auch die ganzen gut gemeinten Ratschläge für andere Architekturen>nichts. Ist doch OK, wenn er davon genug hat,
Jo.
>Ganz ehrlich, heute wird auf einem sehr hohem Niveau gejammert. Heute>programmieren und debuggen wir unsere System mit JTAG und ISP. Wir haben>System mit mehren MHz teilweise sogar mehreren 100er MHz und wir haben>Funktionsgruppen nach denen wir uns damals die Finger geleckt hätten.
In der Tat!
>Und wofür nutzen wir das? Wir programmieren heute mit der>Holzhammermethode und über fünf Abstraktionsschichten Funktionen, die>man lieber andersweitig in Hardware gegossen hätte.
Leider :-(
> In ein paar Jahren>wird, Raspberry sein dank, wohl keiner mehr ohne ein vollständiges OS>und Phyton auskommen. Ich freue mich dann schon auf die Fragen wie "Mein>PI ist für die XYZ-Steuerung zu langsam, wie kann man das beschleunigen>...". Antwort wird dann wohl sein: "Übertakten oder kaufe dir den PI XXL>2020 mit Octacore und 5GHz Systemtakt.".
Leider^2 :-((
>Also ich finde es gut, wenn mal jemand die alten MCS51 entstaubt und>diese mal wieder anfasst. Was für Gründe da auch immer hinter stecken.
Nostalgie?
Jobst M. schrieb:> Stimmt, nur 27 Befehle
Herrje, dieses Kriterium sollte eigentlich jeden in die Arme des PIC1654
treiben. Nur 29 Befehle - traumhaft!
Markus Müller schrieb:> 8051 µC gibt es auch von NXP (LPC900/LPC700), da kannst Du vorbeischauenLPC922 z.B. als DIP mit ROM-Bootloader kann direkt mit USB-seriell Kabel
und dem kostenlosen FlashMagic geflasht werden. Der ROM-Bootloader wurde
übrigens in die ARM LPCs übernommen.
Anderseits hat der LPC922 nichts was der ARM-Nachfolger LPC812 nicht
auch hat, und den gibt es auch als DIP.
Falk Brunner schrieb:> Was ist denn an AVR Assembler unangenehm? Der ist doch klar und> geradlinig strukturiert, man hat haufenweise Register. STM32 ist klar,> das ist ne andere Liga, kenn ich nicht, würde man praktisch auch> seltenst in ASM programmieren.
Vielleicht doch mal ansehen, ARM-Assembler ist deutlich einfacher als
AVR-Assembler (weniger Befehle, linearer Adressraum, alle Befehle
bedingt ausführbar - nicht nur Sprünge). Ist fast schade dass auf ARM
fast nur C programmiert wird. Hier mal der berühmte Euklid-Algorithmus:
int gcd (int a, int b)
{ while (a != b)
{ if (a > b) a = a - b; else b = b - a; }
return a; }
gcd
CMPS R0, R1
SUBGT R0, R0, R1 ; greater than >
SUBLE R1, R1, R0 ; less or equal <=
BNE gcd
Lothar schrieb:> Hier mal der berühmte Euklid-Algorithmus:
Aber nur ARM im Original. Bei den CM3 kommt einer hinzu, bei den CM0
gehts so überhaupt nicht. Bei ebendiesen Original-ARMs ist aber die
Bastelei mit Konstanten nicht nach jedermanns Geschmack. Wenn man sie
aus Zeitgründen nicht PCrel laden will.
So richtig schön war aber Intel 860 im pipelined Mode. Daran haben sich
sowohl die Compiler als auch gute Assembler-Programmierer die Zähne
ausgebissen.
A. K. schrieb:> Aber nur ARM im Original. Bei den CM3 kommt einer hinzu
Stimmt das vergesse ich immer, weil der IAR Assembler beim M3 den ITE
automatisch einfügt. Braucht der ITE wirklich Zykluszeit, ich dachte der
ist nur für die Pipeline-Steuerung?
Also man kommt auch in ARM-Assembler hinein, wenn man das möchte, und
vorher MCS51 hatte. Keine Frage. Den fand ich auch äußerst interessant.
Ich persönlich komme sowieso mit allem zurecht, besonders den PIC.
Für einen ARM, den ich aber beruflich bearbeiten mußte, nicht im Hobby,
mußte ich auch mal ganz kleine trickreiche Assembler-Schnipselchen
machen, z.B. für das Startup-File, was bei Keil ja auch komplett in
Assembler geschrieben war. An den Interruptvektoren die Spurious
Interrupts oder Surprise Interrupts nachträglich behandeln, abfangen,
ein Thema bei den NXP LPC2000. Das klappte auch vorzüglich, nicht
zuletzt wegen eines sehr guten Assembler-Tutorials und sogar von
Chinesen, was ich mal im Internet fand, in Europa gabs zu diesem
Zeitpunkt nix.
Die Linuxer damals in der Firma implementierten in ein Embedded-Board
auch reichlich ARM-Assemblercode Funktionen. Also nicht C. Für einen
ARM, wo ein Linux drauf laufen sollte. Aber davon kenne ich nichts, habe
nur seitenweise dort schönen ARM-Assembler gesehen. Z.B. einfacherweise
einzelne Funktionen wie COPY32 u.ä..
Lothar schrieb:> Braucht der ITE wirklich Zykluszeit, ich dachte der> ist nur für die Pipeline-Steuerung?
Gute Frage. Immerhin muss die fetch/decode stage ihn irgendwie
bearbeiten. Könnte evtl. vom Kontext abhängen.
Jobst M. schrieb:> 4? Selbst wenn dem so sein sollte, dann kann man wenigstens 3 mit MOV> erreichen. Problem für den Anfänger erledigt.
Neben DATA, IDATA und XDATA gibt es auch noch PDATA, per Register
addressierbarer externer RAM.
Jobst M. schrieb:> Beim AVR muss man für den> richtigen Adressraum auch noch den richtigen Befehl wählen.
Hm, was meinst du damit genau? Es gibt beim AVR doch nur den
Programmspeicher und RAM.
greg schrieb:> Hm, was meinst du damit genau? Es gibt beim AVR doch nur den> Programmspeicher und RAM.
Ihm wäre es lieber gewesen, wenn IN/OUT als Spezialfall von LDS/STS vom
Assembler adressabhängig in die entsprechenden Opcodes umgesetzt würden.
Und da gebe ich ihm Recht, der Zirkus mit den um 0x20 verschobenen
Adressen muss wirklich nicht sein.
Derzeit ist es ja so, dass Ports im IN/OUT Bereich nur mit IN/OUT
verwendet werden dürfen, weil sonst die Adresse um 0x20 verschoben ist.
Das ist Murks.
Den Versatz immerhin haben die Xmegas abgeschafft. Die indirekte
Adressierbarkeit der Register vermisst wohl niemand.
Jobst M. schrieb:> Edson schrieb:>> Ich glaube, so führt die Diskussion in die falsche Richtung.>> Ich denke, die Diskussion ist schon längst beendet :-)
In Bezug zur Eingangsfrage gab es eigentlich gar Keine. Ich meinte auch
eher das, was sich parallel angebahnt hat.
Es bringt schon nicht viel, sich über Schönheiten und Hässlichkeiten
eines Assemblers zu unterhalten. Aber noch weniger bringt es, gegen die
Eigenschaften des einen Mikrocontrollers zu Argumentieren, wenn man aus
gutem Grund eine Anderen gewählt hat, oder?
Ich meine, wenn die Entscheidung schon gefallen ist :)
greg schrieb:> Also, ich will OP bestimmt nicht davon abhalten, mit einem 8051er> anzufangen. Aber man muss doch dazu stehen, dass die Architektur diverse> Macken hat.
Er ist kein Einsteiger, er will sich nur mit einem 8051 weiter bilden!
greg schrieb:> Also, ich will OP bestimmt nicht davon abhalten, mit einem 8051er> anzufangen. Aber man muss doch dazu stehen, dass die Architektur diverse> Macken hat.
Nöö, das sind nette Features, keine Macken.
Es ist ja eine schöne Illusion, zu glauben, Macken seien bei neueren
moderneren Dingen endgültig alle beseitigt. ;-)
Aber es wird immer so sein, daß einem was gefällt, und dem anderen
nicht.
Hi,
als eines der billigsten und IMHO coolsten 8051-Entwicklungssysteme
würde ich auch mal die AX206-Schlüsselanhänger nicht vergessen:
http://www.vdr-portal.de/board18-vdr-hardware/board11-displays/p1149586-howto-dpf-easy-hacking-tng
Da kriegt man immerhin auf Ebay die Dinger ab 5€ und hat einen TFT-LCD
und USB mit dabei. Entwicklungssystem basiert voll auf SDCC (wer will,
kann's auch mit Keil probieren..). Das einzige was nervig ist: die
Dinger sind oft sehr unterschiedlicher qualität und Bauweise, aber da
muss man einfach bisschen rumfragen in den Foren.
Harald schrieb:
--snip --
> Aber danke schon mal für die tollen Vorschläge. Scheint so, als ob ATMEL> auch bei 8051 vorne dabei ist.
Hab mich schon mit sehr vielen verschiedenen uCs beschaeftigt und wenn
es denn der 8051 sein soll, dann ein paar Vorschlaege dazu.
Wie bereits mehrfach erwaehnt wuerde auch ich die SiLabs Chips
waermstens empfehlen. Dort gibt es alles von sehr einfachen Chips bis
hin zu 100 MHz Teilen, die in vielen Dingen einen Durchsatz wie 32-bit
uCs bieten. Der Hauptgrund fuer Silabs ist allerdings, dass die
weiterhin an den 8-bit Teilen arbeiten. Inzwischen ist auch bei SiLabs
der Cortex hoechste Prioritaet (siehe Zukauf von Energy Micro) aber im
Gegensatz zu vielen anderen bereits genannten ist die 8-bit Familie noch
lebendig.
Atmel hat verschiedene hervorragende, gute und auch weniger gute
Produktfamilien. Die 8051 werden nur noch gemolken, gehoeren zu den
weniger guten. Wenn Atmel, dann AVR oder Cortex-M.
Infineon hat zwar die Hobbyisten nicht gerade im Fokus aber doch ein
paar nette 8-bitter. Sollte Motorsteuerung oder komplexe
Timergeschichten auf deinem Lernplan stehen, schau dort mal rein.
Cypress kann ich fuer 8051 nicht empfehlen, ausser der 20-bit
Delta-Sigma ADC steht auf deiner Wunschliste. Die Teile sind im Aufbau
sehr kompliziert und wenn man etwas anderes machen moechte als PSoC
Creator (IDE) vorgibt, steht man recht schnell im Wald.
NXP LPC700 und (viel besser) LPC900 hab ich selbst als Architekt
mitdefiniert, also sind das auch schoene Bausteine ;). Trotzdem kann ich
die nicht mehr empfehlen, denn sie sind bei NXP weit ausserhalb aus dem
Fokus gerueckt. Sie nenne die LPC900 "legacy" das ist schon eine
"Anti-Empfehlung" NXP LPC1xxx oder LPC4xxx sind allerdings auch sehr
interessante Alternativen zum STM32.
Zusammenfassende meine Empfehlung fuer 8051 basierende Chips in dieser
Reihenfolge:
1. Silabs
http://www.silabs.com/products/mcu/Pages/8-Bit-Microcontrollers.aspx
2. Infineon XC800 Familie
http://www.infineon.com/cms/en/product/microcontrollers/8051-compatible-8-bit-microcontrollers/channel.html?channel=ff80808112ab681d0112ab6b7661083f
3. NXP http://www.nxp.com/products/microcontrollers/8_16_bit_legacy/
4. Atmel
http://www.atmel.com/products/microcontrollers/8051architecture/default.aspx
Gruss aus dem trockenen Kalifornien, Robert
Bei der ganzen "Diskussion" über verschiedene ANDERE Controller würde
mich jetzt eher interessieren, welchen Weg der Threadersteller bei den
8051ern geht ?
Auch wenn der super veraltet ist (und ich selbst neues mit diesem
praktisch nichts mehr mache) würde mich doch eher interessieren, mit
welchem Equipment er da jetzt beginnt?
Zum lernen wie ein Controller (oder ein Prozessor) funktioniert finde
ich den nach wie vor auch heute noch "genial".
Die Verwandschaft (alleine schon die Mnemonic) zu 8080 / 8085 oder sogar
auch schon 8086 (auch wenn der 16-Bittig ist) ist nicht zu übersehen).
Die sehr einfache Art, Code in einen extern angeschlossenen RAM zu
transferieren und dort auszuführen (früher nannte man so etwas
Monitorprogramm... heute basteln wir noch ein paar Funktionen hinzu und
nennen das Betriebssystem) finde ich schon sehr gut und verdeutlicht
einem einiges.
Adressbereiche kann man so sehr viel deutlicher verstehen als mit allem
anderen. Schade ist, dass es keinen "I/O - Zugriff" gibt, dann könnte
man dort auch noch schön den Unterschied zwischen Memory mapped und I/O
mapped erkennen!
Die Schwierigkeit heute beim 8051er ist, dass es zwar mittlerweile
einige (viele) mit ISP Unterstützung gibt (und auch preiswerte
Controller), aber die Unterstützung mit Flashprogrammern (die nur etwas
taugen) ist ultra dürftig. Selbst Atmel hat für diese nur einen ultra
veralteten Programmer für den Paralleport, der in sehr vielen Fällen
nicht mehr existent ist.
Deswegen würde es mich wie gesagt interessieren wie der Threadersteller
jetzt "vorgeht":
- Welche Sprache ?
- Welche IDE (wenn überhaupt)
- Welchen Flasher ?
Gruß,
R. Seelig
Ralph S. schrieb:> aber die Unterstützung mit Flashprogrammern (die nur etwas> taugen) ist ultra dürftig
Aber ich habe oben doch schon geschrieben (und natürlich selber
ausprobiert & genutzt), das der AVRISP MkII die 89S51/89S52 prima
flashen kann, der kommt auch mit der umgekehrten Resetpolarität ohne
Zusatzhardware klar.
Bei den neueren Chipvarianten nutzt du dann deren Bootloader. Nur ein
paar Krücken bei Atmel brauchen das olle Paralleldings, wie eben z.B.
der AT89S8253.
Als IDE habe ich MIDE51 benutzt, mittels eines kleinen Batchfiles kannst
du direkt aus der IDE dein Zielsystem flashen. MIDE51 liefert ASEM51 mit
und hat ne Option auf den SDCC, wenn du den besorgst, bzw. hast.
Schmunzeln muß, ich wollte ja nicht wissen wie DU das machst, sondern
der Threadersteller...
Ich hab ja mit dem Flashen der 51er kein Problem, ich hatte mir (sehr
mühselig) eben etwas eigenes gebastelt gehabt (an der seriellen
Schnittstelle) die eben auch kein Problem mit dem 8253 hat (das Problem
bei diesem Chip ist, dass das Flashen einzelner Bytes ewig viel länger
als bspw. bei einem S52 dauert - siehe Datenblatt -).
Der 8253 wird "NUR" (wie der S2051 und S4051) im Pagemodus relativ
schnelle geflasht !
Nachdem ich den 8253 im Griff hatte, fand ich den wirklich nicht
schlecht:
konnte mehr als die generischen S51 / S52 und war preislich DEUTLICH
weit unterhalb der Chips, die einen Bootloader haben ! (Btw. ich kann
Bootloader nicht wirklich leiden, der Umgang mit diesen beim
Programmieren der Chips finde ich einfach nur Umständlich, ich geben am
PC entweder ein Flashkommando das in die IDE eingebunden ist oder ich
benutze eine Oberfläche. Aber das "gefummel" auf einem Board mit,
Schalter umstellen, Reset-Taste drücken etc. finde ich etwas nervig ).
Also als IDE habe ich die freien mide51 und mcs51 gefunden. Zusätzlich
habe ich keil zur Verfügung. Bascom wäre auch zu probieren.
Also assembler, c und Basic.
Programmer werd ich mich umsehen, wenn die Chips feststehen.
Harald schrieb:> Programmer werd ich mich umsehen, wenn die Chips feststehen.
Wäre es denn nicht zielführender, zunächst nach einem Programmer für die
bevorzugte IDE zu schauen und dann die uC zu besorgen?
Was hast du von einem "schönen Chip", wenn die IDE nicht frei ist und
der Programmer nur schwer zu beschaffen oder total überteuert ist? Solls
ja geben.
Also Maxim/Dallas (wo ich Samples bestellt habe) stellt einen Loader zur
Verfügung.
Für die ATMEL Chips gibts ebenso entsprechende Loader.
Also vollkommen unabhängig von der Tool Chain/IDE....
Für die parallel zu programmierenden muss ich mich sowie schlau machen.
Die jeweils nötige Peripherie kann man sich basteln.
Also wo ist das Problem? Die IDE hat ja nix mit dem Programmer zu tun.
Bei mir darf es ruhig auch ein bisschen Kommandozeile sein. Bin nicht so
der ein-Klick-Mensch. Dann weiss ich wenigsten was passiert...
Robert Teufel schrieb:> Hab mich schon mit sehr vielen verschiedenen uCs beschaeftigt und wenn> es denn der 8051 sein soll, dann ein paar Vorschlaege dazu.>> Wie bereits mehrfach erwaehnt wuerde auch ich die SiLabs Chips> waermstens empfehlen. Dort gibt es alles von sehr einfachen Chips bis> hin zu 100 MHz Teilen, die in vielen Dingen einen Durchsatz wie 32-bit> uCs bieten. Der Hauptgrund fuer Silabs ist allerdings, dass die> weiterhin an den 8-bit Teilen arbeiten. Inzwischen ist auch bei SiLabs> der Cortex hoechste Prioritaet (siehe Zukauf von Energy Micro) aber im> Gegensatz zu vielen anderen bereits genannten ist die 8-bit Familie noch> lebendig.
Hallo Herr Teufel,
lange nichts von Ihnen gehört. Sie scheinen immer noch bei NXP zu sein.
Die SiLabs-Dinger sind ganz nett, aber wenn am besten schon jemand ein
wenig den 8051 aus älteren Zeiten kennt.
Es ist schon ein paar Jahre her, und ich hatte auf dem Entwicklungstisch
zwei Boards liegen: Eines mit einem SiLabs 8051, der 100 MHz kann, und
ein LPC2000-Board von Keil.
Die 100MHz sind mit den 2-Cycle-Core auch richtig was, das geht ab wie
Hund.
Ich hatte die Aufgabe, bei Einschaltung verschiedener Peripherals mal
Energieverbrauchsmessungen zu machen. Dabei wurde ich völlig überrascht.
Die SiLabs-Teile hatten doch bei ähnlicher Performance den dreifachen
Stromverbrauch als die LPC2000. Wofür wir uns entschieden, war dann
völlig klar. Aus dem Bauch heraus ohne Messungen hätte ich damals
vermutet, daß die Energiebilanz deutlicher zum 8-Bitter aus fällt, war
es aber nicht.
Es liegt da wohl an den Halbleiterstrukturen, damit steht und fällt auch
ein Energieverbrauch.
Es kam dem Unternehmen auf den Energieverbrauch pro Rechenleistung an.
Denn man hatte auch autonome Versorgungen mit Solarpanels im Auge.
Aber der TO sollte doch auch mal versuchen, eine Suche hier in das
Marktforum zu setzen. Suche altes 8051-Eval-Board bspw.. Da wurden immer
auch mal welche durch Entrümpelungen verschenkt, sogar Boards mit dem
80C517A drauf. Der hat sogar für heutige Ansprüche noch ein paar nette
Features, und ich arbeite immer noch damit.
Harald Nagy schrieb:> Also Maxim/Dallas (wo ich Samples bestellt habe) stellt einen Loader zur> Verfügung.
Geht auch direkt mit einem Terminalprogramm.
> Für die ATMEL Chips gibts ebenso entsprechende Loader.
Für die, die einen Bootloader haben. Also die AT89C51EB/RB/RC...
Geht auch direkt mit einem Terminalprogramm.
Harald Nagy schrieb:> Dann weiss ich wenigsten was passiert...
Kenne ich, geht mir genau so.
Dann ist das Terminalprogramm Dein Freund :-)
Wenn Du eine günstige Lösung suchst, um AT89S8253 (oder die anderen) zu
flashen, kannst Du Dich auch gerne melden.
Gruß
Jobst
Wilhelm F. schrieb:>> Hallo Herr Teufel,
War ich da gemeint? Herr Teufel hat schon lange niemend mehr zu mir in
den Foren gesagt :)
>> lange nichts von Ihnen gehört.
Bin nicht mehr oft im deutschen Forum.
> Sie scheinen immer noch bei NXP zu sein.
Eher nicht, da habe ich mich bereits 2007 verabschiedet. Die LPC900
wurden so zwischen 2001 und 2005 zum Leben erweckt, da war ich dort.
> Die SiLabs-Dinger sind ganz nett, aber wenn am besten schon jemand ein> wenig den 8051 aus älteren Zeiten kennt.>> Es ist schon ein paar Jahre her, und ich hatte auf dem Entwicklungstisch> zwei Boards liegen: Eines mit einem SiLabs 8051, der 100 MHz kann, und> ein LPC2000-Board von Keil.>> Die 100MHz sind mit den 2-Cycle-Core auch richtig was, das geht ab wie> Hund.>> Ich hatte die Aufgabe, bei Einschaltung verschiedener Peripherals mal> Energieverbrauchsmessungen zu machen. Dabei wurde ich völlig überrascht.> Die SiLabs-Teile hatten doch bei ähnlicher Performance den dreifachen> Stromverbrauch als die LPC2000. Wofür wir uns entschieden, war dann> völlig klar. Aus dem Bauch heraus ohne Messungen hätte ich damals> vermutet, daß die Energiebilanz deutlicher zum 8-Bitter aus fällt, war> es aber nicht.
Die aelteren Silabs 51-er waren sehr auf schnellen Takt ausgelegt, das
frisst Strom! Ausserdem waren aeltere Prozesse in Benutzung -> nicht gut
fuer die Energiebilanz.
>> Es liegt da wohl an den Halbleiterstrukturen, damit steht und fällt auch> ein Energieverbrauch.>> Es kam dem Unternehmen auf den Energieverbrauch pro Rechenleistung an.> Denn man hatte auch autonome Versorgungen mit Solarpanels im Auge.
Da waere doch ein MSP430 angesagt gewesen oder nicht?
> Aber der TO sollte doch auch mal versuchen, eine Suche hier in das> Marktforum zu setzen. Suche altes 8051-Eval-Board bspw.. Da wurden immer> auch mal welche durch Entrümpelungen verschenkt, sogar Boards mit dem> 80C517A drauf.
Tja, den C517A mag ich auch und das Marktforum ist mir nicht in den Sinn
gekommen weil wohl keiner was in die USA schicken moechte. Ist eine gute
Idee! Flash hat der zwar nicht aber schoene Timer, einen ordentlichen
ADC, 2 serielle und viele I/Os.
Bevor ich bei NXP aufschlug war ich naemlich FAE bei Siemens-> Infineon
:)
Schoene Gruesse in die alte Heimat, Robert
Robert Teufel schrieb:
> LPC900 hab ich selbst als Architekt> mitdefiniert, also sind das auch schoene Bausteine ;).
Hallo Robert, da Du vom Fach bist, folgende Frage:
Ist es erlaubt, einen 8051 Software-Emulator zu vertreiben oder hat
Intel die Hand auf dem Befehlssatz?
Hab jetzt endlich mal Zeit gehabt eure Vorschläge zu recherchieren. In
Frage kommen demnach folgende:
LPC922
AT89LP2052
AT89C51CC03
AT89C51ED2
AT89C51RB2
AT89C51RC2
von den vieren meines erachtens entweder der CC03 oder ED2, wenn schon
PLCC
AT89S51
AT89S52
AT89C4051
So, nun welchen nehmen...
Harald schrieb:> Hast du was im petto?
Jopp.
Harald Nagy schrieb:> LPC922
Jopp. Schnell. Aber kaum Peripherie.
> AT89LP2052
Jopp. Sehr schnell. Aber auch kaum Peripherie.
> AT89C51CC03
Jopp. Aber bei Reichelt bekommst Du den nicht!
Achte darauf, dass hinter dem ...03 ein U steht. Sonst kommt der mit CAN
Bootloader (dann ein C)
> AT89C51ED2> AT89C51RB2> AT89C51RC2
Nope. Bei den PLCC würde ich mich für den CC03 allein schon wegen des
ADC entscheiden.
> AT89S51> AT89S52> AT89C4051
Nope. Die beiden 51er sind auch wirklich 8051. Der 52 ist zwar ein 8052,
aber nur 1000x beschreibbar.
(Ich stelle gerade die Verwandschaft mit einem Analogschalter fest ...)
> So, nun welchen nehmen...
:-)
Hattest Du nicht auch welche von Dallas bestellt?
Ich habe gerade nochmal nach Alternativen Ausschau gehalten und könnte
mich gerade maßlos über die RS-Seite aufregen. Scrollen ist die Maxime -
oder wie? Wer programmiert sowas? **Kopfschüttel*
Die coolen Teile gibt es aber nicht als DIP oder PLCC.
Wenn die 80c535/537 nicht mit externem ROM zu betreiben wären, würde ich
sogar danach bei eBay Ausschau halten ...
Gruß
Jobst
Jup die Dallas teile sind unterwegs. 430 und 320. Der 320er ist
allerdings ROMless...
Den cc03 gibt es mit und ohne 'c'. Mit c steht can bootloader, ohne c
uart.
Das wäre dann also der vernünftigste...?
Der 430er ist doch ganz cool! Damit würde ich jetzt erstmal einfach
loslegen.
Den CC03 gibt es mit C und mit U und nicht ohne etwas. ;-)
Exakt so sollte Deiner dann heissen: AT89C51CC03UA-SLSUM
Steht auch im Datenblatt 'Ordering Information'
Gruß
Jobst
Muss ich dir recht geben.
Dann werd ich mal mit dem anfangen was jetzt unterwegs ist und dann
weiter schauen. Aber grundsätzlich steht die Auswahl ja jetzt fest.
Danke wieder mal allen die geholfen haben!
Harald schrieb:> Den Link hatte ich vergessen> http://www.reichelt.de/Atmel-C51-Controller/T-89C5...>> Auch wenn die anderen nur 1000x programmierbar sind, dafür sind sie> billiger oder?
Wenn so ein Stein nur 1000x programmierbar ist, dann kaufst du einen
oder zwei weitere auf Reserve. Für 1000x flashen brauchst du schon eine
ganze Weile.
Bei einem Flash-Versuch pro halbe Stunde sind das 500 Stunden, also drei
Wochen ununterbrochen.
Robert Teufel schrieb:> Wilhelm F. schrieb:>>>>> Hallo Herr Teufel,> War ich da gemeint? Herr Teufel hat schon lange niemend mehr zu mir in> den Foren gesagt :)
Was ein Glück, daß ich nicht noch "Sehr geehrter Herr Teufel" schrieb.
;-)
> Die aelteren Silabs 51-er waren sehr auf schnellen Takt ausgelegt, das> frisst Strom! Ausserdem waren aeltere Prozesse in Benutzung -> nicht gut> fuer die Energiebilanz.
Die Wechsel von Halbleiterprozessen kann man aber als eher kleinerer
Kunde auch gar nicht durchschauen. Da gibts wenig Info.
> Da waere doch ein MSP430 angesagt gewesen oder nicht?
Hmmm, ich glaube, den gabs 2005 noch nicht so.
Außerdem legten wir ein wenig Wert darauf, bei Tools wie dem Compiler
bei Keil zu bleiben. Man kannte sich halt lange, und wenn mal was nicht
stimmte, gabs halt hervorragenden Support.
Ich hab noch ein SiLabs-Board, aber auch schon fast 10 Jahre alt. Einen
C8051F064. Immerhin auch schon mit 25MHz und dem 2-Cycle-Core.
Was mache ich da eigentlich, um den mal wieder in Betrieb zu nehmen?
Läuft rein auch mit Speisespannung nur über USB, kein Netzteil nötig.
Neue Tools suchen? Die alte SiLabs-IDE von damals auf der CD könnte
inzwischen so ihre Mätzchen machen. Das war ja für Windows XP. Die würde
sowieso nur rein zum Flashen verwendet, weil die hatte ja eine starke
Codebeschränkung auf nur 2kByte.
Wilhelm F. schrieb:> Hmmm, ich glaube, den gabs 2005 noch nicht so.
Doch. In der Firma in der ich bis 2000 gearbeitet habe, wurde der schon
einige Jahre zuvor eingesetzt.
Gruß
Jobst
Wilhelm F. schrieb im Beitrag #3483873
>> Was mache ich da eigentlich, um den mal wieder in Betrieb zu nehmen?> Läuft rein auch mit Speisespannung nur über USB, kein Netzteil nötig.> Neue Tools suchen? Die alte SiLabs-IDE von damals auf der CD könnte> inzwischen so ihre Mätzchen machen. Das war ja für Windows XP. Die würde> sowieso nur rein zum Flashen verwendet, weil die hatte ja eine starke> Codebeschränkung auf nur 2kByte.
Servius,
Lade dir die aktuelle silab IDE runter, läuft bei mir auch unter win7
soweit astrein
Als Compiler bindest z.b den sdcc ein, den nutze ich auch schon länger
alternativ bietet silab mit Registrierung auch den Keil Compiler
unbeschränkt an zum
einbinden.
Gruß Flo
FloMann schrieb:> Wilhelm F. schrieb im Beitrag #3483873>>>> Was mache ich da eigentlich, um den mal wieder in Betrieb zu nehmen?>> Servius,> Lade dir die aktuelle silab IDE runter, läuft bei mir auch unter win7> soweit astrein> Als Compiler bindest z.b den sdcc ein, den nutze ich auch schon länger> alternativ bietet silab mit Registrierung auch den Keil Compiler> unbeschränkt an zum> einbinden.
Ja, Danke!
Irgend wie so werde ich es machen. SDCC habe ich ja von anderen
8051-Derivaten, und kenne mich schon etwas darin aus.
Da bleibt nur die Frage offen, ob mein C8051F064EK Demo-Kit debuggen
kann oder nicht. Mit dem SDCC sehe ich dann etwas schwarz.
Aber da bekomme ich selbst wieder Laune, zu basteln. Mal sehen, ob ich
mal ein Testprogrämmchen mache, LED blinken. ;-)
Ansonsten schaute ich mal wieder näher in die Datenblätter. Schöne
Teile. Ich bin schon wieder erstaunt, obwohl das Board ja nun auch schon
fast 10 Jahre alt ist.
Es wäre dem Harald auch sehr zu empfehlen.
Wilhelm F. schrieb:> FloMann schrieb:>>> Wilhelm F. schrieb im Beitrag #3483873>>>>>> Was mache ich da eigentlich, um den mal wieder in Betrieb zu nehmen?>>>> Servius,>> Lade dir die aktuelle silab IDE runter, läuft bei mir auch unter win7>> soweit astrein>> Als Compiler bindest z.b den sdcc ein, den nutze ich auch schon länger>> alternativ bietet silab mit Registrierung auch den Keil Compiler>> unbeschränkt an zum>> einbinden.>> Ja, Danke!>> Irgend wie so werde ich es machen. SDCC habe ich ja von anderen> 8051-Derivaten, und kenne mich schon etwas darin aus.>> Da bleibt nur die Frage offen, ob mein C8051F064EK Demo-Kit debuggen> kann oder nicht. Mit dem SDCC sehe ich dann etwas schwarz.
Dem EK liegt ja normal der silab jtag/c2 programming/debug adapter
dabei, mit diesem geht
es auch in verbindung mit sdcc. Bissel blöd ist es bei structs/unions
und einfachen variablen
wenn der Compiler diese optimiert, static hilft dann aber zum bequemen
watchen letzteres..
anzahl der breakpoints könnte höher sein und hier und da kann man mal
kein breakpoint in eine
code zeile setzen Aufgrund fehlender adresskorrelation..
für eine blinky blinky led aber mehr als ausreichend..
Allgemein ist die silab ide für die 8bitter etwas spatanisch gehalten,
aber durchaus gut mit zu
arbeiten. Auch wenn der c51 core nicht wirklich für C prädestiniert sein
mag,
bei komplexeren programmen würde ich nicht im traum dran denken
diese selbst rein in asm zu schreiben, da mag der asm als noch so toll
Empfunden werden mit effizienten arbeiten im ganzen gesehen hat das imo
wenig zu tun.
> Aber da bekomme ich selbst wieder Laune, zu basteln. Mal sehen, ob ich> mal ein Testprogrämmchen mache, LED blinken. ;-)>> Ansonsten schaute ich mal wieder näher in die Datenblätter. Schöne> Teile. Ich bin schon wieder erstaunt, obwohl das Board ja nun auch schon> fast 10 Jahre alt ist.>> Es wäre dem Harald auch sehr zu empfehlen.
Jup die silab c51er hab ich auch recht gerne, hier im forum haben sie
wohl aber weniger
Beachtung, gibt ja auch eine breite pallette an verschiedenen typen,
sind imo immer
mal ein blick wert.. zb. der f06x ,wenn man es braucht, hat echt gute
brauchbare 1msps 16bit adc
mit DMA und für bissel mehr speicher ein unkompliziertes emif... sind
aber halt nicht wirklich die
kostengünstigsten aber noch im rahmen....
Harald schrieb:> Die leidigen Diskussionen welche Systeme besser sind, interessieren mich> nicht wirklich.
Dann sollte man hier auch nicht solche Fragen stellen.
Ein vernünftige Antwort bekommt man hier sowieso nie.
OldMen schrieb:> Ein vernünftige Antwort bekommt man hier sowieso nie.
Doch.
Man muß einfach nur das Rauschen wegfiltern, also in diesem Fall alle
Antworten ohne 8051-Bezug.
Das Rauschen läßt sich leider nicht vermeiden.
Es mag zwar Foren geben mit weniger Rauschen, dann aber oft auch mit
weniger Nutzsignal.
Jobst M. schrieb:> Die beiden 51er sind auch wirklich 8051. Der 52 ist zwar ein 8052,> aber nur 1000x beschreibbar.
Also im Atmel AT89S52 Datenblatt steht:
Endurance: 10,000 Write/Erase Cycles
Und beim AT89C51CC03:
Read/Write Cycle: 100K
Peter Dannegger schrieb:> Also im Atmel AT89S52 Datenblatt steht:> Endurance: 10,000 Write/Erase Cycles
Oh, neues Datenblatt ... nun können die also 10x so viel ... In Rev. C
steht noch 1000x
Komisch, dabei habe ich die Dinger durch flashen schon mehrfach kaputt
bekommen und dachte, dass wär okay so ...
Gruß
Jobst
Jobst M. schrieb:> Komisch, dabei habe ich die Dinger durch flashen schon mehrfach kaputt> bekommen und dachte, dass wär okay so ...
Normalerweise schafft man so bald kein Flash. Rechne mal 10.000 Zyklen
und alle Viertelstunde einen Flash-Vorgang. Da bist du bei 2500 Stunden,
das ist mehr als ein Vierteljahr, wenn man pausenlos arbeitet.
Bei einem LPC2000-er passierte mir mal ein Schnitzer: Ich machte ein
Programm, was laufend einen Flash-Sektor löscht und beschreibt, so im
15-Sekunden-Takt. Es sollte eigentlich nur mal ein paar Minuten laufen,
und über die serielle Schnittstelle einen Snapshot auf dem PC-Bildschirm
ausspucken. Am Feierabend vergaß ich ausgerechnet an dem Tag, als das
Programm lief, die Stromabschaltung am Arbeitsplatz. Die Augen und der
Verstand sind um die Feierabendzeit gelegentlich schon mal etwas
viereckig. Na, am nächsten Tag flashte es morgens noch schön, und an dem
µC habe ich in der folgenden Zeit überhaupt nichts bemerkt.
Dumdideididel.
Die Katz hat die Fidel und die Kuh springt über den Mond.
Ein kleiner Sprung für eine Kuh aber ein großer Sprung für die Kuhheit.
So, das musste hier mal in aller Deutlichkeit gesagt werden.
A. K. schrieb:> Das Flash kriegt man recht fix verbrannt, wenn man einen Debugger> verwendet, der für Breakpoints den Code im Flash modifiziert.
OK, sowas passiert dann bestimmt schon mal im Minutentakt, anders als
beim kompletten Flash-Download.
Da beginne ich schon wieder meine ollen 8051-er mit
Von-Neumann-Schaltung und Code im RAM zu lieben. Dort zerbröselt ja
wirklich gar nichts.
Wilhelm F. schrieb:> Rechne mal 10.000 Zyklen> und alle Viertelstunde einen Flash-Vorgang.
Nö. Bei dem Ding Rechne ich tatsächlich mit 1000.
Und wenn ich FW optimiere, geht das auch im Minutentakt!
Gut, da haue ich bei einem Projekt nicht 1000 Zyklen durch, aber nach
ein paar wenigen Projekten ist das Ding hin.
Gruß
Jobst
Jobst M. schrieb:> Gut, da haue ich bei einem Projekt nicht 1000 Zyklen durch, aber nach> ein paar wenigen Projekten ist das Ding hin.
Jetzt traue ich mich kaum noch, mein schönes SiLabs-Board auszupacken,
und zu schauen, ob es online debuggen kann. Die Flash-Zyklen normale
Programmdownloads machen aber wohl nichts, sind auch wohl mehr als
10.000.
Auf meinen ollen Boards mit dem RAM als Codespeicher brauche ich mir
damit überhaupt nie Gedanken zu machen. Da wird nicht geflasht, sondern
geRAMt.
Jobst M. schrieb:> Gut, da haue ich bei einem Projekt nicht 1000 Zyklen durch, aber nach> ein paar wenigen Projekten ist das Ding hin.
Vielleicht ein Bug in der Programmer-Firmware, irgendeine Zeit zu kurz.
Wie äußert sich überhaupt das "ist das Ding hin"?
Ich hatte früher mal den AT89S8252 verwendet, da ließ sich kein einziger
totflashen.
"kaputt" heisst bei Flash, dass die spezifizierte Data Retention Time
nicht mehr eingehalten wird. Die Daten halten dann nicht 20 Jahre,
sondern sind vielleicht schon nach zwei Jahren nicht mehr lesbar. Genau
wie bei den USB-Sticks.
Daher sollte man den Controller, auf dem man debuggt hat, auch nicht für
den späteren Dauereinsatz in der Applikation verwenden.
Peter Dannegger schrieb:> Vielleicht ein Bug in der Programmer-Firmware, irgendeine Zeit zu kurz.
Nein, kann ich garantieren. Die Zeit ist sogar inhärent.
> Wie äußert sich überhaupt das "ist das Ding hin"?
Bits die nach dem flashen eigentlich 0 sein sollten, aber 1 bleiben.
Wilhelm F. schrieb:> Jetzt traue ich mich kaum noch, mein schönes SiLabs-Board auszupacken,> und zu schauen, ob es online debuggen kann. Die Flash-Zyklen normale> Programmdownloads machen aber wohl nichts, sind auch wohl mehr als> 10.000.
Ja, bei einem gesockelten DIP-Controller für -,80 schmerzt das dann
nicht so sehr ...
Gruß
Jobst