#116 Regression test support for PIC platforms


Add regression test support for PIC14 and PIC16
platforms, using the gpsim simulator.


  • Borut Ražem

    Borut Ražem - 2006-02-06
    • assigned_to: nobody --> borutr
  • Scott Dattalo

    Scott Dattalo - 2006-02-06

    Logged In: YES

    Hi Borut,

    gpsim and gpasm have several new features that will probably
    be useful for SDCC regression tests. You may be aware of
    these already, but here's a brief overview.

    It's possible to embed simulation commands into a .asm file
    and have gpsim execute them. (This feature works only for
    relocatable mode, btw.) Probably the most useful feature is
    a simulation assertion, but essentially *all* of gpsim's
    commands are available. gpsim's regression/ subdirectory in
    CVS provides several examples. In particular, check out the
    for testing logic modules. Here's an example where the lower
    3 bits of portb pass through several xor logic gates (that
    effectively form a 3-input XOR gate) and are read on portc
    bit 2:

    incf PORTB,F
    .assert "((portc>>2) & 1) == ( ((portb>>2) ^ (portb>>1) ^
    portb) & 1)"

    But in general, the gpasm .assert directive is turned into a
    gpsim break point that when encountered will halt the
    simulation if the expression evaluates false.


  • Borut Ražem

    Borut Ražem - 2006-02-06

    Logged In: YES

    Hello Scott,

    I know about .assert and .sim (actually .direct) features in
    gputils/gpsim. I already used them in pic14 regression tests
    (sdcc/src/regression) you originally wrote (it's easy to
    stand on the shoulders of giants :-).

    I also adapted the usart module so that characters sent to
    the serial port are written to the console, which is
    required by the current platform independent regression test
    framework (sdcc/support/regression). I intent to include the
    module to gpsim/extras.

    Thank you,

  • Borut Ražem

    Borut Ražem - 2006-08-07

    Logged In: YES

    Done for PIC16 quite some time ago.

    Still missing for PIC14: the main problem is that PIC14 port
    currently doesn't support printf() - actually funtons with
    variable arguments.


  • Nobody/Anonymous

    Logged In: NO

    Would variable arguments functions be needed except for printf?

    In support/regression/fwk/lib/testfwk.c only four different
    calls for printf are used, one of them being:

    __printf("--- FAIL: \"%s\" on %s at %s:%u\n", szMsg,
    szCond, szFile, line);

    If vaargs functions are not within reach, this could be
    worked around by using a combination of several
    _prints(const char *s) and _printn(int n) ?


  • Raphael Neider

    Raphael Neider - 2006-08-08

    Logged In: YES

    This might be a good idea: In the current argument passing
    scheme, the argument list is limited to less than 15 bytes.
    The call you just picked might already cross this limit (4
    generic pointers: 12 bytes, 1 int: 2 bytes, total: 14 bytes).

    Although I'd rather like to get varargs working (in the
    course of which the "address of 1. argument does not work"
    problem should be fixed as well), Frieder's proposal might
    serve well as a temporary workaround... if one wants to see
    all the errors the PIC port will generate ;-)


    PS: I will not touch testfwk.c for now, feel free to do so.

  • Borut Ražem

    Borut Ražem - 2006-08-08

    Logged In: YES

    I already have (better said I had it some time ago ;-) a
    testfwk.c which doesn't use the printf() or var. args
    functionality, but I don't see much sense to commit it:
    pic14 is still very immature so that many regtests will
    fail. And there is already a quite long list of pic14 bugs
    in the bug log, which have to be solved - some of them are
    already resulting from regression tests.

    On the other hand, we are claiming that SDCC is "ANSI - C
    compiler" and variable arguments are a part of the standard...

    I still believe that in this moment is better to fix the
    pic16 regression tests bugs for the next release and then
    concentrate on the pic14.


  • Scott Dattalo

    Scott Dattalo - 2006-08-08

    Logged In: YES


    I think you should commit your testfwk.c for the pic14 port.
    Maybe we can use this printf-less framework for the other
    ports too.

    In my opinion, the core of SDCC should provide the hooks
    required for the regression tests of the various ports and
    not the other way around. If there was a pragma mechanism
    that allowed the developers to instrument a regression test,
    then developers could begin to evaluate the port's integrity
    much sooner. Supporting an advanced feature like variable
    argument functions (which despite being part of the ANSI
    standard I'd never consider using in a PIC14 based
    application anyways) only hinders testing.


  • Borut Ražem

    Borut Ražem - 2006-08-08

    Logged In: YES

    OK, I found it.

    There is actually an other pic14 bug which prevents the
    current test suite to run: [ 1427663 ] SIGSEGV on static
    array of function pointers

    I already localy modified the generate-cases.py script to
    generate a sequence of function calls instead an array of
    function pointers. This change will affect all targets.

    With the __printf() removal we will loose the LOG()
    functionality, so that some regression test have to be


  • Maarten Brock

    Maarten Brock - 2006-08-08

    Logged In: YES

    Then define LOG empty for the ports that do not support
    it :-)

    Function pointers are another advanced feature IMHO.
    Most small devices don't even have a CALL (REGS)
    instruction and you need to use the PUSH REGS, RET


  • Borut Ražem

    Borut Ražem - 2006-08-14

    Logged In: YES

    Added regression test support for pic14.


  • Borut Ražem

    Borut Ražem - 2006-08-14
    • status: open --> closed

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks