Peter Dannegger schrieb: > Hier ist eine 8*12Bit BAM: > Beitrag "AVR: Fast-PWM (BAM) 12 Bit für 8 Kanäle" > > Die könnte man auf 24 Kanäle aufbohren. > Das ergebe dann 8MHz 4096 3 = 650Hz. > Und dann 7 * multiplexen ergibt 93Hz. > Bei 16MHz CPU-Takt sind 186Hz drin. > Und wenn man den Interrupt etwas aufwendiger programmiert, sollte der > Teiler /3 auch wegfallen können, also max 560Hz Bildfrequenz. habe das ganze probiert mit einem mega32 und bin soweit gekommen Folgendes Problem: ich hab bei einem testlauf bemerkt, dass ich wenn ich nur die zweite anodenreihe leuchten lassen will (PD2-low und entsprechende farben an PortA,B,C anlege) leuchtet mir die dritte also die darauffolgende auch mit(mit der gleichen farbe), obwohl ich das nicht will. habe schon alles gecheckt und weiss nicht mehr weiter. es muss an der ISR liegen, hardware mäßig ist alles in ordnung video zur matrix: https://www.youtube.com/watch?v=M6GuzfsicnE
Da kannst du schon bumpen. Wenn ich das Zip anklicke, teilt mir der Entzipper mit, dass das Zip-File ungültig ist.
Da man aber in deinem Video sehen kann, dass * wenn Zeile 2 angesteuert wird, Zeile 3 mitleuchtet * wenn Zeile 3 angesteuert wird, diese nur mit halber Kraft leuchtet würde ich aus der Ferne mal schätzen, dass du irgendwo einen Kurzschluss zwischen den Steuerleitungen für Zeile 2 und Zeile 3 hast.
Karl Heinz schrieb: > würde ich aus der Ferne mal schätzen, dass du irgendwo einen Kurzschluss > zwischen den Steuerleitungen für Zeile 2 und Zeile 3 hast. habe ich schon ausgeschlossen indem ich die zeilen einzeln OHNE ISR angesteuert habe. die steuerleitungen sind ok. hab jetzt den code ungepackt angehängt, es liegt sicher an der ISR.
:
Bearbeitet durch User
Richard __ schrieb: > hab jetzt den code ungepackt angehängt, es liegt sicher an der ISR. Das erste was ich tun würde: Diese ganzen Assembler Quark über Bord werfen und das ganze ordentlich in C schreiben. Im ersten Anlauf durchaus auch ohne BAM Das ganze ist in C nicht mehr als vielleicht 10 bis 15 Zeilen Code.
Karl Heinz schrieb: > Diese ganzen Assembler Quark über Bord werfen und das ganze ordentlich > in C schreiben. Na ja, für Bit 0 im bit angle hat er nur 3 Taktzyklen Zeit, das bekommt er nur mit vorab-Laden der Register (hier r13-r21) hin und wird ein C-Compiler nie so machen. lds r13, BAM_data_red0 lds r14, BAM_data_green0 lds r15, BAM_data_blue0 lds r17, BAM_data_red0+1 lds r18, BAM_data_green0+1 lds r19, BAM_data_blue0+1 lds r20, BAM_data_red0+2 lds r21, BAM_data_green0+2 ... out _SFR_IO_ADDR(BAM_PORT_RED), r13 ;start out _SFR_IO_ADDR(BAM_PORT_GREEN), r14 out _SFR_IO_ADDR(BAM_PORT_BLUE), r15 out _SFR_IO_ADDR(BAM_PORT_RED), r17 ;3 cycles later out _SFR_IO_ADDR(BAM_PORT_GREEN), r18 out _SFR_IO_ADDR(BAM_PORT_BLUE), r19 lds r22, BAM_data_blue0+2 nop out _SFR_IO_ADDR(BAM_PORT_RED), r20 ;6 cycles later out _SFR_IO_ADDR(BAM_PORT_GREEN), r21 out _SFR_IO_ADDR(BAM_PORT_BLUE), r22 Aber der Code ist natürlich absolut grausam blöde geschrieben in dem man Scanzeile 0..6 in mehrfach kopierten Code dupliziert an statt zu indizieren, dann die sehr merkwürdig aufwändige Art die Bits 9-12 zu erfassen, man hat da so viel Zeit, daß es wirklich in C geht und mit Indexvariablen. > hardware mäßig ist alles in Ordnung Tja, oder auch nicht. Passiert das mit 2. und 3. Zeile bei jeder Farbe oder nur bei Grün ? Da rot/grün/blau im Code so deutlich getrennt sind, spricht ein identisches Verhalten bei den Farben doch für ein Hardwareproblem (oder kopierten falschen Code, aber wer will die tausenden von Zeilen für so eine primitive Multiplexsteuerung schon überblicken ob do irgendwo ein Bit nicht stimmt ?). Kann es nicht sein, daß PD2 und PD3 fehlerhaft initialisiert sind (Special Function).
MaWin schrieb: > Aber der Code ist natürlich absolut grausam blöde geschrieben tja ich habe es nicht besser hinbekommen. MaWin schrieb: > in dem man > Scanzeile 0..6 in mehrfach kopierten Code dupliziert an statt zu > indizieren, wenn du mir helfen willst den code praktischer zu schreiben musst du mir das näher erklären habe mal aus spaß getestet wenn ich die zeilen weglasse (bit 9-12 OCR1B interrupt) ldi r17,0x3 out _SFR_IO_ADDR(OCR1BH),r17 ldi r17,0x02 out _SFR_IO_ADDR(OCR1BL),r17 passiert das nicht mit den zeilen.
Richard __ schrieb: > wenn du mir helfen willst den code praktischer zu schreiben musst du mir > das näher erklären Deinen Code wirst du schon selber schreiben müssen, ich habe so was vor 30 Jahren (mit rot/grün LEDs) gemacht. Der Assemblercode der schnellen bits muss so bleiben, aber nur EIN MAL. Der Interrupt Code der langsamen bits (könnte durchaus in C sein) zählt 0..15, bei 0 ruft er den schnellen Assemblercode auf, bei 1 gibt er bit 9 aus, bei 2 und 3 bit 10, bei 4-7 bit 11 und bei 8-15 bit 12. Bei 15 (weil da Zeit ist, meinethalben bei 8-15 aufgeteilt in Häppchen) bereitet er die Daten für den nächsten Assemblerdurchlauf auf, in dem er die benötigten Daten der nächsten scanline dort hin kopiert.
habe die ISR neu geschrieben und das mit der zeile ist in ordnung jetzt. an sich bin ich zufrieden. am code gibt es sicher noch verbesserungsmöglichkeiten. würde mich über vorschläge freuen.
So kann man es natürlich auch machen, indiziert statt umkopieren. Deutlich besser als vorher.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.