Hallo zusammen, ich versuche Mal mein "Problem" auf das Geringste runterzubrechen - eigentlich ganz simpel: Im Rahmen eines Projekts versuche ich, die Zeit zwischen zwei steigenden Flanken an einem IO-Pin auszulesen und zu speichern, um sie nachfolgend zu verwerten. Dies habe ich bereits mit dem Input Capture Mode innerhalb der STM32-Programmierung realisiert. Besonders zufriedenstellend war das nicht, da ich dafür die vorgefertigte HAL-Library benutzt habe. Gerne würde ich mich nun erstmals - besonders was das Thema Timer angeht - auf die Assembler-Ebene begeben und dachte da direkt an die AVR-Familie, denn dort könnte ich mit dem AVR-GCC starten, weil ja dort doch sehr viele hardwarenahe Befehle implementiert sind und ich in C(++) eigentlich ganz guten Überblick habe. Mein Auswahlkriterium bezieht sich erstmal nur auf das oben beschriebene Problem: Habe gesehen, dass es bei den 16-Bit-Timern vieler Mikrocontroller der Familie auch einen solchen Input Capture Mode gibt. So weit so gut, gerne würde ich aber die absolut minimalste Peripherie verwenden, um meine Aufgabe zu lösen. Bräuchte beispielsweise auch nur 5 IO's. Deshalb: Ist es grundsätzlich möglich, die oben beschriebene Aufgabe mit einem einfachen 8-Bit-Timer ohne Input Capture Mode zu realisieren? Vielen Dank für eure Hilfe!
libre95 schrieb: > Besonders zufriedenstellend war das nicht, da ich dafür die > vorgefertigte HAL-Library benutzt habe. Wo liegt das Problem? Die HAL mag nicht die schönste und beste sein, aber wenn man das Problem damit lösen kann, reicht es. > Gerne würde ich mich nun erstmals - besonders was das Thema Timer angeht > - auf die Assembler-Ebene begeben und dachte da direkt an die Warum? Assembler bringt hier keinen Vorteil. Man kann Register auch ohne HAL in C direkt setzen. Und gerade die Input Capture Funktion entspannt das Timing ungemein, so daß man eben NICHT jeden Takt mit Assembler möglichst effizient nutzen muss. > Mein Auswahlkriterium bezieht sich erstmal nur auf das oben beschriebene > Problem: Habe gesehen, dass es bei den 16-Bit-Timern vieler > Mikrocontroller der Familie auch einen solchen Input Capture Mode gibt. > So weit so gut, gerne würde ich aber die absolut minimalste Peripherie > verwenden, um meine Aufgabe zu lösen. Bräuchte beispielsweise auch nur 5 > IO's. Na dann nimm halt einen ATtiny24, der hat einen 16 Bit Timer1 und nur 14 Pins. > Deshalb: Ist es grundsätzlich möglich, die oben beschriebene Aufgabe mit > einem einfachen 8-Bit-Timer ohne Input Capture Mode zu realisieren? Sicher.
Bei der Frage fehlen die wichtigen Angaben zur Periodendauer des zu messenden Signales und wie genau du es aufgelöst haben möchtest. So ist die Frage nicht zu beantworten. Aber du hast schon mal erkannt, dass es devices mit einem Hardware-Input-Capture gibt. Entweder, du hast Glück und jemand kennt zufällig die Antwort, wenn du oben genannten Parameter bereitstellst, oder du musst dich durch die Parameter-Suche wühlen. Das wird dir eher keiner abnehmen. Ich könnte höchstens noch eine Idee zu einem anderen Konzept beisteuern: Je nachdem, wie dein Signal und deine Anforderungen an die Messung sind, kannst du das auch in Software lösen. Dann kannst du die kleinen Dinger aus der Attiny Serie nehmen. Ich hab mich da mal im Bereich Modelbau ein bisschen mit rumgeschlagen :> Beitrag "RC Servo Signalmessung mit ATTiny85 und Konsorten"
Wenn die SW-Lösung für dich passt - währe der Tiny85 ein heißer Kandidat. Der hat 8 Pins minus VCCpin minus MassePin minus Resetpin = 5 :) Sofern dein Messpin in 5 Pins gehört :>
> gerne würde ich aber die absolut minimalste Peripherie > verwenden, um meine Aufgabe zu lösen. Früher hatte ich auch die Einstellung, nicht mehr als unbedingt nötig in meinen vorhandenen AVR Chips ungenutzt zu lassen bzw. den absolut assenden AVR-Typ zu nutzen/kaufen. Aber was genau ist denn nun Grund deines (selbst auferlegten?) Minimalismus? Preis der Chips, verfügbarer Platz auf der Platine, das Gefühl, im benutzten Chip nicht allzuviel ungenutzt zur Verfügung zu haben, Masochismus? Oder was ganz Anderes? Ich würde Dir raten, nimm einen AVR, den Du bereits in der Schublade hast, der ist garantiert günstiger als jeder, den Du ansonsten extra kaufen musst. Wenn es allerdings echte Kriterien hinsichtlich Gehäuse-Größe gibt, dann nimm den lesitungsfähigsten, der in den vorhandenen Platz passt.
Jasson J. schrieb: > Bei der Frage fehlen die wichtigen Angaben zur Periodendauer des > zu > messenden Signales und wie genau du es aufgelöst haben möchtest. > So ist die Frage nicht zu beantworten. Sind solche Angaben nicht nur für die Taktfrequenz des MCU wichtig? Verstehe nicht genau, was das mit dem Vorhandensein eines Input Capture Modes bzw. der größe des Timers zu tun haben soll... /o\ Die zu messende Zeitspanne beträgt 44us, die Auflösung kann als grob angenommen werden bzw. ist zunächst egal. > Ich könnte höchstens noch eine Idee zu einem anderen Konzept beisteuern: > Je nachdem, wie dein Signal und deine Anforderungen an die Messung sind, > kannst du das auch in Software lösen. > Dann kannst du die kleinen Dinger aus der Attiny Serie nehmen. > Ich hab mich da mal im Bereich Modelbau ein bisschen mit rumgeschlagen > :> > Beitrag "RC Servo Signalmessung mit ATTiny85 und Konsorten" Vielen Dank für die Verlinkung! Das hat mir direkt ein paar Denkanstöße gegeben und mich gleichzeitig ein bisschen gegruselt... :) Vielleicht versuche ich es doch erstmal mit dem Input Capture selbst... :) Noch eine Frage, die du mir bestimmt schnell beantworten kannst: Mit dem einen Timer möchte ich wie gesagt den Input Capture realisieren - darüberhinaus würde ich gerne noch ein delay über einen Timer implementieren (ohne die Delay-Funktion zu nutzen). Benötige ich dann dafür zwei von einander unabhängige Timer oder kann ich das mit ein und dem selben Timer realisieren? LG
Thilo L. schrieb: >> gerne würde ich aber die absolut minimalste Peripherie >> verwenden, um meine Aufgabe zu lösen. > Aber was genau ist denn nun Grund deines (selbst auferlegten?) > Minimalismus? Vielleicht bin ich einfach du von früher. :) Die Anforderung, die Platine so klein wie möglich zu halten, besteht... allerdings wird ein ATtiny mit einem 16-Bit-Timer wahrscheinlich nicht viel größer sein als derjenige mit einem 8-Bit-Timer. :D Ein bisschen Masochismus und Weiterbildung á la "sowas wie input capture brauch ich bestimmt nicht, das bekomm ich selber hin!" mischt bestimmt auch mit :)
libre95 schrieb: > Dies habe ich bereits mit > dem Input Capture Mode innerhalb der STM32-Programmierung realisiert. > Besonders zufriedenstellend war das nicht, da ich dafür die > vorgefertigte HAL-Library benutzt habe. Die Timer beim STM32 sind dafür eigentlich gut geeignet. Jasson J. schrieb: > Bei der Frage fehlen die wichtigen Angaben zur Periodendauer des zu > messenden Signales und wie genau du es aufgelöst haben möchtest. > So ist die Frage nicht zu beantworten. So sieht es aus. Ein einfacher Ansatz mit ATmega88, ohne die genauen Anforderungen zu kennen: Beitrag "Stoppuhr – Geschwindigkeit – Pulsweite mit Atmega88" Ein anderer Ansatz mit STM32: http://www.mino-elektronik.de/FM_407/fmeter_407.htm#a5 libre95 schrieb: > Benötige ich dann > dafür zwei von einander unabhängige Timer oder kann ich das mit ein und > dem selben Timer realisieren? Es reicht ein Timer, sofern er mehrere Output-Compare-Register hat.
libre95 schrieb: > Die zu messende Zeitspanne beträgt 44us, die Auflösung kann als grob > angenommen werden bzw. ist zunächst egal. Naja, wenn es egal ist, reicht auch eine "Puls da oder nicht da" Erkennung. Reicht das? 44us sind schon recht kurz, immerhin muss in der Zeit der Interrupt für das Auslesen und Umkonfigurieren des Input Capture erfolgen. Geht noch in C, wird aber schon sportlicher. > Noch eine Frage, die du mir bestimmt schnell beantworten kannst: Mit dem > einen Timer möchte ich wie gesagt den Input Capture realisieren - > darüberhinaus würde ich gerne noch ein delay über einen Timer > implementieren (ohne die Delay-Funktion zu nutzen). Benötige ich dann > dafür zwei von einander unabhängige Timer oder kann ich das mit ein und > dem selben Timer realisieren? Dafür reicht ein Timer, denn der kann, wenn man es richtig macht (tm) mit der Output Compare Funktion eben diese Verzögerung erreichen.
Hallo, Du könntest einen Zähler frei laufen lassen und einen INT bei einer steigenden Flanke auslösen und in der ISR den Zählerwert auslesen und anschließend zurücksetzen. So ähnlich habe ich mal Tasten entprellt. Für mehrere Eingänge kannst Du den Zählerstand einfach zwischenspeichern und in der Hauptschleife jeweils vom vorigen Wert subtrahieren. Für PCINT könnte das so ähnlich aussehen PC_ISR: .if NS sbic PINB, 6 ;nur beim Impuls =0 prüfen .else sbis PINB, 6 ;nur beim Impuls =1 prüfen .endif reti push AL in AL,SREG push AL …….Deine Werte speichern pop AL out SREG,AL pop AL reti Gruß Carsten
libre95 schrieb: > Gerne würde ich mich nun erstmals - besonders was das Thema Timer angeht > - auf die Assembler-Ebene begeben und dachte da direkt an die > AVR-Familie, denn dort könnte ich mit dem AVR-GCC starten, weil ja dort > doch sehr viele hardwarenahe Befehle implementiert sind und ich in C(++) > eigentlich ganz guten Überblick habe. Das ganze Spiel geht auch problemlos mit den STM32/Cortex-M. Auch dafür gibt es einen GCC und auch da kann man in Assembler arbeiten. Dazu mein Tutorial: ARM-ASM-Tutorial. Wobei ich auch keinen Grund sehe warum man Timer nicht in C oder C++ ansteuern soll. Die Timer der STM32 sind schon sehr gut geeignet so etwas in sehr präzise zu messen.
Falk B. schrieb: > Naja, wenn es egal ist, reicht auch eine "Puls da oder nicht da" > Erkennung. Reicht das? Reicht so beschrieben für mich zunächst aus! > 44us sind schon recht kurz, immerhin muss in der > Zeit der Interrupt für das Auslesen und Umkonfigurieren des Input > Capture erfolgen. Geht noch in C, wird aber schon sportlicher. Das heißt? Wie hoch muss meine Taktfrequenz sein? Eigentlich bin ich von einem Timer ausgegangen, der einfach in Mikrosekunden hochzählt.... kenne mich mit der Materie eben noch nicht so aus. > Dafür reicht ein Timer, denn der kann, wenn man es richtig macht (tm) > mit der Output Compare Funktion eben diese Verzögerung erreichen. Vielen Dank, dahingehend werde ich mich auch noch einmal informieren. Auch Danke an deinen Vorposter.
libre95 schrieb: >> 44us sind schon recht kurz, immerhin muss in der >> Zeit der Interrupt für das Auslesen und Umkonfigurieren des Input >> Capture erfolgen. Geht noch in C, wird aber schon sportlicher. > > Das heißt? Wie hoch muss meine Taktfrequenz sein? Eigentlich bin ich von > einem Timer ausgegangen, der einfach in Mikrosekunden hochzählt.... > kenne mich mit der Materie eben noch nicht so aus. Na dann nimm 8 MHz, ggf. einfach mittels internem RC-Oszillator erzeugt.
Niklas G. schrieb: > Das ganze Spiel geht auch problemlos mit den STM32/Cortex-M. Auch dafür > gibt es einen GCC und auch da kann man in Assembler arbeiten. Dazu mein > Tutorial: > ARM-ASM-Tutorial. Wobei ich auch keinen Grund sehe warum man Timer > nicht in C oder C++ ansteuern soll. Die Timer der STM32 sind schon sehr > gut geeignet so etwas in sehr präzise zu messen. AVR war wie gesagt nur mein erster Gedanke - vielen Dank für die Verlinkung, auch hier werde ich mich weitergehend informieren! :) Habe ja selbst gemerkt, wie unglaublich gut die Timer der STM32 funktionieren - das alles hat wirklich nur mit Weiterbildung zu tun, denn es kann mmn nicht schlecht sein, etwas mehr über die Register ö.ä. innerhalb von MCUs zu lernen.
Falk B. schrieb: > Na dann nimm 8 MHz, ggf. einfach mittels internem RC-Oszillator erzeugt. An 8MHz hatte Carsten-Peter C. schrieb: > Hallo, > Du könntest einen Zähler frei laufen lassen und einen INT bei einer > steigenden Flanke auslösen und in der ISR den Zählerwert auslesen und > anschließend zurücksetzen. So ähnlich habe ich mal Tasten entprellt. Für > mehrere Eingänge kannst Du den Zählerstand einfach zwischenspeichern und > in der Hauptschleife jeweils vom vorigen Wert subtrahieren. Für PCINT > könnte das so ähnlich aussehen > PC_ISR: > .if NS > sbic PINB, 6 ;nur beim Impuls =0 prüfen > .else > sbis PINB, 6 ;nur beim Impuls =1 prüfen > .endif > reti > push AL > in AL,SREG > push AL > …….Deine Werte speichern > pop AL > out SREG,AL > pop AL > reti > > Gruß Carsten Auch hier vielen Dank für den Denkanstoß! :)
libre95 schrieb: > Falk B. schrieb: >> Na dann nimm 8 MHz, ggf. einfach mittels internem RC-Oszillator erzeugt. > > An 8MHz hatte > .......ich auch schon gedacht. /o\ Vielen Dank!
libre95 schrieb: > Deshalb: Ist es grundsätzlich möglich, die oben beschriebene Aufgabe mit > einem einfachen 8-Bit-Timer ohne Input Capture Mode zu realisieren? Nur mit Abstrichen bezüglich der erreichbaren Messgenauigkeit. Mit InputCapture kann man halt auf einen Systemtakt genau messen, ohne beträgt die Ungenauigkeit immer mindestens drei Systemtakte, bei unglücklich konstruierter Software auch noch beliebig mehr. > Die zu messende Zeitspanne beträgt 44us, die Auflösung kann als grob > angenommen werden bzw. ist zunächst egal. Na wenn die Auflösung dir egal ist, dann ist das auch kein Problem. Das Intervall ist endlos. 44µs sind bei 8Mhz Systemtakt 352 Takte. Das stellt auch in C noch keinerlei Problem dar. Ein sinnvoll geschriebenes C-Programm sollte also etwa 1,7% maximalen Messfehler erreichen, genau wie ein entsprechendes Assembler-Programm. Dazu ist allerdings noch der Fehler durch Abweichungen des Systemtaktes vom 8MHz-Sollwert zu addieren, der auch leicht mal bei 2% liegen kann, aber immerhin quasi-statisch ist, solange Betriebstemperatur und Spannung einigermaßen konstant bleiben. Auch das gilt aber natürlich vollkommen unabhängig von der verwendeten Sprache. Was ich nicht verstehe: Wie kann dir die Auflösung egal sein? Also mich interessiert bei jeder Messung als Erstes die erreichbare Auflösung (natürlich in Relation zur notwendigen Auflösung). Mit Bullshit wie "grob bis egal" kann niemand etwas sinnvolles anfangen. Da sollte schon wenigstens ein oberer Grenzwert für den zulässigen Fehler angegeben werden.
libre95 schrieb: > So weit so gut, gerne würde ich aber die absolut minimalste Peripherie > verwenden, um meine Aufgabe zu lösen. Bräuchte beispielsweise auch nur 5 > IO's. Mit dem Attiny 24/44/84a bist du da am nächsten dran.
Eher so der Vollständigkeit halber: 16 Bit Timer/Counter mit Input Capture und "wenigen" GPIOs (5, für den 6. müsste man den Reset opfern) gäbe es z.B. im ATtiny102. Im Gegensatz zu den bereits genannten ATtiny24 (mehr Pins als benötigt) und ATtiny85 (kein 16 Bit Timer) sollte der alle deine Anforderung erfüllen und ist - soweit ich es sehe - der einzige 8-Pinner AVR dieser Art. Gibt es allerdings nur als SMD (SOIC und UDFN), aber wenn es um Platz geht, sollte das selbstverständlich sein. Wenn es DIL sein muss, geht es beim ATtiny44A weiter, ist aber auch nur die nächstgrößere Klasse (14 Pins). Fun fact: Als BGA nimmt der weniger als die halbe Fläche des SOIC8 in Beschlag. Wenn es wirklich um Platz gehen würde und man unbedingt leiden möchte, geht es um das Package, nicht die Pins. Ich muss aber Thilo L. absolut recht geben: Es lebt sich viel entspannter, wenn man sich auf eine Hand voll Controller beschränkt, die man regelmäßig einsetzt. Das schont die Nerven und vereinfacht die Beschaffung, ganz besonders in Bastel-Kleinmengen.
Dyson schrieb: > Mit dem Attiny 24/44/84a bist du da am nächsten dran. Na wenn's schon 14-Pinner sein müssen, dann aber gleich richtig: ATtiny214/414/814 (XMega-Architektur) oder ATtiny441/841 ("klassische" Architektur). Die haben zwar allesamt 14 Pins, aber dafür immerhin mindestens einen 16Bit-Timer mit InputCapture-Funktion.
@libre95 Du hast ja jetzt diverse Denkanstöße. Nu interessiert mich aus Neugier, was deine Applikation ist :) Grundsätzlich war das schon mal gut, dass du am Anfang deine Frage auf das nötigste fokussiert hast.
libre95 schrieb: > Hallo zusammen, > > ich versuche Mal mein "Problem" auf das Geringste runterzubrechen - > eigentlich ganz simpel: Im Rahmen eines Projekts versuche ich, die Zeit > zwischen zwei steigenden Flanken an einem IO-Pin auszulesen und zu > speichern, um sie nachfolgend zu verwerten. Dies habe ich bereits mit > dem Input Capture Mode innerhalb der STM32-Programmierung realisiert. > Besonders zufriedenstellend war das nicht, da ich dafür die > vorgefertigte HAL-Library benutzt habe. > > Gerne würde ich mich nun erstmals - besonders was das Thema Timer angeht > - auf die Assembler-Ebene begeben und dachte da direkt an die > AVR-Familie, denn dort könnte ich mit dem AVR-GCC starten, weil ja dort > doch sehr viele hardwarenahe Befehle implementiert sind und ich in C(++) > eigentlich ganz guten Überblick habe. > > Mein Auswahlkriterium bezieht sich erstmal nur auf das oben beschriebene > Problem: Habe gesehen, dass es bei den 16-Bit-Timern vieler > Mikrocontroller der Familie auch einen solchen Input Capture Mode gibt. > So weit so gut, gerne würde ich aber die absolut minimalste Peripherie > verwenden, um meine Aufgabe zu lösen. Bräuchte beispielsweise auch nur 5 > IO's. > > Deshalb: Ist es grundsätzlich möglich, die oben beschriebene Aufgabe mit > einem einfachen 8-Bit-Timer ohne Input Capture Mode zu realisieren? > > Vielen Dank für eure Hilfe! Hallo, eine paar ganz wichtige Infos fehlen noch: Wie genau muß das denn sein, und wie soll der µC mit dem Rest der Welt reden? Die Aussage 16Bit sind halt etwas "unpräzise". 16 Bit heißen ja nur, daß man bis 65536 zählen kann. Das muß halt mit der Taktquelle und internen Prescalern halt auch zu Deiner "Signallänge" passen. Hintergrund sind die Taktquelle - einfach ausgedrückt: - intern: billig, einfach, ungenau (bis zu +-10% je nach Device) - extern: teuer, aufwendiger, genau (Genauigkeit "beliebig" je nach Geldbeutel) Kommunikation mit Rest der Welt: µC sinnvollerweise so wählen, daß bevorzugte Kommunikation (z.B. UART,SPI, I²C etc.) in HW unterstützt wird. Auflösung 16 Bit: Es nutzt wenig, einen µC mit z.B. 8 MHz zu wählen (1 Takt=125ns) und dann mit einem 16-Bit Timer ein Signal mit z.B. 5µs auszuwerten. Dann hätte man auch nur 40 Schritte (d.h. nur gut 5 Bit im Timer genutzt). Solange man diese Randbedingung nicht kennt, sind wir hier vollständig im Glaskugelmodus bei der µC Auswahl. Robert
Angehängte Dateien:
-
Mouser_ATtiny1616-MNR.png
110 KB
ATtiny1616-MNR 20-Pin VQFN 3x3mm Flash: 16 kB SRAM: 2 kB EEPROM: 256 bytes 16-bit Timer/Counter type A (TCA): 1 16-bit Timer/Counter type B (TCB): 2 12-bit Timer/Counter type D (TCD): 1
libre95 schrieb: > Benötige ich dann > dafür zwei von einander unabhängige Timer oder kann ich das mit ein und > dem selben Timer realisieren? Input-Capture und Output-Compare kann man getrennt benutzen (separate Interrutpvektoren). Assembler bereitet nur unnötigen Ärger und Fehlerquellen (push/pop, keine Datentypen, keine Variablenverwaltung usw.). Wer C kann, muß mit dem Klammerbeutel gepudert sein, wenn er Assembler macht.
Beitrag #6707569 wurde von einem Moderator gelöscht.
Beitrag #6707574 wurde von einem Moderator gelöscht.
Hoert mit den Tinies auf. die sind superguenstig fuer hohe Stueckzahlen, dafuer vielen Restirktionen. Unterhalb einem Mega sollte man sich nicht antun.
libre95 schrieb: > ich versuche Mal mein "Problem" auf das Geringste runterzubrechen - Steht im Widerspruch zu: Pandur S. schrieb: > Hoert mit den Tinies auf. Der/Die/Das libre95 ist der Gott seines Projektes. Darum auch der Wunsch das Himmelreich. Ihm ist die Entscheidung, der Geldbeutel und die Arbeit.
Hallo, nur mal so als Tipp. Die AVRxDB Serie hat einen Timer namens TCB der hat spezielle Messfunktion dafür. Man kann die Frequenz oder Pulsweite oder Frequenz + Pulsweite in 16Bit messen. 32Bit mittels Kaskadierung. Prescaler stehen alle von TCA zu Verfügung. Noch genauer gehts nichts.
Veit D. schrieb: > nur mal so als Tipp. Die AVRxDB Serie hat einen Timer namens TCB der hat > spezielle Messfunktion dafür. Die schon mehrfach im Thread genannten neuzeitlichen Tinys haben genau denselben Timer...
c-hater schrieb: > Veit D. schrieb: > >> nur mal so als Tipp. Die AVRxDB Serie hat einen Timer namens TCB der hat >> spezielle Messfunktion dafür. > > Die schon mehrfach im Thread genannten neuzeitlichen Tinys haben genau > denselben Timer... Stimmt. :-) Allein die Kaskadierung bleibt den AVRxDA/DB vorenthalten. Wird der TO nicht benötigen wenn er bekannte 44µs messen möchte.
:
Bearbeitet durch User
Beitrag #6708058 wurde von einem Moderator gelöscht.
Peter D. schrieb: > Assembler bereitet nur unnötigen Ärger und Fehlerquellen (push/pop, > keine Datentypen, keine Variablenverwaltung usw.). > Wer C kann, muß mit dem Klammerbeutel gepudert sein, wenn er Assembler > macht. In Assembler schreibt man gerade deshalb um nicht von der zusätzlichen Hochsprachenbürokratie belästigt zu werden und ALLE Freiheiten mit minimalsten Anforderungen an die Programmierumgebung genießen zu können!
Moby schrieb: > In Assembler schreibt man gerade deshalb um nicht von der zusätzlichen > Hochsprachenbürokratie belästigt zu werden und ALLE Freiheiten mit > minimalsten Anforderungen an die Programmierumgebung genießen zu können! Das kann ein Aspekt sein. Für mich ist aber meist eher der entscheidende Punkt: Asm dann zu benutzen, wenn die Lösung auf gegebener Hardware mit C schwierig bis unmöglich wird, mit Asm aber noch geht, vielleicht sogar gerade noch geht. Denn genau diese Grenzfälle zeigen oft sehr deutlich auf, dass C-Compiler eben immer noch recht weit davon entfernt sind, für jeden Anwendungsfall optimalen Code zu erzeugen. Was natürlich nicht wirklich überraschend ist, da wesentlich Aspekte eines Gesamtsystems dem Compiler halt garnicht als Information zur Verfügung stehen bzw. ihn auf Grund seiner (doch recht beschränkten) Arbeitsweise zumindest nicht weiter interessieren.
c-hater schrieb: > ... ganz viel ... Ich schätze, das ist der "vernünftigste" Beitrag, den ich je von dir gesehen habe. Ich fasse es mal so zusammen: 1. Keine Sprache ist ideal bzw. immer optimal 2. ASM ist einsetzbar, insbesondere, wenn es keine Alternativen gibt.
Arduino Fanboy D. schrieb: > Ich fasse es mal so zusammen: > 1. Keine Sprache ist ideal bzw. immer optimal Natürlich nicht. Den entscheidenden Punkt hast du aber übersehen: die EINZIGE Sprache, die das theoretische Leistungsmaximum SICHER bereitstellen kann, ist: ASM. Natürlich ist hier zu 100% der Programmierer dafür verantwortlich, es auch tatsächlich zu erreichen. Keine Chance, die Verantwortlichkeit auf irgendeine andere Instanz abzuwälzen, wie es C-Programmierer so gerne tun. Da ist halt LibXYZ Schuld, wenn's nicht geht. Armselige Schutzbehauptungen inkompetenter Programmierer... > 2. ASM ist einsetzbar, insbesondere, wenn es keine Alternativen gibt. Und auch oft, wenn es es durchaus Alternativen gäbe, also nicht die Performance eine Rolle spielt, sondern die einfache Implementierung ohne viel Syntax-Gebabel. Was halt für SEHR viele kleine µC-Anwendungen durchaus der Fall ist.
c-hater schrieb: > Was halt für SEHR viele kleine µC-Anwendungen durchaus der Fall ist. Ergänzend vielleicht: Alles, was in einen AVR8 passt, ist aus meiner Sicht eher "klein". Klein genug, um es auch in Asm problemlos beherrschen zu können.
Jasson J. schrieb: > @libre95 > > Du hast ja jetzt diverse Denkanstöße. > > Nu interessiert mich aus Neugier, was deine Applikation ist :) > Grundsätzlich war das schon mal gut, dass du am Anfang deine Frage auf > das nötigste fokussiert hast. Hab den Hallsensor HAL 15xy vorliegen, der hat einen implementierten Power-On Self-Test, den ich mittels MCU ausgewertet habe. Quasi überhaupt nichts Großes: Zeit zwischen den beiden steigenden Flanken (aus dem Datenblatt) beträgt 44us => Grüne LED leuchtet. Andernfalls eine rote. Habe den Self-Test natürlich zuvor ohne MCU getriggert und mir das Ganze auf dem Oszi angeschaut, da wurden bei ca. 50 Durchläufen mit verschiedenen Sensoren niemals über 44us erreicht, wenn das Ding funktioniert hat. Deshalb habe ich mich bisher auch nicht wirklich um eine eventuelle Messgenauigkeit bzw. Toleranz (z.B. +/- 1us) gekümmert. Wollte eben erstmal, dass es prinzipiell funktioniert und das tut es eigentlich auch. /o\
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.