TK.

Hi, this application can't be built with MPLAB, please use gputils instead as recommended via the README.txt (the README links to a Wiki page which describes the details). However, here a quickstart for you without the need to install the complete toolchain. Only install gputils: http://sourceforge.net/projects/gputils/files/gputils-win32/0.14.3/gputils-0.14.3.exe/download Thereafter open a cmd terminal, change to the midibox_cv_* directory, and enter following command in the command line: Best Regards, Thorsten.

V0 has only an effect on the contrast. If you already saw the black row after power-on, it won't help to increase the voltage. This case still puzzles me, because from the datasheet I would say that these are pretty good LCDs where no compatibility issues have to be expected. :-/ If you can't find a way to get them working, and before you throw them away, just send me one or two LCDs so that I can test them at my side. Best Regards, Thorsten.

This sounds like a power integrity issue, which could maybe be solved by adding 100n caps between some (or all) 3.3V and GND inputs of the OLEDs. I would start with OLED 9: add a 100 nF cap there. Do you already notice a change with this measure? If not: add also 100 nF caps to OLED 1, 5, (9), 13 (each fourth display) - any change? Each display should show the GLCD number. The first one "SSD1306 #1", the second one "SSD1306 #2", etc... Can you see this as well, or are the numbers changing? I fixed the warning. I wrote this test at a time where the ROTATED feature didn't exist. Best Regards, Thorsten.

Ok, but this gives me a totally new impression about what you mean with "get these displays running". Actually at least the first 8 displays are working, because it seems that they are properly initialized (which is already a big success) and print out messages. Of course, it's wrong that (almost) all of the first 8 displays print out the same message, and that the remaining 8 displays don't print anything. I would expect, that after a "store" or "restore" command each display prints out a different message. But these symptoms bring much more light into the story. Before we continue the remote analysis, it would be interesting to know, if you've used sockets for the display connections, so that you are able to remove displays? Because the first interesting test would be the following: what happens, if you upload this application: http://www.ucapps.de/tmp/mios32_test_app_lcd_ssd1306_LPC1769.zip The second interesting test: what happens, if only the second display is connected to the socket, and all others are removed. IMPORTANT: power-off the core while removing the OLEDs! Best Regards, Thorsten.

Hallo Dee, tja, besonders wegen des "etc." und "genau so" wird es problematisch, eine passende Alternative fuer Dich zu finden. ;-) Andererseits wuerde es mich wundern, wenn Doepfer diese Control-Platine nicht zumindest als Ersatzteil anbieten wuerde. Hast Du schonmal direkt beim Vertrieb nachgefragt? Gruss, Thorsten.

I guess that you mean sm_c_example1 with the sm_simple.asm driver, and that you want to use the DIN shift register selected with SM_ROW_DIN only partly for a matrix. Some remaining pins of this SM_ROW_DIN should be used for normal button functions, right? Yes, this is possible. Since the driver uses "MIOS_DIN_SRGet" instead of "MIOS_DIN_ChangedSet00", you even don't need to touch the .asm file DIN_NotifyToggle() should be called on any pin toggle. So, just filter out the pins which are part of the matrix, all other pins can be used like "normal" inputs. Best Regards, Thorsten.

Cool! :smile: I'm not a windows expert and therefore can't give you so many hints on driver issues. At least it works on the two PCs I've access to - under WinXP and under Win7, without GM5 driver only when "single_usb" mode has been configured with the bootloader application, and with GM5 driver also when multiple ports are allowed ("single_usb off") There is an alternative driver from KORG which might work better: (you've to de-install the GM5 driver first before installing a new one) Best Regards, Thorsten.

I can only see a single error: P1.27 has to be connected to SDA and the OE# line of IC2 But this could also be a drawing mistake in the schematic, right? Which LCD configuration are you using exactly? You can find this out by uploading the MIOS32 bootloader update application (makes sense to use the latest release) Enter "help" and copy&paste the terminal output into this posting. Best Regards, Thorsten.

this isn't really required, the linked cores are working fine no, because it's only a minor issue which can be easily handled with the proposed procedure at the user side Please also see: how often do you want to reconfigure your MBHP_MF_NG modules in future? (maybe never again.. ;-) And the procedure can be easily handled in MIOS Studio, no need to open your MIDIbox, or to change connections or whatever... just temporary change the endpoint into a forwarding point via the MBHP_MF_NG tool in MIOS Studio, and you will be able to configure the other modules as well. it's due to a conceptional flaw which can't be fixed. Best Regards, Thorsten.

