- LiFePO4 Speicher Test         
Seite 2 von 2 ErsteErste 12
Ergebnis 11 bis 16 von 16

Thema: CPU wird langsamer, Fusebits falsch ???

  1. #11
    Benutzer Stammmitglied Avatar von modtronic
    Registriert seit
    14.05.2011
    Ort
    Hagen
    Alter
    46
    Beiträge
    68
    Anzeige

    LiFePo4 Akku selber bauen - Video
    Zitat Zitat von 021aet04 Beitrag anzeigen
    Hast du schon versucht das Ergebnis vorher zusammenzusetzten und dieses dann gesamt an die Funktion zu übergeben?
    Also in etwa so :
    Code:
    unsigned char ergebnis = data1 + data2 + ... + data8
    I2c_start
    ...
    ...
    ...
    i2c_write(ergebnis)
    I2c_stop
    Was du auch testen kannst wäre einen fixen wert zu übergeben (und schauen ob sich etwas verbessert)

    Ein weiterer test wäre nicht mit addition sondern mit schieben (ergebnis = (data1<<0) | (data1<<1) | ... | (data8<<7) ).
    In dataX steht dann eine 0 oder 1 je nachdem ob der Eingang low oder high ist.

    MfG Hannes
    Moin

    Das mit dem ergebnis vorher hatte ich auch schon. bewirkt keine änderung.
    Was meinst du genau mit schieben ???

    grüsse
    Patrick

    - - - Aktualisiert - - -

    Zitat Zitat von shedepe Beitrag anzeigen
    Kann die Library denn überhaupt den Hardware I2C des Atmegas nutzen. Wenn ich danach google, dann sieht das stark danach aus als ob die lib Software I2C auf jedem beliebigen Pin machen kann. Da muss man sich natürlich nicht wundern wenn das entsprechend langsam ist.

    Als alternative kann ich die lib von Peter Fleury empfehlen: http://homepage.hispeed.ch/peterfleu...-software.html
    Geht dann natürlich nur auf den Hardware I2C Pins.
    Moin

    wie gesagt, ich habe vieles selber erlernt und so geht es ja auch.
    ob und was die interne lib kann, weiss ich nicht. ich nutze codevision

    interessant wäre, mir vllt mit einem beispiel zu zeigen was du genau meinst.
    leider habe ich das so nicht ganz verstanden...

    Grüsse
    Pat

    - - - Aktualisiert - - -

    gibt es deine keine lib für den mcp23017 ??
    habe nur was für den arduino gefunden

  2. #12
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    07.03.2011
    Beiträge
    1.899
    Zitat Zitat von modtronic Beitrag anzeigen
    i2c_start();
    i2c_write(adresse des mcp)
    i2c_write(0x14) // zb Port A
    i2c_write( data1 + data2+ data4 + data8+ data16 + data32 + data64 + data128 );
    i2c_stop();
    Die achtfache Addition dürfte bei einem ATMEGA mit 16MHz so rund eine µs dauern. Wenn das versehentlich 16-Bit Variable sind, vielleicht auch zwei. Ist also unerheblich. Die Übertragung mit 100kHz I2C dauert etwa 300µs (3*9 Takte plus Start und Stop), und das unabhängig davon, ob die 100kHz in SW oder in HW gemacht werden. Um das Ganze etwas zu beschleunigen, kann man den "Sequential mode" Mode verwenden (Datenblatt 3.2.1). Da kann man alle 16 Bit in einem I2C Transfer schreiben.

    Aber selbst wenn man das zweimal macht, dauert das weniger als eine Millisekunde. Das merkt man nicht, es muß also etwas anderes sein.

    MfG Klebwax
    Strom fließt auch durch krumme Drähte !

  3. #13
    Erfahrener Benutzer Robotik Visionär Avatar von 021aet04
    Registriert seit
    17.01.2005
    Ort
    Niklasdorf
    Alter
    36
    Beiträge
    5.055
    Was schieben ist bzw wie man schiebt, steht dort. Als Beispiel:
    Ergebnis = (1<<2) | (1<<3);
    (1<<2) ist ein Schiebebefehl => es wird eine 1 geladen und um 2 stellen nach links geschoben => es steht dann beim 3ten Bit im Ergebnis eine 1

    Das Zeichen | bedeutet bitweises Oder

    Beim oberen Beispiel hast du dann im Bit 2 und Bit 3 eine 1 stehen.

    Ich würde mir die Grundlagen der Digitaltechnik anschauen.

    MfG Hannes

  4. #14
    Benutzer Stammmitglied Avatar von modtronic
    Registriert seit
    14.05.2011
    Ort
    Hagen
    Alter
    46
    Beiträge
    68
    Zitat Zitat von Klebwax Beitrag anzeigen
    Die achtfache Addition dürfte bei einem ATMEGA mit 16MHz so rund eine µs dauern. Wenn das versehentlich 16-Bit Variable sind, vielleicht auch zwei. Ist also unerheblich. Die Übertragung mit 100kHz I2C dauert etwa 300µs (3*9 Takte plus Start und Stop), und das unabhängig davon, ob die 100kHz in SW oder in HW gemacht werden. Um das Ganze etwas zu beschleunigen, kann man den "Sequential mode" Mode verwenden (Datenblatt 3.2.1). Da kann man alle 16 Bit in einem I2C Transfer schreiben.

    Aber selbst wenn man das zweimal macht, dauert das weniger als eine Millisekunde. Das merkt man nicht, es muß also etwas anderes sein.

    MfG Klebwax
    Tag

    Das es an der Kommunikation des Busses liegt hatte ich auch nicht gedacht
    sondern das es Programmtechnisch ist.
    habe jetzt sämtliche Variablen von int auf unsigned char geändert, was die Programmlänge reduziert.

    Ich bin zwar der Meinung das die CPU etwes schneller ist, aber wenn auch nicht wirklich viel.

    Gut

    Dann was mache ich noch im Programm:
    Der Eingabebus arbeitet aus einer anderen oder älteren Entwicklung als Paralleler 16 Bit Bus.
    Hier frage ich 16 Eingänge ab und speichere diese in Variablen ab.
    Beispiel E1-16 -> vin1....vin16 die ich später abfragen kann.

    Hier zähle ich per Takt über einen interen Timer einen Zähler (counter ++) immer hoch.
    Pro Eingang mache ich nun folgendes

    if (counter == 1 && in1 == 1)
    {
    vin1 = 1
    }

    if (counter == 1 && in1 == 0)
    {
    vin1 = 0
    }

    das mache ich natürlich 16x pro counterstellung..hier muss ich aber sagen wenn nur der eingangsbus programmiert ist,
    die cpu sehr schnell ist.
    erst wenn der I2C bus ins spiel kommt, also von der software wird er langsamer

    sind vllt die if anweisungen das problem ?

    vllt kann man diese routinen auch anders machen, arrays vllt ???

    grüsse
    Patrick

    - - - Aktualisiert - - -

    Zitat Zitat von 021aet04 Beitrag anzeigen
    Was schieben ist bzw wie man schiebt, steht dort. Als Beispiel:
    Ergebnis = (1<<2) | (1<<3);
    (1<<2) ist ein Schiebebefehl => es wird eine 1 geladen und um 2 stellen nach links geschoben => es steht dann beim 3ten Bit im Ergebnis eine 1

    Das Zeichen | bedeutet bitweises Oder

    Beim oberen Beispiel hast du dann im Bit 2 und Bit 3 eine 1 stehen.

    Ich würde mir die Grundlagen der Digitaltechnik anschauen.

    MfG Hannes
    Mahlzeit

    ich muss sagen ich bin beruflich SPS Programmierer, kenne als Schiebeoperationen.
    das Problem ist ich habe mit Codevision angefangen zu programmieren über einen kollegen und mir vieles selber angeignet.
    Daher denke ich auch, ist das Programmieren wie ich es mache nciht immer optimal und vermutlich auch zu kompliziert.


    Aber ich weiss was du meinst, könnte man versuchen

  5. #15
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    07.03.2011
    Beiträge
    1.899
    Zitat Zitat von modtronic Beitrag anzeigen
    Tag
    Das es an der Kommunikation des Busses liegt hatte ich auch nicht gedacht sondern das es Programmtechnisch ist.
    habe jetzt sämtliche Variablen von int auf unsigned char geändert, was die Programmlänge reduziert.
    Dein Prozessor wird im Datenblatt mit knapp 16 Mips beschrieben. Das wären 16 Millionen Additionen pro Sekunde. Deine 8 gehen da als Messfehler durch.

    Dann was mache ich noch im Programm:
    Der Eingabebus arbeitet aus einer anderen oder älteren Entwicklung als Paralleler 16 Bit Bus.
    Hier frage ich 16 Eingänge ab und speichere diese in Variablen ab.
    Beispiel E1-16 -> vin1....vin16 die ich später abfragen kann.

    Hier zähle ich per Takt über einen interen Timer einen Zähler (counter ++) immer hoch.
    Pro Eingang mache ich nun folgendes

    if (counter == 1 && in1 == 1)
    {
    vin1 = 1
    }

    if (counter == 1 && in1 == 0)
    {
    vin1 = 0
    }

    das mache ich natürlich 16x pro counterstellung..hier muss ich aber sagen wenn nur der eingangsbus programmiert ist,
    die cpu sehr schnell ist.
    erst wenn der I2C bus ins spiel kommt, also von der software wird er langsamer

    sind vllt die if anweisungen das problem ?

    vllt kann man diese routinen auch anders machen, arrays vllt ???
    Mit deiner Beschreibung kann ich nicht wirklich etwas anfangen.

    Ich frag daher mal anders: wie oft machst du das mit dem MCP?

    MfG Klebwax
    Strom fließt auch durch krumme Drähte !

  6. #16
    Benutzer Stammmitglied Avatar von modtronic
    Registriert seit
    14.05.2011
    Ort
    Hagen
    Alter
    46
    Beiträge
    68
    Zitat Zitat von Klebwax Beitrag anzeigen
    Dein Prozessor wird im Datenblatt mit knapp 16 Mips beschrieben. Das wären 16 Millionen Additionen pro Sekunde. Deine 8 gehen da als Messfehler durch.


    Mit deiner Beschreibung kann ich nicht wirklich etwas anfangen.

    Ich frag daher mal anders: wie oft machst du das mit dem MCP?

    MfG Klebwax
    Hallo

    Zum eine, ich habe an der Problembehafteten CPU 5 MCP23017 im Einsatz, daher wird die Routine 10 mal benötigt.
    Aber:
    Ich habe das Problem gefunden. Das Problem kommt von der Takterzeugung welcher intern im Timer des MC als Overflow Interrupt Routine gemacht wird.

    Ich habe mal die Durchlaufzeit des Programmteils gemessen und war irgendwo bei 1ms..
    Daher kam mir der Gedanke das der Timer welcher ja auch Zeit braucht zum arbeiten vermutlich immer wieder unterbrochen wird wenn das Programm durchlaufen wird.
    Vermutlich ist es daher auch so gewesen..Man sieht das auch dort an der RUN Led welche vom Timer zum blinken gebracht wird, da diese doch etwas unregelmässig blinkt wenn man sie beobachtet.
    Habe hier dann mal ein Oskar angeschlossen und man sieht genau, im Verhältnis mit der Abfrage der Eingänge wie der Timer arbeitet.

    Habe das jetzt anders Programmiert..und zack...geht !

    Hier sieht man allerdings auch, wenn man sich vieles selber beibringt, das es viele Wege nach Rom gibt.

    Frage ist, wäre es interessant mein Projekt mal Vorzustellen da es hier ja eigentlich um Robotik geht ?

    Grüsse
    Patrick

