Hi, weiß jemand, wie oft man die Fusebits programmieren kann? Sind die als Flash (10000 mal) oder als EEPROM (100000 mal) implementiert? Danke
Wie oft willst Du die Fuses umprogrammieren? Alleine für 10000 mal brauchst Du Jahre und nach 20 mal umprogrammieren sollte man das für sich richtige mit den Fuses eingestellt haben wo bei man meist nur den Takt, Taktquelle und evtl. noch die Bootsize einstellt. Gruß Andi
Ich glaube mich entfernt zu erinnern, dass die Fuses FLASH sind... Mangels Beweis allerdings ohne Garantie ;) Die Frage bleibt, warum du die Fuses zehntausend mal umstellen willst.
Das Frage lässt sich leicht leicht beantworten. Ich entwerfe gerade einen Programmer für PIC/AVR controller. Und bei den ATmega ist es nun mal so, dass die Programmier/Lesegeschwindigkeit im Verhältnis zum Takt steht. Programmingclock >= 2x oder 3x CPU clock. Da der Controller interne 8MHz hat, wäre is durchaus interessant vor jedem SW-Update auf intern 8MHz umzustellen und nach der Programmierung zurück auf die vom User gewünschte Taktzahl. Habe gerade mal einige Zeitmessungen mit einem ATmega64 (64kBytes Flash)gemacht. Verify-Zeit bei 1MHz ca. 9s Verify-Zeit bei 8Mhz ca. 2s Und gerade wenn man selber programmiert und sein Programm öfter mal update will (z.B. beim Debuggen), wären da pro Update bestimmt 15s Zeitersparnis drin, die die Nerven des Programmieres schonen. Wenn man mal einen Tag lang programmiert und seine SW so 100mal und öfter zum Prozessor hochläd, hat man bestimmt eine halbe Stunde Freizeit gewonnen. Vielleicht auch mehr. So leicht kann die Antwort sein :-) Die andere Alternative wäre, man Taktet seinen Prozessor immer mit min. 8MHz und braucht die Fuses dann nicht umzustellen. Ansonsten wären es zwei updates pro Programmierung (intern 8MHz und dann das gewählte). Bernd
Ok, ok :) Diese zehn Sekunden kannst du aber auch bequem dazu benutzen mal die Augen auszuruhen oder den Rücken zu entspannen g Naja, bei 100 Updates pro Tag kommt man immernoch auf 100 (Arbeits)Tage, also ein halbes Jahr. Vielleicht stirbt der µC dann ohnehin ob irgendeines anderen "Unfalls".
Wenn Du jedes mal den Clock vor und nach dem Proggen umstellen willst gehen dafür die 7 Sekunden auch drauf. Genau genommen sparst Du Dir im Höchstfall bei 100 mal proggen 11,67 Minuten wenn das Umstellen der Fuses vor und nach dem Proggen automatisch mit umgestellt wird wobei das bestimmt auch ne Sekunde dauert. Allerdings konnte ich das mit Pony-Prog und nen Mega8515 nicht nachvollziehen. Bei 1MHz sowohl auch bei 8MHz war die Zeit zum Proggen und Verify identisch. Möglich, dass das mit nen STK500 anders ist. Keine Ahnung, mit was Du proggst aber vielleicht solltest Du Dir vor jedem proggen Deine Erweiterungen genauer durchdenken und kontrollieren um die Anzahl der Updates zu verringern. Durch ein genaueres Durchdenken des Programmes im Vorfeld kann man auch schneller zum Ziel kommen. Gruß Andi
"Wenn man mal einen Tag lang programmiert und seine SW so 100mal und öfter zum Prozessor hochläd,..." Vielleicht sollte man da eher mal grundsätzlich über die Herangehensweise an die Programmierung nachdenken. Die Programmierung scheint heute fast ausschließlich nach dem "Versuch/Fehler"-Prinzip abzulaufen. Mal eben zwei Zeilen ändern und gucken was passiert. Länger über ein Problem nachdenken, Entwerfen und dann Umsetzen scheint aus der Mode gekommen zu sein. Zu meinen Zeiten am Großrechner wäre das undenkbar gewesen. Mal eben alle Karten neu ablochen und dem Operator und die Hand drücken, der hätte mir eine Vodel gezeigt :-) Gruß Ingo
So ganz kann ich mich dem Argument von Ingo nicht verschließen... Aber: Wenn ich etwas neues ausprobiere, z.B. irgendeinen exotischen Timermodus, dann gehe ich auch gerne nach diesem Modell vor. Zwar mache ich mir auch zuerst Gedanken, was das Programm eigentlich machen soll, aber manchmal gehts halt einfacher mit der try 'n error Methode. Bei komplizierteren Geschichten habe ich den Simulator sehr schätzen gelernt. Leider kann er z.B. die TWI-Schnittstelle nicht simulieren... Aber mal im ernst: Wer flasht seinen Controller 100x pro Tag? Und selbst wenn, dann hat der Controller nach dieser Frist die 3 Euro verdient, die er gekostet hat.
War ja auch nur ein extrem Beispiel. Wenn man davon ausgeht, dass von den 64k warscheinlich nur 1-8k real genutzt werden, dann geht es sowieso schneller. @Andi: Das umsetzen der Fuse dauert ca. 10ms. Was die Programmiergeschwindingkeit angeht, bedeutet 8MHz Clock nicht automatisch, dass es schneller geht. Es bedeutet nur, dass der Controller die Daten schneller aufnehmen kann, ausgeben kann. Wenn der Programmer es nicht unterstützt, hat es keine Bedeutung. @Ingo: Wenn immer möglich verwende ich auch den Simulator, aber es gibt eine Vielzahl von Anwendungen, wo ein Debuggen im Simulator quasi unmöglich ist und da macht es schon Sinn. Wozu gibt es sonst In-Circuit-Debugger? Wenn dann auch noch externe Komponenten im Spiel sind, die dem Controller das Timing vorgeben, bleibt nur die Echtzeitausführung in Verbindung mit Trace Messages um Fehler zu suchen. Und wenn man keinen ICD besitzt, bleibt nur die Möglichkeit den Programmfluss irgendwo zu stoppen und zu schauen, wie weit alles nach Plan gelaufen ist. Wenn alles OK war, lässt man das Programm beim nächsten Start ein Stückchen weiter laufen. Hier ist aber ohne ICD jedesmal eine Neuprogrammierung für erforderlich. An alle: Kann mir jemand sagen, wie lange PonyProg zur Programmierung/Verifizierung eines ATMega mit 8, 16, 32, 64k braucht? Was ist die niedrigste Taktung des ATMega, bei der PonyProg noch funktioniert? Und was macht Ihr, wenn als Clocksource der Low-Frequency Oszillator angewäht wurde? Auch hier gilt, 1 Programmingcycle = 2 Oszillatorcycls. Ich glaube bei einem 32kHz Oszillator könnte man da getrost in den Urlaub fahren. Hier ist man immer gezwungen, die Clock umzustellen. Gruß, Bernd
Hallo Bernd! Ich finde die Idee mit den Fuses umstellen nicht schlecht, aber dennoch für sehr umständlich. Man muss bedenken, dass jeder Prozessor andere Fuses besitzt. Manche Prozessoren haben gar keine Fuses. Oder der ATmega48V/88V/168V kann nur im Bereich von 0 - 6MHZ betrieben werden. Wenn du mit deinem Programm sowieso nicht alle Prozessoren abdecken möchtest kann man das ruhig so machen. Aber wenn ich mir deine Erzählung durchlese, sehe ich, dass du auch Pics programmieren möchtest, was mir zeigt, dass du ein Interesse daran hast, möglichst viele Prozessoren abzudecken. Mein Ratschlag: Entwerfe dein Programm so, dass du die Geschwindigkeit in MHZ für den Zielprozessors angeben kannst. Danach wird die höchstmögliche SPI-Geschwindigkeit laut Datenblatt berechnet, die übrigens auch wieder von Prozessor zu Prozessor schwanken kann (Beispiel AT90S1200 benötigt wieder eine andere SPI-Geschwindigkeit). Ich habe auch ein paar Fragen: 2 Sekunden Verifizierung (ATMEGA64) sind für ein Programmiergerät ungeheuer schnell. Liest du bei der Verifizierung den gesamten Flash-Speicher aus? Aus Welcher Hardware besteht dein neues Programiergerät? Welcher µC? Welche Programmierprache bzw. Compiler wird für die PC-Plattform verwendet? Welches Protokoll verwendest du für die Übertragung an das Programmiergerät für die AVRs? Ich würde mich sehr freuen, wenn du uns Näheres darüber berichtest. Danke Tschüss Martin
Hi 2s sind nicht weiter exotisch. Bei entsprechendem SPI-Takt und schneller PC Übertragung ist das keine Thema. Matthias
Ja schon. Aber das Programmiergerät enthält ja sicherlich einen µC, der die Daten für die SPI-Schnittstelle aufbereiten muss. Wenn man nicht aufpasst, hat man hier einen Flaschenhals. Der Kontroller muss die Daten holen, das Zielsystem damit programmieren und die Daten wieder zurückschicken. Martin
Hi ein AVR der mit 8MHz läuft hat bei 2MHz SPI-Takt 32 Takte Zeit um das nächste Byte für die SPI Schnittstelle bereitzustellen. Das sollte locker reichen. Man arbeitet dann eben mit entsprechend großen Puffern und FIFO's. Die reine SPI-Übertragungszeit beträgt etwa 1s. Man hat dann noch eine ganze Sekunde Zeit die Daten in den PC zu schaufeln. Per USB kein Problem. Been there. Done that. Matthias
@Martin: "2 Sekunden Verifizierung (ATMEGA64) sind für ein Programmiergerät ungeheuer schnell. Liest du bei der Verifizierung den gesamten Flash-Speicher aus?" Antwort: Ja. Darüber hinaus habe ich noch einen Read-Mode, der nur die Programmierten Bytes ließt, dann geht es abhängig von der Programmgröße entsprechend schneller. "Aus Welcher Hardware besteht dein neues Programiergerät? Welcher µC?" FT232BM (USB-Controller) & PIC18F242@40MHz (ca. 10 Millionen Befehle/Sek.). 12V generierung inkusive. Es ist kein externes Netzteil erforderlich. Preis für die Bauteile werden ca. bei 15 (Reichelt) liegen. Der PIC lässt sich direkt in der Schaltung über den USB-Controller programmieren, so dass für Firmwareupdates kein extra Programmiergerät erforderlich ist. Für PIC18Fxx2 lässt sich die Schaltung also auch ohne µC verwenden, was allerdings deutliche Geschwindigkeitseinbußen zur folge hat. "Welche Programmierprache bzw. Compiler wird für die PC-Plattform verwendet?" C++ "Welches Protokoll verwendest du für die Übertragung an das Programmiergerät für die AVRs?" Nichts genormtes/Möglichst wenig Overhead. Und falls es interessiert: Geplante Unterstützung für: PIC18Fxx2/8 (Programmier-/Verifizierzeit PIC18F252 ca. 2,5s ohne EEPROM - EEPROM ca. +1s) (weitere PIC18Fxxxx werden wohl folgen) ATmega Serie (ATmega64 mit 64k Programmieren/Verifizieren @>6,7MHz ca. 5s ohne EEPROM) PIC12F629/675 und kompatieble PIC16F???? ATtiny 11/12 (ca 1-2Sek) Die Programmierzeiten verkürzen sich, wenn der Speicher nicht komplett gefüllt ist. Bernd
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.