Search the Community

nice one! the comparison tool looks very useful... got the second display to work! the enable-signal of the second display needs to be the same as for the first one. lcd_num_x is set to 1 and lcd_width is 255, which gives me a width of 256 with 2 128-pixel-width displays. the only drawback seems to be the MIOS32_LCD_PrintString-Function. if you print the static screen in the while-loop (KS0108-Test), as it is, both displays and the four leds on the board flicker. whereas if you print the static screen before the while-loop it runs perfect without any flickering. i cant believe, that the printstring-function works slower on the stm32f4 than on the lpc17, where the ks0108-test runs without flickering out of the box. do you see any reason for that ?? kind regards, mOnO

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.

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.

TK, do you have thoughts on pinouts for the "J5C" connector on STM32F4? I will put together a DB-15 breakout/level shifter board for Gates 1-8, DIN Start and Clock, and MIDI OUT 3 (no room on the DB-15). Will it be more like STM32F1 or LPC17? Thanks, Andy

im still working on my prototype for the stm32disovery and im hoping to get this done today/tomorrow. in the meantime ive updated the mios32_toolchain for the stm32f4 and compiled the ks0108-demo-app, which compiles just fine. obviously the lcd-parameters for the ks0108 are not set yet on my board. so i wanted to set them, but compiling the bootloader-updater-application fails, because of the app_lcd/universal-driver. whenever you have chance, can you try to compile the updater for the stm32f4 ? there are too many errors and i agree that all these compiler-options are really a mess... thx, mOnO ps. ive compiled the ks0108-demo-app using the old universal-driver. with the updated version compiling fails as well...

It seems that my concerns about the cost of the OEM board is perceived as unfair criticism by some - that's why I'd like to explain why I think that the KissBox OEM is (edit: maybe) not a solution that fits my usecase. For others it might be the perfect solution. I have about 25+ years of experience with good old MIDI. I say this to justify that I have collected a good number of MIDI gadgets over this time. That's why I am in the process of designing a huge, modular, programmable MIDI patchbay, partly based on MIDIbox. However, with Benoit and TK introducing KissBox OEM integration into MIDIbox land, I discovered that RTP-MIDI has potentially solved the same problem already that I am working on: making sure that MIDI signals sent out by a certain device reach another device in the "network". Using RTP-MIDI, one would simply not need a hardware patchbay, because it is inherently there already. However, all the nice gear I have is not RTP-MIDI-ready. If I wanted to continue to use that "legacy" gear in an RTP-MIDI based setup, then I need to find a way of translating traditional MIDI into RTP-MIDI. I don't need additional features that my legacy MIDI gear doesn't understand anyways. I don't necessarily need this to be MIDIbox based either, but I'd surely love to because it is a platform I am quite familiar with. Let's say I want to integrate about 50-60 legacy MIDI devices. So far, this seems to be a costly endeavor using KissBox OEM boards at 100,- per each (edit: 8 16) devices for the RTP part alone (add MIDIbox hardware to that)... Benoit said they chose a microcontroller that has many more features - so I conclude there must be cheaper ways to achieve what I want. I do believe there is even a market for my usecase :smile: . It also looks to me a bit like a hen-egg problem: RTP-MIDI will have a hard time taking off if there is not enough momentum. It's going to be hard to sell that technology if there are not enough compatible devices. But then again, manufacturers will only jump the train if there is demand from customers (us). I sincerely hope that NAMM will be a success for KissBox and RTP-MIDI. Edit: Benoit corrected a typo, so that actually halves the cost and reduces my concerns significantly! Now I only need to find out where to connect a third IIC chain for the remaining 4 MIDI I/Os. Could PA8 and PA9 (IIC3 on STM32F4) be made available for such a task? Adding to a total of 16 physical MIDI I/O ports on the MIDIbox (4 UART based via J11E, 12 IIC-based via 3 IIC chains with 4 I/Os each)? Nothing but the router functionality has to run on the core...

Yes, 100% correct! Btw.: I received the STM32F4 PCB today, first results are promising (no error so far... of course, it has been layouted by SmashTV! :)) Best Regards, Thorsten.

