TK.

I just doublechecked your snapshot. Of course: you've assigned the MP output to the volume target twice. One time as generic Target1 and Target2 (which is normally not required), and then again with the "hardwired" targets Vol1 and Vol2 Just remove the Volume destination from Target1 and Target2 Best Regards, Thorsten.

Bei mir laeuft es eigentlich ziemlich stabil, selbst wenn ich mehrere Module hintereinander schalte (siehe auch ) Wie lang ist denn das Kabel zwischen Core und LRE8x2 Modul? (sollten hoechstens 30 cm sein) Und hast Du schon nach kalten Loetstellen gesucht? Gruss, Thorsten.

- are you using the new v2_044_pre1 firmware that I linked in the posting above? - did you configure the MP as described in topic [19] here: http://www.ucapps.de/midibox_sid_manual_ki.html ? Best Regards, Thorsten.

I guess that you mean, that this only happens when the "Play" button is toggled in the Ctrlr editor or on the CS. But that the envelope works correctly when MIDI notes are played, right? Here is a new version which should fix the problem with the "Play" button: http://www.ucapps.de/mios/midibox_sid_v2_044_pre1.zip Best Regards, Thorsten.

Yes, of course you don't need an optocoupler in such a "system", instead you can cross-link the Rx/Tx IOs directly as long as the grounds are connected together. It seems that this is a typical misunderstanding about MIDI. People think, that MIDI is slow because they only know the common physical layer which requires optocouplers for ground decoupling, and optocouplers reduce the bandwidth... But in a "closed system" (inside a MIDIbox) this doesn't matter, IOs can be directly connected and the baudrate can be increased by factor 10 and more. In fact MIDI is still a very efficient protocol to interconnect sequencers and synthesizers. Just consider that it has been defined at a time where microcontrollers ran 100 times slower than today. Accordingly the protocol avoids any unnecessary overhead - and therefore should still be the first choice if performance does matter. To give you a comparison: the sampler only listens to a single MIDI channel, therefore the "running status" optimisation can be used (handled by MBSEQ by default). The transmission of Note and Velocity will require 2 bytes. At the standard MIDI baudrate this will take 640 uS At a 10x higher baudrate only 64 uS... and I guess that we could even go for 20x or even 50x! Best Regards, Thorsten.

Yes, a MIDI connection would be the most simple way to connect the cores. You could increase the baudrate at both sides to reduce the latency, especially if no optocoupler is used. (I will check the max possible baudrate tomorrow) Alternative solutions: - use MBNET, resp. communication via CAN - but both applications are not prepared for this - even faster: use SPI - again both applications are not prepared for this So, the alternative solutions would be a nice challenge for the case that you want to improve your programming skills ;) But at the end I think, that an increased UART baudrate is already sufficient to ensure a good "user experience", and that you won't notice a big difference with the alternative solutions. Best Regards, Thorsten.

I checked this today, and found the reason: my initial hint to increase the MP depth wasn't complete! I added the new topics [19] and [20] to the "known issues" page to inform everybody about the intended usage of the modulation matrix: -> http://www.ucapps.de/midibox_sid_manual_ki.html 19] An envelope doesn't sweep through the whole value range: yes, this is true if only the ENV depth is set to maximum level (+127). With the default configuration of the modulation matrix, this will result into a quarter of the available value range. E.g. if the filter cutoff is set to 0, ENV depth set to 127, the filter will only sweep between 0%..25%. Same for volume. In order to sweep through the whole range, the modulation path parameters have to be changed: enter the MOD page select MOD 1 (if not already done) for EG1 you will notice, that EG1 is only assigned to Sr1 - assign it also to Sr2, and ensure that the "1+2" operator is selected -> this will double the ENV level in addition, set the Depth parameter of the modulation path to 127 -> this will double the MP level As the result, you will get an envelope which sweeps through the whole value range from 0% to 100% [20] The AOUT channel is always at maximum level when the V2A option is used: because the volume parameter in the CFG page sets the offset for this AOUT routing option. Change the volume to 0 to set the offset to 0V (similar to CutOff) Best Regards, Thorsten.

