- LiFePO4 Speicher Test         
Seite 3 von 3 ErsteErste 123
Ergebnis 21 bis 25 von 25

Thema: Immer wieder Servos...

  1. #21
    Erfahrener Benutzer Robotik Visionär Avatar von 021aet04
    Registriert seit
    17.01.2005
    Ort
    Niklasdorf
    Alter
    36
    Beiträge
    5.070
    Anzeige

    Praxistest und DIY Projekte
    1.) Masseschleife durch Induktion? Was meinst du damit?
    2.) Wenig Strom ist das bei einem Servo definitiv nicht. Servos nehmen beim Verfahren mehrere Ampere auf (abhängig vom Servo) und das ist nicht wenig.
    3.) Du musst dir vor Augen halten das jede Leiterbahn ein Widerstand ist und dieser einen lastabhängigen Spannungsabfall verursacht. Dadurch kann es z.b. zu einem Reset des uC kommen (im schlimmsten Fall).

    MfG Hannes

  2. #22
    Neuer Benutzer Öfters hier Avatar von Radom
    Registriert seit
    18.12.2016
    Ort
    Raisting
    Beiträge
    11
    @i_make_it
    Davon bin ich weit entfernt! Wenn ich meinen Plan nicht so aufbaue, wie er dann auch tatsächlich verdrahtet wird, kenn ich mich nicht mehr aus, bin ja blutiger Anfänger mit Elektronik...
    Edit: 10 oder mehr Layer, wegen Signalversatz auf die Länge der Leitung achten, da raucht mir der Kopf, wobei ich mich wahrscheinlich schon mit
    kapazitive und induktive Kopplungen
    beschäftigen werde müssen

    @Hannes
    1) Masseschleife war falsch geschrieben, die habe ich ja nicht. Aber einen Störstrom könnte ich ja durch Induktion bekommen, oder? (weil das gibt es im Audiobereich ja auch)
    2) Der gezogene Strom für die Servos läuft doch bei mir nicht über uC, wegen der extra Stromversorgung, deshalb macht man das doch, oder verstehe ich es falsch?
    3) Der uC resetet ja nicht, sondern das Rechtecksignal zitterte am Ende

    Danke für eure vielen Infos!

  3. #23
    Erfahrener Benutzer Robotik Visionär Avatar von 021aet04
    Registriert seit
    17.01.2005
    Ort
    Niklasdorf
    Alter
    36
    Beiträge
    5.070
    Zu Punkt 2 musst du meinen Punkt 3 lesen => jede Leiterbahn ist ein Widerstand mit lastabhängigem Spannungsabfall
    Zu Punkt 3 habe ich geschrieben das im schlimmsten Fall der uC resettet, es können aber auch andere Fälle eintreten (wiebei dir mit den Signalen).
    Deswegen Lastkreis und Steuerkreis trennen, Massen an einem Punkt zusammenführen (Sternpunkt).

    MfG Hannes

  4. #24
    Neuer Benutzer Öfters hier Avatar von Radom
    Registriert seit
    18.12.2016
    Ort
    Raisting
    Beiträge
    11
    Ist schon einige Zeit her, aber das Thema war ja noch nicht vom Tisch.

    Den Kabelsalat habe ich durch Platinen ersetzt. Es gibt jetzt nur noch längere an den Tastern und Servos, weil sie ja weiter weg sind.
    Last- und Steuerkreis sind getrennt und Massen habe ich auch sauber zusammengeführt.

    Danke für eure Tips und Infos !
    Was auch immer es am Ende war es hat sich erledigt, jetzt läuft es !!

    Zur Programmierung von zeitkritischen Sachen habe ich noch Fragen, bei denen ihr mir vielleicht noch mal Tips geben könnt:
    Kann man eigentlich irgendwie messen wie lange bestimmte Anweisungen brauchen, oder bleibt da nur testen ?

    Viele Anweisungen, die in der ISR ausgeführt werden sollen, habe ich ja eigentlich nicht (gefühlt):
    Timer 1
    1. Servo-Laufvariable resetten wenn > Anzahl Servos
    2. 3 einfache Berechnungen um am MUX-Shield den richtigen Pin auszulesen
    3. je nach Taster-Status Werte in zwei Arrays schreiben
    4. über eine for() jeweils 1x shiftOut() an insgesamt 3 Register senden
    5. Länge für OCR1B aus dem Array lesen, dem Timer zuweisen und ihn starten


    Timer 2
    1. Timer interrupt abschalten
    2. per shiftOut() das Steuersignal wieder abschalten


    Anfangs hatte ich den Ablauf noch etwas anders, aufgeblähter, und ich musste die Routinen auf das obige reduzieren sonst war der Zeitablauf gestört und es lief natürlich nicht.
    Am schlimmsten waren
    Code:
    Serial.print()
    Serial.println()
    die ich Anfangs einfach brauchte um meinen Code zu kontrollieren.

    Die kürzeste Zeit, die der Arduino in meinem Programm zum Ausführen bis zum nächsten Interrupt hat, sind 0,6 ms - und mich wundert jetzt, dass bei einem Takt von 16 MHz, den der Arduino UNO ja hat, so wenige Zeilen da schon was ausmachen.
    Also dass das ein Tick nicht genügt um eine Anweisung auszuführen ist mir klar, aber gibt es Anhaltswerte wonach ich gehen kann? Dass ich abschätzen kann wie viele Anweisungen in eine Zeit x passen?
    Wie macht ihr das?


    Viele Grüße, Radom

  5. #25
    Erfahrener Benutzer Robotik Visionär Avatar von oberallgeier
    Registriert seit
    01.09.2007
    Ort
    Oberallgäu
    Beiträge
    8.685
    .. Die kürzeste Zeit .. bis zum nächsten Interrupt hat, sind 0,6 ms .. gibt es Anhaltswerte wonach ich gehen kann? Dass ich abschätzen kann wie viele Anweisungen in eine Zeit x passen?
    Wie macht ihr das? ..
    600 µs bei 16 MHz ergibt 9600 Taktzyklen. Das sind ja nu nicht sooo viel. Nen genauen Zeitbedarf bekommst Du aus der fooxxfile.lls heraus. Darin, in der *.lls steht nämlich neben allen möglichen Dingen auch der (dis-)assemblierte Code Deines Programms, siehe dieses Beispiel aus (m)einen Codevorrat :
    Code:
    arno_01.elf:     file format elf32-avr
    
    Sections:
    Idx Name          Size      VMA       LMA       File off  Algn
      0 .data         00000366  00800100  000019cc  00001a80  2**0
                      CONTENTS, ALLOC, LOAD, DATA
      1 .text         000019cc  00000000  00000000  000000b4  2**1
                      CONTENTS, ALLOC, LOAD, READONLY, CODE
      2 .bss          00000165  00800466  00800466  00001de6  2**0
                      ALLOC
      3 .eeprom       00000001  00810000  00810000  00001de6  2**0
                      CONTENTS, ALLOC, LOAD, DATA
      4 .debug_aranges 00000020  00000000  00000000  00001de7  2**0
                      CONTENTS, READONLY, DEBUGGING
      5 .debug_pubnames 000006d9  00000000  00000000  00001e07  2**0
                      CONTENTS, READONLY, DEBUGGING
      6 .debug_info   000019a4  00000000  00000000  000024e0  2**0
                      CONTENTS, READONLY, DEBUGGING
      7 .debug_abbrev 00000311  00000000  00000000  00003e84  2**0
                      CONTENTS, READONLY, DEBUGGING
      8 .debug_line   0000141d  00000000  00000000  00004195  2**0
                      CONTENTS, READONLY, DEBUGGING
      9 .debug_frame  000002e0  00000000  00000000  000055b4  2**2
                      CONTENTS, READONLY, DEBUGGING
     10 .debug_str    00000649  00000000  00000000  00005894  2**0
                      CONTENTS, READONLY, DEBUGGING
     11 .debug_loc    00000619  00000000  00000000  00005edd  2**0
                      CONTENTS, READONLY, DEBUGGING
     12 .debug_ranges 000000c0  00000000  00000000  000064f6  2**0
                      CONTENTS, READONLY, DEBUGGING
    
    Disassembly of section .text:
    
    00000000 <__vectors>:
           0:    0c 94 34 00     jmp    0x68    ; 0x68 <__ctors_end>
           4:    0c 94 51 00     jmp    0xa2    ; 0xa2 <__bad_interrupt>
           8:    0c 94 51 00     jmp    0xa2    ; 0xa2 <__bad_interrupt>
           c:    0c 94 51 00     jmp    0xa2    ; 0xa2 <__bad_interrupt>
          10:    0c 94 51 00     jmp    0xa2    ; 0xa2 <__bad_interrupt>
          14:    0c 94 51 00     jmp    0xa2    ; 0xa2 <__bad_interrupt>
          18:    0c 94 51 00     jmp    0xa2    ; 0xa2 <__bad_interrupt>
          1c:    0c 94 6e 02     jmp    0x4dc    ; 0x4dc <__vector_7>
          20:    0c 94 a0 02     jmp    0x540    ; 0x540 <__vector_8>
          24:    0c 94 51 00     jmp    0xa2    ; 0xa2 <__bad_interrupt>
          28:    0c 94 51 00     jmp    0xa2    ; 0xa2 <__bad_interrupt>
          2c:    0c 94 f4 01     jmp    0x3e8    ; 0x3e8 <__vector_11>
          30:    0c 94 2c 02     jmp    0x458    ; 0x458 <__vector_12>
          34:    0c 94 51 00     jmp    0xa2    ; 0xa2 <__bad_interrupt>
          38:    0c 94 51 00     jmp    0xa2    ; 0xa2 <__bad_interrupt>
          3c:    0c 94 51 00     jmp    0xa2    ; 0xa2 <__bad_interrupt>
          40:    0c 94 51 00     jmp    0xa2    ; 0xa2 <__bad_interrupt>
          44:    0c 94 51 00     jmp    0xa2    ; 0xa2 <__bad_interrupt>
          48:    0c 94 90 00     jmp    0x120    ; 0x120 <__vector_18>
          4c:    0c 94 bc 00     jmp    0x178    ; 0x178 <__vector_19>
          50:    0c 94 51 00     jmp    0xa2    ; 0xa2 <__bad_interrupt>
          54:    0c 94 5b 06     jmp    0xcb6    ; 0xcb6 <__vector_21>
          58:    0c 94 51 00     jmp    0xa2    ; 0xa2 <__bad_interrupt>
          5c:    0c 94 51 00     jmp    0xa2    ; 0xa2 <__bad_interrupt>
          60:    0c 94 51 00     jmp    0xa2    ; 0xa2 <__bad_interrupt>
          64:    0c 94 51 00     jmp    0xa2    ; 0xa2 <__bad_interrupt>
    
    ..
    00000120 <__vector_18>:
    // ============================================================================== =
    
    
    // ============================================================================== =
    ISR( USART0_RX_vect )
    {
         120:    1f 92           push    r1
         122:    0f 92           push    r0
         124:    0f b6           in    r0, 0x3f    ; 63
         126:    0f 92           push    r0
         128:    11 24           eor    r1, r1
         12a:    8f 93           push    r24
         12c:    9f 93           push    r25
         12e:    ef 93           push    r30
         130:    ff 93           push    r31
      u8 i = rx_in;
         132:    90 91 af 04     lds    r25, 0x04AF
    
      ROLLOVER( i, RX0_SIZE );
         136:    9f 5f           subi    r25, 0xFF    ; 255
         138:    90 34           cpi    r25, 0x40    ; 64
         13a:    08 f0           brcs    .+2          ; 0x13e <__vector_18+0x1e>
         13c:    90 e0           ldi    r25, 0x00    ; 0
      if( i == rx_out ){            // buffer overflow
         13e:    80 91 b0 04     lds    r24, 0x04B0
         142:    98 17           cp    r25, r24
         144:    31 f4           brne    .+12         ; 0x152 <__vector_18+0x32>
        URX0_IEN = 0;            // disable RX interrupt
         146:    80 91 c1 00     lds    r24, 0x00C1
         14a:    8f 77           andi    r24, 0x7F    ; 127
         14c:    80 93 c1 00     sts    0x00C1, r24
         150:    0a c0           rjmp    .+20         ; 0x166 <__vector_18+0x46>
        return;
      }
      rx_buff[rx_in] = UDR0;
         152:    e0 91 af 04     lds    r30, 0x04AF
         156:    f0 e0           ldi    r31, 0x00    ; 0
         158:    80 91 c6 00     lds    r24, 0x00C6
         15c:    e1 59           subi    r30, 0x91    ; 145
         15e:    fb 4f           sbci    r31, 0xFB    ; 251
         160:    80 83           st    Z, r24
      rx_in = i;
         162:    90 93 af 04     sts    0x04AF, r25
    }
         166:    ff 91           pop    r31
         168:    ef 91           pop    r30
         16a:    9f 91           pop    r25
         16c:    8f 91           pop    r24
         16e:    0f 90           pop    r0
         170:    0f be           out    0x3f, r0    ; 63
         172:    0f 90           pop    r0
         174:    1f 90           pop    r1
         176:    18 95           reti
    
    00000178 <__vector_19>:
    // ============================================================================= =
    ..
    ..
    // ============================================================================= =
    ..
    000019c8 <_exit>:
        19c8:    f8 94           cli
    
    000019ca <__stop_program>:
        19ca:    ff cf           rjmp    .-2          ; 0x19ca <__stop_program>
    Anfangs allerlei Organisation. Beachte die beispielhafte ISR( USART0_RX_vect ), besonders die pushs am Beginn und die pops am Ende der ISR. Die sind blanker Overhead, weil die ISR erstmal alle von ihr benutzten (manchmal nicht benutzte) Register am Stack sichern - pushen - muss. Weil sie ja zu einem beliebigen Zeitpunkt/Codeabschnitt bedient wird, an dem "niemand" weiß, was gerade in den zentralen Registern der ALU steckt. Am Ende des eigentlich "sinnvollen" Codes der ISR werden die entsprechend der ISR-Startsituation gesicherten Register wieder zurückgeladen - gepopt. Zweimal je sieben pushs bzw. pops sind schon mal achtundzwanzig Maschinenzyklen - die aufgewendet werden müssen, damit alles seine Richtigkeit hat (im beispielhaften Controller pro push oder pull jeweils 2 Zyklen).

    Dieser Overhead kostet Zeit wie jeder andere Prozessor-Codeschritt. Und so simpel wie eben von mir vorgerechnet kannst Du nun Routine für Routine durchgehen und die einzelnen Zeiten rauslesen (siehe Datenblatt, Instruction Set Summary, hier aus dem Atmel-42735B-ATmega328/P_Datasheet_Complete-11/2016). Dies gilt aber nur dann, wenn nicht innerhalb Deines betrachteten Codes eine - oder mehrere - ISR ausgelöst werden und abgearbeitet werden müssen . . . es sei denn, es geht um einen Abschnitt der z.B. mit cli (); (=Global Interrupt Disable) anfängt und mit sei (); (= Global Interrupt Enable) endet ODER wenn Interrupts z.B. noch garnicht erlaubt sind.

    Klar ?
    Geändert von oberallgeier (27.06.2017 um 00:27 Uhr) Grund: Absolute Adresse der ISR.. eingetragen - nur der Ordnung halber
    Ciao sagt der JoeamBerg

Seite 3 von 3 ErsteErste 123

Ähnliche Themen

  1. Immer wieder dieses VISTA
    Von Naturp im Forum PC-, Pocket PC, Tablet PC, Smartphone oder Notebook
    Antworten: 12
    Letzter Beitrag: 16.03.2010, 20:28
  2. immer wieder pwm tiny45
    Von meldano im Forum Basic-Programmierung (Bascom-Compiler)
    Antworten: 1
    Letzter Beitrag: 23.04.2007, 03:23
  3. Immer wieder - Labornetzteil...
    Von Vaterssohn im Forum Elektronik
    Antworten: 2
    Letzter Beitrag: 15.11.2006, 22:47
  4. Immer wieder....I2C Bus
    Von JensB im Forum Elektronik
    Antworten: 1
    Letzter Beitrag: 16.09.2004, 17:26
  5. Immer wieder LCD Probleme
    Von Bruce im Forum Robby CCRP5
    Antworten: 7
    Letzter Beitrag: 03.08.2004, 13:26

Stichworte

Berechtigungen

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

LiFePO4 Speicher Test