seppoman Posted December 16, 2003 Report Share Posted December 16, 2003 Hallo,ich habe letzte Woche erst dieses Projekt entdeckt und nach einer Website-Schmöker-Nacht beschlossen, mir eine MidiBox SID zu bauen. Jetzt habe ich mir folgendes Display ersteigert:http://cgi.ebay.de/ws/eBayISAPI.dll?ViewItem&item=3064807223Das ist ein Futaba 2x40 VFD Display, für 21 Euro (sind übrigens noch 20 Stück verfügbar :-)Ich will das Gerät per "C64 PSU optimized" versorgen. - Da ein VFD wohl bis zu 500 mA braucht, soll ich das Display dann über den regulären Anschluß versorgen, oder lieber direkt vom 64er Netzteil? Nachdem der 7805 nicht bestückt wird, kann ich diesen ja eigentlich nicht überlasten. Aber evtl. T1 bei der Helligkeitsregelung, oder ist das nur eine Steuerleitung ohne Stromfluß?- Kann man sich im Rest der Core-"Netzteil"-Abteilung (also C3-6 und der Gleichrichter) bei Verwendung des C64-Netzteils nicht auch alles außer C5 sparen oder doch lieber normal bestücken, um bessere S/N zu erreichen?- Produziert ein VFD irgendwelche Einstreuungen, die man abschirmen müßte?Hoffentlich sind keine allzudoofen Fragen dabei, mein Halbwissen im Elektronikbereich ist noch ausbaufähig :)Danke,Seppoman Quote Link to comment Share on other sites More sharing options...
TK. Posted December 17, 2003 Report Share Posted December 17, 2003 Hallo Seppoman,am besten schliesst Du es direkt an das 64er Netzteil an. Wie Du schon richtig vermutet hast, wuerde es den T1 ueberlasten. Er steuert den Strom. Eine Helligkeitsreglung via PWM kann ich nicht empfehlen, dadurch entsteht Jitter an den analogen Eingaengen (und speziell beim SID: extremer Audio-Noise)VFD Einstreuungen: keine Ahnung, habe solch ein Display noch nie betrieben. Vielleicht weiss jemand anderes mehr?Bestueckung: 7805 und Gleichrichter weglassen, C6 ist ohne den 7805 nicht notwendig, tut aber auch nicht weh. C5 drauflassen und mit der 5V-Leitung verbinden.Gruss, Thorsten. Quote Link to comment Share on other sites More sharing options...
seppoman Posted January 8, 2004 Author Report Share Posted January 8, 2004 Hallo Thorsten,erstmal Danke für Deine Antwort. Ich hab über Weihnachten fleißig gelötet, Montag kamen auch endlich die PICs aus Taiwan, und die ersten Töne kamen schon raus :)Heute hab ich mich mit dem VFD beschäftigt (riesiges Teil übrigens, Gesamtbreite mit Platine 25 cm...). Nur leider bekomme ich nichts vernünftiges angezeigt. Der Cursor bewegt sich nach dem Einschalten nur ein Zeichen nach rechts und das wars. Die Belegung ist allerdings auch anders benannt, hoffentlich ist das Teil überhaupt kompatibel?D0-D7 sind vorhanden, dann noch WR, SEL und BUSY. Ich hab das Ganze mal so verbunden:RW -> WRRS -> SELE -> BUSYEnable und Busy kam mir sowieso komisch vor, deshalb hab ich das auch mal abgeklemmt (ein paar zufällige Zeichen, wohl zu schnell Daten bekommen), Select hab ich High und Low gesetzt, bringt aber alles nichts.Seriell (mit 5V Signal) könnte man das Display auch noch betreiben, der I2C-Anschluß wird aber wohl ungeeignet sein (I2C ist wohl ein Bus und das VFD hat für seriell nur RXD und Busy).Das Modul hat einen Toshiba TD62C950RF Chip drauf, über den ich im Netz nichts finde.Ein Datenblatt fürs Nachfolgemodell (?) habe ich gefunden: http://www.futaba.com/display_modules/vfd_products/pdfs/M402SD07JJ.pdfHab ich überhaupt Chancen, das Display zu verwenden, oder muß ich damit unfreiwillig unter die Case-Modder gehen? ;) )Vielen Dank,Seppoman Quote Link to comment Share on other sites More sharing options...
TK. Posted January 8, 2004 Report Share Posted January 8, 2004 Super, dass Du schon etwas hoerst. :)Aber mit dem sehen - hm - das VFD hat im Vergleich zu einem Standard Display ein voellig anderes Bus Interface. Es kann kein Read, stattdessen muss man die Busy-Leitung pollen. Auch die Kommandos - bspw. zum Setzen des Cursors - sehen voellig anders aus. Mit MIOS kann man solch ein Display ueber einen "Custom LCD Driver" ansteuern (siehe die app_lcd* Beispiele), aber um die Programmierung muesstest Du Dich selber kuemmern...Gruss, Thorsten. Quote Link to comment Share on other sites More sharing options...
seppoman Posted January 8, 2004 Author Report Share Posted January 8, 2004 Hallo Thorsten,danke für die schnelle Antwort :)Das hab ich schon befürchtet. Meinst Du, es ist einfacher, das VFD seriell oder parallel anzusteuern? Oder gibt es evtl. eine Möglichkeit, mit ein paar Bauteilen dazwischen den seriellen Anschluß nach I2C zu konvertieren, und dann einfach den I2C-Treiber zu benutzen?Ich hab mir gerade das MPLAB heruntergeladen und werde versuchen, erstmal den vorhandenen Treiber zu verstehen - von Assembler hab ich bisher noch wenig Ahnung (ein paar nette Spielereien mit Lauflichtern haben wir mal in der FH programmiert, aber das war alles kürzer als 20 Befehle ... )Hast Du evtl. ein paar Links, bei denen ich mich zum Thema Parallelport-Handling usw. einlesen könnte?Vielen Dank,Seppoman Quote Link to comment Share on other sites More sharing options...
TK. Posted January 9, 2004 Report Share Posted January 9, 2004 Wahrscheinlich ist der parallele Treiber am einfachsten zu programmieren. Morgen veroeffentliche ich den Source Code zu MIOS, darin findest Du den CLCD Treiber, den Du als Vorlage hernehmen kannst. Viel muss nicht geaendert werden, lediglich das Polling --> vereinfacht! <-- sich! :)Sonderzeichen werden von diesem Display wohl nicht unterstuetzt, deshalb koennen die huebschen Bargraphs nicht angezeigt werden.Gruss, Thorsten. Quote Link to comment Share on other sites More sharing options...
TK. Posted January 10, 2004 Report Share Posted January 10, 2004 Du findest den CLCD Treiber nun auch als "Custom Driver" in der MIOS Download Section. Was muss geaendert werden - an der Hardware:TEST# auf +5V klemmenSEL# mit der Enable Leitung verbindenWR# mit R/WBusy mit R/S -- vorsicht: hier einen 100 Ohm Widerstand in Serie schalten, damit es waehrend des Bootens keinen Kurzschluss gibt (Busy ist ein Ausgang). Ausserdem wuerde ich noch einen 10k Pull-Down vorsehen, damit der Core weiterlaeuft, falls das Display mal nicht angeschlossen istSoftware:In der Initialisierungsroutine den R/S Pin auf TriState (Input) setzen:bsf TRISD, USER_LCD_PIN_RSDer restliche Initialisierungscode fliegt raus, weil sich das Display selbst initialisiertUSER_LCD_Data: "Select Data Register" fliegt raus. Da es nur einen Datentransfermodus gibt, und die Zeichen < 32 Steuerzeichen sind, wuerde ich die Routine so umschreiben, dass nur Zeichen >= 32 uebertragen werden. Ansonsten gibt das Display wohl hin und wieder wirre Zeichen aus, oder macht gar nichts mehrUSER_LCD_Cmd: hat bei Deinem Display eine voellig andere Bedeutung. Ich wuerde die Routine so umschreiben, dass sie lediglich Zeichen < 32 uebertraegtUSER_LCD_WaitUnbusy: dieser Code wird schlicht und einfach durch folgenden Ersetzt:USER_LCD_WaitUnbusy IFSET PORTD, USER_LCD_PIN_RS, rgoto USER_LCD_WaitUnbusy returnUSER_LCD_Strobe_Set und USER_LCD_Strobe_Clr:hier muss die Polaritaet geaendert werden, da SEL# ein Low-Aktives Signal ist. Aus "bcf" wird "bsf", aus "bsf" wird "bcf"USER_LCD_Clear: hier muss das entsprechende Steuerkommando an das LCD gesendet werdenUSER_LCD_CursorSet: ditoGruss, Thorsten. Quote Link to comment Share on other sites More sharing options...
seppoman Posted January 10, 2004 Author Report Share Posted January 10, 2004 Hi Thorsten,tausend Dank für die ausführlichen Infos :) Ich habe gestern abend schon den MIOS Quellcode runtergeladen und die ganze Nacht mit der PIC-Assembler-Referenz und der CLCD Routine verbracht. Zumindest teilweise verstehe ich glaube ich, was da passiert. Mit Deinen Tips hast Du mir aber wohl mindestens 1-2 Tage Nachdenken erspart ;)Wegen Initialisierung: Laut Datenblat ist das Display nach dem Einschalten in Vertical Scroll mode mit aktiviertem Cursor. Wird das Display sowieso wo anders auf Normal ohne Cursor gesetzt, oder muß ich das doch hier machen?Naja, ich werd mich heute Abend mal ausführlich damit beschäftigen und weiter berichten :)Viele Grüße,Seppoman Quote Link to comment Share on other sites More sharing options...
seppoman Posted January 11, 2004 Author Report Share Posted January 11, 2004 Hallo,so, nach einer langen Nacht geht das Ganze jetzt einigermaßen. Das Einzige was noch nicht richtig funktioniert, ist die Cursor-Positionierung. ----------------------------------------------------------USER_LCD_CursorSet movlw 0x10 ;Cursor positionieren call USER_LCD_Cmd SET_BSR MIOS_LCD_CURSOR_POS movf MIOS_LCD_CURSOR_POS, W, BANKED cpfsgt 0x3F call USER_LCD_CursorSet_Y1, 1 rgoto USER_LCD_CmdUSER_LCD_CursorSet_Y1 andlw 0x3F addlw 0x28 return 1-------------------------------------------------------------Hierbei wird die zweite Zeile nicht korrekt verarbeitet. Weshalb die 1 bei call/return sein muß, weiß ich nicht, geht ja sonst auch ohne, aber hier Chaos. Mit 1 kann man in der ersten Zeile positionieren, die zweite ist aber falsch - das Display zählt in der zweiten Zeile direkt weiter, 28h ist also das erste Zeichen.Wenn ich z.B. auf (MIOS)Zeichen 40h will, springt das Programm in die Unterroutine (hab ich überprüft), ändert aber anscheinend trotzdem nichts an der Positionsadresse, d.h., das Zeichen erscheint bei 40h nach Zählung des Displays. Was irgendwie komisch ist, denn selbst wenn ich in der Y1-Routine einen Denkfehler hätte, irgendwas müßte sich trotzdem ändern. Hast Du ne Idee?Zu den Sonderzeichen: Das VFD kann auch selbstdefinierte Zeichen. Kann man die über den Custom-Treiber auch einbinden, oder müßte ich dafür die CLCD-Routine direkt ändern?Und gleich noch ne Frage: Seitdem ich das VFD dran habe (hatte vorher testweise ein kleines LCD) zeigt mir MIDI-OX immer beim Einschalten ein Bündel beliebiger MIDI-Daten (Noten, Controller, Realtime usw.). Das Display produziert also wohl beim Start irgendwelche Störungen. Kann man die mithilfe von z.B. einem dicken Elko an der Display-Versorgung vermeiden?So, nachdem die Nachbarn schon wieder wach werden, muß ich doch mal Schlafen gehen ;)Viele Grüße,Seppoman Quote Link to comment Share on other sites More sharing options...
TK. Posted January 11, 2004 Report Share Posted January 11, 2004 Also irgendwie sieht das ganz seltsam aus, weder call noch return erlauben ein zweites Argument. Der Assembler scheint an dieser Stelle wohl etwas zu tolerant zu sein. Ich nehme an, dass diese Funktion alle Zeichen ab 0x40 nach 0x28 mappen soll. Das koennte man auch so schreiben:USER_LCD_CursorSet movlw 0x10 rcall USER_LCD_Cmd SET_BSR MIOS_LCD_CURSOR_POS movf MIOS_LCD_CURSOR_POS, W, BANKED BIFSET MIOS_LCD_CURSOR_POS, 6, BANKED, addlw -(0x40-0x28) rgoto USER_LCD_DataDer Trick: in der zweiten Zeile ist Bit 6 gesetzt - das BIFSET macro (dahinter steckt die btfsc Instruction) tested dieses Bit und zieht 0x18 (0x40-0x28 ) davon ab - so wird aus 0x40 eine 0x28Sonderzeichen: Du koenntest in mios_vectors.inc "MIOS_CLCD_SpecialCharInit" und "MIOS_CLCD_SpecialCharsInit" auf Deine eigenen Funktionen umlenkenVermeiden der Stoerungen waehrend des Einschaltens: dazu kann ich nicht viel sagen, ich habe noch nie mit einem VFD gearbeitet, weiss nicht, wie das mit der Stromaufnahme ausschaut. Vielleicht ist auch einfach nur Dein Netzteil zu schwach, so dass es waehrend des Einschaltens zu einem kurzen Spannungseinbruch kommt.Gruss, Thorsten. Quote Link to comment Share on other sites More sharing options...
seppoman Posted January 11, 2004 Author Report Share Posted January 11, 2004 Hallo Thorsten,Vielen Dank, mit Deinem Code funktioniert das Ganze wunderbar :)Zu meiner Routine:Laut PIC-ASM-Referenz im Datenblatt erlauben call/return einen zweiten Parameter:Syntax: [ label ] CALL k [,s][...] If ’s’ = 1, the W,STATUS and BSR registers arealso pushed into their respectiveshadow registers, WS, STATUSSand BSRS. If 's' = 0, no updateoccurs (default). Then, the 20-bitvalue ’k’ is loaded into PC<20:1>.Bei return genauso.So ganz verstehe ich die ganze Register/Adressierungs-Geschichte nicht, aber ich hatte den Eindruck, daß irgendwie WREG nicht vernünftig verarbeitet wird, und die 1 dazu bringt das Ganze wenigstens irgendwie zum Laufen...Warum das weder mit noch ohne 1 geht, verstehe ich nicht.falls W > 3F, sprung, dort den Teil unter 40 holen und 28 dazuWenn W z.B. 40h ist, müßte andlw 0x3F -> W=0 ergeben. 28h dazu -> 1.Zeichen 2. Zeile...Naja, ist nicht so wichtig, mit der BIFSET-Lösung ist ja alles OK. Die Subroutine hab ich auch nur gebaut, weil ich nicht wußte, wie man mit einem einzigen Befehl einen Wert abzieht, da die subXX-Befehle ja immer W von etwas abziehen und nicht umgekehrt....Sonderzeichen: Wie funktioniert das mit den Vektoren, bzw. woher weiß ich, wohin der Vektor zeigen muß? (wie gesagt, mit der ganzen Speicherverwaltung kenne ich mich noch nicht aus)Wegen Netzteil: Ich verwende C64-PSU-Optimized. Momentan hängt daran außer dem VFD nur der Core und eine SID-Platine. Interessanterweise gibt es keine Random-Events, wenn man beim SID-Modul die 14V-Leitung abklemmt, auch nicht, wenn ich das zweite SID-Modul auch noch mit 5V anschließe. Das C64-Netzteil hat 1,5 A bei 5 V, Das Display zieht max. (also wohl beim Einschalten) 1 A. nur 1 Core und 1 Sid werden keine 500 mA brauchen?Viele Grüße,Seppoman Quote Link to comment Share on other sites More sharing options...
seppoman Posted January 12, 2004 Author Report Share Posted January 12, 2004 Hi Thorsten,Noch eine Frage (sorry wenns langsam etwas viele auf einmal werden...):Ich versuche gerade, den Treiber in die SID-Applikation einzubauen. habe app_lcd getauscht. PIC ID sowohl mit Typ 0 als auch Typ 7 gesetzt. MIOS 1.5 unverändert hochgeladen. In SID sowohl mit als auch ohne USER_INIT movlw 0x07 call MIOS_LCD_TypeSetprobiert.und bekomme nur entweder wirres Zeug (wohl wenn typ0 oder auto) oder MIDI-Display per SysEx.Woran liegt das, hab ich was vergessen?Vielen Dank,Seppoman Quote Link to comment Share on other sites More sharing options...
TK. Posted January 12, 2004 Report Share Posted January 12, 2004 Der Stromverbrauch von Deinem Display ist ziemlich hoch, nunja... musst Du mal ein wenig herumfrickeln.Vektoren: ersetze "EQU <MIOS-addresse>" einfach durch ein "EQU <USER_LCD-adresse>". Du musst die Adresse nicht als Zahl angeben, hier reicht auch das LabelHast Du das ", 1" hinter den call und return Befehlen mittlerweile entfernt? Mir ist eingefallen, warum ich diese Option aus meinem Hirn geloescht habe - weil man sie innerhalb einer MIOS Applikation niemals anwenden sollte ;-)MIOS verwendet bereits die Shadow-Register fuer den schnellen Kontextswitch bei Interrupts. Wenn Deine LCD Routine nun die Shadow-Register ueberschreibt, kracht es, sobald ein Interrupt die Displayroutine unterbricht.Weil ich Deinen Code nicht kenne, kann ich ansonsten nur noch raten - vielleicht verwendest Du TMP1? Sollte innerhalb eines Treibers aber niemals eingesetzt werden - nur die die im Header angegebenen Register sind erlaubt, es gibt spezielle temporaere Register fuer den Display Driver (MIOS_GLCD_TMPx)Gruss, Thorsten. Quote Link to comment Share on other sites More sharing options...
seppoman Posted January 12, 2004 Author Report Share Posted January 12, 2004 Hi Thorsten,ich bastle weiter am Treiber-Einbinden herum, ohne Erfolg. Jetzt wollte ich versuchen, in MIOS den CLCD-Treiber einfach direkt anzupassen. Compilieren konnte ich das MIOS, aber das hex2syx hat mit folgendem Fehler abgebrochen:You are trying to overwrite the MIOS adress range.[..]Ich hab jetzt mal versucht, einfach den Original-Quelltext zu compilieren, mit dem gleichen Ergebnis. Ist da in Deinem Release noch irgendein kleiner Fehler, oder mache ich was falsch?Bis dann,Seppoman---------------------------------------Edit:durch die Frage von psytron in Latest News bin ich selber draufgekommen  ::) Ist natürlich klar, daß, wenn man MIOS hochlädt, man den MIOS Adress Range überschreibt. Peinlich, peinlich :)Der Treiber funktioniert wunderbar, einzige kleine Macke: beim Durchschalten der Patches flackern in der ersten Zeile manchmal kleine "x" an den Stellen vor den Zahlen auf. Werd mir mal die CS_MENU-Routinen anschauen, ob diese iXe auch so gesendet werden und mein Display einfach träger als normal ist, oder obs doch noch irgendwie am Treiber liegt. Für Sonderzeichen hab ich provisorisch einfach x00 und x01 auf die ASCII-Symbole "Doppelpfeil" umgelenkt, da das allgemeingültig-MIOS-konforme Definieren von Zeichen etwas aufwendig ist - Das VFD hat nur 5x7 Pixel, also müßte man erstmal die Tabelle umwandeln, und die Pixel werden verschachtelt übertragen, also erstes Byte ist Zeile 1[1..5],Zeile 2[1..3] usw. Die SID-Applikation gibt ja sowieso nur die Pfeile aus, und dafür reicht << und >> erstmal.Trotzdem wäre es natürlich gut, den Treiber als User LCD einbauen zu können, damit man1. nicht bei MIOS-Updates jedesmal im Code rumpfuschen muß und2. der Treiber genauso wie die anderen Custom Treiber einzubinden ist - wenn ich alles fertig habe, wäre es wohl schon für den einen oder anderen nützlich, wenn der Treiber hier in die Sammlung aufgenommen würde und dann nicht alles anders ist als sonst.Warum wird bei MIOS_LCD_Cmd und MIOS_LCD_Data eigentlich bei Typ 7 nicht USER_LCD_Cmd/Data aufgerufen? Wenn ich das richtig sehe, macht _Cmd bei Typ6 und Typ7 gar nichts, _Data nur bei Typ7 nichts? Wobei das ja eigentlich nicht der Grund für die fehlende Ausgabe bei der SID-Applikation sein kann, denn bei der CLCD7-Beispiel-Applikation gehts ja auch.Jedenfalls Langer Rede Kurzer Sinn: Wie integriere ich einen Custom Treiber in die Applikation, so daß er auch wirklich verwendet wird und nicht das MLCD aktiviert wird?Vielen Dank,Seppoman Quote Link to comment Share on other sites More sharing options...
TK. Posted January 13, 2004 Report Share Posted January 13, 2004 Kannst Du mir mal das geaenderte mios_clcd.inc zuschicken? Dann mache ich Dir ein app_lcd.inc daraus.Warum es kein USER_LCD_Data und USER_LCD_Cmd gibt? Weil die Bedeutung je nach Display-Typ voellig verschieden ist. Die x'en sind evtl. die Sonderzeichen, vielleicht auch der Cursor. Wie auch immer, das wuerde sich mit einem sauber programmierten Custom LCD Treiber aendern.Gruss, Thorsten. Quote Link to comment Share on other sites More sharing options...
seppoman Posted January 16, 2004 Author Report Share Posted January 16, 2004 Hallo Thorsten,so, nachdem ich mal nen Tag Auszeit von Assembler gebraucht und ein paar Sachen an der Hardware weiter gebaut habe, bin ich wieder am Treiber. Das mit MIOS_LCD_Cmd / Data ist jetzt klar, die müssen ja beim Custom Treiber gar nicht von außen angesprochen werden.Die iXe hab ich inzwischen gefunden. In CS_MENU baust Du die erste Zeile des Menüs auf, indem Du erst "Pxxx C xx ----" schreibst, und dann die tatsächlichen Informationen drüberschreibst. Wenn man den String einfach in "P C " ändert, sieht man auch keine iXe mehr. Liegt also tatsächlich daran, daß das Display wohl recht langsam ist. Interessant fand ich, daß auch wenn man z.B. das Mod-Wheel bewegt, bei jedem MIDI-Event das Display upgedated wird, was ja im Hauptmenü auf jeden Fall unnötig ist. Meinst Du, daß das fürs Timing nachteilig ist (weil MIOS evtl. aufs Display wartet), oder ist das egal?Im Save-Menü flackert die erste Zeile, was wohl auch an der Geschwindigkeit liegt. und sobald man hier in P# geht, blinken erste und zweite Zeile abwechselnd. Ist das normal? Wenn nein, hast Du ne Idee, was man dagegen machen kann?Jedenfalls maile ich Dir gleich mal die mios_clcd zu. Vielen Dank schon mal!Und schon wieder ne neue Frage:Ich baue mir gerade die Frontplatte, auf der (u.A. wegen dem großen Display) nicht genug Platz ist, um sowohl für OSC als auch für ENV 5 Encoder zu montieren. Jetzt hab ich mir überlegt, daß ich ja dem OSC-Encoder-Layer-Schalter noch ne vierte Ebene samt LED verpassen könnte, so daß man zwischen OSC Envelope, OSC Misc, ENV Envelope und Assign (Menu_P1..P5) schalten kann. Ist das ein großer Aufwand?Viele Grüße,Seppoman Quote Link to comment Share on other sites More sharing options...
TK. Posted January 16, 2004 Report Share Posted January 16, 2004 Also wenn Du den Bildschirmaufbau auf diese Weise verfolgen kannst, dann wuerde ich Dir dringenst empfehlen, mit der Frontplatte zu warten und nach einem anderen Display ausschau zu halten. Diese Dummy-Zeichen erscheinen bei einem normalen Display vielleicht fuer 50 uS (Microsekunden!) - sind also voellig unauffaellig, bei Dir liest es sich so, als wuerde es sich um Millisekunden handeln. Diese Latenz waere fuer einen MIDI Controller vielleicht noch akzeptabel, aber einen Synth macht das unbrauchbar.Auch die Dummy-Display-Updates sind voellig akzeptabel, weil sie normalerweise nicht weh tun. Der Aufwand, unnoetige Updates zu erkennen und zu verhindern steigt schnell ins Unermessliche (und wer soll das alles testen? Nach solch einer Aenderung traut man sich ja gar nichts mehr neues mehr einzubauen ;-)), deshalb habe ich das gar nicht erst angefangen und gehe lieber auf nummer sicher - bevor ich wochenlang den Fehler-Reports im Forum nachgehen muss...Das Erweitern des OSC-Layers ist kein besonders grosser Aufwand, aber Du muesstest dich halt selbst darum kuemmern. Ich kann das mit meiner Hardware nicht testen. Hint: cs_menu_io_tables.inc, cs_menu_buttons.inc, cs_menu_leds.incGruss, Thorsten. Quote Link to comment Share on other sites More sharing options...
seppoman Posted January 18, 2004 Author Report Share Posted January 18, 2004 Hi Thorsten,zur Abwechslung mal wieder auf Deutsch :)weiß nicht ob Du meine Mail bekommen hast mit dem Treiber, aber das "in einen Custom Treiber umwandeln" hat sich eventuell erledigt (außer die Sonderzeichen-Geschichte). Ich hab mir den iic Treiber mal angeschaut und festgestellt, daß Du im iic Treiber kein ;; notify that no graphical LCD is connected bcf MIOS_BOX_CFG0, MIOS_BOX_CFG0_USE_GLCDdrin hast, obwohl das laut Datenblatt auch ein CLCD ist. Deshalb hab ich die Zeile aus meinem Treiber mal rausgenommen, mit dem Ergebnis, daß er jetzt problemlos als Custom Treiber mit nomalem MIOS drunter funktioniert. Ist damit die Sache ok, oder hat es irgendwelche Nachteile (Timing), diese GLCD-Einstellung zu haben? Wenn ich das richtig gesehen habe, wird dadurch bei der Cursor-Positionierung eine GLCD-Routine verwendet, die einige Operationen mehr durchführt.Timeout-Routine hab ich mal versucht, allerdings weiß ich ehrlich gesagt nicht, ob sie funktioniert. Bei den ARPSEQ-Sounds führt das schnelle Hinundherdrehen von Mod-Wheel oder Encodern zu Timing-Problemen, die aber mit dem Timeout-Versuch auch nicht anders sind. Kannst Du die Auswirkungen der Timeout-Flags etwas erklären? Wozu gibt es .._TIMEOUT0 und .._TIMEOUT1? Wird bei Timeout das Display-Update zurückgestellt und erst wieder versucht, wenn dazwischen Realtime-bezogene Sachen erledigt wurden? Wenn das so ist, würde es dem Timing helfen, wenn der Timeout-Loop nicht bis 0xff zählt (wie im CLCD-Treiber) sondern früher abbricht?Wie Du siehst, hab ich mich noch nicht ganz damit abgefunden, das Display aufzugeben, weil 1. es einfach geil aussieht, und - wichtiger - ich letzte Woche schon das Loch dafür in die Frontplatte geschnitten habe...Übrigens hab ich gesehen, daß mit meinem 2x16-LCD die iXe auch beim Durchschalten zu erkennen sind. Bei dem haben allerdings Mod-Wheel-Bewegungen nur minimalen Einfluß aufs Timing.Bis dann,Seppoman Quote Link to comment Share on other sites More sharing options...
TK. Posted January 18, 2004 Report Share Posted January 18, 2004 Hallo,das MIOS_BOX_CFG0_USE_GLCD Flag hat eigentlich (noch) gar keine Bedeutung. Ich habe es erst in MIOS V1.5 eingebaut und werde es im Laufe der Zeit auch in den Applikationen verwenden. Diese konnten bisher nur ueber den Display Type feststellen, ob ein CLCD oder GLCD angeschlossen ist. Weil aber ein User LCD auch ein CLCD sein kann, und weil es spaeter auch mal eine Companion Chip Loesung fuer GLCDs, die quasi ein CLCD emulieren, geben wird, hielt ich diese Loesung fuer angemessen.Wann ist ein CLCD ein CLCD: wenn es die Moeglichkeit gibt, 8 Sonderzeichen gemaess der HD44780 Spec zu uebergeben. Das ist bei Deinem Display nicht der Fall.Die SID Applikation verwendet momentan noch ein internes GLCD Flag, aber wie sich das auswirkt, schaust Du Dir lieber im Source Code an, das schreibe ich hier jetzt nicht auf... (schau einfach in das main.lst, dort befindet sich der gesamte Code)TIMEOUT1/TIMEOUT2 ist ein 16-bit counter, der dafuer sorgt, dass der LCD Driver deaktiviert wird, wenn kein Display angeschlossen ist. Mit Performance hat das nichts zu tun.Xe: was meinst Du mit Durchschalten? Es gibt durchaus Performance-Engpaesse in der MIDIbox SID, bspw. wenn ein Patch fuer einen (oder mehrere) SID Slaves umgeschaltet wird, oder wenn viele CC's gleichzeitig eintreffen und verarbeitet werden muessen. Das kann man aber nicht aendern, bedenke was da staendig im Hintergrund laeuft (die SID Engine sid_sw.inc ist so etwas wie ein virtueller Synth, und die ganzen DIN/DOUT Shiftregister wollen auch zuverlaessig versorgt werden) und dass die Slaves ueber MIDI mit Daten gefuettert werden (das Versenden eines Patches dauert ca. 250 mS!) - die einzige saubere Loesung waere hier, einen separaten PIC fuer das Control Surface herzunehmen, jeden Slave mit einem eigenen BankStick zu bestuecken und die Kommunikation nicht ueber die MIDI Schnittstelle laufen zu lassen - aber ihr wollt es ja immer billig ;-)Gruss, Thorsten. Quote Link to comment Share on other sites More sharing options...
doc Posted January 18, 2004 Report Share Posted January 18, 2004 [glow=red,2,300]- aber ihr wollt es ja immer billig [/glow]...Entschuldigung, ich kann mir das Lachen kaum verkneifen... aber wo TK recht hat, hat er Recht ! ;D Quote Link to comment Share on other sites More sharing options...
seppoman Posted January 18, 2004 Author Report Share Posted January 18, 2004 Hi Thorsten,woran das mit dem USE_GLCD liegt, kann ich auch nicht sagen. Ich hab mir das nochmal angeschaut, und das Flag wird eigentlich nicht ausgewertet, aber trotzdem hab ich die Applikation gerade zweimal compiliert, mit dem einzigen Unterschied, daß dieses Flag einmal gelöscht und einmal nicht gelöscht wird. Und eben einmal der MLCD-Treiber und einmal der USER LCD treiber aktiviert wird. Naja, wenn Du sagst, daß es nichts macht diese Zeile rauszulassen, dann kann der Grund ja eigentlich egal sein...Das interne GLCD-Flag ist CS_STAT_DISPLAY_GLCD? Das steht ja wenn ich das richtig sehe in keinem Zusammenhang zum MIOS_BOX_CFG0_USE_GLCD? Kann es sein, daß dieses immer gesetzt wird, wenn Display Type > 0 ist?----- ;; set CS_STAT_DISPLAY_GLCD depending on LCD mode bcf CS_STAT, CS_STAT_DISPLAY_GLCD call MIOS_LCD_TypeGet skpz bsf CS_STAT, CS_STAT_DISPLAY_GLCD----Wegen Timeout: Wenn ein Timeout eintritt, wird das Display dauerhaft deaktiviert?Ich habe gerade mal die Geschwindigkeit des Displays versucht zu testen. Wenn ich in die WaitUnbusy-Routine eine Schleife einbaue, die nach 127 Runden (Bit 7 gesetzt) rausspringt und die Zeichenausgabe überspringt, fehlen ca. die Hälfte der Zeichen, das ist also wohl schon zu schnell...Wäre es nicht allgemein sinnvoll, die Displayausgabe so zu bauen, daß sie erstmal in einen Buffer geht, der erst rausgeschrieben wird, wenn echtzeitabhängige Dinge komplett erledigt sind? Bzw. beim Ändern von Parametern während des Spielens könnte man ja auch auf die Anzeige ein paar zwischenliegender Werte einer Drehbewegung verzichten - Wenn ich spiele und dabei z.B. am Filter drehe, ist es ja nicht so schlimm, wenn der zugehörige Wert erst ne Viertelsekunde später angezeigt wird. Ich vermute nur, das würde wohl ziemlich kompliziert werden?iXe: Mit Durchschalten meine ich, Patche mit einer schnellen Drehung umzuschalten. Ist schon klar, daß da ziemlich viel passiert.BTW: So extrem auf billig fixiert bin ich nicht - wenn das mit dem CS Companion in Zukunft kommt, würden mich die 20 Euro nicht davon abhalten, wenn es Vorteile bringt :) Wäre es dann damit auch möglich, den Companion für die Ansteuerung meines Displays zu nutzen, wenn dort der Custom Treiber installiert wird? Nachdem ich sowieso während dem Spielen nicht unbedingt an allen Parametern gleichzeitig rumschraube, könnte ich mir behelfsmäßig das Dummy-Update bei Mod-Wheel events ausbauen, und meinen "Lieblings-Parameter" einfach per Mod-Wheel steuern. Überhaupt stelle ich komischerweise auch nicht bei allen Sequencer/Arpeggiator-Sounds Timing-Probleme fest, das beschränkt sich auf ein paar Sounds, die so richtig aus dem Tritt kommen (z.B. Arpseq Three, muß mal schauen, was an den betroffenen Sounds anders ist...)Bis dann,Seppoman Quote Link to comment Share on other sites More sharing options...
TK. Posted January 19, 2004 Report Share Posted January 19, 2004 Das mit dem USE_GLCD flag schaue ich mir irgendwann einmal an...Ja, die SID Applikation geht noch davon aus, dass es sich bei LCDs mit ID > 0 grundsaetzlich um ein graphisches LCD handelt. Deshalb gibt es nun das USE_GLCD flag, aber es wird so noch nicht funktionieren, das ganze befindet sich wie gesagt in Vorbereitung und wird vielleicht ab MIOS V1.6 oder spaeter in voller Schoenheit funktionieren (Prioritaet: ziemlich niedrig, zumal die Applikationen daran angepasst werden muessen)Das mit dem Busy hast Du wie bereits erwaehnt falsch verstanden. Es geht hier nicht darum, Zeichen zu unterdruecken, sondern eher darum, dass MIOS nicht in einer Endlosschleife haengen bleibt, wenn mal zufaellig kein LCD angeschlossen ist.Buffern: das moechtest Du nicht wirklich! Die MIDIboxSEQ kann bspw. 2x80 Zeichen darstellen, das sind 160 Byte, die kann man fuer schoenere Dinge verwenden.Das Control Surface der MBSEQ habe ich uebrigens etwas geschickter programmiert, hier werden nur die Items upgedated, die sich wirklich geaendert haben. Optimiert und verifiziert habe ich das ganze mit einem Oszilloskop (ein Item-Refresh dauert ca. 200 uS). Den Aufwand koennte ich auch irgendwann einmal fuer die MIDIbox SID treiben, aber nicht heute, und auch nicht in den naechsten 1-2 Wochen, aber vielleicht danach? Schaunmer mal... das waere jedenfalls der bessere Weg.Echtzeit: hier uebersiehst Du, dass die Echtzeit-Tasks jederzeit die Display-Ausgabe unterbrechen koennen, deshalb braucht die Ausgabe auch manchmal etwas laenger. Wenn es soweit kommt, dass andere Low Priority Jobs (wie bspw. der Wavetable-Handler) zu lange warten muessen, geht man normalerweise her und splitted die Display-Ausgabe in zwei oder mehrere Teiljobs, die dann mit jedem USER_Tick alternierend ausgefuehrt werden. Dies waere eine Loesung, wenn sich der Display-Inhalt komplett aendern wuerde, aber bei der MBSID ist es ja nur ein kleiner Teilbereich, deshalb wuerde sich hier die gleiche Methode wie bei der MBSEQ besser eignen.Du schreibst:beim Ändern von Parametern während des Spielens könnte man ja auch auf die Anzeige ein paar zwischenliegender Werte einer Drehbewegung verzichtenmit der DISPLAY_UPDATE_REQ Methode wird so etwas aehnliches bereits gemacht. Es wird nicht sofort refreshed, sondern nur dann, wenn CS_MENU mal wieder dran kommt. Und das ist auch normalerweise ausreichend, solange die Displayausgabe < 1 mS dauert. Wenn bspw. viele MIDI Events aufeinmal eintreffen, arbeitet MIOS_MPROC erstmal den gesamten Buffer ab, bevor USER_Tick aufgerufen wird. Du verwendest ein 2x40 Display, hier dauert die Ausgabe doppelt so lange. So habe ich die MBSID noch nicht betrieben, und deshalb ist mir dieses Performanceproblem auch noch nicht so bewusst geworden. Ich verwende auch normalerweise kein Modwheel, sondern aendere die Parameter direkt am Control Surface...Aber wie ich bereits oben schrieb, gibt es geschicktere Methoden, das auszumerzen, allerdings kann man das nicht in 5 Minuten erledigen, sondern muss gezielt die Timings mit einem Oszi ausmessen und dort optimieren, wo es wirklich Sinn macht. Wenn ich mal nichts besseres zu tun habe (vielleicht hast Du ja mitbekommen, woran ich gerade bastle...) werde ich mir das mal anschauen. Companion: das ist die Loesung speziell fuer sehr langsame LCDs (insbesondere fuer die billigen graphischen LCDs), bei der die Befehle in einem grossen Buffer aufgefangen werden. Aber Dir waere wohl dann mit der Aenderung im MBSID CS_MENU bereits geholfen - abwarten und Tee trinken.Update ausbauen: klar, kannst Du machen, siehe sid_midi.inc, SID_MIDI_CC - dort stehen die beiden Update Requests. Schmeiss die mal raus, dann sollte das MOD-Wheel keine Auswirkungen auf das Timing haben. Du koenntest dieses Verhalten auch ueber einen zusaetzlichen Button steuern, wie waere es bspw. mit dem "CS_MENU_MODE, CS_MENU_MODE_EDIT" flag? Wenn es nicht gesetzt ist, einfach die beiden Befehle ueberspringen.Ich sehe uebrigens gerade, dass dort "CS_STAT_UPDATE_PARAMETERS" gesetzt wird - das ist evtl. der eigentliche Uebeltaeter, muesste ich auch mal mit dem Oszi ausmessen und gegenenfalls auf Zeit (und nicht auf Codegroesse) optimierenAber wie ich bereits angedeutet habe: momentan liegen meine Prioritaeten woanders. Ich betreibe meine MBSID gerade mit der MBSEQ, da benoetige ich keinen Wavetable-Sequenzer ;-)Gruss, Thorsten. Quote Link to comment Share on other sites More sharing options...
TK. Posted January 20, 2004 Report Share Posted January 20, 2004 Hallo,die Analyse mit dem Oszi hat folgendes ergeben:Der Update des gesamten 2x20 Displays dauert ca. 800 uS (bei einem 2x40 HD44780 Display ca. 1.6 mS), die Abarbeitung von CS_MENU_UpdateCCPara ca. 1.2 mS. Doch damit nicht genug: in CS_MENU_UpdateCCPara wird faelschlicherweise ein zweiter Display Update requested, und der wird dann ca. 200 uS spaeter zusaetzlich abgearbeitet.Das bedeutet, dass bei einem 2x40 Display die eintreffenden CCs ein Delay von mindestens 2.8 mS + 1.6 mS erzeugen. Falls zwischendurch erneut ein CC eintrifft (was innerhalb dieser langen Zeitspanne durchaus moeglich ist), wird erneut ein Update erzwungen, und dieses unregelmaessige Verhalten kann durchaus zu einem hoerbaren Jitter fuehren.Abhilfe:in "CS_MENU_UpdateCCPara" den unnoetigen DISPLAY_UPDATE_REQ rausschmeissen, so dass schonmal 1.6 mS eingespart werdenden unteren Teil von SID_MIDI_CC wie folgt aendern:#if CS_ENABLED == 1 IFCLR CS_MENU_MODE, CS_MENU_MODE_EDIT, rgoto SID_MIDI_CC_NoUpdate ;; request update of CS parameters bsf CS_STAT, CS_STAT_UPDATE_PARAMETERS ;; force a display update bsf CS_STAT, CS_STAT_DISPLAY_UPDATE_REQ SID_MIDI_CC_NoUpdate #endifVorteil: zero delay, Nachteil: die im CS gespeicherten Parameter koennen nur noch im Edit Modus von extern veraendern werden - das ist aber verkraftbar.Bleiben noch zwei weitere Aenderungen, die ich dann demnaechst einbauen werde:- einen speziellen Update Request, der lediglich die untere Zeile updated, um das Delay auf 400 uS zu minimieren. Die Uebertragung eines einzelnen MIDI Events dauert 1 mS, die LCD Ausabe wird sich nicht mehr bemerkbar machen - viel mehr Aufwand ist an dieser Stelle also gar nicht notwendig.- beim Wavetable-Sequenzer werde ich das WT_STATE_NEXT flag durch einen Counter-Mechanismus ersetzen, so dass er niemals aus dem Takt kommt. Diesen Mechanismus habe ich mittlerweile auch in die MBSEQ eingebaut, sie laeuft nun selbst nach einer Stunde noch synchron zur Masterclock.Soviel zu diesem Thema... ;-)Gruss, Thorsten. Quote Link to comment Share on other sites More sharing options...
seppoman Posted January 20, 2004 Author Report Share Posted January 20, 2004 Hi Thorsten,so, ich hab Deine Änderungen mal eingebaut - prima :) Der einzige Sequencer-Patch, der bei Mod-Wheel-Bewegung noch etwas wacklig wird, ist der ARPSEQ Three, allerdings auch lang nicht mehr so schlimm wie vorher, da muß man schon ziemlich rumscratchen, um deutliche Auswirkungen zu hören :) Eine kleine Änderung hab ich noch gemacht: CS_STAT_UPDATE_PARAMETERS hab ich immer dringelassen, da das keinen hörbaren Effekt hat, und so wird wenigstens beim nächsten Cursor-Blinken der richtige Wert angezeigt.Echtzeit: D.h. also, daß nur der Wave-Sequencer von der Display-Geschwindigkeit runtergezogen wird, weil dieser im Gegensatz zu Note On/Off / CC nicht die Priorität hat, um das Display zu unterbrechen? Der Rest wird also bearbeitet, obwohl der Display-Treiber in der WaitUnbusy Schleife ist? Momentan ist das Ganze timingmäßig schon ziemlich brauchbar. Wenn dann irgendwann noch Deine genannten Änderungen kommen, hätte ich praktisch keine Nachteile mehr durch das langsame Display?Falls doch: Könnte man die geplante Companion-Lösung auch dazu verwenden, darauf den Display-Treiber fürs VFD laufen zu lassen oder wird das erstmal nur GLCDs unterstützen?Eine andere Sache konnte ich auch noch nicht klären: das komische Flackern im Save-Menü. Dort scheint im Gegensatz zu sonst das Display mit wahnsinnig schnellen Updates überfahren zu werden. Ich konnte bisher noch nicht die Stelle finden, in der dieses Menü geschrieben wird. Könntest Du mir sagen, wo ich suchen muß?Vielen Dank,Seppoman Quote Link to comment Share on other sites More sharing options...
TK. Posted January 21, 2004 Report Share Posted January 21, 2004 Hallo,dass CS_STAT_UPDATE_PARAMETERS bei Dir weniger ausmacht als das LCD, stimmt mich schon etwas nachdenklich. Ohne handfeste Zahlen kann ich Dir eigentlich keinen serioesen Vorschlag machen, deshalb habe ich mal schnell einen Benchmark geschrieben, mit dem man die Performance genaustens ermitteln kann (das hatte ich sowieso schon immer mal vor...).Siehe auch "MIOS Toy of the week"Welcher Counter-Wert ergibt sich bei einem VFD?Prioritaeten: nein, auch die eingehenden Noten und der SID Register Update werden mit niedriger Prioritaet behandelt (der PIC kann nur zwei Prioritaeten) - so etwas nennt sich kooperatives Multitasking, bekannt aus den alten Amiga, Atari und Mac Zeiten. Falls eine Routine mal laenger braucht, muss man sie splitten, wie weiter oben erwaehnt.Unter normalen Umstaenden ist das kein Problem, ein komplexeres Multitasking mit Kontextswitching, etc, wuerde nur zu groesseren Latenzen fuehren und nicht unbedingt ein Performancegewinn bedeuten (siehe Windows).Save-Menue: ist mir noch nicht aufgefallen, werde ich mir dann irgendwann einmal anschauen. Danke fuer den Hinweis!Gruss, Thorsten.P.S.: die SID Sound engine, MIDI In/Out Buffer, DIN/DOUT chains werden hingegen mit hoechster prioritaet behandelt und sind deshalb stets stabil im Timing. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.