avogra

I just finished the graphics to illustrate the new modes and also how to create custom modes. It is attached to my last post in the topic, TK quoted. with the graphics, it should be easier to see, how a custom mode might solve your problem. good luck!

Hallo, so, jetzt hab ich mich endlich mal an die versprochene Grafik für die neuen Encoder-Modes gemacht. Ist das so verständlich? Soll ich den Teil für die Custom modes so drin lassen oder lieber als extra eintrag in die wiki? Grüße, Alex

Hi, You can try to identify the bad transitions and use a custom detent-mode. Therefore, instead of MIOS_ENC_MODE_DETENTEDxx, use 0x01, 0x02, 0x04 and 0x08 to test increments, and 0x10, 0x20, 0x40 and 0x80 for decrements. Try them one after another in normal speed-mode and note, which show jitter and which are jitter-free for a full revolution of the encoder. to get a behaviour like DETENTED2, you need one jitter-free increment and one decrement. For DETENTED (resp. DETENTED1) you need two jitter-free test-modes for increment and two for decrement. Then you can sum up the working test-modes to a custom mode and use that for your application. remember to add the modes in hex! Just an example: let's assume, the following test-modes are jitter-free: 0x02, 0x08, 0x10, 0x40, 0x80. to get a custom DETENTED2-like mode, you could use 0x02 for increments and 0x10 for decrements, summing up to 0x12 as your custom-mode. to get a DETENTED1-like mode, you could use 0x02, 0x08, 0x10 and 0x80, resulting in 0x9A as custom-mode. I hope you can find a working enc-mode that way. best regards, Alex

what hasn't been mentioned yet: at 10bit resolution it will become really hard to avoid some jitter due to noise from power supply and the like. so you will have a steady stream of little tempo changes. imho, a higher resolution is only sensible if you set the values digitally instead of a pot.

Probier alternativ mal DETENTED5 aus. das ist fast der gleiche modus wie DETENTED4, aber es werden genau die anderen Flanken ausgewertet. wenn das auch nichts hilft, könntest du außerdem noch statt MIOS_ENC_MODE_DETENTEDx direkt 0x66 oder 0x99 ausprobieren. Sollte also dann so aussehen: ... MIOS_ENC_PIN_TABLE ;; encoders 1-16 ;; SR Pin Mode ENC_ENTRY 4, 0, 0x66 ... Grüße, Alex

i don't have them at hand but i'm quite sure it was 16 detents as the description says. no idea how this shaft is meant to be used. the diameter is somewhere between 11 and 12mm from what i remember. i didn't mount a knob at all and just used it as is. if you want to use it as data-wheel, you could make a larger custom knob (fitting the hard detends). But i doubt you will find a ready-made knob. Cheers, Alex

wow, it's really nice! i want that too :)

sounds to me like all your banksticks have the same adress. at the top of http://ucapps.de/mbhp_bankstick.html there's a wiring diagramm. the banksticks get their adress from the connection of pins 1-3. although i doubt reading would work, when they all have the same adress. so maybe i'm wrong.

if it is ok, to have 5 distinct midi-ports instead of merging them into one, you could also replace your 1x1 interface by this: http://www.ucapps.de/mbhp_usb_gm5.html some interesting links: http://www.midibox.org/dokuwiki/doku.php?id=tk_gm5_bulkorder http://www.midibox.org/dokuwiki/gm5x5x5_pcb_bulk_order http://www.midibox.org/forum/index.php/topic,13891.msg119474.html#msg119474 that will only work for you, if your virtual organ can handle different midi-ports, of course. for a pedalboard and stop switches, i guess a midibox64 or midibox64e should be fine. cheers, Alex //edit: typos & replaced german words :)

jepp, gibts, probier mal midiyoke aus: Midiyoke dann gibts noch "hubi's loopback device" glaub ich, aber das hab ich nie ausprobiert. Gruß, Alex

Hi, ich hab mir das Datenblatt mal angeschaut. Ich hab zwar selber nicht wirklich die Ahnung, aber ich denk, das Display ansteuern wird schon n bisschen aufwändiger. mMn ist definitiv in MIOS selbst rumwursteln angesagt. Die Teile verwenden ein serielles Interface, das eigentlich ganz einfach zum ansteuern aussieht. Unsere PICs haben als schnelle Schnittstellen nur 1x UART (wird für MIDI verwendet) und 1x I2C oder? Letzterer hat ja n festes Protokoll, scheidet also auch aus. Die Screenkeys wollen mind. 50kHz. kA, ob man das irgendwie in Software halbwegs performant hinbekommt. Wenn ja, denk ich aber, dass das direkt in MIOS eingebaut werden müsste :-/ Wie gesagt, da hab ich keine Ahnung. Wenn du mehrere ansteuern willst, bräuchts wohl außerdem nen Multiplexer, da die Dinger keine Adressen haben, anhand denen man sie ansprechen kann. Das sollte aber das geringere Problem sein. Poste doch mal im Englischen Parts-Forum das Datenblatt. Da is die Wahrscheinlichkeit größer, dass es sich einer von den Profis mal anguggt. Wobei die sicher schon mal jemand entdeckt hat :) Ich denk auf jeden Fall, der Aufwand is schon nicht ohne. Könnte aber auch total daneben liegen :-P Gruß, Alex