I'd like to take a moment to clarify all the connections between the core and the peripherals. Is this correct? DIN/DOUT (buttons, LRE, Gate Outs) - J8/J9 (MBHP_CORE_LPC17) - J8/J9 (MBHP_CORE_STM32F4) ANALOG INPUTS - 2 inputes from J5B.A4 and J5B.A5 (MBHP_CORE_LPC17) - 8 inputs from J5A and J5B (MBHP_CORE_STM32F4) SCS buttons & encoder - J10 (MBHP_CORE_LPC17) - J10A (MBHP_CORE_STM32F4) OLED - J5A and J28 (MBHP_CORE_LPC17) - J10B (MBHP_CORE_STM32F4) - http://www.ucapps.de/mbhp/mbhp_lcd_ssd1306_alt_port__stm32f4.pdf LC Module CLCD/GLCD - J15A (both LPC17 & STM32F4) Analog-in AINSER - J19 (both LPC17 & STM32F4) (Not supported - slows down CPU too much) Analog-out AOUT - J19 (both LPC17 & STM32F4) MBHP_CORE_STM32F4 peripherals: MIDI IO MBHP_MIDI_IO - J11e (MBHP_CORE_STM32F4) Ethernet MBHP_ETH or equivalent - J16e (MBHP_CORE_STM32F4) MBHP_CORE_LPC17 peripherals: SD Card - J16 (MBHP_CORE_LPC17) (edited connections for OLEDs and Analog Inputs)

Apart from the smaller footprint I cannot see any advantages of the Cerb40 over the STM32F4-DISCOVERY kit: twice as expensive, fewer IO pins available, and less widespread :-/. Maybe outside of MIDIbox land the FEZ Cerberus software can be useful, but here it does not play a role at all.

