topic Code optimizer prohibits bit-banging?! in S12 / MagniV Microcontrollers

Code optimizer prohibits bit-banging?!

usdkurt — Thu, 22 Apr 2010 04:47:46 GMT

Hi, I'm having a problem where it appears that the CodeWarriror (4.6 btw) optimizer seems to be optimizing away my attempts to bit bang a sensor clock... here's what I've got.

In IO_Map.h we have this declaration for Port P:

/*** PTP - Port P I/O Register; 0x00000258 ***/
typedef union {
byte Byte;
struct {
    byte PTP0        :1;                                       /* Port P Bit 0 */
    byte PTP1        :1;                                       /* Port P Bit 1 */
    byte PTP2        :1;                                       /* Port P Bit 2 */
    byte PTP3        :1;                                       /* Port P Bit 3 */
    byte PTP4        :1;                                       /* Port P Bit 4 */
    byte PTP5        :1;                                       /* Port P Bit 5 */
    byte PTP6        :1;                                       /* Port P Bit 6 */
    byte PTP7        :1;                                       /* Port P Bit 7 */
} Bits;
} PTPSTR;
extern volatile PTPSTR _PTP @(REG_BASE + 0x00000258);
#define PTP                             _PTP.Byte

Then in my code I'm trying to do the following:

void ClearSensor(void) {
unsigned int i;

    // first, clock out NPIXELS pixels with SI low
    PTM &= ~0x10;     // set data input low
    PTP &= ~0x20;    // set clock low
    for (i= 0; i < NPIXELS; i++) {
        PTP |= 0x20;    // this statement executes
        PTP &= ~0x20;    // this statement does not execute
    }   // end for i

}    // end ClearSensor()

When I follow this code through the debugger the second statement in the for loop appears to never be executed. I don't see wiggling on the Port P number 5 pin, either. I was expecting the declaration of volatile on the PTP memory location would force the optimizer to always write to PTP regardless of other code nearby, but apparently I'm mistaken. Any ideas? I tried putting my bit set/reset statements in separate functions that are called in place of the in-line statements, but I still have the same problem.

Kurt

Re: Code optimizer prohibits bit-banging?!

bigmac — Thu, 22 Apr 2010 11:38:19 GMT

Hello Kurt,

What you seem to be implying is that PTP5 changes from zero to one, and stays at that state for the entire for loop sequence? If the code within the loop were being optimized away, I might expect that the output would remain at zero.

Perhaps see what occurs if you place some code between the two statements, maybe __asm nop;

You might also see what happens when using the bit field that is already set up.

_PTP.Bits.PTP5 = 1;

_PTP.Bits.PTP5 = 0;

Regards,

Mac

Re: Code optimizer prohibits bit-banging?!

kef — Thu, 22 Apr 2010 12:39:13 GMT

Kurt,

could you show disassemble of ClearSensor routine? If you modified some compiler settings, then also please provide compiler command line switches.

Isn't NPIXEL == 0?

Re: Code optimizer prohibits bit-banging?!

usdkurt — Fri, 23 Apr 2010 07:28:52 GMT

Hi Mac & Kef,

Thanks for responding... I may be getting fooled by what the debugger is showing me... I changed the bit setting actions to separate functions, and then what the debugger showed me when single-stepping in C was different than what it was showing me when single-stepping in the assembly. In C, the highlighting would just toggle back and forth between the bit set line and the for() line, while in assembly I could see it jumping around to various places that included both a bit set and bit clear (in assembly).

By the way, I had tried the bit fields approach, too, which gave the same appearance in C: jumping between bit set and for(). At that time I had not tried single stepping in assembly, so I don't know if it was just debugger weirdness.

In any case, now that I actually see it doing bit clears and bit sets in assembly I have to find out why it isn't coming out on the pin! That pin is shared with a couple of functions: SPI and PWM. Probably one of them is claiming the pin, and thus no port twiddling is getting through.

NPIXELS is #defined elsewhere.

Thanks for your suggestions, I will probably have a follow-up tomorrow saying "I found it!" Hope so, anyway.

Kurt