Das Gleiche ist nicht das Selbe - Laufzeitunterschiede

Druckbare Version

40 Beiträge dieses Themas auf einer Seite anzeigen

29.10.2009, 10:10
sternst

Zitat:

Zitat von oberallgeier

Der Grund, warum der falsche Code vom Compiler nicht angemeckert wird, ist mir noch nicht klar. Der ist aber auch weniger wichtig, als die Antwort auf die Frage, warum der ausführbare Code a) läuft und b) in der inkorrekten Variante zu einer längeren Einschaltdauer des betreffenden Pinns führt.

Das hat doch GeoBot eigentlich schon erklärt.
Das Schreiben einer 1 nach PINx toggelt den Ausgang (nicht bei allen AVRs, nur bei "neueren") , eine 0 hat keine Auswirkung.
Einmal Toggeln pro Schleifendurchlauf => halbe Frequenz mit 50% Duty-Cycle

Und warum bitte sollte der falsche Code vom Compiler angemeckert werden?
Falls sich das auf das MCU-define bezieht, das ist eh völlig ohne Funktion. Da hättest du auch schreiben können:

Code:

#define MCU WirdGarNichtVerwendet
29.10.2009, 10:31
oberallgeier

Danke, ja, das wurde schon erklärt - aber ich habe das noch nicht durchgearbeitet. Gefunden und gelesen hatte ich zwar die Passage schon in meinem Doc 8161C–AVR–05/09, die ist übrigens gleich und auf derselben Seite wie im 8161D. Das muss ich mal in Ruhe durchgehen, um die 50% Duty Cycle und die 200 ms zu begreifen.

Danke jedenfalls für die geduldigen Erläuterungen - und den dontdefinetumuch-Hinweis. Letzterer hängt ein bisschen damit zusammen, dass vom AVRStudio eine so gute Unterstützung geliefert wird. Durch die hatte ich mich anfangs über mache Probleme mancher Kollegen mit dem makefile gewundert . . . das ich garnicht kannte *ggg*. Meine MCU-Definition im Code bleibt aber weiter aus Dokumentationsgründen (auch wenns nicht immer stimmt).

Ich hätte jedenfalls ein Meckern des Compilers erwartet - der ja auch mein PC5 beim mega168 problemlos verstanden hatte; für den mega328 brauchte ich dafür gesonderte defines in meiner ~com~.h.
29.10.2009, 10:57
sternst

Zitat:

Zitat von oberallgeier

Das muss ich mal in Ruhe durchgehen, um die 50% Duty Cycle und die 200 ms zu begreifen.

Ach komm, so kompliziert ist das nicht ;-)

Code:

|-----Schleife-----||-----Schleife-----||-----Schleife-----||-----Schleife-----| 1---0------------- 1---0------------- 1---0------------- 1---0------------- PORT an--aus----------- an--aus----------- an--aus----------- an--aus----------- PIN tog-nix----------- tog-nix----------- tog-nix----------- tog-nix----------- => an---------------- aus--------------- an---------------- aus---------------

Zitat:

Ich hätte jedenfalls ein Meckern des Compilers erwartet - der ja auch mein PC5 beim mega168 problemlos verstanden hatte; für den mega328 brauchte ich dafür gesonderte defines in meiner ~com~.h.

Hä? Du meinst, bei deinem WinAVR fehlt in den Controller-Defines für den Mega328P das PC5?
29.10.2009, 11:25
oberallgeier

Zitat:

Zitat von sternst

... Ach komm, so kompliziert ist das nicht ...

Ahhh - ja, danke, wenn Du das so schön erklärst . . . Und vermutlich haben dann die beiden Befehle SetBit(PINC, 5); und ClrBit(PINC, 5); immer (nur) getoggelt. DAS liesse sich ja praktisch kontrollieren - weil dann in einem 50xBlinke-Loop nur 25 Blinkies erscheinen dürften (habe ich jetzt richtig gedacht?).

Zitat:

Zitat von sternst

... bei deinem WinAVR fehlt in den Controller-Defines für den Mega328P das PC5?

Im Prinzip ja. Das heißt in der iom328p.h vom WinAVR-20090313 nämlich so:

Code:

/* Copyright (c) 2007 Atmel Corporation....*/ .... /* $Id: iom328p.h,v 1.3.2.14 2009/02/11 18:05:28 arcanum Exp $ */ .... /* avr/iom328p.h - definitions for ATmega328P. */ .... /* This file should only be included from <avr/io.h>, never directly. */ .... /* Registers and associated bit numbers */ #define PINB _SFR_IO8(0x03) #define PINB0 0 #define PINB1 1 #define PINB2 2 #define PINB3 3 #define PINB4 4 #define PINB5 5 #define PINB6 6 #define PINB7 7 #define DDRB _SFR_IO8(0x04) #define DDB0 0 #define DDB1 1 #define DDB2 2 #define DDB3 3 #define DDB4 4 #define DDB5 5 #define DDB6 6 #define DDB7 7 #define PORTB _SFR_IO8(0x05) #define PORTB0 0 #define PORTB1 1 #define PORTB2 2 #define PORTB3 3 #define PORTB4 4 #define PORTB5 5 #define PORTB6 6 #define PORTB7 7 #define PINC _SFR_IO8(0x06) #define PINC0 0 #define PINC1 1 #define PINC2 2 #define PINC3 3 #define PINC4 4 #define PINC5 5 #define PINC6 6 #define DDRC _SFR_IO8(0x07) #define DDC0 0 #define DDC1 1 #define DDC2 2 #define DDC3 3 #define DDC4 4 #define DDC5 5 #define DDC6 6 #define PORTC _SFR_IO8(0x08) #define PORTC0 0 #define PORTC1 1 #define PORTC2 2 #define PORTC3 3 #define PORTC4 4 #define PORTC5 5 #define PORTC6 6

