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.

ro.heg

RCLine User

Wohnort: Quickborn

  • Nachricht senden

41

Sonntag, 26. Oktober 2008, 18:40

Hallo Claus,
danke für Deine Nachricht!
Mit den Ausdrücken von MPLAB muß ich mich erst anfreunden.
SEKUNDEN_HIGH steht auf "LN20 (das muß die Zeile sein)
und "COL13" (das muß die Spalte sein)
Soll ich jetzt die Variablen nach links (COL1) setzen?
Aber in LN20 lassen? D.h. alles eng aneinander (EQUH'00')
Wirklich alles NEU für mich!
mh.. was mache ich nur mit SEKUNDEN_HIGH ?damit radix dec
wirksam bleibt?

Viele Grüße

Rolf

42

Sonntag, 26. Oktober 2008, 19:10

Zitat

Original von ro.heg
SEKUNDEN_HIGH steht auf "LN20 (das muß die Zeile sein)
und "COL13" (das muß die Spalte sein)

COL13 ist verkehrt, Labels müssen in Spalte 1 beginnen.

Zitat


Soll ich jetzt die Variablen nach links (COL1) setzen?

Ja. Lösche alle Leerzeichen und Tabs davor.

Zitat


Aber in LN20 lassen? D.h. alles eng aneinander (EQUH'00')

na ja, zwischen den Bezeichnern muss schon mindestens ein Leerzeichen sein, sonst kann der Parser mit dem langen Ding nichts anfangen.

Zitat


mh.. was mache ich nur mit SEKUNDEN_HIGH ?damit radix dec
wirksam bleibt?


Vielleicht so:

SEKUNDEN_HIGH equ D'10' ; explizite Angabe der Basis 10

Eigentlich müsste auch

SEKUNDEN_HIGH equ 10; wg. radix dec ist Basis 10 gemeint

funktionieren, aber mit einer expliziten Angabe wird es IMHO klarer, besonders, wenn man hier Teile des Codes postet.

Grüße
Claus

43

Sonntag, 26. Oktober 2008, 22:26

Hi Rolf,

zu der Position der Labels in der Zeile hat Claus ja schon geschrieben.

Was "radix" angeht: Wenn Du alle Zahlen im Text immer explizit mit der Basis angibst, brauchst Du die Zeile mit "radix" überhaupt nicht. Ich verwende aus Gewohnheit immer "radix dec", weil ich es z.T. von anderen Entwicklungswerkzeugen und Programmiersprachen gewohnt bin, daß eine Zahl ohne spezielle Angabe zur Basis eben dezimal interpretiert wird. "movlw 25" soll (für mich) tatsächlich eine Fünfundzwanzig ins WRegister laden, und keine 37. Schließlich bin ich mit dem Dezimalsystem aufgewachsen, und der Computer soll sich diesbezüglich gefälligst nach mir richten...

Wir hatten hier im Forum ja schon öfters über Dein Piepser-Programm kommuniziert, daher denke ich zu wissen, daß z.B. Deine Labels "SEKUNDEN_HIGH" und SEKUNDEN_LOW" "Variablen" (also Speicherzellen im RAM) sein sollen.
Hier ist zunächst ein klarer Fehler: Du weist den Symbolen den Wert H'10' und H'11' zu (das ist dadurch die RAM-Adresse der Variablen). Wenn Du Dir aber im Datenblatt des 12F629 (sorry, daß ich nun schon wieder damit nerve...) mal die "Data Memory Map" anschaust, wirst Du sehen, daß sie Adresse 0x10 (=H'10') schon mit dem "T1CON"-Register belegt ist, und die Adresse 0x11nicht implementiert ist. Der RAM-Bereich (als "General Purpose Registers" bezeichnet) fängt bei Adresse 0x20 an.

Zum Stil: Die Variablen-Adressen mit "EQU" zuzuweisen ist nicht besonders zu empfehlen. Viel besser ist z.B. "CBLOCK" zu verwenden. Siehe dazu unser SIM-Demoprogramm, dort sind die Variablen "timer" und "counter" jeweils als eine Speicherzelle definiert. Der Vorteil ist eine leichte Portierbarkeit auf einen anderen Prozessor, denn nur die Anfangsadresse (hier: 0x20) muß ggf. geändert werden. Auch, wenn man mal Programmteile aus verschiedenen Projekten kombinieren möchte, ist es leichter und weniger fehleranfällig, wenn man nur die Variablen-Definitionsblöcke kopieren muß und nicht hinter jeder Variablen die fest mit EQU zugewiesene Adresse anpassen muß.
Außerdem hat sich eingebürgert, daß Variablen mit Kleinbuchstaben und Konstanten oder Hardware-Register mit Großbuchstaben bezeichnet werden. Das macht das Programm etwas besser lesbar, weil man schon rein optisch ein leichtes Unterscheidungsmerkmal hat.

