[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [avr-chat] AVR and accelerometers
From: |
Shashank Chintalagiri |
Subject: |
Re: [avr-chat] AVR and accelerometers |
Date: |
Sun, 18 Nov 2007 15:31:49 +0530 |
Would electrically isolating the SPI bus from the MCU during
programming be possible/help solve the problem? I was thinking a
tristate bus which is controlled by the reset pin of the SPI
programming interface should be able to do just that, although with
the addition of another IC on the board and on the bus lines, which
also means the IC would have to respond fast enough to the SPI data
signals when the SPI signals are going through it.
On Nov 18, 2007 7:18 AM, Michael Hennebry
<address@hidden> wrote:
> On Fri, 16 Nov 2007, Bob Paddock wrote:
>
> > Now with that stage set we have the entrance of Mr. Murphy.
> >
> > During the exchange between the programming software/hardware
> > communicating with the AVR to load its program, Mr. Murphy throws
> > in a some data bits on the MOSI (SDA/SDI/SDO) line, that are
> > properly clocked (SCL/SPC), from the perspective of the 302, so
> > that the 302 sees its own address.
> >
> > As a now properly selected 302, from the view of the 302, it is
> > obligated to generate an ACK on the SDA/SDI/SDO line.
>
> If one really wants, I think that there is a way around that:
> Find out what data bytes cause the problem and avoid them during ISP.
> Avoiding them and still getting them into
> flash would require writing some pages twice.
> Once for the odd 0s and once for the evens might do the trick.
> If it works, at most 8 passes will be necessary..
> If one can't do ~(1<<0), ... ~(1<<7) and the ISP command bytes,
> the problem is not solveable.
>
> I did write "really wants".
>
> > Remember the programming software is talking to the AVR using
> > this same line as MOSI. This ACK from the 302 does not belong on
> > the MOSI line at this time, creating contention on the MOSI
> > line. This causes the programming software to abort the transfer
> > because the AVR data was found to be corrupted during the
> > verification cycle (just as likely the verification cycle is what
> > is corrupted, but that you may be able to recover from).
>
> --
> Mike address@hidden
> "Horse guts never lie." -- Cherek Bear-Shoulders
>
>
>
>
> _______________________________________________
> AVR-chat mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/avr-chat
>
--
________________________________
Chintalagiri Shashank
Junior Undergraduate
Department of Physics
Indian Institute of Technology, Kanpur
address@hidden
address@hidden
http://home.iitk.ac.in/~chintal
________________________________
I don't believe in If anymore
If is for children
Building Daydreams
-Roger Whitaker
- [avr-chat] AVR and accelarometers, nautilussoftware, 2007/11/16
- Re: [avr-chat] AVR and accelarometers, David VanHorn, 2007/11/16
- Re: [avr-chat] AVR and accelarometers, Clemens Koller, 2007/11/16
- Re: [avr-chat] AVR and accelerometers, Bob Paddock, 2007/11/16
- Re: [avr-chat] AVR and accelerometers, Clemens Koller, 2007/11/17
- Re: [avr-chat] AVR and accelerometers, Michael Hennebry, 2007/11/17
- Re: [avr-chat] AVR and accelerometers,
Shashank Chintalagiri <=
- Re: [avr-chat] AVR and accelerometers, Bob Paddock, 2007/11/18
- Re: [avr-chat] AVR and accelerometers, Clemens Koller, 2007/11/18
- Re: [avr-chat] AVR and accelerometers, Graham Davies, 2007/11/18
- Re: [avr-chat] AVR and accelerometers, Bernard Fouché, 2007/11/19
- Re: [avr-chat] AVR and accelerometers, Clemens Koller, 2007/11/19
- Re: [avr-chat] AVR and accelerometers, Bob Paddock, 2007/11/19
- Re: [avr-chat] AVR and accelerometers, Bob Paddock, 2007/11/19
Message not available