Lieber Besucher, herzlich willkommen bei: RCLine Forum. Falls dies Ihr erster Besuch auf dieser Seite ist, lesen Sie sich bitte die Hilfe durch. Dort wird Ihnen die Bedienung dieser Seite näher erläutert. Darüber hinaus sollten Sie sich registrieren, um alle Funktionen dieser Seite nutzen zu können. Benutzen Sie das Registrierungsformular, um sich zu registrieren oder informieren Sie sich ausführlich über den Registrierungsvorgang. Falls Sie sich bereits zu einem früheren Zeitpunkt registriert haben, können Sie sich hier anmelden.

1

Samstag, 22. November 2008, 01:44

Interner RC-Oszillator statt Quarz

Hallo Rolf,

Zitat

Original von ro.heg
Bedingt durch den internen Clock streuen die Zeiten. Als Beispiel:

3x PIC 12F629 I/P programm.

der erste
Vorgabe 1300 (gemessen=1183 Sek.), 1950 (1776 Sek.), 2600 (2368 Sek.)
der zweite
Vorgabe 1300 (gemessen=1215 Sek.), 1950 (1822 Sek.), 2600 (2429 Sek.)
der dritte
Vorgabe 1300 (gemessen=1243 Sek.), 1950 (1866 Sek.), 2600 (2486 Sek.)

diese hohe Ungenauigkeit haben die internen RC-Oszillatoren nur, wenn sie nicht kalibriert werden.
Durch Fertigungstoleranzen haben die Frequenz-bestimmenden Bauteile auf dem Chip keine sehr exakten Werte. Allerdings misst der Hersteller am fertigen Chip die Abweichung des internen Oszillators von der Sollfrequenz und legt einen Korrektur-Wert im Programmspeicher ab, der ins "OSCCAL"-Register geschrieben werden sollte. Ein kalibrierter, interner Oszillator eines PICs weicht unter Normalbedingungen weniger als 1% von seiner Sollfrequenz ab.

Wie wird der Oszillator kalibriert?
Das ist nicht für alle PICs gleich, daher muß ggf. das Datenblatt herangezogen werden.

Zum Beispiel: PIC12F629
Hier schreibt der Hersteller am Ende des Programmspeichers (Adresse 0x3FF) einen "retlw"-Befehl mit dem OSCCAL-Wert in den Programmspeicher. Am Anfang des Programms kann dieser dann per "call"-Befehl aufgerufen werden:

Quellcode

1
2
    call  0x3FF
    movwf  OSCCAL

(Aufpassen: OSCCAL liegt in Registerbank 1!)

Zum Beispiel: PIC12F508
Hier liegt der Wert für OSCCAL beim Reset schon im W-Register, so daß nur ganz am Anfang des Programms der Befehl

Quellcode

1
    movwf  OSCCAL

eingebaut werden muß.

Grüße,

Thomas

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »Ottili« (22. November 2008, 02:06)


ro.heg

RCLine User

Wohnort: Quickborn

  • Nachricht senden

2

Sonntag, 23. November 2008, 09:43

spitze!!!
die Zeiten stehen haarscharf an 1200 / 1800 / 2400 Sekunden, und das bei
allen dreien.
Interessant zu wissen, was denn eigentlich bei
call 0x3FF
movwf OSCCAL
geschieht.
Also den Debugger angeschmissen und hier der Ablauf:
Zu Beginn stand in Zelle 90h = 80h (OSCCAL)
Nach call 0x3FF wurde im Arbeitsreg. W = 00h geladen,
was mit movwf OSCCAL in Zelle 90h geschoben wurde.
Beim 16F627 ist in allen 4 Bänken kein Register OSCCAL vorhanden,
sollte das mit dem Reset zusammen hängen? Werde das mal im
Datenblatt suchen.

Ein Pic hat bei den vielen raus / rein wohl den Geist aufgegeben.

Viele Grüße

Rolf

3

