- Labornetzteil AliExpress         
Seite 3 von 5 ErsteErste 12345 LetzteLetzte
Ergebnis 21 bis 30 von 48

Thema: Seltsames Problem

  1. #21
    Erfahrener Benutzer Roboter Genie Avatar von HeXPloreR
    Registriert seit
    08.07.2008
    Ort
    Soltau - Niedersachsen
    Alter
    46
    Beiträge
    1.369
    Anzeige

    LiFePo4 Akku selber bauen - Video
    Also bei mir tut die Hex vom Hubert genau das was sie soll: 5x PB1 an/aus, PB0 an, 5x PB1 an/aus, PB0 aus und wieder von vorne...
    Wo der Fehler bei Dir liegt kann ich nicht sagen, ich tippe: Frequenz...oder einfach falschrum eingesetzt

    viele grüße
    Geändert von HeXPloreR (09.10.2012 um 16:37 Uhr)

  2. #22
    Erfahrener Benutzer Begeisterter Techniker
    Registriert seit
    21.04.2010
    Beiträge
    356
    Hm also ich hab jetzt nochmal mein Programm auf das wesentlich wichtige beschränkt:
    Code:
    #define F_CPU 8000000UL
    #include <avr/io.h>
    #include <util/delay.h>
    #include "port.h"
    int main(void)
    {
        DDRB=0xFF;
        while(1)
        {
            _delay_ms(100);
            toogle_pin(PORTB,PB0);
        }
        return 0;
    }
    was von GCC wie folgt übersetzt wird:
    Code:
        .file    "main.c"
    __SREG__ = 0x3f
    __SP_H__ = 0x3e
    __SP_L__ = 0x3d
    __CCP__ = 0x34
    __tmp_reg__ = 0
    __zero_reg__ = 1
        .text
    .global    main
        .type    main, @function
    main:
    /* prologue: function */
    /* frame size = 0 */
    /* stack size = 0 */
    .L__stack_usage = 0
        ldi r24,lo8(-1)
        out 55-32,r24
        ldi r25,lo8(1)
    .L2:
         ldi r18,lo8(159999)
        ldi r19,hi8(159999)
        ldi r20,hlo8(159999)
        1:subi r18,1
        sbci r19,0
        sbci r20,0
        brne 1b
        rjmp .
        nop
        in r24,56-32
        eor r24,r25
        out 56-32,r24
        rjmp .L2
        .size    main, .-main
    Und erstaunlicherweise funktionierd.
    Ich hab keine Ahnung woran es lag, aber jetzt schein alles zu funktionieren.
    Auch sachen ala
    Code:
    for(uint8_t i=0;i<10;i++) _delay_ms(100);
    gehen plötzlich.
    Obwohl ich schwören könnte vorher alles richtig gemacht zu haben.

  3. #23
    Erfahrener Benutzer Roboter Genie Avatar von HeXPloreR
    Registriert seit
    08.07.2008
    Ort
    Soltau - Niedersachsen
    Alter
    46
    Beiträge
    1.369
    Und wieso benutzt Du jetzt eine port.h - und woher hast Du die? Hast Du nicht schon io.h drin? Und 8MHz???? naja, was denn nun...1MHz oder 8MHz?
    Ich vermute dass das neue Programm garnicht auf dem µC angekommen ist vorher.
    Geändert von HeXPloreR (09.10.2012 um 16:55 Uhr)

  4. #24
    Erfahrener Benutzer Begeisterter Techniker
    Registriert seit
    21.04.2010
    Beiträge
    356
    8MHz weil ich die Fuses wieder umgestellt hab.
    port ist ne eigene die ich schon weiter oben gepostet hab.
    und irgendwie hast mich das zeug trotzdem, nachdem das Programm größer wird bleibt es wieder einfach stehen.
    Also zumindest hab ich nen neuen ansatz:
    Wenn ich den MC auf 1MHz stelle läuft das Programm und wenn ich ihn auf 8MHz stelle läuft es nicht.(natürlich takt im code angepasst.

  5. #25
    Erfahrener Benutzer Roboter Genie Avatar von HeXPloreR
    Registriert seit
    08.07.2008
    Ort
    Soltau - Niedersachsen
    Alter
    46
    Beiträge
    1.369
    jetzt versteh ich nixhts mehr...mit 8MHz läuft es, dann mit 1MHz auch...und jetzt wieder mit 8MHz nicht mehr?
    Welche Spannung nutzt Du,das wurde weiter oben schon mal gefragt? Kann es sein das er mit deiner Spannung nicht mit 8MHz läüft bzw sobald Du LED zuschaltets die knappe Spannung einbricht und der µC resetet wird bzw die Brown Out detection anspricht?

    Habe diese Probleme nicht bei 5V.
    Beide GND Pins angeschlossen?
    Du weißt, das Du die Hex von Hubert jetzt nur an 1MHz verwenden kannst/solltest!?

    Viele Grüße
    Geändert von HeXPloreR (09.10.2012 um 18:38 Uhr)

  6. #26
    Erfahrener Benutzer Begeisterter Techniker
    Registriert seit
    21.04.2010
    Beiträge
    356
    Also mal ganz von vorne:
    Ich nutze via die Stromversorgung des MyAVR MK2, das sind 5V, aus dem USB anschluss.
    Ich takte den AVR über den internen Taktgenerator.
    Ich habe folgendes Programm erstellt:
    Code:
    #include <avr/io.h>
    #include <util/delay.h>
    #include "port.h"
    
    int main()
    {
        DDRB=0xFF;
        while(1)
        {
            _delay_ms(100);
            toogle_pin(PORTB,PB0);
        }
    }
    Das läuft mit 1MHz prima, nutze ich jedoch 8MHz geht die LED einmal an und bleibt an.
    Es sind beide AGND-GND->MyAVR GND
    AVCC->VCC-> MyavrVCC
    PB0->LED rot->GND
    PB1->LED grün->GND
    Reset->R4,7k->VCC
    zwischen GND und VCC hängt ein 100nf cap und die ISP pins sind direkt durchgeschlossen.
    Ja mir ist klar das ich das von Hubert nur mit 1MHz nutzen kann, allerdings funktionierd das von Hubert auch mit 1MHz nicht.
    Ich glaube ich weis das Problem, meine _delay_ms routine ignoriert irgendwie die Takt angabe.
    Folgendes Szenario:
    Wenn ich den AVR auf 1MHz stelle und im Quellcode F_CPU mit 1MHz definiere wartet er bei
    Code:
    for(uint8_t i=0;i<10;i++) _delay_ms(100);
    genau 1s.
    Stelle ich nun den AVR auf 2MHz, schreibe in den Quellcode F_CPU mit 2MHz müsste er ja bei obigem Code wieder 1s warten, tut er aber nicht. er wartet eine halbe sekunde.
    bei 4MHz dementsprechend 250ms, bei 8 MHz 125ms.
    Daher dachte ich vorhin er würde hängen, da ich als zeitspanne nur 100ms hatte, er aber bei 8MHz nur 12.5ms gewartet hat konnte ich das An und aus schlicht nicht mehr erkennen.
    Um diese Erkenntnis auszuprobieren hab ich promt an F_CPU rumgespielt.
    Ich habe Werte zwischen 100kHz und 100GHz eingestellt, dabei war es vollkommen egal, die Led blinkt bei einem CPUTakt von 8MHz mit konstanten 8Hz vor sich hin, egal wie ich F_CPU definiere.
    Hoffe das hat jetzt jemand verstanden.
    Geändert von Thalhammer (09.10.2012 um 21:16 Uhr)

  7. #27
    Erfahrener Benutzer Roboter Genie Avatar von HeXPloreR
    Registriert seit
    08.07.2008
    Ort
    Soltau - Niedersachsen
    Alter
    46
    Beiträge
    1.369
    okay, ich nehme an Du hast zwischen LED die min 470Ohm Widerstände extern verbaut? Ich schlage vor Du entfernst mal die Verbindung bei AVCC - denke die benötigt man hier nicht - und schon garnicht einfach so angeschlossen - und das dadurch der fehler entsteht ist naheliegend.

    Dann liesst du bitte einmal die Low-Fuses aus, um die Anzeige zu aktualisieren. Dann prüfst Du ob 1MHz (+64ms)
    Und dann nimmst Du bitte nochmal die Hex von Hubert und brennst es in den Flash.
    Geändert von HeXPloreR (09.10.2012 um 21:16 Uhr)

  8. #28
    Erfahrener Benutzer Begeisterter Techniker
    Registriert seit
    21.04.2010
    Beiträge
    356
    Lies mal oben, ich hab was ergänzt, ich denke der Fehler liegt bei der PC Software.

  9. #29
    Erfahrener Benutzer Roboter Genie Avatar von HeXPloreR
    Registriert seit
    08.07.2008
    Ort
    Soltau - Niedersachsen
    Alter
    46
    Beiträge
    1.369
    ...und ich denke Du schreibst die Fuses einfach nicht in den µC...nur im Programm reicht eben einfach nicht, da kannst Du rein schreiben was du möchtest an Frequenzen, damit versaust Du Dir nur die Zeiten, dein µC läuft fleissig mit 1MHz - weil Du es nicht für nötig hälst den "manuell" auszulesen(zur Kontrolle) und dann "um zu stellen", und dann in den Fuse Speicher "einzuschreiben".

    Code:
    $regfile = "m8adef.dat"
    $crystal = 8000000
    
    $baud = 19200
    
    
    $hwstack = 40
    $swstack = 16
    $framesize = 32
    
    Led Alias Portb.0                                           'the anode of the LED connected to PortB.0, cathode with resistor (470 Ohm) to ground
    Config Pinb.0 = Output
    
    Do
        Waitms 500
        Toggle Led
    Loop
    Geht sogar in Bascom...hab 100 zu 500 ms geändert damit man es besser sehen kann

    Wenn ich meine Fuses über mySmartUSB mit myAVR öffne, dann steht dort JEDESMAL 1MHz is default, erst nach dem auslesen der Fuses zeigt es den richtigen Wert von 8MHz an.
    Geändert von HeXPloreR (09.10.2012 um 21:53 Uhr)

  10. #30
    Erfahrener Benutzer Begeisterter Techniker
    Registriert seit
    21.04.2010
    Beiträge
    356
    Bei dem Satz komm ich nicht mit.
    Egal, hier meine Vorgehensweise:
    Ich stelle den AVR auf 1MHz (lfuse=0xE1) und gebe im File F_CPU 1000000UL an.
    Ich baue und flashe mein Programm.
    Die LEd blinkt mit 1Hz->Stimmt so.
    Ich stelle den AVR auf 2MHz (lfuse=0xE2).
    Die Led blinkt mit 2Hz->Stimmt so, da das neue Programm noch nicht geflasht wurde, also stimmen die Zeiten nicht.
    Ich ändere im File auf f_CPU 2000000UL.
    bauen, übertragen.
    Die Led blinkt aber nach dem flashen immernoch mit 2Hz->Stimmt nicht, da er eigentlich die Zeiten anpassen müsste.
    ---->>>Der Compiler passt die Zeiten nicht an.
    Und ich hab jetzt in das ASM File gekuckt und einmal für 1MHz erstellt und einmal für 8MHz, die Dateien sind absolut identisch.
    Falls jetzt noch einer an einen Hardware defekt glaubt muss er schon ein verdammt gutes argument haben.
    Ich hab mal die ASM files als zip angehängt damit ihr euch überzeugen könnt.
    Angehängte Dateien Angehängte Dateien
    • Dateityp: zip ASM.zip (824 Bytes, 2x aufgerufen)
    Geändert von Thalhammer (09.10.2012 um 21:58 Uhr)

Seite 3 von 5 ErsteErste 12345 LetzteLetzte

Ähnliche Themen

  1. Seltsames Problem bei Array; Werte wandern
    Von Jaecko im Forum C - Programmierung (GCC u.a.)
    Antworten: 3
    Letzter Beitrag: 05.07.2012, 23:11
  2. Seltsames Problem nach dem Flashen...
    Von Nix_Blicker im Forum Asuro
    Antworten: 6
    Letzter Beitrag: 17.09.2008, 01:08
  3. Sehr sehr seltsames Problem
    Von Powell im Forum Elektronik
    Antworten: 9
    Letzter Beitrag: 23.05.2008, 21:32
  4. Antworten: 0
    Letzter Beitrag: 15.02.2008, 13:14
  5. Seltsames Problem (Erledigt)
    Von sledge77 im Forum Elektronik
    Antworten: 1
    Letzter Beitrag: 13.12.2006, 00:19

Berechtigungen

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

LiFePO4 Speicher Test