Die "Weihnachts"-PIC16F84 Frage

Hallo @all,
Weihnachtszeit-Lichterzeit! So ist es und so soll es sein. Jedes Jahr ärgere ich mich über die "Grottenschlechten" Fensterbilder. Ein grausames Gemisch von Blinkgeber Sternschnuppen und überdrehten Lichterketten. Also, als Elektroniker sage ich den Nachbarn den Kampf an!!!!!!!!
Mit unzähligen LED habe ich eine Weihnachtsglocke gelötet. (übrigens sehr gelungen!) Nun will ich dieser "Leben "einhauchen, indem ich das Glockenpendel zum "Schwingen" bringe. Kein Problem, ein Rechts-Links Lauflicht übernimmt die Aufgabe ohne Probleme. Es sieht absolut echt aus. Was ich vermisse ist das langsame "anschwingen" des Pendels,ein schneller werden und wieder ein "Ausschwingen" Ich dachte in mein Listing einfach noch ein Unterprogramm einzubinden das verschiedene Zeiten des Rechts-Linksschieben erlaubt. Aber wenn ich mit Return aus den UP springe geht er ja zu call und läuft UP wieder ab. Wie springe ich in ein zweites UP und wie springe ich geziehlt zurück????
Wer hat ne Idee???
(Hier das Programm von mir was so super geht)

So, mal sehen. Also ich hab gerade ein Problem bei deinem Code, ich sehe nur EIN Unterprogramm bzw dessen Aufruf, und das wäre CALL Wait.
Du möchtest ein Ausklingen machen? Ich baue mir immer Wait-Schleifen, die so lange, wie der Wert im Akku* Konstante in Milisekunden, wartet. Also ne einstellbare Wait-Schleife. Du könntest dann eine Aussenschleife machen, in der du den Wert hochzählst. Dh mit jedem Schleifendurchlauf steigt der Wert in W (oder auch einer vereinbarten Speicherzelle) und damit wird die Pauselänger, die Pendelfrequenz langsamer. Du kannst dann ab einem bestimmten Wert die Schleife beenden und hast dann dein Standbild.

Grobe Form in Pseudo Code
Schleifen Variablen Initialisieren
Anfang: Scheife prüfen (ist die Variable größer X, dann weiter sonst nach Ende: )
Pendel Link
Warte für X *Konstante sekunden (also movfw X, call Wait)
Pendel Rechts
Warte für X *Konstante sekunden (also movfw X, call Wait)
X=X+1;
Goto Anfang:
Ende: Fertig

Die Lösung, die Du suchst, ist im Prinzip der Ansatz von the_Ghost:

Irgendwo zählst Du ja eine Variable hoch/runter, der die Wartezeit zwischen zwei Frames (d.h. Bildern) steuert. Dieser Zählwert muss variieren. D.h. er muss während der Schwingung in Richtung Mitte ansteigen, und danach wieder abfallen.
Wenn Du einen Timer nutzt, dann ändere einfach den Timerzielwert. (Je nach Timermodus der End- oder Startwert)

Hi du hast doch da die warte schleife (wait) mach die doch am anfang bei jeden durchlauf nen pahr werte kleiner und irgentwan denn wieder etwas schneller damit haste den des anschwingen / auschwingen

@theborg: Danke, dass Du die Gedanken unserer Posts nochmal zusammengefasst hast.

Du musst die Geschwindigkeit wie einen Sinus gestalten. Ich hänge dir mal 2 Grafiken an, wie du es programmieren könntest.

Anmerkung: 0, %pi/2 = ganz außen %pi/4 = mitte

Es ist nicht nötig, einen Sinus zu programmieren. Das ist viel zu komplex. Eine simple, lineare Steigerung ist für ein subjektives Schwingen ausreichend. Beachte: Wieviele Bilder werden es insgesamt? 5? 7? 9? Viel mehr nicht.

Ja, braucht man nicht unbedingt, wenn es wenige sind, kann man auch ein Lookuptable verwenden....
Oder halt in ein Linear-workarrount... wobei ich auch denke, dass der unterschied nur minimal sein wird...

