Die "Weihnachts"-PIC16F84 Frage

[Shunth]

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

[the_Ghost666]

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.

[thewulf00]

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.

[the_Ghost666]

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

[s.o.]

Ich kenne mich jetzt nicht so mit PICs aus (Seit wann gibt es denn Weihnachstschweine ), 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.

[the_Ghost666]

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)

[Shunth]

@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.

[the_Ghost666]

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.