Sonntag, 23. November 2008, 12:29

Hallo Rolf,

Zitat

Original von ro.heg
spitze!!!
die Zeiten stehen haarscharf an 1200 / 1800 / 2400 Sekunden, und das bei
allen dreien.
Interessant zu wissen, was denn eigentlich bei
call 0x3FF
movwf OSCCAL
geschieht.
Also den Debugger angeschmissen und hier der Ablauf:
Zu Beginn stand in Zelle 90h = 80h (OSCCAL)
Nach call 0x3FF wurde im Arbeitsreg. W = 00h geladen,
was mit movwf OSCCAL in Zelle 90h geschoben wurde.

der "retlw xx"-Befehl an Programmadresse 0x3FF wird vom Hersteller nach der Fertigung in den Chip hineinprogrammiert, und damit das Programm im Simulator mit dem "virtuellen" Prozessor überhaupt funktioniert und bei "call 0x3FF" nicht ins Leere läuft, steht auch hier auf Adresse 0x3FF ein "retlw 0"-Befehl, obwohl dieser nicht im Anwender-Programm erzeugt wurde. Den Befehl kannst Du sehen, wenn Du Dir im Simulator das Programmspeicher-Fenster öffnest (View/Program Memory) und zur letzten Adresse scrollst.
Im "echten" Prozessor steht an dieser Stelle halt lediglich ein anderer Zahlenwert, als 0.

Zitat


Beim 16F627 ist in allen 4 Bänken kein Register OSCCAL vorhanden,
sollte das mit dem Reset zusammen hängen? Werde das mal im
Datenblatt suchen.

der 16F627 hat einen bereits bei der Herstellung abgeglichenen Oszillator, da braucht man im Programm keine Kalibrierung mehr vorzunehmen und es gibt auch kein OSCCAL-Register.

Zitat


Ein Pic hat bei den vielen raus / rein wohl den Geist aufgegeben.

wie äußert sich das? Meckert das Programmiergerät (dann ist er vermutlich wirklich hin) oder funktioniert nur das Programm mit der Oszillator-Kalibrierung nicht?
Bei letzterem könnte es sein, daß versehentlich der "retlw xx"-Befehl bei 0x3FF gelöscht wurde. Normalerweise liest der Brenner diesen Befehl vor dem Löschen des PICs aus und schreibt ihn danach wieder 'rein, wenn das aber einmal nicht geklappt hat, ist der Befehl mitunter weg und "call 0x3FF" läuft ins Leere. Dann muß ggf. nur manuell ein neuer Kalibrierungswert einprogrammiert werden.

Viele Grüße

Thomas

ro.heg

RCLine User

Wohnort: Quickborn

  • Nachricht senden

4

Dienstag, 25. November 2008, 11:59

Hallo Thomas,
zum kranken Pic und sein Verhalten:
Programmierablauf lief anstantslos ab; ohne meckern!
Nach Anlegen der Versorgung zeigt der Pieper Dauerton u. lässt sich auch
nicht mit Reset in Ruhe setzen.
Heute Morgen der zweite Pic:
In der Programmierphase wird zu Beginn unterbrochen und eine Meldung
"irgendwas mit Write 03FF" erscheint. Schade, ich habe sie nicht notiert!
Ich breche alles ab und starte nochmals neu.
Programmierablauf ohne jede Meldung, aber der Pic zeigt auf der Platine
absolut todes Verhalten.
Nun habe ich beide Pics ohne Kalibrierung neu programmiert.
Resultat: beide arbeiten einwandfrei im Testbetrieb Reset alles ok.
Ich werde mal den Inhalt von 3FF ermitteln.

Grüße
Rolf

ro.heg

RCLine User

Wohnort: Quickborn

  • Nachricht senden

5

Dienstag, 25. November 2008, 12:14

Zur Ergänzung:

auf Platz 3FF steht der Opcode 3400 RETLW 0

6

Mittwoch, 26. November 2008, 01:13

