I/O Steuerung 1us

[Sigi M. (sigim)]

Hallo,

ich habe ein Problem bei der I/O-Steuerung meines SAM3S-Controllers.
Ich möchte einen Pin der als output konfiguriert ist auf input schalten 
und dann wieder auf output, im Prinzip eine Unterbrechung simulieren.
Die funktioniert auch wunderbar nur mit der Zeit passt etwas nicht.
Ich hätte gerne, dass das aus- und wieder einschalten innerhalb von 
einer Mikrosekunde erledigt wird. Es dauert aber ca. 4us. Auch bei 
anderen Zeiten, hab ich einen Offset von ca. 3us. Hat da jemand eine 
Idee woran das liegen könnte und wie man das beheben kann?

Den sysclk hab ich auf 12MHz RC Oszillator konfiguriert und meine 
delay-Funktion besteht im Prinzip aus lauter nop's.

Hoffe mir kann jemand bei diesem Problem helfen oder Hinweise geben wo 
ich denn nachschauen könnte.

Gruß Sigi

[Floh (Gast)]

Sigi Maier schrieb:
> SAM3S-Controllers

Schau mal ins Datenblatt wie hoch die I/O-Clock ist.

[AVR (Gast)]

Und wir sollen jetzt raten was da schief läuft? Zeig uns doch etwas 
Code.

Sigi Maier schrieb:
> Den sysclk hab ich auf 12MHz RC Oszillator konfiguriert und meine
> delay-Funktion besteht im Prinzip aus lauter nop's.
Hast du den Overhead, der durch die Schleife entsteht (Vergleich und 
Sprungbefehl) mit in deine Überlegung einberechnet?

[Sigi M. (sigim)]

pio_set_output(PIOC, PIO_PC16, HIGH, DISABLE, ENABLE);
pio_set_input(PIOC, PIO_PC16, PIO_DEFAULT);
delay(1);
pio_set_output(PIOC, PIO_PC16, HIGH, DISABLE, ENABLE);

die delay-Funktion

__attribute__( ( always_inline) ) static __INLINGE void _DELAY_1US(void)

{
__ASM volatile ("nop");
__ASM volatile ("nop");
__ASM volatile ("nop");
__ASM volatile ("nop");
__ASM volatile ("nop");
__ASM volatile ("nop");
__ASM volatile ("nop");
__ASM volatile ("nop");
__ASM volatile ("nop");
__ASM volatile ("nop");
__ASM volatile ("nop");
__ASM volatile ("nop");
__ASM volatile ("nop");
__ASM volatile ("nop");
__ASM volatile ("nop");
__ASM volatile ("nop");
__ASM volatile ("nop");
__ASM volatile ("nop");
__ASM volatile ("nop");
__ASM volatile ("nop");
__ASM volatile ("nop");
__ASM volatile ("nop");
__ASM volatile ("nop");
__ASM volatile ("nop");
__ASM volatile ("nop");
__ASM volatile ("nop");
__ASM volatile ("nop");
__ASM volatile ("nop");
__ASM volatile ("nop");
__ASM volatile ("nop");
__ASM volatile ("nop");
__ASM volatile ("nop");
__ASM volatile ("nop");
__ASM volatile ("nop");
__ASM volatile ("nop");
__ASM volatile ("nop");
__ASM volatile ("nop");
__ASM volatile ("nop");
__ASM volatile ("nop");
__ASM volatile ("nop");
__ASM volatile ("nop");
__ASM volatile ("nop");
__ASM volatile ("nop");
__ASM volatile ("nop");
__ASM volatile ("nop");
__ASM volatile ("nop");
__ASM volatile ("nop");
__ASM volatile ("nop");
__ASM volatile ("nop");

}

der Aufruf davon geschieht in einer for-Schleife

static void delay(unsigned int DiscTime)
{
    for ( int i = 0; i < DiscTime; i++)
   {
     __DELAY_1US();
   }
}