Bei den Equates für SW1..SW3 weiß ich nicht so recht, was davon zu halten ist. Wenn es Definitionen der Portleitungen für die Schalter sein sollen, passen sie nicht zu Deiner Hardware-Beschreibung!?

Grüße,

Thomas

Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von »Ottili« (26. Oktober 2008, 22:37)


ro.heg

RCLine User

Wohnort: Quickborn

  • Nachricht senden

44

Dienstag, 28. Oktober 2008, 09:18

Hallo Thomas,
ich sitze hier und versuche das zu verarbeiten!

1. radix dec habe ich entfernt und folgendes vorgegeben.
movlw HIGH 1200 ;ist die Zeit für 20 Minuten
movwf SEKUNDEN_HIGH
movlw LOW 1200
movwf SEKUNDEN_LOW

2. Ich hatte aus dem Ordner sofort die Data-Memory Map vom 12F629
und vergleichsweise vom 16F627 zur Hand
mh, merkwürdig bei beiden Typen liegt T1CON auf 10h. Nur das beim
16F nicht gemeckert wurde. Egal auch wie, soll ich es versuchsweise
erst mal mit SEKUNDEN_HIGH EQU H'20' versuchen und alle Variablen
aufwärts.
3. Das mit CBLOCK muß ich erst noch verarbeiten.

Zum Schluß wieder eine Frage zu den 9 Warnungen:
"Warnung (219) Test_2.asm 103 invalid RAM location spezified"
Das Gleiche mit Nr. 108/112/138/143/147/173/178/182
Was sagen mir diese Nummern?
Ich hatte Test_2.lst geöffnet u. dachte, es sind Zeilen-Nummern,finde aber
keinen Zusammenhang.

Viele Grüße
Rolf
P.S. Ich glaube, ich bin der einzige, der ewig nervt!

45

Dienstag, 28. Oktober 2008, 12:18

Hallo Rolf,

Zitat

Original von ro.heg
1. radix dec habe ich entfernt und folgendes vorgegeben.
movlw HIGH 1200 ;ist die Zeit für 20 Minuten
movwf SEKUNDEN_HIGH
movlw LOW 1200
movwf SEKUNDEN_LOW

also, ich versuche das mit dem Radix nochmal ganz deutlich zu erklären:
Wenn Du im Assembler-Quelltext eine Zahl schreibst, dann kann diese verschiedene Zahlenbasen haben, z.B. hexdezimal ist zur Basis 16, entsprechend bestehen die Zahlen aus 16 verschiedenen Ziffern (0..9,a,b,c,d,e,f). Unser gebräuchliches Dezimalsystem (Basis: 10) besteht aus 10 Ziffern (0..9), und das Binär- oder Dualsystem (Basis: 2) besteht nur aus zwei Ziffern (0,1), daher wird es gerne in der Computertechnik verwendet, weil eine digitale Elektronik nur "an" und "aus" kennt.
Daneben gibt es auch noch das Oktalsystem (Basis 8 ). Andere Zahlensysteme mit beliebigen Basen wären denkbar, haben aber keine praktische Bedeutung

