TK.

Probierst Du bitte mal folgende Firmware aus: http://www.ucapps.de/mios32/midibox_seq_v4_070_j15pp.zip Es waere interessant zu wissen, ob mit dem modifizierten LCD Treiber immer noch lediglich 2.5V an RW anstehen, oder die vollen 3.3V (unabhaengig vom J15_S Jumper - der Pin kann keine hoeheren Spannungen treiben) Vielleicht funktioniert das Display nun sogar auf Anhieb ;-) Gruss, Thorsten.

I've a new hypothesis which has to be proven - could you please check the following two firmwares at your side: http://www.ucapps.de/mios32/midibox_seq_v4_070_j15pp.zip http://www.ucapps.de/mios32/midibox_seq_v4_070_j15pp_fastsr.zip With both versions Duggle was able to get 18 CLCDs connected in parallel (!) running - my hope is, that it also helps to solve the issue with your LCDs Best Regards, Thorsten.

Ok, I see the problem - the factor is too low (actually it's not a factor, but a divider which has to scale down the 10bit value into the 7bit range). But apart from this configuration issue, it also makes sense to add a proper saturation. So, here are the steps: change: unsigned char value_7bit = 0; to: unsigned int value_7bit = 0; This ensures, that a rollover can be detected properly. Before the ACMath_Scale call, write: if( value_7bit > 127 ) value_7bit = 127; This ensures that the conversion value is within the 0..127 range before it will be scaled. Nevertheless, increase the "factor", otherwise the sensor will saturate to 127 quickly. Best Regards, Thorsten.

Hi, it would be important to know, which parameters you are using exactly. Such as sMin, sMax, sFrom, sTo, sFactor Nest Regards, Thorsten.

Hi Braintu, note that the LPC1769 has internal pull-up devices, which are normally activated by MIOS32 when GPIOs are used as inputs. Therefore you won't find such pull-ups on typical IO ports on the MBHP_CORE_LPC17 module, such as J5A/B or J10 The biggest problem is, that we are living in Germany... ;-) This not only means that higher production and investment costs have to be considered (somebody told me once, that assembly companies typically expect at least 100 boards for a run in the fab). But this also means, that you've to consider all this strange legal stuff such as CE, RoHS, EAR, WEEE, etc... here a good entry point for the never ending discussions about such topics: http://www.mikrocontroller.net/topic/176076 The most simple way to bypass such restrictions would be to sell the pre-assembled boards outside Europe. This is what we did for the MBHP_CORE_STM32 module via SmashTV - but it was a different situation, since it was the only 32bit module at this time; the demand was high enough, and Smash fortunately managed to phase out the module before the next, more powerful MBHP_CORE_LPC17 came up, so that his pre-investions didn't get lost. In your case I fear, that the demand is not high enough - and that you will have to organize and handle the whole topic by yourself. Of course, I could be wrong... let's see how many people evince their interest in this thread. Best Regards, Thorsten.

The next MBNG version will support SED1520 based GLCDs: This display controller is very similar to KS0108 - which means that a lot of cables have to be connected to J15 and J28. Also the number of supported displays is limited to 4 maximum! But what makes this display attractive is the low price: http://www.pollin.de/shop/dt/MzM0OTc4OTk-/Bauelemente_Bauteile/Aktive_Bauelemente/Displays/LCD_Modul_WINTEK_WD_G1203T.html -> only 1.95 EUR! :smile: Schematic: http://www.ucapps.de/mbhp/mbhp_lcd_sed1520_mios32.pdf Best Regards, Thorsten.

Very interesting story which will definitely help others to understand the possibilities with MBNG :) Best Regards, Thorsten.

If the module is only accessible via MIDI, the synth engine of MBFM wouldn't really help, because it needs direct access to the sound registers for fast updates. So - if you are searching for a CS, MBNG would be the preferred choice because of the much higher flexibility compared to old PIC based controllers. MBSEQ V4 would be a good choice, if you would like to focus on sequencer functions. But the complexity of this project is much higher. Best Regards, Thorsten.

Do you have programming skills? Are you planning to use an existing application as a basis, or do you expect that it will work without changing the application code? Best Regards, Thorsten.

P1.25 geht zum SCLK Eingang des seriellen Shift Registers - dieses hochfrequentes Signal kannst Du so ohne weiteres nicht messen. P1.26 geht zum RCLK Eingang des seriellen Shift Registers - es steht die meiste Zeit auf 0V P1.27 ist das RW Signal, es steht entweder auf 0V oder 3.3V - je nachdem, was der LCD Treiber gerade macht. Aber Du kannst es ja auch mit dem "testlcdpin" Kommando direkt ansteuern. Wenn Du den LPC abziehst, werden die LCD Control Signale (somit auch P1.27) ueber die R33 Pull-Ups auf 5V gezogen, das passt. P1.25 und P1.26 werden in dem Fall nicht mehr getrieben, eigentlich solltest Du dann auch keine 5V mehr messen. Wenn am RW Pin nun ploetzlich nur noch 2.5V anliegt, dann verhaelt es sich wie bei einem Kurzschluss zwischen zwei Pins. Generell ist es uebrigens sehr einfach herauszufinden, ob der Fehler eher am Core Modul, oder am Kabel bzw. LCD liegt. 1) LCD abstoepseln, und die Spannungen der einzelnen Pins mit dem testlcdpin Kommando direkt an J15A messen 1a) Spannungen passen? -> Fehler liegt nicht am Core Modul, weiter bei 2) 1b) Spannungen fehlerhaft? -> Fehlersuche am Core Modul fortsetzen. 2) LCD anschliessen, und die Spannungen nochmal durchmessen Wenn nun eine Spannung nicht mehr den erwarteten Level erreicht, weisst Du, wo bspw. ein Kurzschluss (oder ein Kabeldreher) vorliegen koennte. Gruss, Thorsten.