[(prx) A. K. (prx)]

Wie kommst du auf die Idee, dass diese zig NOPs bei 12MHz Takt 1µs 
brauchen?

[Sigi M. (sigim)]

1/12MHz gibt mir doch wie lang ein Befehl dauert und dann 1us/Ergebnis 
gibt mir Anzahl der nop's die ich brauch, oder nicht?

[Floh (Gast)]

Lass mal die Nops / Delays weg und schau, wie schnell er überhaupt kann 
:-)

[(prx) A. K. (prx)]

Sigi Maier schrieb:
> 1/12MHz gibt mir doch wie lang ein Befehl dauert und dann 1us/Ergebnis
> gibt mir Anzahl der nop's die ich brauch, oder nicht?

Wenn ein NOP einen Takt benötigt und eine Mikrosekunde aus 12 Takten 
besteht, wieviel NOPs benötigt man dann für eine Mikrosekunde?

[ ] 24, weil Befehl 16 Bit gross, Prozessor hat ja 32 Bits,
[ ] 12, weil ich so blöd frag,
[ ] keine Ahnung, Rechnen ist nicht so mein Ding.

[Sigi M. (sigim)]

Ja kann, dass ich da paar zuviele zusammen kopiert habe, da ich mit dem 
Rechner mit dem ich arbeite keinen Internet Zugang habe. Die Sache ist, 
dass ich diesen 3us offset auch bei z.B. nur einem nop oder auch bei 10 
habe...

[Walter S. (avatar)]

Sigi Maier schrieb:
> delay(1);
> die delay-Funktion__attribute__( ( always_inline) ) static __INLINGE void 
_DELAY_1US(void)

kannst du uns vielleicht auch die funktion delay() zeigen?

[Thomas E. (thomase)]

Sigi Maier schrieb:
> Auch bei
> anderen Zeiten, hab ich einen Offset von ca. 3us. Hat da jemand eine
> Idee woran das liegen könnte und wie man das beheben kann?
Weil dein Funktionsaufruf und vor allen Dingen die Schleife diese Zeit 
benötigen und dein Compiler das nicht vollständig optimiert.
Bei solchen Taktzählverzögerungen gehört alles dazu: push-pop, Schleife 
initialisieren, Schleifenzähler inkrementieren, Schleifenendebedingung 
prüfen etc..
Und das Hin- und Herschalten des Ports kostet Zeit. Da werden auch 
wieder Funktionen aufgerufen.
Eine µs in Software bei 12MHz bekommst du nur mit Inline-Assembler hin.

setbit
passende Anzahl nops
clrbit

Keine Ahnung, wie die Befehle heissen. Such dir das selber raus.

mfg.

[Marc L. (dasbaum)]

Ich kenne mich zwar mit den hier verwendeten Mikrocontrollern nicht aus, 
allerdings wäre deine Berechnung für einen PIC falsch... und ich denke 
dass der Unterschied von Controller zu Controller bezüglich der 
Rechnungsart nicht sonderlich ändert.

1/12 MHz = 0.000000083 s

Das bedeutet allerdings nicht, dass er Controller alle 83nS ein NOP 
ausführen kann. Bei einem PIC wären es 4*83nS.
Falls das bei diesem / generell bei anderen Controllern anders ist, wäre 
ich froh wenn da jemand etwas dazu sagen kann, da es mich gerade selbst 
interessiert.
Nochmal: Ich behaupte NICHT dass jeder Controller so funktioniert, ich 
weiss es lediglich von den PIC's, klärt mich auf falls es hier anders 
ist, danke.

Nebenbei, unendlich viele NOP's aneinander zu Reihen ist nicht 
sonderlich schlau. Benutz lieber eine Schleife, in der du X-Mal ein NOP 
aufrufst.

Leider kann ich nicht sonderlich gut C Programmieren, aber das geht 100 
% einfacher.

