whats cheap, easy 100s of MIPs for dsp in the loop - Page 1
Forum section: electronics / general

author: f5r5e5d
author_rank: Frequent Contributor
timestamp: June 01, 2014, 04:04:55 am
content: I would like to build in a monitor/controller for a audio amp, calc instantaneous pwr, do Iout, Isupply balance math, compare I,V vs load Z template, auto adjust baises, SOA, short circuit limit, power on sequence...while possibly giving up cycle by cycle limits above 20 kHz it really looks like the built in anti alias of audio specific delta-sigma ADC/codec chips greatly simplify analog glue and would fit with up to 8 channels ~100ks/s eachbut cheap, "easy" to program/develop middling to upper 100s of MIPs is less obvious to me - I haven't done much digital in the last decade but did some single chip few MHz uC and 40 MHz fixed point DSP code earlieras I see it the operations may involve <10 MIPs of "arithmetic" but really don't map to DSP simd/pipline/FIRin the past I've found "the rest of the code" which requires lots of idiosyncratic mixing/matching/comparing as well as the drag of reading, moving indexing near 1 Ms/s data streaming in is really what gobbles the MIPsfrom my past experience I wouldn't want to go with less than 4-10x overkill over reasonably anticipated back of the napkin estimate of processing powerthe AD Blackfin ez kits and Audio ezextender with 2x AD1938 looks like the best matching dev tool that could be expected - dsPIC33 currently hitting 70 MIPs would likely fail to do all I want as far as I can tellany other suggestions? or experiences with AD's current tool chain?this is more heavy duty hobby level than a funded commercial product development - probably not going FPGA with NatInst or Matlab $10k block diagram compilers - though the ads sure look cool and lots quicker dev time if they work

author: Dago
author_rank: Frequent Contributor
timestamp: June 01, 2014, 06:29:18 am
content: I've always wanted to try xCOREs from XMOS. Up to 1000 MIPS, multiple cores (16 in the 1000 MIPS one). Cheap too, the most powerful one is like 20$.http://www.xmos.com/I have no real experience with them though.

author: nctnico
author_rank: Super Contributor
timestamp: June 01, 2014, 11:55:14 am
content: How about using a fast ARM microcontroller? Maybe even use a dual core controller or one with a floating point unit.

author: Marco
author_rank: Super Contributor
timestamp: June 01, 2014, 01:09:12 pm
content: For a one off you aren't going to do it cheaper than the ARM boards (TI and Freescale have the best documentation, since you want to hang a lot of ADCs on the GPIO you're going to need this). For the price of the Blackfin kit you can buy quite a few.PS. thexCore Startkitlooks nice, you give up the memory and huge amount of computational power of the ARM boards, but it's still 8x62.5 MIPS and much lower power ... for 15$ that's pretty interesting.

author: f5r5e5d
author_rank: Frequent Contributor
timestamp: June 01, 2014, 03:38:29 pm
content: beaglebone black caught my eye as a dev platform - way overkill processor/board resources but cheap, tons of info for Linux - not too sure about people's success rate with bare metal C coding it from search - maybe just too much (unused) functionality to config?I hope the open source tool chain has improved in the last 15 years - I have an allergy to header/lib/link/make... editing 3-4 files to address a fixed location hardware resourcewould have to roll my own DAQ "cape" for the speed/channel count I wantnear term practical for me is probably just using dsPIC33 and its internal ADC for bias servo and seeing how many MIPs are left over for other wants - cheaper than 4+ AD633 analog multiplier chips and the rest of the analog glue

author: nctnico
author_rank: Super Contributor
timestamp: June 01, 2014, 05:45:06 pm
content: I have used NXP's ARM microcontrollers for DSP purposes in the past. They have an SSP interface which talks to codecs from TI (and probably other brands as well) directly. If you daisy-chain a couple of codecs you can come up with a neat solution. The best way to deal with DSP algorithms is to do all the processing inside the interrupt from the codec interface (in my case the SSP interface). That way you don't have to move all the data around first.

author: miguelvp
author_rank: Super Contributor
timestamp: June 01, 2014, 07:53:11 pm
content: http://www.arm.com/products/processors/selector.phpDo you need floating point and Neon instruction set? I would select the core first then look for manufacturers based on what you need.

author: fcb
author_rank: Super Contributor
timestamp: June 01, 2014, 08:18:12 pm
content: There are two ways to tackle this.1. Define very carefully the calculations you want to perform (perhaps in pseudo code) and from this work out the minimum speed necessary.2. Choose a processor you are happy with and then try and squeeze your application in it.I have used the dsPIC33F series since for maybe 7 years in audio applications. I would probably not move to the dsPIC33E though - there isn't the doubling in performance you would expect. I use them all the time at 96KHz, and have done some 192KHz stuff with them also.If you want to do some heavy lifting then I would skip the Blackfin and do it in a SHARC (ADSP21369 is pretty mean).

