ISP mystery question - why PDI/PDO

Go To Last Post
15 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

On the atmega64a I was playing with they have the serial pin mapping using SCK from the SPI, but instead of MOSI and MISO, they are using PDI/PDO which ends up being RXD0/RXD1.  It is a bit annoying because I want to use those for serial and get junk on my terminal every time I program.

 

Now I'm looking at a atmega640 and it does the same thing!  Any idea why they don't just use the SPI MOSI and MISO like they did on smaller megas?

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

alank2 wrote:
Any idea why they don't just use the SPI MOSI and MISO like they did on smaller megas?

Tribal memory.  For that configuration of models, the first Mega (Mega103 in the previous millennium) used those pins so the compatible models also do.  Have you noticed the M103C fuse, and it is enabled by default?

 

alank2 wrote:
get junk on my terminal every time I program.

Now, that is "interesting".  Usually a limiting resistor is used to allow both subsystems to work.  But the usual symptom is the serial driver chip overwhelming the ISP signals, not the opposite.

 

 

How often are you programming the chip such that something "on the terminal" is anything more than an annoyance?  Surely not even a situation in units 2 and 3 and ... n in the field?

 

Why did Chrysler have left-hand thread on left-side lug nuts?  Why didn't they listen when I told them not to do that?

Chrysler had a unique way of fastening wheels in the 1960s and 70s and it led to countless broken wheel studs and stripped lug nuts. The driver side had left-hand threads and the passenger side had right-hand threads, ultimately causing confusion when service was called for.

 

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

Last Edited: Thu. May 10, 2018 - 07:12 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

RX0/TX0 shared the same pins as PDI/PDO, so if you are using RX0/TX0 in the project, when you program, it can't help but to see the changes to PDI/PDO because of the programming process.  If you have a terminal connected to that port, you'll see that all show up as junk.  Not a problem with final use, but an annoyance for development.  The mega640 doesn't look look like it has the compatibility fuse, but it seems to do the same thing, perhaps because it is a descendant of the 64A?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

alank2 wrote:
Now I'm looking at a atmega640 and it does the same thing!
alank2 wrote:
The mega640 doesn't look look like it has the compatibility fuse, but it seems to do the same thing, perhaps because it is a descendant of the 64A?

Now, in that family, the 64-pin parts follow the Mega128.  But not the 100-pin parts like the Mega640.  So tell how it "SEEMS" to "DO" the same thing?

 

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

By the same thing I mean that the 640 uses the PDI/PDO instead of MISO/MOSI.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

alank2 wrote:
By the same thing I mean that the 640 uses the PDI/PDO instead of MISO/MOSI.

Huh?  Wouldn't that be constent, to use the same naming for the programming pins, regardless of the mapping?  And I thought your rail was against USART interference -- how can you be getting such interference if "does the same" is not using USART0 pins?

 

That said, the consistency indeed leaves something to be desired as Pin Configurations doesn't have PDI/PDO on both diagrams.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It would be consistent with doing it wrong!!!!!  Consistent would be putting MOSI with MOSI, MISO with MISO, SCK with SCK as most of the megas and tinys.  I just don't get why ISP which is so SPI like wouldn't use those pins!  Perhaps I am close minded to the AVR's "I grew up on".

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

But why are you ignoring the comments about Mega640 and your repeated claims that are not correct?

 

About your main premise, I'll have it fixed in the next release.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Forgive me theusch, apparently no matter how large you post it, I'm not getting it!!!!  The 640/1280/2560 DO use MISO/MOSI.  That is pleasing to me.

 

What are you going to fix in the next release?

Last Edited: Sat. May 12, 2018 - 03:32 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Most recent statement:

alank2 wrote:
The 640/1280/2560 DO use MISO/MOSI.

Prior statements:

alank2 wrote:
I'm looking at a atmega640 and it does the same thing!
alank2 wrote:
By the same thing I mean that the 640 uses the PDI/PDO instead of MISO/MOSI.

I'm out.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Go on.   It is pretty straightforward.   The TQFP-64 chips like m103, m64, m128, m1281, m2561 use PE0, PE1 i.e. share the UART pins.

 

The TQFP-100 chips m640, m1280, m2560 use the SPI pins.

 

Yes,   it would seem logical for them to all use SPI pins.    Hey-ho.   You just have to put up with what you have got.

 

For someone with experience in hardware programmers,   it seems a little odd to make a fuss.    You are not going to alter the design of mature / obsolete chips.

 

I have always suspected that features like "default M103C" are due to a single big customer (with an ignorant purchasing manager).

Thousands of customers have endured pain because one bloody minded M103 customer was not prepared to change fuses when the M128 was introduced.

 

David.

Last Edited: Sun. May 13, 2018 - 01:27 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

david.prentice wrote:
For someone with experience in hardware programmers,   it seems a little odd to make a fuss.    You are not going to alter the design of mature / obsolete chips.

 

I do agree that what are you going to do about it, not much, but I find it peculiar.  When ISP labels its pins MISO and MOSI, I always thought that the MISO and MOSI pins would be what they connect to.  It just doesn't make any sense that it uses SCK from the SPI interface and then RXD/TXD.  Aren't they entirely different systems internally?  I don't ever recall the drawings of the SPI and USART them showing interconnections between them.  Perhaps the programming system isn't really shown.  The only other 64 pin AVR I've dealt with was the atmega325 and it had ISP on the SPI port.  FWIW, using the USART pins isn't the best idea they ever had.  At least when it is on the SPI port, you can use pullups to keep any other SPI based devices from having issues during the programming process.  There is nothing you can do to stop a USART from receiving/transmitting junk if RXD0/TXD0 are used for programming.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

When ISP is happening the AVR is held in RESET so all the peripherals are disabled/tristated. I've always assumed ISP is its own separate peripheral (combinatorial state machine) and presumably the only thing active at the time. Maybe it is the case that in those chips that share ISP on the SPI pins that, to save silicon area, they are able to reuse part of SPI in some way?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The junk on serial port should be easy to avoid. Just use a simple tri-state driver to turn off signal to PC RX when AVR is held in reset.

/Jakob Selbing

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

[mysteriously] share the UART pins.

Don't forget that some chips have SPI support in the UART peripherals as well, and the internal hardware is pretty similar.  Hardware-wise, the serial port may make as much sense as the SPI port.