Which application did you try? is it the same hex-file as the other core?

thanks for all the fish

jepp, funktioniert perfekt :D jetzt fehlt nur noch #define MIOS_ENC_MODE_DETENTED5 0x5a in cmios.h, falls bei jemand die rastung in die andere richtung verschoben ist :P Soll ich für ucapps.de mal n neues bild mit allen encoder-typen machen, oder die state-machine dokumentieren? Gruß, Alex

wollt, grad posten, dass er state nr. 7 / 0x08 nicht erkennt -.-

hui, das ging ja schneller als ich für den post gebraucht hab ^^ in c funktionierts bei mir. dann werd ich gleich mal testen.

Hey Thorsten, ich glaub ich hab grad ne Möglichkeit gefunden, wie man den jump-table los wird und gleichzeitig jeden beliebigen detent-mode ohne zusätzlichen code implementieren kann. -> Speicher gespart, bessere Performance, mehr Flexibilität -> was will man mehr 8) Also, folgende Überlegung: Es gibt ja 8 Zustands-Übergänge, die uns interessieren. Ein Char hat bekanntlich 8 Bit. Man könnte die ENC_MODEs also so nutzen, dass jedes Bit angibt, ob bei dem entsprechenden Übergang ein Do_Inc bzw. Do_Dec ausgelöst werden soll. Die ENC_MODEs könnten dann z.B. so aussehen: Bit 7 6 5 4 3 2 1 0 Übergang 0x8 0xE 0x7 0x1 0x4 0xD 0xB 0x2 --------------------------------------------- NonDetented 1 1 1 1 1 1 1 1 = 0xFF Detented1 1 0 1 0 1 0 1 0 = 0xAA Detented2 0 0 1 0 0 0 1 0 = 0x22 Detented4 1 0 1 0 0 1 0 1 = 0xA5 (Pollin-Mode1 :) ) ... Die Übergänge hab ich aus meiner Grafik von oben entnommen und sortiert nach Bit 0-3 = Do_Inc, Bit 4-7 = Do_Dec Wenn sich einer der Encoder-Pins ändert, muss die Routine also wie bisher nen Enc_State/Übergang zusammenstellen. dann in nem Lookup-Table dem Übergang nen Wert Enc_State_Nr = 0 bis 7 zuordnen, entsprechend dem Tabellen-Kopf, oder 0xFF, falls es einer der Zustände ist, die nicht interessieren (ok, gibt immer noch nen Table, aber der enthält nur Zahlen). Falls Enc_State_Nr nicht 0xFF ist: Das Bit des ENC_MODEs an der Stelle Enc_State_Nr auf 1 prüfen. falls das der Fall ist: wenn Enc_State_Nr <= 3, Do_Inc aufrufen, ansonsten Do_Dec Die Definition der ENC_MODEs am Anfang kann man sich dann auch schenken, da die jetzt (zumindest mit der Grafik) selbstredend sind. Für Änderungen an den Modes brauchts dann nur noch nen Eintrag in cmios.h. Ich werd das Ganze gleich mal in C implementieren, musste den Gedanken nur ganz schnell irgendwo hin schreiben :P Ich fürchte, für Assembler reichts bei mir noch nicht, aber vielleicht schaff ichs ja teilweise und ne gute Seele hilft mir bestimmt ;) Grüße, Alex P.S.: irgendwie passt das ganze nur noch bedingt ins Topic, eigener Thread?

yep :) just go through the whole file. I haven't looked closely into it, but i guess there are some other settings as well.

I haven't used the MB64 yet, but as far as i know, you don't need to do any programming in C. (MB64 is written entirely in Assembler anyhow, right?) It's mere adapting a bunch of settings, e.g. how many DINs and AINs are connected. look into the setup_midibox64.asm, it's all nicely explained there. After that, it should be working :)

