AVR910 - Universal Programmer Improvement suggestion #1652

flyandancexo · 2024-02-01T15:07:07Z

flyandancexo
Feb 1, 2024

I have successfully tested my new programmer very loosely based on AVR910 on an Atiny13, atmega88, atmega16 and atmega128 with AVRdude V6.3 and AVRdude V7.2, and this covers page size from 32-256 byte; The screenshot is on an Atmega128 using V7.2 with a write speed of 129998/6.05=21487 and read speed of 129998/3.57=36414; It's still a working project, and so the final speed would be much faster. To actually create something great; it's very complicated that I have been spending more than 5 months working on it up to this point, and it's still not done yet.

======================================================
I can modify the source code for AVR910 easily, but I will let you do it, since I am not part of the team, but here I am providing some insights that I know that can make AVR910 great for the future.

devcode:
What the heck is devcode? Does anyone actually understand what it's? It's absolutely nothing I can tell you. First thing first, it should be removed or make optional. The absolutely key thing that is required to properly program a MCU correctly is simply the target MCU's page size because different MCU has different page size, to properly programming different MCU, this is critical and AVRdude shouldn't need to request this information from the programmer, but instead can get that from the -p option via AVR-part.

The command order is incorrect in AVEdude's AVR910 implementation: page size is requested before the target MCU is actually being selected, that means it's literally mission impossible for anyone to actually able to create a working programmer using AVR910. The point of the devcode is for the host to selected a supported MCU by sending back its picked code back to the programmer.

################################################################Incorrect Order
avrdude: send>>>>>>>>> : a [61]
avrdude: recv: ? [3f]
avrdude: send>>>>>>>>> : b [62]
avrdude: recv: Y [59]
avrdude: recv: . [00]
avrdude: recv: @ [40]
programmer supports buffered memory access with buffersize = 64 bytes
################################################################Incorrect Order

avrdude: send>>>>>>>>> : T [54] v [76]
avrdude: recv: . [0d]
avrdude: avr910_devcode selected: 0x76
################################################################Incorrect Order
avrdude: send>>>>>>>>> : P [50]
avrdude: recv: . [0d]

avrdude: AVR device initialized and ready to accept instructions
################################################################Incorrect Order

This is my magic of actually able to send back the correct requested page size. A lot of information can be extracted from the signatureBytes.

case SETpagesize:
  targetDecoder ( signatureBytes, &targetPageSize );
  serialWrite('Y');  // Send yes
  serialWrite( (uint8_t)(targetPageSize>>8) );   // Send high-byte first (This is a 0)
  serialWrite( (uint8_t)targetPageSize&0xff );   // Send low-byte of target PageSIZE
break;

Universal command:
It sounds useful, but beyond dumb. It's useless basically. Below is my code that works around this problem. Instead of using universal command, use those my suggested command codes to request various fuses back. It's simpler and easier.

//not supported in AVR910 - add them 
#define SENDlowFuse 'F'        //to send Low fuse (1 byte)
#define SENDhighFuse 'N'       //to send High fuse (1 byte)
#define SENDextFuse 'Q'        //to send Extended fuse (1 byte)
#define SENDcalibration 'C'    //to send all calibration bytes back, ends with 0;
#define SENDlock 'K'           //to send Lock fuse (1 byte)

#define WRITElowFuse 'f'        //to Write Low fuse (1 byte),  send okay back
#define WRITEighFuse 'n'        //to Write High fuse (1 byte),  send okay back
#define WRITEextFuse 'q'        //to Write Extended fuse (1 byte),  send okay back
#define WRITElock 'k'           //to Write Lock fuse (1 byte),  send okay back

// My work around
// to receive 4 Command bytes; Send 1 byte response and send okay back
case UNIcommandReceived:
  for( uint8_t i=0; i<4; i++ ){
    hostCOM[i] = SERIALread();
  }
   