Da ich bisher nur Assembler kann, poste ich mal. Evtl. hilft dir sowas:

movlw d'3'
movwf Variable

1us
decfsz Variable ; Dekrementiere Variable (1 Prog. Zyklus - 4 Taktschläge - 0.000000332s)
goto 1us
... weiter mit Code

[(prx) A. K. (prx)]

Marc Liechti schrieb:
> Falls das bei diesem / generell bei anderen Controllern anders ist, wäre
> ich froh wenn da jemand etwas dazu sagen kann, da es mich gerade selbst
> interessiert.

Das ist je nach Prozessor anders und bewegt sich so zwischen ARM, AVR, 
PIC24 mit 1 Takt und 8051ern (bei altem Core) mit 12 Takten pro NOP.

[Marc L. (dasbaum)]

A. K. schrieb:
> Das ist je nach Prozessor anders und bewegt sich so zwischen ARM, AVR,
>
> PIC24 mit 1 Takt und 8051ern (bei altem Core) mit 12 Takten pro NOP.

Danke für die Antwort ;) und wieder was dazu gelernt.

[MCUA (Gast)]

>oder Hinweise geben wo ich denn nachschauen könnte.
Der kürzeste Befehl hängt immer vom Masch.Takt ab, nicht vom OscTakt 
(steht im DB)  Masch.Takt = OscTakt. / x
z.B ist x bei Pics<=18 4; bei PIC24 2; bei '51 (norm) 12; bei HC11 4; 
bei AVR, EZ8, RL78, STM8 1.

[Bronco (Gast)]

Schau Dir den Assembler-Code an (z.B. im Debugger) und zähle die 
Befehle.
Irgendwoher muß Deine Laufzeit ja kommen.

[Alexander V. (avogra)]

Also wenns hier auf genaue Einschaltzeiten oder Verzögerungen ankommt, 
dann würde ich das überhaupt nicht in Software machen, sondern einen 
Timer mit Output-Compare benutzen.
Damit kannste dann deinen Pulse auf den Prozessortakt genau vorgeben, 
ohne viel Spaghate machen zu müssen.

[Walter S. (avatar)]

Walter S. schrieb:
> Sigi Maier schrieb:
>> delay(1);
>> die delay-Funktion__attribute__( ( always_inline) ) static __INLINGE void
> _DELAY_1US(void)
>
> kannst du uns vielleicht auch die funktion delay() zeigen?

liest hier eigentlich jemand mit?
Damit wollte ich den Hinweis geben dass delay aufgerufen wird und nicht 
die dargestellte Funktion DELAY_1US

[Ziegenpeter (Gast)]

Walter S. schrieb:
> Damit wollte ich den Hinweis geben dass delay aufgerufen wird und nicht
> die dargestellte Funktion DELAY_1US

Die ist unterhalb der ganzen nops. Vor lauter nops übersieht man die 
schnell ;)

[Sigi M. (sigim)]

Sooo...also erst einmal danke an alle, aber das Problem lag ganz wo 
anders.
Es ist ein bisschen peinlich, aber jetzt wo ich den Optimizer wieder 
aktiviert habe komm ich mit einem nop auf 820 ns...

[Stefan (Gast)]

Mal angenommen, delay(1) würde wirklich GENAU 1µs warten, dann hast Du 
immer noch den Aufruf der nachfolgenden Funktion und die Dauer dieser 
Funktion zusätzlich. Insofern kann dein Ausgangs-Impuls zwangsläufig 
niemals exakt 1ms dauern.

Angenommen, dein Mikrocontroller braucht nur 1 Takt pro Befehl, dann 
bezweifle ich, dass Du ohne Assembler auch nur ansatzweise an die 
gewünschten 1µS heran kommen wirst, denn das alles müsste mit maximal 12 
Assembler Befehlen realisiert werden. Eher weniger, weil einige Befehle 
sicher mehrere Takte benötigen. Deine gemessenen 3µS liegen in dem 
Bereich, den ich erwarte.