achso, ich dachte, jedes byte extra ist ein absolutes No-Go. wenn dem nicht so ist, schreib ich auch gern die tabelle und die aufgerufenen funktionen um, so dass meine vorgeschlagenen modi auch nen platz drin haben (leider nur in C). Das einfach mit ner Verzweigung zu machen, und die Tabelle doppelt reinzuschreiben ist ja nicht die sauberste Lösung. Ich bin mal durchgegangen, was man ändern müsste. Bisher sinds ja 7 Funktionen, die Aufgerufen wurden. Und es geht sich wunderschön aus, dass du pro Funktion einen Vergleich brauchst, um den ENC_MODE zu filtern. Wenn ich meine beiden Modi mit rein nehm, brauch ich eine zusätzliche Funktion, und jede Funktion braucht dann 2 Vergleiche gegen ENC_MODE. Ich weiß nicht, wieviel Platz das beansprucht, aber ich vermute mal, weniger als 40 Byte. Performance-mäßig sollte es nicht mehr kosten als ne zusätzliche verzweigung in meine tabelle. Ich schreib die Tabelle und die Funktionen mal entsprechend um. Kannst ja dann schaun, obs dir gefällt und in Assembler umschreiben :-P //edit: hab mir den Assembler nochmal genauer angeschaut. Ich werd's da auch mal probiern. Mehr als nicht funktioniern kanns ja nicht :) Grüße, Alex

na wenn ich kein geld für neue ausgeben will, bleibt mir wohl kaum was anderes übrig :P ich nehm mal an, thorsten sieht ungern ne zweite version von mios hier rumgeistern. wenn noch jemand probleme mit den panasonic encodern hat und mios nicht selber anpassen will, dem kann ich ja meine version auf anfrage schicken. Grüße, Alex

also wenns n 2x20 sein soll/kann/darf, kann ich nur das weiß auf blau bei pollin empfehlen, bin mit dem echt superzufrieden: http://www.pollin.de/shop/detail.php?pg=NQ==&a=MjgzOTc4OTk=

to replace the "??" in his post entirely you missed: upload an application :-P /edit: oops should read more carefully, sorry for stupid post

Das fass ich einfach mal als Kompliment auf, danke :) (Auch wenn das Ganze wohl vor allem eine Frage der Muße ist :P ) Ich hab mir den MIOS32-Code mal angeschaut. bin weitgehend klar gekommen, lustigerweise hast du sogar die gleiche Reihenfolge für die Pins in ENC_STAT hergenommen, es sind also auch bei dir case 1 und 4, wo mein encoder zickt. Seh jetzt auch, warum das mit dem Erweitern bissl ungünstig ist. Nachdem sich ja die States für DETENTED2 und DETENTED3 gegenseitig ausschließen, hab ich die beiden einfach für meine States missbraucht. DETENTED1 ist damit zwar identisch mit UNDETENTED aber damit werd ich wohl leben können. Mein Table sieht jetzt so aus: JUMPTABLE_2BYTES_UNSECURE rgoto MIOS_ENC_Do_Nothing ; 0 rgoto MIOS_ENC_Do_Dec_D13 ; 1 - only if NON_DETENTED, DETENTED1 or DETENTED3 rgoto MIOS_ENC_Do_Inc_D12 ; 2 - only if NON_DETENTED, DETENTED1 or DETENTED2 rgoto MIOS_ENC_Do_Nothing ; 3 rgoto MIOS_ENC_Do_Inc_D13 ; 4 - only if NON_DETENTED, DETENTED1 or DETENTED3 rgoto MIOS_ENC_Do_Nothing ; 5 rgoto MIOS_ENC_Do_Nothing ; 6 rgoto MIOS_ENC_Do_Dec_D12 ; 7 - only if NON_DETENTED, DETENTED1 or DETENTED2 rgoto MIOS_ENC_Do_Dec_D12 ; 8 - only if NON_DETENTED, DETENTED1 or DETENTED2 rgoto MIOS_ENC_Do_Nothing ; 9 rgoto MIOS_ENC_Do_Nothing ; A rgoto MIOS_ENC_Do_Inc_D13 ; B - only if NON_DETENTED, DETENTED1 or DETENTED3 rgoto MIOS_ENC_Do_Nothing ; C rgoto MIOS_ENC_Do_Inc_D12 ; D - only if NON_DETENTED, DETENTED1 or DETENTED2 rgoto MIOS_ENC_Do_Dec_D13 ; E - only if NON_DETENTED, DETENTED1 or DETENTED3 rgoto MIOS_ENC_Do_Nothing ; F Funktioniert einwandfrei :D Vieeelen Dank für den Hinweis! Grüße, Alex