und wurde von mir in meiner ~com~.h so ersetzt (weil ich es eben anders gewöhnt bin):

Code:

// === #defines der PortPins beim 328p =========================================== // === Portpins sind beim 328p definiert als PINB1 bzw. PORTB1 =================== // ================================================================================= #define PB0 0 // Pindefinition #define PB1 1 // Pindefinition #define PB2 2 // Pindefinition #define PB3 3 // Pindefinition #define PB4 4 // Pindefinition #define PB5 5 // Pindefinition #define PB6 6 // Pindefinition #define PB7 7 // _ // Pindefinition _ _ _ Port B hier zu Ende #define PC0 0 // Pindefinition #define PC1 1 // Pindefinition #define PC2 2 // Pindefinition #define PC3 3 // Pindefinition #define PC4 4 // Pindefinition #define PC5 5 // Pindefinition _ _ _ PortC/PDIP328p nur bis PC5

Schien mir sicherer (weniger fehlerträchtig) als die neuen Pinbezeichnungen - vor allem, wenn ich mal wieder vom m328p auf den m168 zurückgehen will.

So - und nun schalte ich erstmal aus (und gehe noch ne Runde fliegen).

Danke für Deine Unterstützung-
29.10.2009, 11:36
sternst

Zitat:

Zitat von oberallgeier

Und vermutlich haben dann die beiden Befehle SetBit(PINC, 5); und ClrBit(PINC, 5); immer (nur) getoggelt.

SetBit(PINC, 5) toggelt, und ClrBit(PINC, 5); macht gar nichts.

Zitat:

Im Prinzip ja. Das heißt in der iom328p.h vom WinAVR-20090313 nämlich so:

Ah tatsächlich. Anscheinend hat Atmel die Namensgebung etwas geändert. Die Defines werden nämlich automatisch aus Atmels Device-Description-Files generiert.

Zitat:

Meine MCU-Definition im Code bleibt aber weiter aus Dokumentationsgründen

Würde ich nicht machen. Du hast doch schon im Kommentar am Anfang der Datei den Controller stehen. So ein funktionsloses Define stiftet höchstens Verwirrung, wie man ja hier gesehen hat. ;-)
29.10.2009, 11:48
oberallgeier

Zitat:

Zitat von sternst

... Würde ich nicht machen ... ein funktionsloses Define stiftet höchstens Verwirrung ...

Ok.

Übrigens: Bis auf dieses Detail mit den Portpins ist der m328p nach meinen bisherigen, eher bescheidenen Erfahrungen aber code-kompatibel. (Beispiel: Code total ca. 2800 Zeilen, davon ca. 50+ % Kommentar, Hex 20 KB bzw: Program: 7236 bytes (22.1% Full) Data: 418 bytes (20.4% Full)).
29.10.2009, 14:46
Jaecko

Zitat:

Zitat von oberallgeier

[OT]Es ist nicht möglich, dass die fehlerhafte MCU-Bezeichnung auf eine bayerische Zifferntastatur zurückzuführen ist, da die bekanntlich keine 6 enthält. Ihr kennt die bayerische Zifferntastatur nicht? Bild hier [/OT]

Wer's noch nicht kennt:
http://www.affengeile-geschenke.de/a...ausschnitt.jpg
29.10.2009, 20:15
oberallgeier

Zitat:

Zitat von sternst

... Ach komm, so kompliziert ist das nicht ...

Stimmt, es ist tatsächlich garnicht kompliziert. Der Text der Dokumentation vom Mai 09 ist derselbe wie der vom Oktober 09 und für mich wirklich gut verständlich. Was die Entwickler dabei gedacht hatten - oder ist anzunehmen, dass diese Funktion sich einfach ergeben hat? Egal. Bleibt für mich allenfalls nur noch übrig zu klären, ob das Ding im roten Kreis ein FET ist?

................Bild hier

Allen herzlichen Dank für Mühe und Geduld.
29.10.2009, 20:25
PICture

Hallo!

@ oberallgeier

Laut Symbol ist es ein MOSFET (metall oxid semiconductor FET). Der Unterschied im Bau zum JFET (juncion FET) ist nur, dass Gate (G) von Kanal (S-D Strecke) isoliert ist.

MfG
29.10.2009, 20:38
sternst

Zitat:

Zitat von oberallgeier

Was die Entwickler dabei gedacht hatten - oder ist anzunehmen, dass diese Funktion sich einfach ergeben hat?

Ne, das war schon Absicht. ;-)
Das gibt einem die Möglichkeit, Teile eines Ports atomar umzuschalten.

40 Beiträge dieses Themas auf einer Seite anzeigen