{
//send low Fuse
if( hostCOM[0]==0x50 && hostCOM[1]==0x0 ){ serialWrite( SPI_readLow_fuse() );  }

//send high Fuse
else if( hostCOM[0]==0x58 && hostCOM[1]==0x08 ){ serialWrite( SPI_readHigh_fuse() );  }

//send ext Fuse
else if( hostCOM[0]==0x50 && hostCOM[1]==0x08 ){ serialWrite( SPI_readExtend_fuse() );  }

//send lock Fuse
else if( hostCOM[0]==0x58 && hostCOM[1]==0x00 ){ serialWrite( SPI_readLock_fuse() );  }

//receive low Fuse (write to Target MCU)
else if( hostCOM[0]==0xAC && hostCOM[1]==0xA0 ){ serialWrite( hostCOM[2] ); SPI_writeLow_fuse( hostCOM[3] ); }

//receive high Fuse (write to Target MCU)
else if( hostCOM[0]==0xAC && hostCOM[1]==0xA8 ){ serialWrite( hostCOM[2] ); SPI_writeHigh_fuse( hostCOM[3] ); }

//receive ext Fuse (write to Target MCU)
else if( hostCOM[0]==0xAC && hostCOM[1]==0xA4 ){ serialWrite( hostCOM[2] ); SPI_writeExtend_fuse( hostCOM[3] ); }

//receive lock Fuse (write to Target MCU)
else if( hostCOM[0]==0xAC && hostCOM[1]==0xE0 ){ serialWrite( hostCOM[2] ); SPI_writeLock_fuse( hostCOM[3] ); }

//Read Calibration Byte 0
else if( hostCOM[0]==0x38 && hostCOM[2]==0x00 ){ serialWrite( SPI_readCalibration(0) );  }
//Read Calibration Byte 1
else if( hostCOM[0]==0x38 && hostCOM[2]==0x01 ){ serialWrite( SPI_readCalibration(1) );  }
//Read Calibration Byte 2
else if( hostCOM[0]==0x38 && hostCOM[2]==0x02 ){ serialWrite( SPI_readCalibration(2) );  }
//Read Calibration Byte 3
else if( hostCOM[0]==0x38 && hostCOM[2]==0x03 ){ serialWrite( SPI_readCalibration(3) );  }
}
serialWrite('\r'); //send OK
break;

======================================================================
Correct order:
This is a log that I have saved and re-order to a correct and proper order. Order is important. For example, issuing a page write command before chip erase is incorrect. It's not possible to write to a page without it being erased first.

Programmer information are requested
Programming mode is entered 'P'
signatures bytes are requested 's'
T and t is requested and selected (this should be removed or made optional)
and etc.

################################################################
avrdude: send>>>>>>>>> : S [53]
avrdude: recv: F [46] D [44] x [78] I [49] C [43] S [53] P [50]
avrdude: send>>>>>>>>> : V [56]
avrdude: recv: 1 [31] 0 [30]
avrdude: send>>>>>>>>> : v [76]
avrdude: recv: F [46] D [44]
avrdude: send>>>>>>>>> : p [70]
avrdude: recv: S [53]
Programmer id    = FDxICSP; type = S
Software version = 1.0; Hardware version = F.D

################################################################
avrdude: send>>>>>>>>> : P [50]
avrdude: recv: . [0d]
################################################################
Reading |                                                    | 0% 0.00 s
avrdude: send>>>>>>>>> : s [73]
avrdude: recv: . [0f] . [93] . [1e]
################################################################
avrdude: send>>>>>>>>> : T [54] v [76]
avrdude: recv: . [0d]
avrdude: avr910_devcode selected: 0x76
################################################################
avrdude: send>>>>>>>>> : a [61]
avrdude: recv: ? [3f]
avrdude: send>>>>>>>>> : b [62]
avrdude: recv: Y [59]
avrdude: recv: . [00]
avrdude: recv: @ [40]
programmer supports buffered memory access with buffersize = 64 bytes
################################################################
avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.03 s
avrdude: device signature = 0x1e930f (probably m88p)
avrdude: Note: flash memory has been specified, an erase cycle will be performed
.
         To disable this feature, specify the -D option.
