PORT32 outputs

[AudioBoy]

Hi All.

I have 2 functions:

Code: Select all

// Port 32A helpers
#define PORT32A_PEEK(X) {asm("peek %0, res[%1]":"=r"(X):"r"(XS1_PORT_32A));}
#define PORT32A_OUT(X)  {asm("out res[%0], %1"::"r"(XS1_PORT_32A),"r"(X));}

static void OutF0(unsigned s){
 unsigned tmp;
     PORT32A_PEEK(tmp);
     if(s) tmp |= 0x08; else tmp &= (~0x08);
     PORT32A_OUT(tmp);
 }
//
static void OutF1(unsigned s){
 unsigned tmp;
     PORT32A_PEEK(tmp);
     if(s) tmp |= 0x10; else tmp &= (~0x10);
     PORT32A_OUT(tmp);
 }

when I call these 2 functions one after another:

Code: Select all

  OutF0(a);
  OutF1(b)

I saw than the 1st function does nor works (I do not see the signal with the oscilloscope).
But, when I put a small delay between the calls - it starts to work!

Code: Select all

  OutF0(a);
  t :> time; time += 20; t when timerafter(time) :> int _; // 200ns delay
  OutF1(b)

So, the questions are:
- why it happened?
- is this solution with timer is good, or there is(are) another, more preferable solution(s)?

[richard]

So, the questions are:
- why it happened?

When you output on a port, the output value is queued to be driven at the next falling edge of the clock. On the other hand a peek instruction returns the current value on the pins. If there is no falling edge between the out and the subsequent peek then the peek won't see the new output value.

Adding sufficient delay between the output instruction and the peek instruction should prevent the problem you are seeing. Instead of using a timer it might be neater to use a syncr instruction on the port. The syncr instruction pauses until the port has completed any pending outputs.

- is this solution with timer is good, or there is(are) another, more preferable solution(s)?

Another solution might be to maintain an output_value variable which you store to every time you output on the port - this way you always know the current output value without having to peak.

[AudioBoy]

Thank you, Richard, I understood.

[AudioBoy]

Another question - I play with the Audio Reference Design, ad got this result:

Code: Select all

Constraint check for "tile[0]" (node "0", tile 0):
  Cores available:            6,   used:          5 .  OKAY
  Timers available:          10,   used:          8 .  OKAY
  Chanends available:        32,   used:         16 .  OKAY
  Memory available:       65536,   used:      36944 .  OKAY
    (Stack: 2580, Code: 23036, Data: 11328)

Then I wrote my function in the audiohw.xc, and use the timer as global variable:

Code: Select all

timer MyTmr;
unsigned MyTime;
unsigned MyFlag;

void MyFunction(unsigned d){
    MyTmr :> MyTime;
    MyTime += d;
    MyFlag=1;  
}

But at the results, this line does not changed: Timers available: 10, used: 8 . OKAY
Why the number of used timers is the same after I added another one?

[infiniteimprobability]

But at the results, this line does not changed: Timers available: 10, used: 8 . OKAY
Why the number of used timers is the same after I added another one?

From tools version 13, timers are automatically re-used by the compiler. This effectively gives you unlimited timers per logical core, with the tradeoff of a small amount of setup code to work out the next timer event, in the case of say selecting on multiple timers. You won't get slip, but may get some small amount of jitter from this.

This is why you will see one timer used per logical core, even if you are not using it.

You see two extra timers used because XUD allocates two additional ones.

You can access dedicated hardware timers using hwtimer_t in hwtimer.h, if you have some extremely time critical code.

[AudioBoy]

Thank you, not its clear.