Skip to content

Commit fe065c2

Browse files
SpenceKondeSpenceKonde
committed
Quick fixes to this.
1 parent 9e648d9 commit fe065c2

4 files changed

Lines changed: 69 additions & 39 deletions

File tree

‎megaavr/extras/DU14.md‎

Lines changed: 19 additions & 17 deletions
Original file line numberDiff line numberDiff line change
@@ -1,14 +1,16 @@
1-
# AVR DU - That's U for USB
2-
They're here, or nearly so. Support for them is pending.
3-
4-
These are one of those parts that leave you very little ambiguity about whether it's the right part for the job. Do you need USB? Then you need to DU the DU, cause as far as AVR is concerned, it's this, or classic AVR, and nobody wants to use those. And the DU-family of parts is absolutely a respectable product line. But the fact remains, that if you don't need USB, there is something cheaper, better at what you do need, or in most cases, both better and cheaper. USB exacts a very heavy price - but it obviously allows functionality that is otherwise entirely impossible, that of directly interacting with personal computers, so you will be able to:
1+
# AVR32DU14/AVR16DU14 AVR DU - That's U for USB
2+
These are one of those parts that leave you very little ambiguity about whether it's the right part for the job. Do you need USB? Then you need to DU the DU, cause as far as AVR is concerned, it's this, or classic AVR, and nobody wants to use those. And the DU-family of parts is absolutely a respectable product line. But the fact remains, that if you don't need USB, there is something cheaper, better at what you do need, usually both. USB exacts a very heavy price - but it obviously allows functionality that is otherwise entirely impossible, that of directly interacting with personal computers, so you will be able to:
53
* Spoof Keyboards and Mice
64
* Act as a virtual USB serial port
75
* Make a USB DMX device
86
* Program over USB pending availability of a bootloader suitable for such
97
* For the true wizards, the option to make an entirely custom USB device awaits you.
108

11-
This great power, however, comes at a terrible cost, for the other peripherals have met the Native USB. The Natives are not friendlyWhat's sort of astonishing is just how much these parts sacrifice for native USB: They lose the TCD. They lose 2 pins The 14-pin parts are particularly starved for pins: They have only 7 pins available without using reset or UPDI for I/O. MVIO was taken our of user hands and put towards shifting the levels of the USB signals it would appear. With the constrained pincount, that most peripherals have only one pinset should come as no surprise. But native USB does have a transformative effect on the parts.
9+
Currently, there is no support for the USB available as part of the core yet, that is the top priority new feature, but one which I feel totally unqualified to write.
10+
11+
**Until there is is at least one library available with some sort of USB functionality, the only reasonable thing to do with this core and a DU microcontroller is to develop such a library.**
12+
Once that has been done, it will open scores of new use cases.
13+
1214

1315
## Pin Mapping / Pinout
1416
`[DU14 Pin Mapping](DU14.png "Arduino Pin Mapping for AVR DU14")`
@@ -63,7 +65,7 @@ Standard Dx-series I/O pins with INLVL support and PINCONTROL. But you sure don'
6365
* DM, DP, VUSP (The USB pins)
6466
* PA0, PA1 (Crystal, if used)
6567
* PC3
66-
* PD4-PD7
68+
* PD4-PD7
6769
* PF6, PF7 (Reset, UPDI)
6870

6971

@@ -85,35 +87,35 @@ Yes, that, be glad it's on PD6 and 7 not PF6 and 7!
8587

8688
| USART1 | swap | TX | RX | XDIR | XCK |
8789
|---------|------|-----|-----|------|-----|
88-
| ALT2 | 2 | PD6 | PD7 | - | - | Treated as the default, as options 0 and require PC0, PC1 or PC4 and PC5, none of which are available.
90+
| ALT2 | 2 | PD6 | PD7 | - | - | Treated as the default, as options 0 and require PC0, PC1 or PC4 and PC5, none of which are available.
8991
| NONE | 3 | - | - | - | - |
9092

9193