################################################################
avrdude: erasing chip
avrdude: send>>>>>>>>> : e [65]
avrdude: recv: . [0d]
################################################################

avrdude: processing -U flash:w:RDsmall.txt:r
avrdude: reading input file RDsmall.txt for flash
         with 20 bytes in 1 section within [0, 0x13]
         using 1 page and 44 pad bytes
avrdude: writing 20 bytes flash ...
################################################################
Writing |                                                    | 0% 0.00 s
avrdude: send>>>>>>>>> : A [41] . [00] . [00]
avrdude: recv: . [0d]
avrdude: send>>>>>>>>> : g [67] . [00] @ [40] F [46]
avrdude: recv: . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] .
[ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff
] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] .
 [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [f
f] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff]
. [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff]
avrdude: padding flash [0x0000, 0x003f]
################################################################
avrdude: send>>>>>>>>> : A [41] . [00] . [00]
avrdude: recv: . [0d]
avrdude: send>>>>>>>>> : B [42] . [00] @ [40] F [46] S [53] m [6d] a [61] l [6c] l [6c] :
[3a] = [3d] = [3d] = [3d] = [3d] = [3d] = [3d] = [3d] = [3d] = [3d] = [3d] = [3d
] = [3d] = [3d] D [44] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] .
 [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [f
f] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff]
. [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [
ff] . [ff]
avrdude: recv: . [0d]
Writing | ################################################## | 100% 0.05 s
avrdude: 20 bytes of flash written
avrdude: verifying flash memory against RDsmall.txt
avrdude: reading on-chip flash data ...
################################################################
Reading |                                                    | 0% 0.00 s
avrdude: send>>>>>>>>> : A [41] . [00] . [00]
avrdude: recv: . [0d]
avrdude: send>>>>>>>>> : g [67] . [00] @ [40] F [46]
avrdude: recv: S [53] m [6d] a [61] l [6c] l [6c] : [3a] = [3d] = [3d] = [3d] =
[3d] = [3d] = [3d] = [3d] = [3d] = [3d] = [3d] = [3d] = [3d] = [3d] D [44] . [ff
] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] .
 [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [f
f] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff]
. [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff]
Reading | ################################################## | 100% 0.02 s
################################################################
avrdude: verifying ...
avrdude: 20 bytes of flash verified
################################################################
avrdude: send>>>>>>>>> : L [4c]
avrdude: recv: . [0d]
################################################################

If the programmer didn't pass the 'P' stage, then it should terminate the programming event. Going forward at that point is meaningless. Send a 'L' command to terminate it.

Then signatures are checked with the provide -p option, and again terminates it if it's not matching.

Fuse can be checked after that or not, safe mode.

T and t option should be made optional or removed completely.

Page size is the 'b' command, this shouldn't be requested in the first place because page size can be extracted form AVR-part, but this can be read back as a confirmation. 1, if the answer is 'Y' and the page size is a valid size of 32-64-128-256, then this over-rides AVR-Part, and a warning message should be promoted. 2, If the answer is not 'Y', then use the page-size provide by AVR-part;

//Write and Read Commands
#define SETaddress 'A'   //to receive 2 bytes: Word-Address(High-byte 1st); then send ok back
#define SENDblock 'g'    //to receive 3 bytes: Block-size(High-byte 1st), Type(F/E); then send n-bytes back
#define RECEIVEblock 'B' //to receive 3 bytes: Block-size(High-byte 1st), Type(F/E); then read n-bytes, then send okay back

