Hallo Leute, ich habe gerade eine Liste mit ASM-Befehlen der ATmegas durchgeschaut und bemerkt, dass der befehl spm (als in Flash schreiben) als einziger keine angaben über die Ausführungsdauer hat. Wie kann man das verstehen? Gruß, Yaro
Weil dieser Befehl ggf. das Flash programmiert. Und wie lange das dauert hängt nicht vom Core ab.
Es hängt aber doch von der Taktrate ab.... Einen AVR programmieren, der mit 1MHz getaktet ist dauert viel länger, als einen 16MHz getakteten AVR zu programmieren.
Aus einem Datenblatt: 25.2.4 Programming Time for Flash when Using SPM The calibrated RC Oscillator is used to time Flash accesses. Table 26-6 shows the typical programming time for Flash accesses from the CPU. Flash write (Page Erase, Page Write, and min max write Lock bits by SPM) 3.7 ms 4.5 ms Note: 1. Minimum and maximum programming time is per individual operation. avr
Yaro schrieb:
> Es hängt aber doch von der Taktrate ab....
Definitionssache. Es hängt nur dann von der Taktrate ab, wenn man es in
Takten misst. Wenn man die Dauer in Zeit misst, dann nicht.
Das ist etwas komisch... Ich meine dei Dauer in "Zeit", nicht in "Takten" Wenn ich einen AVR mit dem AVRISP programmiere, der mit 1MHz getaktet ist, dauert das viel länger als wenn ich einen programmiere, der mit 8MHz getaktet ist. ICh habe zwar grad keine genauen werte, meine mich aber zu erinnern, dass es ca. 40sek zu 10sek waren. Am SPI Bus kann das nicht liegen, denn der überträgt ein Wort deutlich schneller, als in 3ms (selbst bei 1MHz)
Wo ist beim ISP-Programmieren der Befehl "SPM"? Richtig, es gibt keinen, das ISP-Programmieren geht nach einem eigenen Protokoll mit eigenen Befehlen. Dennoch ist auch beim ISP-Programmieren die reine Programmierzeit eine taktunabhängige Konstante, nämlich twd_flash (ATmega88: 4.5ms), die je Block (page) gewartet werden muss.
Yaro schrieb: > Wenn ich einen AVR mit dem AVRISP programmiere, der mit 1MHz getaktet > ist, dauert das viel länger als wenn ich einen programmiere, der mit > 8MHz getaktet ist. Was hat AVRISP mit SPM zu tun? Die Programmierzeit via ISP hängt einerseits vom Flash ab, andererseits von der Kommunikation zwischen PC und ISP-Adapter und Controller. Und die Kommunikation zwischen Adapter und Controller wird mit sinkendem Takt langsamer, weil der ISP-Takt maximal 1/4 des Controller-Taktes betragen darf.
> Was hat AVRISP mit SPM zu tun? Naja... Beide schreiben in den Flash... Deswegen kam ich darauf. > Kommunikation zwischen Adapter und Controller wird mit sinkendem > Takt langsamer, weil der ISP-Takt maximal 1/4 des Controller-Taktes > betragen darf. 1/4 des Controllertaktes wird sich doch kaum merkbar auf eine Zeit von 4.5ms auswirken. Die Übertragung eines Bytes dauert bei einem Takt von 1MHz nur ca. 32us.
Probier es doch aus. Lässt sich ja einstellen. Aber nimm dafür den gleichen Controller, denn es hängt auch direkt von der Blockgrösse des Flash ab. Doppelte Pagegrösse halbiert die nackte Programmierzeit, wenn man sie auf das Byte runterrechnet, denn der Programmiervorgang bezieht sich im Flash immer auf eine komplette Page, nicht auf einzelne Bytes.
Yaro schrieb: >> Was hat AVRISP mit SPM zu tun? > Naja... Beide schreiben in den Flash... Deswegen kam ich darauf. Die Frage lautete aber eindeutig nach "spm", und damit hat es nichts zu tun. > 1/4 des Controllertaktes wird sich doch kaum merkbar auf eine Zeit von > 4.5ms auswirken. Die Übertragung eines Bytes dauert bei einem Takt von > 1MHz nur ca. 32us. Schön wär's. Um 1 Byte per ISP zu übertragen, musst Du 4 Bytes senden. Damit und mit Deiner Rechnung braucht die Übertragung von 35 Bytes genauso lang wie das Programmieren eines Blocks (der - je nach Type - kleiner oder größer sein kann als diese 35 Bytes). Jedenfalls bist Du mit der Übertragungszeit lange innerhalb derselben Größenordnung wie die Programmierzeit.
>Die Frage lautete aber eindeutig nach "spm", und damit hat es nichts zu >tun. Die Frage war anfangs auch nicht wegen dem AVRISP sondern allgemein gestellt. Erst später kam mir dann die Parallele zum Flashen >Aber nimm dafür den gleichen Controller Ich hab beides mit einem ATmega8, aber mit unterschiedlichen Frequenzen gemacht. >Um 1 Byte per ISP zu übertragen, musst Du 4 Bytes senden. Selbst bei 4Bytes liegt die übertragungsgeschwindigkeit für ein "richtiges" Byte dann bei weniger als 150us == 0.15ms, was bei einer Schreibzeit von 4.5ms vernachlässigbar klein ist. Bei meinem USBASP lässt sich einstellen, mit welcher Geschwindigkeit geflasht werden soll. Wenn ich 1MHz einstelle, dann ist es langsam, egal wie hoch der zu flashende Controller getaktet ist. Wenn ich 8MHz einstelle, dann geht es deutlich schneller (natürlich nur bei Controllern, die einen Takt von mind. 8MHz haben, denn sonst funktioniert die Übertragung über SPI nicht). Ich weiß nicht recht, ob das dafür Spricht, dass die Programmierzeit von dem Bus abhängt, oder dass das USBASP einfach nur länger wartet, bevor es das nächste Byte sendet. Auf jeden Fall ist scheint mir das ganz noch nicht so logisch, wie ichs gerne hätte =)
> Selbst bei 4Bytes liegt die übertragungsgeschwindigkeit für ein > "richtiges" Byte dann bei weniger als 150us == 0.15ms, was bei einer > Schreibzeit von 4.5ms vernachlässigbar klein ist. Nöö, die 4,5ms beziehen sich ja nicht auf ein (1) "richtiges Byte", sondern auf eine ganze Page. Um die zu füllen, musst Du halt ein paar "richtige Bytes" mehr übertragen. Bei 32 "richtigen Bytes" hast Du die Schreibzeit bereits erreicht. Nun schau mal im Datenblatt nach, wie groß die Pages bei den einzelnen AVRs sind (ich habe es nicht mehr im Kopf, wusste es aber mal, als ich meine ISP-Software schrieb). Ich befürchte, dass die Datenübertragung (einer Page) bedeutend länger dauert als die Schreibzeit (einer Page). ...
Alles klar. Vielen Dank allen, die hier etwas beigetragen haben!
Thread beobachten
Seitenaufteilung abschaltenBitte 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.