Eine Frage an alle schlauen Köpfe in diesem Forum... Ich habe ein Problem beim Einsatz des o.g. MC. Normalerweise habe ich immer den 51RC benutzt, aber Aufgrund von Portmangel habe ich mich diesmal für den ED2 entschieden. Nur der läuft nicht mit externem ROM und RAM. Ersetze ich den mit dem RC2 auf einem Adapter, dann funktioniert alles. Gibt es in den Registern vom ED2 was man umstellen muß, was ich eventuell übersehen habe? Ich suche nun schon seit knapp zwei Wochen an dem Fehler. Vielleicht kann mir jemand einen Tip geben. Grüße in die Runde
Stefan schrieb: > Gibt es in den Registern vom ED2 was man umstellen muß, was ich > eventuell übersehen habe? Security Level programmiert? Lösch mal die Fuses. Es wäre sinnvoll, mal die richtige Bezeichnung der Chips zu posten, also z.B. AT89C51RD2 bzw. AT89C51ED2.
Matthias S. schrieb: > Security Level programmiert? Oh, da muß ich warscheinlich noch mal schauen. Im Programm selbst habe ich nichts dergleichen gemacht.
Da komm ich warscheinlich nur über ISP-Programmer ran. Ich habe hier nur enen EPROM-Simulator. Damit habe ich nur Zugriff auf das AUXR- und AUXR1-Register. Somit nur auf ENBOOT und EXTRAM, die ich im Programm schon berücksichtigt habe. Etwas Anderes finde ich hier nicht.
Stefan schrieb: > Nur der läuft nicht mit externem ROM und RAM. Doch, mit dem EA-Pin kannst Du den internen Flash komplett abschalten. Nur wozu? Dann gehen doch wieder 18 Portpins verloren.
Das EA-Pin liegt auf GND. Ja, es stimmt das hier 2 Ports verloren gehen und in der Endversion wird das Prgramm auch im internen Speicher landen. Nur zum Testen ist das nicht sehr praktisch. Dauert lange wenn man ca 50k jedesmal über ISP schicken will. Beim EPROMMER dauert es keine 2 Sekunden.
Stefan schrieb: > Dauert lange wenn man ca 50k jedesmal über ISP schicken will. > Beim EPROMMER dauert es keine 2 Sekunden Um und die Zeit zu verkürzen hast du nun 2 Wochen Arbeit investiert und es ist noch kein Ende in Sicht ? Weniger oft testen, mehr richtigen code schreiben.
Tja, wie das manchmal so ist. Mich macht das aber ein wenig verrückt, wenn man keinen Fehler erkennt und das was man will, trotzdem nicht funktioniert... Naja, wie es aussieht werde ich da meinen Plan wohl ändern und das Layout noch mal überarbeiten und gleich altbewährte Technik verwenden. Bischen größer, aber funktioniert immer.. ;)
MaWin schrieb: > Weniger oft testen, mehr richtigen code schreiben. ....ist schwierig wenn es um Grafik geht. Man weiß erst ob es einem gefällt wenn es auf dem TFT angezeigt wird.
Hallo Stefan, Ich habe mich vor rund 10 Jahren auch mit denselben uC beschäftigt. Als Programmiergerät verwendete ich den von ASIX. Mich würde interessieren ob und wie gut bei Dir der ADC funktioniert. Obwohl ich alles Übrige zufriedenstellend unter uV2 zum Laufen bringen konnte, hatte ich mit dem ADC andauernd Probleme. Der wollte trotz Codebeispiele nicht funktionieren und produzierte nur Extremwerte. Könntest Du mir Deine Erfahrungen diesbezüglich mitteilen? Gruß, Gerhard
Gerhard O. schrieb: > Mich würde interessieren ob und wie gut bei Dir der ADC funktioniert. M.M.n. hat sich Atmel mit den Spin-Offs der MCS51 Familie nicht wirklich mit Ruhm bekleckert. Ich erinnere mal an den AT89S253, dessen EEPROM vor Errata gestrotzt hat. Ich könnte mir ähnliches bei dem AT89C51RD2/ED2 auch vorstellen, habe aber keine Erfahrung mit dem Chip.
Gerhard O. schrieb: > Mich würde interessieren ob und wie gut bei Dir der ADC funktioniert. Tja, dazu müßte ich das Ding erst einmal zum Laufen bringen. Momentan kann ich dazu nichts sagen. Ist ja auch das erste Mal , das ich den MC einsetzen will. Sonst habe ich immer mit dem AT89s51 oder dem AT89c51RC gearbeitet.
Matthias S. schrieb: > Gerhard O. schrieb: >> Mich würde interessieren ob und wie gut bei Dir der ADC funktioniert. > > M.M.n. hat sich Atmel mit den Spin-Offs der MCS51 Familie nicht wirklich > mit Ruhm bekleckert. Ich erinnere mal an den AT89S253, dessen EEPROM vor > Errata gestrotzt hat. Ich könnte mir ähnliches bei dem AT89C51RD2/ED2 > auch vorstellen, habe aber keine Erfahrung mit dem Chip. So weit ich mich erinnern kann stand nichts in den Errata was den ADC betrifft. Normalerweise sitzt das Problem eher vor dem Monitor. Aber hier biss ich mir tatsächlich die Zähne aus. War nichts zu machen. Aber ich bin auch der Meinung, daß diese Serie unter "Ferner liefen" gehört. Im Augenblick setze ich auf den AVR128DB als Hobby 8-bit Flagschiff. Die Curiosity Bords mit dem DB sind ja gerade wegen der UPDI Debug Schnittstelle auch recht interessant. Hoffe, daß der einigermaßen hält was versprochen wird. Mit den größeren PICs hatte ich auch nie irgendwelche bemerkenswerte Probleme in Firmenanwendungen. Für kleinere Sachen funktionieren ja auch die 328er recht zufriedenstellend und kommen in der Form von Nano und Pro-Mini fertig montiert.
Matthias S. schrieb: > M.M.n. hat sich Atmel mit den Spin-Offs der MCS51 Familie nicht wirklich > mit Ruhm bekleckert. Mir ist da nichts aufgefallen. Wir haben den AT89C51CC03 eingesetzt. ADC und EEPROM funktionieren einwandfrei. Nur das I2C hat Atmel nicht hingekriegt. Multimaster funktioniert weder bei den 8051, noch bei den AVRs.
Stefan schrieb: > Nur der läuft nicht mit externem ROM und RAM. Sollte lt. Dabla aber: External Access Enable: /EA must be externally held low to enable the device to fetch code from external program memory locations 0000H to FFFFH. If security level 1 is programmed, /EA will be internally latched on Reset. Ganz vorne steht aber auch: • High-speed Architecture – In Standard Mode: • 40 MHz (Vcc 2.7V to 5.5V, both Internal and external code execution) • 60 MHz (Vcc 4.5V to 5.5V and Internal Code execution only) – In X2 mode (6 Clocks/machine cycle) • 20 MHz (Vcc 2.7V to 5.5V, both Internal and external code execution) • 30 MHz (Vcc 4.5V to 5.5V and Internal Code execution only) Gruß Jobst
24.3.3 Default Values The default value of the HSB provides parts ready to be programmed with ISP: • [...] • LB2-0: Security level four to protect the code from a parallel access with maximum security. Security Level LB0 LB1 LB2 Protection Description 4 X X P Same as 3, also external execution is disabled (Default). Na, da hammwas! Default: Verfused. Gruß Jobst
:
Bearbeitet durch User
Jobst M. schrieb: > Default: Verfused. Und war es das? Stefan schrieb: > Dauert lange wenn man ca 50k jedesmal über ISP schicken will. > Beim EPROMMER dauert es keine 2 Sekunden. Hängt von der Taktrate des ISP ab. Eproms rauspöpeln, löschen, beschreiben, Pins geradebiegen und wieder in die Fassung würgen + Software von Int. auf ext Speicher und wieder zurück umschreiben + jeweiliger Fehlersuche kostet keine Zeit? Verwendest Du keinen Debugger? Da solltest Du doch relativ schnell rausfinden woran es hakt und musst nicht laufend nach Prinzip Hoffnung den Code umschreiben.
ich habe den ED2 immer mit Atmel Flip "in circuit" programmiert. Das ging in ca. 30s durch. Verstehe also nicht den großen Zeitaufwand.
Max M. schrieb: > Eproms rauspöpeln, löschen, beschreiben, Pins geradebiegen und wieder in > die Fassung würgen + Software von Int. auf ext Speicher und wieder > zurück umschreiben + jeweiliger Fehlersuche kostet keine Zeit? Entschuldigung , war mein Fehler. Ich meinte natürlich einen Epromsimulator..
Jobst M. schrieb: > Na, da hammwas! > > Default: Verfused. ..und an die Dinger komme ich nur über ISP ran?
Ich habe gerade selber noch mal die Stelle im Datenblatt nachgeschaut. Du hast Recht. Ich war der Meinung das die 8051 iger immer abwärtskompatibel seien und mit EA = GND die internen Speicher abgeschaltet sind. Dachte ich mir schon das das an irgend so einer kleinen Sache liegen muß. Danke an die Runde und insbesondere an Jobst! Aber mal noch eine andere Frage... Max spricht hier von einem Debugger. Ich benutze, wenn überhaupt, den der in Turbo51 enthalten ist. Ist nicht sehr hilfreich aber ab und zu doch notwendig. Gibt es da was Passendes das gut funktioniert? Ich programmiere schon seit 20 Jahren mit Turbo51.
am komfortabelsten ist der Keil C- Compiler der kann sogar sehr schön simulieren, aber hat auch gute Optionen zum Debuggen. Bis 1k Code (oder 2k?) kostenlos nutzbar.
Schade, ist leider C. Da müßte ich von vorn anfangen und ich hab noch nie was mit C gemacht.
Stefan schrieb: > Max spricht hier von einem Debugger. Ich benutze, wenn überhaupt, den > der in Turbo51 enthalten ist. Ist nicht sehr hilfreich aber ab und zu > doch notwendig. > Gibt es da was Passendes das gut funktioniert? Ich programmiere schon > seit 20 Jahren mit Turbo51. Die '51er hab ich zum Schluß mit dem Hitex MX51 ICE debugged. So vor 10-20 Jahren war das. Davor auch mit dem Intel ICE5100. Bei diesen alten Cores war es übliche ein extra ICE zu haben. Da Turbo51 auch OMF erzeugt sollte das mit solchen ICEs funktionieren. Nur wenn du die Erweiterungen der aufgebohrten '51er benutzt, könnte es problematisch werden. Keine Ahnung wie weit die von Hitex unterstützt werden. Aber zuerst müsstes so ein altes Teil mal haben. Ev. bietet jemand sowas an bevor er es in die Tonne schmeißt. Übrigens, auch der EPROM Simulator (Promlogic?) war damals sehr hilfreich. Aber heutzutage nehm' ich da doch lieber einen Cortex-MX mit 'nen Segger J-Link. Das ist eine ganz andere Welt.
Andi B. schrieb: > Übrigens, auch der EPROM Simulator (Promlogic?) Ich verwende hier den EEROM-8U. Der läuft tadellos. Ist auch kaskadierbar, wenn man mal 2 oder mehr EPROMS braucht.
Stefan schrieb: > Ich programmiere schon > seit 20 Jahren mit Turbo51. Sorry, ich lag falsch. Der AT89c51ED2 ist so steinalt, das der garkein debug Interface bietet. Das Killerfeature ist der ONCE Modus, bei dem ein externer Debugger die Kontrolle übernehmen kann. Der ist so groß wie eine Stereoanlage in den 80ern. Habe ich vor vielen Jahren entsorgt, weil sich selbst auf Ebay kein Käufer fand. Uralte MCU mit uralter IDE (letztes Release 2013) mit annähernd ausgestorbener Programmiersprache und ausgestorbener Eprom Technik. Aber immer noch in Produktion und schon für 10€/Stk zu haben 😣 Das ist alles Nostalgie in Reinstform. Selbst ein 30cent stm8 bietet in allen Belangen mehr. Mach einfach so wie Du immer gemacht hast. Hat für Dich vorher funktioniert und für alles was heute das Leben so angenehm mit MCUs macht, müsstest Du wohl einmal alles in die Tonne kloppen und neu anfangen mit allem.
Max M. schrieb: > Aber immer noch in Produktion Das liegt daran, dass MCS51 neben ARM die am weitesten verbreitete Plattform ist. > Das ist alles Nostalgie in Reinstform. Quark! Gruß Jobst
Jobst M. schrieb: > Security > Level LB0 LB1 LB2 Protection Description > 4 X X P Same as 3, also external execution is disabled > (Default). > > Na, da hammwas! > > Default: Verfused. Nö, man kann nur nicht auf beides gleichzeitig zugreifen. "EA is sampled and latched on reset" Das meint, mit /EA = low ist nach einem Reset der interne Flash abgeschaltet und Programm und Daten können nur vom externen Speicher gelesen werden. Der AT89C51ED2 ist dann quasi ein 80C31. Du kannst aber auch den AT89LP51ED2 benutzen. Der kann die oberen 32k auf externen Codespeicher umschalten. Die LP-Serie kann per Fusebit auf den Fast-Mode umgeschaltet werden. Ein "MUL AB" dauert dann statt 24 Quarztakten nur 2 Quarztakte. Zusätzlich haben sie eine Multiply–Accumulate Unit (16Bit Mul).
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.