Wenn Du nun eine Zahl schreibst, ohne Kennzeichnung, welches System dieser Zahl zugrundeliegt, ist das Ergebnis nicht unbedingt eindeutig:
eine "10" ist nach unserem üblichen Zahlenverständnis die Zahl unserer Finger beider Hände zusammen, nämlich "zehn". Genausogut kann man die Zahl aber auch binär interpretieren, sprich "eins-null", was nach dezimal umgewandelt dem Wert 2 entspricht.
Oder hexadezimal: sprich auch "eins-null", hat dann aber den dezimalen Wert 16!
Im Oktalsystem wäre die "10" entsprechend eine dezimale 8.
Das englische Wort "radix" heißt nichts anderes, als "Basiszahl" (http://dict.leo.org/ sei dank, sonst hätte ich dafür auch mein altes englisch-Lexikon 'rauskramen müssen)

Wenn überhaupt nichts angegeben ist, arbeitet der MPASM als "default"-Einstellung im Hexadezimalsytem! Das bedeutet, die oben in Deinem Text angegebene Zahl für die Sekunden (1200) werden vom Assembler nicht als "Eintausendzweihundert" interpretiert, sondern als "0x1200" (0x = eine mögliche und sehr gebräuchliche Kennzeichnung der Zahl als "hexadezimal"). Du bekommst als Wartezeit also nicht 20 Minuten (= 1200 Sekunden), sondern 4608 Sekunden, da 0x1200 = d'4608' ist:
1 * 16^3 + 2 * 16^2 + 0 * 16 + 0

Du kannst das ganz leicht korrigieren, indem Du die '1200' explizit als Dezimalzahl kennzeichnest (D'1200'), oder Du sagst dem Assembler am Anfang Deines Programmtextes, daß alle Zahlen, die nicht besonders gekennzeichnet sind, als Dezimalzahlen zu verstehen sind.
Genau das macht die "Radix"-Anweisung: "Radix dec" heisst also: Alle Zahlen im folgenden Text ohne besondere Kennzeichnung sind Dezimalzahlen!
Ich bevorzuge letzteres, weil es unserem, von klein auf gelernten Zahlenverständnis am Besten entspricht, daß eine "10" eben eine Zehn ist, und keine 16 und keine 2. Wenn an entsprechender Stelle im Programm ein anderes Zahlensystem angebracht ist, dann werden diese Zahlen entsprechend gekennzeichnet, z.B. B'10100011' für eine Binärzahl, 0xA3 oder H'A3' für die gleiche Zahl im Hexadezimalzsystem oder eben einfach 163 als Dezimalzahl.

Zitat


2. Ich hatte aus dem Ordner sofort die Data-Memory Map vom 12F629
und vergleichsweise vom 16F627 zur Hand
mh, merkwürdig bei beiden Typen liegt T1CON auf 10h. Nur das beim
16F nicht gemeckert wurde. Egal auch wie, soll ich es versuchsweise
erst mal mit SEKUNDEN_HIGH EQU H'20' versuchen und alle Variablen
aufwärts.

Ich würde schon sagen, daß es für den 16Fxxx genauso falsch ist, die Adressen 0x10 und 0x11 als RAM verwenden zu wollen. Wenn es dort funktioniert hat, kann ich Dir leider auch nicht sagen, warum - es dürfte eigentlich nicht gehen!

Zitat


Zum Schluß wieder eine Frage zu den 9 Warnungen:
"Warnung (219) Test_2.asm 103 invalid RAM location spezified"
Das Gleiche mit Nr. 108/112/138/143/147/173/178/182
Was sagen mir diese Nummern?
Ich hatte Test_2.lst geöffnet u. dachte, es sind Zeilen-Nummern,finde aber
keinen Zusammenhang.

Es sind schon die Zeilennummern, und wenn Du auf die Fehlermeldung doppelklickst, springt der Cursor sicher auch auf die Stelle im Text. Nur: der eigentliche Fehler ist nicht der Befehl an dieser Stelle (z.B. movwf SEKUNDEN_LOW"), sondern steckt in der Definition: "SEKUNDEN_LOW equ H'11'
Damit sagst Du ja erstmal nur, daß das Label "SEKUNDEN_LOW" den Wert H'11' hat. Das ist NOCH kein Fehler, aber später im Programm, z.B. beim Befehl
"movwf SEKUNDEN_LOW" ersetzt der Assembler die Bezeichnung "SEKUNDEN_LOW" durch den Zahlenwert 0x11 oder dezimal 17. Erst jetzt wird daraus ein Fehler, den der Assembler erkennen kann, weil die Adresse 0x11 keine gültige RAM- oder Register-Adresse des Prozessors ist!

Grüße,

Thomas

Zitat


P.S. Ich glaube, ich bin der einzige, der ewig nervt!

Och, vielleicht bist Du auch nur der einzige, der sich traut, Fragen zu stellen...

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »Ottili« (28. Oktober 2008, 12:28)


46

Dienstag, 28. Oktober 2008, 13:02

Zitat

Original von ro.heg
2. Ich hatte aus dem Ordner sofort die Data-Memory Map vom 12F629
und vergleichsweise vom 16F627 zur Hand
mh, merkwürdig bei beiden Typen liegt T1CON auf 10h. Nur das beim
16F nicht gemeckert wurde.

So, hab grad mal ins Datenblatt geguckt:
Ist klar, warum der Assembler beim 16F627 nicht meckert:
Die Adresse 0x10 wird sowieso bei beiden Prozessortypen nicht angemeckert, weil diese bei beiden Prozessoren existiert (= Register T1CON)
Nur beim 12F629 ist die Adresse 0x11 (also Dein Label "SEKUNDEN_LOW") nicht implementiert, daher führt der Zugriff darauf zu einer Warnmeldung des Assemblers.
Beim 16F627 liegt auf dieser Adresse das Register "TMR2".

Richtig ist das Programm deshalb aber für beide Prozessoren nicht - daß es evtl. sogar mit dem 16F627 einigermaßen zu funktionieren scheint, liegt dann eher zufällig daran, daß Du die Register beschreiben und auch wieder auslesen kannst. Aus Sicht des Programms verhalten diese sich daher fast wie normale RAM-Speicherzellen. Allerdings wirst Du spätestens dann auf sehr merkwürdige Effekte stossen, wenn Du in Deinem Program irgendwann einmal einen der Timer (TMR0, TMR1) verwenden willst....

Zitat


Richtig funktion
Egal auch wie, soll ich es versuchsweise
erst mal mit SEKUNDEN_HIGH EQU H'20' versuchen und alle Variablen
aufwärts.
3. Das mit CBLOCK muß ich erst noch verarbeiten.

Eben genau das "und alle Variablen aufwärts." macht die "CBLOCK"-Anweisung automatisch!
Also, statt:

Quellcode

1
2
3
4
5
6
;hier wird die Zeit gezählt:
sekunden equ H'20'
minuten  equ H'21'
stunden equ H'22'
;Speicherplatz für was anderes:
irgendwas equ H'23'

kannst Du schreiben:

Quellcode

1
2
3
4
5
6
7
8
  CBLOCK H'20'
;hier wird die Zeit gezählt:
sekunden
minuten
stunden
;Speicherplatz für was anderes:
irgendwas
  ENDC

Der Vorteil: fängt der RAM-Bereich z.B. bei einem anderen Prozessor an einer anderen Adresse, als 0x20 an, kannst Du das leicht durch abändern nur einer einzigen Zahl portieren! Oder, wenn Du noch eine Variable einfügen willst, z.B. "millisekunden", geht das bei CBLOCK ganz einfach:

Quellcode

1
2
3
4
5
6
7
8
  CBLOCK H'20'
millisekunden
sekunden
minuten
stunden
;Speicherplatz für was anderes:
irgendwas
  ENDC

Bei Definition durch EQU musst Du entweder alle folgenden Zahlen ändern, oder die neue Variable hinten anhängen, wodurch evtl. thematisch zusammengehörende Variablen auseinandergerissen werden:

Quellcode

1
2
3
4
5
6
7
8
;hier wird die Zeit gezählt:
sekunden equ H'20'
minuten  equ H'21'
stunden equ H'22'
;Speicherplatz für was anderes:
irgendwas equ H'23'
;bei der Zeit fehlten noch die Millisekunden:
millisekunden equ H'24'

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »Ottili« (28. Oktober 2008, 13:04)


ro.heg

RCLine User

Wohnort: Quickborn

  • Nachricht senden

47

Mittwoch, 29. Oktober 2008, 10:16

Hallo Thomas,
Erfolg: habe die Variablen auf Spalte 1 gesetzt...nur noch 4 Warnungen.
Die EQU Zuweisungen von SW0 bis SW3 gelöscht .
btfss GPIO,1 usw. in der Abfrage eingegeben ..0 Warnungen 0 Error!
Aber jetzt kommts:
CBLOCK H'20'
SEKUNDEN_HIGH
SEKUNDEN_LOW
LOOP1
LOOP2
LOOP3
Taste F10 oh wei 170 ERRORS!!
Habe herumexperementiert, d.h. CBLOCK spaltenmäßig versetzt
die LOOPs mit EQU 25/26/27 versehen kein Erfolg
CBLOCK wieder heraus genommen und EQU ab 20 = alles ok!

Ich warte noch mit den Brennen.

Grüße an alle

Rolf

48

Mittwoch, 29. Oktober 2008, 10:26

Hast du an das ENDC am Ende des Variablenblocks gedacht?

ro.heg

RCLine User

Wohnort: Quickborn

  • Nachricht senden

49

Mittwoch, 29. Oktober 2008, 19:43

Hallo Claus,
DANKE, es haut hin!
Sollte ich das bei Thomas überlesen haben?
Viele Grüße

Rolf

Heute war im Norden Deutschlands ein hervorragendes Flugwetter
bei fast Windstille, und trotzdem bin ich beim Landeanflug abgeschmiert.

ro.heg

RCLine User

Wohnort: Quickborn

  • Nachricht senden

50

Donnerstag, 30. Oktober 2008, 13:10

Hallo Leute,
ich bin fast am Ziel!
Brennen lief ohne Probleme ab. (Configuration = 3FA4)
Nach Anlegen der Versorgung lief der Pieper mit ungewöhnlich schrillenden
Tönen los.
Bei "Halten" der Taste Reset war Ruhe, bei Loslassen wieder die Töne!
Gewählt hatte ich PULL-UP Widerstände, die Pegel an den Eingängen
hatten einen Messwert von ca. 2,8 bis 3,0 Volt. Nur am Reseteingang
lagen ca. 0,5 Volt. Das machte mich stutzig, so daß ich einen 10K
extern anlegte und siehe da, der Pieper arbeitet sauber.
Anscheinend muß man den Reset GP3 mit einem externen Widerstand
belegen.

Viele Grüße

Rolf

51

Donnerstag, 30. Oktober 2008, 19:12

Hallo Rolf,

Zitat

Original von ro.heg
Anscheinend muß man den Reset GP3 mit einem externen Widerstand
belegen.

Deine Feststellung ist richtig: am MCLR/GP3/VPP Pin gibt es keinen internen Pull-Up Widerstand. So steht's auch im Datenblatt:

Zitat

12F629 Data Sheet:
3.2.1 WEAK PULL-UP
Each of the GPIO pins, except GP3, has an individually
configurable weak internal pull-up.


Grüße,

Thomas

ro.heg

RCLine User

Wohnort: Quickborn

  • Nachricht senden

52

Freitag, 31. Oktober 2008, 09:25

Hallo Leute,
meinen Erfolg muß ich wieder zurückschrauben, Warum?
10 K am Reseteingang alles ok!
Versorgung anlegen, der Pic fragt die Eingänge ab und bleibt in der Schleife
=auch ok! Ich drücke die Taste "Test", er springt in die "Blink-Schleife"
(3Sek. EIN/ 5Sek. AUS) = ist auch ok! Die Werte in LOOP1/2/3 habe ich in
H'xx' eingegeben.
Versorgung abnehmen, DIP-Schalter1 EIN und wieder anlegen.
Der Sekundenzähler läuft bis 4197 Sek. und dann kommt die Blinkphase!
(Soll, und so war es beim Pic16F627, 1200 Sek.)
Am besten, ich mach mir die Arbeit und schreib die Routine auf:
(vorber1) ;20 Minuten
movlw HIGH 1200
movwf SEKUNDEN_HIGH
movlw LOW 1200
movwf SEKUNDEN_LOW
call warten
goto blinken ; hier springt er dann in die Blinkphase, tut er auch

(warten)
incf SEKUNDEN_LOW,F
incf SEKUNDEN_HIGH

(warten1)
decfsz SEKUNDEN_LOW,F
goto warten2
decfsz SEKUNDEN_HIGH,F
goto warten2
retlw 0 ; hatte ich auf return geändert, bringt nichts

(warten2) ;Schleife für ca. 1 Sek.
movlw H'FF'
movwf LOOP1
movlw H'FF'
movwf LOOP2
movlw H'05'
movwf LOOP3

(gehe)
decfsz LOOP1,F
goto gehe
decfsz LOOP2,F
goto gehe
decfsz LOOP3,F
goto gehe
goto warten1
ab hier geht es dann weiter mit vorber2 = 30 Minuten mit DIP-Schalter 2
(Eingabe = 1800) das hab ich nicht getestet.
Mein Verdacht ist, daß er die Eingabe 1200 als Hex-Wert interpretiert,
denn nach Umrechnung sind 1200h = 4608 Dezimal.
Bringt das "Kuttel-Muttel" wenn ich Werte mal in H'xx' angebe und wieder
in movlw HIGH 1200?

Vielleicht habt Ihr eine Lösung!

Viele Grüße

Rolf

53

Freitag, 31. Oktober 2008, 12:24

Zitat

Original von ro.heg
Hallo Leute,
meinen Erfolg muß ich wieder zurückschrauben, Warum?

Naja, ein Erfolg ist doch schonmal, wenn es wenigstens teilweise funktioniert.
Es ist ganz normal, das ein etwas komplexeres Programm nicht gleich auf Anhieb macht, was es soll - dafür gibt es ja den Debugger...

Zitat


Der Sekundenzähler läuft bis 4197 Sek. und dann kommt die Blinkphase!
(Soll, und so war es beim Pic16F627, 1200 Sek.)

hier muß ich ganz klar auf mein Posting weiter oben hinweisen, wo ich die Sache mit dem Radix erklärt habe. Es ist für Assembler-Programmierung zwingend notwendig, den Umgang mit den verschiedenen Zahlensystemen (dec/hex/binär) zu beherrschen!
Wie ich oben schon schrieb, wird Deine "1200" tatsächlich als H'1200' interpretiert, da Du "radix dec" 'rausgeschmissen hast und die 1200 nicht als Dezimalzahl gekennzeichnet hast!

Zitat


Am besten, ich mach mir die Arbeit und schreib die Routine auf:

Wenn es mehr, als nur ein kurzes Programmsegment ist, wäre es vielleicht geschickter, einfach das xxxx.asm File als ZIP-verpackt dem Posting anzuhängen.

Zitat


Mein Verdacht ist, daß er die Eingabe 1200 als Hex-Wert interpretiert,
denn nach Umrechnung sind 1200h = 4608 Dezimal.

richtig! Warum gehst Du Deinen eigenen Verdachtsmomenten nicht erstmal nach?

Zitat


Bringt das "Kuttel-Muttel" wenn ich Werte mal in H'xx' angebe und wieder
in movlw HIGH 1200?

Du kannst jeden Wert jeweils in einem beliebigen, für die jeweilige Situation am Besten passenden Zahlensystem angeben - das vereinfacht das Schreiben des Programms, weil Du Werte nicht selbst umrechnen musst, und macht den Programmtext besser lesbar. Die Zahl muß für den Assembler nur entsprechend gekennzeichnet sein, und Du musst berücksichtigen bzw. durch "radix xxx" entscheiden, welches Zahlensystem gelten soll, falls eine Zahl nicht gekennzeichnet ist!
Wie ich schon mehfach schrieb, erachte ich es als sinnvoll, über "radix dec" als "Default"-Zahlensystem das Dezimalsystem zu nehmen, weil es für uns das gebräuchliche System ist.

Grüße,

Thomas

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »Ottili« (31. Oktober 2008, 12:26)


ro.heg

RCLine User

Wohnort: Quickborn

  • Nachricht senden

54

Mittwoch, 5. November 2008, 10:11

Hallo Thomas und Claus,
es ist geschafft, d.h. ich bin am Ziel!
Wenn man bedenkt, es muß ca. Juni 2008 gewesen sein, daß ich erste
Kontakte zu Euch bekam.
Die Idee, einen Ortungspieper mit einem PIC16F627 zu erstellen, habe ich
besonders Thomas zu verdanken, daß es zum Erfolg kam. Mit den Minuten-
Schleifen hätte ich auf den Schlauch gestanden.
Einige Feinheiten und Korrekturen mußte ich noch ausführen.
Die 20 Minuten Konstante von 1200 mußte ich auf 1300 erhöhen, um zur
gemessenen Zeit von 1184 Sek. zu kommen.
30 Minuten von 1800 auf 1950 (gemessen = 1775 Sek.)
40 Minuten von 2400 auf 2600 (gemessen = 2367 Sek.)
Ich vermute, daß es mit den internen Quarz zusammen hängt.
Die paar Sek. Differenz sind aber nicht von Wichtigkeit.
Habe bei Reichelt Material bestellt und dann kann das löten losgehen.
Mit einem Befehl in den Zeitschleifen fehlt mir der Sinn des Ganzen!
Er kann nur aus den Vorschlägen von Thomas stammen.
Werde es im Thread "Fragen zu den Befehlen" einbringen.
Ich muß erst mal üben, wie ich aus pic12f_01.asm eine Zip-Datei mache,
und vor allem, wie ich die bei RC-Line hinein bekommen.
Weis auch nicht, wie Ihr immer die Rückantwortblasen macht.
Also, ich weiß in meinem Alter von 73 Jahren vieles noch nicht!
Ich bedanke mich vielmals bei Euch für Eure Hilfe und Geduld und den
Hinweis "mit den Datenblatt"!

Viele Grüße

Rolf

P.S. hier läuft eine umfangreiche Modellbau Eisenbahnanlage (FleischmannH0)
voll über einen alten ATARI mit GFA-Basic programmiert.
Das Interface wurde in Handarbeit selbst erstellt. Und träume davon, einen
Märklinkrahn mit einem PIC16xx zum Leben zu erwecken.
Zur Zeit läuft er mit einem Motorola Baustein, programmiert mit einer
graphischen Software.

55

Mittwoch, 5. November 2008, 11:55

Halo Rolf,

Zitat

Original von ro.heg
Hallo Thomas und Claus,
es ist geschafft, d.h. ich bin am Ziel!

gratuliere! :)

wow - Respekt, daß Du auch mit 73 weiter bereit bist, quasi die "Schulbank zu drücken" und Dich mit neuen Sachen zu beschäftigen! Vor dem Hintergrund verstehe ich jetzt auch besser, warum Du mit dem englischen so zu kämpfen hast: Englisch in der Schule zu lernen war wohl in Deiner Generation nicht so selbstverständlich wie heute.

Zitat


Ich muß erst mal üben, wie ich aus pic12f_01.asm eine Zip-Datei mache,
und vor allem, wie ich die bei RC-Line hinein bekommen.

dafür benutze ich schon seit vielen Jahren das Programm "Filzip"
(www.filzip.de)
Wenn Du das auf Deinem PC installiert hast, hast Du im Menü, wenn Du mit der rechten Maustaste auf eine Datei klickst, einen extra Menüpunkt "Filzip" zum Verpacken und Entpacken der Datei.
Wenn Du dann die fertige ZIP-Datei an den Beitrag anhängen willst, klickst Du beim Schreiben Deines Beitrags weiter unten bei "Dateianhang:" auf [bearbeiten...] und suchst die Datei auf Deiner Festplatte, dann [Speichern].

Zitat


Weis auch nicht, wie Ihr immer die Rückantwortblasen macht.

Das geht über "[ quote]" (aber ohne Leerzeichen vor dem q!) und [/quote]
"quote" = englisch "Zitat"
Also:
[ quote]
Dies ist ein Zitat
[/quote]
erscheint als:

Zitat


Dies ist ein Zitat

Weitere "BBCodes" sind hier beschrieben: http://www.rclineforum.de/forum/misc.php?sid=&action=bbcode

Zitat


P.S. hier läuft eine umfangreiche Modellbau Eisenbahnanlage (FleischmannH0)
voll über einen alten ATARI mit GFA-Basic programmiert.
Das Interface wurde in Handarbeit selbst erstellt. Und träume davon, einen
Märklinkrahn mit einem PIC16xx zum Leben zu erwecken.
Zur Zeit läuft er mit einem Motorola Baustein, programmiert mit einer
graphischen Software.

nicht bloß träumen --- machen! ;)