Hallo,
erstmal vielen Dank für eure Anregungen. Ich habe später selbst bemerkt das nur ein UP da ist, wie the_Ghost erkannt hat. Bin irgendwie mit goto und call durcheinander gekommen. Habe mir auch schon gedacht mittels dem TMR0 ein UP zu schreiben das einfach mal länger mal kürzer "zählt" Mal sehen ob ich dass so hinbekomme.

Auf jeden Fall DANKE an alle die mitgedacht haben!!!!

Zitat:

---

Zitat von s.o.

Ja, braucht man nicht unbedingt, wenn es wenige sind, kann man auch ein Lookuptable verwenden....
Oder halt in ein Linear-workarrount... wobei ich auch denke, dass der unterschied nur minimal sein wird...

---

Da hast Du vollkommen Recht. Eine Tabelle würde hier wohl allen Ansprüchen genügen, egal ob linear oder sinus.

.......dann klärt mich mal auf über die LOOKUPTABLE.......
Meint ihr, eine im internen EEPROM befindliche Tabelle, die dann abgefragt wird???

Also mit ner Lookup-Table macht man ja nichts anderes, als einen Wert einem anderen zuzuordnen. Die Tabelle geht dabei von x=1 bis n und du bekommst jeweils ein y(x) zurück. Ist also einfach nur eine Tabelle mit 2 Spalten.
Wie man sowas macht: Es gibt da verschiedene Möglichkeiten. Du kannst ne Lookup-Table in den RAM Schreiben, was den Vorteil hat, dass du die Tabelle einfach verändern und mit nem Pointer (INDF) abfragen kannst. Leider verbraucht das ne Menge Platz, weil du freie Zellen im RAM brauchst UND die Initialisierungswerte auch erstmal da reinschreiben musst, also Zusatzverbrauch von Programm-Memory. Möglichkeit 2 wäre die, die Tabelle im EEPROM abzulegen, und mit nem Unterprogramm auszulesen. Vorteil ist klar, du hast ne initialisierte Tabelle, verbrauchst kaum Programm-Memory und auch keine RAM-Zellen. Nur wenn das EEPROM anderweitig belegt wird, oder die Tabelle groß ist, sollte man an ne andere Variante denken.
Und die wohl einfachste: Möglichkeit 3: Du legst die Bytes im Programmspeicher als RETLW Befehle ab. Eine Anleitung dazu gibts bei Sprut.de ->
Segmente:
addwf PCL, f
retlw B'00011000' ; 0
retlw B'11011110' ; 1
retlw B'00110010' ; 2
retlw B'01010010' ; 3
retlw B'11010100' ; 4
retlw B'01010001' ; 5
retlw B'00010001' ; 6
retlw B'11011010' ; 7
retlw B'00010000' ; 8
retlw B'01010000' ; 9
Aufrufen tust du das mit movfw (lade den Wert X) Call Segmente.
Er kommt dann mit einem Wert in W zurück, der der Zuordnung von X entspricht.
Vorteil: Einfach, keine RAM-Zellen werden verschwendet.
Nachteil: PIC16er legen wegen ihrer internen 14bit Befehlsbreite solche Bytes unvorteilhaft ab. Man verschenkt einiges an Platz, aber meist ist der Programmspeicher größer als das EEPROM, also halb so schlimm. Wichtig ist noch, dass ein Problem auftauchen kann, wenn der ProgrammCounter, den du direkt manipulierst, an ner ungünstigen Stelle liegt. Siehe hier http://www.sprut.de/electronic/pic/f....html#tabellen
Es kann dann passieren, dass der Verweiß auf ne völlig falsche Stelle passiert ->Crash. Ist mir aber noch nie passiert.

Das könnte man z.B. nehmen. Es reicht aber auch eine Tabelle im Flash.
Es geht nur darum, die Werte, die in der Warteschleife genutzt werden sollen, im Voraus zu berechnen, damit sie nicht erst beim Benutzen errechnet werden müssen.
Der Vorteil hierbei ist, dass Du eine beliebig komplexe Funktion nutzen kannst, auch z.B. den Sinus, denn Du berechnest die Werte ja VORHER (z.B. am PC), so dass Du sie dann in die Tabelle einträgst und trotzdem z.B. ein Sinusschwingen hast.
Wobei bei diesem Beispiel - wie gesagt - die Unterschiede (vor allem subjektiv gesehen) zwischen einer linearen Beschleunigung zu einer Kurvenbeschleunigung so minimal sind, dass es nicht nötig ist, einen Sinus zu nutzen.

