What is EDDS?

The Embedded Data Display System (EDDS) is a client/server software package intended to solve a rather specific problem: providing a common, lightweight way to extract and plot data (or images) from an embedded data source. The key term here is "lightweight".

This software might be useful to you, if:

You have an embedded device.
It doesn't have a graphics display.
It does have some form of communications link (e.g., ethernet, USB, etc.)
It's capturing or generating data that you'd like to plot or it's capturing image data that you'd like to display in realtime on your PC, Mac, or Laptop.

The software for EDDS comes in two peices. There is a server that must run your embedded application that manages the transport of your plot data to a connecting client application. The server software comes in the form of a library (EDDSourceLib), and must be ported to run on you embedded platform. The display client (EDDClient) is developed using the Qt Framework so that it may compiled to run on any platform supported by Qt, including Windows, Mac, and linux operating systems. Because the EDDS protocol is open, developers can use the EDD client or integrate their own data visualization software that can be used in a final "branded" product while using the same embedded codebase.

Background

The Embedded Data Display library and client was originally developed by Michael Williamson and Critical Link LLC in order to support data visualization needs of customers using the MityDSP, MityDSP-XM, and MityDSP-PRO processor platforms.

The need for data visualization on embedded devices almost immediately arises during the development of custom data acquisition hardware. Too many times have I observed co-workers and customers re-spinning the common engineering wheel whenever a new embedded platform is brought to life:

Find some way to export the data to CVS or XML.
Capture the data with a PC.
Load it into Excel or Calc.
Fiddle with charting the data or write crazy visual basic to visualize the data.

Or worse, rewrite (or copy and paste code around now apparently called "refactoring") custom application software on both the embedded platform and the display platform.

Or even worse, pay a pile of money to export the data to a mega pricey tool like Matlab or Labview. Not that I don't appreciate these tools (because I do, they are both extremely powerful), but there are a lot of times when you just want to see the data, not analyze it for the next 5 weeks. Besides, is it that hard to code up your own FFT routine?

While stewing on the problem, what I really wanted to define was an RFC that outlined a binary plotting protocol that was independent of the physical and transport link layers. OK, I really wanted to find someone else that had already done that and some code that already implemented it that I could port to the MityDSP,. No such luck.

I was all set to start an RFC call the "Plot Interface Message Protocol". That's right, "PIMP". But clearer minds prevailed, and writing and RFC looked extremely painful and I needed something immediately. Instead, EDD was started.

Some trades about the architecture:

I chose not to use XML for the transmission of the data or the meta data because I wanted *lightweight*, and I wanted to optimize bandwidth for devices having a low link data rate.
I chose not to use an embedded web server or java application to display the data (although I think it's a cool idea) because I wanted lightweight, and I wanted to optimize bandwidth for devices having a low link data rate. I also wanted to support non-ethernet solutions (e.g., USB or serial links).
I chose little endian data because (sadly) 99% of the people I deal with use PC's, and it felt silly to marshal to network order "just because".
If you ask why I didn't use something like ACE/TAO for a transport mechanism, you missed the "embedded" and "lightweight" theme completely.

Embedded Data Display System
Home About Screen Shots Download License EDDS @ SourceForge Doxygen Code Reference Bug Reports Feature Requests	What is EDDS? The Embedded Data Display System (EDDS) is a client/server software package intended to solve a rather specific problem: providing a common, lightweight way to extract and plot data (or images) from an embedded data source. The key term here is "lightweight". This software might be useful to you, if: You have an embedded device. It doesn't have a graphics display. It does have some form of communications link (e.g., ethernet, USB, etc.) It's capturing or generating data that you'd like to plot or it's capturing image data that you'd like to display in realtime on your PC, Mac, or Laptop. The software for EDDS comes in two peices. There is a server that must run your embedded application that manages the transport of your plot data to a connecting client application. The server software comes in the form of a library (EDDSourceLib), and must be ported to run on you embedded platform. The display client (EDDClient) is developed using the Qt Framework so that it may compiled to run on any platform supported by Qt, including Windows, Mac, and linux operating systems. Because the EDDS protocol is open, developers can use the EDD client or integrate their own data visualization software that can be used in a final "branded" product while using the same embedded codebase. Background The Embedded Data Display library and client was originally developed by Michael Williamson and Critical Link LLC in order to support data visualization needs of customers using the MityDSP, MityDSP-XM, and MityDSP-PRO processor platforms. The need for data visualization on embedded devices almost immediately arises during the development of custom data acquisition hardware. Too many times have I observed co-workers and customers re-spinning the common engineering wheel whenever a new embedded platform is brought to life: Find some way to export the data to CVS or XML. Capture the data with a PC. Load it into Excel or Calc. Fiddle with charting the data or write crazy visual basic to visualize the data. Or worse, rewrite (or copy and paste code around now apparently called "refactoring") custom application software on both the embedded platform and the display platform. Or even worse, pay a pile of money to export the data to a mega pricey tool like Matlab or Labview. Not that I don't appreciate these tools (because I do, they are both extremely powerful), but there are a lot of times when you just want to see the data, not analyze it for the next 5 weeks. Besides, is it that hard to code up your own FFT routine? While stewing on the problem, what I really wanted to define was an RFC that outlined a binary plotting protocol that was independent of the physical and transport link layers. OK, I really wanted to find someone else that had already done that and some code that already implemented it that I could port to the MityDSP,. No such luck. I was all set to start an RFC call the "Plot Interface Message Protocol". That's right, "PIMP". But clearer minds prevailed, and writing and RFC looked extremely painful and I needed something immediately. Instead, EDD was started. Some trades about the architecture: I chose not to use XML for the transmission of the data or the meta data because I wanted lightweight, and I wanted to optimize bandwidth for devices having a low link data rate. I chose not to use an embedded web server or java application to display the data (although I think it's a cool idea) because I wanted lightweight, and I wanted to optimize bandwidth for devices having a low link data rate. I also wanted to support non-ethernet solutions (e.g., USB or serial links). I chose little endian data because (sadly) 99% of the people I deal with use PC's, and it felt silly to marshal to network order "just because". If you ask why I didn't use something like ACE/TAO for a transport mechanism, you missed the "embedded" and "lightweight" theme completely.