Viele Grüße

Thomas

ro.heg

RCLine User

Wohnort: Quickborn

  • Nachricht senden

56

Freitag, 14. November 2008, 13:50

Hallo Thomas,
ich stehe wieder vor einem Problem!
5 St. 12F629 I/P habe ich programmiert, die Hardware auf 2 St. Lochraster
aufgebaut.
Beim Anlegen der Versorgung stellen sich des öfteren irrable Zustände ein.
Die Zustände sehen wie folgt aus: (alles reiner Zufall)

Der Anfangszustand sieht gut aus, d.h. der Pieper blinkt nach Betätigen
der Taste "Test".
oder: nach Betätigen der Taste Test tut sich garnichts, erst wenn ich Reset
drücke und danach Test beginnt der Pieper zu blinken.
oder: der Pieper bleibt sofort im Dauerton, nach Reset wieder Dauerton.
Das machen alle 5 Pic´s mit beiden Lochrasterpl.
In meinem Buch steht, daß der interne Reset-Impuls sehr kurz sei und
die volle Betriebsspann. verspätet an den MCLR-Pin anliegt.
Am Eingang der Versorg. habe ich einen Tantal 4,7yF/25V und 100nF direkt an Pin
1 nach 8.
Das Buch zeigt eine Schaltung mit 10K als Pull-Up u.100nF gegen GND.
Dann legt man noch von der Mitte einen 270R nach MCLR.
Mit den 16 Pics habe ich das nicht beobachtet, hatte allerdings einen 10 yF
im Einsatz.
Es kann doch nur etwas mit dem Reset zu tun haben, oder?