//Initialization Commands
#define SETpagesize 'b'        //to send 3 bytes: 'Y', pagesize(High-byte 1st) back
#define ERASEappSection 'e'    //to send Okay back when done
#define SENDsignatures 's'     //to send 3 Signature bytes back (third byte 1st)
#define SENDidentifier 'S'     //to send 7 Identifier bytes back
#define SENDsoftVersion 'V'    //to send 2 bytes back 0.0
#define SENDhardVersion 'v'    //to send 2 bytes back 0.0 (optional)
#define SENDprogrammerType 'p' //to send 'S' or 'P'
#define ENTERprogramMode 'P'   //to send okay back (first stage after programmer information)
#define LEAVEprogramMode 'L'   //to send okay back (last step)

//device code is useless, but a hack with -x devcode=0x88 means it can send one byte back (remove or make optional)
#define SENDdeviceCode 't'     //to Supported Device Codes 1-128, end with 0; 
#define SELECTdevice 'T'       //to receive 1 byte, ignored; send okay back

//Universal command
#define UNIcommandReceived '.' //to receive 4 Command bytes; Send 1 byte response and send okay back (remove or make optional)

//not supported in AVR910 - (add them, my proposed new codes)
#define SENDlowFuse 'F'        //to send Low fuse (1 byte)
#define SENDhighFuse 'N'       //to send High fuse (1 byte)
#define SENDextFuse 'Q'        //to send Extended fuse (1 byte)
#define SENDcalibration 'C'    //to send all calibration bytes back, ends with 0;
#define SENDlock 'K'           //to send Lock fuse (1 byte)

#define WRITElowFuse 'f'        //to Write Low fuse (1 byte),  send okay back
#define WRITEighFuse 'n'        //to Write High fuse (1 byte),  send okay back
#define WRITEextFuse 'q'        //to Write Extended fuse (1 byte),  send okay back
#define WRITElock 'k'           //to Write Lock fuse (1 byte),  send okay back

Block mode or page mode should be used under any circumstance, and so the 'a' can be made optional. There are more that can be changed, but to make it compatible with older version, a lot of the not required things should be made optional. For example, if 'S' option is made optional, older programmer should still work. It's just not responding with a 7-byte string, no problem at all, but if you were to increase the 'S' option string to 8 characters, then it would not work properly.

Last but not least, change the AVR910 description to New 2024 Updated Serial Programmer. The old description sounds very cheap.

mcuee · 2024-02-02T05:00:33Z

mcuee
Feb 2, 2024
Maintainer

@flyandancexo

Thanks for the enhancement idea.

I can modify the source code for AVR910 easily, but I will let you do it, since I am not part of the team, but here I am providing some insights that I know that can make AVR910 great for the future.

Why not publish the FW source code of your enhancement in your github repo? And then raise a PR to enhance avrdude to support your enhanced avr910 programmer. We may treat it as a new programmer and not touch the existing avr910, so you can actually use a new name which you like.

Without an open-source FW, I do not think avrdude project will want to support it, now that we have the support of many programmers (some may say too many).

7 replies

mcuee Feb 2, 2024
Maintainer

BTW, for sure "obliged" is the wrong word here. This is not how Open Source projects work. The avrdude maintainers here are very accommodating to the requests but still we are not "legally or morally bound" to fix the issue.

Dictionary
Definitions from Oxford Languages · Learn more
o·blige
/əˈblīj/
verb
past tense: obliged; past participle: obliged
make (someone) legally or morally bound to an action or course of action.

flyandancexo Feb 3, 2024
Author

In a justice society or cummunity, the people with the job title of whatever should do whatever the job title requires him or her to do. So a teacher's job is to teach, and a preacher's job is to preach. Whether you are paid or not, in an open or close cummunity.

So what is the job of a maintainer, to maintain, I think. If you don't want to do your job, don't volunteer to be one, so "obliged" is a correct word. Maybe not legally, but morally you should be, unless you are lacking on that department.

mcuee Feb 3, 2024
Maintainer