9294
### SPI0 mux options
93-
SPI0 had been swaggering around like he was some sort of movie star after what he got on the DD-series PORTMUX. Well, the DU sure cut him down to size...
94-
On the 14-pin parts, SPI is reduced to a single option on the 14 pin parts.
95+
SPI0 had been swaggering around like he was some sort of movie star after what he got on the DD-series PORTMUX. Well, the DU sure cut him down to size...
96+
On the 14-pin parts, SPI is reduced to a single option on the 14 pin parts.
9597

9698
| SPI0 | swap | MOSI | MISO | SCK | SS |
9799
|---------|------|------|------|-----|-----|
98100
| ALT4 | 4 | PD4 | PD5 | PD6 | PD7 | Treated as the default, as options 0, 1, 2, and 3 all require pins we don't have available.
99101

100102

101103
### TWI0 mux options
102-
A bit confining on 14 pin. Just a bit.
104+
A bit confining on 14 pin. Just a bit.
103105

104-
Not that the single mapping option should surprise anyone, seeing as there is strong precedent for "no pins no feature". As for losing dual mode, I bet USB got into a fight with that the TWI over something and he pulled some strings and got him exiled from the design. Speaking more seriously, I think there was likely concern that it would be hard to accommodate the need for timely processign of both at once. The point of dual mode is - as I understand it - that people want to use AVRs to wrastle other TWI devices, and aggregate the data for communication, likely at a different logic level, over I2C. But this is the DU. The purpose of the DU isn't to play dispatch between TWI and TWI. it's to play dispatch between USB and whatever. So....
106+
Not that the single mapping option should surprise anyone, seeing as there is strong precedent for "no pins no feature". As for losing dual mode, I bet USB got into a fight with that the TWI over something and he pulled some strings and got him exiled from the design. Speaking more seriously, I think there was likely concern that it would be hard to accommodate the need for timely processign of both at once. The point of dual mode is - as I understand it - that people want to use AVRs to wrastle other TWI devices, and aggregate the data for communication, likely at a different logic level, over I2C. But this is the DU. The purpose of the DU isn't to play dispatch between TWI and TWI. it's to play dispatch between USB and whatever. So....
105107

106108
| Mapping | swap | Master or Slave |
107109
|---------|------|-------------------|
108110
| ALT3 | 3 | SDA/PA0 SCL/PA1 |
109111

110112

111113
### TCA mux options
112-
Well, I think you can all guess which option we'd want to default, heh.....
114+
Well, I think you can all guess which option we'd want to default, heh.....
113115

114116
| TCA0 | WO0 | WO1 | WO2 | WO3 | WO4 | WO5 |
115117
|---------|-----|-----|-----|-----|-----|-----|
116-
| PORTA | PA0 | PA1 |
118+
| PORTA | PA0 | PA1 |
117119
| PORTC | - | - | - | PC3 | - | - |
118120
| **PORTD** | **PD0** | **PD1** | **PD2** | **PD3** | **PD4** | **PD5** |
119121

