- 12V Akku mit 280 Ah bauen         
Seite 2 von 3 ErsteErste 123 LetzteLetzte
Ergebnis 11 bis 20 von 22

Thema: Das Gleiche ist nicht das Selbe - Laufzeitunterschiede

  1. #11
    Erfahrener Benutzer Roboter Experte Avatar von sternst
    Registriert seit
    07.07.2008
    Beiträge
    672
    Anzeige

    Praxistest und DIY Projekte
    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
    MfG
    Stefan

  2. #12
    Erfahrener Benutzer Robotik Visionär Avatar von oberallgeier
    Registriert seit
    01.09.2007
    Ort
    Oberallgäu
    Beiträge
    8.655
    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.
    Ciao sagt der JoeamBerg

  3. #13
    Erfahrener Benutzer Roboter Experte Avatar von sternst
    Registriert seit
    07.07.2008
    Beiträge
    672
    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---------------
    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?
    MfG
    Stefan

  4. #14
    Erfahrener Benutzer Robotik Visionär Avatar von oberallgeier
    Registriert seit
    01.09.2007
    Ort
    Oberallgäu
    Beiträge
    8.655
    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-
    Ciao sagt der JoeamBerg

  5. #15
    Erfahrener Benutzer Roboter Experte Avatar von sternst
    Registriert seit
    07.07.2008
    Beiträge
    672
    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.

    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.

    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.
    MfG
    Stefan

  6. #16
    Erfahrener Benutzer Robotik Visionär Avatar von oberallgeier
    Registriert seit
    01.09.2007
    Ort
    Oberallgäu
    Beiträge
    8.655
    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)).
    Ciao sagt der JoeamBerg

  7. #17
    Erfahrener Benutzer Robotik Einstein Avatar von Jaecko
    Registriert seit
    16.10.2006
    Ort
    Lkr. Rottal/Inn
    Alter
    41
    Beiträge
    2.009
    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
    #ifndef MfG
    #define MfG

  8. #18
    Erfahrener Benutzer Robotik Visionär Avatar von oberallgeier
    Registriert seit
    01.09.2007
    Ort
    Oberallgäu
    Beiträge
    8.655
    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.
    Ciao sagt der JoeamBerg

  9. #19
    Erfahrener Benutzer Lebende Robotik Legende Avatar von PICture
    Registriert seit
    10.10.2005
    Ort
    Freyung bei Passau in Bayern
    Alter
    72
    Beiträge
    11.077
    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

  10. #20
    Erfahrener Benutzer Roboter Experte Avatar von sternst
    Registriert seit
    07.07.2008
    Beiträge
    672
    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.
    MfG
    Stefan

Seite 2 von 3 ErsteErste 123 LetzteLetzte

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •  

LiFePO4 Speicher Test