Beiträge von Empirelord

Öh, ja. ich werde demnächst mal Bilder posten, aber mehr als ein Steckbrett und ein gutes Multimeter habe ich hier auch nicht.
Mein Problem ist im Moment eher, dass ich höllisch viele Wackelkontackte habe, was zu ätzender Frickelei führt.
Ich habe zwar mal ein wenig c programmiert(~1000 Zeilen), aber bei µC ist mir das auch ein Buch mit 7 Siegeln. Also halte ich mich an den Assemblercode und betreibe Learning by Doing.
Allerdings mache ich zur Zeit mein Abi und habe somit tonnenweise Zeit(von der nächsten Woche mal abgesehen).

Pesi:
Zwischen der RC5+... und TinyControl Version gibt es eine Änderung in der Wait.inc Datei, und zwar wird temp0 statt 50 nun 10 zugewiesen. Das sollte ja eigentlich die Zeit ändern, die die Funktion braucht. (Welches ist nun richtig?)

Habe nochmal ins Datenblatt geschaut, und in der aktuellen Version sollte es auf dem Tiny45 nicht laufen, weil der Timer keine 16, sondern nur 8 Bit hat. Es gibt aber natürlich einen einfachen Workaround: Ein Register zum Zählen abstellen und nur jeden 2^8=256 Takt die Routine wirklich durchlaufen. Wird dann auch noch implementiert...

Edit: Wie es scheint, habe ich den code noch nicht verinnerlicht. In der Ursprungsversion läuft das ganze ja auch im 8Bit Timer... Ich werde jetzt erstmal probieren, meine Testumgebung zum Laufen zu kriegen, das lohnt sich ja sonst nicht.

MfG Empirelord

Also...
Die Version, die ich hier als Tiny45 schon hochgeladen habe, sollte, wenn man die Flags richtig setzt, auch ohne Kristall funktionieren, wenn sie überhaupt funktioniert.
Ich habe jetzt die letzten Stunden damit verbracht zu probieren Pesi's Idee von einem Taster zu implementieren. Ich werden jetzt erstmal was essen und dann testen, also stay tuned.
Das ganze hält mich natürlich effektiv von der "Restrukturierung" ab, ab dafür kann ich dann gleich die neuen Sachen einbringen.

Edit: wurde von bioshock infinite aufgehalten, updates morgen.

Edit2: Ich kann hier ja wunderbar viel Code schreiben, aber das hilft nicht viel, wenn mein Entwicklerboard streickt.
Kurzversion: Es läuft nicht so gut/schnell wie geplant, aber es ist ja auch kein Projekt, welches besonders dringend wäre, oder?

MfG Empirelord

Ich bin nochmal in das Datenblatt des Tiny45 gegangen, und wie es scheint, hat der auch eine interne 16MHz-Taktquelle. Damit wäre der Quarz obsolet und das ganze sollte mit nur minimalen Änderungen laufen.
(Ich werde das morgen dann kurz machen)

Pesi:
Ich würde definitiv sagen, dass es ein geringerer Aufwand ist, sich seine eigene Version zusammenzubasteln, wenn man nur Werte setzten muss und alles dann per .ifdef läuft, allerdings wird der Code dadurch natürlich auch lang und ugly.
Ich habe im Moment einiges an Zeit und auch Lust AVR zu lernen, wenn du also die Zeit finden solltest deine neuesten Versionen mit den features hochzuladen würde ich da durchgehen und das zu einem Projekt verbacken.

MfG Empirelord

Hi, freut mich ja zu sehen, dass es noch mehr Leute gibt, die das Nutzen. (sehr schöne Arbeit übrigens)
Der Hauptentwickler hier ist ja Pesi, ich bin ja nur dabei die Software anzupassen. Insofern weiß ich nicht, was er in der Richtung 45 gemacht hat.
Aufgrund des "schrecklicken" Versionsmanagements der Software bin ich gerade dabei, dass unter anderem mit .ifdef umzuschreiben und könnte somit eine 45-Version morgen/übermorgen fertig haben.
(Mehr dazu, wenn ich soweit bin Bugs zu suchen)

Edit: Ich habe jetzt doch einfach schnell aus der TinyControl-Version eine 45-Version zusammengehackt. (Leider musste die Status LED dran glauben)
Ich habe keinen 45 hier um das ganze zu testen, aber prinzipiell sollte es mit Rot(PB0), Grün(PB1) und Blau(PB2), sowie einem 16MHz-Quarz an PB3-PB4 und rc-empfänger an PB5 klappen.
Netter Nebeneffekt: Die Software ist wieder so klein, dass sie auch in den Attiny25 passen sollte. (Source + hex sind im Anhang)

Edit2: Der DMX-Kanal ist logischerweise rausgefallen, so dass auf Programm 0 nun Gewitter liegt und es nur noch 6 Programm sind.