Actually you would have to remove one strobe, because currently you transfer 3 nibbles instead of 2 And you transfer three times a 0 (-> would result into 0x000), because in 4bit mode only the data at the D7, D6, D4 and D4 pin will be taken over by the LCD. The 4 bit protocol is: first strobe for the MSBs (data bits 7..4 directly visible at D[7:4]), second strobe for the LSBs (data bits 3..0 copied to D[7:4], e.g. via "swapf LATD, F") You can see the difference in the original implementation: http://svnmios.midibox.org/filedetails.php?repname=svn.mios&path=%2Ftrunk%2Fmios%2Fmios_clcd.inc General hint: if you do such experiments (with the danger that the LCD comes into an invalid mode), it makes sense to re-power the core after the code upload to ensure that it starts under "known conditions" (power-on reset). In 4bit or 8bit mode? Possible reason: USER_LCD_Data is only made for 8bit mode Anyhow, currently I'm a bit confused about your posting. :-/ - are you planning to use the LCD in 4bit mode in future - and if yes: why? You've already all connections for 8bit mode - is the LCD working correctly in 8bit mode now? Best Regards, Thorsten.

Yes, just select any AOUT interface, such as MBHP_AOUT Up to 8 shift registers can be assigned to the trigger function, and each shift register provides 8 outputs. You just specify the shift register number. If you want to use the 5th shift register, you've to specify: DOUT_GATE_SR1 5 DOUT_GATE_SR2 0 DOUT_GATE_SR3 0 DOUT_GATE_SR4 0 DOUT_GATE_SR5 0 DOUT_GATE_SR6 0 DOUT_GATE_SR7 0 DOUT_GATE_SR8 0 # if set to 1, the DOUT "gates" will send 1mS pulses # useful for analog drums DOUT_1MS_TRIGGER 1 Best Regards, Thorsten.

Ok, I found two problems: 1) MBNG forwarded the SysEx stream multiple times, which resulted into garbage. This issue is now fixed in following version: http://www.ucapps.de/mios32/midibox_ng_v1_027_pre4.zip 2) there is a conceptional issue with the MIDIbox Link in such a configuration when the firmware of forwarding points should be updated or configured. But there is also an easy to use workaround which should be sufficient. I documented this in the header of this .ngc file: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fmidibox_ng_v1%2Fcfg%2Ftests%2Fmf_multi.ngc Everything is working at my side now, I hope that you've the same luck! :) Best Regards, Thorsten.

It could be, that your programmer doesn't clear the ID bits - in this case, the wrong baudrate will be selected. There is a workaround which is documented here: http://www.ucapps.de/howto_debug_midi.html Search for "TEST SW2" Best Regards, Thorsten.

According to the datasheet of your OLED, the ROMA character set will print out an ö instead of | It seems that ROMC is better suitable. The C code shows how to change it: Write_Command(0x72); //Function Selection B. Select the character no. of character generator Select character ROM Write_Data(0x01); //CGRAOM 248 COGRAM 8 Select ROM A I guess that you've to Write_Data(0x09) instead (see http://www.buy-display.com/download/ic/US2066.pdf, page 29) A reboot indicates that the USER_LCD_WaitUnbusy takes too much time. In other words: sometimes extremely much time (> 100 mS) - not desired anyhow. This could be caused by a protocol incompatibility with your display. On the other hand: it seems that this LCD is so fast, that maybe the BUSY flag doesn't need to be polled at all! :smile: Could you please check what happens if USER_LCD_WaitUnbusy just returns immediately without polling the status flags? Best Regards, Thorsten.

it is (I upgraded last week as well) - I just haven't updated the documentation yet (/edit: now done) no, I'm sure that it has no influence (I used MIOS Studio a lot during the weekend ;-) I will try it at my side this evening. Best Regards, Thorsten.

Yes, you mixed up the devices. I changed the wording to avoid such confusion. - the on-board Audio DAC is always available - the SDIO interface is not available due to pin conflicts with the Audio DAC - only one channel of the integrated 12bit DAC (part of STM32F407) is available - no killer, one channel is still enough, e.g. to generate CV. It can be multiplexed with external S&H buffers. - the second channel of the integrated DAC is not available due to pin conflicts with J16, which is used to access a SD Card. Best Regards, Thorsten.