Hallo Rolf,

Zitat

Original von ro.heg
Nun habe ich beide Pics ohne Kalibrierung neu programmiert.
Resultat: beide arbeiten einwandfrei im Testbetrieb Reset alles ok.
Ich werde mal den Inhalt von 3FF ermitteln.

das deutet genau auf das hin, was ich schon vermutet habe: irgendwann wurde versehentlich der "retlw xx"-Befehl auf 0x3FF gelöscht. Dadurch führt der Befehl zum holen des Kalibrierungs-Wertes "call 0x3FF" zum Absturz.
Such mal in Deiner Brenner-Software, ob es da eine Möglichkeit gibt, manuell einen neuen Kalibrierugs-Wert in den Prozessor zu schreiben. Falls die Software des Programmiergerätes das nicht unterstützt, müßte es auch gehen, indem der entsprechende Befehl mal ausnahmsweise an das Anwender-Programm angehängt wird:

Quellcode

1
2
  org 0x3FF
    retlw 0x80

Jetzt ist nur noch die Frage, welcher Zahlenwert da eingesetzt wird. 0x80 stellt erstmal einen mittleren Wert dar, und dann müsste man mit ein paar Versuchen den passenden Korrekturwert herausfinden.
Neulich hatte ich ein ähnliches Problem: ich wollte den Kalibrierungs-Werte von einem PIC12F675 wieder herstellen. Dafür habe ich ein kleines Programm geschrieben, daß an GP2 exakt alle 10 Sekunden einen kurzen Impuls ausgibt (siehe Anhang). Damit kann man schnell sehen, ob der Prozessor zu schnell oder zu langsam läuft und den Zahlenwert ggf. anpassen. Nach 3-4 Iterationen hat man den Wert 'raus...

Grüße,

Thomas
»Ottili« hat folgende Datei angehängt:
  • intosctest.zip (1,51 kB - 10 mal heruntergeladen - zuletzt: 21. Januar 2015, 00:49)

ro.heg

RCLine User

Wohnort: Quickborn

  • Nachricht senden

7

Mittwoch, 26. November 2008, 09:17

oh, weia!!!
das nennst Du ein kleines Programm!
Übrigens verweist der Assembler auf einen Fehler. Es muß sich um eine
#include - Datei handeln.
Der Zeiger steht auf _MAXRAM H'3F' "fehlt da irgend was davor?".
Ich dachte schon, man könnte den von mir ermittelten Wert über
View/Program Memory "3400h" einfach in den Speicher 03FF transportieren.

Na, mal sehen, was ich daraus mache.

Viele Grüße

Rolf

8

Mittwoch, 26. November 2008, 22:48

Zitat

Original von ro.heg
oh, weia!!!
das nennst Du ein kleines Programm!

naja, die Erzeugung der 50ms Intervalle habe ich von meinem Ortungspiepser-Programm "geklaut", daher ist der Code etwas komplizierter, als er eigentlich für diese eingeschränkte Aufgabe sein müsste. Zudem lässt sich das Programm ohne Änderungen für zwei Prozessortypen assemblieren: den 12F675 und den 12F509.
Der Hex-Code für den 12F675 lässt sich auch einfach in den 12F629 brennen, da die Prozessoren kompatibel sind - der 675 hat lediglich zusätzlich den A/D-Wandler.
Da der 12F508/509 nur einen 8-Bit Timer hat, ist das Programm auch etwas länger. Wenn es nur für 12F629/675 wäre, würde sich der 16-Bit Timer anbieten.

Zitat


Übrigens verweist der Assembler auf einen Fehler. Es muß sich um eine
#include - Datei handeln.
Der Zeiger steht auf _MAXRAM H'3F' "fehlt da irgend was davor?".