MfG Empirelord

@define: Stimmt. Ich habe da auch völlig übersehen, dass es diese Definition schon gibt, nämlich PGM_COUNT. Ist in meinem Fall nur 6, weil DMX rausfällt.

Zero: Ja, das habe ich explizit gesetzt, in der Configuration.inc

Stimmt, diese Macken hat die neue Dimmerkorrektur-Funktion dann leider, naja, werde mir das heute Nachmittag nochmal angucken. Im Moment habe ich aber auch noch genug Speicher um die Tabelle drin zu haben.

Zu der Baumarktfunktion: Die grundsätzliche Idee hierbei war, dass man die Operation die auf die daten ausgeführt wird nicht mehr 3-mal drinhatt und per Bedingung auswählt, welche man ausführt, sondern durch ein bisschen Pointer-Arithmetik die Adresse abhängig vom aktuellen Fade gesetzt wird und man dann die Datenoperation entsprechend nur noch 1-mal drinhatt. Ich bin mir aber leider nicht sicher, ob das ganze so noch funktioniert. Außerdem habe ich (um noch ein paar Bytes rauszupressen) die rjmp/br** _Baumarkt_Ende Konstrukte durch entsprechende direkte Sprungbefehle nach _RGB_Output ersetzt, aber das ist ja eine Kleinigkeit. Weil der Beitrag wundeschön lang werden würde, wenn ich das einfach so reinposte, habe ich es in den Anhang getan.

Bezüglich _Key_Select: Das habe ich ganz übersehen, dass man das ja auch explizit setzen kann. Danke, nochmal 10Byte weniger.

Edit: Eine andere Stelle, wo ich nochmal ein paar Byte herausholen konnte war bei _pgm_select, und zwar indem ich eine Sprungtabelle verwendet habe. Wie bei meinem restlichen Code gilt auch hier: Ich weiß nicht, ob es funktioniert, aber hier ist der code (zero ist das nicht benutzte R27-DMX register, im ganzen Programm auf 0 gesetzt, sparrt ein paar Byte):

_pgm_select:


		cpi		temp0,6						; teste ob zu groß
		brlo	_main						; wenn ja, weg hier
		ldi		ZL, low(_j_table)			; setze Adresse
		ldi		ZH, high(_j_table)
		add		ZL,temp0					; addiere die entsprechende Position
		adc		ZH,zero						; überlauf
		push	ZL							; ablegen
		push	ZH
		ret									; und da hin springen


_j_table:
		rjmp	_Lightning
		rjmp	_Fixed_Colour
		rjmp	_Baumarkt
		rjmp	_Blob
		rjmp	_Fire
		rjmp	_Random_Fade

So, ich habe jetzt mal den Nachmittag damit verbracht zu probieren, eine Version mit LCD, allen Programmen, aber ohne DMX und DIP zusammenzustellen. Natürlich sind die 2048Byte dabei eine sehr interessante Herausforderung. Hier einige Ideen und Fragen dazu:
In der Dimmerkorrektur-Funktion. Ich weiß nicht, wie die Werte ausgewählt wurden, aber die sind verdammt nah an x²/4 dran. Könnte man dann icht auch kürzer diesen Code verwenden:

_Dimmerkorrektur:


		mov		temp0,temp1				;a=b
		rcall	_Multiply				;a*b=a²
		rol		Mathe_H					;Mathe>>2, bzw. a²:=.25a²
		rol		Mathe_L
		rol		Mathe_H
		rol		Mathe_L
		mov		temp1,Mathe_L			;und zurückgeben.


		ret

Zu der Baumarkt Funktion brauche ich glaube nicht viel zu sagen... Wiederholungen pur. Ich habe da im Moment etwas extrem unhübsches zusammengehackt, aber hey 80Byte.(Habe aber noch eine bessere Idee, deshalb hier noch kein Code).
In der Keyselect-Funktion kann man die Zahlen-Keys auch durch eine viel kürzere Schleife erfassen.
Ich baue im Moment auf der TinyControlStandard2313-Version auf, wofür ist die Status-LED da?

MfG Empirelord

Zitat

Naja, diese Vermutung gab es doch schon mal im Dezember ...

Jup, wollte das nur bestätigen.

Zitat

Vielleicht könntest Du die Schaltung + Firmware für die Eigenbau-Fernbedienung auch hier vorstellen?

Ich war unkreativ und habe einfach ein anderes Projekt aus dem Internet nachgebaut. Das interessante ist, mit wie wenig externen Teilen man dort auskommt. Das ganze ist in C geschrieben und braucht entsprechend auch 460Byte auf dem Attiny2313, aber nagut, man hat's ja.

