1µS mit 1MHz erzeugen

rechne dir doch einmal aus wie "lang" ein einzelner takt bei 1MHz ist..

Holger L. schrieb:
> Ich wollte mal fragen ob jemand einen kleinen Denkanstoß hat, es geht
> darum auf dem momentanen "Testsystem" (Atmega8 mit 1 MHz) einen 1µS
> Zähler zu erzeugen.

 LOL.

> Der erste Ansatz bestand aus einer Softwarelösung die leider bei 2 MHz
> aussteigt.

 Hahaha.

 Du bist aber ein lustiger Kerl.

> Holger L. schrieb:
> einen 1µS Zähler zu erzeugen.
Hallo,
die Aufgabenstellung ist Nonsense.
S ist die Einheit für Siemens (Leitfähigkeit)
1µS = 1 MOhm! Aber was hat das mit einem Zähler zu tun?
Gruß Öletronika

Marc Vesely schrieb:
> Du bist aber ein lustiger Kerl.

Ja.
Es war mit der 1µS nur ein wenig unglücklich ausgedrückt.

Andi ... schrieb:
> rechne dir doch einmal aus wie "lang" ein einzelner takt bei 1MHz ist..

Das tat ich. 1µS.
Die Softwarelösung besteht eigentlich auch nur aus einer Methode von der 
ich weiß das sie 7 Instruktionen benötigt (+ ein paar zum Aufrufen).

Aber irgend eine Lösung muß es dort doch geben ?

P.S. : Den ganzen Beitrag lesen nicht nur die erste Zeile.

Holger L. schrieb:
> Aber irgend eine Lösung muß es dort doch geben ?

Wenn deine Software mehr tun muss, als es der Takt momentan zulässt: 
Takt erhöhen. Vielleicht könnte man auch die UART irgendwie verwursten, 
sodass man nicht gleich 10 MHz braucht. Aber 1 MHz One Wire geht bei 1 
Mhz CPU-Takt absolut garnicht.


Jonathan

Gerade noch mal alles gelesen - da kam nichts neues raus :-)

Holger L. schrieb:
> Aber irgend eine Lösung muß es dort doch geben ?

 Mit 1MHz bestimmt nicht. Dass dein Timer mit 1MHz arbeiten kann,
 nützt dir nichts, da dir nicht mal Zeit bleibt, die Register
 auszulesen, geschweige den etwas damit anzufangen.
 Sprung und Rückkehr aus ISR benötigen mindestens 7 Taktzyklen,
 also 7us bei 1MHz, Register auslesen 2-4 Takte, Pin oder Flag setzen
 oder was du sonst tun willst noch 1-3 Takte... - Sinnlos.
 So kurze Delays macht man in Assembler und mit Schleifen, wobei
 Delays die kürzer als etwa 4-5us sind, mit NOPs erzeugt werden.

Holger L. schrieb:
> Das Ziel ist später einen DS18S20 (One Wire) mit 1.2 Mhz
Wie stellst du dir das vor wenn das One-Wire Protokoll min. 61µs für ein 
bit vorsieht?

Siehe Seite 14:
http://datasheets.maximintegrated.com/en/ds/DS18S20.pdf

Holger L. schrieb:
> P.S. : Den ganzen Beitrag lesen nicht nur die erste Zeile.

Holger, du willst was von uns. Nicht jeder kann sich präzise ausdrücken. 
Aber Dein erster Post ist unvollständig und widersprüchlich, es fällt 
schwer, einen Sinn darin zu erkennen. Akzeptier die Kritik und gib uns 
keine Anweisungen, was wir besser machen können.

Pink Shell schrieb:
> gib uns keine Anweisungen, was wir besser machen können.
Sondern sag, was du warum womit machen willst. Nicht aber wie du 
es machen willst. Das "wie" wird sich dann schon ergeben.

Man könnte auch einfach einen Link auf Netiquette setzen...

Vielleicht ist er einfach ein Troll, der den Thread geschickt 
eingefädelt hat. Es sind im Eröffnungsthread schon einige Indizien, dass 
hier bewusst mit Falschinformationen der Leser angespitzt werden soll.

1. 1MHz Takt vs. 1µs: Das erkennt schon jedes Kleinkind, dass dies
   unmöglich ist.

2. Er will _delay_us() ersetzen... warum?

3. "Softwarelösung die leider bei 2 MHz aussteigt": bei 2MHz-µC-Takt?

4. DS18S20 (mit 1.2 Mhz mit maximalen 1 K Bytes Flash: gibt es nicht.

Hier werden systematisch einfachste technische Begriffe mit praktischen 
Unmöglichkeiten verknüpft. Ein Schelm, wer böses dabei denkt ;-)

