BEBDigitalAudio

By the way, as promised, the firmware V2.0 is now available for those who want to upgrade their OEM module. Note that this version requires the KissBox Editor to be upgraded to last version too (V11) to get access to new functionnalities The file is available on this page http://www.kissbox.nl/downloads.html

I agree with you, but since I can not explain why some HC125 are acting in this way, I prefer to provide an easy workaround for those who are already working (or will work soon) with the RTP-MIDI module. Not sure that everybody has a full lot of HC125 from different suppliers to swap and find the "good" ones (moreover I already found two chips from two suppliers giving this behaviour... so it's not related to a given manufacturer) I have to say that Thorsten also saw a degradation of performances on his setup when the speed was too high, and we think that it comes from the cabling, generating parasitic oscillations. I think that most members here do not have a fast oscilloscope (maybe I am wrong about that...) to check the signal integrity, so I prefer to provide an easy fix which makes sure that a working solution can be found even under degraded conditions due to cabling

During the tests with the RTPMIDI MBHP, I found a very strange problem : the communication between the OEM module and the STM32F4 was sometimes becoming garbled and some messages were lost (you can easily see that with Thorsten's test application and MIOS Studio console) In Thorsten source code, the speed is set to 10Mbps (after Thorsten and me made a lot of tests on our development prototypes). My first proto and the two first RTPMIDI MBHP are working flawlessly at this speed, but the third module I made is failing. I finally found what was wrong: on one board, the 74HC125 used to select the MISO line between SD Card and RTP-MIDI module reacts quite strangely when it is powered by 3V. I discovered that the signal becomes out of phase (because of the lower speed of the chip) and this is enough to garble some bits in the message. Honnestly, I do not have a real explanation for that, since the 74HC125 is supposed to work between 2.7V and 5V, and it's supposed to accept more than 25MHz signals under 3V. But when I replace the 74HC125 on this board or when I power it under 3.3V, the problem disappears. I found a workaround for now if you encounter this problem: just reduce the SPI CLK on SPI0. When it is lowered to 5MHz or 2.6MHz, no more problems are occuring (and even 2.6Mbps is 83 times the speed of MIDI, so you still plenty of bandwidth even with 16 sessions in parallel) To change the SPI speed, you can do one of the two following things: - in MIOS32_SPI_MIDI.H file, locate the definition of MIO32_SPI_MIDI_SPI_PRESCALER. Change it to another prescaler value (MIOS_SPI_PRESCALER_32 gives 2.6Mbps, MIOS_SPI_PRESCALER_16 gives 5.2Mbps) - define MIOS_SPI_MIDI_SPI_PRESCALER in your own project (the code from Thorsten will detect your own definition and it will override the default one). This solution is the best one from my point of view, since it does not affect the source code from Thorsten (but I have asked to Thorsten if he could use a lower value by default)

Just back from holidays, and playing already with the RTPMIDI core board... and doing some magic tricks with it : no USB cable on the STM32F4DISCOVERY, no USB cable on the USB socket of the motherboard... but everything is running :tongue: (Nothing magic : I just installed a Power Over Ethernet module on the OEM board, it provides more than enough current for the complete motherboard... and it makes a nice picture)

As I got some questions from people who have received (or about to receive) their OEM board, I would like to give here some details and explanations about this board : - the most important : in the small package containing the CPU module, you will find a sticker with a serial number and the MAC address. Do not stick it on the RTP-MIDI OEM or the CORE board, this sticker has a metallic support for better resistance, and it may create short circuits on a PCB. This sticker was designed to be put outside a device, not inside - you can see on the package and on the PCB : "V3.1 - 03/2012". This is not the production date, it's just the date at which the PCB files were created - the date code (for the production date) is visible on the right side of the PCB, under the processor. The boards delivered now indicate 0814, which means that PCB was manufactured in week 8/2014 (the components are generally soldered in the next 3 or 4 weeks) - the package indicates "firmware : --". Do not worry, I install OEM firmware V1.0 before packing back the CPU module. So the CPU are delivered with firmware already installed (this is the same firmware as the one Thorsten used to validate the code on his side for the MIOS) - I am currently finishing the OEM firmware V2.0, which some new functions, which will require Editor V11 (Editor V11 will tell you that firmware is obsolete if you use it with OEM firmware V1.0, so just use Editor V10 for now). I will post a message here as soon as OEM firmware V2.0 becomes available (normally, in the middle of August) Benoit

Thanks Shuriken, yes, we use an XMOS chip on the V3 CPU because of its incredible flexibility and speed (more than 800MIPS, 16 realtime threads with a 10ns accurate scheduler...), a lot of memory even for our most complex applications (the complete RTP-MIDI engine uses only 60% of the RAM if I remember well, including Bonjour services, configuration tool support, etc... :smile: ) Historically, the XMOS chip was the reason I took contact with Thorsten, because we were discussing of making a MBHP board based on this chip (just imagine that XMOS has a four-core model - the G4, providing 1600MIPS and 256K of SRAM... The only problem with this chip is to find an application able to use the huge processing power :tongue: ) But finally, we agreed to use our OEM board as a "ready to use" co-processor, handling all the communication job and freeing the Cortex for other tasks (a little bit like with the Ploytec chip)

And here we are finally :sweat: The PCB for the RTPMIDI_CORE_STM32F4 arrived yesterday evening, and I assembled it as fast as possible to test it. Here it is, doing the first test run, and already equipped with the RTP-MIDI OEM module Of course, I discovered a small design glitch: I added a extra connector (J16), moved J1 in turn... and completely forgot about the mini USB connector on the STM32F4. And of course, the 3M connectors are a little bit smaller than the ones I used on my prototype, so it's a little bit difficult to insert the USB connector when the flatcable to the RTP-MIDI board is installed (I have to remove a little bit of plastic on the connector, and slightly lifted the PCB from the connector if I want to use the ST-LINK for debugging). I will correct that in the next version of the PCB. If you do not use the ST-LINK (for example with MIOS studio), or if you do not want to install the RTP-MIDI option, there is no "collision" problem. By the way, it's also possible to use J16 to connect to the RTP-MIDI OEM (and then get more room), but the cabling is not direct between the board and J16 (not very funny to twist connectors like that) Apart this little problem, no smoke and both CPU are running :wink: So the PCB is now available for those interested

Yes, that's the second edition (on the first edition cover, there was a Chameleon....) I discussed many times with Elektor to translate the bok in English, but the work and the cost seem too high related to the amount of sales.... (And thank you for the "impressive" in the comment *blushes*)

I have contacted Analog Devices to see if they could allow MIDIBox to use a EZKit license to compile applications (and for those who would need help, I have the full license and I know at least one other member in this list who has a full license too :shifty: ) Basically, we can use the VDSP to generate binary files to be loaded via RTP-MIDI and SPI in the DSP target (whatever it is, EZKit or anything else). I will provide all the tools for that as soon as I have finish to validate them. For the DSP source code itself, I have a lot of DSP code already written (mainly coming from the book I wrote :rolleyes: - but sorry, the book is in French) that is available as a basis for My goal for now is to translate the 56300 programs coming from Chameleon project (many of them are available under GPL) since they are very good. We may even get attention from people from Chameleon community and maybe get some help from their DSP coders. I hope to finish the first program next week (just before I leave for one week of holiday.... and I promised to my wife that I will not start the computer for one full week :puppeh: )

The solution described in the post of Element14 is clearly the cheapest and most flexible one compared to EZKit. However, I see different problems after looking to the details : - the board is not equipped at all, the original poster "just" made a PCB, and as far as I can see, it's not yet available - I can't understand how the maker of the board soldered the grounding pad under the DSP, since this must be done by reflow soldering technique - there is no SDRAM on the board, and creating a PCB compatible with SDRAM packages would be stupid (the complexity of the motherboard receiving the development board would be at the same level). It would be much more economic to make a development board pre-equipped with the SDRAM - the 21489 is not very well supported by Visual DSP from what I have read on some forums. Analog Device pushes to go now to CrossCore Embedded Studio for the last generation chips. The problem is that I do not have the license for CCE (and I will not switch to CCE because the other projects I am working on are compiled under VDSP :no: ) I will look to the possibility to make a similar development board as soon as I have received the PCB for the RTP-MIDI MBHP (and when I come back from holidays :smile: )

Yes, that's what I understand too. The highest "standard" frequency given by ST is 168MHz, but the tests were done at 250MHz from I understood in the discussion 250MHz seems the maximum speed the STM32 can reach

By the way, I just noted an interesting sentence in the message found by Shuriken : People are often asking themselves why DSP are still "alive" while microcontrollers are getting DSP and FPU functionnalities for a low cost.. You have the answer here : for 2x clock frequency (250MHz vs 450MHz), the DSP is able to achieve 40x more computations than the Cortex

Wow, I did not know that board. Sounds very interesting if it is available already (that's what I described in my first post, but mine was based on a 21369 + SDRAM) The 21489 uses the same instruction set as the 21369 (and like all SHARC), has more on-chip memory and has the same SDRAM expansion capabilities than the 21369, so it looks like an interesting alternative for synthesis. However, the board you see in the post does not have any SDRAM, and you basically need it as soon as wavetables are involved (the Chameleon had DRAM too). Without external SDRAM, we would be limited to virtual analog or FM processing, because the on-chip RAM is very limited. And as I looked to the 21489 page on Analog's website, I discovered that they make a low-cost version for the 21489, called "EZBoard" (it's roughly 60% of the price of the EZKit). I have to check what is the exact difference between the two boards (they give roughly the same characteristics list between the two boards). And good thing : the 21489 EZBoard is available at Digikey, Mouser, Farnell, etc... Here in France, I see a retail price of 306 euros (strange anyway, because US price is 350$ :shocked: ). Both have SDRAM and audio interface. I will try to contact the guy who post the message Shuriken found to see if the board is available in a form or another

Some news about the investigations I am making for this crazy project : - I found a serious problem with the ASX implementation i had in mind. To stop the ATMega, I need to activate its reset line, but at the same time this activates the SPI programming mode of the AVR... which is enabled by receiving two specific bytes. And the MOSI line of the micro becomes MISO... so the chip receives what I send to the DSP. If the binary stream sent to the DSP contains a specific sequence of bytes, this activates the programming mode of the ATMega, and may corrupt its Flash memory. - I found a lower cost solution than the EZKit : http://danvillesignal.com/price-lists/price-list-for-standard-products They sell a ADSP-21369 board for 310$ (but without the audio chipset), and the price drops to 260$ for 10 pieces. The audio board could then become something in open source for the MIDIBox community (the only difficulty being that all I²S audio chips are SMD). For people who want to write their own DSP code, they can use the EZKit. For the others who want just to use existing code, the Danville board could be much cheaper

Last fresh news... Just changed the arguments in PATH variable in Eclipse to c:\msys\1.0\bin;${Path};c:\mios32_toolchain\bin rather than c:\msys\1.0\bin; ${Path}; c:\mios32_toolchain\bin Yes, there is a difference :shocked: I simply the removed the space after each separator !!! And now it works !!! BONK BONK BONK <- noise of my head on my desk Thanks anyway for your proposals ilmenator and Zossen :queen:

Thanks for the tips I will try the Linux stuff today Yes, I did. But obviously, it's not the sources which can not be located, but the tools themselves. I made a quick test by changing the GCC_PREFIX, and the file name Eclipse is looking for changes too. So it's a stupid problem related to the path or something like that, but I am really out of idea after verifying everything (and moreover, the same setup works perfectly on another machine)

Hello guys, I am currently preparing a dedicated workstation under XP for my MBHP developments, and since this morning, I am getting an incredibly stupid problem : Eclipse keeps telling me "make: arm-none-eabi-gcc: Command not found" I checked everything, reinstalled the complete toolchain, but no way : I am getting this stupid error The file exists : c:\mios32_toolchain\bin\arm-none-eabi-gcc.exe (I am able to start it with the command line, so I assume it's not corrupted or anything like that) In Eclipse, I have added the following path in C/C++ Build Environment (in the variables) : c:\msys\1.0\bin; c:\mios32_toolchain\bin; ${Path} Honnestly, I am scratching my head and feel stupid, since I am quite sure it's a problem related to an incorrect path, but I can't see where I am doing wrong. If somebody else here has better eyes than me... (mine are getting quite red...) and see what is wrong... Thanks by advance Benoit

That's what I said in the first post, but as soon as you look to DSP platform, the cost is quite high (or you get limited to VLSI or Spin chip, which are very, very limited) Concerning the limitation of VDSP, it's not exactly what you say : the software can run without any limitation for 90 days, after that, you get the size limitation for the code space to 25% However, there are different points to take into account : the DATA RAM is not limited after 90 days, one the PROGRAM RAM. So you can build a project using the whole RAM without problem. the 21364 and 21369 are running at 400MHz max. With a 48kHz sampling rate, it means they can execute between 8000 and 8500 instructions between each interrupt, so the linker limitation is not really impacting for the real-time processing code (and since we have the NG MB to process the MIDI stuff and peripherals, it's giving us more freedom) there is a way to lift this limitation very easily and get access to full Program Memory after the 90 days :smile: ) And yes, the Plugiator is quite limited... :sad: The problem is that the whole MIDI processing is done by the DSP on the board, the ATMega32 does only a very few things: it controls the PDIUSBD12 chip for USB communication it loads the DSP code from the SPI Flash (afer de-encrypting it....) it transform the MIDI data from the UART into MIDI data on SPI In other terms, it's mainly there for the USB and protecting the firmware file from being copied between two Plugiator... So, if you do not use the USB, the microcontroller just acts as a MIDI gateway between UART and SPI, meaning that all processing is reported to the DSP, which consumes a lot of ressources. Honnestly, I am still asking myself why they have chosen this approach, with the ATMega32 able to do much, much more. But this will be not anymore a problem once the ASX/Plugiator is hooked to a NG MB :rolleyes:

That's what I did at the beginning (use the white connectors supposed to go normally to the CME keyboard cables). But I discovered that it is impossible to upload a new firmware by the MIDI link. You can use only the USB connector for that, which is a pain (the tools provided by Use Audio are simply awful for that) And the SYSEX protocol over the USB is encrypted, that's how they protect their plugin and make sure they only run on one board (it made me crazy, because one of my ASX failed... and it was loaded with the 8 plugins. I was not able to transfer them to the other one) So finally (as I know very well the DSP made by Analog Devices), I decided to look to the way the ATMega32 loads the DSP, and I found that it does it simply by using the SPI link of the DSP... and the link can be accessed by the connector SV3 :smile: (used to program the ATMega in factory I think) You can easily inhibit the ATMega by holding the nRST line down (which keeps the chip under reset and put it into high impedance), then the SPI lines are available for external processor. Now, there is a point to take into account : the VisualDSP toolchain is required to program a board like the ASX (not a problem for me, since I have the licence for it, but a real problem for other DIYers, since VDSP costs a lot of money...) That's why I have a preference for the solution using the EZKit (you get access to VDSP when you buy the kit) Now, it would be quite easy to make two versions of a DSP software, one compiled for the ASX, the other for the EZKit 21364 (By the way, just note that Plugiator module also use the ASX hardware - there is just a front panel with encoders and LED display over it - and the iCON X-Synth is exactly the same board than the ASX and it runs the same plugins)

I use two models : 21364 and 21369 (I sincerely prefer the SHARC DSP for sound generation and processing to Blackfin) The 21364 is good for machines with limited sample memory requirements (FM synths) and it provides a little bit more memory for code The 21369 is perfect for sample based machines (with 128Mb SDRAM), but its code memory is more limited than the 21364 (2Mb against 3Mb). It also has much more integrated peripherals, which are sometimes useful for some projects Each of these boards has 8 separated analog outputs, so you can easily put an analog processing per channel behind (yes, I did it already :shifty: )

Hello all, as I told in the thread dedicated to the RTP-MIDI compatible NG board I made, I added some expansion ports to the board, not only for the KissBox but also for something else on which I am working since a long time... It's time now to reveal what I am working on :smile: Since a very long time, I work on the idea to ressucitate the Soundart Chameleon, and since the beginning, I am convinced that the MIDIBox NG CPU is the right base for it. For those who do not know what the Chameleon was: the Soundart Chameleon was an hardware synthesizer, built around a DSP56300 and a Coldfire microcontroller. The whole software base was completely opened, and it was possible to write your own synthesizer application. The bad thing is that Soundard went bankrupt, and Chameleon disappeared, which is a pity, considering that the idea was brilliant, and the price was affordable for such a machine. The MIDI part of the Chameleon was running under MIDIShare (a open concept, similar in many ways to MIOS), and it was responsible of loading the DSP code. Then come the DSP problem... I program and design DSP boards since a long, long time for pro audio and music applications, and I know quite well that DSP may seem out of reach for DIY community. We are facing two problems : price and tooling. Almost all DSP uses BGA and other SMD industrial packages, making the idea of DIY board really out of reach for most of MIDIBox members. Making the PCB is not really a problem anymore, but soldering these chips by hand is most of the time impossible. Even "low end" DSP like the VLSI and the Spin FV-1 are SMD. So I looked to two other solutions : recycling ASX/i-CON/Plugiator boards or use Analog Devices EZ-Kit boards For both of them, the cost is roughly the same (around 350 euros for a board - ouch!), but there is nothing to do at hardware level. If you think it's expensive, just take a look to the Monome Aleph.... 1400 dollars!!!! The Aleph is partially open source (hardware is closed source), and the software is still quite limited today (as far as I know, the Aleph only have one synth project for now). Even with a 500 dollars DSP board, a MIDIBox project would cost half this price (and would be compleetly open) From a personal point of view, the EZKit are much better (more audio I/O, more interfacing possibilities, complete documentation available, software toolchain delivered with the kit), but they are bigger and you must write your own software (but that's where I come into the game, since I will provide the code and support for the community) The ASX/iCON boards are delivered with three excellent software synths (the VST interface for them being simply awful however :sad: ), and they can be driven directly from MIDI I/O from the MIDIBox for simple projects. There is no technical documentation for these boards (I had to draw the schematics by myself, after hours and hours of investigation), and getting access to the DSP requires some modification (to inhibit the local processor and replace it with the MIDIBox board), but it's feasible I have included in the RTPMIDI_CORE board the connector needed to access the EZKit and ASX boards, so the link will be very easy to make between the two boards (see "MIDIBox goes RTP-MIDI" topic for details about this board), and I am currently coding and testing the library for the STM32 to load firmware in DSP board (take care, Analog Device calls it a bootloader too, but it has nothing to see with MIOS bootloader :shifty: ) I just expect now that this project will get some interest from the MIDIBox community I did not want to go into much details in this already quite long post, but of course, if you have any question... just ask (I am preparing some pictures of the first prototypes I made) Benoit

I have made some last minute changes (and included the connector requested by Novski :smile: ), and the PCB now receives the KissBox board directly, in the same way we do for the STM32F4 board. The final PCB review was done yesterday and the files are now in the factory for production. For those being interested, the PCB will be available starting from the 29th July. I will publish the updated schematics on my website very soon (probably this weekend). As I explained in the previous post, I have decided to sell the PCB either "naked" or in the form of a kit, including the KissBox OEM module plus all other components (the KissBox board will be optional of course) (And I have already made the first application for this board :rolleyes: ... I will post a message in the "design" section of the forum very soon about it, I need to make first some photos of the proto application)