[SOLVED-ish] Propeller C: behavior discrepancy between CMM and LMM modes using hardware counters?

roblgroblg Posts: 2
edited 2020-01-02 - 05:16:51 in Propeller 1
Update: I continued stripping things out and I think I've narrowed it down to the compiler optimizations that were originally in the Makefile I'm using to compile Simple-Libraries (which I borrowed from some github repository) so that's on me, as I suspected it might be.

For funsies, I also verified that stripping out everything and starting from propeller.h + copying the three functions used (low(), get_state(), pause()) results in the expected (identical) behavior between LMM and CMM memory modes.

Onward! And, as they say: it's never a bug in the compiler ;)


Hey all,

I've got an Activity Board WX (Rev A, Prop v1) that I've been playing with off and on for several years. I'm building Propeller C using PropellerGCC on Linux.

I'm seeing discrepancies in behavior between code compiled using the CMM and LMM memory models, and I'm sort of at a loss for direction on how to proceed. My intent is just to use the Propeller counter hardware to make one of the on-board LEDs pulse at 1s intervals. This setup is based on code in the servo360 library from "Simple Libraries", which I've been having trouble getting to work consistently.

The repro code is really minimal:
#include "simpletools.h"

void test_pulse(int pin) {
  low(pin);

  PHSB = 0;
  FRQB = 0;
  // CTRMODE = NCO (Numerically controlled oscillator) -- single-ended
  CTRB = (4 << 26) | pin;
  FRQB = 1;
  PHSB = -(CLKFREQ); // count up by clock ticks for 1s

  //print("%d, %d\n", (INA & (1<<pin)), (OUTA & (1<<pin)));

  // block until pin goes low again
  while (get_state(pin)) {};

  CTRB = 0;
  PHSB = 0;
  FRQB = 0;
}

int main()
{
  print("Starting\n");
  while (1) {
    test_pulse(26);
    pause(1000);
  }

}

I'm compiling it with a script that essentially boils down to:
mem=${mem:-"cmm"}

propeller-elf-gcc \
    -o "$OUTPATH/myrobot.elf" \
    -m32bit-doubles \
    "-I${LIBPATH}/include" \
    "$SOURCE" \
    "-L${LIBPATH}/lib" \
    "-m$mem" \
    "-lsimple-$mem"

Using LMM, the P26 LED turns on, stays on for 1s, turns off for 1s, and repeats (hooray! the behavior that I expect)

Using CMM, the P26 LED turns on very briefly (not even full brightness).This makes me think
get_state(pin)
isn't behaving the same way, or there's a timing issue in CMM that's not there in LMM? I'm also totally open to the idea that I might have something obvious/trivially wrong in my setup since getting set up on Linux in the first place was quite the adventure.

I'd appreciate any thoughts folks might have, or references to read that might be handy (I've been piecing things together as I find them, but my day job doesn't involve working with microcontrollers, so I've got all sorts of strange knowledge gaps that I'm trying to fill as fast as I find them :) ).

Thanks!

Robert

Comments

  • If you're on Linux and at the level of writing your own scripts for compilation, you may appreciate PropWare. See my signature for details. At very least, you may appreciate the "Default Compile Flags" section of this page: https://david.zemon.name/PropWare/#/reference/cmake-reference
  • @DavidZemon -- thanks for the tip! The C compiler flags listed look comparable to what I'm using, but that at least gives me some confidence that I'm not missing something obvious. (For context, I started from https://github.com/dbetz/propeller-gcc/blob/master/simple-libraries/Makefile#L45-L47 to build Simple-Libraries).

    I'm actually now leaning more towards something happening at link-time (though I barely know what I'm talking about). The disassembly of get_state looks identical when compiled as a library with `-Os` and when compiled into my main.c, but the library version exhibits the weird behavior (it appears to return almost immediately).

    In any event, I'm having fun poking at this for the moment. I haven't gotten to do my actual propeller programming, but I've certainly been learning a lot. :)
Sign In or Register to comment.