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 dich mal bei Silabs um. Die haben Toolsticks, die sind sehr günstig.
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 Mikrocontroller Mikrocontroller Vergleich STM32 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.
:
Bearbeitet durch User
@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
Ich schmeiß hier auch noch mal meinen anderen Thread www.mikrocontroller.net/topic/320336 in den Raum. Wenn einen Chinglish nicht abschreckt...
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
Michael_ schrieb: > Die AT89C51CC03 f.f. werden sehr of eingesetzt. Wohl deshalb weil der einer der wenigen mit CAN ist, die Atmel im Programm hat.
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.
:
Bearbeitet durch User
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?
Werd mir mal das Programm von ATMEL zu Gemüte führen und nach praktikablen uC screenen.
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
Ich hoffe Du kannst Dir einen MK-II irgendwo ausleihen: http://www.reichelt.de/Programmer-Entwicklungstools/AT-JTAG-ICE2/3/index.html?&ACTION=3&LA=446&ARTICLE=45038&GROUPID=2969&artnr=AT+JTAG+ICE2&SEARCH=AT+MK ... der ist richtig teuer. Unverschämt teuer. Verdammt teuer. Schon eine Frechheit.
:
Bearbeitet durch User
Markus Müller schrieb: > Unverschämt teuer. Schon eine Frechheit das ist der JTAG ICE MK2, nicht der AVR ISP Mk2. Du vergleichst Porsche mit Dacia
Markus Müller schrieb: > Ich hoffe Du kannst Dir einen MK-II irgendwo ausleihen: > > http://www.reichelt.de/Programmer-Entwicklungstools/AT-JTAG-ICE2/3/index.html?&ACTION=3&LA=446&ARTICLE=45038&GROUPID=2969&artnr=AT+JTAG+ICE2&SEARCH=AT+MK > > ... der ist richtig teuer. Unverschämt teuer. Verdammt teuer. Schon eine > Frechheit. Das ist wohl eher was für Entwicklungsabteilungen. Da ist ja sogar ein EPROMMER wieder billig, wenn man auf Debugging verzichten kann.
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
;-) Naja, die Ideen kommen halt nicht alle auf einmal.... Kann euch aber auch nicht so schädigen...
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:
1 | set prog="C:\xasm\AVR Tools\STK500\Stk500.exe" |
2 | %prog% -cUSB -dAT89S52 -e -if%1 -pf -vf |
3 | pause
|
:
Bearbeitet durch User
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
Angehängte Dateien:
-
isp_uploader_final.gif
24 KB
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
Im angehängten zip befindet sich ein System auf AT89C51RB2 basierend ... Zum angucken oder nachbauen ... Gruß Jobst
@ 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
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.html Jobst 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 vorbeischauen LPC922 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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
greg schrieb: > Es gibt beim AVR doch nur den Programmspeicher und RAM. Plus EEPROM, das erst bei den Xmegas im Datenadressraum aufkreuzt.
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 :)
:
Bearbeitet durch User
Also, ich will OP bestimmt nicht davon abhalten, mit einem 8051er anzufangen. Aber man muss doch dazu stehen, dass die Architektur diverse Macken hat.
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.
http://www.reichelt.de/80C-87LPC-89C51-Controller/P-89LPC-922-FN/3/index.html?&ACTION=3&LA=2&ARTICLE=68345&GROUPID=2941&artnr=P+89LPC+922+FN Wenn ich die Parameter hier sehe, krieg ich richtg Lust, was damit zu machen.
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.
:
Bearbeitet durch User
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
> Wenn Du eine günstige Lösung suchst, um AT89S8253 (oder die anderen) zu > flashen, kannst Du Dich auch gerne melden. > Hast du was im petto? LG
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...?
Den Link hatte ich vergessen http://www.reichelt.de/Atmel-C51-Controller/T-89C51CC03-PLCC/3/index.html?&ACTION=3&LA=446&ARTICLE=50968&GROUPID=2960&artnr=T+89C51CC03+PLCC&SEARCH=at89+cc03 Auch wenn die anderen nur 1000x programmierbar sind, dafür sind sie billiger oder?
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
Passt. Muss dich trotzdem korrigieren. Das ist der richtige. Steht auch bei artikelnummer des Herstellers. Mit ohne c ist die reichel nr ;-)
Harald schrieb: > Den Link hatte ich vergessen > http://www.reichelt.de/Atmel-C51-Controller/T-89C51CC03-PLCC/3/index.html?&ACTION=3&LA=446&ARTICLE=50968&GROUPID=2960&artnr=T+89C51CC03+PLCC&SEARCH=at89+cc03 Huch. Wieso habe ich den denn vorhin nicht gesehen? > Auch wenn die anderen nur 1000x programmierbar sind, dafür sind sie > billiger oder? Joar. Ist nur blöd, wenn man in der Bastelphase auf einmal einen Fehler hat und diesen nicht auf Anhieb findet, weil er nicht offensichtlich ist ... 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!
Solltest Du in Zukunft aufgrund benötigter Features einen Chip auswählen, der SMD sein sollte, kannst Du Dir ja dies noch ansehen: http://www.mikrocontroller.net/attachment/153522/uSOIC_MAX9611_01.jpg http://www.mikrocontroller.net/attachment/154830/ic1.jpg http://www.spaceflakes.de/2087/steckbrettadapter-fuer-smd-ics/ Gruß Jobst
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.
Den AT89C51CC03 mit CAN Bootlader kannst Du mit einem P-CAN Dongle bespielen, habe ich auch schon mal gemacht.
Jobst M. schrieb: > Solltest Du in Zukunft aufgrund benötigter Features einen Chip > auswählen, der SMD sein sollte, kannst Du Dir ja dies noch ansehen: > > http://www.mikrocontroller.net/attachment/153522/uSOIC_MAX9611_01.jpg > http://www.mikrocontroller.net/attachment/154830/ic1.jpg > > http://www.spaceflakes.de/2087/steckbrettadapter-fuer-smd-ics/ > vor allem letzteres find ich sehr geil ;-)
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.
Was heisst solche Fragen? Die Frage war doch sehr konkret formuliert... Oder wozu ist ein Forum da?
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.
Da hast du recht. Und im Grunde ist das Signal/Rausch-Verhältnis hier ja ganu gut.
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.
Das Flash kriegt man recht fix verbrannt, wenn man einen Debugger verwendet, der für Breakpoints den Code im Flash modifiziert.
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
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.