Seite 2 von 2 ErsteErste 12

Ähnliche Themen

  1. ATMEGA16 nicht mehr erreichbar. Fusebits falsch gesetzt?
    Von ricola im Forum AVR Hardwarethemen
    Antworten: 12
    Letzter Beitrag: 25.12.2013, 19:46
  2. Zweiter Mikrocontroller als Taktgeber - Fusebits falsch gestellt -.-
    Von Lif im Forum Microcontroller allgemeine Fragen/Andere Microcontroller
    Antworten: 4
    Letzter Beitrag: 10.12.2012, 21:04
  3. [ERLEDIGT] Stopwatch wird ignoriert/ falsch interpretiert
    Von Mac80 im Forum Robby RP6
    Antworten: 3
    Letzter Beitrag: 09.05.2012, 14:31
  4. Fusebits werden falsch ausgelesen u. lassen sich nich ändern
    Von memi im Forum Basic-Programmierung (Bascom-Compiler)
    Antworten: 5
    Letzter Beitrag: 10.05.2006, 16:27
  5. Mega32 Fusebits falsch gesetzt
    Von klucky im Forum AVR Hardwarethemen
    Antworten: 12
    Letzter Beitrag: 28.01.2006, 23:49

Berechtigungen

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

LiFePO4 Speicher Test