Hi everybody.
I am trying to make an application that would take the data from the port that the real-time XScope uses and do something with it (e.g. create a diagram and similar, like Real-Time Scope in the xTimeComposer does). I have found this https://github.com/xcore/sc_xscope_support and was wondering if that is what I need (Are there any examples of usage?). I would also like to know which protocol is used and basically all you guys can tell me about this subject, since I couldn't find anything in the documentation.
Thanks
XScope host application Topic is solved
-
zivke
- Member
- Posts: 11
- Joined: Fri Aug 01, 2014 12:21 pm
-
Folknology
- XCore Legend
- Posts: 1274
- Joined: Thu Dec 10, 2009 10:20 pm
Yes thats the right host library to support xScope (it makes using the xScope socket interface simpler). There is an example of using the xScope IP/Port socket interface within the Startkit examples (host_dsp_control & host_dsp_gui), these should help get you started, not sure about documentation for the socket interface, haven't seen that as yet.
-
peter
- XCore Addict
- Posts: 230
- Joined: Wed Mar 10, 2010 12:46 pm
The xScope host interface is unfortunately not documented for the user yet and could potentially change over time. The best thing to do will be to use the sc_xscope_support library to build your application as this should be kept up to date with any changes to the interface.
Basically the application has to send an initial byte in the initialise_socket() function in order to tell the xScope server what data to send to that socket. The three types of data requested are RECORD, PRINT and REGISTER. RECORD messages are all the xScope data sent from the device. The PRINT messages are any messages created with println, printf, etc... and finally the REGISTER messages are sent making the connection between the xScope probe name and the ID.
xScope probes used to be addressed by using an integer ID. However, this makes it hard to leave probes in a module and merge that with any other modules or applications. Hence there is now a new file (config.xcope) that describes the probes using names. All the probes are then given IDs by the compiler taking into account all the other probes in the application. See https://github.com/xcore/sw_avb_lc/blob ... fig.xscope as an example of named probes. An example application which uses the probe name to ensure that it gets the right probe ID is the audio analyzer application: https://github.com/xcore/sw_audio_analy ... analyzer.c.
Once you have connected to the xScope socket of the xrun process the hook_data_received() function will be called for every block of data received from the device. Again there are lots of examples of sending data to/from the target device. The host/app_audio_analyzer in the github xcore/sw_audio_analyzer repo gives an example of an application which has both a console on the host that can control the device and an application which will send audio glitch data back to the host if one is detected. The xcore/sw_startkit_examples has a QT GUI application (host_dsp_gui) which is used to control a DSP processing core on the device.
You launch xrun with --xscope-port IP:PORT (for example --xscope-port 127.0.0.1:12346) in order for it to create a socket for a host application to connet to. These happen to be the default values that all the host applications expect to connect to.
Basically the application has to send an initial byte in the initialise_socket() function in order to tell the xScope server what data to send to that socket. The three types of data requested are RECORD, PRINT and REGISTER. RECORD messages are all the xScope data sent from the device. The PRINT messages are any messages created with println, printf, etc... and finally the REGISTER messages are sent making the connection between the xScope probe name and the ID.
xScope probes used to be addressed by using an integer ID. However, this makes it hard to leave probes in a module and merge that with any other modules or applications. Hence there is now a new file (config.xcope) that describes the probes using names. All the probes are then given IDs by the compiler taking into account all the other probes in the application. See https://github.com/xcore/sw_avb_lc/blob ... fig.xscope as an example of named probes. An example application which uses the probe name to ensure that it gets the right probe ID is the audio analyzer application: https://github.com/xcore/sw_audio_analy ... analyzer.c.
Once you have connected to the xScope socket of the xrun process the hook_data_received() function will be called for every block of data received from the device. Again there are lots of examples of sending data to/from the target device. The host/app_audio_analyzer in the github xcore/sw_audio_analyzer repo gives an example of an application which has both a console on the host that can control the device and an application which will send audio glitch data back to the host if one is detected. The xcore/sw_startkit_examples has a QT GUI application (host_dsp_gui) which is used to control a DSP processing core on the device.
You launch xrun with --xscope-port IP:PORT (for example --xscope-port 127.0.0.1:12346) in order for it to create a socket for a host application to connet to. These happen to be the default values that all the host applications expect to connect to.