umstieg auf PicoPower

[oberallgeier]

Hi thewulf00, hallo alle,

Unterschiede vom 168 zum 328p:
- doppelt soviel Flash, EEProm und RAM ...

Die Verdoppelung des Speichers hatte mich zur erhöhten Geldausgabe verleitet. Die ersten Versuche zeigen mir: es gibt weitere Unterschiede. Ich habe aber leider keinen Schimmer welche. Es ist so, dass ich den m168er Code nicht 1:1 für den m328P zum Übersetzen bekomme (aber ich kann natürlich immer noch nicht für meine C-Codes garantieren). Während der alte Code für den mega168 störungsfrei compiliert wird und einigermassen sinnvoll läuft (siehe hier Funktionsbeispiel), bringt dieselbe, einfach kopierte Modulsammlung Fehler. WinXPpro, AVR Studio 4.16.638 mit SP, WinAVR-20090313. Das ganze Projekt wurde natürlich in der üblichen Weise als "neues Projekt" im AVRStudio angelegt; die einzigen Änderungen sind die Bezeichnungen der MCU in den AVRStudio Project Options und als #define MCU = AVR_ATmega328P im Code.

Zwei beispielhafte Compilermeldungen:

Die Definition im Headerfile *com*.h
ISR(TIMER0_COMPA_vect);
ergibt den Fehler
../D01_20_com_x51.h:246: warning: data definition has no type or storage class

Diese Codezeile
PORTC ^= (1<<PC4); // Zeitmessung: Port PC5 toggeln
bringt mir diese Fehlermeldung (und ähnliche für andere Ports)
../D01_20_gpd_x50.c:81: error: 'PC4' undeclared (first use in this function)

Und so spät in der Nacht finde ich nicht den geringsten Hinweis im Datenblatt 8161C–AVR–05/09 zum ATmega328P. Zu allem Überfluss läuft der für den mega168 compilierte Hexfile auf dem 328P ohne Störung. Ich bitte deprimiert um Hilfe.

[manhunt]

Is des jetzt ein Scherz? (ohne Spaß)

Da hat Atmel bzw der avr-gcc/avr-libc einfach bei der implementierung der atmega328p geschlampt also etwaige Defines gehen bei dir nicht. Oberallgeier hast du wirklich atmega328p eingegeben und wenn ja kannst du probieren das p wegzulassen? (ka ich benutz AVR studio nicht)

Das das hexfile geht glaub ich dir gerne deine Fehler sind ja auch nur ganz kleine Fehler bei der Implementierung un die avr-libc aber trotzdem solltest du dem ganzen nicht trauen da du im 328 ne ram verdopplung hast die du jetzt sicher nicht nutzt bzw sicher nicht ALLE SFR vom 168 an den selben Adressen beim 328 sitzen.

lg manhunt

[oberallgeier]

... Da hat Atmel bzw der avr-gcc/avr-libc einfach bei der implementierung der atmega328p geschlampt ...

Das glaube ich erstmal NICHT (ist auch kein Spass - nicht so spät nachts). Bei wenigen anderen Fällen hatten sich ähnliche Vermutungen durch mich nie bewahrheitet. Ich hatte so etwas auch nie ernsthafter geglaubt. Es geht sicherlich auf eine Unsauberkeit im Code zurück, vielleicht bei meiner Headerdatei. Hier bekomme ich sicher die Quittung für "Mutiges Programmieren bei bescheidenen Sprachkenntnissen". Headerdatei gibts hier wegen 20 000 - Zeichen-Limit bei Forumpostings.

... hast du wirklich atmega328p eingegeben und wenn ja kannst du probieren das p wegzulassen ...

Ja und ja. Das "p" weglassen geht bei den Projekt Options nicht, da gibt es nur ein Flyout (die Programmierer kennen ja ihre Pappenheimer) bzw. beim Erstellen eines neuen Projektes eine feste Deviceliste, beide mit einer definierten Auswahl. Die Deklaration einer MCU im Code ist danach überflüssig, läuft mit oder ohne, "Die Programmierer ... " siehe oben.

... sicher nicht ALLE SFR vom 168 an den selben Adressen beim 328 sitzen ...

