ZitierenFrage: kann ich den Vorteiler NICHT so einstellen beim Programmanfang, dass der niedrige Takt eingestellt wird ?
Dann könnte ich schnell programmieren - und den Tiny langsam laufen lassen. Stimmt das ?
Joe,
DerAltevomBerg
Nein,der Programiertakt ist vom Systemtakt abhängig.
Das STK500 bringt dir da nix.
Du mußt eben soweit runtergehen (Also die Wartezyklen soweit erhöhen) bis es einwandfrei klappt.
Alternativ Setz ihn zum Programieren auf 1 Mhz und danach wieder mit passenden Weits auf 16 Khz was aber dann aufwendig wird.
Zeit Sparste damit nicht.
Bei 16Khz Systemtakt darf der Programiertakt also die 4 Khz nicht überschreiten.
Dh. 1/4000 = 250µs pro Takt also 125µs pro Flanke.
10% Sicherheit drauf sind dann 275 also rund 280µs bzw. 137.5 also Rund 140µs an verzögerung.
Ich weiß momentan nicht was der Wert zb. bei Bascom darstellen soll.
könnte in µs sein ,Zähler einer Programschleife,in Zyklen irgendeines Taktes (Port,FSB,System etc.) oder einfach irgendein fiktiver Wert.
Soweit zu den Vermutungen.
Aber die Neugier ist geweckt.
Ich hab mal eine Schaltung an nen Zähler gehangen (SCK) und für den Bascom Programmer einige Werte ermittelt.
Weil es möglich ist das es auch Hardwareabhängig sein könnte hab ich dann das Ganze auf 2 Rechnern veranstaltet.
Testobjekt war ein Tiny26 mit 8 Mhz und fast vollem Flash.
Getestet wurde auf einem P4-1800 und einem P3-866.
Auf den anderen Kisten (A64,P3-Celeron,P2,P-MMX) hab ich jetzt kein Bascom drauf also keine Zahlen.
Angaben in Hz. (Die Übertragung ist nicht Konstant also nur ungefähre Zahlen)
Es ist also Abhängig von der Hardware.Code:Wert P4-1800 P3-866 ================================== 0 16700 12600 5 16500 12600 10 13400 10200 20 9400 7700 25 8000 6800 50 5000 4600 100 2800 2600 200 1500 1450 300 1000 1000 400 750 750
Jetzt stellte sich die Frage ob es von der CPU abhängt.
Die Überlegung sagt mir das 16Khz selbst für einen P100 lächerlich sind also hat die CPU damit nur wenig zu tun.
Also kommt nur der Systemtakt in Frage.
Also hab ich zusätzlich mal den P4 auf 2400 Getaktet und den P3 auf 1100 gebacht und jeweils 2 Werte überprüft.
Das P4-Board erlaubt eine FSB unabhängige Übertaktung wärend der P3 "nur" über den FSB zu übertakten ist.
Wie erwartet hat sich an den Weten vom P4 kaum was getan aber beim P3 war ein fast Proportionaler anstieg zu verzeichen.
Einzige Ausnahmen sind die unteren beiden Werte (300 und 400) bei denen schon jetzt kein Unterschied mehr zu sehen ist.
Selbst die 200 zeigt nur wenig differenz.
Es ist aber anzunehmen das ein Moderner Rechner der 3000er Klasse (und höher) ganz andere Zeiten hervorbringt.
Hast du es mal mit 150-200 Probiert ?
Das sollte eigentlich reichlich sicherheit bringen.
Wenn dann probleme auftauchen dann können es auch störungen sein die dir in die Übertragung funken.
Logischerweise machen die sich mit steigender Übertragungszeit stärker bemerkbar.
Was absolut Tödlich für jede Schaltung ist sind Handys.
Diese Laberfrikadellen nimmt zwar kaum noch einer richtig war aber jedes eingeschaltete Gerät ist auch ein Sender..
Ebenfalls unterschätzt sind Röhrensichtgeräte (Fernseher/Monitore) und Trafos (Halogenlampen auffem Tisch usw.) die in die Schaltung einstreuen können.
Ein weiterer Faktor sind irgendwelche Programme die im System für Sicherheit sorgen sollen und die Komunikation auf den Schnittstellen stören könnten.
Das kann alles sein von Virenscannern über Firewalls bis zu irgendwelchen Systemerweiterungen.
ggf. mal überprüfen.
Gruß
Ratber
Frage: kann ich den Vorteiler NICHT so einstellen beim Programmanfang, dass der niedrige Takt eingestellt wird ?
Dann könnte ich schnell programmieren - und den Tiny langsam laufen lassen. Stimmt das ?
Joe,
DerAltevomBerg
Sorry aber aus deiner Frage werd ich momentan nicht ganz schlau.
Erläutere mal was du damit meinst.
Gruß
Ratber
Hallo Ratber,
sorry, die Frage war total doof gestellt. Sooo spät am Abend
Du hattest selbst (Verfasst am: 13 Feb 2006, 8:09) geschrieben:
und das verstehe ich als µC-Anfänger so, dass für den Programmiervorgang der Takt auf 1 MHz gesetzt wird und danach - mit dem Programmiergerät wieder auf 16 kHz.Zitat von Ratber
Mich interessiert das, weil ich noch in der Anfängerphase bin. Als eine Übung habe ich eine Pacer geschrieben, darin kommt vor:
.... rcall takt_38khz ; Taktfrequenz herabsetzen ...
und danach
....
takt_38khz: ;=== Stelle Taktrate auf 37.5kHz
ldi r16,(1<<clkpce) ; erlaube Änderung
; des Clock-Prescaler
out clkpr,r16
ldi r16,(1<<clkps3) ; Teile den Takt durch 256
out clkpr,r16
ret
.....
Und nun nehme ich (in meiner Unwissenheit) an, dass man den eigentlichen Takt (calibrated internal RC oscillator) auch softwaremässig bei der Programminitialisierung einstellen kann - beim tiny13 vermutlich mit cksel 10 oder 01 und einer ähnlichen Routine wie oben.
Dann stelle ich den Takt vor dem Programmieren wieder auf 9M6 - und kann die Rückstellerei getrost vergessen.
Ist das so richtig gedacht - löst das das ursprüngliche Problem ?
Hoffe so ist die Frage besser gestellt.
Danke für die Aufmerksamkeit,
Joe
DerAltevomBerg
Nö,das klappt nicht so wie du dir das denkst.
Wenn du von den 16 Khz auf 1 Mhz willst dann mußt du schon die Fuse-Bits ändern und das geht nur über den jeweiligen programieradapter da man an die Fuses nicht per Software herankommt.
(Wenn doch einer einen Weg gefunden hat dann mir sagen.Könnte ich auch gut brauchen)
Zudem nur mal so zum nachdenkenl:
Beim Programieren übernimmt der Adapter die Kontrolle über den Controller und es läuft keine Software.
Der controller müßte schon hellsehen können das er gleich neu programiert wird um den Takt rechtzeitig höher zu stellen.
Woher soll der Controller also wissen das er gleich neu bespielt wird ?
Was du da in Gedanken vor hast geht nur mit einem Bootloader und dafür ist der Tiny13 nun wirklich viel zu klein.
Wie ich oben schon sagte kannst du den Takt für die Programmkontrolle erstmal auf 1 Mhz lassen und erst später ,wenn die Funktion der software weitgehends ok ist und nicht mehr so oft neu programiert werden muß, setzt du ihn wieder auf den Wunschtakt herunter.
Eine aufwändigere alternative ist den Controller für die Zeit der entwicklung mit einem externen Takt zu betreiben.
So kann man das Program bei 16 Khz testen und zum Programieren auf einen höheren Takt umschalten.
Wenn die Soft dann endgültig steht kann man dann auf den internene Takt umstellen.
Die Schaltung dazu wäre recht einfach.
Eine Taktquelle aus einigen Invertern mit Quarz oder nen fertigen Generator usw.
Dahinter einen Teiler ,zb. einen 8 Bittigen Zähler.
Da greift man einfach den passenden Takt mittels umschalter wählen
Machbar ist auch ein stufenlos regelbarer Oszillator usw.
Aber egal was du nun am Ende machst oder nuimmst,es ist immer ein kleiner Aufwand.
Mal so nebenbei gefragt:
Ist es denn so schlimm für das maximale 1 Kilobyte einige sekunden zu warten ?
Gruß
Ratber
Hallo Ratber,
danke für die Erläuterung. So hab ich wieder was gelernt - das brauch ich im Moment, nicht alles steht so ausführlich in den Büchern (ich hab eins von FRANZIS - im manual steht es sicherlich schon, wenn ich/man es in den 300 Seiten finde/t
Na ja, und einige Sekunden warten ist nicht wirklich schlimm - da kann ich zwischendurch immer mal im Forum stöbern (und solche Bemerkungen machen - ich finde dieses Forum riesig gut, weil es Dich und andere gibt, die solche Anfängerfehler sehr gepflegt ausbügeln, DANKE).
Und jetzt vermute ich auch, warum das Fuse-Bit so heisst - weil eine Sicherung im Allgemeinen NICHT intern gesetzt wird.
Schönen Tag wünscht
Joe
DerAltevomBerg
Ich weiß nicht wie es die Jungs von Atmel sehen aber das wäre eine eingängige Formulierung.
Gruß
Ratber
Berechtigungen
Lesezeichen