author: Sailor
author_rank: Regular Contributor
timestamp: June 02, 2014, 12:10:47 pm
content: It's 15 years since I last did any serious DSP work, but at the time the way I handled a problem that was at the limit of feasibility was to have multiple processors (Analog ADSPs) pipelined, with dual-port SRAM between each processor, and then multiple sets of these in parallel. While you may not need to go to these extremes, the benefits of pipelining are easily realized if your overall processing can be divided into relatively simple consecutive operations. You need to get each stage to be about the same length (in time), even if it means breaking a long stage into smaller segments. You then write your code so that the input data for each stage is being pulled (and used directly) from the RAM that was the output of the previous stage, and your output data is going directly to the next RAM where it will become the input for the next stage, etc.As nctnico said, in principle, 'do all the processing inside the interrupt from the codec interface'. It is an absolute waste of time shuffling data around to suit your code. You must organize your code to suit your data, and/or alter your data source to work better with your code.Once you get the pipeline working properly, you can achieve remarkable throughputs. Especially if you do it all in assembler as I did. But it took a chunk of my life.

author: diyaudio
author_rank: Frequent Contributor
timestamp: June 02, 2014, 07:10:16 pm
content: Quote from: f5r5e5d on June 01, 2014, 04:04:55 amI don't understand where the DSP fits here.SHARC/Blackfin ADZS-HPUSB-ICE cost $1,300, a SHARC audio development board cost $600. I bought the blackfin/sharc emulator for $600I purchased a sharc/blackfin clone (doesn't do tiger sharc) and I got a full Licence for Visual DSP++ 5.1 all for $600

author: lewis
author_rank: Frequent Contributor
timestamp: June 02, 2014, 07:24:07 pm
content: I've done exactly this in a dsPIC33E. The Data Converter Interface can be configured easily for I2S, and DMA takes care of buffering and sampling. Calculating real power and deriving load impedance is pretty simple with a few mathematical tricks, avoid floating point maths at all cost and divide as little as possible. Multiplying by reciprocal constants is very fast. Cheap audio ADCs can be calibrated to function well for measurement in these applications, internal MCU ADCs work well for voltage rails, mains input and temperature.Instantaneous short circuit protection and SOA protection is best implemented passively, you'll struggle to get the MCU to react fast enough under all circumstances.Can't say much more I'm afraid, commercial designs and all that.

author: f5r5e5d
author_rank: Frequent Contributor
timestamp: June 02, 2014, 11:33:35 pm
content: DSP specific instructions won't help my app that much - but DSP chips do seem to be attractive on cost for high instructions/s, have the timers/interrupts/spi/sport peripherals built in - well tuned for embedded - haven't seen the ins cycle breakdown yet but ADSP-BF592 advertises "400 MHz" not counting MMACs - can be had for < $US 10 in singles, looks like hand/hobby lab solderable pkgif using the dsPIC33 and its 2x 1 Ms/s 10 bit ADCs multiplexing 8 I, V measurements should be able to do limits in few 10s of us - even 100 us limiter response will save lots of MOSFET outputsbut the main motivation is controlling a "geometric mean" non-switching output bias scheme loosely equivalent to diodes replacing the output emitter R - clearly thermal stability issues requiring some more calculation than is convenient in analog - particularly sorting out the bias condition for servoing in the presence of large signal at audio frequencyI've used both ADSP and PIC professionally - but again over a decade ago - just wanted some update, pointers to whether the embedded processing landscape has changed that much, if there are better options

author: f5r5e5d
author_rank: Frequent Contributor
timestamp: June 06, 2014, 03:59:00 pm
content: after a (very) little search it looks like STM32F205 would be a possibility - but the STM32F2xx seems to be skipped over in ST support - no cheap Nucleo board, support added to STM32Cube only past few monthshave any use the STM32F2xx, the STM3220G-EVAL?the features I like so far are the 3x fast 2 Ms/s 12 bit ADC, 2x 12 bit DAC - before having to rely on PWM for analog output, and 120 MHz operationNXP, ATMEL, Freesacle ARM Cortex at comparable level didn't seem to have the ADC performance - did I miss some other good option?

author: dannyf
author_rank: Super Contributor
timestamp: June 06, 2014, 04:42:05 pm
content: The 2 series is not widely used.For analog signals, people tend to use the 3 series or the 4 series.

author: f5r5e5d
author_rank: Frequent Contributor
timestamp: June 06, 2014, 09:57:04 pm
content: thanx, I didn't really look at the STM32F3xx because 74 MHz seems too low for comfort, the 3x 50 ks/s 16 bit delta-sigma ADC are a feature I missed - if both were 2x faster I'd jump on itI don't see the delta-sigma ADC offered in the STM32F4 series which are faster but 2x price of the F2xx for ~ the same analog I/OI could see going with F4xx just for the apparent better support in Dev tools, forums