TMS320 IDMA3 Channel Request Descriptor (IDMA3_ChannelRec)
Handle Handle to logical DMA channel
numTransfers Number of DMA transfers that are submitted using this logical channel handle. Single (==1) or Linked ( >= 2)
numWaits Number of individual transfers that can be waited in a linked start. (1 for single transfers or to wait for all transfers to complete.)
priority Relative priority recommendation {Urgent, High, Medium, Low}.
protocol Optional protocol handle for allocating channel environment (“env”) memory and calling custom channel initialization function.
persistent When persistent is set to TRUE, the granted physical EDMA resources (PaRAMs and TCCs) are for exclusive use by this channel. They cannot be shared with any other IDMA3 channel.
Tuesday, August 14, 2012
TMS320 IDMA3 Functions Description
TMS320 IDMA3 Functions Description
dmaChangeChannels() Called by an application whenever logical channels are moved at run-time.
dmaGetChannelCnt() Called by an application to query an algorithm about its number of logical DMA channel requests.
dmaGetChannels() Called by an application to query an algorithm about its DMA channel requests at initialization time, or to get the current channel holdings.
dmaInit() Called by an application to grant DMA handle(s) to the algorithm at initialization.
TMS320 Framework Components DMAN3ACPY3 Users Guide
TMS320 Framework Components DMAN3ACPY3 Users Guide
The direct memory access (DMA) controller performs asynchronously scheduled data transfers between memory regions without the intervention of the CPU. The parallel operation of the DMA with the execution of the CPU relieves the CPU of the burden of these data transfers. This allows a system to achieve greater throughput.
Algorithms and client applications may want to take advantage of the DMA to overlap data movement with CPU processing. However, XDAIS does not allow compliant algorithms to directly access or control any hardware peripherals, including the DMA. All system DMA resources must be controlled by the client application.
The new Framework Components DMA utilities allow XDAIS algorithms and client applications to utilize DMA resources by providing standard DMA software abstractions and interfaces. Framework Components now includes the following DMA modules and interfaces:
IDMA3. This is the standard interface to algorithms for DMA resource specification and negotiation protocols. This interface allows the client application to query and provide the algorithm its requested DMA resources.
DMAN3. This is the DMA resource manager. It is responsible for managing and granting DMA resources to algorithms and applications based on the IDMA3 interface.
ACPY3. This is the functional DMA interface and library. The ACPY3 interface describes a comprehensive list of DMA operations that an algorithm can perform on the logical DMA channels acquired through the IDMA3 protocol. These functions are implemented as part of the client application and are called by the algorithm.
The following figure shows which modules are implemented by client application frameworks and which are implemented by algorithms or components. Arrows indicate which modules use other modules.
Client applications use the algorithm's IDMA3 interface to query the algorithm's DMA resource requirements and grant the algorithm logical DMA resources via handles. Each granted handle provides the algorithm a uniform, private logical DMA channel abstraction. Algorithms, upon getting provisioned by the framework with their DMA resource needs, may call ACPY3 functions to schedule DMA transfers on the logical DMA channels. Alternatively, algorithms may provide their own DMA functions to program the physical DMA resources acquired through the IDMA3 protocol.
The basic ideas and objectives described in the "Use of the DMA Resource" chapter of TMS320 DSP Algorithm Standard Rules and Guidelines (SPRU352) apply to the design, implementation and use of the ACPY3 and IDMA3 interfaces. Collectively, IDMA3, DMAN3, and ACPY3 provide a flexible and efficient model that greatly simplifies the management of system DMA resources and services by the client application. They also provide a simple and powerful mechanism for algorithms to configure and access DMA services.
The following tables summarize the API functions and structures used by the IDMA3, ACPY3, and DMAN3 interfaces.
The direct memory access (DMA) controller performs asynchronously scheduled data transfers between memory regions without the intervention of the CPU. The parallel operation of the DMA with the execution of the CPU relieves the CPU of the burden of these data transfers. This allows a system to achieve greater throughput.
Algorithms and client applications may want to take advantage of the DMA to overlap data movement with CPU processing. However, XDAIS does not allow compliant algorithms to directly access or control any hardware peripherals, including the DMA. All system DMA resources must be controlled by the client application.
The new Framework Components DMA utilities allow XDAIS algorithms and client applications to utilize DMA resources by providing standard DMA software abstractions and interfaces. Framework Components now includes the following DMA modules and interfaces:
IDMA3. This is the standard interface to algorithms for DMA resource specification and negotiation protocols. This interface allows the client application to query and provide the algorithm its requested DMA resources.
DMAN3. This is the DMA resource manager. It is responsible for managing and granting DMA resources to algorithms and applications based on the IDMA3 interface.
ACPY3. This is the functional DMA interface and library. The ACPY3 interface describes a comprehensive list of DMA operations that an algorithm can perform on the logical DMA channels acquired through the IDMA3 protocol. These functions are implemented as part of the client application and are called by the algorithm.
The following figure shows which modules are implemented by client application frameworks and which are implemented by algorithms or components. Arrows indicate which modules use other modules.
Client applications use the algorithm's IDMA3 interface to query the algorithm's DMA resource requirements and grant the algorithm logical DMA resources via handles. Each granted handle provides the algorithm a uniform, private logical DMA channel abstraction. Algorithms, upon getting provisioned by the framework with their DMA resource needs, may call ACPY3 functions to schedule DMA transfers on the logical DMA channels. Alternatively, algorithms may provide their own DMA functions to program the physical DMA resources acquired through the IDMA3 protocol.
The basic ideas and objectives described in the "Use of the DMA Resource" chapter of TMS320 DSP Algorithm Standard Rules and Guidelines (SPRU352) apply to the design, implementation and use of the ACPY3 and IDMA3 interfaces. Collectively, IDMA3, DMAN3, and ACPY3 provide a flexible and efficient model that greatly simplifies the management of system DMA resources and services by the client application. They also provide a simple and powerful mechanism for algorithms to configure and access DMA services.
The following tables summarize the API functions and structures used by the IDMA3, ACPY3, and DMAN3 interfaces.
Monday, July 16, 2012
Who Invent PCB
The Austrian Jewish engineer Paul Eisler invented the printed circuit while working in England around 1936 as part of a radio set. Around 1943 the USA began to use the technology on a large scale to make proximity fuses for use in World War II . After the war, in 1948, the USA released the invention for commercial use. Printed circuits did not become commonplace in consumer electronics until the mid-1950s, after the Auto-Sembly process was developed by the United States Army.
Before printed circuits (and for a while after their invention), point-to-point construction was used. For prototypes, or small production runs, wire wrap or turret board can be more efficient. Predating the printed circuit invention, and similar in spirit, was John Sargrove's 1936–1947 Electronic Circuit Making Equipment (ECME) which sprayed metal onto a Bakelite plastic board. The ECME could produce 3 radios per minute.
Before printed circuits (and for a while after their invention), point-to-point construction was used. For prototypes, or small production runs, wire wrap or turret board can be more efficient. Predating the printed circuit invention, and similar in spirit, was John Sargrove's 1936–1947 Electronic Circuit Making Equipment (ECME) which sprayed metal onto a Bakelite plastic board. The ECME could produce 3 radios per minute.
Monday, June 25, 2012
MCU CRACK Engineering
Beijing Techip provide MCU crack and decryption service for all Z86Eserial MCU, part of the Z86E serial models are listed below:
Z86E03 Z86E04 Z86E06 Z86E07 Z86E08 Z86E11 Z86E122 Z86E123 Z86E124 Z86E125 Z86E126 Z86E132 Z86E133 Z86E134 Z86E135 Z86E136 Z86E142 Z86E143 Z86E144 Z86E145 Z86E146 Z86E18 Z86E21 Z86E23 Z86E30 Z86E31 Z86E33 Z86E34 Z86E40 Z86E43 Z86E44 Z86E61 Z86E63 Z86E73 Z86E74 Z86E83 Z89371 Z86E001 Z8PE00 Z8PE003
Please contact us :techip688@gmail.com
Wednesday, June 6, 2012
Transit of Venus
This afternoon, Venus began its "transit" across the face of the sun as
the planet passed directly between the Sun and Earth, a rare and
spectacular sight for skywatchers. The next transit will take place in
2117.
Monday, May 28, 2012
Virus Infects Computers Across Middle East
A complex computer virus has been pilfering confidential information
from computers in the Middle East for at least two years, according to a
security report released on Monday.
The virus, called Flame, has been infecting computers in Iran, Israel, Lebanon, Sudan, Syria, Saudi Arabia and Egypt. It has been grabbing images of users’ computer screens, recording their instant messaging chats, remotely turning on their microphones to record their audio conversations and monitoring their keystrokes and network traffic, according to a report by Kaspersky Labs, a Moscow-based security research firm.
If the report’s findings prove to be true, Flame would be the third major Internet weapon to have been discovered since 2010. The first, named Stuxnet, was intended to attack software in specialized industrial equipment, and was used to destroy centrifuges in an Iranian nuclear facility in 2010. The second virus, called Duqu, like Flame, performed reconnaissance. Security researchers believe Duqu was created by the same group of programmers behind Stuxnet.
The researchers said Flame appeared to have been developed by a different group of programmers. It contains 20 times more code than Stuxnet and is much more widespread than Duqu. Researchers believe Duqu hit fewer than 50 targets worldwide. Kaspersky’s researchers said they had detected Flame on thousands of computers belonging to individuals, private companies and universities across the Middle East.
“Flame can easily be described as one of the most complex threats ever discovered,” Alexander Gostev, the head of Kaspersky’s Global Research and Analysis team, wrote in a blog post on Monday. “It’s big and incredibly sophisticated. It pretty much redefines the notion of cyberwar and cyberespionage.”
Researchers say they do not know who is behind the virus, but given its complexity and the geography of its targets, they said it was most likely being staged by a government. The authors of Stuxnet and Duqu are also unknown but their targets and digital evidence suggest to some researchers that they may have been part of a joint American-Israeli project to sabotage Iran’s nuclear program.
Kaspersky’s researchers said the majority of computers infected with Flame were located in Iran. Like Duqu and Stuxnet, Flame infects machines through a known security hole in the Windows operating software.
Researchers discovered Flame while investigating reports that another computer virus, called Wiper, had been erasing computer programs in Iran. The International Telecommunications Union, a United Nations agency, had asked Kaspersky’s researchers to look into Wiper when they discovered that thousands more computers had been infected with Flame.
The virus, called Flame, has been infecting computers in Iran, Israel, Lebanon, Sudan, Syria, Saudi Arabia and Egypt. It has been grabbing images of users’ computer screens, recording their instant messaging chats, remotely turning on their microphones to record their audio conversations and monitoring their keystrokes and network traffic, according to a report by Kaspersky Labs, a Moscow-based security research firm.
If the report’s findings prove to be true, Flame would be the third major Internet weapon to have been discovered since 2010. The first, named Stuxnet, was intended to attack software in specialized industrial equipment, and was used to destroy centrifuges in an Iranian nuclear facility in 2010. The second virus, called Duqu, like Flame, performed reconnaissance. Security researchers believe Duqu was created by the same group of programmers behind Stuxnet.
The researchers said Flame appeared to have been developed by a different group of programmers. It contains 20 times more code than Stuxnet and is much more widespread than Duqu. Researchers believe Duqu hit fewer than 50 targets worldwide. Kaspersky’s researchers said they had detected Flame on thousands of computers belonging to individuals, private companies and universities across the Middle East.
“Flame can easily be described as one of the most complex threats ever discovered,” Alexander Gostev, the head of Kaspersky’s Global Research and Analysis team, wrote in a blog post on Monday. “It’s big and incredibly sophisticated. It pretty much redefines the notion of cyberwar and cyberespionage.”
Researchers say they do not know who is behind the virus, but given its complexity and the geography of its targets, they said it was most likely being staged by a government. The authors of Stuxnet and Duqu are also unknown but their targets and digital evidence suggest to some researchers that they may have been part of a joint American-Israeli project to sabotage Iran’s nuclear program.
Kaspersky’s researchers said the majority of computers infected with Flame were located in Iran. Like Duqu and Stuxnet, Flame infects machines through a known security hole in the Windows operating software.
Researchers discovered Flame while investigating reports that another computer virus, called Wiper, had been erasing computer programs in Iran. The International Telecommunications Union, a United Nations agency, had asked Kaspersky’s researchers to look into Wiper when they discovered that thousands more computers had been infected with Flame.
Subscribe to:
Posts (Atom)