Viele Grüße

Rolf

P.S. habe mit dem LED Programm das Debuggen geübt, komme noch darauf
zurück!

57

Samstag, 15. November 2008, 03:17

Hallo Rolf,

ein (oder das?) Problem dürfte sein, daß Du GPIO nicht initialisierst. Nach einem Reset haben die Bits im GPIO-Register lt. Datenblatt einen undefinierten Zustand, oder im Klartext: wenn Du Reset drückst, behält der Ausgang für den Piepser den Status (an/aus) bei, den er bei Drücken der Reset-Taste gerade hatte. Du soltest also vor "begin" den Befehl "clrf GPIO" einfügen, damit der Piepser zunächst ausgeschaltet ist.

Grüße,

Thomas

ro.heg

RCLine User

Wohnort: Quickborn

  • Nachricht senden

58

Sonntag, 16. November 2008, 09:44

Hallo Thomas,
danke für Deine Hilfe, jetzt verhält sich der Beginn, wie ich es gewohnt war.
Habe natürlich das Datenblatt Tabelle 2-1: heraus geholt,
wo auf Adresse 05h GPIO xx xxxx zu sehen sind.
Bei meinen erst erstellten mit den 16F627 hatte ich zu Beginn
clfr PORTA und PORTB vorgegeben, dadurch lief auch alles.
Wieder mit den xx xxxx dazu gelernt.
Aber wenn ich schon beim Datenblatt bin:
Das Register OPTION_REG setzt sich auf 1111 1111
Beim Debuggen Deines LED programms steht der Wert 0111 1111 in diesen Register, nach dem Schritt "bcf OPTION_REG,7.
(werden mit der ,7 = Bit ausgewählt und gelöscht)?
Deshalb der Kommentar GPPU - Bit auf Null setzen.
Habe bei mir das auch so übernommen, da ich mit diesen Register sowieso
noch nichts anfangen kann. Will auch nicht zu sehr in die Tiefe gehen.