Hi, in the src/lc_hlp.inc file you will find a "LC_HLP_MsgCursorPos" table, which allows to specify, where LC characters should be print on the LCD E.g.: LC_HLP_MsgCursorPos JUMPTABLE_2BYTES 55 ;; (55 table entries) retlw 0x00 + 7 retlw 0x00 + 8 retlw 0x00 + 9 retlw 0x00 + 10 retlw 0x00 + 11 retlw 0x00 + 12 retlw 0x00 + 13 retlw 0x00 + 16 retlw 0x00 + 17 ... By default, the LC screen will be spreaded over two 2x40 LCDs (makes 2x80) But you could also use this mechanism to remove characters... something like: LC_HLP_MsgCursorPos JUMPTABLE_2BYTES 55 ;; (55 table entries) retlw 0x00 + 0 retlw 0x00 + 1 retlw 0x00 + 2 retlw 0x00 + 3 retlw 0x00 + 4 retlw 0x00 + 63 ; not used retlw 0x00 + 63 ; not used retlw 0x00 + 5 retlw 0x00 + 6 retlw 0x00 + 7 retlw 0x00 + 8 retlw 0x00 + 9 retlw 0x00 + 63 ; not used retlw 0x00 + 63 ; not used ... the disadvantage is, that the LCD won't display the full message sent by the DAW But if you can live with this limitation, then try it out. In general the configuration of a MBNG is much easier, because the application doesn't need to be rebuilt for customizations. See also: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fmidibox_ng_v1%2Fcfg%2Ftemplates%2Flogictrl.ngc The cursor mapping table (described above) exists as well, it's just easier to read (and to modify): # X cursor positions are defined in MAP1 # spread message over two 2x40 LCDs MAP1 2 3 4 5 6 7 8 \ 12 13 14 15 16 17 18 \ 22 23 24 25 26 27 28 \ 32 33 34 35 36 37 38 \ 42 43 44 45 46 47 48 \ 52 53 54 55 56 57 58 \ 62 63 64 65 66 67 68 \ 72 73 74 75 76 77 78 It provides 4 USB MIDI ports, so that you could run multiple LC emulations in parallel (each LC needs a dedicated port). Best Regards, Thorsten.

Welcome back! :) yes unfortunately nobody found a solution yet. confirmed Best Regards, Thorsten.

Cool! :smile: Btw.: I gave you access to the programmers lounge of the forum, where you will find additional informations about MIOS32. Best Regards, Thorsten.

Servus, Wie machst Du das denn genau? Und: hast Du das zweite LCD schonmal getestet? Was passiert bspw. wenn Du folgendes Kommando im MIOS Terminal eingibst: lcd @(2:1:1)Second LCD tippe mal folgendes Kommando im MIOS Terminal: set debug on so wird mit jedem Taster oder Encoder-Event eine Meldung generiert Gruss, Thorsten.

You are right, your schematic is wrong there: the CS line of the 9th display has to be connected to the leftmost data output of a MBHP_DOUT module, accordingly to D7 (in your schematic called QH) This is consistent to the typical mapping of LEDs: the first LED is located at the leftmost output pin of a MBHP_DOUTX4 module. Best Regards, Thorsten.

CS doesn't need to be toggled, the datasheet only shows a simple access example. So: I bet that one or more connections are wrong, especially because KS0108 type displays are usually very easy to handle (there are no error prone configuration sequences). Best Regards, Thorsten.

