Im stuck with a simple symptom and not able to find the problem. my design latches port C and B to a 74ls374 latch, Im using one PORTB output as control line to "latch" the data that is on PORT C and B at the time. The problem is that the circuit was working fine, until I realize that if I took the control line from PIN 1 (PORTB), and connected this wire to PIN 2 ( PORTB) , it continues working fine and the same happens if I connected this wire to PIN 3.

I have tested everything that was on my mind, this is why Im asking for some new ideas. I can send the code and schematics if you tell my how. My design is very basic because I need this to be working perfect before going forward with my project.

Help is appreciated.

Hi gnkarn,

Are PB2 and PB3 set as outputs?

Have you tried connecting the clock line of the '374 latch directly to ground? Do the latch outputs continue to follow the latch inputs?

Mike

Yes PB2 and PB3 are set as outputs for future use Yes, if you maintain the 374 clock to ground the outputs stays with no change, if you alternate the pin to +5 and 0v, once you connect it to zero it latches the new state .

The problem is that it does the same when I connect it to the other two pins, it would be good to have an oscilloscope at this moment ...

thanks Gustavo

Hi Gustavo,

I looked at the code you sent me and it appears that you are actively driving pin PB2 to be the same as PB1. PB3 seems to be in another category altogether, but I think you are basically "off by one" in your use of the registers. Take a look at my e-mail and let me know if that fixes things!

Mike

Mike, It seams that I sent an old version of the code ( i did millions during debugging), but the actual version of the code is right, Im driving only PIN1 and keeping PIN2 and 3 in zero. So mystery continues ..

Gustavo

Hi Gustavo,

Could you post your code here: http://nerdkits.pastebin.com/ as well as posting the image of your schematic? I'd like to let the other forum members take a look in case I'm missing something!

The other thing I'd highly recommend doing is making a super-simple test version of your code -- no interrupts, no program memory reading, etc. Try to reduce your code to the simplest possible case and see if the problem persists or not. That should lead you to where the problem might be.

Mike

I have posted the reduced code ( no interrupts, no LCD) just plain 8 LEDS connected to the latch where 6 bits are in portC and the Two MSB are in port B.

http://nerdkits.pastebin.com/m391c60ec

the kit does exactly the same thing when I connect the latch control pint to portB pins 1 2 0r 3, ( IC pins 15,16,17), even when only PIN1 hs a 0 to 1 to 0 signal, the others remains always in zero.

I dont know how to post the schematics on the pastebin ..

Gustavo

Hi gnkarn,

How about a super-minimal test like this:

#include <avr/io.h>
#include "libnerdkits/delay.h"

int main() {
  DDRB = 0xFE;
  while(1) {
    // setup data
    PORTB = 0xF0;
    delay_us(10);
    // make latch #0 transparent
    PORTB = 0xF2;
    delay_us(10);
    // latch it
    PORTB = 0xF0;

    // sleep for about a second
    delay_ms(1000);

    // setup data
    PORTB = 0x00;
    delay_us(10);
    // make latch #0 transparent
    PORTB = 0x02;
    delay_us(10);
    // latch it
    PORTB = 0xF0;

    // sleep for about a second
    delay_ms(1000);
  }
}

If you connect the clock pin of your '374 to PB1, then your four outputs (coming from PB4-PB7) should toggle on/off every second. Does that happen?

But if you instead connect the clock pin of the '374 to PB2, then the outputs should not toggle. (Whether they are stuck high or low is irrelevant since we don't really know the start-up state of the latch -- but they should not be switching at all.)

Mike

Mike, Thanks again The minitest is working fine, the three control lines ( i have tested one at a time) works perfect. Now the question is why is not doing the same on the original code?, I will recheck the code again , and see if I can find the cause.

Gustavo

Hi Gustavo,

OK, glad to hear it worked -- I think we're on to something! Can you check whether the delay_us(10) calls make any difference? Try reducing the 10 to 1 and see if it breaks... or removing the delay_us calls completely. That's about the only difference I can see at the moment between this code and your earlier one.

Mike