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#a5libre95 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
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.
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.
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\
