Lockbit im ATtiny überbrennen?

DS lesen, chip erase durchführen, dann sind auch die lock bits zurückgesetzt.

Zitat

Original von Zeon
...
hab mich nach ewiger drückerei vor der digitaltechnik nun dorch mal entschlossen ein wenig mit AVR's zu experimentieren...

Für alles was über eine einmalige kurzfristige Aktion hinausgeht, ist Atmel eine schlechte Wahl. Und der IAR Compiler dazu punkto Qualität kaum mehr zu unterbieten. Außer vielleicht noch vom alten '51 IAR.

Also wenn man schon einsteigt, dann sollte die Wahl auf vernünftigere Firmen/Prozessorfamilien fallen.

Auf die Begründung bin ich gespannt. Was ist denn vernünftig? PIC? Dann können wir die Diskussion gleich lassen, Grabenschlachten helfen niemandem.
Nur so viel: ich habe schon Programme für PIC anpassen müssen, die Informatik-Ingenieure mit angeblich jahrelanger Embedded-Erfahrung auf teuren Profi-IDEs erstellt haben. Die Codequalität und -sicherheit bekomme ich mit kostenloser Software und AVR allemal hin, bei wahrscheinlich kürzerer Entwicklungszeit.
Im übrigen vermisse ich neben einer Begründung in Deiner Antwort die Frage nach der Anwendung. Um einen einfachen Zeitschalter zu realisieren braucht man u.U. eine andere uC-Familie als für eine Prozesssteuerung mit Grafikausgabe, Realtime-OS, CAN und LAN...

Die AVRs sind zwar nicht sehr leistungsstark, dafür aber als 5V Versionen erhältlich und recht leicht zu programmieren.