Du hast vermutlich den 12F629 unter "Configure/select device" eingestellt. Der Quelltext ist aber nur für die Prozessor-Typen 12F675 oder 12F509 vorgesehen. Mit dem 12F629 (oder anderen Prozessor-Typen) wird die falsche INC-Datei eingebunden, was zur Fehlermeldung führt. Entweder müsste der Quelltext auf den 12F629 angepasst werden, oder Du assemblierst einfach für den 12F675 und brennst den erzeugten Code in den 12F629. Wie gesagt, das geht, weil 675 und 629 Code-kompatibel sind.

Zitat


Ich dachte schon, man könnte den von mir ermittelten Wert über
View/Program Memory "3400h" einfach in den Speicher 03FF transportieren.

nein, das geht nicht, da das nur der Speicher des simulierten Prozessors ist. Die Hex-Datei wird durch Veränderungen hier nicht beeinflusst.
Ideal wäre, wenn Deine Brenner-Software eine Option hätte, mit der ein neuer Kalibrierungs-Wert eingestellt werden kann. Bei der Software zu meinem USB-Brenner (Sprut Brenner 8 ) geht das und sieht so aus: (s.Bild)

Grüße,

Thomas
»Ottili« hat folgendes Bild angehängt:
  • osccal.gif

ro.heg

RCLine User

Wohnort: Quickborn

  • Nachricht senden

9

Donnerstag, 27. November 2008, 13:32

Hallo Thomas,
danke nochmal für Deinen Hinweis "configure/Select Device"
Hier hätte ich mit meinen neuen Projekt "Märklinkrahn mit einem 16F627"
gleich am Anfang festgehangen. Das Thema liegt schon wieder Wochen
zurück. Dein Brenner ist mit meinem nicht zu vergleichen. Selbst wenn ich
über die CD nach Hilfe suche, hänge ich mit meinen Englischkenntnissen fest.
Die Oberfläche hat u.a. Aktivierungen im Bereich WRITE:
WRITE Code
WRITE Data
WRITE Config. Word
Erase bef. Write
Du schreibst, ich soll org 0x3FF und retlw 0x80 am Qelltext anhängen!!
Hab ich in Vorbereitung im Bereich Bank 0 versucht, Ergebnis 39 Fehler,
vorwiegend in Call und Goto Befehlen.
Frage: Wo bzw. an welcher Stelle anhängen!
Habe wieder einen Pic programmiert und es klappte mit OSCCAL.
Vielleicht sollte ich nicht hintereinander weg programm.
Dein letztes Programm erinnert mich sehr an Basic.

Viele Grüße und frohe Adventszeit

Rolf

10

Freitag, 28. November 2008, 02:43

Hallo Rolf,

Zitat

Original von ro.heg
...
Hab ich in Vorbereitung im Bereich Bank 0 versucht, Ergebnis 39 Fehler,
vorwiegend in Call und Goto Befehlen.
Frage: Wo bzw. an welcher Stelle anhängen!

ans Ende vom Programmcode, d.h. unmittelbar vor dem "END" am Ende der ASM-Datei.

Grüße,

Thomas

11

Freitag, 28. November 2008, 12:21

Hallo Rolf,

inzwischen ist mir auch eine Möglichkeit eingefallen, wieso der Kalibrierungswert Deiner "defekten" PICs überhaupt gelöscht worden ist:
Du hattest ja vor der Verwendung der MPLAB-IDE mit ASM-Files experimentiert, wo keine Include-Datei verwendet wurde, sondern die ganzen Prozessor-Definitionen im ASM File selbst standen. Und da hattest Du fälschlicherweise die Konfiguration vom 16F627 für den 12F629 übernommen, wobei ein Konfigurations-Wert von 3F70h herauskam.
Bei diesem Wert ist Bit 7 (= Code-Protection) auf 0, d.h. der Programmspeicher ist geschützt und kann vom Programmiergerät nicht mehr ausgelesen werden. Das gilt auch für den Kalibrierungs-Wert in der Speicherzelle 0x3FF!
So vermute ich jetzt mal, daß die PICs, die Dir aktuell mit der Oszillator-Kalibrierung Probleme machen, genau die sind, die Du damals mit der falschen Konfiguration programmiert hattest - kann das sein? Dann wüssten wir jetzt wenigstens, woran es lag...

