CoreDX DDS on ThreadX is here!

April Newsletter 2013

Welcome to the Twin Oaks Computing, Inc Newsletter!

Our monthly newsletter brings you news and information about Twin Oaks Computing and our CoreDX DDS middleware. Be sure to "like", "follow" and "friend" us on our Social Networking sites for fun facts, free giveaways, and stories about Communications Middleware, Technology, and Twin Oaks Computing.

ThreadX and CoreDX DDS Optimize Data Distribution in Embedded Real-Time Devices

Communications middleware serves a variety of software systems, from deeply embedded real-time systems and mobile devices to enterprise and database systems. It enables communication between two otherwise separate software threads, tasks, components, processes, or applications to exchange information, either within one device or between multiple systems. The communications middleware simplifies the design, programming, and management of applications by streamlining how applications receive and process data. Communication is critical to coordinate the activities of various threads and applications.

For more information about CoreDX DDS on ThreadX, click here...

CoreDX DDS and FPGAs

Field Programmable Gate Arrays are a fast, versatile, scalable, and inexpensive development platform. FPGAs often need to communicate and interoperate with GPPs, DSPs, and other FPGAs. Software must manage these highly interconnected communications and interoperability issues, while still delivering optimal performance and reliability. It's not surprising that as more development occurs on FPGAs, developers want the functionality and convenience of a middleware like DDS.

For more information about CoreDX DDS and FPGAs, click here...

Frequently Asked Question: Possible Memory Leak

Question:My subscribing CoreDX DDS application has a memory leak somewhere. I've trimmed it down to a simplified application using CoreDX DDS, so I'm wondering if it is possible the leak is in CoreDX DDS?

Answer:Of course, anything is possible. However, we regularly and thoroughly test our CoreDX DDS products with an eye on memory, including very detailed profiling of every memory allocation and de-allocation. Let start at some common mistakes that can cause memory leaks in a subscribing CoreDX DDS application.

• Neglecting to call return_loan() after every successful read() and take() call.
• Neglecting to clear your data and sample_info sequences in between successive calls to read() or take().
• Allowing the samples to grow in your DataReader cache (for example, a History.kind = KEEP_ALL with infinite Resource Limits where the samples are not removed using take() or a configured Lifespan).
• Allowing the instances to grow in your DataReader cache (for example, an infinite ResourceLimits.max_instances where the DataWriter is not properly managing instance lifecycles).

If none of these are applicable in your application, please provide us with some sample code and/or the output from a memory profiling tool (for example, valgrind) and we will provide additional assistance.

Click here to learn more

More Upcoming Events

April 22-25, 2013 Design West, Silicon Valley, CA, USA. Read more...

June 17-21, 2013 OMG DDS Days, Berlin, Germany Read more...

June 18, 2013 Real Time Embedded Computing Conference, Denver, CO, USA. Read more...

October 23-25, 2013 RoboBusiness, Santa Clara, CA, USA Read more...

For more information about Twin Oaks Computing:

"Follow" us on Twitter...

"Like" us on Facebook...

View Twin Oaks Computing on Pinterest...

View Twin Oaks Computing Power Point Presentations discussing everything from Android to Interoperability on Slideshare...