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

Submitted by:  Volker <funker211>
Submitted on:  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>


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)

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.




    No changes have been made to this item

    Back to the top

    Powered by Savane 3.4