I have experience only with their 54xx series (used the 5420 in our hi-spec module,
formatting link
), which is probably less of an experience than yours. However, here I go with my impressions:
I would disagree with that. I wrote my own assembler back then (spent
3 months to do it and saved probably 6+ by having things under control). Their instruction set is DSP oriented and one has to understand how things are meant to be done but this is a reasonable way to accelerate things close to the limit.
If you are talking about some toolchain TI give I just don't know how things are, though.
Uhm, was not the case with me.
I disagree with that - the 54xx series were quite logical and compact to me. A 10+ years old chip can deliver 200 MMACs/S at 300 mW, not bad at all (40 bit accumulation result IIRC).
That's true enough, they were 100% useless to me. But then I am not what an "ordinary" customer is (I guess they all imagine that as a box mover, take our chip - put on board - click here - sell. I was naive enough to try the standard support channel at Freescale recently - instead of torturing people I know there who do care and can really help - and the result was the same, totally useless).
Not sure about that but I guess "the TI way" is too broad a description. We all still use the 7400 in its various incarnations, after all :-). The 54xx series was anything but bloated, in fact it still is among the most compact DSPs I know of.
I have heard your complaints from other people as well, but I think they were related to their huge - 6xxx? series, so we are likely talking about different things.
As can be seen from the other replies here, these things can be a matter of taste.
My only experience with TI DSPs was with a TMS320F28x device, quite a number of years ago. Many things have changed for the better since then, but others have stayed the same.
I had three main problems when working on that project - the development tools, the chip, and the cpu architecture.
The development tools were absurdly expensive - a simple jtag debugger was an order of magnitude more expensive than the debugger I used for a Freescale processor at the time. It didn't have any advanced features - it is fair enough to pay for things like high-speed interfaces, trace buffers, etc. But it was basically a simple parallel-port jtag interface. The compiler toolchain (code composer) was expensive, difficult to work with, bug-ridden, and was incapable of producing tight object code from the C source. One of the most "entertaining" features was that the C startup routines did not zero out the bss section on startup - you can be sure that caused me a /lot/ of head-scratching before I found out that problem.
The chip itself had several hardware bugs, and far too little ram. This problem was made worse by having a minimum addressable unit of 16 bits, so the code had to use lots of packed bit-field structures to store flags or small data items.
The cpu architecture was the biggest issue. It is a specialised dsp core, and you need a very deep understanding of the way it works in order to write efficient code. You really need to write in assembly, and it involves a lot of tracking of the state of all the registers on each and every assembly instruction. I was using some pre-existing motor control code - it took a great deal of effort to adapt the code so that it could run the motor in either direction (the sample code was unidirectional). I first tried to re-write the code in C - it was something like 20 times slower.
I think it would be fair to assume that the development tools have improved enormously in the mean time, and I also know they are much cheaper. I would expect that the more modern chips have fixed the hardware bugs I had to deal with.
But the limitations of a DSP-specific architecture remain. Chips that are designed with the goal of doing a maximum number of MAC instructions per clock cycle are seldom good at more general software, and they seldom work well with high-level languages. This is as much a limitation of the programming languages we use as anything else - C has no way to work sensibly with 40-bit accumulators, MAC loops, hardware-accelerated cyclic buffers, 16-bit or 32-bit chars, etc. The latest C standards have improved a bit with support for saturated and fixed point arithmetic, but most compilers don't support them. Compilers for DSP's often seem to be particularly backwards - I've seen some list "better support for C90" amongst their "new features".
DSPs have their place in the development world, but for the sort of code I write, they don't work well unless they are so much of a hybrid device that you can view them as microprocessors with DSP extensions. I realise that for an audio player such as I am planning, the processor will spend most of its time doing DSP-style code. But the developer (or developers) will spend most of their time working with microcontroller-style code.
Although I mentioned TI's DSPs earlier, I am equally unenthusiastic about other specialised DSPs such as SHARC or Freescale's DSPs. I am not ruling out anything (or not much, anyway) at this stage, but I have my biases!
I find that 99% of the time tools done by silicon vendors pretty much suck out loud. In my experience that's been true for TI, Intel, Motorola, Zilog, Atmel, PIC, and ARM. Some are better, some are worse. I'd say Atmel's at the "better" end of the spectrum, TI is at the "worse" end, but they're all several notches below third-party tools (either commercial or open-source).
I doubt it. As recently as a year ago, TI FAEs were still warning people away from using Code Composer for the MPS430 and telling them to use IAR or even gcc. When the TI guys are telling customers that CC is crap, then you _know_ it's bad.
I looked into AVR32. Yes, one can make low end audio stuff with it. The CPU performance is fairly low; you can't do much with it.
Just a serial port.
Not a codec but just a digital part of stereo delta sigma DAC. You will need to add quite a few analog components to make the actual reasonably good DAC; it is questionable what would be the realistic performance.
Barely enough to do anything useful.
NAND flash is just a parallel port. There is NO NEED for HW support unless you are planning to boot from NAND.
IDE interface is just a parallel port.
Yes. We know. In the other words, there is no ethernet :-)
Could be a cheap solution for disposable mp3 players and like but not for performance audio.
Vladimir Vassilevsky DSP and Mixed Signal Design Consultant
I used 28xx on the project several years ago, too.
Don't remember the exact numbers, but Code Composer 2.xx was somewhat $800, whereas a typical embedded toolset is $2.5k.
- a simple jtag debugger
I don't use JTAG debuggers.
Code Composer was (and is) one of the cleanest (and dumbest) toolsets that I worked with.
Don't remember that problem. Surprisingly, I didn't have to do my own startup code for CCS, as it is usual with embedded toolsets.
The built-in ADC was very inaccurate and inconvenient. The flash programming was ridiculously slow. Other then that, the hardware was OK. Oh, and they changed the flash programming procedure once; that was a pain for production.
Wrote a ~100K executable for it, with floating point and everything.
To my big dissapointment, F28xx appeared not to be a DSP, but just a microcontroller :-)
I had to do a couple of time critical DSP functions in F28xx assembly. Yes, TI assembler is tough and the core structure is absurd.
There could be a difference in speed as much as 2-3 times depending on the level of optimization. Compiled code is not too bad, I wrote some interrupt functions running at 48kHz entirely in C. Just not to forget to enable flash pipeline if the code is running from flash.
It is not a DSP-specific architecture; it is a pile of TI architectural nonsense inherited from the long past.
Modern DSPs can execute general purpose code just as good. The tradeoff could be in the code size, as the DSP instructions are usually fatter then MCU instructions.
In the theory, you are supposed to call vendor provided hand-written library functions which implement typical DSP algorithms. In practice, you have to do everything yourself :-)
DSP compilers that I work with are full featured C++, not just embedded C++.
There is mainly a marketing difference between modern DSPs and modern microcontrollers. Well, devices positioned as DSPs usually don't have the MMU, while microcontrollers do.
While ago I profiled an audio codec code on PC 486. The 50% of time is spent calculating convolutions, the rest 50% is almost evenly distributed for everything else.
Things like graphics user interface can be computationally intensive, too.
SHARC is rather low performance core, power hungry, and almost no peripherals. Hardware floating point is neat, though. Can't comment about Frescale.
Biases are very important in our job.
Vladimir Vassilevsky DSP and Mixed Signal Design Consultant
That family was the successor of the 28x chips, so I was probably working on this before your project.
I don't remember the prices either, though I think it was a lot more than $800. Maybe that was including the debugger software. And I may be biased here too - my company was a lot smaller in those days, and the limit for "absurdly expensive" was a lot lower.
I never liked it. But then, I seldom like manufacturer's or toolchain specific IDE's. I work with lots of devices, and so prefer to use the same editor and makefiles. And as a compiler, it was simply not very good.
It is possible that this was due to a configuration error in the project (I started with an example project from TI) rather than in the tools themselves - I never did find out the cause. It was easy enough to initialise the data manually in main() once I knew of the problem.
The UART on the chips I used had a bug. If you didn't enable interrupts, it would not set the flag indicating new characters had arrived. So I had to poll the receive register and look for changes. I also heard that the CAN controller had a lot of problems, but I didn't use it myself.
Perhaps we see these things from a different viewpoint!
I think perhaps things had changed a bit between the 28x and the 28xx - when I worked with it, the compiler was much worse than that. There may also have been differences in the processor architecture - the 28xx was certainly a lot faster, and had lots more memory than the 28x.
Most of the microcontrollers I work with don't have an MMU either, but that depends on the size of the project.
I've been looking at the AVR32, as it is certainly a popular choice for low-end MP3 players. But I don't think it will be powerful enough here. It would be a different matter if Atmel still had the AP7xxx line of AVR32 devices - those had a lot more processing power (and useful peripherals, such as two Ethernet ports). But I suppose they never managed to capture enough market with those devices, so they were dropped.
I2S hardware is important. Yes, it is just a high-speed serial port - not much more than a 32-bit SPI bus. But as you say, not many microcontrollers have such a port.
I don't need support for DACs on the chip. This is a high-end device - the DACs will be external, and a lot higher fidelity than anything built into a microcontroller.
128K is indeed a lot for a small package microcontroller. However, I am expecting to use external RAM of some sort (and possibly external flash, depending on what we end up with).
NAND support might be an interesting extra, but it is not a requirement for this project.
Ethernet is a requirement for the project. It is possible to have an external Ethernet controller, but it is a lot easier if the chip has one built in.
I see that as the main stumbling block to the acceptance of this device, the need to learn to use their tools and language. I won't even call it Forth since it is Forth like, but has changed a lot over the years and is not even close to ANS compliant.
But I don't see anything on the market that can touch the performance potential of this chip relative to the power consumption. I expect it is the optimal solution for a lot of hand held applications. But I don't think it will have Windows CE or Android ported to it...
Yes, sort of. The development system is ColorForth and it is made to work with the chips rather than the other way around. Or in reality, I guess the whole thing is made to work together as an integral development process.
And that is exactly why I wouldn't use such a sole source product. No company can afford to continue making parts that don't sell in high volume and the AVR32 just doesn't appeal to enough of a market to assure it's continued existence.
l
y
I'm not sure of this in the Green Arrays device. The biggest problem for quality audio in a CPU is clock noise. The GA devices are async with no master clock, so no clock noise. In fact, their method of implementing ADC provides integration over the entire sample period, averaging out noise rather than just a sample and hold which under- samples noise and aliases it into the audio band. I haven't seen details from an implementation, but I expect they can get at least CD quality audio input and output.
m
That gets around one of the limitations of the GA devices, small memory. They have no on chip flash and each of the 144 processors has only 64 words of RAM.
Can a collection of 700 MHz processors directly drive 100 Mbps Ethernet? I am pretty sure 10 Mbps Ethernet can be handled easily.
I'm not ruling out Linux - it would certainly make some of the software easier because I could use existing audio apps with little or no modification. And it means I have full flexibility on the network. However, Linux would add more bulk than I'd like - it means a lot more RAM and Flash, and slower startup times.
While it's possible to run Linux with as little as 2 MB flash and perhaps 4 MB ram, you really want something like 16 MB flash and 32 MB ram for even a small system - if you aren't going to use a fair amount of existing libraries and programs on it, there is little point in using Linux in the first place.
And while I think 128 K ram is too small for a high-end audio player, I don't expect to need more than a couple of MB's. Of course, if I end up with a chip with a DDR memory interface, it might be that 32 MB is cheaper than 2 MB.
If I am going for something that big, a Cortex-A8 would probably be better. It's faster, and has Neon - it would certainly have no problems dealing with anything audio. I don't think there is much point in picking an older core for a new product.
DDR-2 memories start at 32 MB and should not be that expensive. If you are not into using old technology, then you should forget about SDRAM and DDR-1. Short term, looking at Digikey this does not seem to be true. (2MB SDRAM = $3 = $1.5/MB ; 32 MB DDR-2 = $14 = $0.5/MB) The relation should be more like 5:1 in price.
Price would be the main motivation, unless you are doing only a few. With a SAM9 you do not need any flash memory on your system since you can boot from an SD-Card.
--
Best Regards
Ulf Samuelsson
These are my own personal opinions, which may
or may not be shared by my employer Atmel Nordic AB
Power and size are of little concern, but I wouldn't say (component) cost is not an issue - just that it is not the biggest factor. High-end audio devices have a high consumer cost price, but being low volume products sold through chains of distributors and shops there is a very large scale factor between the component price at the manufacturers end, and what the end customer pays.
Having said that, we are looking closer at using small PC cards from VIA as a way to minimize software development costs (and development costs are /always/ relevant!).
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.