Different MEGA328 package?

I have a design running on an MEGA328P that was developed with Arduino but does not have the boot loader installed in the target chip. I just program via the "Upload Using Programmer" in the Sketch pulldown via the SPI pins and an Atmel ISP MK2 pod.

Works fine with the MEGA328P, the exact same chip on the UNO except has no bootloader.

Now the final design will use a different SMT version of the MEGA328. So how do I make the necessary changes as the pin numbers will be different from the standard Arduino libraries?

Necessary changes to what to do what, exactly? SPI is still SPI. SCK is still PB5. MISO is still PB4. MOSI is still PB3. /SS is still PB2. /RESET is still PC6.

The SPI part is not the issue. I can program the target chip without any issues. I have used and own Atmel tools long before I started with Arduino.

The problem is I need to use three pins with PWM capability. The pin numbers are different on the surface mount chip versus the DIP version on the UNO board.

For example port PD5 is pin# 11 on the standard DIP version of the MEGA328-PU
However port PD5 is pin# 9 on the MEGA328-AUR, a surface mount version.

On other development systems you need to specify the exact chip version or modify the hardware profile. How would I do that with Arduino.

You are confusing physical pin numbers with I/O numbers. PD5 is I/O 5, regardless of what its physical pin number is. Both your sketch and the Arduino AVR core know nothing, care nothing, of the physical pin number.

So are you saying if I specify PD5 on a MEGA328-PU, which is pin# 11, the code will still work on a MEGA328-AUR except that I would use pin#9?

Remember that while both chips are MEGA328, one is the 28pin DIP package and my target is a 32pin TQFP package and has different pin numbers for the ports.

Are you using the VQFN or TQFP package?

I stand behind what I have written.

You might give some thought to the 3rd party Uno R3 boards that use an SMD 328P rather than a DIP. Do they need special changes in your sketch or in the core? Of course not.

Good luck with your project.

TQFP.

The development board was the UNO R3.

The prototype hardware board used a MEGA328-PU DIP version without a bootloader - works fine.

The final product will use a MEGA328-AUR, a TQFP package for size reasons. But I can't easily breadboard that and an initial PCB run is expensive if it doesn't work.

I am just asking a question and trying to understand if and how the complier/linker knows which pin is which function. Or is that hardwired inside the chip and the complier/linker doesn't care.

If you are saying the later is the case, then I am good?

Thank You for your help.

The datasheet will show you the pin designations for the various packages. The chip die inside the packaging doesn't know/care what package pin is connected to which contact on the die. As long as you are connecting to the package pin that the datasheet says is allocated to PD5 (for example), then the physical package doesn't matter.

On an UNO, with the basic blink sketch, LED_BUILTIN is allocated board edge pin D13 which is connected to PB5. Regardless of the type of 328 package, it's still PB5 that gets toggled.

I repeat:

OK, I got it!

Thank you all respondents and happy holiday.

Are you sure?
The 32 pin TQFP has 4 more pins then the 28 pin DIP.
What are you doing with the 4 more pins?

Ignoring the extra pins or ground/Vcc as required. Very simple device:

External crystal, reset circuit, SPI for programmer, and 3 output pins with PWM.

So as long as PD5 is PD5 no matter what package of the MEGA328, I'm good?

I do realize that PD5 on a MEGA8 is not the same as PD5 on a MEGA328 due to different architecture.

You can't ignore ground/Vcc pins.

So as long as PD5 is PD5 no matter what package of the MEGA328, I'm good?

As long as you realize that the physical pin numbers are different.

Not ignoring GND/Vcc pins. I meant connecting them as specified on data sheet even if that pin does not exist on a different package.

Actually, Mega328 and Mega8 are really close to each other. Pin compatible, too. The original Arduino had an ATmega8, and the upgrade(s) to 168 and then 328P were pretty much "drop in a new chip."
(There are a couple of peripheral features missing on the 8: fewer PWMs, no Pin Change interrupt, slightly different UART... So there were SOME oftware changes.)