??? 07/26/05 17:27 Read: times |
#98186 - True but... Responding to: ???'s previous message |
Jan Waclawek said:
And don't forget, the UART-ISP DOES involve extra circuitry - that one which is used for the ISP invocation; and indeed it has become a major issue for UART-ISP (see the "lost bootvector" case, whatever is the cause of "loss", the result is a defunct chip (*)). I personally like the way TI does it--you pull down PSEN while resetting the IC and it comes up in ISP mode. I'm not sure if there's any way to "lose" that capability. I've seen people mention lost bootvectors but I've never really paid much attention to what causes it or what process those MCUs use to enter ISP in the first place. Craig, you are speaking from the viewpoint of the user, whereas I am speaking from the viewpoint of the manufacturer. From this point of view, the SPI-ISP is simpler and safer in many respects. Of course, the manufacturers standpoint is (or should be), that the user should use a proper programmer, as he would use for parallel programming (here comes the kitchenware-problem). But the reality is that the end-user isn't always going to use a "proper programmer" because, unlike a parallel programmer where you pop an IC into the programmer, ISP is in-circuit. Atmel's "official" cable consists of a 10-pin IDC header and I don't think everyone is going to want to install a 10-pin IDC header on their boards--especially when you really only need 4 or 5 pins to achieve their ISP. I can see myself putting a 4 or 5-pin SIP header on a board very easily whereas a 10-pin IDC is going to cost more and take up more board real estate. So the reality, I think, is that if you have something that is to be programmed in-system and the "system" (the end-user's design) is going to be different for every user, it's unlikely that a single cable is going to be acceptable to all those designs. And if the users are going to want to use different cables anyway, then this comes back to the manufacturer--they're going to have a lot less support calls if it's a simple UART-based ISP than if it's some strange SPI-based protocol that is only available officially for their special cable and which is not all that well documented for those that can't use that cable. Oh yes, that's a good point. Rather, it ought to be debugged. Search the fora worldwide; you will find at least as many complaints on UART-ISP as on SPI-ISP. And, obviously, they are NOT caused by improper "cable"... so what, then? I can only speak for what I see in this forum since I don't frequent other related forums--but I see time and time again people asking how to do Atmel ISP; I was one of them less than a year ago. I don't recall seeing anyone asking how to do TI or Dallas ISP. Now I guess that could also be a result of the fact that Atmel is more commonly used in student applications, etc. but in theory the UART approach should be pretty straight-forward. Now I agree that if the manufacturer doesn't properly debug their UART-based ISP, then the end-user is toast. The same question could be asked "What if the ADD A,idata" instruction doesn't work? There has to be some quality control at the manufacturer side. But I think it's a lot easier for the manufacturer to control quality and make sure their UART-based ISP works properly than to assume that thousands of developers world-wide are going to be build quality cables. Personally, I wish all the manufacturers would agree on a single process for getting into UART-based ISP mode so that we could use a single cable and a single program to easily ISP the MCUs from any manufacturuer. Of course, that's probably precisely the reason they don't do it. The last thing they probably want is us not being locked in to their offerings. :) Regards, Craig Steiner |