Search the Community

Another nail in the coffin for the LPC17 - all hail STM32F4 Discovery :P

Thank you Thorsten I'll put a STM32F4 DIscovery in my shopping basket and wait for the new module PCB's :smile: I think its -15V to + 15V, but I am not sure, I don't know enough about how filters work electronically, and this is my first CV/gate equipment Maybe you can see it from the attached file? I assume one CV input is for the Resonance and one is for the Cut Off, and the Key tracking I am not sure how works WEB2 Korg MS20 filter 3.991 REV1.1.pdf

Yes, it's on my TODO list. Only problem is that the complete SysEx stream needs to be buffered in RAM before it's stored on SD Card. Accordingly, the used core module (LPC17 or STM32F4) will limit the max size. E.g. with STM32F4 it would be possible to handle 64k dumps easily, but for LPC17 I fear that only 4..8k can be buffered. How long is the SysEx dump of your drum machine? Best Regards, Thorsten.

hallo xii, habe gerade deinen beitrag gelesen und denke ich habe da was für dich! unter diesem link: http://www.chipkit.net/forum/viewtopic.php?f=15&t=2561 findest du eine "kleine" beschreibung meines projekts. natürlich ist der beitrag schon etwas älter. bin im november vom pic32 (fubarinosd) auf midibox (lpc1769) umgestiegen und arbeite zz am midibox-stm32f4-board. auch beschreibt der beitrag da die eigentliche funktion als midi-sequenzer. dürfte aber kein problem sein, daraus nen midi-controller zu machen! durch das modulare design kann man natürlich auch beliebige bedienelemente verwenden. "endlos-potis" (encoder) findest du da auch. diese haben sogar noch ne taster-funktion und rasten prima. die von dir beschreibenen bedienelemente könnte man auf diese art natürlich auch anschließen. man müsste da halt nur neue "module" konstruieren. momentan arbeite ich an ner neuen version der einzelnen module. ua werde ich die bedienelemente der "poti"-platte ändern und die potis zb auf eine seperates modul bauen. das wäre dann sozusagen so eine art integrierte "drehbank" (doepfer) mit 64 potis. auf anraten von tk werden die neuen module ohne den "rand" auskommen, da der doch etwas störend auf ner frontplatte wirkt und natürlich nur unnötige kosten für die frontplatte verursacht. besonders "schön" sieht man das auf der komplett-ansicht im untersten bild. das ganze ist halt noch "in progress", hoffe aber ma, daß ich das diese jahr noch schaffe. wenn du ideen für neue module hast, die spezielle bedienelemente oder auch beliebige kombinationen davon verwenden, schreib mir einfach. auch sollten "nur" 64 bedienelemente gar kein problem darstellen, egal ob lpc17 oder stm32... beste grüsse, mOnO

Before trying to level shift the Tx signal (which involves some soldering work and an additional IC, such as a 74HCT541), following experiments would be interesting. 1) connect your MIDI synthesizer to MIDI OUT1 - are you able to play notes? 2) connect your MIDI Pal between MIDI IN1 and OUT1 - does it show the outgoing MIDI data, and is MIDI loopback working? 3) and now the trick: bridge R21 (a 220 ohm resistor) with a small cable so that it doesn't limit the current draw anymore. Together with R22 (the second 220 ohm resistor which shouldn't be bridged (!) to prevent a short circuit between ground and 3.3V while plugging in the cable), this should result into a current draw of ca. 7.5 mA, which is still close to the MIDI spec, but might help in your case. Background: actually the MIDI spec says, that the current loop requires about 5 mA. Assumed that the MIDI Out has two 220 Ohm resistors in serial, and the MIDI IN of the target device has a single 220 Ohm resistor as well, this results into exactly 3.3V / 3*220 Ohm = 5 mA However, some interfaces might have a poorly designed MIDI IN circuit, so that this is not enough to drive the optocoupler. @Dugan: could you please also check if 3) solves the issue at your side? If this solves the issue, I will document the workaround at the MBHP_CORE_LPC17 page. Fortunately with the STM32F4 core it will be possible to use the Tx pin in Open Drain mode again, so that MIDI OUT can be supplied at 5V and therefore no adaption issues can be expected (due to a hardware imperfection in the LPC1769 chip this isn't possible). Best Regards, Thorsten.

well, that was a bit of excitement! had to swap boards, toolchains & enviroment-variables...,-) here is the result: mios32_toolchain gcc-arm 4.8_20131204 lpc17 28ms 27ms stm32f4 18ms 17,8ms AND i noticed, that you are right! the trouble is, that you cant see the flickering on the lpc17, because its far too slow! i wouldnt even say, that the led on the lpc17 "flickers". its more like a "blinking". didnt realize that about 2 month ago, when i built up my lpc17-board. also the "knobs" are not rotating as smooth as on the stm32f4. so it was a misinterpretation on my side, sry, and probably the reason, why my lcd-displays are quite cheap (around 7 pounds each). dont get me wrong, i still like them, but i will look out for a replacement type with a modern controller, when i get chance. i bought them from china and would rather go for rs/farnell as a supplier, just because they are more reliable and can deliver next day (for free) as well! so i would say: problem solved! ks0108 works just fine on the stm32f4. will add some more components to my stm32f4-board in the next days. mainly sd-card, i2c and midi. we shall see... kind regards, mOnO

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.

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?