hallo, nachdem mich gestern die encoder doch ziemlich genervt haben, hab ich mal n bisschen ursachenforschung betrieben. Leider hab ich in Augsburg weder Werkzeug, noch Messgerät oder ähnliches. Ging aber auch ohne, und ich hab sogar ne Flick-Lösung in C gefunden :) Also nochmal das Problem im Detail: Bei den Pollin-Encodern gibt es einige (2-3) (Rast-)Stellungen, in denen der Rastpunkt ziemlich genau mit der Flanke des 2ten Encoder-Pins zusammenfällt. Liegt vermutlich am ungewöhnlichen (?) Aufbau des Encoders. Das führt nun dazu, dass der Pin bei der leichtesten Erschütterung umschaltet. Ich hab ursprünglich MIOS_ENC_MODE_DETENTED mit "Speed-Mode Fast (2)" verwendet. Laut der Übersicht http://www.ucapps.de/mios/mios_encoder_modes.gif ist das genau der erste INC-Übergang. Genau das beobachte ich auch in der Software: in DIN_ENC_NotifyToggle kommen zufällig "incrementer >0" an und mein zähler springt munter nach oben. da der DEC-Übergang auf einer anderen Flanke liegt, gehts auch nicht wieder nach unten. probeweise hab ich mal MIOS_ENC_MODE_UNDETENTED mit "Speed-Mode Normal" verwendet. Da hier jede Flanke ausgewertet wird, habe ich erwartet, dass nun abwechselnd +/-1 als incrementer ankommt. mein zähler würde also nicht mehr nach oben zählen sondern zufällig zwischen zwei benachbarten Werten wechseln. Interessanterweise kamen aber immernoch aufeinanderfolgende incrementer == +1. Also hab ich mal n bisschen nach Theorie zur Encoder-Auswertung gesucht und bin auch schnell fündig geworden http://www.hilpers.com/604594-prelldauer-bei-encoder-drehimulsgeber (kein schöner thread, aber die info, die ich gesucht hab, war drin) . Kurz zusammengefasst gibts im Wesentlichen folgende gängige Implementierungen: Abfrage: regelmäßiges Polling <-> Interrupt -da die Encoder am SR hängen, geh ich bei MIOS mal von ersterem aus Auswertung: Finite-State-Maschine <-> Ein Pin wird als Takt, zweiter als Richtung ausgewertet -die zweite Möglichkeit hab ich nicht hundertprozentig verstanden, aber laut dem Thread würde sie genau das beobachtete Verhalten erklären. Dafür braucht sie weniger Rechenleistung. Eine "saubere" Encoder-Implementierung verwendet also grundsätzlich eine Finite-State-Maschine zur auswertung, die Art der Abfrage spielt dann keine Rolle. Also hab ich mal meinen einen Encoder aus ENC_TABLE gelöscht und in DIN_NotifyToggle eine eigene Encoder-Auswertung geschrieben. Der Encoder funktioniert jetzt einwandfrei, allerdings komm ich bei allzu schnellem Drehen an die Performance-Grenzen. Liegt mit Sicherheit an C bzw. meinem noch optimierbaren Code. Die Zustände der Finite-State-Machine entsprechen der PinA/B-Kombination. Theoretisch möglich sind 16 Übergänge zwischen diesen Zuständen. Da nur benachbarte Zustände interessieren, sind nur 8 Übergänge relevant. Ich hab das ganze mal in ne Grafik gepackt: Mein Code is eigentlich ganz simpel. Er merkt sich bei nem neuen DIN_NotifyToggle-Aufruf den letzten Zustand und packt den mit dem neuen Zustand in ein variable, so dass darin letztendlich ein Übergang entsprechend der Tabelle oben enthalten ist. Hat diese den Wert 2 oder D, wird ENC_NotifyChange mit positivem incrementer aufgerufen, bei Wert 8 oder 7 mit negativem. Die wackligen Übergänge 1 und 4 spielen also gar keine Rolle mehr. Schöner wärs natürlich, wenn MIOS schon einen entsprechenden ENC_MODE hätte *zwinker* u.U. könnten die rastungen natürlich auch in die andere Richtung verschoben sein. Deshalb wären zwei neue Modi ne feine Sache: MIOS_ENC_MODE_DETENTED4 positiver incrementer für Übergang 2 und D, negativer für Übergang 8 und 7 MIOS_ENC_MODE_DETENTED5 positiver incrementer für Übergang B und 4, negativer für Übergang E und 1 BTW, mit is grad MIOS_ENC_MODE_DETENTED3 in mios_enc_table.inc aufgefallen. was macht denn der? Grüße, Alex