Grüße,

Thomas

ro.heg

RCLine User

Wohnort: Quickborn

  • Nachricht senden

12

Freitag, 28. November 2008, 13:26

Hallo Thomas,
Deine Idee könnte stimmen, denn:
Es war am 06.10.2008, als Du den Config-Wert von 3F61 auseinander
gedröselt hast. Und da ist Bit 7 =0
Anfang November habe ich bei Reichelt 12 St. PIC12F629 I/P bestellt,
mein jetziger Bestand zeigt aber 14 St. Also müßten 2 gekillte drunter sein.
Ein von den toten habe ich mit der Ergänzung org 0x3FF usw. versucht, zu
programmieren. (Am Ende des Quelltextes vorher eingefügt)
Der Programmer lief los und dann kam die Meldung
Write Error at: 03FF
Wrote: 3480
Read: 0000
mh..langsam lerne ich den Inhalt der Configuration immer besser kennen.
Danke nochmal!

Viele Grüße

Rolf

13

Freitag, 28. November 2008, 13:59

Zitat

Original von ro.heg
Der Programmer lief los und dann kam die Meldung
Write Error at: 03FF
Wrote: 3480
Read: 0000


das ist nicht schön - das Programm scheint nun eigentlich richtig zu sein, da der Brenner den "retlw 0x80"-Befehl tatsächlich an der richtigen Stelle (0x3FF) in den Programmspeicher schreiben will, aber offenbar geht das schief. Vielleicht klappt es, wenn Du nochmal ganz explizit den Controller löschen lässt, und dann nochmal neu mit dem Hex-File programmierst?

Grüße,

Thomas

ro.heg

RCLine User

Wohnort: Quickborn

  • Nachricht senden

14

Sonntag, 30. November 2008, 13:04

mh...."den Controller ganz explizit löschen"!
Thomas, das ist für mich ja wieder was Neues.
Viele Grüße

Rolf

15

Sonntag, 30. November 2008, 14:16

Hallo Rolf,

damit meine ich, mit der Brenner Software einfach nur alles, was im Controller steht, zu löschen (sowas wie eine Option "Ertase All"), inclusive des OSCCAL-Wertes.
Ich habe aber gerade mal im Internet nach dem Velleman System und OSCCAL als Stichwort recherchiert, dabei bin ich sogar auf Forenbeiträge von "Leidensgenossen" von Dir gestossen, die ebenfalls nicht weiter wissen, wie sie den falschen OSCCAL-Wert (hier: Daten 0000 statt dem retlw-Befehl auf Adresse 0x3FF) wieder weg bekommen - habe aber keine Beiträge mit verwertbaren Antworten gefunden. Ich habe den Eindruck, daß die Velleman Brenner-Software IMMER den Wert ausliest und wieder zurückprogrammiert - normalerweise sinnvoll, aber wenn da einmal "0000" drin steht, ist man offenbar verloren.

Ich würde daher vorschlagen, Du markierst die beiden PICs, wo "call 0x3FF" in die Hose geht, und verwendest sie entweder in einer Anwendung mit externem Oszillator (z.B. Quarz) oder mit internem Oszillator, wenn eine Abweichung der Taktfrequenz von einigen % keine Rolle spielt. Dann natürlich ohne die Befehle "call 0x3FF" und "movwf OSCCAL" zur Kalibrierung des Oszillators.

Grüße,

Thomas

ro.heg

RCLine User

Wohnort: Quickborn

  • Nachricht senden

16

Donnerstag, 14. Oktober 2010, 08:56