Still waiting for the PCB (hopefully it isn't stucked at german Zoll...) For the STM32F4 version you can expect a pool size of 64k! :) Best Regards, Thorsten.

It´s done: Event Pool Number of Items: 786 Event Pool Allocation: 24571 of 24576 bytes (99%) Hopefully the STM32F4 version of MidiBox NG will be released soon.

120 Buttons 13 Encoder 20 Potentiometer 7 Fader 40 RGB Leds 22 Duo Leds 22 Single Leds 16 8-Segment Led Bars 8 10-Segment Led Bars Number of Items: 457 Event Pool Allocation: 16299 of 24576 bytes (66%) And its still growing... Will there be a STM32F4 version of MidiboxNG in the near future?

@Chriss: thanks for the valuable input! I'm planning to setup a new webpage for the project which summarizes the facts and wishes, so that we know where we are :smile: it should update automatically on CV channel changes. Are you using the MIDI or OSC option? Could you please try the latest .jzml file in the SVN repository? I adapted it to the latest Lemur version, the old one wasn't 100% compatible. There are several mini-router available at Reichelt for around 25..30 EUR To people who want to use the (preferred) MBHP_CORE_STM32F4: it won't provide an ethernet port anymore. @Sneakthief Yes, correct, it's ca. 15 mm measured from PCB bottom to OLED top I would calculate 30 mm For STM32F4 I can't confirm yet, but it will be ca. 30 mm as well Here btw. a preview of the PCBs - they have a different format compared to MBHP_CORE_LPC17! MBHP_CORE_STM32F4: 120x88 mm MBHP_MIDI_IO: 103x44 mm (two MBHP_MIDI_IO boards can be chained for 4 MIDI INs and 4 MIDI OUTs) Best Regards, Thorsten. I bought it from Ebay for 5 EUR But the height is very similar to all 2x20 CLCDs that I know. You can calculate the same height like for the OLEDs Of course, no problem for me if you adjust the alignments. Best Regards, Thorsten.

First of all, the 2nd layout with the CLCD on the right seems ergonomic to me. 1. I'm not sure if we can fit everything within a Ponoko P2-sized case (384x384mm acrylic piece cut into a box). Let's consider the top panel: - The LED ring pcb is 342mm wide and it would need at least an extra mm of room, hence the width of 343mm that I chose. - The top panel needs to extend 3mm on each edge to overlap the side pieces, meaning a width of 349mm - That leaves 35mm of vertical height inside: 384mm minus 349mm (Imagine that the single 384x384mm "P2" acrylic piece gets cut into 4 pieces - top panel next to one side panel, bottom panel next to a side panel, then the front panel, then the back panel) - The OLED/CLCD pcb layer looks to be about 15mm high, right? - My guess is that the MIDIbox LPC/STM32F4 is 22mm including the solder protrusions on the bottom. Can somebody verify this? So that's a total of 37mm for both pcb layers... 2mm too much, not including space needed between the boards. 2. Re. case style: Some of the options I was personally considering for an acrylic case... - A clear acrylic case with a nice scratch-resistant laser-cut overlay. This way the LED-rings, OLED's and CLCD don't need to have holes cut out and have a protective layer. Downside: a few extra $ for the overlay. - Transparent gray acrylic. Looks nice, hides the ugly pcb's underneath. Downside: I find smooth acrylic cases scratch too easily and collect dust like crazy :( - Matte gray acrylic. Same as above, less prone to scratches. Downside: Will the LED-rings be visible enough? Will any engraved text be legible? I don't think building it into the CS box makes any sense. You simply don't want up to 16 CV/gates from a desktop unit extending all the way to your modular. Please trust me on this. I've been building my DIY-modular for 10 years now and as your modular grows (which it inevitably does!), you'll see what I mean.

OK. Thanks again! I wait for some 595s which i ordered on monday, then i can test more than 8 matrices. For the performance issue: i already have a STM32F4 Module and will built it these days. Best regards Marxon

Imp: I don't think you realize how tiny those display are - the viewing area is 21.74 x 11.20mm. Try cutting out a piece of paper that size and you'll see what I mean. I have a little XMega Protolab mini oscilloscope ( http://www.gabotronics.com/development-boards/xmega-xprotolab.htm ) which uses a similar display. It's good for waveforms but when it comes to going through parameter settings, the 20x2 CLCD is a much better solution. I would recommend going to a larger GLCD if you really want to go this route. Don't forget, somebody would have to rewrite the user interface to compensate for the lack of the SCS (standard control surface): 1 encoder, 2 dedicated buttons and 4 soft-buttons. Not to mention, the STM32F4 setup is more affordable ...assuming the MIDIbox carrier boards are the same price: 16e 1x STM32F4 27e 4x SSD1306 OLEDs 8e 1x 20x2 CLCD Total: 51e 28e 1x STM32F4 54e 8x SSD1306 OLEDs Total: 82e

It's the Alientek OLED from Taobao: http://item.taobao.com/item.htm?id=6239945991 And I purchased it via Youbuy: http://www.yoybuy.com/en/ See also http://www.ucapps.de/mbhp_lcd.html Let's keep this in mind - but independent from such an option, how would the ideal MBCV2 CS look like? It's already running on a STM32F4 :) (and SmashTV will send me a prototype for the upcoming MBHP_CORE_STM32F4 module soon) The application is ca. 25% faster on a STM32F4. Best Regards, Thorsten.

Are there any big hurdles for getting this to work on the STM32F4 discovery?

The availability is not so good as for the smaller STM32F4-DISCOVERY kit. See http://www.findchips.com And I don't want to be responsible for a sellout of the last available boards ;-) Best Regards, Thorsten.

Hallo Thorsten Erst einmal vielen Danke für die guten Infos. Ist wirklich interessant was sich in Bezug auf die STM32 MCUs dieses Jahr so getan hat. Das sah letztes Jahr bei meinen ersten Gehversuchen mit dem STM32F4 Discovery Board noch etwas mager aus. Wenn ich mein Synth Project in den nächsten Wochen abgeschlossen habe, plane ich eine verbesserte 2.Version. Das Kind hat auch schon einen Namen.. "WAVE 2". Vielleicht mit einem STM32. Schaun wir mal .. :smile: Übrigens bin ich gerade dabei, die Loop-Funktion für die Wavesamples in meinem Synth zu programmieren. Gute Ideen und Anregung für die Umsetzung verschaffe ich mir aus dem Bedienungshandbuch des PPG Waveterm A und einigen Demos auf Youtube. PPG WAVETERM A 2.2 Schon geil die Sounds :smile: Die Loopfunktion funktionier bei mir ähnlich. Nur mit dem einzigen Unterschied das ich statt 64KByte ganze 1Mbyte Samplespeicher habe, dazu noch 2x VCF's (OTA13700) und 2x VCA's (OTA13700). Gruß Rolf

Hallo Rolf, wenn Du bereits ein STM32F4DISCOVERY Board hast, koenntest Du bspw. mit diesem Tutorial direkt loslegen, einen Synthesizer zu programmieren: http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Ftutorials%2F024_i2s_synth%2F MIOS32 bietet ja schon alles was man dafuer braucht. Vor allem die I2S und MIDI (USB und UART basierend), scannen von Buttons, Encodern, LEDs, verschiedene LCD typen (character oder graphisch), SD Card, usw. usw. Die Toolchain basiert auf gcc mit nanolib: http://www.midibox.org/mios32_toolchain/ Und zum Aufladen von Code, sowie zum Debuggen via printf verwendet man MIOS Studio: http://www.ucapps.de/mios_studio.html Alternativ koennte man auch mit Eclipse debuggen (falls Du eine IDE suchst, mit der man bspw. Breakpoints setzen kann, waehrend der Laufzeit Variablen abrufen kann, usw) - irgendwo gab es mal ein Thread zu diesem Thema. Welche Peripherals bietet die Atmel MCU, die nicht im STM32F4 enthalten sind? (wenn man mal vom Audio DAC absieht, doch ein externer DAC ist u.U sogar vorteilhaft, weil man die Spannungsversorgung besser gegen Stoerungen aus der digitalen Spannungsdomaene isolieren kann) Gruss, Thorsten.

Hallo Thorsten Interessehalber hatte ich mir vor einigen Monaten das sehr preiswerte STM32F4DISCOVERY Evaluation Board gekauft und ein wenig damit experimentiert (siehe Link unten) Leider sind die wirklich guten Entwicklungstools dafür etwas teuer. Ich programmiere gerne mit ATMEL Studio. Es hat viele Vorteile wzB leichte Bedienung, keine Codegrößenbeschränkung und ist Freeware. Es ist mir schon bewusst, das die ATMEL MCU's nicht zu den schnellsten ihrer Gattung zählen. Aber Geschwindigkeit ist halt nicht alles was zählt. Die ATMEL MCU's haben ihren Vorteil in der Menge der angebotenen internen Peripherie und sowie einen großen Funktionsumfang. Im Vergleich dazu sieht so ein schneller STM32F4 etwas alt aus. Link: Meine ersten Erfahrungen mit dem STM32F4DISCOVERY Evaluation Board Gruß Rolf

Last saturday I checked a Quad-IIC board with the new compiler on a STM32F1, STM32F4 and LPC17 - still works. What happens at your side if only the second, third or fourth uC is stuffed, and all other PICs are removed? Btw.: the fastest way to check the availability of the IIC slaves is to enter the "system" command in MIOS Terminal. Best Regards, Thorsten.

Thanks for your feedback, ilmenator! It is good to know, that it should work, maybe it is because of my adaptations to get the VFDs running which required some (probably improperly done :)) driver hacking or the long SRIO chains I am using, or the old compiler toolchain i am using (did not manage to update yet, am compiling on FreeBSD, which complicates things :))... But no worries for now - will wait for the new core and then update everything properly :-). Am really looking forward to the STM32F4, awesome specs, cheap price :) Many greets, Peter

Hola Altitude! Thanks for your answer - yes, the bootloader is up to date. It is really not important, please don´t pull your hair :) - will upgrade to the new STM32F4 based core and check IIC MIDI again, when it is available - 192KB of RAM will allow for more SEQ goodness, maybe even 1024 step patterns as a Christmas present? :-) Many greets! Peter