I will stop here.

flyandancexo Feb 3, 2024
Author

If you feel embarrassed, you should delete my post. That is the only way to cover up your embarrassment.

mcuee Feb 3, 2024
Maintainer

I am not embarrassed at all. But if you continue, I can block you.

mcuee · 2024-02-02T05:04:15Z

mcuee
Feb 2, 2024
Maintainer

Existing discussions on avr910.

0 replies

stefanrueger · 2024-02-02T11:17:41Z

stefanrueger
Feb 2, 2024
Maintainer

//device code is useless

Universal command:
It sounds useful, but beyond dumb. It's useless basically.

I am sure your protocol that is loosely based on the AVR910 protocol works for programming the four parts that you have tried it with. If, in your suggested modification, avrdude were to request the low fuse (your command F) how would the physical programmer know what ISP command bit pattern to send to the target AVR? There are some 10 different bit patterns for the 182+ AVR ISP parts to read the low fuse:

$ avrdude -p\*/At | grep -P "(\s|l)fuse.read.[01]" | cut -f3- | sort | uniq -c
      2 fuse	read	0101.0000--0000.0000--xxxx.xxxx--oooo.oooo
      1 fuse	read	0101.0000--xxxx.xxxx--xxxx.xxxx--oooo.oooo
      1 fuse	read	0101.0000--xxxx.xxxx--xxxx.xxxx--oooo.xxoo
      1 fuse	read	0101.0000--xxxx.xxxx--xxxx.xxxx--xoxo.oooo
      2 fuse	read	0101.0000--xxxx.xxxx--xxxx.xxxx--xxoo.oooo
      1 fuse	read	0101.0000--xxxx.xxxx--xxxx.xxxx--xxox.o1oo
      5 fuse	read	0101.1000--xxxx.xxxx--xxxx.xxxx--xxox.xxxo
     14 lfuse	read	0101.0000--0000.0000--0000.0000--oooo.oooo
    154 lfuse	read	0101.0000--0000.0000--xxxx.xxxx--oooo.oooo
      1 lfuse	read	0101.0000--0000.0000--xxxx.xxxx--ooxx.oooo

In the early days, different parts required different bit patterns and they had different mechanisms to read/write flash and or eeprom and different mechanisms to recognise when it was safe to communicate with the part again (different write delay timings among those). So, what you describe as beyond dumb and useless was, and still is, necessary to program these older parts. You may not care about these parts, but ATmel did and the AVRDUDE project does.

Your idea is not the first extension of the AVR910 protocol and certainly not the only one. Extending the AVRDUDE 910 protocol to your suggested one is out of question as it would rule out other extensions that might be more useful, eg, cater for flash in excess of 128 kB.

Can I suggest that once your work

On the firmware is finished, tested with a large set of parts and documented
A working hardware design is published under open-hardware so that it can be built by users
The firmware source is published as open-source (not just the hex file)

you are welcome to submit a PR for adding a -c programmer for this project to avrdude, which the team will consider merging if there is evidence that the programmer works, is used by a number of people and the quality of the code is tolerable.

0 replies

flyandancexo · 2024-02-03T02:09:05Z

flyandancexo
Feb 3, 2024
Author

//device code is useless

Universal command:
It sounds useful, but beyond dumb. It's useless basically.