You are sure that the data lines are connected correctly? What happens if you replace the code in APP_Background by: void APP_Background(void) { MIOS32_LCD_GCursorSet(0, 0); MIOS32_LCD_Data(0x01); MIOS32_LCD_Data(0x02); MIOS32_LCD_Data(0x04); MIOS32_LCD_Data(0x08); MIOS32_LCD_Data(0x10); MIOS32_LCD_Data(0x20); MIOS32_LCD_Data(0x40); MIOS32_LCD_Data(0x80); while( 1 ); // wait endless } I expect that you will see some kind of backslash at the upper left corner of the GLCD Best Regards, Thorsten.

You could doublecheck if the CS voltage is the problem with following configuration (has to be done with the bootloader update app): set lcd_type 0x81 set lcd_width 64 So that the non-inverted CS option is selected, and only the first half of the KS0108 LCD is accessed. Now tie CS1 to 5V - do you see a "valid" picture? Best Regards, Thorsten.

Hi, this is normal - in this application the LED will flash whenever the LCD will show a new picture. Does this also happen when the lcd_type 0x82 (==GLCD_KS0108_INVCS) is selected? Your datasheet specifies that VIH should be 3.5V minimum, so that 3.1V could be problematic (but I'm unsure). Do you have access to an additional 74HCT541 (or similar level shifter) to pull this signal to 5V? Best Regards, Thorsten.

Wow, good catch Duggle! I haven't expected that a serial termination makes a big difference in this case. I just have noticed, that the test application doesn't support more than 12 displays, because it has been developed before I added the J28 SR extension. This means, that actually Display 13-16 should be black! (Shame on me that I only tested the CS 9 and 10 yesterday, and not all pins...) So, could you please check this new build: http://www.ucapps.de/tmp/mios32_test_app_lcd_ssd1306_LPC1769_16OLEDs.zip MBNG should already allow you to access all displays. You can try this by entering following LCD commands: lcd @(1:1:1)OLED1 lcd @(2:1:1)OLED2 lcd @(3:1:1)OLED3 lcd @(4:1:1)OLED4 lcd @(5:1:1)OLED5 lcd @(6:1:1)OLED6 lcd @(7:1:1)OLED7 lcd @(8:1:1)OLED8 lcd @(9:1:1)OLED9 lcd @(10:1:1)OLED10 lcd @(11:1:1)OLED11 lcd @(12:1:1)OLED12 lcd @(13:1:1)OLED13 lcd @(14:1:1)OLED14 lcd @(15:1:1)OLED15 lcd @(16:1:1)OLED16 into MIOS terminal while the MBNG firmware is running Best Regards, Thorsten.

Yes, this will be the only way to analyze it further. Just use two probes, and compare the signals at the D0 and D1 pins (e.g. compare with Display 1) And also check, that the CS lines are strobed from the 74HC595 Best Regards, Thorsten.

Ok, now I remember The problematic function isn't Timer(), because it doesn't do that much. It just increments a timestamp. Instead, TASK_MatrixScan causes the problem, because this task (with priority 2) is running in an endless loop, so that lower prio tasks will never be executed. This part should be overworked. Maybe the best way would be to take this tutorial as a template: http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Ftutorials%2F029_keyboard_velocity%2F In difference to the code that I gave you some time ago, it uses the SRIO driver. While the SRIO driver scans the shift registers via DMA, other tasks can be executed - and this gives you more than enough processing power to handle the LCD. I could integrate your code into this framework if you want (I can do and test this on sunday) But of course you could also try this by yourself :smile: Best Regards, Thorsten.

If 4bit mode is still for interest: you need a different USER_LCD_Data and USER_LCD_Cmd routine, because the one from the src/app_lcd.inc of the MBSID V2 application is only applicable for 8bit mode. USER_LCD_Data should look like: USER_LCD_Data ;; store byte in data latch movwf USER_LCD_LAT_D ;; wait until display unbusy rcall USER_LCD_WaitUnbusy ;; exit if current LCD not available due to timeout btfsc USER_LCD_STATUS, USER_LCD_STATUS_CUR_DISABLED, BANKED return ;; select data register bsf USER_LCD_LAT_RS, USER_LCD_PIN_RS ;; activate write bcf USER_LCD_LAT_RW, USER_LCD_PIN_RW ;; strobe rcall USER_LCD_Strobe_Set rcall USER_LCD_Strobe_Clr ;; transfer lower 4 bit swapf USER_LCD_LAT_D, F ;; strobe and exit rcall USER_LCD_Strobe_Set rgoto USER_LCD_Strobe_Clr and USER_LCD_Cmd: USER_LCD_Cmd ;; store byte in data latch movwf USER_LCD_LAT_D ;; wait until display unbusy rcall USER_LCD_WaitUnbusy ;; exit if current LCD not available due to timeout btfsc USER_LCD_STATUS, USER_LCD_STATUS_CUR_DISABLED, BANKED return ;; select command register bcf USER_LCD_LAT_RS, USER_LCD_PIN_RS ;; activate write bcf USER_LCD_LAT_RW, USER_LCD_PIN_RW ;; strobe rcall USER_LCD_Strobe_Set rcall USER_LCD_Strobe_Clr ;; transfer lower 4 bit swapf USER_LCD_LAT_D, F ;; strobe and exit rcall USER_LCD_Strobe_Set rgoto USER_LCD_Strobe_Clr this is untested code! Please also replace the (wrong): movlw 0x01 ; /////////////////////CGRAOM 248 COGRAM 8 Select ROM A movwf USER_LCD_LAT_D rcall USER_LCD_Strobe_Set rcall USER_LCD_Strobe_Clr movlw 50 ; 50 ms delay call MIOS_Delay rcall USER_LCD_Strobe_Set rcall USER_LCD_Strobe_Clr movlw 50 ; 50 ms delay call MIOS_Delay rcall USER_LCD_Strobe_Set rcall USER_LCD_Strobe_Clrby: movlw 0x01 ; /////////////////////CGRAOM 248 COGRAM 8 Select ROM A rcall USER_LCD_Dataand doublecheck later, if 0x09 is maybe the better value Best Regards, Thorsten.

Wow - 10mil is pretty small! Are you also using this width for the 3.3V and GND tracks? If yes: solder a cable between a central GND and central 3.3V point to the Vs/Vd inputs of an OLED which currently doesn't work if CS is connected to ground, does this help? If not: do the same for SDA and SCLK, solder the cables directly from pin P1.27 and P1.29 You could use wires from a ribble cable for this test. you could try it without C, and with R=100 and R=220, maybe this works better (but without a scope it will be difficult to find out the best fitting values) But it seems that we should more focus on your layout ;-) Best Regards, Thorsten.

Hm... maybe it makes sense to talk about your layout. How are the D0/D1 (resp. SCLK/SDA) lines routed? If you haven't routed short connections between the displays, then this could explain the issues as well, especially your last test where the CS lines of display 9..16 are tied to ground. Termination could help. Here an interesting thread about this topic with many pictures and possible solutions: Best Regards, Thorsten.

Could you please doublecheck, that the BS0/BS1/BS2 jumpers are soldered to ground (0) and not to Vcc (1) for all displays? If the jumper settings are incorrect at one or more displays, D0 will have a different function and would disturb other displays. Best Regards, Thorsten.

Oh yes, of course this could be the case. Yes We should review your app, maybe there is a way to optimize the execution time, so that lower prio tasks can be serviced again. Could you please attach your app.c file to this posting? Best Regards, Thorsten.

The strange display behaviour could be related to corrupted data transmissions. E.g. changes in the brightness, ghost pictures, missing pixels, etc. can happen when a command word isn't transferred correctly. In order to check this, I compiled another test where the serial data (via D0/D1) is transferred slower than in the original configuration. Please try it: http://www.ucapps.de/tmp/mios32_test_app_lcd_ssd1306_LPC1769__slow_serdata.zip 2) to displays 9-16: in order to find out, if this is related to the 74HC595 shift register which drives the CS lines, it would be interesting what happens if the displays are always selected. Means: remove the 74HC595 ( named "IC DISP-SEL" in your schematic) from the socket, and tie all CS lines (QA..QH) to ground. Any change? 3) also to displays 9-16 (regardless if test 2 is passing): disconnect displays 1-8 if possible. If not possible (you haven't mentioned yet, if the LCDs are plugged into sockets), remove IC2 from the socket, and tie QA..QH to 3.3V in order to ensure, that the CS lines are not activated For each test it will be required that you power-off the core for at least 5 seconds. This ensures, that all LCDs are starting with a fresh power-on reset Best Regards, Thorsten.