Programatic access to software simulator

Post your requests and ideas on the future development of mikroC PRO for dsPIC30/33 and PIC24.
Post Reply
Author
Message
LanceBeasley
Posts: 64
Joined: 01 Mar 2016 15:39

Programatic access to software simulator

#1 Post by LanceBeasley » 13 Jun 2018 15:03

I have gotten into the habit of writing a fair amount of test code in mikroC. I pull the library files into a test project where the functions can be tested in main().

Having written a lot of NodeJS test code using libraries like Mocha, Rewire, Should I was able to catch a lot of bugs early, and more importantly to catch bugs introduced during rewrites, just by re-running the test code. Further, we use gitlab for our code repository which allows us to write macros for various events, especially during commits which allows us to run test code automatically.

I would like 2 features added to the simulator:
  1. Make some kind of object available in the simulator that can be called using special functions in code where test data can be stored, whether variables, memory, data from the Watch Clock, etc.
  2. Further, make this object (and the debugger) accessible from the command line in the form of stdin (to push the object into the simulator) and stdout (to get the results of the test).
The object could be as simple as string space that the test code has to manage. For example:

Code: Select all


void updateMikroCstdoutPointer() {
    //Code to find the end of the data in mikroC.stdout
}

main() {
    unsigned short testValue, returnValue;
    unsigned int mikrocStdOutPointer = 0;
    char strData[20];

    testValue = 1;
    returnValue = lib_function(testValue);
    if (returnValue == 1) { //the right result
        strcpy(mikroc.stdout[mikrocStdOutPointer], "Test 1 Passed\n");
        updateMikroCstdoutPointer();
        
    } else {
        strcpy(mikroc.stdout[mikrocStdOutPointer], "Test 1 Failed line: returnValue (should be 1), was ");
        updateMikroCstdoutPointer();
        IntToStr(returnValue, strData);
        strcpy(mikroc.stdout[mikrocStdOutPointer], strData);
        updateMikroCstdoutPointer();
    }
Further ideas:
  • mikroc.stdin, mikroc.stdout - strings passed into the debugger when called and out of the debugger (when the sim is done)
  • mikroc.sim.pause, mikroc.sim.stop - control the debugger
  • mikroc.clock.current.cycles, .delta.cycles, .resetToZero, .MHz - access to the Watch Clock
    • This would enable powerful tests for time critical functions
  • mikroc.statistics - access to the function, variable and structure sizes
The bottom line is, creating even basic access to the simulator could enable very powerful test code.

LanceBeasley
Posts: 64
Joined: 01 Mar 2016 15:39

Re: Programatic access to software simulator

#2 Post by LanceBeasley » 15 Jun 2018 13:44

I will go one step further. I frequently find myself doing web searches for alternatives to mE's IDE. I have a large code base in mikroC, I like the compiler, and especially all the background work that mE does with registers, etc.

But the IDE continues to be really bad. And it is very, very clear that mE does not have any interest in fixing it, nor will it be fixed in the next 5 years. The fact is, mE doesn't want to be in the IDE business, and would gladly get out if they could. I would venture to say that the IDE issues aren't mentioned in developer meetings any more because everyone knows they won't be addressed. There are few if any stakeholders that see the IDE issues as being THAT BAD.

mE is a lot like a hole-in-the-wall restaurant where the curtains are 50 years old with 40-year-old stains, the industrial carpeting is so old and dirty it feels and acts more like tile, and the plates and cups are so chipped and worn that each one can be individually identified. BUT, the food so good we don't mind that the floor is sticky. In case my analogy is too obtuse, the compilers are very good, but the IDE/building is beginning to weird out the germaphobes/tabspacing-aphobes to the point they are willing to make the whole-sale jump to MPLAB.

As a follow-on to my last post, I have a suggestion. Modify the compiler and debugger so as to be compatible with an open-source IDE, or even the Jet Brains or Microsoft IDE.

Its a lateral shift with a very small downside, affecting those parts of mE's code base that is far more familiar to the developer team. Granted, adapting the debugger to a 3rd party IDE will take some work, but once the mE products are attached to an IDE maintained by programmers who are passionate about great IDEs, mE's sole responsibility in the future will be to stay compatible with their chosen external IDE- a far less difficult prospect.

Its possible to maintain compatibility with the existing IDE, but my guess is everyone will want to make the switch.

There is an ENORMOUS amount of pent-up goodwill waiting on this!!

Bonus tip: Hire just one NodeJS programmer with a lot of experience in automated testing, and task them with making the mE software compatible with the latest open source developer tools and frameworks.

User avatar
petar.suknjaja
mikroElektronika team
Posts: 683
Joined: 05 Mar 2018 09:44
Location: Belgrade

Re: Programatic access to software simulator

#3 Post by petar.suknjaja » 19 Jun 2018 08:35

Hi,

Thank you very much for your words.
We liked the inspirational video very much :D
I will forward your suggestions to our developers.

Kind regards,
Petar

LanceBeasley
Posts: 64
Joined: 01 Mar 2016 15:39

Re: Programatic access to software simulator

#4 Post by LanceBeasley » 04 Sep 2018 13:54

As you consider some sort of API to the debugger, also consider integration with CLION. I'd guess there are some issues with integrating such a tool, issues more related to business models than to technical hurdles. But none-the-less, I would be writing much better code with the integrated tools, especially considering the advanced static code analysis.

Thanks

Post Reply

Return to “mikroC PRO for dsPIC30/33 and PIC24 Wish List”