Why embedded

An embedded system is built to be specific to its task using minimal software/hardware to achieve maximum reliability, minimal cost, and minimal physical size.  Think network appliance not computer server.  One of the outcomes is that a Compact Flash (CF) drive is used instead of a hard drive.

There are a number of advantages to using CF.  It has no moving parts, no spin up time, uses much less power than hard drives, generates almost no heat, is physically very small, and makes no noise.  Hard drives are particularly vulnerable to corruption during power failure.  You can use a RAID array and a UPS to improve reliability but that adds cost, increased power requirements, more heat generation, more noise and increased physical space requirements. 

Because of the lower power requirements and minimal heat generation with CF, a small fan less ATX power supply or low cost power brick with DC output may be an option. You would also need a suitable motherboard with DC input or DC converter to plug into a standard ATX motherboard connector.  While we are at it, choosing a CPU that does not require a fan is preferable assuming you are not doing a lot of CPU intensive tasks such as transcoding, software echo cancellation, and multiple simultaneous calls.  A fan is just another thing that can and does fail not to mention the fact it adds noise.  Of course, there is nothing stopping you from using just about any old PC you may have sitting around, at least for experimenting.

There is a lot of information on the internet about choosing the appropriate speed CPU for your particular asterisk application.   This is all beyond the scope of this article. 

Hardware

It is assumed you have a Windows PC with a CDRW for downloading and burning your Linux software to CD.  It is also assumed you have high speed internet and a multi port router.  The Development system motherboard should be as close as possible to the production system.  Ideally it should be exactly the same otherwise you will have to rely on more loadable module drivers for all the differences.  That increases the size of your bootable image.  The larger the bootable image the more RAM needed and the longer it takes to load the image into RAM which slows down your boot time and so on.

The hardware can be broken down into Development and Production platforms:

*I created 3 primary partitions on a 256MB SanDisk CF.  1 is mounted read only and contains the file system.  The other is mounted read/write for the Asterisk configuration (.conf) files which are expected to change infrequently.  The 3^rd is mounted read/write for Voicemail.  CF drives do not recognize partitions internally as far as I know.  They have built in management features such that, in theory, if multiple internal write failures occur the built in controller eventually decides the device can no longer be written to reliably.  At that point the entire device is permanently switched to read only mode.  A failure in the Voicemail partition will cause all 3 partitions to become read only.  If that is the case it is quite acceptable for this application.  It would allow the system to continue to operate (without Voicemail or configuration changes) until such time as the CF can be replaced.  Since CF is quite inexpensive these days there is no reason you could not use a second CF device and avoid any potential write failure issues affecting the loadable file system and configuration files on partition 1 and 2 all together.  USB flash drives are also a low cost option for Voicemail which I may try in the future.

**At the time of this writing, most CF to IDE adapters and CF drives do not support DMA mode.  That seems to be quickly changing.  The standard SanDisk 256MB CF I purchased did support DMA but the CF to IDE adapter I purchased about the same time did not.  This caused a delay problem during booting and mounting of the CF.  Disabling DMA in the BIOS did not solve the problem.  I had to enter an ide=nodma statement into the GRUB menu.1st file.  DMA is much more desirable because it prevents IDE interrupts and reduces the load on the CPU in general.  These are both highly advantageous for a real-time system like an IP PBX.