@@ -133,7 +135,7 @@ PORTMUX.TCAROUTEA = tcaroutea; // then write the temp variable back to the regis
133135
```
134136

135137
#### TCB mux options
136-
Same as susual. Guess what pins we don't have here? Yes, that's right, the usual.
138+
Same as susual. Guess what pins we don't have here? Yes, that's right, the usual.
137139

138140
| TCBn | Default | Alt1 |
139141
|------|---------|------|
@@ -144,17 +146,17 @@ Default mappings are used, since PF4/5 are shared with the preferred TCA pins, w
144146

145147
The type B timers are much better utility timers than PWM timers. TCB1 is the default millis timer and cannot be used for PWM in that mode. We're definitely timer-starved on these parts, with only 2 TCB, and with the TCD having been fed to the USB peripheral.
146148

147-
There is no TCD. (It and the PLL driving it was last seen being shoved over thee ciff into the maw of Native USB),
149+
There is no TCD. (It and the PLL driving it was last seen being shoved over thee ciff into the maw of Native USB),
148150

149151
### LED_BUILTIN
150152
To match other parts, `PIN_PA7` shall be the pin that the core "expects" to be connected to an LED. If you want to have a different pin be recognized by the application (this does not change the bootloader - you would still need to do a custom build of that too), this can be overridden if a custom board definition is created by passing `-DLED_BUILTIN=(some other pin)` as part of build_extra_flags, building via the CLI, or by equivalent means provided by other third party development environments.
151153

152154
### Bootloader Options
153155
None for now.
154156

155-
### The ADC took it in the shorts.
157+
### The ADC took it in the shorts.
156158

157-
It's structured like an Ex-class ADC. But it lost it's whole differential section, plus two bits.
159+
It's structured like an Ex-class ADC. But it lost it's whole differential section, plus two bits.
158160

159161
## Official Documentation
160162
When all else fails, read the real documentation. They keep moving the .pdf files around, so now I just link to the prduct page, from whence the datasheet, errata, and "technical briefs" are linked.

‎megaavr/extras/DU20.md‎

Lines changed: 23 additions & 15 deletions
Original file line numberDiff line numberDiff line change
@@ -1,9 +1,17 @@
1-
# AVR32DU20/AVR16DU20
2-
**WARNING** This document is based largely on speculation and the very limited public information about these parts.
1+
# AVR32DU20/AVR16DU20 AVR DU - That's U for USB
2+
3+
These are one of those parts that leave you very little ambiguity about whether it's the right part for the job. Do you need USB? Then you need to DU the DU, cause as far as AVR is concerned, it's this, or classic AVR, and nobody wants to use those. And the DU-family of parts is absolutely a respectable product line. But the fact remains, that if you don't need USB, there is something cheaper, better at what you do need, usually both. USB exacts a very heavy price - but it obviously allows functionality that is otherwise entirely impossible, that of directly interacting with personal computers, so you will be able to:
4+
* Spoof Keyboards and Mice
5+
* Act as a virtual USB serial port
6+
* Make a USB DMX device
7+
* Program over USB pending availability of a bootloader suitable for such
8+
* For the true wizards, the option to make an entirely custom USB device awaits you.
9+
10+
Currently, there is no support for the USB available as part of the core yet, that is the top priority new feature, but one which I feel totally unqualified to write.
11+
12+
**Until there is is at least one library available with some sort of USB functionality, the only reasonable thing to do with this core and a DU microcontroller is to develop such a library.**
13+
Once that has been done, it will open scores of new use cases.
314

4-
## Pin Mapping / Pinout
5-
`[DU20 Pin Mapping](DU20.png "Arduino Pin Mapping for AVR DU20")`
6-
**Image not available - absent help we do not foresee being able to provide any sort of pinout diagram for this or future parts**
715

816

917
## Features and Peripherals
@@ -65,7 +73,7 @@ All pins are fully async, able to wake from sleep without clock on Rising and Fa
6573
### USART1 mux options
6674
*You mean mux **OPTION**!*
6775

68-
Uh, Yes, yes, option.
76+
Uh, Yes, yes, option.
6977

7078
| USART1 | swap | TX | RX | XDIR | XCK |
7179
|---------|------|-----|-----|------|-----|
@@ -74,18 +82,18 @@ Uh, Yes, yes, option.
7482
At least we got two USARTs! Look at the EB!
7583

7684
### SPI0 mux options
77-
SPI0 had been swaggering around like he was some sort of movie star after what he got on the DD-series PORTMUX... Well, the DU sure cut him down to size.
78-
On the 14-pin parts, SPI is reduced to a single option on the 14 pin parts.
85+
SPI0 had been swaggering around like he was some sort of movie star after what he got on the DD-series PORTMUX... Well, the DU sure cut him down to size.
86+
On the 14-pin parts, SPI is reduced to a single option on the 14 pin parts.
7987

8088
| SPI0 | swap | MOSI | MISO | SCK | SS |
8189
|---------|------|------|------|-----|-----|
8290
| ALT4 | 4 | PD4 | PD5 | PD6 | PD7 |
8391

8492

8593
### TWI0 mux options
86-
A bit confining on 14 pin. Just a bit.
94+
A bit confining on 14 pin. Just a bit.
8795

88-
Not that the single mapping option should surprise anyone, seeing as there is strong precedent for "no pins no feature". As for losing dual mode, I bet USB got into a fight with that the TWI over something and he pulled some strings and got him exiled from the design. Speaking more seriously, I think there was likely concern that it would be hard to accommodate the need for timely processign of both at once. The point of dual mode is - as I understand it - that people want to use AVRs to wrangle other TWI devices, and aggregate the data for communication, likely at a different logic level, over I2C. But this is the DU. The purpose of the DU isn't to play dispatch between TWI and TWI. it's to play dispatch between USB and whatever (potentially TWI - but then it'd probably be the master, no? And even if not, dual mode is for running host and client functionality *on* *different* *pins*. You can do multimaster modes from PA0/PA1 just fine as far as I know, with the usual caveats.
96+
Not that the single mapping option should surprise anyone, seeing as there is strong precedent for "no pins no feature". As for losing dual mode, I bet USB got into a fight with that the TWI over something and he pulled some strings and got him exiled from the design. Speaking more seriously, I think there was likely concern that it would be hard to accommodate the need for timely processign of both at once. The point of dual mode is - as I understand it - that people want to use AVRs to wrangle other TWI devices, and aggregate the data for communication, likely at a different logic level, over I2C. But this is the DU. The purpose of the DU isn't to play dispatch between TWI and TWI. it's to play dispatch between USB and whatever (potentially TWI - but then it'd probably be the master, no? And even if not, dual mode is for running host and client functionality *on* *different* *pins*. You can do multimaster modes from PA0/PA1 just fine as far as I know, with the usual caveats.
8997

9098
| Mapping | swap | Master or Slave | Dual Mode Slave |
9199
|---------|------|-------------------|-----------------|
@@ -98,7 +106,7 @@ You really don't use a DU for PWM. It's still credibly for the purpose, just lim
98106

99107
| TCA0 | WO0 | WO1 | WO2 | WO3 | WO4 | WO5 |
100108
|---------|-----|-----|-----|-----|-----|-----|
101-
| PORTA | PA0 | PA1 |
109+
| PORTA | PA0 | PA1 |
102110
| PORTC | - | - | - | PC3 | - | - |
103111
| **PORTD** | **PD0** | **PD1** | **PD2** | **PD3** | **PD4** | **PD5** |
104112
| PORTF | PF0 | PF1 | - | - | - | - |
@@ -118,7 +126,7 @@ PORTMUX.TCAROUTEA = tcaroutea; // then write the temp variable back to the regis
118126
```
119127