Ein erstes Modul ist in einer Sukhoi 29/30E von der Fa. SebArt eingesetzt,
hoffentlich brauch es keinen Alarm zu geben.

Viele Grüße

Rolf

59

Sonntag, 16. November 2008, 12:16

Hallo Rolf,

Zitat

Original von ro.heg
Das Register OPTION_REG setzt sich auf 1111 1111
Beim Debuggen Deines LED programms steht der Wert 0111 1111 in diesen Register, nach dem Schritt "bcf OPTION_REG,7.
(werden mit der ,7 = Bit ausgewählt und gelöscht)?

genau so ist es - die Befehle "bcf" (bit clear f) und "bsf" (bit set f) dienen zum Setzen bzw. Löschen eines einzelnen Bits, dessen Bitnummer (0..7) angegeben wird.

Grüße,

Thomas

ro.heg

RCLine User

Wohnort: Quickborn

  • Nachricht senden

60

Mittwoch, 19. November 2008, 11:58

Hallo Thomas,
es gibt noch ein Miniproblem, evtl. auch für Dich interessant.
Die Anweisung "clrf GPIO" sorgt grundsätzlich dafür, daß der Pieper bei
Anlegen der Versorgung nicht anläuft.
Aber: Wenn ich Ubatt abnehme u. nach kurzer Zeit (ca. 15 Sek.) wieder
anlege, kommt es vor, daß bei Betätigen der Taste "Test" (GP1 auf LOW)
der Pieper nicht anläuft.
Dabei zeigen die Eingänge GP4 und GP5 ca. 0,8 Volt, dagegen GP1 und GP7
volle Ubatt. Entlade ich vorerst den Tantal 4,7yF am Eingang, ist die Welt in
Ordnung, d.h. alle GPx Eingänge zeigen 5 Volt
Im Quelltext steht
movlw B'110011'
movwf WPU ;damit habe ich doch die PULL-UP Widerstände an GP0, 1, 4 und 5
richtig vorbereitet!
GP2 = Output
GP3 = Reset
Ich glaube aber beinah, damit kann ich leben.

Viele Grüße

Rolf