Hallo, ich bin's nochmal. Nachdem es ja hier wieder still geworden ist, ein paar gute Nachrichten von meiner Seite:
Ich habe den Fehler in meiner Schaltung gefunden! Es war ganz trivial einfach nur, dass ich keine RC5-Fernbedienung hatte. Ich habe jetzt mit einem 2.ten attiny2313 eine RC5-Fernbedienung gebastelt und es geht. In den nächsten Wochen werde ich also mein LED-Projekt dann doch wieder weitertreiben und alles interessante posten.

Vielen Dank für die Unteerstützung hier übrigens, ohne euch hätte ich das nie so lange durchgezogen.

MfG Empirelord

Ich habe für meine Software-Debugging-Versuche einfach ganz banal deine LCD_Number Routine aufgerufen mit entsprechend eindeutigen Nummern, also an den entsprechenden Stellen im Programm halt die dafür nötigen 3 Zeilen eingefügt.
Die bereits fertig mitgelieferte Software funktioniert bei mir wenn ich sie einfach nur flashe auch nicht mir IR-Empfang, es wird allerdings GROESSENWAAHN angezeigt. (Das legt ja schon nahe, dass nicht direkt ein Software-Fehler ist)
Aber vielen Dank erst einmal für die Tipps, ich werde morgen dann noch einmal die Banalitäteten durchtesten und melde mich dann wieder.

Der IR-Empfang funktioniert bei mir leider immer noch nicht, deshalb wende ich mich einfach nochmal an die Großmeister:
Meine Softwaredebugging-Versuche haben ergeben, dass der Controller die ganze Zeit nach einem Timeout-Fehler in _rc5_overrun landet. Ich habe (2x) die Pinbelegung des IR-Empfängers getestet und die Flags sind eigentlich auch richtig aufvlfuse:0xff hfuse:0xdf efuse:0xff gesetzt.
Mir gehen langsam die Ideen aus, was ich noch machen könnte. Eine Beobachtung war, dass der IR-Empfänger die ganze Zeit 5 V liefert und bei Signalen 0V, ist hier eventuell ein Unterschied zum Original-Controller?
Oder müssen vielleicht Änderungen an den Timings vorgenommen werden?
Wie gesagt, jegliche Hilfe wird gerne in Empfang genommen.

Vielen Dank erstmal für die Erklärung.
Ich werde wahrscheinlich keinen "neuen" Code einbringen, aber dank des modularen Aufbaus ist es ja sehr einfach ihn auf die eigenen Bedürfnisse anzupassen, sprich in meinem Fall kein DMX, mit Display ,Fernbedienungstasten und möglichst viele Programme.
Wenn ich allerdings mein Projekt einigermaßen fertiggestellt habe werde ich natürlich die Daten dafür veröffentlichen.
Im Moment habe ich bloß den IR-Empfang noch nicht zum Laufen gekriegt, Display geht allerdings bereits. Was macht man also -> Debugging mit "Kommandozeilenausgabe". Keine Angst, wenn ich da nicht weiterkomme frage ich hier wieder.

Als ich im Internet über diese Software gestolpert bin, fand ich die Idee sehr interessant und gut umgesetzt und so entschied ich mich dies nach zubauen. Dies ist mein erstes Projekt mit µC und AVR-Assembler (habe schon x86-Erfahrung), ich habe probiert mir möglichst viel zu dem Thema anzulesen, aber es könnte nichtsdestotrotz seien, dass ich einige Anfängerfragen stellen muss. Ich hoffe trotzdem, dass insbesondere Pesi mit bei einigen Fragen/Probleme die sich beim Nachbauen für mich auftaten helfen könnte:
1. In dem Quellcode gibt es die _rc5_receiver-"Funktion", diese wird aus _ISR_Timer0OVF aufgerufen, sobald das Programm aber erst einmal in der Hauptschleife angekommen ist findet allerdings kein Aufruf mehr von einer dieser beiden Funktionen statt, soweit ich das erkennen kann. Insofern frage ich mich, was ich hier übersehe, denn das Programm kann ja eigentlich auch in der Hauptschleife noch RC5 empfangen.
2. Ich konnte den SFH5110-Empfänger nicht mehr finden und habe den im Thread zuerst erwähnten TSOP31236 (was ist der ) als Ersatz genommen. Funktioniert dieser "Out-of-the-Box" oder muss dafür die Software modifiziert werden?
3. Wenn man kein DMX verwenden möchte, dann reicht es dies nicht zu bestücken und in der Software komplett auszukommentieren, oder macht man damit etwas anderes kaputt?
4. In RC5_Receiver.inc wird gesagt, dass die Zeiten für 8MHz angepasst wären, es wird allerdings ein 16MHz Quartz verwendet. Wird dies auch softwareseitig gelöst oder was ist hier der Trick?
5. Wenn man die Ausgänge beim Testen nicht bestückt sollte das auch keine Probleme verursachen, denn es sind ja nur Ausgänge, oder?

MfG Empirelord