Kolejny "TIP&TRICK ( niestety kolejny "partyzant").
Modyfikujemy dowolnym edytorem hex-a plik: "as.exe" w toolchainie (w oryginalnym Atmela pod :....\avr\bin\as.exe).
Trzeba znaleźć string nazwy niepotrzebnego nam procesora o odpowiednio długiej nazwie np. "atmega329pa" i zamienić na "atmega328pb". (skontrolować długość pliku przed i po modyfikacji).
Zmiana ta spowoduje, że procesor atmega328pb pojawi się na liście "MCU type" w projekcie Eclipse'a.

Aktualny algorytm:

Operacja jednorazowa:
0. modyfikujemy toolchain plikami dla '328PB lub instalujemy z MkClipse.
0A. modyfikujemy plik as.exe jak wyżej. ( nie załączam modyfikacji z powodów formalnych-każdy hakuje na własną odpowiedzialność).

Normalna praca z procesorem 328pb:
1. zakładamy w Eclipse projekt na: atmega328PB.
2. w Eclipse: project- properties- C/C++general- path and symbols- (zakładka) Symbols- Add- name: MCU value: atmega328pb . Wpis pozwala na obsługę plików io*.h dla '328PB przez Eclipse'a ( brak błędów składni dla rejstrów itp. w edytorze).

Zalety metody:
-pliki io*.h są na swoich miejscach w toolchainie,
-Eclipse "widzi" te pliki oraz "widzi" typ procesora,
-można modyfikować ustawienia kompilacji.
-w widoku: "AVR supported MCU" pojawia się "ptaszek" w kolumnie: "avr-gcc..."
-w widoku: "AVR Device eksplorer" '328pb jest prawidłowo identyfikowany i zasoby są pokazywane.


wady:
- konieczność modyfikacji toolchaina ( i pamiętania o tym w przypadku upgrade'). Mimo wszystko ta metoda jest IMHO bardziej "elegancka", niż oficjalne metody "partyzanckie" stosowane przez ATMEL-a (ukrywanie gdzieś plików io*.h i innych dla '328pb i pokrętna kompilacja, - zamiast prostego zapisania tych plików we właściwych katalogach).
- nadal częściowy brak wsparcia '328pb przez plugin-avr ( metoda "obejściowa").
- konieczność dokładnej weryfikacji (plików wynikowych) tej metody- czy nie zostało coś pominięte.
-w widoku: "Avr supported MCU" nie pojawia się "ptaszek" w kolumnie: "fuses" oraz wartość sygnatury; brak linka do dokumentacji pdf ( to obsługuje avr-plugin).