Hallo Thomas,
das war mal im Jahr 2008...so vergeht die Zeit!
Gestern war ich dem Verzweifeln nahe.
Hatte noch 10 St. neue PIC12F-675 I/P und wollte sie programmieren
zur Verwendung "Ortungspieper"
bei 5 St. meldete der Programmer Error at: 03FF
Hab mir nochmal den Quelltext angesehen
call 03FF
movwf OSCCAL (Bank1)
Meine letzt programmierten waren 12F-629 I/P und ich meine,
da klappte es.
Sollte doch ein Unterschied zwischen beiden sein?
Will bei Reichelt neue bestellen.

Viele Grüße

Rolf

17

Donnerstag, 14. Oktober 2010, 12:07

Hallo Rolf,

ob 675er oder 629er, kann für die Oszillator-Kalibrierung nicht relevant sein. Der einzige Unterschied zwischen den Typen besteht darin, daß der 675 noch zusätzlich einen A/D-Wandler hat.

An Programmspeicher-Adresse 03FF steht der vom Hersteller individuell für jeden Chip ermittelte Kalibrierungs-Wert für den internen Oszillator, in Form eines "retlw"-Befehls. Für die Fehlermeldung Deines Brenners kann ich mir nur zwei Ursachen vorstellen (daß alle Deine 5 PICs dort eine defekte Speicherzelle haben, gehört nicht dazu!):

A) Der PIC ist mal vollständig gelöscht worden, wobei auch der Kalibrierungs-Wert gelöscht wurde. Nun merkt der Brenner, daß der Kalibrierungs-Wert fehlt und meckert.
In diesem Fall müsstest Du irgendwie manuell einen neuen Kalibrierungswert ermitteln und den entsprechenden "retlw"-Befehl an Adresse 0x3FF einfügen.

B) Du hast in Deinem Programmcode selbst einen Befehl an Adresse 0x3FF. Der Brenner stellt fest, daß die Speicherzelle bereits einen anderen Code enthält und meckert. Hier solltest Du den Befehl aus Deinem Programm nehmen.

Viele Grüße,

Thomas

ro.heg

RCLine User

Wohnort: Quickborn

  • Nachricht senden

18

Donnerstag, 14. Oktober 2010, 13:19

Hallo Thomas,
danke für Deine Antwort.
Hinweis B. müßte stimmen.
Ich entdecke im Qelltext zu Beginn:
;Änderung: Probleme mit der Kalibrierung (Eingabe:org 0x3FF/retlw 0x80) am Ende.
Und was steht am Ende?
org 0x3FF
retlw 0x80
end

werde das heute Abend entfernen und mit 12F-675 neu starten.
Melde mich!

Grüße

Rolf

ro.heg

RCLine User

Wohnort: Quickborn

  • Nachricht senden

19

Samstag, 16. Oktober 2010, 10:00

Hallo Thomas,
alles ist wunderbar abgelaufen!
Anderes Thema: Hast Du schon mal mit dem ATTINY 44 20PU
Kontakt gehabt?
Unter Elektr. Schaltungen wurde von Ralf ein Thread eröffnet
"Aktiver Lipo-Saver / Gyro Pulser usw." (Bascom / ATTINY44)
Lieferant www.farnell.com für Atmel (Reichelt hat die Type nicht)
Programmer mySmart USB MK2 von ELV zu 27,95 €
Ein Lernpacket gibt es auch vom Franzis-Verlag zu 49,95 € in Deutsch
Aber ich glaube, da muß man im englischen versiert sein.
Atmel würde mich schon interessieren.

Viel Grüße und nochmals Dank

Rolf

20

Samstag, 16. Oktober 2010, 13:27

Hallo Rolf,

Zitat

Original von ro.heg
Hast Du schon mal mit dem ATTINY 44 20PU
Kontakt gehabt?


nicht wirklich - aber da gibt es den Bereich "Atmel Programmierung" hier im Forum, da sollten sich jede Menge mehr oder weniger erfahrene Atmel-Anwender tummeln... ;)

Vilele Grüße,

Thomas