Pink Shell schrieb:
> Holger, du willst was von uns. Nicht jeder kann sich präzise ausdrücken.
> Aber Dein erster Post ist unvollständig und widersprüchlich, es fällt
> schwer, einen Sinn darin zu erkennen. Akzeptier die Kritik und gib uns
> keine Anweisungen, was wir besser machen können.

?
Was damit gemeint war, war das nicht auf unsinnigen Dingen herum 
geritten werden soll.
Antworten wie "LOL" "1µS = 1 MOhm" "1µS ≙ 1MΩ" sind nicht gerade 
hilfreich.
Es sollten eigentlich Leute angesprochen werden die sich mit dem Timing 
von 1 Wire, bzw. mit dem des DS18S20 und Mikrocontrollern auskennen und 
nicht irgend welche frustrierten Typen.

Eduard L. schrieb:
>>  DS18S20 (One Wire) mit 1.2 Mhz mit maximalen 1
> K Bytes Flash betreiben
> Es gibt beim DS18S20 weder Flash noch 1K Bytes zu beschreiben.

Meine Güte...
Natürlich nicht. Aber es gibt Ic's die zum Beispiel von Atmel 
hergestellt werden mit denen man die Temperatursensoren auslesen kann.

Frank M. schrieb:
> Vielleicht ist er einfach ein Troll, der den Thread geschickt
> eingefädelt hat. Es sind im Eröffnungsthread schon einige Indizien, dass
> hier bewusst mit Falschinformationen der Leser angespitzt werden soll.

Nette Theorie,
ich habe mich lediglich zu sehr darauf versteift die _delay_us Funktion 
zu ersetzen. Das der Beitrag ein wenig wirr scheint muß ich allerdings 
zugeben.

1. Das ist klar, der DS18S20 benötigt im Prinzip keinen 1µS Takt es geht 
(glaube ich) ab 15 µS los. Mit einer Ausnahme, die aber durch ein nop 
behandelt werden kann.

2. Weil _delay_us() mit 1MHz "nicht funktioniert".

3.
Atmega8 @ 8MHz Kommunikaton funktioniert
Atmega8 @ 4MHz Kommunikaton funktioniert
Atmega8 @ 2MHz oder kleiner Kommunikaton funktioniert nicht

1

#define nop() asm volatile("nop")

2

// software mikrosekunden delay

3

void delay_us(uint16_t delay)

4

{

5

  // 7 Instruktionen

6

  while(delay > 0)

7

  {

8

    delay--;

9

    nop();

10

  }

11

}

Laut Simulation im Atmelstudio 6.2 passen die Zeiten, nun weiß ich nur 
nicht ob es an dem Software delay liegt oder ob irgendwo ein anderes 
Problem besteht, wie z.B. der Bus release.

4. Das ist nun aber eine Troll Aussage ?

Um dem ganzen Spuk ein Ende zu bereiten :

Es soll an einen ATtiny13 der mit 1.2MHz(intern) läuft ein DS18S20 
angeschlossen und ausgelesen werden.
Fuses, sowie EEprom können nicht geändert werden.

An diejenigen die Ernsthaft geantwortet haben, schonmal ein Danke, da 
waren bereits ein zwei gute Tipps bei.

Eli A. schrieb:
> Wenn du nicht bereit bist zu lernen können wir den Thread auch
> schließen...

Auf solche Drohungen stehe ich nicht wirklich...

Eli A. schrieb:
> Wenn du wirklich Mikrosimens meinst solltest du uns Mal erklären was ein
> Takt von 1 Mikrosimens ist.

µs, Zufrieden ?

Eli A. schrieb:
> Schon mal darüber nachgedacht, dass das while(delay) und das delay--
> auch Zeit brauchen?

Ja, 7 Instruktionen.
Aber viel interessanter ist der Funktionsaufruf, bzw. das verlassen der 
Funktion das wurde aber mit berechnet.

Eli A. schrieb:
> Ansonsten denke ich, dass 1 Wire mit einem AVR mit 1k Flash und 1.2MHz
> leicht möglich ist wenn man weiß was man tut...

Das ist eine Aussage. Und genau darum geht es.
Besteht von deiner Seite aus Interesse mir dabei zu helfen oder war das 
nun nur eine Einschätzung ?

Holger L. schrieb:
> Es soll an einen ATtiny13 der mit 1.2MHz(intern) läuft ein DS18S20
> angeschlossen und ausgelesen werden.
> Fuses, sowie EEprom können nicht geändert werden.

1

#include <avr/power.h>

2

.

3

.

4

.

5

6

clock_prescale_set(clock_div_1); //Und schon läuft dein Attiny mit 9,6MHz

7

8

clock_prescale_set(clock_div_8); //Wenn es wieder langsamer sein darf

mfg.

Super, ich danke dir.

