Jump to content

The NG and the DSP...


BEBDigitalAudio
 Share

Recommended Posts

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

  • Like 1
Link to comment
Share on other sites

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: )

Link to comment
Share on other sites

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)

Link to comment
Share on other sites

I checked out the EZKit. But the price is quite steep  :pinch:

 

And there is some major restrictions to the use of VDSP with EZKit, it will only work for 90 days. And only allows usage of 10922 words of memory for code space.

 

And i knew about the Plugiator module :wink: The controls seemed quite limited to me. Something you could do much better with something like MB NG.

Link to comment
Share on other sites

I checked out the EZKit. But the price is quite steep

 

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:

Edited by BEBDigitalAudio
Link to comment
Share on other sites

  • 2 weeks later...

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

Link to comment
Share on other sites

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

Edited by BEBDigitalAudio
Link to comment
Share on other sites

By the way, I just noted an interesting sentence in the message found by Shuriken :

 

I can do single point DFT with 128 array at 2MHz repetition rate, while ARM Cortex M4 (STM32F407 running 250MHz can only do 50KHz !! )

 

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

Edited by BEBDigitalAudio
Link to comment
Share on other sites

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: )

Link to comment
Share on other sites

Well i got a bit carried away looking for hardware options. But i think it should be doable to make a good and usable hardware design.

 

But the big problem is the software side of things. So maybe it's better to focus on that first? I am sure if there is a good use case, interest will come.

Link to comment
Share on other sites

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: )

Edited by BEBDigitalAudio
Link to comment
Share on other sites

I guess it's this book:

 

 DSP_1.jpg

 

Most impressive :thumbsup: . Unfortunately not yet translated by Elektor to any other language. I can read basic french, but this probably has to much topic specific words for me.

Edited by Shuriken
Link to comment
Share on other sites

I like the project and hope that we will find people who are interested to program interesting applications :)

 

A comment to the terminology:

MIDIbox NG is a MIDI controller application based on MIOS32: http://www.ucapps.de/midibox_ng.html

I guess that you mean MIOS32, not NG: http://www.ucapps.de/mios.html

 

Best Regards, Thorsten.

Link to comment
Share on other sites

  • 7 months later...

Hello all,

 

I have maybe found a "lowcost" solution for this project: the miniDSP board, made by a company based in Honk Kong (but owned by french people :happy: ). It costs only 185 USD, but the standard software restricts the use to their own DSP module loaded over USB.

I have started to discuss with them about the possibility to access to specification of their protocol. The good thing is that they download the DSP code using SYSEX over a good old MIDI USB connection, so the STM32 MB would support it without any problems.

 

And I also get some interest for some people based in France who proposed to get involved in the development of some modules of this project. Slowly but surely, we may get somewhere :sweat:

 

Benoit

Link to comment
Share on other sites

  • 3 weeks later...

I got bad news from them last week : they do not want to disclose their protocol... Technically, it would be possible to reverse the protocol, but it's probably a huge task. And I am afraid that they run a complete application in the DSP by default, which is only parameterized from the PC (so not possible to upload a new firmware in the DSP)

 

However, I am still convinced that we can do something... and I will probably finish by making my own PCB for the DSP :rofl:

 

And still about DSP, I also have something in my mind that I will submit to MB group very soon... Too early to reveal it for now, but I am sure that it will get interest from the community (with RTP-MIDI fully involved of course :shifty: )

 

And if any MB member goes to Frankfurt Musik Messe, do not hesitate to come on KissBox booth, I will be very happy to meet you there (we are on booth B93 in the Pro Light and Sound building)

Link to comment
Share on other sites

How many DFTs can a mutli-GHz, multicore ARM board manage? Surely that's the competition at this price point, not an STM32? It's also not clear how well optimised the DFT code under comparison was, or whether it leveraged NEON, etc.

Link to comment
Share on other sites

How many DFTs can a mutli-GHz, multicore ARM board manage? Surely that's the competition at this price point, not an STM32? It's also not clear how well optimised the DFT code under comparison was, or whether it leveraged NEON, etc.

It's pretty hard to tell, especially when the compiler is dealing with NEON. By the way, I do not think NEON was involved in the DFT test described before.

 

The difficulty is that the gap between "general use" CPU and DSP is becoming smaller and smaller. Most CISC CPU now have dedicated DSP instructions (NEON or anything else), and many DSP integrate a general CPU (take a look to XMOS for example : they now provide a XCore chip with a ARM coprocessor! Same thing for Analog Device, with the BlackFin DSP.

What is sure is that DSP cores are still beating all general use CPU in terms of pure DSP processing power, since they have an highly optimized architecture, most of the time with parallel FPALU, address generators, etc.. For example, a SHARC can execute up to 6 instructions in one cycle when the SIMD engine is activated, giving 2400MIPS peak power for 400MHz clock.

 

The biggest challenge for now with the DSPs is the cost of the development chain...

Link to comment
Share on other sites

  • 1 month later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

×
×
  • Create New...