ilmenator Posted September 4, 2013 Report Share Posted September 4, 2013 Yes, there was a user project but AFAIR there was a 6-voice limit due to slow SD card access. Quote Link to comment Share on other sites More sharing options...
niklasni1 Posted September 4, 2013 Author Report Share Posted September 4, 2013 I know. It looks like it woulod be a suitable basis, though. I couldn't get it to talk to my SD card reader when running on the Discovery board (though other apps saw the card fine), but I haven't looked at it for a while. Quote Link to comment Share on other sites More sharing options...
TK. Posted October 20, 2013 Report Share Posted October 20, 2013 Some news from STM32F4: I started with the schematic and assigned the pins. The upcoming breakout board (layouted by SmashTV) will provide sockets for: - USB (via the on-board Micro-Socket) - 4 MIDI INs and 4 MIDI OUTs (note: the MIDI IOs will require a separate PCB, more about this topic later...) - 3 SPIs, each one with 2 CS lines. Two SPIs at 5V, one at 3.3V (for SD Card) - 8 analog inputs - 2 LCD ports - 2 IIC - 1 CAN - 8 IOs (J10) - (on-board) Stereo Audio DAC Note: some of the current pin assignments will be changed based on the new schematic in the next days. Everybody who already built the HW has to adapt some connections (e.g. for the SD Card) accordingly. I will publish the schematic once I tested all connections, and once I'm sure that they are final. Best Regards, Thorsten. Quote Link to comment Share on other sites More sharing options...
niklasni1 Posted October 20, 2013 Author Report Share Posted October 20, 2013 Excellent news! I'm not sure how much it'd interfere with existing MIDIBox stuff, but I really think you should consider using the dedicated SD controller. It is a *lot* faster. Quote Link to comment Share on other sites More sharing options...
TK. Posted October 20, 2013 Report Share Posted October 20, 2013 Unfortunately some SDIO pins conflict with the Audio-DAC, so that it can't be used on the STM32F4DISCOVERY board. Or do you know a workaround? Best Regards, Thorsten. Quote Link to comment Share on other sites More sharing options...
niklasni1 Posted October 20, 2013 Author Report Share Posted October 20, 2013 No, I don't. My mate who designed the board with SRAM and card reader has done some work with the TI Cortexes as well, he complained of similar things. It's like ST didn't really think the pin assignments through :/ Quote Link to comment Share on other sites More sharing options...
TK. Posted October 23, 2013 Report Share Posted October 23, 2013 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. Quote Link to comment Share on other sites More sharing options...
niklasni1 Posted October 24, 2013 Author Report Share Posted October 24, 2013 Nice! I'll give that a spin tomorrow night! Quote Link to comment Share on other sites More sharing options...
sneakthief Posted October 25, 2013 Report Share Posted October 25, 2013 (edited) Nice work on finding out how to relocate the SD CS pin to PB2 to finally free up the DAC! (Right?) Edited October 25, 2013 by sneakthief Quote Link to comment Share on other sites More sharing options...
TK. Posted October 27, 2013 Report Share Posted October 27, 2013 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. Quote Link to comment Share on other sites More sharing options...
sneakthief Posted October 27, 2013 Report Share Posted October 27, 2013 (edited) The IO pins of the SDIO peripheral (high speed SD Card access) conflicts with the on-board Audio DAC, so that it can't be used. Is this info that you posted on the new STM32F4 page still true? I was under the impression that one DAC was freed up and all the pins for a high-speed SDIO SD card were now enabled? Or am I totally confused? Edited October 27, 2013 by sneakthief Quote Link to comment Share on other sites More sharing options...
TK. Posted October 27, 2013 Report Share Posted October 27, 2013 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. Quote Link to comment Share on other sites More sharing options...
sneakthief Posted October 27, 2013 Report Share Posted October 27, 2013 Ohhh, I should have spent more time reading the datasheet! Quote Link to comment Share on other sites More sharing options...
niklasni1 Posted November 2, 2013 Author Report Share Posted November 2, 2013 I have the sample player running on my Discovery board.. wondering what's the best way to connect it directly to an LPC17 core? I've made room in my new 3D-printed Seq v4 "case" (more like scaffolding, really) for a Discovery board and mounted on some veroboard, and I was thinking of just using DOUT->DIN triggers but a MIDI connection would be nicer (velocity, etc). Any suggestions? Quote Link to comment Share on other sites More sharing options...
TK. Posted November 3, 2013 Report Share Posted November 3, 2013 Yes, a MIDI connection would be the most simple way to connect the cores. You could increase the baudrate at both sides to reduce the latency, especially if no optocoupler is used. (I will check the max possible baudrate tomorrow) Alternative solutions: - use MBNET, resp. communication via CAN - but both applications are not prepared for this - even faster: use SPI - again both applications are not prepared for this So, the alternative solutions would be a nice challenge for the case that you want to improve your programming skills ;) But at the end I think, that an increased UART baudrate is already sufficient to ensure a good "user experience", and that you won't notice a big difference with the alternative solutions. Best Regards, Thorsten. Quote Link to comment Share on other sites More sharing options...
niklasni1 Posted November 3, 2013 Author Report Share Posted November 3, 2013 Is it fine just to connect everything directly without an optocoupler? I've been told MIDI is weird electrically, but not really what that entails. Since they're in the same box, I'd prefer to use an internal ribbon cable over an external DIN5-cable... Quote Link to comment Share on other sites More sharing options...
TK. Posted November 3, 2013 Report Share Posted November 3, 2013 Yes, of course you don't need an optocoupler in such a "system", instead you can cross-link the Rx/Tx IOs directly as long as the grounds are connected together. It seems that this is a typical misunderstanding about MIDI. People think, that MIDI is slow because they only know the common physical layer which requires optocouplers for ground decoupling, and optocouplers reduce the bandwidth... But in a "closed system" (inside a MIDIbox) this doesn't matter, IOs can be directly connected and the baudrate can be increased by factor 10 and more. In fact MIDI is still a very efficient protocol to interconnect sequencers and synthesizers. Just consider that it has been defined at a time where microcontrollers ran 100 times slower than today. Accordingly the protocol avoids any unnecessary overhead - and therefore should still be the first choice if performance does matter. To give you a comparison: the sampler only listens to a single MIDI channel, therefore the "running status" optimisation can be used (handled by MBSEQ by default). The transmission of Note and Velocity will require 2 bytes. At the standard MIDI baudrate this will take 640 uS At a 10x higher baudrate only 64 uS... and I guess that we could even go for 20x or even 50x! Best Regards, Thorsten. Quote Link to comment Share on other sites More sharing options...
niklasni1 Posted November 3, 2013 Author Report Share Posted November 3, 2013 (edited) I don't really think of MIDI as slow. Certainly not too slow for sending <5 notes per second I will be... but higher baud rates could be interesting. Of course, what I really should be doing was to integrate the sample player with the sequencer and just run the whole thing on one core :smile: Edited November 3, 2013 by niklasni1 Quote Link to comment Share on other sites More sharing options...
TK. Posted November 5, 2013 Report Share Posted November 5, 2013 The official MIOS32 toolchain is based on gcc-arm-embedded and newlib-nano now. Prebuilt binaries for Win32/MacOS/Linux can be downloaded from: https://launchpad.net/gcc-arm-embedded (and from http://www.midibox.org/mios32_toolchain) The build will probably fail with other toolchains if they don't support newlib-nano due to this new flag in $MIOS32_PATH/include/makefile/common.mk # for https://launchpad.net/gcc-arm-embedded: enable newlib-nano for better performance # not compatible with other toolchains (users have to switch to new version, or disable the line below) LDFLAGS += --specs=nano.specs therefore an update to the new toolchain is required. And it's worth the change, because I measured performance improvements in many MIOS32 applications! :smile: @niklasni1: your recommended switched for Cortex-M4 fails at my side. I'm able to build a binary, but the core crashes very early, although I'm sure that the FPU will be initialized in MIOS32_SYS_Init() I will debug this sooner or later, until then please use the updated common.mk, which enables M4 instructions, but doesn't select FPU instructions or libraries Best Regards, Thorsten. Quote Link to comment Share on other sites More sharing options...
FelixSchoenstein Posted December 10, 2013 Report Share Posted December 10, 2013 I suppose this is a poor time to ask this, but anyway: Are there any plans to produce a core module using the STM32F429? It has more memory, more i/o ports, and it comes with a LCD built-in. Quote Link to comment Share on other sites More sharing options...
TK. Posted December 11, 2013 Report Share Posted December 11, 2013 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. Quote Link to comment Share on other sites More sharing options...
romsom Posted January 13, 2014 Report Share Posted January 13, 2014 You are probably well aware of the Cerb40, but I wanted to post it anyway, since it's pretty cheap, available (GHI, Watterott) and OpenHardware (CC-BY-SA) and has been used already e.g. with the PreenFM2: https://www.ghielectronics.com/catalog/product/450 Greetings, Roman Quote Link to comment Share on other sites More sharing options...
ilmenator Posted January 13, 2014 Report Share Posted January 13, 2014 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. Quote Link to comment Share on other sites More sharing options...
romsom Posted January 14, 2014 Report Share Posted January 14, 2014 The advantages I can see are: - (as you mentioned) smaller footprint - OpenHardware (i.e. layout data is available) Especially the OH aspect can be important to some people (including me) for idiological and practical reasons. And while the board surely has its limitations it may be suitable for smaller, more specialized applications (e.g. SoftSynths, SamplePlayers etc. ; MidiboxKB-powered devices) I "recommended" this purely as a hardware component, and am familiar with Midibox/MIOS btw. Quote Link to comment Share on other sites More sharing options...
niklasni1 Posted January 14, 2014 Author Report Share Posted January 14, 2014 (edited) I'd say it's highly unsuitable for softsynths and sample players compared to the Discovery board, since it doesn't have an audio output... Edited January 14, 2014 by niklasni1 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.