1. This forum section is a read-only archive which contains old newsgroup posts. If you wish to post a query, please do so in one of our main forum sections (here). This way you will get a faster, better response from the members on Motherboard Point.

Bottom feeding network appliances

Discussion in 'Embedded' started by D Yuniskis, Dec 18, 2009.

  1. D Yuniskis

    D Yuniskis Guest

    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
     
    D Yuniskis, Dec 18, 2009
    #1
    1. Advertisements

  2. D Yuniskis

    D Yuniskis Guest

    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. :<
     
    D Yuniskis, Dec 18, 2009
    #2
    1. Advertisements

  3. 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
    32 or 64 kB SRAM

    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 www.atmel.com).
    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 ...;-)
     
    Ulf Samuelsson, Dec 18, 2009
    #3
  4. D Yuniskis

    D Yuniskis Guest

    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!
     
    D Yuniskis, Dec 20, 2009
    #4
  5. D Yuniskis

    D Yuniskis Guest

    Hi Ulf,

    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 :< )
     
    D Yuniskis, Dec 30, 2009
    #5
  6. 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
     
    Stefan Carter, Jan 18, 2010
    #6
  7. D Yuniskis

    D Yuniskis Guest

    Hi Stefan,

    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? :>
     
    D Yuniskis, Jan 18, 2010
    #7
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.