Die IAR Embedded Workbench ist derzeit der mit Abstand beste Compiler für die AVR Familie. Ein ehemaliger Kollege (der die GCC AVR Library mitentwickelt hat prüfte hierzu komplexe Programme mit mehreren Compilern (GCC, IAR, CodeVision...). Im Ergebnis war die Codedichte des IAR um ca. 30% höher als die des GCC, der der zweitbeste Compiler war. Ähnlich sieht es mit den Laufzeiten aus. Der Codevision Copiler ist dagegen sehr ineffizient, da aber Speicher und Rechenleistung recht billig sind, kann man kleine bis mittlere Projekte dennoch schön mit dem Codevision zusammenkleistern. Heizungssteuerung fertiggestellt in 10 Stunden usw.

Bei den AVRs sind die Fusebits invertiert. Ich würde das STK500 kaufen und mit dem AVR Studio versuchen, die Funktion Chip Erase zu starten.

Die Lock-Bits kann man ganz leicht mit dem STK500 per HV-Programmierung löschen. Einen STK500 bekommt man heute schon unter 100€ mit Treiber-CD, Kabel, etc. Ausserdem vertragen sie sich mit fast allen USB<->RS232-Wandlern die man am Markt bekommt.

> Auf die Begründung bin ich gespannt...

Weil Atmel Prozessoren ziemlich schnell abkündigt und deshalb für Dinge die über Jahre produziert oder gewartet werden müssen nicht brauchbar ist. Deren Datenblätter haben noch immer 'Preliminary' Status und den Bautteil gibt's schon gar nicht mehr. Auch weil die Nachfolgetypen, laut Atmel eh kompatibel zumindest im Compatibility Mode, in Wahrheit aber nicht kompatibel sind. Nur 2 Beispiele gefällig mit denen ich mich rumschlagen mußte - doppelt so lange Schreibzeit für's EEPROM, geänderte Eingangsspannungspegel..... Und das neben den Dingen die in den Atmel App Notes als Differenz angeführt sind. Darum habe ich ja geschrieben -

>Für alles was über eine einmalige kurzfristige Aktion hinausgeht, ist Atmel eine schlechte Wahl.....

Und weil wir gerade wieder einen halben Tage verplempert haben (nicht zum ersten Male) nur um die richtige Kombination von Optimierungseinstellungen zu finden wo der IAR nicht Code einfach wegoptimiert obwohl notwendig und somit die SW wieder so tut wie sie programmiert wurde. Warum die IDE diese Einstellungen nicht gespeichert bzw. überschrieben hat, das ganze Projekt ist vor Jahren eingechecked worden, ist noch immer unerklärlich. Aber das Hautproblem ist, der IAR meint er müsse Teile einfach weglassen. Drum -

> Und der IAR Compiler dazu punkto Qualität kaum mehr zu unterbieten.

Und weil ich vom alten '51 IAR durch einfaches Vergleichen des Codes weiß, daß er miesen Code erzeugte. Deshalb -

> Außer vielleicht noch vom alten '51 IAR.

Und weil der IAR ARM Compiler nicht nur langsam, manchmal sogar exterm langsam (und da spreche ich vom Faktor >100) ist, und manchmal aus einer Codezeile 20k Code macht nur weil er die ? in den #defines der CMSIS nicht geschnallt bekommt. Aber der Cortex-M3 ist jetzt wieder ein anderes Thema. Nur zum illustrieren, daß IAR in verschiedensten Bereichen schlampt.

Ok, das klingt bedacht. Ich kann diese Erfahrung gerade nicht teilen, ein kleines Interface von 1999 mit einem 90S2313 lebt mit Tiny2313 zehn Jahre später erneut auf, aber die letztlich notwendigen Anpassungen hängen natürlich auch vom Code ab.
Welche Alternative hast Du anzubieten? PIC? Die, wo ständig ein Neuer dazu kommt, dem wieder eine Kleinigkeit fehlt, um für die jeweilige Aufgabe geeignet zu sein?

Zitat von shaun

PIC? Die, wo ständig ein Neuer dazu kommt, dem wieder eine Kleinigkeit fehlt, um für die jeweilige Aufgabe geeignet zu sein?

Weil du es erwähnst - ja die bauen soviele neue Typen daß nicht mal mehr ihre App Engineers da durchblicken Andererseits hat Microchip praktisch noch nie einen Prozessor abgekündigt. Du kannst heute noch den Prozessor kaufen den sie vor 20 Jahren auf den Markt gebracht haben. Und zwar in der Maskenversion wie du den ursprünglich freigegeben hast. Nicht irgend einen neueren vielleicht kompatiblen Nachfolger...

Bez. Kleinigkeit fehlt - bei einem 24FJxxxGx fehlt für kleine Steuerungen eigentlich nichts (außer DMA der dann bei den HJ dabei ist, allerdings dann wieder mit schwächeren Ausgangstreibern :(. Die Architektur ist allerdings ziemlich verkorkst und hat deshalb wahrscheinlich keine große Zukunft. Aber das ist eine andere Geschichte. Nicht das ich meine ein PIC wäre soviel besser als ein Atmel, aber man kann den Chip mit dem man vor 10 Jahren mal was baute auch heute noch kaufen und das Geräte reparieren/erweitern/duplizieren. Man ist nicht gezwungen wegen eines abgekündigten Prozessors umzudesignen/umzulernen.

Wenn man allerdings was größeres machen will, kommt man heutzutage um die ARM Familie kaum rum. Nachdem nun sogar Freescale auf Cortex-M4 aufgesprungen ist, ist der ARM Zug nicht mehr aufzuhalten. Wenn man die Historie von Motorola kennt, erhält diese Richtungsentscheidung eine besondere Bedeutung. Natürlich kann man einwenden, 32 Bit ist doch für vieles überdimensioniert. Aber da es schon Cortex-M3 um unter 1$ im 32 Pin QFN Gehäuse und mit ca. 200uA/MHz gibt, wird's für 8 und 16 Bitter in Zukunft schon ziemlich eng werden. Warum soll ich mich da mit den kleinen Würmer und Beschränkungen an jeder Ecke rumschlagen, wenn ich es doch mit dem Standard JTAG Adapter und massenweise IDEs viel eleganter lösen kann? Klar bleiben die Nischen für die ganz Kleinen. Aber will der Hobbybastler wirklich für jede Aufgabe einen anderen Prozessor/Debugger/Programmer/IDE? Oder ist nicht gerade für diesen eine gewisse Kontinuität notwendig? Genau diese bietet gerade Atmel nicht was auch der Grund ist, warum ich diese Firma nicht mag.