Aus RN-Wissen.de
| (2 dazwischenliegende Versionen von 2 Benutzern werden nicht angezeigt) | |||
| Zeile 1: | Zeile 1: | ||
| − | Du solltest deutlicher herausstellen bei welchen AVRs dieser Fehler bekannt ist. Ist es vielleicht nur ein bestimmter Typ? Gut wäre auch eine Quellenangabe für diese Bugbeschreibung. | + | Du solltest deutlicher herausstellen bei welchen AVRs dieser Fehler bekannt ist. Ist es vielleicht nur ein bestimmter Typ? Gut wäre auch eine Quellenangabe für diese Bugbeschreibung. --[[Benutzer:Frank|Frank]] 17:26, 9. Jan 2006 (CET) |
| − | --[[Benutzer: | + | :Es ist gedacht, um bei Problemen mal kurz zu überfliegen und vielleicht ein Aha-Erlebnis zu haben, und sich nicht z.B. im eigenen Programm den Wolf zu suchen, weil EEPROM 0 nicht geht. Oder beim Programmieren sich erinnern "da war doch was...". Falls wer detailiertere Angaben will, findet man die wie gesagt im Manual. Jeder kann ja zu dieser Seite beitragen oder alle Datenblätter aller Revisions an AVRs runterladen, durchgehen und sich eingeladen fühlen, an dieser Seite mitzuwirken. --[[Benutzer:SprinterSB|SprinterSB]] 17:35, 9. Jan 2006 (CET) |
| − | : | + | ::Ja ich find das ja auch schon ganz hilfreich. Nur könnte der Eindruck erweckt werden das dies bei sehr vielen Avr´s ein Problem mit dem EEPROM Byte gibt. Da ich aber sowas noch nie feststellen konnte, geh ich mal von aus das es nur ein bestimmter Typ ist wo das auftritt. Wäre natürlich sinnvoll wenn das dann auch dabei stehen würde, damit keine falschen Gerüchte aufkommen. Auch in deinem Intresse, als Autor wäre das hier sicher besser. --[[Benutzer:Frank|Frank]] 20:16, 9. Jan 2006 (CET) |
| − | + | ||
| + | :::Es geht doch nicht darum, irgendwelche Gerüchte zu streuen oder AVR mies zu machen. Im Vergleich zu anderen Architekturen ist AVR praktisch fehlerfrei. | ||
| + | |||
| + | :::Falls es holpert, dann ist das nicht nur für ein spezielles Derivat zu erwarten, denn für verschiedene Derivate wird wohl das gleiche VHDL oder Verilog oder was auch immer verwendet, und nicht komplettes Neudesign gemacht. Abhängigkeiten sind eher von den physikalischen Randbedingungen zu erwarten wie: Betriebsspannung, Temperatur, Taktrate, Einstrahlungen, aktivierte Komponenten, evtl. max. Betriebsspannung/Taktrate, Revision (keine Ahnung wie man die rausbekommt, am Aufdruck jedenfalls nicht, und ein SFR mit einer ID gibt's AFAIK auch nicht — oder es ist nicht vom Hersteller dokumentiert. Und die Revision-Numerierung muss auch nicht parallel laufen). | ||
| + | |||
| + | :::Errata-Sheets konnte ich beim Hersteller bislang nicht finden. Speziell mit EEPROM hatte ich selbst schon mal Probleme und hab dann darauf verzichtet (was bei der Applikation möglich war). Mir war damals nicht bekannt, daß es Probleme geben kann, und ein Workaround hab ich nicht ausprobiert, aber eben auch nicht gerafft, warum's manchmal nicht geht. In einem Forum hab ich's dann später gelesen, daß speziell Adresse 0 Ärger macht. Möglicherweise ist es auch nicht Adresse 0, sondern die erste Zelle, die man beschreibt oder nur, wenn das direkt nach dem Start erfolgt, weil intern erzeugte Spannungen noch nicht voll da sind. | ||
| + | |||
| + | :::So einfach ist das leider nicht mit Beschreibung von Hard-Bugs, weil auch die Hersteller es nicht immer wissen und ganz viele Faktoren das beeinflussen können und nicht alles am VHDL nachvollziebar ist. | ||
| + | |||
| + | :::--[[Benutzer:SprinterSB|SprinterSB]] 13:33, 10. Jan 2006 (CET) | ||
Aktuelle Version vom 10. Januar 2006, 13:33 Uhr
Du solltest deutlicher herausstellen bei welchen AVRs dieser Fehler bekannt ist. Ist es vielleicht nur ein bestimmter Typ? Gut wäre auch eine Quellenangabe für diese Bugbeschreibung. --Frank 17:26, 9. Jan 2006 (CET)
- Es ist gedacht, um bei Problemen mal kurz zu überfliegen und vielleicht ein Aha-Erlebnis zu haben, und sich nicht z.B. im eigenen Programm den Wolf zu suchen, weil EEPROM 0 nicht geht. Oder beim Programmieren sich erinnern "da war doch was...". Falls wer detailiertere Angaben will, findet man die wie gesagt im Manual. Jeder kann ja zu dieser Seite beitragen oder alle Datenblätter aller Revisions an AVRs runterladen, durchgehen und sich eingeladen fühlen, an dieser Seite mitzuwirken. --SprinterSB 17:35, 9. Jan 2006 (CET)
- Ja ich find das ja auch schon ganz hilfreich. Nur könnte der Eindruck erweckt werden das dies bei sehr vielen Avr´s ein Problem mit dem EEPROM Byte gibt. Da ich aber sowas noch nie feststellen konnte, geh ich mal von aus das es nur ein bestimmter Typ ist wo das auftritt. Wäre natürlich sinnvoll wenn das dann auch dabei stehen würde, damit keine falschen Gerüchte aufkommen. Auch in deinem Intresse, als Autor wäre das hier sicher besser. --Frank 20:16, 9. Jan 2006 (CET)
- Es geht doch nicht darum, irgendwelche Gerüchte zu streuen oder AVR mies zu machen. Im Vergleich zu anderen Architekturen ist AVR praktisch fehlerfrei.
- Falls es holpert, dann ist das nicht nur für ein spezielles Derivat zu erwarten, denn für verschiedene Derivate wird wohl das gleiche VHDL oder Verilog oder was auch immer verwendet, und nicht komplettes Neudesign gemacht. Abhängigkeiten sind eher von den physikalischen Randbedingungen zu erwarten wie: Betriebsspannung, Temperatur, Taktrate, Einstrahlungen, aktivierte Komponenten, evtl. max. Betriebsspannung/Taktrate, Revision (keine Ahnung wie man die rausbekommt, am Aufdruck jedenfalls nicht, und ein SFR mit einer ID gibt's AFAIK auch nicht — oder es ist nicht vom Hersteller dokumentiert. Und die Revision-Numerierung muss auch nicht parallel laufen).
- Errata-Sheets konnte ich beim Hersteller bislang nicht finden. Speziell mit EEPROM hatte ich selbst schon mal Probleme und hab dann darauf verzichtet (was bei der Applikation möglich war). Mir war damals nicht bekannt, daß es Probleme geben kann, und ein Workaround hab ich nicht ausprobiert, aber eben auch nicht gerafft, warum's manchmal nicht geht. In einem Forum hab ich's dann später gelesen, daß speziell Adresse 0 Ärger macht. Möglicherweise ist es auch nicht Adresse 0, sondern die erste Zelle, die man beschreibt oder nur, wenn das direkt nach dem Start erfolgt, weil intern erzeugte Spannungen noch nicht voll da sind.
- So einfach ist das leider nicht mit Beschreibung von Hard-Bugs, weil auch die Hersteller es nicht immer wissen und ganz viele Faktoren das beeinflussen können und nicht alles am VHDL nachvollziebar ist.
- --SprinterSB 13:33, 10. Jan 2006 (CET)
