bugAVR Downloader/UploaDEr - Bugs: bug #44170, Update/Rectify/Clarify...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #44170: Update/Rectify/Clarify Documentation

Submitter:  Volker <funker211>
Submitted:  Tue 03 Feb 2015 11:26:01 AM UTC
   
 
Category:  None Severity:  3 - Normal
Priority:  5 - Normal Item Group:  None
Status:  None Privacy:  Public
Assigned to:  None Originator Name:  funker211
Open/Closed:  Open Release:  None
Programmer hardware:  Device type: 

Tue 03 Feb 2015 11:26:01 AM UTC, original submission:  

In the AVRDUDE Documentation (http://www.nongnu.org/avrdude/user-manual/avrdude_1.html) it says in paragraph 6, sentence 4: "These all use the MPSSE mode, which has a specific pin mapping. Bit 1 (the lsb of the byte in the config file) is SCK. Bit 2 is MOSI, and Bit 3 is MISO. Bit 4 usually reset."

So, Bit number 1 would be SCK, Bit number 2 MOSI, and so forth.

Now, when I look into the "avrdude.conf.in" (the config file used to generate the default configuration file when building), for all "avrftdi" type programmers, SCK has bit 0 assigned, MOSI has bit 1 assigned, and so forth. This kind of numeration is the common one, and what a user normally expects. It maps ADBUS0 to ADBUS7 to bits 0 to 7.

This is in conflict with what the documentation says. In my view, the documentation should be updated and rectified (or clarified that bit 1 means "the first bit", which has <strong>BIT NUMBER</strong> 0).

Now, look at the point where "id = "UM232H";" is defined. It assigns sck = 1, mosi = 2, miso = 3 and reset  = 4, so it uses the bit numbers of the documentation, not a zero-based numbering. Yet, when I look at the cited web page for this programmer, the hardware assignment is SCK = ADBUS0, MOSI = ADBUS1, MISO = ADBUS2 and RST = ADBUS3. Again, here is a zero-based numbering and the assignment (as I think) is wrong!

I assume that the definition of all "avrftdi" type programmers is correct and indeed, a zero-based numbering is required here as well. In this case, the documentation is wrong (or not precise) or the definition of the "UM2232H" is wrong. Did no one test this?

This is documentation issue 1 of 2 I came across. I will post issue 2 in another thread, in order to not mix them.

Volker <funker211>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by funker211 (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    No changes have been made to this item

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code