LeafLabs Garden

A place to share, learn, and grow...

1. 

   jpopadic
   Member

   Hi all. I have a bit of a puzzle for you all.

   The hardware background, in brief, is a 16x16 LED matrix with common anode columns sourced by mosfets controlled by individual IO pins. The rows are sunk by constant current output shift registers. The code below is part of a timer interrupt handler.

   I am seeing strange behaviour from the IO pins controlling the column drivers. In the code below, column n-1 is being driven high a few instructions before column n is driven low. For some unknown reason, the behaviour of the actual pins has the transition of column n-1 delayed significantly - it looks like what I'd expect if the digitalWrite instruction for "lastColumn" were at the end of the block.

   Got any ideas? I'm stumped.

   // Blank row
     digitalWrite(OE, HIGH); // (active low)
   
     // Send row data via SPI
     const int bitplaneOffset = gBitplane * BITPLANE_SIZE;
     const int columnOffset   = gColumn * 2;
     // Red first
     spi.write(pFrontBuffer[bitplaneOffset + columnOffset + 1]);
     spi.write(pFrontBuffer[bitplaneOffset + columnOffset]);
     // Then green
     spi.write(pFrontBuffer[HALFPLANE_SIZE + bitplaneOffset + columnOffset + 1]);
     spi.write(pFrontBuffer[HALFPLANE_SIZE + bitplaneOffset + columnOffset]);
     // Wait for data to arrive.
     NOP
     NOP
     NOP
     NOP
   
     // Extinguish last column driver
     int lastColumn = gColumn - 1;
     if(lastColumn < 0)
       lastColumn = Constants::FrameWidth-1;
     digitalWrite(colPins[lastColumn], HIGH); // (active low) <-------- write here...
   
     // Latch row data
     digitalWrite(LE, HIGH);
     digitalWrite(LE, LOW);
   
     // Light the current column
     digitalWrite(colPins[gColumn], LOW); // (active low)
   
     // Re-enable row drivers
     digitalWrite(OE, LOW);  // (active low)
   
                                                               <-------- pin changes here

   Posted 2 years ago #
2. 

   gbulmer
   Moderator

   jpopadic - How do you know that the behaviour described is happening? Do you have an oscilloscope or something?

   Could the effect be some other cause?
   For example, the spi.write might not complete until after several digitalWrites, which may cause very weird behaviour, maybe even latching an incomplete pattern into the shift registers.

   If you change the sequence of NOPs to delay(1), and put a delay(1) in front of
   

   // Latch row data
   digitalWrite(LE, HIGH);
   digitalWrite(LE, LOW);

   does it change the behaviour?
   That might indicate a 'race condition', where the spi write is taking too long.

   I can't see the arithmetic for gColumn, we need to see that to understand how it all works.

   Have you tried a simpler test? For example, load the shift registers once, and then only change the column drive. Does the problem show up when spi.write isn't being used?

   Posted 2 years ago #
3. 

   jpopadic
   Member

   Hi gbulmer,

   Thanks for the reply.

   I'm using a logic analyzer to investigate the behaviour of the pins.

   I stripped the problem down to the simplest I could and still see the issue. I may have an explanation for what's going wrong and it doesn't appear to be related to the MCU:

   I'm driving my columns using open-drain outputs and pull-up resistors so MOSFETs sourcing a (~1 volt) higher voltage will switch properly). Stray capacitance (I'm measuring around 400pF) and the relatively high value of the pull-ups (10k) should be able to introduce a delay in the neighborhood of a couple of microseconds.

   It looks like I either need to account for the delay by shuffling some code around or decrease the value of my pull-ups.

   Thanks for your time! Sorry it was a red herring.

   Posted 2 years ago #

RSS feed for this topic

Reply

You must log in to post.