Ich hatte gestern vor posten meines Hilferufes die docs 2545P–AVR–02/09 zu ATmega48/88/168 und 8161C–AVR–05/09 zu ATmega48PA/88PA/168PA/328P miteinander verglichen. Die Vektortabellen sind für meine beiden Controller gleich, andere Hinweise für Unterschiede hatte ich nicht gefunden. Das auf mehrere ISR gestützte Programm für den m168 läuft im MiniD0 - siehe das Beispiel im obigen Link, da aber noch mit m168 - problemlos auf dem m328 im MiniD0 mit gleichen Bewegungen. Auch das erste Flashen ging problemlos, >>nachdem<< ich nach mehreren Versuchen festgestellt hatte, dass CKDIV8 aktiv war, wodurch der Controller weder bei 1,5 MHz noch bei 375 kHz erkannt wurde. Erst mit weniger als 100 kHz meldete er sich . . . . . Wird wohl ein anstrengendes Wochenende. Aber ich habe jetzt ja wieder neue m168er *gggg*.

[oberallgeier]

Der Spruch stimmt also doch: Selbst ist der Programmierer (altindische IT-Weisheit). Das Problem war simpel, ist mir aber total unverständlich: Die Portanschlüsse sind vom Compiler als beispielsweise PB2 oder PD4 ohne weiteres nicht erkennbar. Abhilfe brachten Codezeilen in meiner Headerdatei in der Art wie :

 #define    PB2     2           // Pindefinition

Das Seltsame daran ist, dass diese Pinbezeichnungen im Code bei einer Übersetzung für den mega168 vom Compiler angenommen werden.

[manhunt]

Hallo

Ja solche Dinge werden vom Präprzessor übernommen abhängig davon welchen µC du beim define mcu definierts bzw avrstudio......das ist ja auch der Grund warum du PORTE und solche Sachen beim Atmega8 nicht hast, beim 128 jedoch schon es sind ja immer die selben Header nur der Präcompiler passt das halt immer den Umständen entsprechend an.

Deshalb auch meine vermutung das da was schief gegangen ist. Vielleicht solltest du mal die avr-libc updaten....

lg manhunt

[radbruch]

Diese defines stehen in der entsprechenden ioxxx.h im avr-Verzeichniss von WinAVR.

[manhunt]

Ich habs zwar grad net da aber ich glaube für den at328 is es die ioxx8.h oder? Bzw für 168 und 88 und 48 is es immer das selbte...

lg manunt

[oberallgeier]

Diese defines stehen in der entsprechenden ioxxx.h im avr-Verzeichniss von WinAVR.

Genau das hatte ich auch erhofft/angenommen/vermutet/gedacht. ABER:
Für den *328* gibts im WinAVR-20090313 nur die iom328p.h, darin steht
#define PINB1 1 (und Sinngemässes).
Diese iom328p.h wird mittels meiner Codezeile #include <avr/io.h> eingebunden. Daher kommt natürlich, wenn ich die iom328p.h explizit einbinde, diese Fehlermeldung:
#error "Attempt to include more than one <avr/ioXXX.h> file."
Diese Fehlermeldung kommt natürlich auch, wenn ich die iox8.h einbinde (in der PB1 etc. definiert ist).

Dagegen läuft das Compilieren für den mega168 problemlos mit diesen drei libs:
#include <stdlib.h>
#include <avr/io.h>
#include <avr/interrupt.h>

Warum? Weil die io.h für den mega168 die iom168.h includiert in der die iomx8h includiert wird *ggggg*. So ein hübsches Gimmick um drei Ecken gibts leider in der iom328p.h nicht . Macht ja auch nix, ich bin ja draufgekommen. War zwar unerwartet, aber ansonsten nur ein bisschen Arbeit, sonst nix.

Fazit: Wer den mega328 verwendet und die Pinne in der bekannten Art PB1 und ähnlich deklarieren will, muss sich selbst drum kümmern.

[markusj]

@Oberallgeier:
Dann würde ich aber eher über Defines die neuen Bezeichner auf die alten Mappen, man weiß ja nie wann wo was mal nicht so ist wie erwartet.

Warum man in der avr-libc jetzt plötzlich so einen Stilbruch gemacht hat, würde mich aber auch mal interessieren.

mfG
Markus

[oberallgeier]

... über Defines die neuen Bezeichner auf die alten Mappen ...

... Und nach dem nächsten Update geht dann wieder nix mehr.

... Warum man in der avr-libc ... so einen Stilbruch gemacht hat, würde mich aber auch mal interessieren ...

. . . O jerum, jerum, jerum, o quae mutatio rerum!