Compiliere das Programm und schau dann in's Assembler Listing. Dann 
kannst Du die Ausführzeiten der einzelnen Befehle zusammen addieren.

Lösung wird wohl der Einsatz eines Hardware-Timers sein.

[Sigi M. (sigim)]

Hallo zusammen,

also wie schon gesagt es funktioniert bereits und die Zeiten sind auch 
relativ in Ordnung, da dann noch die Laufzeit auf der  richtigen 
Hardware beachtet werden muss. Im Anhang sind die eingegebenen und 
gemessenen Zeiten mit einem nop in der Schleife.
Jetzt meine Frage: Kann mir jemand vielleicht erklären warum da so 
unterschiedliche Zeiten rauskommen und nicht ungefähr im gleichen 
Verhältnis?
Also, dass wenn ich 10us als Zeit eingebe es auch auch das 10-fache von 
1us rauskommt. Ich habe zwar schon dem Atmel-Support geschrieben und auf 
einer Messe mit einem Mitarbeiter geredet, aber naja...nach fünf Emails 
und 3 erklären hatte ich dann keine Lust mehr.
Ich hoffe jemand kann mich da aufklären woran es liegt, da ich echt 
keine Ahnung habe woher diese Unterschiede kommen.

[Ralph (Gast)]

So etwas macht man nicht mit Warteschleifen, das ist NIEMALS genau.
Falls du das wirklich mit einer Schleife machen willst, dann darf dein 
µC NICHTS andres machen als genau diese eine Schleife, und schon mal 
glatt gar keine Interrupts.


Dafür gibt es Hardwaremodule auf dem Chip, die können das sehr gut.
Nennen sich Timer.

[Andreas M. (amesser)]

Sigi Maier schrieb:
> also wie schon gesagt es funktioniert bereits und die Zeiten sind auch
> relativ in Ordnung, da dann noch die Laufzeit auf der  richtigen
> Hardware beachtet werden muss. Im Anhang sind die eingegebenen und

Lol, das ist jetzt nicht dein Ernst oder?

> gemessenen Zeiten mit einem nop in der Schleife.
> Jetzt meine Frage: Kann mir jemand vielleicht erklären warum da so
> unterschiedliche Zeiten rauskommen und nicht ungefähr im gleichen
> Verhältnis?
> Also, dass wenn ich 10us als Zeit eingebe es auch auch das 10-fache von
> 1us rauskommt. Ich habe zwar schon dem Atmel-Support geschrieben und auf
> einer Messe mit einem Mitarbeiter geredet, aber naja...nach fünf Emails
> und 3 erklären hatte ich dann keine Lust mehr.
> Ich hoffe jemand kann mich da aufklären woran es liegt, da ich echt
> keine Ahnung habe woher diese Unterschiede kommen.

Wenn Du einfach mal das gemacht hättest was hier schon zwei mal 
geschrieben wurde, dann müsstest Du es eigentlich wissen. Schaue Dir den 
erzeugten Assembler-Code an und rechne Dir die genaue Laufzeit selbst 
aus. Oder denkst du etwa:

- das der Aufruf der delay Funktion in 0-Zeit stattfindet?
- das die Schleife an sich ebenfalls ohne eine einzige Anweisung
  auskommt?

Wenn man schon solche Software-Verzögerungsschleifen benutzt, dann 
kodiert man immer direkt in Assembler für die jeweilige Platform. Nur 
dann kann man eine halbwegs vernünftige Vorhersage für die Laufzeit 
machen. Die richtige Lösung mit dem Timer wurde Dir auch schon genannt.

Hast du schon mal darüber nachgedacht, dass Dir:
- jeder Interrupt dein schön zurechtgebasteltes Timing zerschießt
- Der Flash-Speicher nicht unbedingt mit vollem CPU-Takt Läuft (In
  deinem Fall aber schon)