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. Hintergrund wäre die GCC _delay_us Funktion zu ersetzen. Der erste Ansatz bestand aus einer Softwarelösung die leider bei 2 MHz aussteigt. Das Ziel ist später einen DS18S20 (One Wire) mit 1.2 Mhz mit maximalen 1 K Bytes Flash zu betreiben.
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.
>(Atmega8 mit 1 MHz) einen 1µS Zähler zu erzeugen. Timer mit Prescaler 1. >Der erste Ansatz bestand aus einer Softwarelösung Was für ein Schwachsinn wenn ein Maschinenzyklus schon 1us dauert.
> 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.
:
Bearbeitet durch User
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
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.
nimm doch einfach ne höhere Taktrate und schick den Controller in den SleepModus, wenn er nichts zu tun hat. Das spart je nach Anwendungsfall mehr Strom und man muss sich nicht mit solchen Problemen rumschlagen.
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
:
Bearbeitet durch User
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.
> DS18S20 (One Wire) mit 1.2 Mhz mit maximalen 1 K Bytes Flash Es gibt beim DS18S20 weder Flash noch 1K Bytes zu beschreiben.
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...
:
Bearbeitet durch Moderator
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.
J. schrieb: > Bitte lern doch mal, Maßeinheiten richtig zu benutzen. Danke. Bitte. Danke für das Danke
Holger L. schrieb: > Antworten wie "LOL" "1µS = 1 MOhm" "1µS ≙ 1MΩ" sind nicht gerade > hilfreich. Holger L. schrieb: > 1µS > 15 µS Wenn du nicht bereit bist zu lernen können wir den Thread auch schließen... Wenn du wirklich Mikrosimens meinst solltest du uns Mal erklären was ein Takt von 1 Mikrosimens ist. Holger L. schrieb: > #define nop() asm volatile("nop") > // software mikrosekunden delay > void delay_us(uint16_t delay) > { > // 7 Instruktionen > while(delay > 0) > { > delay--; > nop(); > } > } Schon mal darüber nachgedacht, dass das while(delay) und das delay-- auch Zeit brauchen? 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...
Holger L. schrieb: > Antworten wie "LOL" "1µS = 1 MOhm" "1µS ≙ 1MΩ" sind nicht gerade > hilfreich. Weil das große (ich schreibs mal klein) "S" den Leitwert Siemens ist und das kleine (schreib ich auch klein) "s" die Sekunde ist. Somit ist µS = Mikrosiemens und Du hast bei: Holger L. schrieb: > 1. Das ist klar, der DS18S20 benötigt im Prinzip keinen 1µS Takt absolut kein Hirn eingeschaltet. Dadurch wirst Du verarscht (auch als Troll, weil so blöd ein Troll nicht sein darf) und bekommst von den anderen nur Stuss zu lesen (die trollen dann mehr als du, wodurch du zum b00n wirst)... ich find das ganze sehr schade! Vorallem weil noch kein Feierabend ist! *Hinweis: mein Text kann spuren von Nüssen enthalten und gibt nur meine Meinung wieder!
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: > Auf solche Drohungen stehe ich nicht wirklich... und ich stehe nicht auf flasch verwendete Einheiten (und Präfixe)... Holger L. schrieb: > µs, Zufrieden ? Ja Holger L. schrieb: > Ja, 7 Instruktionen. > Aber viel interessanter ist der Funktionsaufruf, bzw. das verlassen der > Funktion das wurde aber mit berechnet. Dann würde ich die Funktion für 15µs inlinen und nur aus ein Nops aufbauen. Verbrauch zwar 18 Programmworte für die 15µs (@1.2MHz), wird aber für 1wire nicht sehr oft benötigt...
Eli A. schrieb: > Holger L. schrieb: >> µs, Zufrieden ? > Ja Leider viel zu spät! Den Thread bitte löschen!
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.
Morelator schrieb: > Eli A. schrieb: > >> Holger L. schrieb: >>> µs, Zufrieden ? >> Ja > > Leider viel zu spät! Den Thread bitte löschen! Ich frage mich wirklich, wer hier eigentlich die ganze Zeit dummes Zeug postet! Da hat der TE ein Formelzeichen falsch geschrieben, und darauf wird dann rumgehackt. Wow. Sehr beeindruckend! Kannst Stolz sein... Was ich an diesem Forum wirklich hasse, ist daß auf solchen Nickeligkeiten herumgehackt wird, statt die eigentlich Frage zu beantworten. EIN Hinweis, daß etwas falsch geschrieben / ausgedrückt wurde, sollte doch reichen. Weil oben die Netiquette angesprochen wurde: Auch die, die solch dummes Zeug posten und sich auch "nett" vorkommen, sollten erstmal bei sich selber kehren! Ich kenne wirklich kein anderes Forum, wo so miteinander umgegangen wird. Hier sind doch nicht nur Kellerkinder unterwegs, die bei Neonlicht wochenlang Sachen löten, und durch den wenigen Kontakt zu echten Menschen den Umgang miteinander verlernt haben, oder? Ich glaube nicht, daß Ihr im echten Leben so mit anderen redet. Also laßt es doch auch hier. Beim Lesen von solchen Threads kommt bei die Galle hoch!
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...
Toto schrieb: > Ich frage mich wirklich, wer hier eigentlich die ganze Zeit dummes Zeug > postet! Mein 'Vorposter' zum Beispiel. Schreibt zeilenweise irgendeinen Kram, der mit der Frage nichts zu tun hat und beschwert sich am Ende, dass Leute Kram schreiben, der nichts mit der Frage zu tun hat. Wahrscheinlich so ein Kellerkind, das bei Neonlicht wochenlang Sachen lötet, und durch den wenigen Kontakt zu echten Menschen den Umgang mit anderen verlernt hat.
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...
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
Moin. 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. Wie jetzt die ms in Durchläufe umgerechnet werden hab ich nicht gesehen. Also ggf aufpassen mit dem am preskaler rumdrehen. Könnte ggf das timing komplett verdrehen. Gruss
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.
:
Bearbeitet durch User
OK. Hab mir die falschen Funktionen angeschaut. Wenn ich jetzt die richtige Datei erwischt hab sollte _delay_us auch als inline definiert sein. (Zumindest in Header file die ich jetzt gesehen habe) Da vermutlich F_CPU auf 1MHz eingestellt ist. Müste bei einer us der Funktionsaufruf komplett weg optimiert werden. Da __tmp= 0.3 wird. Das delay kann bei 1MHz nur in 3us bzw in 4us steps warten. + Laufzeit für die tick Berechnungen. Was ich mit dem rumdrehen gemeint hab bezieht sich auf den F_CPU. Der wird zur Compiler Zeit definiert. Wenn dann zur Laufzeit der CPU Takt geändert wird sind alle delays unter Umständen falsch. Da sich F_CPU ja nicht mehr andern läst. Gruss
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).
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.