AVR 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: |
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
Carbon-Copy List
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
Powered by Savane 3.13-758e.
Corresponding source code
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.