> In the older programming algorithm (e.g. in the ATmega128), polling > had to be done differently, by reading back a particular value. This > is basically implemented in avr_write_byte_default(), at line 599ff. As I understand the ATmega128 datasheet, you can read back any value (which differs from 0xff) within the programmed page to check if this page has been programmed. This is what avrftdi currently does for every AVR part. Did you just mix up devices or did you mean "any value within the page to be programmed" when you said "particular value" (in contrast of reading back the boolean value of RDY/#BSY instruction)? > > >> At least for parts, who have this instruction, the timing issues >> could be resolved rather elegantly. > > The config file has to be extended in order to describe which devices > do support the new-style polling. What happens if an AVR gets a command, which it does not know? My (rather hackish) idea would be to issue the command and see what happens. This, of course, works only, if the device signals, that it does not know the command. Do you know if Atmel plans to implement this command in future devices? Because if not, I would re-evaluate the effort to implement this. > > Ideally, I'd like to get rid of all the ISP instructions in the config > file. After all, they are basically the same for every AVR > (STK500/600 are also based on that fact). Alas, it's a tremendous > amount of work to change this. Additionally, the options to the command byte could be deduced from chip memory size, page size/number of pages and bytes per word. This reminds me of another issue: Are there always 2 bytes per word in AVR devices? Code often divides addresses by two or shifts addresses by one (converting byte-addresses to word-addresses). If the number of bytes per word is fixed I'd rather see a macro performing the shift/division or a #define to reduce magic numbers - at least in avrftdi. If the number of bytes per word is not fixed to two, I would suggest a member in the AVRMEM structure. I suppose this would also require the config file changes.
However, polling works fine in avrftdi for now. I tend to stick with it but I would be open to implement RDY/#BSY if, for example, the ISP instructions would be merged out the config file. After all, the RDY/#BSY instruction would not yield an immediate benefit (in speed), apart from a little bit cleaner code. Because avrdude only programs non-0xff pages, it is also guaranteed that a value suitable for polling exists in every programmed page. Best regards, Hannes _______________________________________________ avrdude-dev mailing list avrdude-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avrdude-dev
