Search the Community

STM32F4 is typically ca. 50% faster than a LPC17 core. Also the DMA implementation is better (no shared interrupt for all channels) which results into faster SRIO and SD Card accesses. Best Regards, Thorsten.

Nice that you find the error! :) Here a preliminary version which provides more event pool memory for the STM32F4: http://www.ucapps.de/mios32/midibox_ng_v1_030_pre1.zip Best Regards, Thorsten.

TK definitely didn't give up. I have a prototype MBHP-STM32F4 board here so it's in the testing phase

Dear Thorsten! Do not give up! We are waiting MBHP based STM32F4 Discovery, with great interest. Homebrew from Russia.

At this point, the only possibilities are: 1. Dead CLCD - time to test another CLCD? 2. Something weird with the software and/or configuration - das Heisst: keine Ahnung... TK! Wo bist du denn? :P 3. Bad wiring between the STM32F4, the 74HC595 and the CLCD. Did you try another 74HC595? - time to post a picture of your wiring (both sides, high-res please)

Also, I just compiled the MIDIbox NG application for the STM32F4 on my pc using the latest SVN source. You can try it out: http://sneak-thief.com/MIDIboxNG/project.hex It loads fine and gives me the appropriate message for my setup: [387180.219] [MBNG_LCD] no response from CLCD #1.1 [387180.220] [MBNG_LCD] no response from CLCD #2.1

OK, open MIOS, clear your terminal screen and send load the Bootloader 1.015 hex file - not the MIDIbox NG application. -> What does the terminal say at the very top? For exmaple, my STM32F4 core isn't hooked to and LCD or anything else and it says: [386343.822] Initialize LCD #1 [386343.886] Failed - no response from LCD #1.1 [386343.886] Initialize LCD #2 [386343.950] Failed - no response from LCD #2.1

WOW! GREAT WORK! I am using the new STM32F4 core and immediately noticed that executing of big NGR scripts is much faster! TK, did you modify the SD card access? Or is it because the new core? Best regards Marxon

Did you compile for the new target? Edit: ok, I just saw that you can now download a binary version for STM32F4, and you skip compiling yourself. So, you are using that one?

For anyone who's interested in having the MIDIbox CV 2 do any CV-input processing, there are a few things to consider... The processing rate will likely be in the 1-2KHz range. Not really great for audio but perfectly acceptable for a wide range of other kinds of control-voltage signals, eg. note quantizing. The quantizing hasn't been added yet but it's in the to-do list. If you're using the LPC17 core and the AINSER8/AINSER64 board, you'll need to limit the input voltage to 5V. I recommend putting a 100KB pot or trimmer in front of the circuit linked below. The CCW pin should be connected to ground, the CW pin to the voltage input and the middle pin goes to the 10K Ohm resistor on this circuit: http://www.eevblog.com/forum/projects/pic-input-protection-using-a-zener-diode/msg21840/?PHPSESSID=33bbdf2e2a88957db87cce882680f1ca#msg21840 To calibrate it as a 2:1 voltage divider, send the 100KB pot/trimmer a 10V signal and adjust it until the output is 5V. (corrected - the LPC17 board can't use the AINSER board either) *** PLEASE NOTE: you'll need to limit the input voltage to 3.3V *** To do so, you'll need to build this circuit which limits the input to about -0.2V to 3.3V, regardless of the input (within reason, of course) That means you can send the analog inputs -10 to +10V and it will scale that voltage by 1/3, reject all negative voltages. Therefore, 0-10V will give a result of 0 to 3.3V. Circuit description: 1. I recommend putting a 100KB pot or trimmer in front of the circuit linked below. The CCW pin should be connected to ground, the CW pin to the voltage input and the middle pin goes to the 10K Ohm resistor on this circuit: http://www.eevblog.com/forum/projects/pic-input-protection-using-a-zener-diode/msg21840/?PHPSESSID=33bbdf2e2a88957db87cce882680f1ca#msg21840 *** Instead of connecting 5V to the diodes, used 3.3V *** 2. To calibrate it as a 3:1 voltage divider, send the 100KB pot/trimmer a 10V signal and adjust it until the output is 3.3V. 3. Analog Core inputs: - If you're using the STM32F4 core, you can use up to 8 ADC inputs on the board itself (J5A & J5B). - If you're using the LPC17 core, you can use up to 6 ADC inputs on the board itself (at J5A and B but NOT J5B.A6 and A7 as they're used for MIDI3).

V1.015 is available under http://www.ucapps.de/mios32_download.html workaround for USB MIDI under Windows when more than 1 USB MIDI port is enabled various LCD/GLCD driver updates for STM32F4 Best Regards, Thorsten.

Thanks a lot! That's interesting... I'm in the process of starting a project, and gathering some details. In case I'll start with the STM32F4 I'd be very glad if you could share the preliminary version. By the way, may I also ask what's the scan rate Midibox KB achieves? I'll let you know, Philip

Prototype STM32F4 MIDIbox boards and LRE8x2 boards received! Time for my Reichelt order so I can start stuffing these boards:

Very frustrating, I decided to go with the LPC17 version since it looked like a quicker path to a completed project. In hindsight, I wish I went the STM32F4 route...

The only missing piece is an EEPROM emulation for STM32F4. I will implement this sooner or later, but it won't be available in the next 2..3 weeks. If it's ok for you to start with a MBKB which can't store the parameters, I could give you a preliminary version. Best Regards, Thorsten.

Hi everyone, I wanted to ask if there are any plans to bring the Midibox KB application to STM32F4, since I have a spare board and I would like to do something with it... Thanks, Philip

New topic: How about skipping ethernet altogether and going directly to WiFi? Adafruit offer a cheap breakout module running over SPI: http://www.adafruit.com/products/1469 Is there a free SPI buss for this purpose? I notice the STM32F4 board does not yet have an ethernet connector.

The STM32F4 version of the MIDIbox CV 2 uploaded successfully and MIOS is happy: Operating System: MIOS32 Board: MBHP_CORE_STM32F4 Core Family: STM32F4xx Chip ID: 0x10016413 Serial: #32002C000147333139303639 Flash Memory Size: 1048576 bytes RAM Size: 196608 bytes MIDIboxCV V2.000 © 2014 T.Klose Also, for the MIOS32 toolchain ( http://www.midibox.org/dokuwiki/doku.php?id=windows_mios32_toolchain_core ), I modified the ENV variables to correspond to the STM32F4: set MIOS32_GCC_PREFIX=arm-none-eabi set MIOS32_FAMILY=STM32F4xx set MIOS32_PROCESSOR=STM32F407VG set MIOS32_BOARD=MBHP_CORE_STM32F4 set MIOS32_LCD=universal Should I post this update here? http://midibox.org/forums/forum/13-midibox-documentation-project/

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.