DxCore integrating my AVR128DA28 based UNO board?

[TheEccentricGenius]

Will you be able to add my UNO board with the AVR128DA28, into DxCore?
Or do I have too support it in my own github repo?

All the changes I'll be doing is the pinout.

[SpenceKonde]

Yes, I can do that, I'd need a variant file from you, and what the other board parameters should be.

I will note that I disapprove of alternate pin numberings; I'm a big advocate of PIN_Pxn pin naming.

[TheEccentricGenius]

I'll try and do it next week, I know what to change.

I'll try to read the code plus documentation to format it closely to how you do, so it's easier to mantain....A big thanks.

[TheEccentricGenius]

So, I've just shuffled the pins to be "more like a UNO", if you don't want to support it....That's fine.
The "UNO" pinout has been tested and works to my knowledge....
pins_arduino_UNO4.txt

As for other board configurations, any DA series 28 pin chip should be included.
All internal clock speeds can be allowed.
All the millis()/micros() timer stuff.
All the BOD & WDT configurations should be too.
Reset pin shouldn't be allowed to be configured....Just stick with the default option.
Startup Time can stay too.
Bootloader Serial Port should only be default....No other options for it.
Bootloader Entry Condition should be default only too.
attachInterrupt menu can stay.
prinf() can stay too.
Wire should only have the 1x Wire options.
And FLMAP can stay too.

[TheEccentricGenius]

Also please can the LED_BUILTIN in the bootloader be moved to PC2.....I tried but my PC didn't want to compile Optiboot and I am no MAKEFILE genius.

Anything not described thoroughly I try to explain better, if there's problems.

Thanks.

[TheEccentricGenius]

You can call it Produnio UNO4, in the boards list.

[TheEccentricGenius]

So, does it match the standard or not....I can redo it if not.

[TheEccentricGenius]

I now want to retain the PIN_Pxn pin naming that you've put there, it makes sense to me.
But....I want the pin numbers to align with what they would be on a UNO.

Any advice?

I don't care about the PIN_Pxn pin naming been wrong, it's appropriate if you into hardware level development,

[TheEccentricGenius]

Maybe I'll try to add PORTx, DDRx, PINx too....Depends on what you think though.

[SpenceKonde]

Sorry for lack of responses on this - past couple of months were a shitshow in my life.

From Arduino.h:

/* The Variant file must do one of the following */
/* 1. Use the same pin order as this core's default pin mapping (recommended)
 * 2. Number each pin (port * 8) + bit_position, and define HYPERRATIONAL_PIN_NUMBERS (also recommended)
 * 3. Define NONCANONICAL_PIN_NUMBERS and use any pin numbering. (recommended if you must use a layout that departs significantly from the above)
 * 4. Define SPECIAL_PIN_NUMBERS, and provide a _digitalPinToCanon(pin) macro that takes an Arduino pin number, and returns (port * 8) + bit_position
 *    (Only if you can do it better than the standard noncanonical implementation - that implementation is not grotesque, but it's also not great.
 *    each table lookup takes the form lds lds add adc ld, 7 words and 10 clocks, so the whole thing is probably on the order of 20 and 26)
 * This change permits underlying logic to be written with a single byte to represent a pin, which is present in some obscure parts of the code
 * mostly involving interrupts.
 * Note that for constant pins known at compile time, these should all be able to be constant folded, it's only compile time unknown pins
 * where this applies. And only for the rare cases where we end up doing this, often interrupt related.
 * A lot of this comes back to the question of whether to leave "holes" for missing pins in the numbering. There are two forces pulling in
 * opposite directions here: each ghost pin takes up 4b for it's entries in the pin table (and it's sort of absurd for a 28-pin part to have
 * 47 logical pins because they were missing PB, PE, and 4 pins of PC and PF, but they make this sort of conversion (and a number of
 * similar ones) much easier.
 */

Hence you must define NONCANONICAL_PIN_NUMBERS. This will perform worse than canonical pin numbers, because it means some shortcuts in the math are not available to us.

I wouldn't remove the comment on PD0

I would also be certain to test that things worked correctly once you had those implemented, because it's very possible that somewhere in the core, we implicitly assume that the pins are numbered the way god intended, and use that to find pins relative to other pins. It might only break the DxCore.h library, which is where some of the stuff that relied upon that lives (it's related to portmux changing I think; haven't looked at that kind of stuff in detail in a while.

There's already an Uno 4 isn't there? Based on a different architecture, different instruction set and with little compatibility.

[TheEccentricGenius]

Yes, I will rename mine to something else.
Sorry about the lack of response....Life is complicated here too.
My idea with this "Uno" is more compatibility with the original, and it is about half as powerful as the Uno R4.

I would prefer that the pin numbering was a simple function, so that none of your work is wasted and if they want sheer performance they can stick with the core with all the pin numbering messed up on the board.
Or I can renumber the board to be jumbled up numbers....

[hoka83]

hello anyone here can help me, i am just connecting arduino uno as a programmer for AVR128DA chip using updi and it gives me this error:
avrdude: jtagmkII_initialize(): Cannot locate "flash" and "boot" memories in description
avrdude: jtagmkII_program_enable(): bad response to enter progmode command: RSP_ILLEGAL_MCU_STATE
avrdude: jtagmkII_program_enable(): bad response to enter progmode command: RSP_ILLEGAL_MCU_STATE
avrdude: jtagmkII_read_byte(): bad response to read memory command: RSP_ILLEGAL_MCU_STATE
avr_read(): error reading address 0x0000
read operation not supported for memory "signature"
avrdude: error reading signature data for part "AVR128DA28", rc=-2
avrdude: error reading signature data, rc=-2
avrdude: jtagmkII_program_disable(): bad response to leave progmode command: RSP_ILLEGAL_MCU_STATE
Error while burning bootloader.

[TheEccentricGenius]

I have tested and modified the variants file, I also have edited the boards file and compiled the bootloader for optiboot.

Here is the all the relevant files.

optiboot_boards_variants.zip