To be honest, I don't like doing code, particularly C. I *hate* C. If they'd let me use assembler I'd knock of one of their "to do list" product in my spare time, myself.
This under the table thing was in competition with the vending company (machines right outside the lab). I doubt they'd like the competition if they knew. There was also a coffee kitty that was in competition with the cafeteria, but they weren't open all the time. The coffee kitty wasn't clandestine.
It is a small company (under 100). Firmware and hardware are separated with a pretty broad line, though.
We were three years late (I got there at the end) on what is now our main product. TI shares the blame, though. Their DSPs suck and their support worse. OTOH, one FPGA would have saved at least two years of grief. ;-)
We've considered DSPs, but always wind up doing our serious crunching in an FPGA. A DSP isn't a very good uP and it isn't a very good FPGA.
John
They fill the niche quite nicely for audio or low IF processing though. Hence the reason they're in every cell phone and most modern commercial radios out there...
Often you don't really need a very good general-purpose uP if you're programming in a high-level language anyway. I've often felt the main reason many designs (like cell phones) had a DSP and a separate CPU (long before you had web browsers and other things that easily chew up hundreds of MHz of a general purpose CPU) was that the DSP guys didn't really trsut the CPU guys not to stomp on their time-critical interrupts and careful static memory allocations (when you have slightly weird DSPs like the TI ones Keith mentions that have various sections of memory, some single-ported, some dual-ported, etc.) and whatnot. :-)
---Joel
Had this one happen at a company, a mid-size one and otherwise rather efficient: "But we don't have a scope that would do that, do you know a place where we can rent one for a couple days?" ... "I do but I think Mr.So-and-so at your company has one." ... "Can I put you on hold for a minute?" ... "Sure." ... ... "Dang, indeed, he does!"
An FPGA isn't a very good DSP, either. Like everything in life, the appropriate tool depends on the task.
The real problem was the DMA that couldn't. It's still a nightmare, though after a dozen levels of work arounds it sorta works. At least we can catch it and reset, when it doesn't.
Wow. I would have definitely jumped to at least a different flavor of the same DSP (with working DMA) in such a case!
But I realize that with your hardware and firmware guys separated that's probably not so trivial to do...
Having used TI DSPs myself and heard the experiences of others, I'm starting to think that Analog Devices deserves another look... (even though it's pretty unlikely we'll stray from TI in the immediate future...)
There are none. The chips, of the same vintage design, are identical. The newer ones *should* have it fixed, but no guarantees.
It's not trivial to get management to open a nest of working snakes, either.
Good idea. AIUI we looked hard at ADI before settling on TI. The tipping point was G729 support. That part has never caused any grief. The hardware sucks, though. Oh, and I forgot to mention TI's documentation. Ack!
Plus FPGA can be real power hogs and the big ones cost a fortune.
Ah, interesting -- I had figured you guys had either cooked up your own CoDecs or at least written the code for some industry standard one.
---Joel
G729 is industry standard. ...or perhaps I missed your point.
Again, appropriate tools for the task. Some of the modern FPGAs are pretty miserly. Some are relatively cheap, too. Though your not going to replace code with hardware and save either power or money.
I was thinking you said TI had a bunch of code for G.729 they would just hand you whereas ADI did not, and that was a deciding factor in whose DSP to use. ...whereas if the programmers had been thinking, "we're going to write our own C code to implement G.729 per the written spec," then it wouldn't matter (so much) which DSP was used.
Now that I think about it more, it probably wouldn't have made sense to write your own implementation of G.729 since you'd still end up paying licensing fees anyway, I imagine, and I imagine it's complex enough you'd probably spend some man-months on it.
Sorry for the confusion. :-)
We do our own C code for vocoding... although in our present case it's little more than companding and SSB modulation. :-)
---Joel
Yeah, we bought it from a third-party. It was already done for the TI
55xx series. I suppose it could have been ported to ADI, I'm sure it would have cost more. AIUI, ADI had an G729 implementation but it was only a subset and we needed the whole Magilla.Compression and echo cancellation were third-party packages. They worked, though they really aren't hardware dependant. ;-)
Have something to add? Share your thoughts — no account required.
Ask the community — no account required