I am sure your protocol that is loosely based on the AVR910 protocol works for programming the four parts that you have tried it with. If, in your suggested modification, avrdude were to request the low fuse (your command F) how would the physical programmer know what ISP command bit pattern to send to the target AVR? There are some 10 different bit patterns for the 182+ AVR ISP parts to read the low fuse:
$ avrdude -p\*/At | grep -P "(\s|l)fuse.read.[01]" | cut -f3- | sort | uniq -c
      2 fuse	read	0101.0000--0000.0000--xxxx.xxxx--oooo.oooo
      1 fuse	read	0101.0000--xxxx.xxxx--xxxx.xxxx--oooo.oooo
      1 fuse	read	0101.0000--xxxx.xxxx--xxxx.xxxx--oooo.xxoo
      1 fuse	read	0101.0000--xxxx.xxxx--xxxx.xxxx--xoxo.oooo
      2 fuse	read	0101.0000--xxxx.xxxx--xxxx.xxxx--xxoo.oooo
      1 fuse	read	0101.0000--xxxx.xxxx--xxxx.xxxx--xxox.o1oo
      5 fuse	read	0101.1000--xxxx.xxxx--xxxx.xxxx--xxox.xxxo
     14 lfuse	read	0101.0000--0000.0000--0000.0000--oooo.oooo
    154 lfuse	read	0101.0000--0000.0000--xxxx.xxxx--oooo.oooo
      1 lfuse	read	0101.0000--0000.0000--xxxx.xxxx--ooxx.oooo
In the early days, different parts required different bit patterns and they had different mechanisms to read/write flash and or eeprom and different mechanisms to recognise when it was safe to communicate with the part again (different write delay timings among those). So, what you describe as beyond dumb and useless was, and still is, necessary to program these older parts. You may not care about these parts, but ATmel did and the AVRDUDE project does.

Your idea is not the first extension of the AVR910 protocol and certainly not the only one. Extending the AVRDUDE 910 protocol to your suggested one is out of question as it would rule out other extensions that might be more useful, eg, cater for flash in excess of 128 kB.

Can I suggest that once your work

On the firmware is finished, tested with a large set of parts and documented

A working hardware design is published under open-hardware so that it can be built by users

The firmware source is published as open-source (not just the hex file)

you are welcome to submit a PR for adding a -c programmer for this project to avrdude, which the team will consider merging if there is evidence that the programmer works, is used by a number of people and the quality of the code is tolerable.

I can tell that you are the brighter kid among the AVRdude people, yet still you can see, but you can't think. The patterns are actually exactly the same. It's one pattern for all parts, not 10. For example the standard 4 command bytes to read back low byte is simply: 0x50,0,0,Output. The output has various x,x because for those MCUs, the bits on their low-byte are not available or greyed out, so they read back as 0 or empty; The 2nd and 3rd command byte with xxxx,xxxx and that means it doesn't care, it can be anything, so they can be 0,0; so it's just one pattern: 0x50,0,0,Out;

There are only 5 exceptions, with command starts with 0x58, so those 5 MCUs will not be supported. They are either super antique, or there is a bug on how they were entered, but if I really need to support them, I can just pay extra care to read their signature bytes first and supply them with the correct command. It's doable. There are always more solutions to a given problem.

Standard Low byte read  0101.0000--0000.0000--0000.0000--oooo.oooo (one command to rule them all)
      2 fuse	read	0101.0000--0000.0000--xxxx.xxxx--oooo.oooo
      1 fuse	read	0101.0000--xxxx.xxxx--xxxx.xxxx--oooo.oooo
      1 fuse	read	0101.0000--xxxx.xxxx--xxxx.xxxx--oooo.xxoo
      1 fuse	read	0101.0000--xxxx.xxxx--xxxx.xxxx--xoxo.oooo
      2 fuse	read	0101.0000--xxxx.xxxx--xxxx.xxxx--xxoo.oooo
      1 fuse	read	0101.0000--xxxx.xxxx--xxxx.xxxx--xxox.o1oo
      5 fuse	read	0101.1000--xxxx.xxxx--xxxx.xxxx--xxox.xxxo (exceptions)
     14 lfuse	read	0101.0000--0000.0000--0000.0000--oooo.oooo
    154 lfuse	read	0101.0000--0000.0000--xxxx.xxxx--oooo.oooo
      1 lfuse	read	0101.0000--0000.0000--xxxx.xxxx--ooxx.oooo