120128
#### TCB mux options
121-
Same as susual. Guess what pins we don't have here? Yes, that's right, the usual.
129+
Same as susual. Guess what pins we don't have here? Yes, that's right, the usual.
122130

123131
| TCBn | Default | Alt1 |
124132
|------|---------|------|
@@ -129,17 +137,17 @@ Default mappings are used, since PF4/5 are shared with the preferred TCA pins, w
129137

130138
The type B timers are much better utility timers than PWM timers. TCB1 is the default millis timer and cannot be used for PWM in that mode. We're definitely timer-starved on these parts, with only 2 TCB, and with the TCD having been fed to the USB peripheral.
131139

132-
There is no TCD. (It and the PLL driving it was last seen being shoved over thee ciff into the maw of Native USB),
140+
There is no TCD. (It and the PLL driving it was last seen being shoved over thee ciff into the maw of Native USB),
133141

134142
### LED_BUILTIN
135143
To match other parts, `PIN_PA7` shall be the pin that the core "expects" to be connected to an LED. If you want to have a different pin be recognized by the application (this does not change the bootloader - you would still need to do a custom build of that too), this can be overridden if a custom board definition is created by passing `-DLED_BUILTIN=(some other pin)` as part of build_extra_flags, building via the CLI, or by equivalent means provided by other third party development environments.
136144

