TK.

You will find it in a package (.zip file) once I make the first release of the application. Meanwhile just copy&paste the content (as described by Shuriken), or checkout the SVN repository (svn://svnmios.midibox.org/mios32) with a SVN client. Best Regards, Thorsten.

Hi, welcome on board! :smile: This surprises me, because I would expect 3.3V here Are you sure that it's 5V? Then it very likely related to an unintended bridge on the board, e.g. caused by a big soldering blob between the Tx track and a 5V track. Best Regards, Thorsten.

It's either related to a wrong configuration or to a misinterpretation of the LED at your side. I tested the execution time of the while() loop in apps/mios32_test/app_lcd/ks0108. On a LPC1769 one iteration takes ca. 10 mS, whereas on a STM32F4 it takes ca. 5 mS - so, definitely faster. :wink: Possible wrong configuration: check the LCD parameters in the bootloader. For KS0108 you've to specify lcd_num_x 1 and lcd_num_y 1, because the two GLCDs are handled like a big display with 4 segments (this is the way how the driver is implemented) If you've specified lcd_num_x 2, the driver would try to access a non-existing GLCD, and this slows down the execution. Possible misinterpretation: are you testing from a background task, or from a main task (e.g. APP_Tick())? What else is running in your application? Best Regards, Thorsten.

Great! Seems that the immense effort that I spent yesterday to qualify various displays at various cable lengths on the STM32F4 was worthwhile :) You can retrieve the differences with the comparison tool of the svnmios page: http://svnmios.midibox.org/log.php?repname=svn.mios32&path=%2F&isdir=1& Select revision 1938 and 1936, and then click on the compare button. Best Regards, Thorsten.

Yes, this should work. Best Regards, Thorsten.

KS0108 works at my side (I can only check the non-inverted type, 0x80) Best Regards, Thorsten.

Please note that I just had to change the schematic. J10B.D11 is now connected to PE2, and not to PE3 anymore to solve a conflict with the onboard MEMs chip. Best Regards, Thorsten.

This results into the same problem like for the AOUT module, because also DINs/DOUTs are scanned with superfast SPI. + the big problem that the connections to LCD (and OLEDs) should be short as well (<= 30 cm) Best Regards, Thorsten.

Yes Best Regards, Thorsten.

Thanks! :) Best Regards, Thorsten.

This kind of buffering is not sufficient for the superfast SPI signals. I hope that the signal quality can be improved with differential drivers. Best Regards, Thorsten.

Novski, could you please do me a favor and check if following binary is still working at your side? -> http://www.ucapps.de/tmp/mios32_test_app_lcd_ssd1306_LPC1769__20140119.zip In the last days I did some changes in the LCD driver to support STM32F4. I want to ensure that I haven't broken the LPC17 variant before releasing a new bootloader (and MBNG) firmware Best Regards, Thorsten.

Well done!!! :) How did you mount the frontpanel? It looks like it only lays on top, but isn't screwed with the side panels? I would like to see this case as the official alternative solution to the Heidenreich case. Since it can be ordered at Formulor, people are free to choose the material and color and to do customizations (especially on the backpanel). Could you please start a new Wiki page and publish your .svg file (packed into a .zip) there? Best Regards, Thorsten.

Only Vs/Vd/SO/SC/RC1 (not RC2) yes! The sync input will be located at a dedicated IO pin of the core. I will probably take the CAN IO at J18, because it's available for all core variants, and I'm sure that CAN won't be used for the MBCV application. Yes, the 8 analog inputs will be available in the modulation matrix. Note that LPC17 will only provide 6 analog inputs, because J5B.A6 and A7 are allocated by MIDI3 IOs Protection diodes: yes! + 220 ohm resistor in serial to the input for short circuit protection. Transfering the serial signals to an external breakout board is problematic, because actually the cable to an AOUT module shouldn't be longer than 30 cm! We have to do some experiments with line drivers and receivers, see also the bottom of this posting: Best Regards, Thorsten.

Highlight: the break at 1:20 while the plane targets the moon! :thumbsup: Best Regards, Thorsten.

We've a problem here: the application can only open one file (because there is only a single read buffer). This was never a problem before, but now you found a case where it does matter. I've to consider to overwork the file handling to cover this case, but this will be a complicated change, and I won't have the time to do this in the next 3..4 weeks... :-/ Best Regards, Thorsten.

Yes Best Regards, Thorsten.

Did you try the "debug on" mode? It reports the function calls during an event is processed. It could help you to understand, under which circumstances the LED status is changed. Best Regards, Thorsten.

I remember that some people had the same issue with OLEDs because they don't support the 4bit mode properly. Fortunately the MBSID V2 application comes with an alternative LCD driver for 8bit mode. The driver can be selected with LCD type 7 in the PIC ID. Upload following application to change the ID: http://www.ucapps.de/tmp/device_id_00_lcd7.zip Thereafter upload the MBSID application again... For 8bit mode, D0, D1, D4, D5, D6 and D7 of the OLED display have been connected to J15:D0/D1/D4/D5/D6/D7 of the core (as usual) D2 and D3 have to be connected to PIC pin RE1 and RE2, which are available at J5:A6 and J5:A7 (see schematic: http://www.ucapps.de/mbhp/mbhp_core_v3.pdf) Best Regards, Thorsten.

Reichelt hat ein paar recht guenstige Knoepfe im Angebot, so wie bspw. diesen: http://www.reichelt.de/KNOPF-10-150E/3/index.html?&ACTION=3&LA=446&ARTICLE=73960 und diesen: http://www.reichelt.de/KNOPF-13-164E/3/index.html?&ACTION=3&LA=446&ARTICLE=73962 Allerdings haben die keine Markierung; die muesste man sich selbst draufmalen. Gruss, Thorsten.

For MBSEQ V3 the gates will be available at J5A and J5B, DIN start and stop at J10B 4 MIDI IOs are available at J11E For MBCV V2 gates and DIN signals are only accessible via DOUT shift registers (which also act as level shifters). I consider to add the same possibility for MBSEQ V4 (as an option). So: if you want to create something which is compatible with both applications, go for two DOUT shift registers (resp. use a MBHP_DIO_MATRIX module) Best Regards, Thorsten.

I'm always doing this whenever I update central code. It's completely automated at my side for all derivatives - therefore I'm surprised that it fails at your side! Maybe you've changed a file locally which is not in sync with the repository anymore? I would propose that you download the complete repository again (e.g. into a separate folder) and try it from there. However, I just have finalized the new universal LCD driver, again many changes in the MIOS32 base, and again the danger that you miss an update if you are doing local changes in MIOS32 sources! ;-) So - please try it again with a fresh download. And for the case that you are still not able to compile, here are the prebuilt binaries of the new bootloader: http://www.ucapps.de/mios32/mios32_bootloader_v1_014.zip Best Regards, Thorsten.

Yes, for PIC based applications you've to upload MIOS8 first, thereafter upload the application (MIDIO128) Best Regards, Thorsten.

You've to disable the datawheel encoder with: # SR Pin Type ENC_DATAWHEEL 0 0 DETENTED3 Or you've to assign it to different pins Best Regards, Thorsten.

Yes, no problem. Use this template for your C++ applications: http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Ftemplates%2Fapp_skeleton_cpp%2F Here a typical application which applies object oriented C++ code (located under src/components): http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fprocessing%2Fmidibox_cv_v2%2F Best Regards, Thorsten.