This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

debugserver accessing floating point value



The debug server, when it evaluates an expression, evidently always converts the result to type long, whereas the debugger as used in CCS obviously returns the appropriate type, which could be float. Why is this please, and how can I access a floating point value from memory using the debug server?

  • Hi Robert,
    Are you talking about when you use the scripting interface to the debug server (i.e. DSS)?

    Thanks
    ki
  • Yes, DSS, that is exactly what I meant.

  • The memory read APIs all return the value as a long. But you can always use the various javascript number conversion calls to convert the value to whichever format you wish. parseFloat() may be what you need:
    www.w3schools.com/.../jsref_parsefloat.asp

    Thanks
    ki
  • Hello Ki,

    I could be missing something but I don't think this answers the question at all. It could be just the result of a quick Google search. If it is, thanks for trying but I think we could do with an authoritative answer from the right department in TI.


    The premise of my question is that you would expect the debug server to offer enough functionality through the scripting interface to justify the use of the word debugger. But it does not even have a concept of 'float' apparently. How can this be? Is the thing half done? It has been around for a while.

    I still don't know if I am missing something big or it is simply a big hole in one of TI's tools which I guess no-one uses.

    Regards,

    Robert

  • Hi Robert,
    You are absolutely correct. DSS certainly does not have the most user friendly interface and also lacks functionality that it should just natively support. DSS is mostly used for basic debugger automation (connect to target, load, run, set breakpoints, profiling, etc) but that is no excuse. We are looking to overhaul our scripting environment to make it more user friendly and add back such missing functionality. Some discussion has arose over starting over with a new simplified API set and so forth but then there are concerns about backwards compatibility which I am a very strong advocate for. In any case, we are certainly aware of the current limitations of DSS and plan to do something about it.

    In the mean time, I have filed a bug for the lack for floating point support with the memory access DSS APIs. Tracking ID: SDSCM00052150

    Also my parseFloat suggestion is not the best suggestion in this case. You'd want to use Float.intBitsToFloat to extract the proper floating point value from the memory location you read with the current DSS APIs. Make sure Packages.java.lang is being imported:

    importPackage(Packages.java.lang)

    Float.intBitsToFloat(var)

    Thanks
    ki
  • Not knowing much about java or javascript it will take me a while to try this out. I think your suggestion is relying on the DSP representation for floating point being the same as that of the PC on which the debug server and java interpreter is running.

    DSS would be very good for regression testing so I am surprised that it is under-used. Anyone using DSS with a C67 processor would be asking what happened to float.  Yes, please maintain and improve DSS.

    -Robert Durkacz

  • This works well.

    Is there any advice about running DSS from java without using javascript? The reason I ask is that, following TI's start-up scripts and the above advice, we get the javascript interpreter running as a java application then javascript has a way of getting at java.lang modules like the one that understands the float format. So it might be more straightforward to do the whole thing in java.

  • Yes, you can use any language that can interface with Java APIs. Some other languages that I have been able to use are documented in the link below:
    processors.wiki.ti.com/.../Debug_Server_Scripting

    And yes, Java is one of those languages mentioned in the link above:
    processors.wiki.ti.com/.../Java_Scripting_with_DSS

    I understand why Java would be an attractive option (and it does make sense since DSS is simply a set of Java APIs). But we really do recommend javascript because it is the main language we support (best) out of the box.

    Thanks
    ki
  • I can't find documentation for the java API's. We are talking about the jar files that come with CCS right, eg dss.jar? The wiki article talks about "DSS Java API documentation" but does not provide a link.
  • The DSS Java API documentation is the main DSS API documentation. The location of it is mentioned in the link below:
    processors.wiki.ti.com/.../Debug_Server_Scripting

    Thanks
    ki
  • Now I get it, the same documentation works for both java and javascript because of the way javascript is. It is neat that it works that way.
  • Yes, exactly. DSS is really a set of Java APIs. But JavaScript plays very nicely with Java (whether to call DSS java APIs or java.lang.Float APIs) and we recommend it over Java for using DSS because it is much easier to get stated with JavaScript.

    Thanks
    ki
  • Previously Ki-Soo Lee wrote:

    In the mean time, I have filed a bug for the lack for floating point support with the memory access DSS APIs. Tracking ID: SDSCM00052150

    I think what is wanted is that the evaluation of expressions should simply return strings, eg for a float value "3.1418". That would be more normal than converting the expression to a numerical type within the debugger's world. Also, a function which returns the type of an expression should be provided, eg "float". Again this would just be normal, and that functionality is present in the GUI version. TI make a lot of debugging information available through command line tools in XML; even so I don't see how I would be able to extract the type of an expression by combining those tools with debug server scripting.

  • Robert,

    Just wanted to give you an update on this.

    We added a new API for evaluating an expression as a string, and this should be available in the next version of CCS.

    I do have a question about your request for adding an API for returning the 'type' of an expression. How did you envision using this API in scripting? During internal discussions on this topic, we were not able to come up with a use case where someone writing a script would know the variable name to evaluate, but not the type of the variable.

    With DSS, we want to keep the interface as simple and clean as possible. Therefore, we want to make sure there is a real need for a feature first before adding an API for it.

    Thanks,
    Ricky
  • Hi Ricky,

    I guess you are assuming that a user would not want to use DSS interactively, but it is quite possible to use it, being javascript, interactively and even put a lightweight java gui on top of it, which is what I have done recently for a client and would have liked to do in my time as a product developer. This way you can free yourself from the Eclipse-based CCS debugger which is fine when you want all that but difficult to do much with if you need to alter it. For example I might want to connect the DSS debugger to a much better java graphing component than you provide. It should be able to graph an expression appropriate to the type. Eg if it can see the type is float[1000] it should be able to graph it without me separately telling it there are 1000 points and they are floats.
    Thanks for asking,

    Robert