137145
### Bootloader Options
138146
None for now.
139147

140-
### The ADC took it in the shorts.
148+
### The ADC took it in the shorts.
141149

142-
It's structured like an Ex-class ADC. But it lost it's whole differential section, plus two bits.
150+
It's structured like an Ex-class ADC. But it lost it's whole differential section, plus two bits.
143151

144152
## Official Documentation
145153
When all else fails, read the real documentation. They keep moving the .pdf files around, so now I just link to the prduct page, from whence the datasheet, errata, and "technical briefs" are linked.

‎megaavr/extras/DU28.md‎

Lines changed: 14 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1,5 +1,17 @@
1-
# AVR64DU28/AVR32DU28/AVR16DU28
2-
**WARNING** This document is based largely on speculation and the very limited public information about these parts.
1+
# AVR64DU28/AVR32DU28/AVR16DU28 AVR DU - That's U for USB
2+
3+
These are one of those parts that leave you very little ambiguity about whether it's the right part for the job. Do you need USB? Then you need to DU the DU, cause as far as AVR is concerned, it's this, or classic AVR, and nobody wants to use those. And the DU-family of parts is absolutely a respectable product line. But the fact remains, that if you don't need USB, there is something cheaper, better at what you do need, usually both. USB exacts a very heavy price - but it obviously allows functionality that is otherwise entirely impossible, that of directly interacting with personal computers, so you will be able to:
4+
* Spoof Keyboards and Mice
5+
* Act as a virtual USB serial port
6+
* Make a USB DMX device
7+
* Program over USB pending availability of a bootloader suitable for such
8+
* For the true wizards, the option to make an entirely custom USB device awaits you.
9+
10+
Currently, there is no support for the USB available as part of the core yet, that is the top priority new feature, but one which I feel totally unqualified to write.
11+
12+
**Until there is is at least one library available with some sort of USB functionality, the only reasonable thing to do with this core and a DU microcontroller is to develop such a library.**
13+
Once that has been done, it will open scores of new use cases.
14+
315

416
## Pin Mapping / Pinout
517
`[DU28 Pin Mapping](DU28.png "Arduino Pin Mapping for AVR DU328")`

‎megaavr/extras/DU32.md‎

Lines changed: 13 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -1,9 +1,17 @@
1-
# AVR64DU32/AVR32DU32/AVR16DU32
2-
**WARNING** This document is based largely on speculation and the very limited public information about these parts.
1+
# AVR64DU32/AVR32DU32/AVR16DU32 AVR DU - That's U for USB
2+
3+
These are one of those parts that leave you very little ambiguity about whether it's the right part for the job. Do you need USB? Then you need to DU the DU, cause as far as AVR is concerned, it's this, or classic AVR, and nobody wants to use those. And the DU-family of parts is absolutely a respectable product line. But the fact remains, that if you don't need USB, there is something cheaper, better at what you do need, usually both. USB exacts a very heavy price - but it obviously allows functionality that is otherwise entirely impossible, that of directly interacting with personal computers, so you will be able to:
4+
* Spoof Keyboards and Mice
5+
* Act as a virtual USB serial port
6+
* Make a USB DMX device
7+
* Program over USB pending availability of a bootloader suitable for such
8+
* For the true wizards, the option to make an entirely custom USB device awaits you.
9+
10+
Currently, there is no support for the USB available as part of the core yet, that is the top priority new feature, but one which I feel totally unqualified to write.
11+
12+
**Until there is is at least one library available with some sort of USB functionality, the only reasonable thing to do with this core and a DU microcontroller is to develop such a library.**
13+
Once that has been done, it will open scores of new use cases.
314

4-
## Pin Mapping / Pinout
5-
`[DU32 Pin Mapping](EA48.png "Arduino Pin Mapping for AVR DU32")`
6-
**Image not available - absent help we do not foresee being able to provide any sort of pinout diagram for this or future parts**
715

816
## Features and Peripherals
917
| | AVR[16|32|64]DU32 |

0 commit comments

Comments
 (0)