Using QP Modeler for PSoC: Grabbing Serial Data for Display

This form is for general electronics discussions, but, not PSoC.

Moderator: ericb

Forum rules
As you would expect spam, vulgar language, or discussions not related to electronics are banned from this forum.

Using QP Modeler for PSoC: Grabbing Serial Data for Display

Postby rlobet » Thu Jun 07, 2012 11:58 am

Hello Folk.

Just some time ago, I have discovered the QP Modeler, from www.state-machine.com
This is an interesting tool for us, not only because of features provided to directly transform the UML Sequence Diagram used to design state machines, but also directly supports PSoC in a Framework especialy designed.

Coming to the point, this framework is able to provide debug information about the real-time behaviour of the design through a serial port. Every change in state and event will get dump through the serial port. Whether the actual bandwith usage should keep low, depends on design however.

Usualy, serial port are also used to dump debug information using the well-known (PRINTF) method. However, the bandwidth of this interface being limited, the overall system performance (running low-MIPS embedded processors such as M8C or i8051) will drop very quickly as the design grows.
I remember some ten years ago, I have used a tool, which draws real-time data that were embedded through the debug serial port, to an interface that displays the data as graphs. The first step was to embed the API into the operating system (just install API call and relation with STDIO).
Just now, I was browsing the web about this topic, but even YIPPY and Google could not help me to find this tool from an Israeli company which may have disappeared since then.

Nowaday, many company are making similar tools for logging through the serial port. People are usualy using MATLAB, LabView, or even Ms Excel to log data. For the later, the toolsuite is almost for free, such as those from Aggsoft. The problem is, if the tool does not implement a client-server, then the data will not be filtered at source. Of course, the instrumentation may be easier in this case, but you loose the flexibility which will put some limit to this logging method. For instance, if data are filtered at source, you can instrument the code better, adding a lot of information relevant to the detail of the function, knowing that the data will be filtered for the module of your interest after all. In fact, what every embedded developper needs, because it has a big advantage in performance and flexibility, is the concept of "Serial Wire Viewer" introduced for ARM Cortex.


Any advice about this topic, a hint about this Israeli tool, or any other toolsuite in free or pay version, will be welcome.

Yours sincerely,

R. Lobet
rlobet
Newbie
Newbie
 
Posts: 1
Joined: Thu Jun 07, 2012 11:20 am

Return to “%s” General Electronics Discussion

Who is online

Users browsing this forum: No registered users and 1 guest