Toto schrieb:
> Noch was vergessen:
>
> Ich denke, der Zwang, mit Usernamen zu posten, würde die Umgangsformen
> erheblich verbessern.
>
> Wäre mal nen Vorschlag an die Mods...
Wenn du damit Anmeldezwang meinst: Das Thema hatten wir schon gefühlte 
100 mal, Andreas will das aber nicht...

Holger L. schrieb:
> 2. Weil _delay_us() mit 1MHz "nicht funktioniert".

Was soll da nicht funktionieren?

_delay_us() ist so genau wie möglich, nämlich takt-genau aufgerundet auf 
den nächsten ganzen Takt.
Bei 1MHz wird _delay_us(1) zu genau einem NOP.
_delay_us(1.5) wird z.B. zu zwei NOPs.
Wenn so viele Takte zu verbraten sind, dass dafür eine Schleife 
verwendet wird, wird der "Rest" ebenfalls durch angehängte NOPs 
realisiert.

Du kannst selbst schlicht nichts besseres/genaueres programmieren.

Stefan Ernst schrieb:
> Was soll da nicht funktionieren?

Der Funktionsaufruf dauert schon länger als eine Mikrosekunde.
Bei 1MHz wird _delay_us(1) zu 14 Mikrosekunden.
Wenn ich mir das vorher mal ausgerechnet hätte, hätte ich mir den 
Softwaredelay sparen können, es kommt auf das Gleiche hinaus.
Das Problem besteht wohl in irgend einem Timing bei dem durch setzen von 
Registern zu viel Zeit vergeudet wird.
Das dürfte sich wohl nur in Asm lösen lassen, was hier schonmal 
angesprochen wurde.

Es hat sich, dank dem Tipp von Thomas Eckmann, sowieso erledigt.

Was den Beitrag von Toto angeht : Volle Zustimmung !

Holger L. schrieb:
> Der Funktionsaufruf dauert schon länger als eine Mikrosekunde.
> Bei 1MHz wird _delay_us(1) zu 14 Mikrosekunden.

Quatsch. Es gibt keinen Funktionsaufruf, das ist alles Inline-Assembler.
Es ist so, wie ich bereits geschrieben habe:
es wird zu einem NOP und sonst nichts, und dauert damit genau 1µs.

Stefan Ernst schrieb:
> Quatsch. Es gibt keinen Funktionsaufruf, das ist alles Inline-Assembler.

Das ist schon eine Funktion. Die wird aber so gnadenlos optimiert, dass 
in diesem Fall nur noch ein "nop" übrigbleibt.

In delay_basics.h befinden sich 2 Funktionen in Assembler, die ggf. von 
_delay_us() aufgerufen werden. Aber _delay_us() und _delay_ms() sind 
C-Funktionen.

mfg.

Thomas Eckmann schrieb:
> Das ist schon eine Funktion.

Ich habe nichts anderes behauptet.
Es ging um diese Aussage
> Der Funktionsaufruf dauert schon länger als eine Mikrosekunde.
also um den Funktionsaufruf auf Assembler-Ebene. Und den gibt es hier 
nicht.

Stefan Ernst schrieb:
> Ich habe nichts anderes behauptet.

Lass uns hier nicht um den Bart des Propheten streiten. Wir meinen beide 
das gleiche.


123 schrieb:
> Wenn ich das richtig gesehen habe (ergoogelt)
> ist die loop als inline definiert. Somit erfolgt hier kein
> Funktionsaufruf.
> Ist die loop in inline ASM geschrieben. Sie dürfte somit nicht optimiert
> werden.

Guck dir lieber die Funktion an, anstatt irgendwas zu googeln.

_delay_ms() und _delay_us() sind C-Funktionen, die nicht in 
Inline-Assembler geschrieben sind. Und sie werden optimiert. Das geht 
sogar soweit, dass die Funktionen nur mit Optimierung das richtige 
Ergebnis liefern.

> Also ggf aufpassen mit dem am preskaler rumdrehen. Könnte ggf das timing
> komplett verdrehen.

Da wird nicht dran rumgedreht, sondern es wird eine Einstellung 
vorgenommen, die selbstverständlich bei der Compilierung zu 
berücksichtigen ist.


mfg.

123 schrieb:
> Das
> delay kann bei 1MHz nur in 3us bzw in 4us steps warten. + Laufzeit für
> die tick Berechnungen.

Nein.

1) Die Tick-Berechnung findet zur Compile-Zeit statt (daher dürfen die 
Funktionen nur mit Konstanten aufgerufen werden).

2) Der Inline-Assembler-Code kommt heutzutage nicht mehr aus der Lib, 
sondern direkt vom Compiler (über die Builtin-Funktion 
__builtin_avr_delay_cycles), und der funktioniert takt-genau (bei 1MHz 
also in 1µs-Schritten).