Die Spannungen an den LPCXPRESSO Pins passen soweit Warum misst Du an RW/RS/E1/E2 eine andere Spannung als direkt an den LPCXPRESSO Pins? Oder hast Du zwischenzeitlich den Jumper J15_S auf 3v3 gesteckt? Er sollte auf 5v0 stehen, ansonsten wird Dein LCD mit einer zu niedrigen Spannung versorgt. Nachdem die Spannung geaendert wurde, muss der Core reseted werden, damit das LCD neu initialisiert wird. Gruss, Thorsten.

I'm unsure if just only the wording is wrong... these three signals shouldn't be connected together to a single signal. But if you mean if RS can be connected to all DC inputs of the OLEDs, and RW to all SDA (D1) inputs, and E to all SCLK (D0) inputs: yes, of course. The wires should be named DC, SDA and SCLK, because this is the function of the signals. Best Regards, Thorsten.

Yes, chords can be entered for each step. Best Regards, Thorsten.

A minor improvement which hopefully helps if you are facing issues with multiple connected LCDs: MIDIbox NG V1.016 ~~~~~~~~~~~~~~~~~ o LPC17: robustness of LCD driver has been improved Best Regards, Thorsten.

Some minor improvements: Best Regards, Thorsten.

Hallo, aus meiner Sicht alles wie erwartet. Der Teufelskreis laesst sich auch anders brechen, doch Du hast letztendlich eine Loesung gefunden! Wenn Microsoft faehige MIDI Experten haette, waere das alles nicht passiert! :rolleyes: Gruss, Thorsten.

Update: V4.070 got a new MIDI->Ext.Ctrl page which allows to assign externally controlled functions to CCs and Program Change Events. It especially allows to change all patterns, or the phrase, or the song number via a Program Change event. Best Regards, Thorsten.

I checked this, but unfortunately I see no way to change (resp. sort) the order due to RAM limitations. Best Regards, Thorsten.

Finally V4.070 is available with a some requested features: Best Regards, Thorsten.

Martijn could sell you a ready-made MIDIbox SEQ V4 Lite. In order to establish the communication channel, I passed him your email address, so that he can directly contact you. Yes, arpeggiator (resp. transposer) and live recording are standard. The complete documentation can be found under: http://www.ucapps.de/midibox_seq_lite.html Best Regards, Thorsten.

Maybe a plausible answer: do you supply your MBHP_CORE_LPC17 module directly from your PC, or are you using an external PSU, resp. an USB hub with PSU? The LPC17 consumes more power than a STM32 due to the higher clock rate. The backlight of the second LCD will increase the power consumption as well, which could lead to an unwanted voltage drop. Best Regards, Thorsten.

See this changelog (the CC has been moved to a different number based on Wilba's request - it was in conflict with a MIDI handling issue in FL Studio) Seems that I forgot to update the chart, I'm sorry for the confusion! Addendum: actually I updated the original chart, which is also part of the release package: http://svnmios.midibox.org/filedetails.php?repname=svn.mios&path=%2Ftrunk%2Fapps%2Fsynthesizers%2Fmidibox_fm_v1%2Fdoc%2Fmidibox_fm_cc_voice.txt Where did you find the link to this expired file? Best Regards, Thorsten.

Great! :smile: To be honest: I've no plausible answer why this is the solution for the issue. Actually it was the last (un)likely reason why such a failure could happen. The serial input pins of a 74HC595, which are now driven at a slower rate, are not directly connected to the LCDs - the load shouldn't change if more than one LCD is connected to a 74HC595 - but somehow we've an unexpected dependency which isn't understood. Duggle helped a lot by giving the right details at the right moment - but I'm still not able to reproduce this at my side. Best Regards, Thorsten.

Hi, MIDIO128 always loads the "DEFAULT.MIO" file during startup. So, just store your configuration under this name. Best Regards, Thorsten.

You missed the context! It's totally clear to me what you want to achieve, and if you read the linked posting again you will notice that I'm trying to cover multiple requests with a single method. The method isn't implemented yet, which means in other words: it doesn't work because it's still in the planning phase. In order to determine, if the proposed method is sufficient, I'm asking for feedback to find out, if other usecases would lead to an unwanted conflict which requires a different approach. Best Regards, Thorsten.