Hier ist noch eine Application Note von Microchip für Lookup-Tables
http://www.microchip.com/stellent/id...pnote=en011102

Zu finden unter der Bezeichnung AN556

Ich kenne mich jetzt nicht so mit PICs aus (Seit wann gibt es denn Weihnachstschweine :D ), Ich würde die Tabelle wenn es ein AVR wäre ins Flash legen. Dann mit lpm (load program memmory) laden. Der Pointer ist dabei deine aktuelle Position.

Leider haben die PIC16er keinen Pointer, der auf das Flash zugreifen kann, erst die PIC18er können auf den eigenen Flash zugreifen. Der Befehl fehlt einfach. (Sind halt nur 35 Befehle, 1 Pointer)

@the_Ghost

ich habe verstanden...... Das mit der Tabelle im EEPROM hatte ich vor langer Zeit mal probiert (auch von Sprut glaube war das damals als Lernbeispiel)
Dort wurde ein LED Muster in den Speicher gelegt der dann ausgelesen werden sollte. Das Problem seinerzeit war, dass ich, egal wie ich es versuchte, die Daten nicht in den Speicher bekam. Es lag wohl an meinen Brenner weil ist ein "ausgedienter" SER. PIC PROG 2 aus "Uraltzeiten" der Goldwafer-Smartcard :-( Der hat vorn zwei Sockel. Ein für 18 PIN PIC und ein für 8 PIN EEPROM. Ich glaube es lag irgendwie am brennen mit dem Teil (kann aber auch sein ich war zu doof!!!) Auf jeden Fall hat der gebrannt und am Ende habe ich ausgelesen und es war immer der EEPROM leer. Normal geht der gut. (meine die HEX bekomme ich immer "rein" und lüppt. ???!!!)

.....ach und auf die Frage PIC. Ich will demnächst umsteigen auf eventuell AVR. Für mein Projekt hatte ich eben den 16f84 da und sollte reichen. Für AVR: Was ist zu empfehlen??? Brenner, Testboard???? Also ich bevorzuge Assembler und nutze mehr LED und Display-Steuerungen. Bischen PWM für Modellbau.

Mh ob das am Brenner liegt kann ich so nicht sagen, ich habs ein paar mal gemacht und auch ohne Probleme geschafft (Brenner5 von Sprut, danach original Microchip ICD2).
Also Leistungstechnisch reichen die Pics für die beschriebenen Anwendungen immernoch völlig. Auch mit den PIC18 hast du mächtige Controller, mit sogar einigem Schnickschnack, den die AVRs nicht haben, z.b. 12Bit ADC (die meisten AVRs haben 10bit), Ethernet, CAN, USB Hardwaremodule.

Wenn du unbedingt umsteigen willst, dann fang mit nem ATmega88 oder ATmega8 an.*in Deckung spring vor steinewerfenden Pic-Fanatikern,wie ich früher einer war*
Der Mega88 ist neuer und bietet coole Features, die der Mega8 noch nicht hatte. Der Assembler bei den Atmels hat 115 Befehle, 3 Pointer usw. ist also echt umfangreich, das hat Vor- und Nachteile. Ich brauchte immer die Befehlsliste auf dem Schreibtisch, bis ich zu C übergegangen bin.
Als Brenner hab ich von meiner Praxissemster-Firma n original Atmel ISP MkII bekommen und bin damit hoch zufrieden. Es gibt aber billigere Selbstbaubrenner, der Vorteil ist, dass das Ding permanent supportet wird und perfekt in AVRstudio passt. Ausserdem hast du n USB Anschluss, parallele und seriellen Schnittstellen hab ich keine mehr.
Testboards wüsste ich keine, Ich bau und ätz alles selbst. Aber ein Steckbrett ist für nicht-SMD ne gute Wahl, weil es kaum flexibler geht.