ATmel and the AVRDUDE project care about old parts, surely you do, very noble and very nice, but and this is a VERY big BUT, may I ask how many actual parts do AVRdude's AVR910 implementation support currently? With the dev-code bug or limitation, you can't really support more than 30 random parts. By definition, AVR910 can only support maximum 127 MCUs in series mode. Can AVRdude AVR910 support more than 128kB currently? the answer is also NO; It's very easy to support more than 128kB. Simply add additional command for the extended address.

In short, you refuse to update AVRdude AVR910 because you don't want it to support more parts, and you don't want to make it easier for other people to create working programmer with it, and that is okay with me. As I have mentioned clearly, it's all up to you if you want to maintain it or not, as a Maintainer.

PS:
"quality of the code is tolerable" If you really have doubt about my ability, here is a screen-shoot of my again very loosely based on AVR109 bootloader; 129998/3.60=36,110 or 36,1kB/s upload speed has been achieved. Have you actually seen a bootloader with that speed in your entire life? It's a rhetorical question. It can be even faster at 2Mbps, but you refuse to admit that there is a bug in AVRdude, so it's running at 1Mbps for now.

0 replies

stefanrueger · 2024-02-03T02:30:13Z

stefanrueger
Feb 3, 2024
Maintainer

The patterns are actually exactly the same. It's one pattern for all parts, not 10.

Well, no: you marked 5 parts as "exception" in your own analysis after mapping x to 0 and ignoring the last (output) byte.

Notwithstanding this, it is not AVRDUDE's place to argue whether a protocol is good, bad or ugly. The project facilitates programming with existing, popular and working programmers using published protocols.

Happy to continue the discussion once your idea gets to that place.

1 reply

flyandancexo Feb 3, 2024
Author

The output is from the targeted MCU. The programmer doesn't have any control of 4th byte, so issue 0x50, 0, 0, x done. If you are too dumb to see that. Just test it and see if the low-fuse actually read back fine. I sure 1000% it will.

This is exactly why I don't want to be any part of the so call open cummunity. Too many dummies with small balls and big ego, and that is exactly why nothing has been done for this for 20+ years.

mcuee · 2024-02-03T05:16:52Z

mcuee
Feb 3, 2024
Maintainer

I am locking this conversation.

@flyandancexo
You can start a new conversation if you want, but stick to technical contents.

0 replies

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

AVR910 - Universal Programmer Improvement suggestion #1652

{{title}}

Replies: 6 comments 8 replies

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

Select a reply

AVR910 - Universal Programmer Improvement suggestion #1652

flyandancexo Feb 1, 2024

Replies: 6 comments · 8 replies

mcuee Feb 2, 2024 Maintainer

mcuee Feb 2, 2024 Maintainer

flyandancexo Feb 3, 2024 Author

mcuee Feb 3, 2024 Maintainer

flyandancexo Feb 3, 2024 Author

mcuee Feb 3, 2024 Maintainer

mcuee Feb 2, 2024 Maintainer

stefanrueger Feb 2, 2024 Maintainer

flyandancexo Feb 3, 2024 Author

stefanrueger Feb 3, 2024 Maintainer

flyandancexo Feb 3, 2024 Author

mcuee Feb 3, 2024 Maintainer

flyandancexo
Feb 1, 2024

Replies: 6 comments 8 replies

mcuee
Feb 2, 2024
Maintainer

mcuee Feb 2, 2024
Maintainer

flyandancexo Feb 3, 2024
Author

mcuee Feb 3, 2024
Maintainer

flyandancexo Feb 3, 2024
Author

mcuee Feb 3, 2024
Maintainer

mcuee
Feb 2, 2024
Maintainer

stefanrueger
Feb 2, 2024
Maintainer

flyandancexo
Feb 3, 2024
Author

stefanrueger
Feb 3, 2024
Maintainer

flyandancexo Feb 3, 2024
Author

mcuee
Feb 3, 2024
Maintainer