ZitierenHab zwar eigentlich keine Anwendung, lese aber den Thread schon ne Weile mit. Mich würde die IRQ-Version durchaus interessieren. Also antworte ich mal mit : "Ja".
Interesse an einer Interrupt-getriebenen Version ?
Hab zwar eigentlich keine Anwendung, lese aber den Thread schon ne Weile mit. Mich würde die IRQ-Version durchaus interessieren. Also antworte ich mal mit : "Ja".
Grüße,
Daniel
Da geht's mir nicht besser, hab' nicht mal ein Display. Bei Pollin gibt's die auch nicht mehr, außer einem Modell das aber komplizierter bei der Spannungsversorgung ist.Zitat von ePyx
Ich simuliere den Code immer, aus beschriebenen Grund kann ich's nicht am lebenden Objekt testen. Kann also sein, dass noch ein Wurm drin ist, tatsächlich wissen wir's wenn MisterMou es am Laufen hatte.Mich würde die IRQ-Version durchaus interessieren. Also antworte ich mal mit : "Ja".
Naja hab auch kein Display, daher auch keine Anwendung. Aber Interesse kann man ja haben.Dabei kann man nur Lernen.
PS : Das du das ohne Hardware und Anwendung durch simulierst bzw. dir generell den Aufwand machst, ist im Übrigen hoch anzurechnen. Zumindest ich mach das.
Grüße,
Daniel
Ja, klar.
Danke, ganz uneigennützig bin ich aber auch nicht, das mach' ich gern wenn ich's als Knobelaufgabe betrachte....dir generell den Aufwand machst, ist im Übrigen hoch anzurechnen.
Das Schreiben von Assembler in 'ner separate .S-Datei ist im Übrigen um Einiges angenehmer als Inline ASM.
Hatte noch 'ne andere ISR Version gebaut, bei der immer pro ISR-Aufruf eine komplette der 20 Zeilen ausgegeben wurde, die war noch schneller und hätte es auf maximal 115Hz gebracht. Aber sie hätte die Programmausführung recht lange unterbrochen und damit wäre das für UART-Kommunikation ein Problem gewesen.
Die angehängte Version gibt immer nur eine Scanzeile von 12 aus, hat deswegen mehr Overhead und schafft's auf max 103Hz.
Geändert von MagicWSmoke (25.04.2012 um 10:31 Uhr)
Das ist aber sehr schlimm.
Kann ich mir gut vorstellen. Bisher hab ich mich noch nicht wirklich damit auseinandersetzen müssen. Entweder waren die Sachen in C oder in ASM lösbar. Mischen bzw. Optimieren musste ich da bisher nicht allzu viel. Daher ist halt auch interessant.
Grüße,
Daniel
Soo,
endlich hatte ich mal wieder etwas Zeit...
Inzwischen nutze ich ein anderes Display, bei dem "M" manuell geschaltet werden muss. Das heißt, jedes Frame wechselt M zwischen high und low. (1.Frame high | 2.Frame low | ...)
Das Display flimmert weniger bei niedrigen Frequenzen. Es lässt sich bei 57Hz problemlos betreiben, das andere musste mit mindestens 70Hz gefahren werden.
Außerdem besitzt dieses eine LED Hintergrundbeleuchtung. Allerdings steigt die Kontrastspannung von -18V auf +23V, aber für mein Labornetzteil ist das kein Problem.
Der Kontrast ist auch etwas schlechter.
Der große Bonus ist der Touchscreen
Sonst bleibt alles beim Alten.
Zur Zeit habe ich Probleme, dass die Schrift nicht sauber gezeichnet wird. Einige Pixel sind an der falschen Stelle, aber bei dem selben Zeichen immer wieder gleich falsch. Das sieht so aus als würde das Array falsch gespeichert werden.
Und dann passt auch mal wieder alles, einfach so. Ich gebe aber meinem Rechner die Schuld, der ist zur Zeit etwas zickig.
Die IRQ Sache ist ne tolle Idee, aber Timer0 unterstützt doch gar keinen Compare-Interrupt, sondern nur einen Overflow-Interrupt.
Ich sage auch mal "Ja"
edit: Der Rechner ist es nicht, mein großer ist der selben Meinung O.o
Geändert von MisterMou (29.04.2012 um 19:58 Uhr)
Irgendwie bin ich da auf den Mega16 gekommenDie IRQ Sache ist ne tolle Idee, aber Timer0 unterstützt doch gar keinen Compare-Interrupt, sondern nur einen Overflow-Interrupt.
Ich sage auch mal "Ja"
Lässt sich aber einfach auf Preload des Timers umbauen, werd's morgen mal ändern und dann einstellen.
Anbei die geänderte Version für den ATMega8, bei dem nun Timer0 vorgeladen wird.
Es handelt sich aber noch um ungetesteten Code für das ursprüngliche Display, sollte also erst getestet werden ob's auf dem überhaupt hinhaut, sowohl von der prinzipiellen Code-Funktion, als auch mit der Ausgabe jeweils 1 Linie pro ISR-Aufruf.
Sobald das dort läuft, kannst Du die Änderung
selbst in der .S vornehmen, oder C-Beispielcode einstellen, dann schau' ich's mir an.jedes Frame wechselt M zwischen high und low. (1.Frame high | 2.Frame low | ...)
Leider musste meine Kalkulation für den Zähler-Topwert über das #define in der .h über Bord gehen. Der GCC hatte kein Problem damit, aber der GNU Assembler war nicht dazu zu bewegen die Rechnung aufzulösen.
top_val muss also nun selbst ausgerechnet werden, ist für 75Hz bereits erledigt, bei dieser Wiederholrate sind noch ungefähr 27% der Prozessorleistung für anderen Code verfügbar.
Danke für die ganze Arbeit.
Inzwischen überfordert mich Dein Code komplett
Er funktioniert trotzdem tadellos.
Er lässt sich auch am neuen Display testen, allerdings verblasst das Bild nach ein paar Sekunden, daran ist aber M schuld.
Soweit ich das mitbekommen hab, ändert M die Polarität der Kristalle und hält so den Kontrast aufrecht, deswegen der ständige Wechsel.
Die Ansteuerung ist sehr einfach. Nach jedem Frame wird gewechselt.
Ich habe dafür noch den übrigen Port genommen um den original Code nicht ändern zu müssen. M hängt an Pin D0.Code:PORTD=~PORTD;
Meine Pixelfehler waren ein gelegentlicher Kurzschluss zwischen D1 und D2...
Berechtigungen
Lesezeichen