Easy :smile: set kb <1|2> din_inverted <on|off> This option should be enabled if diodes are used with the opposite polarity, and pull-downs are connected to DINs. Examples: set kb 1 din_inverted off: diodes with "normal" direction and pull-up resistors at 74HC165 set kb 1 din_inverted on: diodes with opposite direction and pull-down resistors at 74HC165 If you are using the MBHP_DIO_MATRIX module, the pull-ups can be turned into pull-downs by switching the J6 jumper. Best Regards, Thorsten.

Yes, one DAC channel will be available :) Status: all drivers have been ported and tested, by building a prototype I also validated the IO pinning in the schematic. No errors found. I also started with the MBHP_CORE_STM32F4 page: http://www.ucapps.de/mbhp_core_stm32f4.html Best Regards, Thorsten.

V1.013 is available under http://www.ucapps.de/mios32_download.html fixes the "single_usb" display problem as reported by Duggle above fixes a potential race condition between the core and MIOS Studio for devices with slow flash sector erase times (however, I only noticed this problem on a STM32F4 device yet) support for STM32F4DISCOVERY and the upcoming MBHP_CORE_STM32F4 :smile: -> http://www.ucapps.de/mbhp_core_stm32f4.html Best Regards, Thorsten.

Just to doublecheck: are you using the latest MBHP_MF_NG firmware (v1.004), and did you select channel 2 for the second core in the MBHP_MF_NG configuration tool? It's also important that this change will be permanently stored in EEPROM by pushing the SEND button in the tool. Best Regards, Thorsten.

In theory this should be possible to measure the velocity with these sensors, but it would require (some small and easy to integrate) software changes. The internal LEDs of the opto sensors have to be permanently activated, which means that time multiplexing won't work. Instead, each sensor output has to be connected to a dedicated DIN input. No DOUTs required. I would strongly recommend you to try it out with one or three 78-TCUT1350X01 (double sensors) before buying the complete set for your piano. I can help you with the software extension (because it's easy to test at my side, and could also be useful for other projects) Best Regards, Thorsten.

Hi, This could be related to a USB driver issue under Windows In your snapshot I can see that it worked once, therefore: what happens if you try it multiple times? Could you please also check the same with the GM5 driver? yes, the MBSEQ_HW.V4 file will only be loaded after power-on (or after you typed "reset" into the MIOS Terminal). It won't be loaded when you reconnect the SD Card. This should ensure, that somebody is able to swap a SD Card with an incompatible MBSEQ_HW.V4 file (e.g. from a different MBSEQ hardware) without overwriting the initial hardware settings. yes, because you have to reset the core to load the changes. yes, because no AOUT interface has been selected in the CV configuration page. Best Regards, Thorsten.

The sample player is now also working on the STM32F4DISCOVERY board, which is probably the cheapest solution for this project, because it has an on-board Audio DAC! :) More about this topic soon. A refreshed all precompiled binaries: http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fsynthesizers%2FSD+card+sample+player%2F under release/* NOTE: I changed the MIDI channel assignment, now "midichannel 1" really assigns to the first MIDI channel, and not to channel 2 (previously it was counted from 0, which wasn't obvious) Best Regards, Thorsten.

Some progress: most drivers have been adapted and they are working. Missing: ADC, J10, J5, CAN - they should be available by end of this week. Tested: USB, UART, SPIs, IIC, I2S (Audio), SD Card, LCD Preliminary schematic: http://www.ucapps.de/mbhp/mbhp_core_stm32f4.pdf NOTE: the chip select line for the SD Card (J16.RC1) is now located at pin PB2! There is a new bootloader which works more stable when large blocks are erased: http://www.ucapps.de/mios32/mios32_bootloader_v1_013_pre4.zip I also tried out the SD Card Sample Player and created a precompiled binary: http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fsynthesizers%2FSD+card+sample+player%2F it can be found under release/STM32F407VG NOTE: I changed the MIDI channel assignment, now "midichannel 1" really assigns to the first MIDI channel, and not to channel 2 (previously it was counted from 0, which wasn't obvious) Best Regards, Thorsten.

done in MIOS Studio 2.4.6 -> Best Regards, Thorsten.