Bottom feeding network appliances

Hi,

A while ago, I was involved with an open source VoIP phone design. But, too many of those folks have "other commitments" and this isn't a big priority for them. OTOH, *I* would like to get some devices made for use, here, ASAP.

So, I've decided to "go it alone". This makes things a *lot* easier as I no longer have to worry about other folks' needs/wants/etc. Instead, I can just focus on getting the job done as I see fit (for *my* needs).

And, in harmony with my other design principles. :>

I think what I need (hardware) can be summarized as:

- SoC (real estate is critical -- perhaps 2 sq in)

- low power (existing phone is powered from CO battery so there is NO cost for that -- why would I want to increase my power consumption in the station set when I will already have to deal with the hub/switch's power needs 24/7!)

- 10 bit (?) linear CODEC at ~10KHz (or a companding CODEC)

- 10Mb/s Network interface

- 2 or 3 digital I/O's (things like hookswitch, etc.)

- probably 8KB RAM would be enough (optionally, move the entire application into RAM with a tiny ROM/FLASH loader)

- depending on RAM (and CODEC characteristics), probably 16K of TEXT -- maybe less (depends on how I chose to implement the network stack)

- reasonably low MIPS as the most complex thing here is packet handling

- one timer (more is nicer but not essential -- depending on how capable the instruction set is)

- some sort of watchdog to handle silicon glitches (there won't be any software bugs -- so the hardware has to behave 24/7/365)

- available in low volumes and reasonable cost (I only want to buy a dozen or so -- ideally, just a "sample" lot)

- friendly fabrication (i.e., no BGA's)

- free toolchain

I think this covers *all* of the requirements. So, any capabilities above and beyond aren't worth anything in terms of cost, board space, power consumption, etc. OTOH, anything that gives me an alternative to some of these might have offsetting justifications (e.g., a BT transceiver replacing the 10BaseTX interface).

The goal here is for me to learn something for other upcoming projects while tackling a current need at the same time. "Make one to throw away".

I'd be interested in folks' recommendations as to specific parts. And, pointers to any reference designs (mainly for the hardware as I suspect my software implementation will be radically different from a traditional approach).

Thanks!

--don

Reply to
D Yuniskis
Loading thread data ...

BlackFin EzKit. It has codec and Ethernet. IIRC there is sample VoIP application. There is GCC and embedded linux for fans.

Yea, I've seen a lot of products like "take a reference design, load a reference code to it, put in a shoe box and ship" :))))

VLV

Reply to
Vladimir Vassilevsky

I think that is way more hardware than is needed. :< No doubt the VoIP application uses standard protocols (which is why more CPU is needed than is otherwise necessary)

Yup. I think that is what happened in the US with all the DTV converter boxes! I am kicking myself for not being more alert and purchasing a reference design just so I could tinker with the converter itself. :<

Reply to
D Yuniskis

D Yuniskis skrev 2009-12-18 09:13:

Looks like the AT32UC3A1128/256/512 could be a candidate.

128/256/512 kB of flash

Should be fairly low power

16 bit Sigma-Delta DAC

10/100 Mbit Need external PHY

Plenty of I/O

32 or 64 kB SRAM

Lots of Flash

66 MHz => ~85 Dhrystone MIPS

More is available

Windowed watchdog

Yes

TQFP 100.

Eclipse + GCC Software Framework includes FreeRTOS & lwIP.

You can probably get a BT stack from plenty of places. WLAN SDIO support announced (see recent pressrelease at

formatting link
Without the need for Ethernet, there are other AVR32 choices. The AT32UC3A3 still has the codec, but adds other nice features for Audio Players.

EVK1105 is probably the best. No PCI slots available ...;-)

--
Best Regards
Ulf Samuelsson
 Click to see the full signature
Reply to
Ulf Samuelsson

In reading your notes here (as well as skimming the data sheet) this seems like a *lot* more processor than I need! :<

Hmmm... I didn't see that in my first pass through the datasheet.

That was expected. :>

I could live with a tenth of that! Possibly even less :-/

That's a win.

I'm not interested in anything that runs on the target; just the toolchain on the development host.

It seems (from a cursory glance at other manufacturer's literature as well) that ethernet support forces me to a beefier processor. Does that seem to be the case? I.e., sort of like if you want air conditioning in the car, you need to take the electric windows, moonroof, heated headliner, 17 channel stereo, backup camera and two year subscription to Driving Gloves magazine... :-/

Downgrading would, therefore, mean moving away from ethernet to some other transport medium?

For "part II" (separate post) that might be nice. But, for this task, it seems like most of those features would be overkill. What I want to learn from this application will be applied to deploying some *really* inexpensive devices (i.e., DM+DL below what this part itself costs)

In 2 sq in, I would be surprised if there were! :>

Thanks!

Reply to
D Yuniskis

I've hit a brick wall trying to find a COTS solution that will satisfy all my needs (board space is the *real* killer in this one!).

But, this looks like it *almost* will work for the "audio client" device (cf. "Bottom feeding network appliances II").

A bit short on RAM which means having to add an external device (which eats up more board space, etc.)

At 100K cycles, I guess I could treat the FLASH as "slow RAM" without worrying about durability (e.g., rewrite it *often*)?

Are there export controls (US) on the AES versions?

I've started porting one of my leaner stacks. There doesn't seem to be anything too "funky" in the processor or MAC that would pose much of a problem.

Yes, the MAC tends to limit what you can find available. :< Going wireless for this type of application just seems to be a waste of bandwidth.

OTOH, I've had an interest, locally, in a version of this that *was* wireless (802.11g/n). But, the USB support is just "Full" speed? (think: wireless dongle) That's not of interest to me, personally, but if I could support this need by something as simple as a differential stuffing option on the board (and let someone else write the USB interface) then it is low enough cost to me personally (time) that I would consider doing it.

I'm assuming I can get small quantities "off the shelf" (I'll check local stock) without long lead times (i.e., not "on allocation")? I'll finish the design and layout over the holiday and would like to go for boards the first or second week of the coming new year. (I imagine the PoE converter may be the bigger hassle :< )

Reply to
D Yuniskis

"D Yuniskis" schrieb im Newsbeitrag news:hhg86n$k0o$ snipped-for-privacy@speranza.aioe.org...

Help me out here - you were asking for a device with 8KB and are concluding that

64KB is "a bit short"? Misunderstanding or changed specs?

Stefan

Reply to
Stefan Carter

Two crossed designs unfortunately covered in this thread. The VoIP client could live with very little RAM -- voice has such a low bandwidth that a few KB is enough to buffer a sizable fraction of a second of speech.

Here's the comment in context:

The "audio client" processes "HiFi audio". So, even 64KB of RAM isn't much. Figure at least four bytes per sample, ~45K samples per second so 180KB / second. Of that 64K RAM, you would need housekeeping RAM, RAM to process the audio (i.e., you don't want to let DC on your output nor "nasty frequencies", etc.) Plus, overhead for network stack, authentication, etc. (you don't want foreign hosts pushing crap out your speakers!). I.e., you end up with a much smaller fraction of a second of buffer. (which means you have to add more smarts to figure out how to bridge those potentiual underruns)

Make sense? :>

Reply to
D Yuniskis

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.