View source

From Texas Instruments Embedded Processors Wiki

You do not have permission to edit this page, for the following reasons:

• The action you have requested is limited to users in one of the groups: Users, Editor.
• You must confirm your e-mail address before editing pages. Please set and validate your e-mail address through your user preferences.

You can view and copy the source of this page:

== Generic questions == === From where can I download DSP/BIOS^TM Link? === DSP/BIOS^TM Link releases can be downloaded from: https://www-a.ti.com/downloads/sds_support/targetcontent/link/index.html Recent releases (Version 1.63 onwards) can be downloaded from: http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/DSPLink/ === What do I get with DSPLink, and how do I get started? === Each DSPLink release is available as a full source release including: * Complete source code for the DSPLink product, with associated build system * Sample applications demonstrating the usage of all modules. * Release documents: Release Notes, User Guide, Install Guide, Programmer’s Guide, Porting Guide * Design documents for the DSPLink modules To get started with DSPLink, you can refer to the release documents available within the $(DSPLINK)/doc folder. Refer to the UserGuide for high level information on all protocols (DSPLink components) and the Programmer's Guide for guidance in choosing the protocol that is suitable for your needs. Once you have decided on your protocol, you can refer to sample applications available with the release for an example usage of the APIs. The sample applications are available within the $(DSPLINK)/gpp/src/samples and $(DSPLINK)/dsp/src/samples directory. For example, to use messaging with MSGQ module, refer to $(DSPLINK)/gpp/src/samples/message and $(DSPLINK)/dsp/src/samples/message. The design of the sample application is detailed in UserGuide. The InstallGuide for each platform contains installation instructions and also includes any other useful platform-specific information. Since DSPLink is available as a porting kit with full source, the Porting Guide provides detailed instructions for anyone attempting to port DSPLink to a different platform or GPP Operating System. === What can I port DSPLink to? === DSPLink can be ported to a different GPP operating system, or a different device/platform. === How easy (or difficult) is it to port DSPLink? === DSPLink is available as a porting kit with full source code and documents, including design documents. DSPLink is architected to ensure that it provides portability to: * A different GPP operating system or operating system variant: through usage of OSAL (OS Abstraction Layer) throughout DSPLink * A different device: through splitting of DSPLink code into generic and platform/device specific code within separate easily identifiable directories The DSPLink build system is also generic (make-based) and easily portable to a different operating system or device. The PortingGuide provided with each DSPLink release gives detailed information on different types of DSPLink ports. === How do I find out which version of DSPLink is compatible with a specific version of Codec Engine? === This is very well documented at: [[Codec Engine Roadmap]]. === How do I install a DSPLink patch release? === DSPLink patch releases (for example 1.40.05_p3) are meant to be installed over an existing installation of the base GA release. For example, patch release 1.40.05_p3 can be installed over an existing 1.40.05 GA installation by extracting the tar.gz file into the same base location where the 1.40.05 release is installed. <br> The patch release only contains files that are different in the patch, and is a consolidated patch containing all the previous patches (if any). For example, patch release 1.40.05_p3 is a consolidated patch, including previous patches 1.40.05_p1 and 1.40.05_p2 within it. === Does DSPLink support multiple DSPs? === DSPLink APIs are generic to allow multiple DSPs to be used. From DSPLink 1.60 onwards, multi-DSP support is tested with DSPLink in a star-topology only, i.e. with master GPP connected to multiple DSPs. A couple of reference multi-DSP configurations are also supported. === Does DSPLink support Linux kernel 2.6.18? === From DSPLink version 1.50 onwards, Linux kernel 2.6.18 and above are also supported within DSPLink. === Does DSPLink work on the Beagle Board? === Yes, it does. Further information can be obtained from <br> http://ossie.wireless.vt.edu/trac/wiki/BeagleBoard_DSPLink <br> http://ossie.wireless.vt.edu/trac/wiki/BeagleBoard_CodecEngine <br> == Configuration questions == === What is the --legacy option when I am trying to configure DSPLink? === DSPLink 1.6x releases added support for multiple DSPs connected to GPP in star-topology. In context of this change, certain API signature’s changed between 1.5x streams and 1.6x streams. The --legacy option is provided if application writer wants to use the DSPLink API's exactly the same as what they were in DSPLink 1.5x. If application writer has legacy content which they do not want to change, configure DSPLink using the --legacy option in the dsplinkcfg script. If application developer does not have existing content, do not use this option; Start using API's as present in the latest 1.6x release. === How should I choose between TSK mode or SWI mode in the --DspTskMode option when I am trying to configure DSPLink? === A command line option is provided in dsplinkcfg.pl static configuration script to enable TSK mode instead SWI mode. To enable TSK mode, pass –DspTskMode = 1 option to dsplinkcfg.pl script during DSPLink build configuration. This is an optional argument. If not provided, the current default of DSP SWI mode is assumed. Whenever any of our modules use MPCS for multi-processor protection of shared structures, SWI_disable is called on the DSP-side to protect locally i.e. no other tasks or SWI’s are allowed to execute, and scheduler was disabled. While this would give better performance for DSPLink APIs (since you are making sure it runs to completion), it holds up any other tasks or SWI’s that may want to execute even non DSPLink work, till the MPCS lock is released. Also, the time for which the DSP keeps spinning to get the lock with scheduler disabled can become high if the ARM thread has taken the lock and got preempted. MSGQ and CHNL modules drivers on the DSP-side also used SWI’s for doing actual processing on receiving the IPC interrupt. Similarly, other applications could use DSPLink APIs from SWI context. In DspTskMode, the behavior of MPCS is changed to have MPCS block on a semaphore instead of disabling scheduler. This ensures that only tasks that are actually using DSPLink would block waiting for the semaphore lock to be released. Other non DSPLink tasks and SWI’s would continue executing. To enable this, MSGQ and CHNL drivers have to create server tasks to receive and handle the IPC interrupts. Another impact of this is that in DspTskMode, DSPLink APIs cannot be called from SWI context, and can be called only from TSK context, since they internally call MPCS which would block on a semaphore. This mode would give better latency and enable other tasks/SWI’s to run even though DSPLink is blocked, but potentially the DSPLink API could take longer to run to completion, and hence give worse throughput for DSPLink Depending on the application need, choose the relevant mode. == Build questions == === How do I start trying to build DSPLink? === Check out [[Building_DSPLink|DSPLink install & build sequence]]. This gives a step-by-step guide on how to install and build DSPLink, alongwith pointers to different DSPLink documents where reference material can be found. === Can I build both GPP and DSP sides of DSPLink only on a Linux machine? === Yes! The DSPLink make system supports build of both GPP and DSP-side on a Linux machine. In fact, it is advised to use this method when you are using Linux as a GPP OS because: * A single DSPLink source base can be maintained for GPP and DSP-sides, minimizing possible version mismatch issues for GPP and DSP build. * Scripts can be written over basic DSPLink make system for doing a single-shot build of both GPP and DSP-sides * An NFS-mounted target file system can be easily used to transfer both generated GPP and DSP-side binaries into the target file system. TI provides [https://www-a.ti.com/downloads/sds_support/targetcontent/index.html Standalone DSP/BIOS downloads] and [https://www-a.ti.com/downloads/sds_support/TICodegenerationTools/download.htm Standalone Code Generation Tools downloads] which can be used for building DSPLink DSP-side on Linux. === Why am I getting build failures on Windows PC? === DSPLink can be built on either a Windows PC or a Linux PC. Usually, it is preferable to use the DSPLink Linux build for Linux-based development, since both GPP and DSP-side can be built on the same source base using Linux cross-compilers for GPP-side and Linux-based DSP/BIOS, CGTOOLS for DSP-side. However, users may wish to use a Windows PC for Linux-based development, through installation of mvcyg4.0 or similar. In such cases, the following important points must be considered: * Follow the steps detailed in UserGuide.pdf available with DSPLink release package for steps on customizing your build environment. * For GPP-side build, use the shell available with mvcyg4.0. * For DSP-side build, use dos shell. ** cygwin does not work correctly with DSP-side build due to path related issues when using Windows-based TI tools. ** Ensure that cygwin is removed from the path while using the dos shell. === Does DSPLink use the Linux kernel build system? === No. DSPLink supports multiple operating systems on the GPP-side. To keep the DSPLink build system generic, it does not use the Linux kernel build system, but uses its own make-based build system. === Why am I getting a struct_module warning when inserting the DSPLink kernel module on Linux? === This warning is seen because DSPLink does not use the Linux kernel build system. It is seen when there is a mismatch in certain build options between the Linux kernel and the DSPLink kernel module. However, it can be safely ignored. === Why am I getting a error when inserting the DSPLink kernel module on Linux insmod: error inserting 'dsplinkk.ko': -1 Unknown symbol in module? === If inserting the kernel modules failed with messages such as above, it typically means that they were compiled against a different Linux kernel than you are currently booting. Make sure you are booting the right kernel, and if you are make sure you rebuild the kernel modules against it. === Build errors! Where do I look? === Check out the [[Troubleshooting DSPLink build issues]] article. This lists most of the common build failures and their possible causes, and suggests solutions. == Integration questions == === Configuration issues & failures! Where do I look? === Check out [[Troubleshooting_DSPLink_configuration_issues|Trouble-shooting DSPLink configuration issues]]. This lists most of the common configuration-related issues and failures and their possible causes, and suggests solutions. === DSPLink sample applications and my algorithm work independently, but as soon as I integrate them, my DSP app stops receiving interrupts. Why? === There may be multiple reasons for the integration issues. Two of the common issues are: * Memory map ** DSPLink only defines default memory map, as needed for running its sample applications. However, applications needs for memory are most often much higher. ** The DSPLink memory map must be modified to ensure that the application's memory needs are also taken into consideration. ** The complete steps to modify DSPLink memory map are documented at [[Changing_DSPLink_Memory_Map|Changing DSPLink Memory Map]]. *DSP Interrupt vector ID ** DSPLink uses one or more interrupts for Inter-Processor-Communication between the GPP and DSP, as defined in the DSPLink configuration. ** These interrupts are received on the DSP by attaching them to DSP/BIOS HWI vector IDs. In general, DSPLink uses HWI vector IDs 4 and 5 (or only 4 on platforms where a single interrupt is used). ** If there is a conflict with your application or other drivers for any of these vector IDs, there will be issues in receiving interrupts. ** In DSPLink 1.40.05_p4 onwards (including DSPLink 1.50), the DSP interrupt vector ID(s) used by DSPLink are configurable through the dynamic configuration file <code>$(DSPLINK)/config/all/CFG_<platform>.c</code>. <br> For example, for DM6446, to change usage of interrupt vector from 4 to 6: <br> In <code>$(DSPLINK)/config/all/CFG_Davinci_DM6446.c file</code>, change the interrupt vector usage for the first instance of IPS from 4 to any free vector ID (in this case 6), on the DSP-side: <code lang = c> STATIC CONST LINKCFG_Ips LINKCFG_ipsTable_00 [] = { { "IPS", /* NAME : Name of the Inter-Processor-Signaling component */ (Uint32) 32, /* NUMIPSEVENTS : Number of IPS events to be supported */ (Uint32) 0, /* MEMENTRY : Memory entry ID (-1 if not needed) */ (Uint32) 46, /* GPPINTID : Interrupt no. to used by the IPS on GPP-side. (-1 if uni-directional to DSP) */ (Uint32) 16, /* DSPINTID : Interrupt no. to used by the IPS on DSP-side. (-1 if uni-directional to GPP) */ (Uint32) 4, /* DSPINTVECTORID : Interrupt vector no. to used by the IPS on DSP-side. (-1 if uni-directional to GPP) */ (Uint32) 50000000, /* ARGUMENT1 : Poll value for which IPS waits while sending event (-1 if infinite) */ 0 /* ARGUMENT2 : Second IPS-specific argument */ }, { "IPS", /* NAME : Name of the Inter-Processor-Signaling component */ (Uint32) 32, /* MAXIPSEVENTS : Number of IPS events to be supported */ (Uint32) 1, /* MEMENTRY : Memory entry ID (-1 if not needed) */ (Uint32) 47, /* GPPINTID : Interrupt no. to used by the IPS on GPP-side. (-1 if uni-directional to DSP) */ (Uint32) 17, /* DSPINTID : Interrupt no. to used by the IPS on DSP-side. (-1 if uni-directional to GPP) */ (Uint32) 5, /* DSPINTVECTORID : Interrupt vector no. to used by the IPS on DSP-side. (-1 if uni-directional to GPP) */ (Uint32) 50000000, /* ARGUMENT1 : Poll value for which IPS waits while sending event (-1 if infinite) */ 0 /* ARGUMENT2 : Second IPS-specific argument */ } } ; </code> === DSP-side has single DSPLINKMEM memory segment, but GPP-side config has two segments DSPLINKMEM & DSPLINKMEM1. Will it cause any issues? === No, it will not cause any issues. In the GPP side configuration, the sections are different only to demonstrate how to place different modules at different addresses. For examples, some modules may need to be placed starting at a specific address (needed for some configurations). Hence the DSPLink default configuration uses the <code>DSPLINKMEM</code> section of size 0x5000, which is fixed, into which the specific modules can be placed. The other section <code>DSPLINKMEM1</code> would hold everything else. <br> However, on DSP-side, the purpose of the memory segments is only to ensure that DSP/BIOS^TM does not use those memory regions for its own purpose (e.g. its code/data). Hence it is reserved from DSP/BIOS usage by defining them in the TCI file. Since we are just reserving the memory and not doing anything else through the TCI file, it does not matter whether we reserve the full 1MB in one shot, or reserve separately for the two regions. === When I am integrating two different applications using DSPLink, can I use different processes for them? === Yes. DSPLink can be used from different processes. In earlier DSPLink versions (1.40 & previous), DSPLink imposed certain restrictions on applications using DSPLink from multiple processes. From version 1.50 onwards, this has become much simpler. The details are given at: [[Using_DSPLink_from_multiple_processes|Using DSPLink from multiple processes]]. == Debugging questions == === Why am I getting a failure in setting breakpoints after infinite while loop on DSP-side? === For stopping execution on the DSP-side to be able to debug further, you should not put a direct while (1) loop, because the compiler removes all code after it automatically, which is probably why you are not able to set breakpoints. Execution of DSP can be suspended in 'main ()' by putting an infinite loop at the beginning of the function. However a simple 'while (1)' loop cannot be used as the compiler optimizes away the code after the while loop as that code becomes unreachable. To sneak through this optimization the following while loop can be used: <code lang='c'> { volatile Int i = 1 ; while (i) ; } </code> With this change in place on the DSP side application, follow these steps to be able to debug the DSP application. Follow these steps to break from the loop: * After <code>PROC_start()</code> is successful on GPP, halt the DSP. The DSP will be executing in the while loop. * Load the symbols of the DSP executable using CCS. * Open Quick Watch and set the value of i to 0, or use 'Set PC to Cursor' to break from the loop. The DSP application can now be debugged by placing breakpoints as required or single stepping through the code. === When I enable trace, why am I getting a lot of errors in APIs after "Entered DSPLINK_atExitHandler" print? === All the errors in the <code>DSPLINK_atExitHandler</code> can be ignored. From [[Migrating from DSPLink 1 40 to 1 50 | DSPLink v1.50]] onwards, on Linux, DSPLink registers an atExit handler with Linux to take care of all cleanup (shutdown APIs) that user may have neglected to do. All DSPLink APIs check for whether anything needs to be actually done in the function, or it's been called unnecessarily. If the application had, in fact, made all shutdown APIs as expected, each call in the atExit handler will have happened an extra time. In such cases, each API puts out error codes and possibly [[Debugging DSPLink using SET FAILURE REASON prints | SET_FAILURE_REASON prints]]. However, since all the cleanup has already happened in normal execution, the errors in atExit handler can be ignored. == Multi-process cleanup support questions == === Why does signal handler registered in my application stop working when I integrate DSPLink ? === Signal handling for Linux is enabled by default in DSPLink to provide basic cleanup functionality. The signal handling on Linux for cleanup is dynamically configurable through an OS-specific dynamic configuration file: $(DSPLINK)/config/all/CFG_<GPPOS>.c. The following items are configurable: * Handle signals for cleanup (TRUE/FALSE) - The default value is TRUE. This can be updated to FALSE to indicate DSPLink should not handle signals. * Signal numbers to be handled - This can be updated to provide the signal numbers which the DSPLink signal handler should handle. A re-build of DSPLink user side library and the application is required after updating the configuration to set Handle signals to FALSE. Note: While DSPLink provides basic cleanup functionality on abnormal termination through the signal handling, doing the right cleanup on exit is actually the purview of the application. Hence it is advised that the DSPLink signal handling mechanism should simply be used during development of the application to avoid having to re-boot the hardware on error. However, in the production system, the applications should use an appropriate signal handling mechanism to cleanup all application resources, followed by DSPLink (and other driver) resources on exit, possibly through a different signal handling thread. Note: If you are using CodecEngine, this change doesn't work. Seems like $(DSPLINK)/config/all/CFG_<GPPOS>.c is not used when using CodecEngine. See [http://www.mail-archive.com/davinci-linux-open-source@linux.davincidsp.com/msg14811.html here]. == MSGQ questions == === What is the difference between DSPLink MSGQ and DSP/BIOS MSGQ? === In functionality, DSPLink MSGQ and DSP/BIOS MSGQ are almost exactly the same. In fact, DSPLink gives a GPP-side representation for the DSP/BIOS MSGQ module on DSP-side. Most of the major functionality of MSGQ can be understood by going through DSP/BIOS MSGQ documentation. There are, however, a few differences between DSPLink MSGQ and DSP/BIOS MSGQ: * DSPLink MSGQ on GPP-side has additional APIs: <code>MSGQ_transportOpen()</code> and <code>MSGQ_transportClose()</code> to allow dynamically opening (configuring) and closing the DSPLink physical transport for MSGQ. These are not required and present on DSP-side, where MSGQ configuration is static. * There are some (minor) differences in API signatures on GPP and DSP-sides. * Some functionality of DSP-side MSGQ may not be supported on GPP-side due to the nature of the GPP OS. For example, while DSP-side MSGQ allows user to provide semaphore or other types of notification, GPP-side does not allow this, since the MSGQ APIs are in user-space, while the DSPLink logical implementation is in kernel space. Semaphore is used by default internally to DSPLink for notification. * DSPLink physical transport for MSGQ may impose additional restrictions over DSP/BIOS MSGQ related to calling context. For example, DSPLink 1.50 places the restriction that MSGQ calls falling down into the DSPLink transport (such as MSGQ_locate or MSGQ_put) must not be called from ISR context on DSP-side. === What is the maximum size of messages that can be exchanged using DSPLink messaging? === The Zero Copy Message Queue Transport does not impose any limitation on the maximum message size that can be transferred between the GPP and the DSP. The maximum message size is, however limited by the total POOL size specified for the SMA POOL in the DSPLink dynamic configuration. This also depends on the size of the memory entries made in the memory table to which the SMA POOL refers in the configuration. The maximum message size is limited by what is supported by the physical link between the two processors. === Are the message queues bidirectional? === The message queues are unidirectional. They are created on the receiving side. Senders locate the queue to which they wish to send messages. The queues may be present (created) on any processor in the system. === Can multiple threads receive messages on the same message queue? === Multiple threads/processes must not receive messages on the same Message Queue. Only a single thread/process owns the local Message Queue for receiving messages. However, multiple threads/processes may send messages to the same message queue (either local or remote). === Can the Message Queue be used to send variable sized messages? === Variable sized messages can be sent using the DSPLink messaging component. The message must contain the fixed message header as the first element. However, the rest of the message may be variable-sized. === Is it a requirement for a client to open a Message Queue when sending messages? === No, only a client that receives messages must open a MSGQ. === Can the same Message Queue names be used across processors? === The Message Queue names must be unique over the complete system. This includes Message Queues created across all processors in the system. === Is there a fixed format for the messages in the MSGQ? === The messages must have a fixed header as their first field. This header is used by the messaging component for including information required for transferring the message. The contents of the message header are reserved for use internally within DSPLink and should not directly be modified by the user. === Can I avoid calling MSGQ_locate? === Yes, <code>MSGQ_locate()</code> call can be avoided on one of the processors. This is possible by using the reply messsage facility in MSGQ. While sending a message, the user can choose to specify a source MSGQ. On receiving the message, the receiver may extract information about the source MSGQ from the message, and use it for replying to the received message. For example: *DSP-side creates its own Message Queue using <code>MSGQ_open()</code> *DSP-side locates the GPP-side Message Queue. *DSP-side then allocates a message using <code>MSGQ_alloc()</code> *Within this message, it sets the source queue as the handle of the Message Queue that the DSP has created, using <code>MSGQ_setSrcQueue()</code> API. *Now the DSP-side sends the message to the GPP-side Message Queue *On the GPP-side, the source queue handle is extracted by the GPP application using API <code>MSGQ_getSrcQueue()</code> *Now that the GPP-side has received the handle to the DSP-side Message Queue, it can start using this directly to send messages to the DSP-side Message Queue. In this way, GPP-side <code>MSGQ_locate()</code> has been avoided. To ensure that even the DSP-side <code>MSGQ_locate()</code> call passes within the first call, the GPP-side Message Queue can be created (opened) before <code>PROC_start()</code>. This will ensure that by the time the DSP comes up, it is sure that the GPP-side Message Queue already exists. In this way, the Message Queue location can be made more deterministic. === What are control messages? === Control messages are used internally by the Message Queue Transport for exchanging control information between the two processors. For example, control messages are used by the transport during <code>MSGQ_Locate()</code>. The user must also configure the pool with buffers of the control message size expected by the transport. For a reference configuration, please refer to the message sample application within the DSPLink product. === Can a client on GPP use DSPLink messaging for sending messages to a MSGQ residing on the same processor? === Yes. From DSPLink 1.50 onwards, the MSGQ APIs in DSPLink can be used for exchanging messages between local message tasks on the GPP. However, an OS-specific messaging implementation is recommended for efficiency. === Are messages required to be of a size greater than a fixed minimum size? === The size of the message must be greater than or equal to the size of the fixed message header: <br> <code>sizeof (MSGQ_MsgHeader)</code> === Why does MSGQ_put sometimes result in failure even though the handle to the message queue was previously obtained through a call to MSGQ_locate? === A call to <code>MSGQ_locate()</code> returns a handle to the message queue, based on the current status of the message queue. However, it is possible that the message queue that was located, is closed before <code>MSGQ_put()</code> is used to send a message to it. In this case, it cannot be ensured that the <code>MSGQ_put()</code> call will succeed, since the message queue is no longer valid. To avoid such situations where messages are dropped, the applications on the GPP and DSP can synchronize their cleanup activities. === Are there any restrictions on when an open message queue can be closed? === <code>MSGQ_close()</code> must be called before closing the POOL being used for allocating the messages. This is required, since the call to <code>MSGQ_close()</code> attempts to free any queued messages that have not been claimed by the application. Failure to call <code>MSGQ_close()</code> can result in a memory leak in the system. === Does DSPLink perform DSP-side cache coherence on message buffers? === Yes, cache coherence is performed for any messages sent using DSPLink messaging. However, if a buffer pointer is placed within a message sent using DSPLink messaging, the contents of that buffer are not kept cache-coherent, since there is no way for DSPLink to understand that the message contents are actually a buffer pointer, and not the buffer itself. In such cases, cache coherence can be performed by the application using DSP/BIOS BCACHE APIs. === Why does the MSGQ_get API call in my application crash? === One of the most common causes for MSGQ_get API call crash is improper synchronization between threads in an application. For e.g.: A thread is already blocked on MSGQ_get on the semaphore, and then another thread went ahead and closed that MSGQ. Then the semaphore would be deleted, and the thread that was blocked on MSGQ_get would crash in SYNC_WaitSEM call. Application needs to synchronize before MSGQ cleanup in threads. The threads calling MSGQ_get on the queues should be notified before MSGQ_close is done. === Can I remove the DSPLINK_ALIGN when I call MSGQ_alloc for the MSGQ buffers? === The message size must be a multiple of DSP L2 cache line size. This is required to ensure that the buffers are aligned on cache line boundary. This is essential to ensure that there is no cache corruption when we perform cache coherence operations on the message contents, which includes the message header and payload. If application writer has specified exactMatchReq as FALSE when creating the POOL that holds the message buffers, and you have ensured, during POOL configuration, that the buffer sizes are multiples of DSP L2 cache size, then when MSGQ_alloc is called, even without the DSPLINK_ALIGN (and it is a smaller size than 128 bytes), the POOL will return you the next highest size, which will be an aligned size. However, if you have specified exactMatchReq as TRUE, then MSGQ_alloc will fail if application writer does not use DSPLINK_ALIGN to align the size to cache line boundary. If application writer configures the POOL with non-aligned sizes, you will see non-deterministic behavior in older releases (due to cache related corruption issues) and in later releases of DSPLink (1.6x), you’ll get an error in POOL_open. == RingIO questions == === How do I configure foot-buffer for RingIO? === To configure foot-buffer for RingIO, all that needs to be done is to specify a non-zero size for the foot-buffer through RingIO attributes (<tt>RingIO_Attrs</tt>) passed to <code>RingIO_create()</code> API. '''Example''':<br> <code lang='c'> RingIO_Attrs ringIoAttrs ; ... ringIoAttrs.footBufSize = 2048 ; /* Set other values in ringIoAttrs */ ... status = RingIO_create (RingIOWriterName, &ringIoAttrs) ; </code> === Why am I getting DSP_EINVALIDARG error from RingIO_create when I try to configure foot-buffer?=== DSPLink internally does not allocate separate buffers for RingIO data buffer and RingIO foot-buffer. The RingIO foot-buffer is an extension of the data buffer, and physically contiguous to it in shared memory. If RingIO module were to allocate separate buffers for the data buffer and foot-buffer, they may not be physically contiguous to each other. Hence the total size (RingIO data buffer size + foot-buffer size) is allocated as a single buffer in RingIO_create. The application's POOL configuration must reflect this requirement, and configure a buffer of size (RingIO data buffer size + foot-buffer size), instead of separate buffers for RingIO data & foot-buffer. <br> '''Example:''' <br> *RingIO data buffer size = 1024 bytes *RingIO foot-buffer size = 2048 bytes *POOL must be configured with buffer of size (1024 + 2048 = 3072 bytes) *Configuring POOL only with sizes 1024 and 2048 bytes will not meet the requirements of the RingIO, and will result in failure in RingIO_create === Can I change the notification water-mark threshold or notification function at run-time? === Yes, it is possible to change the notification water-mark threshold by run-time. The <code>RingIO_setNotifier()</code> function can be called again with different water-mark value or a different function pointer in case this needs to be changed at run-time. === Can I disable notification once I have enabled it earlier using <code>RingIO_setNotifier</code> API? === Yes, notification can be disabled by calling <code>RingIO_setNotifier()</code> once again with <code>notifyType</code> parameter as <code>RINGIO_NOTIFICATION_NONE</code>. Do not pass NULL <code>notifyFunc</code>, because that will result in error from <code>RingIO_setNotifier()</code>, and will not achieve the result of disabling notifications. === Are there any alignment/size constraints on RingIO buffers allocated from POOL? === On C4x based devices, RingIO data buffer and attribute buffer must be aligned to the L2 cache line boundary for the DSP, i.e. 128 bytes. This is applicable to all buffers allocated from POOL. So RingIO buffer size (data buffer + foot-buffer), and attribute buffer size must be a multiple of 128 bytes. === Does the variable attribute structure have to be a multiple of 4 bytes in size? === Yes. This is to ensure that all attributes start at a 4-aligned address. If this is not present, then system crashes with bus error. That is because the attribute is internally typecasted to a pointer and accessed as one, and if it is not 4-byte aligned, then the access causes a crash. === Can a RingIO application use the <code>RingIO_Client</code> structure directly? === No, an application should not directly use the <code>RingIO_Client</code> structure. The <code>RingIO_Client</code> structure is accessed by both GPP and DSP, but all accesses are always locked using MPCS. If you access it directly in application outside the lock, then you may get inconsistent contents. If you need any values, then helper macros are provided for the most common ones (e.g. emptySize, validSize, acquired Size etc.) == Other FAQs == * [[DSPLink_POOL_FAQs|POOL FAQs]] [[Category : DSPLink]] [[Category:BIOSLink]] [[Category : FAQ]]

Return to DSPLink FAQs.