Problem beim Programmieren bei minimaler Taktung Tiny13V

[Windi]

Ich versuche ein Programm auf einem Tiny13 möglichst energiesparend zu erstellen da die Schaltung mit Batterien betrieben wird und lange laufen soll. Bei dem Programm reicht es aus, wenn es mit nur wenigen kHz läuft.

Dazu habe ich per Fuses den Takt vom internen 128 kHz-Oszillator verwendet und per Crystal-Befehl im Programm die entsprechende Taktfrequenz eingestellt. Das klappt problemlos. Ich hätte aber gerne noch den "Frequenzteiler durch 8" aktiviert so dass mein Programm nur mit 16 kHz läuft.

So getaktet bekomme ich nach dem Laden allerdings immer einen Verify-Error. Es klappt einfach nicht. Kann mir jemand sagen, warum?

Ich hab es sowohl mit dem Sparprogrammierer "Stecker, Kabel, 2 Widerstände" als auch mit einem "normalen" Programmierstecker mit Treiber-IC versucht. Immer das gleiche Ergebnis.

Bei den hohen Taktungen im Mhz-Bereich klappt es (auch beim Teilen durch 8 ) problemlos.

[ogni42]

Die Programmiergeschwindigkeit darf nicht größer als 1/4 des Taktes sein. Das musst Du für Deinen Programmer einstellen. Dann sollte es auch funktionieren.

[Windi]

Und wo kann ich das einstellen?
Über Port-Delay bei der parallelen Schnittstelle?

[ogni42]

Sollte in der Hilfe zu Bascom stehen. Da können Dir andere sicher besser weiter helfen als ich, da ich immer mit WinAVR und manchmal mit PonyProg arbeite.

[Ratber]

Ja,den Portdelay raufsetzen.

Fang einfach mit 50 an und taste dich vorran bis es läuft.

Denk drann eine klene sicherheitsreserve zu lassen sonst gehts mal und mal nicht.

[Windi]

Dankeschön!
Mit dem Portdelay hat es geklappt.

[Ratber]

Prima.

Darf man fragen welcher Wert nun für ca. 16Khz Taktung reicht ? (Reine Neugier)

[Windi]

Mit 100 hab ich es hin gebracht.
Klappt allerdings nur ca. jedes 4. mal fehlerfrei, aber damit kann ich leben.

[Ratber]

Danke für die Info.

[Windi]

Klappt leider doch nicht so wie ich will.
Bei einem kurzen Programm klappt es nur ca. jedes 4. mal.
Jetzt wollte ich es mit einem längeren Programm versuchen.
Keine Chance. Bricht leider immer mit einem Verify-Error ab.
Jetzt könnte ich natürlich die Wait-Befehle um den Faktor 8 im Programm vergrößern und nach dem Programmieren das "Takt/8"-Fusebit setzen.
Gibt es noch eine andere (sicherere) Möglichkeit den Prozessor fehlerfrei bei 16kHz zu programmieren? Hat das STK500 hier Vorteile?

[Ratber]

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)



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


Es ist also Abhängig von der Hardware.
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.

[oberallgeier]

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 ? :-k

Joe,
DerAltevomBerg

[Ratber]

Sorry aber aus deiner Frage werd ich momentan nicht ganz schlau.

Erläutere mal was du damit meinst.

[oberallgeier]

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:


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.

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.

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

[Ratber]

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 ?

[oberallgeier]

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

[Ratber]

......Und jetzt vermute ich auch, warum das Fuse-Bit so heisst - weil eine Sicherung im Allgemeinen NICHT intern gesetzt wird......


Ich weiß nicht wie es die Jungs von Atmel sehen aber das wäre eine eingängige Formulierung.