Yahoo Groups archive

AVR-Chat

Index last updated: 2026-04-28 22:41 UTC

Message

Re: Problem reading PIND.0 on Mega16 with 16MHz Crystal

2006-02-06 by kernels_nz

Hi Ivan -- MORE INFORMATION !

Nope, using PIND.0 as general input, in fact, the plan is to use
PIND.0 as general input to detect the start condition on a DMX512
packet and then change it to to UART RX to receive the individual
packets after that.

What I have done so far is look for the start condition (PIND.0 low
for more than 80us) and just toggle one of the outputs everytime it
receives a start condition. Doing this on PIND.0 is very erratic!
changing the code only in such a way that I check any other pin, it
works perfectly.

Another thing worth mentioning . . . I have noticed that PIND.0 is
also starting to load my input signal for no apparent reason after a
while of operation. The input signal is buffered, output swing is GND
to 5V. After a while of running with this signal connected to PIND.0,
the output swing measured with my scope droops to GND to approx 2.5V

Im starting to think more and more that the input signal is affecting
the crystal clocking somehow, will try again tonite, and seperate them
 as far as possible and also check the fuses etc. as some of the other
guys suggested.

Thanks
Hein B
Auckland, New Zealand.

--- In AVR-Chat@yahoogroups.com, "Ivan Vernot" <ivernot@...> wrote:
>
> Hien,
> Just a thought.... PIND.0 is shared with RXD on a mega16 - you don't
have 
> the UART enabled while you are trying to read PIND.0? ;-)
> 
> HTH
> Ivan Vernot
> 
> 
> ----- Original Message ----- 
> From: "kernels_nz" <hein@...>
> To: <AVR-Chat@yahoogroups.com>
> Sent: Tuesday, February 07, 2006 8:19 AM
> Subject: [AVR-Chat] Re: Problem reading PIND.0 on Mega16 with 16MHz
Crystal
> 
> 
> > Hi Guys, Thanks for all the suggestions, will check the fuses tonight
> > when I get home, I think the suggestion that the input is actually
> > affecting the crystal instead of the other way round sounds very
valid.
> >
> > Im only checking PIND.0 as general input, and im reasonably
> > experienced with AVR's , so dont believe it's a simple code problem.
> > As I said, using PIND.0 = dont work, any other one of the PIND pins
> > works fine.
> >
> > THANKS AGAIN ! GREAT SUGGESTIONS FROM EVERYONE !
> >
> > Cheers
> > Hein B
> > Auckland, New Zealand.
> >
> > --- In AVR-Chat@yahoogroups.com, "Dave VanHorn" <dvh@> wrote:
> >>
> >> > Could noise from the crystal pin be coupling to the data input
> >> > and corrupting the data stream somehow ? could this be happening
> >> > inside the Mega16 ? If so it is unfortunate that Atmel have
placed the
> >> >  RXD pin of the UART right next to the crystal pins.
> >>
> >> Far more likely that your input signal is disturbing the crystal.
> >> If you haven't programmed the CKOPT fuse, then do so.
> >>
> >> After that, see my other post on checking the oscillator design.
> >>
> >> There are also possible layout issues, involving how the crystal caps
> >> return to the AVR's ground pin. They should do so on an isolated
track
> >> that connects to system ground only at the AVR pin.
> >>
> >> > Unfortunately I really do need to use a 16MHz crystal also, so
merely
> >> > ignoring the problem and using a slower oscillator will not work !
> >>
> >> On a more mundane note, this may be a code problem, can you
detail how
> >> it is that you're checking the pin?
> >>
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
> >
> >
> >
>

Attachments

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.