CPU wird langsamer, Fusebits falsch ???

[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.

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

[modtronic]

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