Features
• Software Module Dedicated to Voice Processing
• Optimized for the AT75 Series Smart Internet Appliance Processor (SIAP™)
• Includes Several Run-time Configurable Standalone Algorithms
– G.729A Vocoder (8 Kbps)
– VAD/CNG Silence Compression (Annex B of G.729)
– G.711 µ-law and A-law Compression (64 Kbps)
– Arbitrary Tone Generator
• ITU-T G.729 and G.711 Standard-compliant
• Available with a uClinux® Device Driver
Overview
The AT75C1220 is a software module designed to run on the DSP subsystem of the
AT75 series Smart Internet Appliance Processor. It implements commonly used voice
processing algorithms:
•
A low bit rate G.729 vocoder for multimedia communication.
•
A silence compression algorithm to efficiently handle periods of silence during
communication.
•
A high-quality voice compression algorithm.
•
An arbitrary tone generator that can be used to generate any frequency during a
programmable duration.
All these algorithms have a number of parameters which can be programmed at run
time. These parameters modify the behavior of the DSP algorithms in such a manner
that they comply with the applicable standards under most situations. They also allow
the AT75C to cope with many non-standard situations often-encountered on private
telephone networks.
The AT75C1220 takes advantage of the AT75 mailbox to exchange data with the onchip ARM7TDMI® core. The organization of the data communication channel makes it
easy to integrate the AT75C1220 interface into most operating systems.
Smart Internet
Appliance
Processor
(SIAP™)
AT75C1220 –
G.729A and
G.711 Voice
Processing
Software
Module
For the developers using uClinux, a specific device driver is supplied. It allows the
uClinux capabilities to be extended to the complete functionality of the AT75C1220
module in a seamless manner.
This document is made up of three sections:
•
A functional description of the supported algorithms.
•
A description of the low-level software interface.
•
A description of the uClinux device driver.
Mixing low-level and driver-level programming should be avoided.
Rev. 1793A–01/02
1
Functional
Description
A functional block diagram of the AT75C1220 module is given in Figure 1.
The different algorithms are independent. They can be enabled, disabled or programmed
individually.
Figure 1. AT75C1220 Block Diagram
G.729 Encoder +
VAD/CNG
G.711 µ-law/a-law
Compression
Micro
A
F
E
Speaker
G.711 µ-law/a-law
Decompression
G.729 Decoder + CNG
Tone Generation
G.729 Vocoder
This algorithm can be used for compressing the speech or other audio signal components of a
multimedia service at a low bit rate. This coder has a bit rate of 8 Kbps. It is based on an Conjugate Structure Algebraic Code Excited Linear Prediction (ACELP) technique.
This coder operates on 10 ms speech frames of 16-bit linear PCM samples (sampling frequency is 8 kHz). A look-ahead of 5 ms and an algorithmic delay of 7.5 ms is to be taken into
account before getting an encoded voice data frame. This leads to a total delay of 15 ms.
Resulting encoded frames are 10 bytes long.
VAD/CNG
Voice Activity Detection (VAD) and Comfort Noise Generator (CNG) algorithms are designed
to work hand-in-hand with G.729 vocoder. Silence compression techniques are used to
reduce the transmitted bit rate during silent intervals of speech. The VAD side detects those
silent intervals. CNG is used to produce a noise that matches the actual background noise.
CNG uses information provided by VAD to encode silent intervals into Silence Insertion
Descriptor (SID) frames that are 2 bytes long. It also re-synthesizes 16-bit linear PCM samples
of background noise with a SID frame input. The VAD/CNG feature can be enabled or not by
means of a configuration command sent to the DSP (see “Request Notification Messages” on
page 7).
G.711 µ-law and Alaw Voice
Compression
µ-law and a-law are logarithmic compression techniques applied to speech signals. They are
done by simple operations that give no delay and excellent quality of speech. However, the bit
rate is high (each 16-bit linear PCM speech sample gives an 8-bit compressed sample leading
to 64 Kbps) making this feature useful only for broadband data networks. The compression/decompression algorithm can be chosen by means of a configuration command sent to
the DSP (see “Request Notification Messages” on page 7).
Tone Generator
The tone generation task generates a pure sine wave with programmable frequency, amplitude and duration.
2
AT75C1220
1793A–01/02
AT75C1220
Low-level
Interface
This section describes how the AT75C1220 software is uploaded into the DSP subsystem program memory. It also describes how the application software running on the ARM® and the
AT75C1220 running on the DSP Subsystem exchange information through the mailboxes.
This section assumes an in-depth knowledge of the ARM/DSP Subsystem interface mailbox
system.
Voice Module
Upload
While the DSP subsystem is held in reset, its program memory is made visible in the ARM
memory space. This allows the ARM application to write a binary image of the DSP software
very easily.
When the DSP subsystem is taken out of reset, its program memory is switched from the ARM
memory space back to the DSP program space just before the first instruction is fetched.
This process is illustrated in Figure 2.
Figure 2. Voice Module Upload
ARM
Core
SIAP_MDRB
ASB
OakB Program
Memory
P-Bus
Reset
Oak DSP
Subsystem
X-RAM
Upload Process
Y-RAM
A typical DSP program uses a number of initialized variables. Typically, the initial values are
stored in the program space, and copied into their RAM location by the DSP start-up routine.
This leads to the following statements:
•
Just after the boot routine has initialized the variables, the DSP subsystem exhibits high
redundancy since the same values exist in both program and data memories.
•
The initial values stored in the program memory waste space and are not used during
operation.
•
To improve the program memory usage, the software is loaded in two consecutive steps.
•
A small data initialization program is first loaded and executed. This program just initializes
the X- and Y-RAM to the values expected by the audio decoder software. When the
initialization is done, the program sends a DATA_INIT_DONE status message to the ARM
application through the status mailbox.
•
Then, the DSP subsystem is put in reset and the program itself is loaded. This code has
no data init start-up routine. It assumes the RAMs are already initialized, which saves
program space. When the software is ready to work, it sends a SW_INIT_DONE status
message through the status mailbox.
3
1793A–01/02
The mailbox operation and status messages are described in the section “Mailbox Usage” on
page 5.
Binary Image Format
When the system is idle, the AT75C1220 module is stored in the ARM memory space, possibly in nonvolatile memory. The module contains the data initialization code, the application
code and additional formatting data. The various fields of the AT75C1220 binary image are
described in Table 1.
Table 1. Binary Image Fields
Field Name
Offset from Start of Field (Bytes)
Length (Bytes)
Description
INIT_OFFSET
0
4
Defines the position of the data initialization code from
the beginning of the module image.
|INIT_LENGTH
4
4
Defines the length of the data initialization code (16-bit
words). Valid between 0 and 24576.
SW_OFFSET
8
4
Defines the position of the audio decoder program from
the beginning of the module image.
SW_LENGHTH
12
4
Defines the length of the audio decoder code (16-bit
words). Valid between 0 and 24576.
INIT_CODE
16
2*INIT_LENGTH
Binary code of the data initialization program.
SW_CODE
16 + 2*INIT_LENGTH
2*SW_LENGTH
Binary code of the application program.
DPMB
Configuration
The DPMB is programmed in configuration 2 (as defined in the AT75 Series Datasheet) that
leads to the configuration shown in Table 2. All the mailboxes allow read/write access from
both sides. Arbitration is done using the semaphores.
Table 2. DPMB Configuration
Mailbox No.
Offset from Base(1)
Length
Direction
Semaphore Address(1)
Usage
0
0x000
0x80
ARM -> Oak
0x200
TX encoded voice data
1
0x080
0x80
ARM <- Oak
0x204
RX encoded voice data
2
0x100
0x40
ARM -> Oak
0x208
DSP memory access
3
0x140
0x40
ARM -> Oak
0x20C
Unused
4
0x180
0x20
ARM -> Oak
0x210
Unused
5
0x1A0
0x20
ARM <- Oak
0x214
Unused
6
0x1C0
0x20
ARM -> Oak
0x218
Request notification
0x1E0
0x20
ARM <- Oak
0x21C
Status notification
7
Note:
4
1. Base address is 0xfa000000 for OakA, 0xfb000000 for OakB.
AT75C1220
1793A–01/02
AT75C1220
Mailbox Access
ARM to Oak Mailboxes
Before accessing the ARM->Oak mailboxes, the ARM must check that the corresponding
semaphore is cleared to 0. Then it can read or write the mailbox data. When the data access is
done, it must set the semaphore to 1 to notify the Oak that new data has arrived
Oak to ARM Mailboxes
The ARM is notified that new data is available in a mailbox when the corresponding semaphore is raised to 1, possibly triggering an interrupt. Then the ARM can access the mailbox.
When the access is finished, the ARM must clear the semaphore to release the mailbox.
Mailbox Usage
This section describes the specific purpose of each mailbox. The exchanged information is
formatted in structured messages. The message format and semantics are described in sections “Request Notification Messages” on page 7 and “Status Notification Messages” on page
10.
Mailbox 0: TX
Encoded Voice Data
Used by the ARM to provide to the OAK encoded speech frames (either G.711 data or G.729
data).
Mailbox 1: RX
Encoded Voice Data
Used by the ARM to get from the OAK encoded speech frames (either G.711 data or G.729
data).
Mailbox 2: Oak
Memory Access
The ARM has the ability to send requests to read or write any location of the DSP memories,
either in program or data space. This is useful for two purposes:
•
DSP software debug
•
Programming of the DSP peripherals under the ARM application control
Mailbox 6: Request
Notification
This mailbox is used by the ARM to pass requests to the DSP. These requests trigger specific
tasks in the DSP software. For example, request notification messages are used to start or to
stop the telephony algorithms
Mailbox 7: Status
Notification
This mailbox is used by the DSP software to send status information. For example, a status
notification message is sent by the DSP software at the end of the data initialization to notify
the ARM application that the data has been initialized.
TX/RX Encoded
Voice Data
The first two mailboxes deal with speech compressed frames. Each byte sent through the
mailbox is put in a 16-bit word where the low byte is the original byte value and in the high byte
are flags.
Assuming the data to be transmitted is in “char buf[0..N-1]”, it is formatted in the mailbox as
shown in Table 3 (otherwise the frame is ignored):
Table 3. Speech Frame Format
Word 0
...
Word i (i = 1... N - 2)
...
Word N - 1
FRAME_START|buf[0]
...
0x0000|buf[i]
...
FRAME_END|buf[N - 1]
with FRAME_START = 0x8000 and FRAME_END = 0x4000
Delivered frames are of variable length:
•
Length = 10 bytes for active speech frames
•
Length = 2 bytes for SID frames
•
Length = 1 byte: frame follows a 2-byte frame while the silence scheme is unchanged
If the system is in G.711 mode, frames are 64 words long.
5
1793A–01/02
Oak Memory
Access
The ARM has the ability to send requests to read or write any location of the Oak memories,
either in program or data space. To achieve this, the mailbox 2 is divided into four fields:
•
Command field (mailbox base + 0): This is a request ID that tells what kind of operation is
to be performed. Valid codes are:
–
0x0001: Program memory read
–
0x0002: Program memory write
–
0x0003: Data memory read
–
0x0004: Data memory write
•
Address field (base + 1 16-bit word): Should be written with the address location to be
accessed. This is the value of the address as it is seen by the Oak.
•
Length field (base + 2 16-bit words): Should be written with the number of consecutive
locations to access.
•
Data field (base + 3 16-bit words and following): For write access, should be filled with the
values to write. For read access, contains the read values requested by the previous
command.
Example of use: Write 0x1234 into data location 0xabcd of the 0akB:
1. Wait for *(0xfb000208) == 0, i.e., the semaphore is cleared
2. *(0xfb000100) = 0x0004 // data write command
3. *(0xfb000102) = 0xabcd // this is the address
4. *(0xfb000104) = 0x0001 // only one word to write
5. *(0cfb000106) = 0x1234 // this is the value
6. *(0xfb000208) = 1 // notify the OakB
Example of use: Read data locations 0xabcd and 0xabce from OakB:
1. Wait for *(0xfb000208) == 0, i.e. the semaphore is cleared
2. *(0xfb000100) = 0x0004 // data write command
3. *(0xfb000100) = 0x0003 // data read command
4. *(0xfb000102) = 0xabcd // this is the first address to read
5. *(0xfb000104) = 0x0002 // two words to read
6. *(0xfb000208) = 1 // notify the OakB
7. Wait for the semaphore to go back to 0.
8. Read 0xfb000106 and 0xfb000108 to get the requested values.
6
AT75C1220
1793A–01/02
AT75C1220
Request
Notification
Messages
Request messages are used by the ARM to trigger specific tasks running on the DSP. These
messages are always formatted in the same way. Figure 3 describes this format.
Figure 3. Request Notification Message Format
Mailbox Base Address
LENGTH
REQUEST_ID
PARAMETER[0]
...
LENGTH Words
PARAMETER[LENGTH - 2]
unused...
16 Bits
A message always begins with a LENGTH field. This field contains the number of words of the
message, excluding the LENGTH field itself.
The REQUEST_ID field is uniquely defined to designate the type of request. Each request can
be followed by a variable but well-defined number of PARAMETER fields. These fields contain
additional data needed to handle the request.
The description of the supported request messages is listed inTable 4. It is forbidden for the
ARM application to issue unsupported messages. However, should the ARM application issue
an unsupported or malformed request, the Oak software must recover gracefully.
G.729 Configuration
Request
This message is sent to the Oak before enabling any G.729 operation.
Table 4. G.729 Configuration Request
G.729 Decoding Start
Request
Word 0
0x0004
Message Length = 0x0004
Word 1
0x0420
Request ID = 0x0420
Word 2
USEVX
Enable[1]/Disable[0] VAD
Word 3
MICR_GAIN = 0x1000*10E(dB/20)
Gain for the microphone input
Valid: 0x0040 (-36 dB) to 0x8000 (+18 dB)
Word 4
SPKR_GAIN = 0x1000*10E(dB/20)
Gain for the speaker output
Valid: 0x0040 (- 36 dB) to 0x8000 (+18 dB)
The G.729 decode task starts as soon as the DSP unit receives this request.
Table 5. G.729 Decoding Start Request
G.729 Decoding Stop
Request
Word 0
0x0001
Message length = 0x0001
Word 1
0x0421
Request ID = 0x0421
The G.729 decode task starts as soon as the DSP unit receives this request.
Table 6. G.729 Decoding Stop Request
Word 0
0x0001
Message length = 0x0001
Word 1
0x0422
Request ID = 0x0422
7
1793A–01/02
G.729 Encoding Start
Request
The G.729 encode task starts as soon as the DSP unit receives this request.
Table 7. G.729 Encoding Start Request
G.729 Encoding Stop
Request
Word 0
0x0001
Message length = 0x0001
Word 1
0x0423
Request ID = 0x0423
The G.729 encode task is stopped as soon as this request is received by the DSP unit.
Table 8. G.729 Encoding Stop Request
G.711 Configuration
Request
Word 0
0x0001
Message length = 0x0001
Word 1
0x0424
Request ID = 0x0424
This message is sent to the Oak before enabling any G.711 operation.
Table 9. G.711 Configuration Request
G.711 Decompression
Start Request
Word 0
0x0005
Number of words of the message
Word 1
0x0410
Request ID
Word 2
LAW
Selected law for compression. Valid values:
0: µ-law
1: a-law
default 0
Word 3
LAWD
Selected law for decompression. Valid
values:
0: µ-law
1: a-law
default 0
Word 4
MICR_GAIN = 0x1000 * 10E(dB/20)
Gain for microphone input
Valid: 0x0040 (-36 dB) to 0x8000 (+18 dB)
Word 5
SPKR_GAIN = 0x1000 * 10E(dB/20)
Gain for the speaker output
Valid: 0x0040 (-36 dB) to 0x8000 (+18 dB)
The G.711 decompression task starts as soon as the DSP unit receives this request.
Table 10. G711 Decompression Start Request
G.711 Decompression
Stop Request
Word 0
0x0001
Number of words of the message
Word 1
0x0411
Request ID
The G.711 decompression task is stopped as soon as the DSP unit receives this request.
Table 11. G.711 Decompression Stop Request
8
Word 0
0x0001
Number of words of the message
Word 1
0x0412
Request ID
AT75C1220
1793A–01/02
AT75C1220
G.711 Compression
Start Request
The G.711 compression task starts as soon as the DSP unit receives this request.
Table 12. G.711 Compression Start Request
G.711 Compression
Stop Request
Word 0
0x0001
Number of words of the message
Word 1
0x0413
Request ID
The G.711 compression task is stopped as soon as the DSP unit receives this request.
Table 13. G.711 Compression Stop Request
Word 0
0x0001
Number of words of the message
Word 1
0x0414
Request ID
Tone Generation
Configuration Request
Table 14. Tone Generation Configuration Request
Word 0
0x0007
Message Length = 0x0007
Word 1
0x0800
Request ID = 0x0800
Word 2
32768 * cos (π * TONE_FREQ/4000)
Word 3
32768 * cos (π * TONE_FREQ/4000)
Words 2 and 3 define the frequency of the
generated tone
Word 4
TONE_LEVEL = 32768 * 10E(dB/20)
Level of the generated tone
Word 5
TONE_DURATION
Duration of the generated tone in
milliseconds
0x0000 means unlimited duration
Word 6
SILENCE_DURATION
Duration of the silence following the tone in
milliseconds
0x0000 means unlimited duration
Word 7
TONE_START
Bit 0: 0 causes the generator to wait for a
tone generation start request (request ID
0x0801) before the tone is generated
1: the generation starts immediately
Bit 1: 0: the tone is added to all other signals
emitted on the speaker
1: all other signals are blocked while the tone
is generated
Example: 0x0007 0x0801 0x5A82 0x5A83 0x4000 0x0080 0x0080 0x0003
This message configures the generator to emit a 1024 Hz tone 6 dB below the reference level.
The tone is emitted as soon as the DSP unit receives the request. After 128 ms of signal and
128 ms of silence, a tone generation done status message is emitted.
Tone Generation Start
Request
The tone starts as soon as the DSP unit receives this request. A tone generation configuration
request (request ID 0x0800) should be issued before the tone generation start request is sent.
If not, the behavior of the tone generator is unpredictable.
Table 15. Tone Generation Start Request
Word 0
0x0001
Message length = 0x0001
Word 1
0x0801
Request ID = 0x0801
9
1793A–01/02
Tone Generation Stop
Request
The tone stops as soon as the DSP unit receives this request. This request can be used to
stop an unlimited tone generation, or to halt the generator before the predefined duration has
elapsed (early termination).
Table 16. Tone Generation Stop Request
Status Notification
Messages
Word 0
0x0001
Message length = 0x0001
Word 1
0x0802
Request ID = 0802
Status messages are used by the Oak to inform the ARM application that a specific event has
occurred, or to respond to an earlier request. These messages are always formatted in the
same way. Figure 4 describes this format.
Figure 4. Status Notification Message Format
Mailbox Base Address
LENGTH
STATUS_ID
PARAMETER[0]
LENGTH Words
...
PARAMETER[LENGTH - 2]
unused...
16 Bits
A status message always begins with a LENGTH field. This field contains the number of words
of the message, excluding the LENGTH field itself.
The STATUS_ID field is uniquely defined to designate the type of status. Each status can be
followed by a variable but well-defined number of PARAMETER fields. These fields contain
additional status information.
The description of the supported status messages is listed below. It is forbidden for the Oak
program to issue unsupported status messages. However, should the Oak program issue an
unsupported or malformed status message, the ARM application must recover gracefully.
Data Initialization
Status
This status message is issued when the data initialization program has completed the data initialization process. The Oak can be safely reset and reloaded with the voice module precisely
named.
Table 17. Data Initialization Status
10
Word 0
0x0006
Message length = 0x0006
Word 1
DATA_INIT_DONE_ID
Status ID = 0x8001
Word 2
VERSION_MONTH
Word 3
VERSION_DAY
Version information:
Contains the date of the generation of the
binary file of the DSP.
Word 4
VERSION_YEAR
Word 5
VERSION_HOUR
Word 6
VERSION_MIN
AT75C1220
1793A–01/02
AT75C1220
Voice Module
Initialization Status
This status message is issued when the audio decoder has finished initializing itself and is
ready to accept request messages. The ARM should not issue any request messages before
this status message has been received.
Table 18. Voice Module Initialization Status
Bad Format Status
Word 0
LENGTH
Message length = 0x0001
Word 1
SW_INIT_DONE_ID
Status ID = 0x8002
The Oak issues this message when it has received a request message in which the LENGTH
field is not compatible with the request type. The Oak ignores the corresponding malformed
request.
Table 19. Bad Format Status
Unknown Request
Status
Word 0
LENGTH
Message length = 0x0002
Word 1
BAD_FORMAT_ID
Status ID = 0x80FF
Word 2
BAD_FORMAT_VALUE
Contains the request ID of the malformed
request message.
The Oak issues this message when it has received a request message with an unsupported
request ID field.
Table 20. Unknown Request Status
Bad Parameter Status
Word 0
LENGTH
Message length = 0x0002
Word 1
UNKNOWN_REQ_ID
Status ID = 0x80FE
Word 2
UNKNOWN_REQ_VALUE
Contains the request ID of the malformed
request message.
The Oak issues this message when it has received a request message with a parameter having an invalid value.
Table 21. Bad Parameter Status
Bad Speech Frame
Status
Word 0
LENGTH
Message length = 0x0002
Word 1
BAD_PARAM_ID
Status ID = 0x80FD
Word 2
UNKNOWN_REQ_VALUE
Contains the request ID of the malformed
request message.
This status is issued when a speech frame message does not have the correct header or
footer.
Table 22. Bad Speech Frame Status
Word 0
LENGTH
Message length = 0x0001
Word 1
BAD_FRAME_ID
Request ID = 0x84FF
11
1793A–01/02
Underrun Status
This status is issued when a speech frame takes too long to arrive, thus causing a discontinuity in the speech stream.
Table 23. Underrun Status
Word 0
LENGTH
Message length = 0x0001
Word 1
UNDERRUN_ID
Status ID = 0x84FD
To avoid flooding the ARM with underrun status bursts, this kind of message should be issued
at most once per compressed frame period, as long as the underrun state is encountered.
G.729 Decoding
Stopped Status
Message
This status is issued if the decode task was stopped by a G.729 decode stop request (request
ID 0x0422).
Table 24. G.729 Decoding Stopped Status Message
G.729 Encoding
Stopped Status
Message
Word 0
0x0001
Message length = 0x0001
Word 1
0x8422
Status ID = 0x8422
This status is issued if the decode task was stopped by a G.729 encode stop request (request
ID 0x0424).
Table 25. G.729 Encoding Stopped Status Message
G.711 Decompression
Stopped Status
Message
Word 0
0x0001
Message length = 0x0001
Word 1
0x8424
Status ID = 0x8424
This status is issued if the decompression task was stopped by a G.711 decompression stop
request (request ID 0x0412).
Table 26. G.711 Decompression Stopped Status Message
G.711 Compression
Stopped Status
Message
Word 0
0x0001
Message length = 0x0001
Word 1
0x8412
Status ID = 0x8412
This status is issued if the compression task was stopped by a G.711 compression stop
request (request ID 0x0414).
Table 27. G.711 Compression Stopped Status Message
Tone Generation
Status
Word 0
0x0001
Message length = 0x0001
Word 1
0x8414
Status ID = 0x8414
This message is issued when the tone duration has elapsed. It is not issued if the tone was
stopped by a tone generation stop request (request ID 0x0802).
Table 28. Tone Generation Status Message
12
Word 0
0x0001
Message length = 0x0001
Word 1
0x8802
Status ID = 0x8802
AT75C1220
1793A–01/02
AT75C1220
AT75C1220
Device Driver
The AT75C1220 software module is supplied with a device driver for uClinux. This device
driver enables the application developer to integrate all the AT75C1220 functionality into the
uClinux kernel. All the features of the AT75C1220 modules can be accessed through the standard uClinux API. This section documents this API.
Under uClinux, the device drivers are accessed through filesystem entries. The AT75C1220
device driver is a character type driver. The associated virtual file can be opened, read from,
written to and closed like any regular file. The major role of the device driver is to redefine the
file access methods, so that the application can interact with the underlying device as if it were
a file through the standard file manipulation functions. It provides the application with an
abstraction layer which hides the low-level interface on top of which it sits.
The AT75C1220 device driver is operated through the /dev/g729 filesystem. It is used for
G.729 operations.
G.729 Driver
Operations
The G.729 driver redefines the following file manipulation functions:
•
int open(const char *path, int flags, mode_t mode);
•
int read(int fd, void *buf, int count);
•
int write(int fd, void *buf, int count);
•
int select(int n, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, struct timeval
*timeout);
•
int close(int fd);
Additionally, the ioctl function allows control over additional features of the AT75C1220 that
are not accessible with the read or write methods. Those special commands are described
below. The prototype of the ioctl function is:
•
int ioctl(int fd, int request, char *argp);
Open Method
Synopsis
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
int open(const char *path, int flags);
Description
The /dev/g729 virtual file must be opened prior to any operation on the G.729 device driver.
This is done with the open method, just like for any regular file. The main operation performed
by the open method of the device driver is to load and initialize the corresponding DSP software in the DSP subsystem.
When this initialization is successful, the open system call converts the file path name
(“/dev/g729” in this case) into a file descriptor. This file descriptor is a non-negative integer that
is used in subsequent I/O operations such as with read, write, etc.
flags is one of O_RDONLY, O_WRONLY or O_RDWR which request opening the file readonly, write-only or read/write, respectively.
flags may also be bitwise-or’d with O_NONBLOCK. In this case, neither the open nor any subsequent operation on the file descriptor which is returned causes the calling process to wait.
13
1793A–01/02
Return Values
Open returns the new file descriptor, or -1 if an error occurred. In the latter case, the global
variable errno is set appropriately to reflect the cause of error. Possible values of errno are:
•
ENODEV: this indicates that the underlying hardware does not exist or is not supported.
One reason can be a corruption of the binary DSP software which could not be loaded into
the DSP subsystem.
•
EBUSY: the underlying hardware is busy. Most probably there is another process using
the same resource.
•
ENOMEM: a memory allocation requested by the driver failed. This happens when the
system memory is full.
Example
int fd = open("/dev/g729", O_RDWR | O_NONBLOCK);
This opens the G.729 device driver in read/write mode. It selects non blocking I/O for read and
write operations. The file descriptor is returned in fd. If fd is positive, the G.729 device is
readily available for read and write operations.
Close Method
Synopsis
#include <unistd.h>
int close(int fd);
Description
When the G.729 device is no longer needed by the application, it can be closed to release system resources. This is done through the close method. The parameter is the file descriptor of
the file to be closed.
Return Values
Close returns 0 on success, or -1 if an error occurred. In the latter case, the global variable
errno is set appropriately to reflect the cause of error. The only possible value for errno is
EBADF which means that fd is not a valid file descriptor.
Example
close(fd);
This closes the G.729 device previously opened.
Read Method
Synopsis
#include <unistd.h>
int read(int fd, void *buf, int count);
Description
As for any file descriptor, the read method attempts to read count bytes from fd into the buffer
starting at buf. When fd is a file descriptor attached to /dev/g729, the bytes read correspond to
the frame recognized by the G.729 decoding device.
Both blocking and non-blocking reads are supported. In blocking mode, read returns only
when there is a G.729 frame available to read. Although the process is blocked, it is safely put
on a system wait queue and does not consume CPU time.
In non-blocking mode, the read function returns immediately even if no data is available. In
this case the return value is -1 and errno is set to EAGAIN.
14
AT75C1220
1793A–01/02
AT75C1220
Return Values
On success, the number of bytes read is returned. It is not an error if this number is smaller
than the number of bytes requested. This may happen for example because fewer bytes are
actually available at the time, or because read was interrupted by a signal.
On error, -1 is returned and errno is set appropriately. Possible values for errno are as follows:
•
EAGAIN: non-blocking I/O has been selected using O_NONBLOCK and no data was
immediately available.
•
EBADF: fd is not a valid descriptor.
•
EINVAL: the /dev/g729 file was not open for reading.
•
EFAULT: buf is outside the accessible address space.
Example
ret = read(fd,buf,256);
This reads at most 256 bytes from file descriptor fd (assumed here to be related to /dev/g729),
and stores them into the memory location pointed to by buf.
Write Method
Synopsis
#include <unistd.h>
int write(int fd, void *buf, int count);
Description
As for any file descriptor, the write method attempts to write count bytes from the buffer starting at buf to the file descriptor fd. When fd is a file descriptor attached to /dev/g729, the bytes
written correspond to the G.729 frame which is to be emitted by the G.729 device.
Both blocking and non-blocking writes are supported. In blocking mode, write returns only
when the G.729 device is ready to accept data. Although the process is blocked, it is safely put
on a system wait queue and does not consume CPU time.
In non-blocking mode, the write function returns immediately even if no data is available. In
this case the return value is -1 and errno is set to EAGAIN. In most cases the application
retries to write until the entire data set is transferred.
Return Values
On success, the number of bytes written is returned. This corresponds to the number of G.729
bytes actually emitted. It is not an error if this number is smaller than the number of bytes
requested. This may happen for example because fewer bytes are actually acceptable at the
time due to lack of memory, or because write was interrupted by a signal.
On error, -1 is returned and errno is set appropriately. Possible values for errno are as follows:
Example
•
EAGAIN: non-blocking I/O has been selected using O_NONBLOCK and no data was
immediately available.
•
EBADF: fd is not a valid descriptor.
•
EINVAL: the /dev/g729 file was not open for reading.
•
EFAULT: buf is outside the accessible address space.
ret = write(fd,buf,256);
This writes at most 256 bytes to file descriptor fd (assumed here to be related to /dev/g729),
from the memory location pointed to by buf.
15
1793A–01/02
Ioctl Method
Synopsis
#include <sys/ioctl.h>
int ioctl(int fd, int request, char *argp);
Description
The ioctl function manipulates the underlying device parameters of the G.729 device.
fd is the file descriptor upon which ioctl acts. It is related to the /dev/g729 virtual file.
Request defines which predefined command to send to the G.729 device. Some commands
may require additional arguments that are stored or received in the buffer pointed to by argp.
The ioctl requests supported by the G.729 device driver are described below:
•
G729_START_PLAYBACK: This command is used to start the G.729 playback. There is
no additional argument.
•
G729_STOP_PLAYBACK: This command is used to stop the G.729 playback. There is no
additional argument.
•
G729_START_RECORD: This command is used to start the G.729 record. There is no
additional argument.
•
G729_STOP_RECORD: This command is used to stop the G.729 record. There is no
additional argument.
•
G729_CONFIG: This command is used to configure the characteristics of the G.729
vocoder algorithm. An additional parameter is used as defined below:
struct config_args {
unsigned short vad_cng;
unsigned short mic_gain;
unsigned short spk_gain;
};
The fields and the values to be written are those defined in the section on “Low-level Interface”
on page 3.
Example
struct config_args {
unsigned short vad_cng;
unsigned short mic_gain;
unsigned short spk_gain;
} *g729_conf;
g729_conf->vad_cng=0;//no VAD/CNG
g729_conf->mic_gain=4096;//micro gain 0dB under reference
g729_conf->spk_gain=4096;//speaker gain 0dB under reference
ioctl(g729, G729_CONFIG, g729_conf);
This configures the G.729 algorithm.
16
AT75C1220
1793A–01/02
AT75C1220
Installation
The AT75C1220 software is already installed in the software delivered with an AT75C.
Application
Example
Synopsis
#include <asm/arch/mailboxes.h>
The demo application delivered with AT75C1220 driver illustrates its capabilities.
Start a G.729
Recording
On the board type:
> voice -729 -rec <your_file>
This opens the G.729 device and records about 10 seconds of voice.
Start a G.729 Playback
On the board type:
> voice -729 -play <your_file>
This opens the G.729 device and plays back the specified file.
17
1793A–01/02
Atmel Headquarters
Atmel Operations
Corporate Headquarters
Memory
2325 Orchard Parkway
San Jose, CA 95131
TEL 1(408) 441-0311
FAX 1(408) 487-2600
Europe
Atmel SarL
Route des Arsenaux 41
Casa Postale 80
CH-1705 Fribourg
Switzerland
TEL (41) 26-426-5555
FAX (41) 26-426-5500
Asia
Atmel Asia, Ltd.
Room 1219
Chinachem Golden Plaza
77 Mody Road Tsimhatsui
East Kowloon
Hong Kong
TEL (852) 2721-9778
FAX (852) 2722-1369
Japan
Atmel Japan K.K.
9F, Tonetsu Shinkawa Bldg.
1-24-8 Shinkawa
Chuo-ku, Tokyo 104-0033
Japan
TEL (81) 3-3523-3551
FAX (81) 3-3523-7581
Atmel Corporate
2325 Orchard Parkway
San Jose, CA 95131
TEL 1(408) 436-4270
FAX 1(408) 436-4314
Microcontrollers
Atmel Corporate
2325 Orchard Parkway
San Jose, CA 95131
TEL 1(408) 436-4270
FAX 1(408) 436-4314
Atmel Nantes
La Chantrerie
BP 70602
44306 Nantes Cedex 3, France
TEL (33) 2-40-18-18-18
FAX (33) 2-40-18-19-60
ASIC/ASSP/Smart Cards
Atmel Rousset
Zone Industrielle
13106 Rousset Cedex, France
TEL (33) 4-42-53-60-00
FAX (33) 4-42-53-60-01
RF/Automotive
Atmel Heilbronn
Theresienstrasse 2
Postfach 3535
74025 Heilbronn, Germany
TEL (49) 71-31-67-0
FAX (49) 71-31-67-2340
Atmel Colorado Springs
1150 East Cheyenne Mtn. Blvd.
Colorado Springs, CO 80906
TEL 1(719) 576-3300
FAX 1(719) 540-1759
Biometrics/Imaging/Hi-Rel MPU/
High Speed Converters/RF Datacom
Atmel Grenoble
Avenue de Rochepleine
BP 123
38521 Saint-Egreve Cedex, France
TEL (33) 4-76-58-30-00
FAX (33) 4-76-58-34-80
Atmel Colorado Springs
1150 East Cheyenne Mtn. Blvd.
Colorado Springs, CO 80906
TEL 1(719) 576-3300
FAX 1(719) 540-1759
Atmel Smart Card ICs
Scottish Enterprise Technology Park
Maxwell Building
East Kilbride G75 0QR, Scotland
TEL (44) 1355-803-000
FAX (44) 1355-242-743
e-mail
[email protected]
Web Site
http://www.atmel.com
© Atmel Corporation 2002.
Atmel Corporation makes no warranty for the use of its products, other than those expressly contained in the Company’s standard warranty
which is detailed in Atmel’s Terms and Conditions located on the Company’s web site. The Company assumes no responsibility for any errors
which may appear in this document, reserves the right to change devices or specifications detailed herein at any time without notice, and does
not make any commitment to update the information contained herein. No licenses to patents or other intellectual property of Atmel are granted
by the Company in connection with the sale of Atmel products, expressly or by implication. Atmel’s products are not authorized for use as critical
ATMEL ® is the registered trademark of Atmel; SIAP ™ is the trademark of Atmel.
ARM ® and ARM7TDMI® are registered trademarks of ARM Ltd.; OakDSPCore ® is a registered trademark of
DSP Group Inc.; uClinux ® is the registered trademark of Lineo Inc. Other terms and product names may be the
trademarkS of others.
Printed on recycled paper.
1793A–01/02/0M