Hallo liebe Forenmitglieder,
ich wende mich mit folgenden Projekt an Euch.
Für einen Demonstrator zum Thema Abtastung, möchte ich eine
Musikabtastung mittels eines ATMega8 vornehmen. Die Wunschvorstellung
ist die Abtastung eines Musikstücks, also der Digitalisierung, Ausgabe
der Abtastwerte (8 oder 10 Bit) an den Ausgängen des ATmegas und die
D/A-Rückwandlung mittels eines DAC.
Die Abtastfrequenz sollte per Poti einstellbar sein, um Effekte wie
Unter-, Ideal- und Überabtastung deutlich zu machen (z.B. 50Hz-20kHz).
Die Audioqualität spielt zunächst eine untergeordnete Rolle, solang die
Effekte hörbar sind.
Bisher habe ich im Forum keine passenden Beiträge gefunden, weshalb ich
meine Fragen hier stelle:
Ist die Umsetzung mit der Hardware möglich?
Gibt es Erfahrungswerte mit der programmtechnischen Umsetzung?
Ich besitze Grundkenntisse im Programmieren und habe bereits Ideen zur
Umsetzung, bin aber für Anregungen offen.
Im Voraus vielen Dank
Dein Atmega kann nicht mit 20kHz abtasten, schon gar nicht ausgeben, und
10 bit sind eher wenig.
Jeder PC schafft schon (48, 96, 192) ksps mit 16 oder gestörten 24 bit,
warum nicht den verwenden ?
Umgekehrt hat es bisher geklappt.
Habe mit dem internen PWM basierten DAC Wavefiles in 8khz 8 bit mono
ausgegeben. Bei ner PWM-Frequenz von 1MHz war das einzig schlechte daran
die eigentliche Klangqualität des wavs.
Rene schrieb:> Ich besitze Grundkenntisse im Programmieren und habe bereits Ideen zur> Umsetzung
Na dann lass mal hören.
> bin aber für Anregungen offen.
Da gibts nicht viel anzuregen. Da es um die Demonstration geht und die
Qualität nicht weiter wichtig ist, liegt es eigentlich auf der Hand:
Die 'Zeitkomponente' wird mit einem Timer erledigt, das ermöglicht dann
auch die Einstellung von aussen. Poti kannst du dir aber abschminken,
den ADC brauchst du zum AD Wandeln des Audiosignals. Den ADC stellst du
auf Free Running und im Timer Interrupt schaufelst du das letzte ADC
Ergebnis auf den Port an dem der DAC hängt. Alles in allem vielleicht 30
Zeilen Code.
Ob du mit dem ADC die vorgegebene maximale Abtastfrequenz schaffst oder
nicht, dazu siehst du bitte im Datenblatt nach und rechnest dir aus, bis
zu welcher Abtastfrequenz du maximal kommen kannst.
Wenn keine Abtastung von 20kHz möglich ist, welche Frequenz ist maximal
umsetzbar? Vielleicht ist auch eine geringe Abtastfrequenz für manche
Musikstücke ausreichend.
@ DJShadowman:
Gibt es einen Forumsbeitrag zu dem Thema, damit ich mich einlesen kann?
Gruß
@ Karl Heinz:
Meine Idee ist, Poti und Musiksignal über die verschiedenen ADC's des
ATMega einzulesen. Wenn ich mich recht erinnere, hat der ATMega doch
vier ADC Eingänge?
Über Timer und ISR möchte ich dann die Ausgabe steuern und nehme an,
dass diese Ausgabe per Potiwert zeitvariabel gestartet werden kann?
@ Peter II:
Eine Conversion Time von 13µs ist angegeben, was einer Frequenz von ca.
77kHz entspricht. Mir fehlt aber leider die Erfahrung, zu beurteilen ob
dies die wirkliche Abtastfrequenz darstellt.
Gruß
Rene schrieb:> @ Karl Heinz:>> Meine Idee ist, Poti und Musiksignal über die verschiedenen ADC's des> ATMega einzulesen. Wenn ich mich recht erinnere, hat der ATMega doch> vier ADC Eingänge?
Aber er hat nur EINEN ADC mit EINEM Eingang intern. Denn allerdings
kannst du auf verschiedene Pins schalten. Du kannst also nicht 2
Eingänge gleichzeitig auswerten, sondern immer nur einen nach dem
anderen, indem du den ADC auf jeweils einen anderen Pin aufschaltest.
Nur hilft dir das nichts. Denn der Flaschenhals besteht darin, dass du
den ADC brauchst, um das Musiksignal abzutasten. Ständiges Umschalten
zwischen den verschiedenen Eingängen, um dann auch das Poti abzufragen,
wirds zumindest bei den höheren Frequenz daher nicht spielen. Bei den
kleineren Abtastfrequenzen wäre das allerdings kein Problem.
Beim digitalen Abtasten kommen innerhalb kürzester Zeit, sehr große
Datenmengen zusammen.
Aus diesem Grund würde ich von den einfachen Atmels Abstand nehmen.
Wohin sonst mit den Daten?
Mit 8 oder 10 Bit reduzierst Du Musik zu Krach. Um aber den Unterschied
in der Abtastrate "sichtbar" zu machen, muss zumindest eine akzeptable
Auflösung her.
Grundsätzlich kannst Du mit einem eigenen Timer (variabel) einen
A/D-Wandler starten, um damit in Deinem Rhythmus abzutasten.
Hallo!
Ich würde das Signal mit nur 8 Bit digitalisieren. Danach evtl. Rotieren
und maskieren. (7...6...5 bit) und direkt auf einem Port über R2R
ausgeben.
Eine Pausenzeit bestimmt die Samplingrate.
Hier könnte man evtl. auch die Abfrage der Bedienknöpfe einfügen.
(eigener Port)
Alles schon kurz und knackig in Assembler.
Mirko
Hallo nochmal,
für die Anpassung der "Abtastfrequenz" ist es sinnvoll wirklich die
Frequenz des ADC's zu verändern oder die Frequenz der Ausgabe?
Ich sehe eher die letztere Möglichkeit als sinnvoll?!?
Gruß und Dank für die schnellen Antworten
Amateur schrieb:> Mit 8 oder 10 Bit reduzierst Du Musik zu Krach.
HiFi wirds sicherlich nicht sein, aber erkennbar wirds schon noch
bleiben.
Ich würde das übrigens nicht direkt mit Musik demonstrieren, sondern
erst mal mit einem Sinusgenerator einen einstellbaren Sinus reinjagen.
Oszi am Eingang, Oszi am Ausgang um die Unterschiede zu zeigen und dann
eventuell als Draufgabe noch einen Lautsprecher, damit man auch hören
kann, was die "Kurvenverformung" dem Sinus antut.
Rene schrieb:> Hallo nochmal,>> für die Anpassung der "Abtastfrequenz" ist es sinnvoll wirklich die> Frequenz des ADC's zu verändern oder die Frequenz der Ausgabe?> Ich sehe eher die letztere Möglichkeit als sinnvoll?!?
Es ist ziemlich wurscht.
Wenn die Ausgabe langsamer läuft als der ADC (im Free Running), dann ist
der Messwert der zur Ausgabe kommt maximal ein bischen 'alt'.
Es ist aber auch kein Problem, in der Timer ISR den ADC (nicht im Free
Running) jeweils wieder neu zu starten. Dann hat man auch exakt gleiche
Samplingintervalle.
Karl H. schrieb:> Poti kannst du dir aber abschminken,> den brauchst du zum AD Wandeln des Audiosiagnals.
Kommt drauf an, wenn man doppelt so schnell sampeln kann, wie die
höchste Abtastfrequenz, dann geht da auch ein Poti noch. Z.B. 750kHz
ADC-Clock (12MHz/Prescaler 16), auf 8 Bit Auflösung würde ich aber nicht
mehr wetten.
> Den ADC stellst du auf> Free Running und im Timer Interrupt schaufelst du das letzte ADC> Ergebnis auf den Port an dem der DAC hängt.
Um ein wenig definierteres Abtastverhalten zu erreichen, wäre als Auto
Trigger Source der Timer empfehlenswert, mit dem man die Samplefrequenz
einstellt. Dann ist's der ADC-Conversion-Complete-Interrupt, in dem eine
Weiterverarbeitung erfolgt. Allzu sehr aufblasen sollte man diese ISR
bei 55,5kHz Aufrufrate dann aber nicht.
MWS schrieb:> Um ein wenig definierteres Abtastverhalten zu erreichen, wäre als Auto> Trigger Source der Timer empfehlenswert, mit dem man die Samplefrequenz> einstellt.
Den hat nur leider der Mega8 nicht.
Aber es wird auch so gehen. Timer auf CTC, ISR anhängen, in der ISR das
Ergebnis auf den Port und zum Schluss mit dem ADSC Bit den ADC neu
starten.
HiFi ist sowieso nicht zu erwarten und soweit ich das verstanden habe
auch nicht gefordert.
Ich würds einfach mal "riskieren". Ich hab schon mehr als einmal im
Leben 10 Minuten für etwas verplempert, was dann nicht so funktioniert
hat, wie ich mir das vorgestellt habe. Aber egal: Es sind die
Fehlschläge, die uns weiterbringen.
Wieviel Ram ist denn im System?
Bei 8 Bit ist ein Sample ein Byte. Bei 8 Khz sind es also 8K Daten die
Sekunden. Bei 8 Sekunden sind 64 KBytes voll.
Und um an einem Sample per Poti zu drehen, sollte das Sample schon etwas
länger sein.
Jede einfache PC-Sampling Software hat doch schon die gewünschten
Funktionen.
Und auch 32bit Arm Prozessoren haben genug Leistung. Bestimmt gibt es
eine App dafür.
Warum muss das so eine 'reduzierte' AtMega8 CPU sein, die laut Atmel
Datenblatt anscheinend nur 1 KByte Ram hat?
Ich glaube nicht, dass "normale" Wandlung mit großen Pausen, und
langsame Wandlung ohne Pausen, vergleichbar sind.
Bei den meisten µP's kann man die "Abtastrate" auch nur in sehr groben
Schritten (Divisor) verändern.
Fütterst Du ein Oszilloskop mit dem Ergebnis, kommt es sehr auf die
gewollte oder auch ungewollte Filtercharakteristik an. Da die "Optik"
einer Kurve nichts mit der sehr subjektiven Interpretation des Ohres
zutun hat ist dieser Vergleich eher mittelprächtig.
PittyJ schrieb:> Wieviel Ram ist denn im System?
Er braucht kein RAM.
ADC sampelt. Samplewert wird sofort per DAC wieder ausgegeben.
Niemand muss da grossartig etwas zwischenspeichern.
Amateur schrieb:> Ich glaube nicht, dass "normale" Wandlung mit großen Pausen, und> langsame Wandlung ohne Pausen, vergleichbar sind.
Den ADC stellt er natürlich auf die größte mögliche
Wandlergeschwindigkeit ein.
Die Samplingrate ergibt sich einzig und alleine dadurch, wie oft pro
Sekunde er eine Wandlung durchführen lässt. Und dazu benutzt er einen
Timer.
Mach es doch einfach am PC. Unter Linux gibt es da tolle Konsolentools,
kann man sogar in Scilab/Matlab usw. machen und die Audiodatei kann man
anschließend mit Audacity weiter analysieren (oder auch in z.B. Matlab).
ADC im free running mode halte ich für keine so gute Idee, damit erzeugt
man einen Jitter, der 1/t der ADC-Samplingfrequenz entspricht.
Mein Vorschlag:
Im Timer-ISR:
* ADC-Wert auslesen
* ADC neu starten
* eingelesenen Wert auf DAC ausgeben
Über die Timer-ISR-Frequenz unterschiedliche Samplingraten einstellen.
Zusätzlich im Programm sicherstellen, daß die Timer-ISR-Frequenz nicht
höher ist als die Abtastfrequenz des ADC.
Eine unterschiedliche Frequenz von ADC und DAC solltest Du vermeiden.
Das erzeugt Effekte, die einem rieigen Jitter entsprechen. Mal Dir
einfach mal auf, was passiert, wenn Du mit 10khz einliest und mit 15khz
ausgibst.
Gruß, Stefan
Karl H. schrieb:> Den hat nur leider der Mega8 nicht.
Dann eben Single Conversion, zuerst in der Timer ISR auslesen, dann ggf.
MUX umstellen und Conversion neu anschubsen.
Stefan K. schrieb:> ADC im free running mode halte ich für keine so gute Idee,
Ich mitlerweile auch nicht mehr.
Da hatte ich aber noch nicht erkannt, wie die Samplingfrequenz am
einfachsten erzeugt wird. Ich wollte dem TO das Leben ein bischen
leichter machen :-)
Und dann ... war das Posting schon draussen. Konsequenterweise blieb ich
dann auch bei der Linie.
> Im Timer-ISR:> * ADC-Wert auslesen> * ADC neu starten> * eingelesenen Wert auf DAC ausgeben
Jep.
MWS schrieb:> Karl H. schrieb:>> Den hat nur leider der Mega8 nicht.>> Dann eben Single Conversion, zuerst in der Timer ISR auslesen, dann ggf.> MUX umstellen und Conversion neu anschubsen.
Müsste man durchrechnen, was das für die maximale Samplingfrequenz
bedeutet.
Aber was bleibt dann noch für den TO zu tun, wenn wir ihm hier alles bis
ins Detail vorkauen?
Sinnvollerweise nimmt man natürlich einen DAC, den man parallel
ansteuern kann. SPI würde wahrscheinlich auch noch gehen. Ein PWM-DAC
wird wohl auch noch drinnen sein (wenn ich mir die diversen Sound
Projekte in Erinnerung rufe, die so etwas benutzen). I2C würde ich erst
mal nicht wirklich empfehlen. Weniger aus technischen Gründen, mehr aus
der programmiertaktischen Überlegung heraus, dass der TO das auch
stemmen können muss. Da wäre eine parallel anzusteuernder DAC sicherlich
das simpelste.
Rene schrieb:> Wenn keine Abtastung von 20kHz möglich ist
Das ist sie aber (sogar noch deutlich mehr).
Man muß bei 20kHz halt nur damit rechnen, daß die unteren 1..2 Bit der
10Bit-Auflösung ein mehr oder weniger reines Zufallssignal enthalten und
nicht das Nutzsignal. D.h.: man kann auch einfach gleich nur 8 Bit des
Ergebnisses verwenden...
Und übrigens:
Was MaWin schrieb (dass eine Ausgabe mit 20kHz nicht möglich wäre) ist
natürlich sowieso absoluter Blödsinn. Das gilt ja nichtmal dann, wenn
die Ausgabe per PWM und analogem Rekonstruktionsfilter erfolgen soll und
natürlich schon garnicht, wenn sie einfach 8Bit-parallel (oder per
UART-SPI) an einen geeigneten DA-Wandler erfolgt.
Da MaWin aber durchaus rechnen kann, hat er vermutlich nur vergessen, in
seine Haßtirade einzuflechten, daß er die Ausgabe von Daten mit 16BpS
meint. Damit hätte er dann zwar natürlich vollkommen Recht, aber das war
von dir gerade garnicht gefragt. Also ganz eindeutig MaWin's Fehler...
Des weiteren:
Auch Karl-Heinz hat sich mal wieder als sehr unflexibel geoutet. Er hat
natürlich insofern Recht, als daß es beim 8Bit-AVR nur eine ADC-Einheit
gibt und die beim Sampling mit 20 kHz, weiß Gott, schon ziemlich am
Limit ist.
Aber er hat nicht mal im entferntesten daran gedacht, in Erwägung zu
ziehen, daß es auch noch andere Möglichkeiten zur Digitialisierung gibt,
als die eingebaute ADC. Unter anderem mehrere, die durchaus geeignet
wären, ein Poti als ein Eingabegerät verwendbar zu machen, und die
allesamt wesentlich genauer wären, als es die (technisch bedingt)
ohnehin sehr eingeschränkte Steuerungsmöglichkeit der Samplerate des
Audio-Teils erfordern würde.
Fazit:
Typische C-Library-User. Ungefähr so fantasievoll, kreativ und flexibel
wie deutsche Beamte.
Allerdings:
Du bist Anfänger, also noch viel weniger kompetent als diese
Dinosaurier, die wenigstens ihren eingefahrenen Kram wirklich
beherrschen.
Ohne C-Libraries kriegst du vermutlich überhaupt garnix gebacken.
Dadurch (und nur dadurch) wird EFFEKTIV für dich die Aussage dieser
Leute zur objektiven Wahrheit...
Du solltest du mal intensiv durchdenken, ob dir diese Abhängigkeit
gefällt.
Mir persönlich hat das "geht nicht" der C-ler jedenfalls niemals genügt
und ich habe sehr, sehr oft festgestellt: das geht doch (und noch
einiges mehr). Es macht halt leider nur überproportional viel Arbeit.
Das kann man machen, wenn es Hobby ist oder universitär, aber nicht,
wenn man verurteilt ist, Geld damit verdienen zu müssen. Oder dann, wenn
der gesparte Hardwareaufwand sich über die Stückzahl gegen den
Entwicklungsaufwand rechnet.
Karl H. schrieb:> Müsste man durchrechnen, was das für die maximale Samplingfrequenz> bedeutet.
Bei angenommenen 750kHz ADC-Takt sollten 50kHz drin sein, nimmt man
jedes 2te Ergebnis für das Poti, bleiben 25kHz.
Der Andere schrieb:> Irgendwie beschleicht mich das Gefühl, dass ihr hier weit oberhalb des> Erkenntnishorizonts des TOs diskutiert.
Für diesen Fall ist er selbst schuld, da er schrieb:
Rene schrieb:> Ich besitze Grundkenntisse im Programmieren und habe bereits Ideen zur> Umsetzung, bin aber für Anregungen offen.
MWS schrieb:> Bei angenommenen 750kHz ADC-Takt
:-)
Okay. Wenn du ans Limit gehst ....
> sollten 50kHz drin sein, nimmt man> jedes 2te Ergebnis für das Poti, bleiben 25kHz.
... kommts hin.
Jetzt muss es der TO nur noch umsetzen.
c-hater schrieb:> Unter anderem mehrere, die durchaus geeignet> wären, ein Poti als ein Eingabegerät verwendbar zu machen, und die> allesamt wesentlich genauer wären, als es die (technisch bedingt)> ohnehin sehr eingeschränkte Steuerungsmöglichkeit der Samplerate des> Audio-Teils erfordern würde.
Und du sprichst den TO da durch, der mit dem nun wirklich simplen ADC
des Mega8 schon überfordert ist.
Im Gegensatz zu dir benutzen wir Postings nicht dazu uns zu profilieren,
sondern gehen auch auf den Kentnisstand des TO ein und versuchen
Lösungen anzubieten, die er auch noch stemmen kann.
Statt eines Potentiometers würde ich einen Drehgeber nutzen. Siehe dazu:
https://www.mikrocontroller.net/articles/Drehgeber
Benötigt ebenfalls einen Timer. Passt also ganz gut zum Verfahren: ADC
mittels Timer-Interrupt anwerfen und darüber flexibel die Abtastfrequenz
einstellen.
Im Studium hatten wir im Labor einen ähnlichen Versuch. Ich glaube dort
waren Abtastfrequenz und Auflösung einstellbar. Sprache ist auch bei
3Bit Auflösung noch teilweise verständlich. Das war sehr eindrucksvoll.
Karl H. schrieb:> Im Gegensatz zu dir benutzen wir Postings nicht dazu uns zu profilieren,> sondern gehen auch auf den Kentnisstand des TO ein und versuchen> Lösungen anzubieten, die er auch noch stemmen kann.
Nein. Ihr versucht, die Lamer in ein Abhängigkeitsverhältnis zu bringen
und sie darin zu halten. Ihr benutzt dazu die natürliche Faulheit und
Unwissenheit der Mehrheit der Bevölkerung.
Natürlich ist es für den Anfänger geil, wenn er (relativ) schnell was
zum Laufen bekommt, keine Frage. Aber damit ist der Weg in den Abgrund
des "geht nicht" bereits vorprogrammiert.
Du selber bist doch das beste Beispiel dafür, wie die hier im Thread
erneut eindeutig gezeigt hast.
c-hater schrieb:> Nein. Ihr versucht, die Lamer in ein Abhängigkeitsverhältnis zu bringen> und sie darin zu halten.
Ach geh, bitte.
Was ist denn der Unterschied, wenn ich in C den ADC konfiguriere, indem
ich dem ADC Bits in den Konfigurationsregistern setze und wenn ich das
in Assembler mache.
Genau: gar keiner.
Selbiges für den Timer.
Sein Problem hat absolut gar nichts damit zu tun, in welcher Sprache er
programmiert. Hier geht es erst mal darum, das Konzept zu
verinnerlichen.
Ein Abhängigkeitsverhältnis kann ich da schon gar nicht erkennen. Es sei
denn, man bezeichnet das bischen Komfort, das man sich nicht mehr um
jeden Kleinkram selber kümmern muss und das man sich durch eine
Hochsprache erkauft, als Abhängigkeit.
> Du selber bist doch das beste Beispiel dafür, wie die hier im Thread erneut
eindeutig gezeigt hast.
Bis jetzt ist aber von dir noch gar kein konkreter Vorschlag gekommen,
wie er am ADC vorbei sein Poti auswerten könnte.
Lass mich raten: Mit dem Poti einen Kondensator aufladen und die Zeit
messen, die er benötigt um entweder die Schaltschwelle eines digitalen
Inputs zu übersteigen oder die Spannung am Kondensator mit dem Analogen
Comperator überwachen?
OK. Wenn du dem TO das zutraust, dann sprich ihn da durch. Ich trau ihm
das nicht zu. Zumindest nicht jetzt.
MWS schrieb:
> Bei angenommenen 750kHz ADC-Takt sollten 50kHz drin sein, nimmt> man jedes 2te Ergebnis für das Poti, bleiben 25kHz.
Braucht man diese schnelle Reaktion? Es wird vielleicht etwas träge,
aber wenn man das Potenziometer jede 1/10 s abfragt, sollte das doch
kaum hörbar sein und man behielte die 50 kHz.
MaWin schrieb:> Dein Atmega kann nicht mit 20kHz abtasten, schon gar nicht ausgeben, und> 10 bit sind eher wenig.
Natürlich kann ein Atmega8 auch mit 20 kHz abtasten. Lediglich das
Wanderrauschen nimmt dabei zu sodass man keine 10 bit mehr hat aber dem
TE genügen anscheinend auch 8 bit, da kann er den ADC auch mit 260 kHz
laufen lassen. Da hat er locker noch 8 bit.
MWS schrieb:> Bei angenommenen 750kHz ADC-Takt sollten 50kHz drin sein, nimmt man> jedes 2te Ergebnis für das Poti, bleiben 25kHz.
Du meinst sicher 650 kHz ;)
Dirk K. schrieb:> Statt eines Potentiometers würde ich einen Drehgeber nutzen.
Für ein Poti kann man sich auch was bauen mit Widerstand, Kondensator,
einem der Timer und dem Analogkomparator und Input-Capture. Geht
schneller als auf die Bestellung für den Drehgeber zu warten.
Hallo,
vielen Dank an alle, die konstukritve Vorschläge gemacht haben.
Alles ist nun wie folgt umgesetzt:
Poti wird per Timer2 jede Sekunde ausgelesen, auf 8Bit beschränkt, womit
die Abtastfrequenz geändert werden kann.
Die Abtastfrequenz wird durch Timer1 (für AD Wandlung der Musik)
bestimmt, der durch den Wert des Poti "vorgeladen" wird. Damit ist eine
Verstellung der Frequenz in 256 Schritten möglich.
Außerdem habe nun auch noch ein AVR-LCD angeschlossen, um die momentane
Abtastfrequenz auszugeben.
Die Musik-Wandelergebnisse(8Bit) gebe ich an einem PORT aus.
Die DA-Wandlung erfolgt übrigens nun nicht mehr mittels Baustein,
sondern mit einer "R2R Leiter".
Wenn jemand Fragen bei einer ählichen Umsetzung hat, stehe ich gerne zur
Verfügung.
Gruß
Karl H. schrieb:> Bis jetzt ist aber von dir noch gar kein konkreter Vorschlag gekommen,> wie er am ADC vorbei sein Poti auswerten könnte.> Lass mich raten: Mit dem Poti einen Kondensator aufladen und die Zeit> messen, die er benötigt um entweder die Schaltschwelle eines digitalen> Inputs zu übersteigen oder die Spannung am Kondensator mit dem Analogen> Comperator überwachen?
Das wäre eine Möglichkeit. Es gibt noch mehr. Wenn du weiter in den
Erinnerungen an dein Studium gräbst, fallen sie dir vielleicht auch die
anderen alle nach und nach noch ein...
Versteh' das bitte richtig: Ich glaube keinesfalls, dass du dumm oder
unwissend bist. Du gehst (wie die anderen eingeschworenen C-ler auch)
bloß immer irgendwie mit einer Art Scheuklappenblick an die Sachen
heran. Du bewertest deren Machbarkeit immer erstmal nur danach, was mit
den verfügbaren C-Libs realistisch machbar wäre.
Das ist der Punkt. Eine Machbarkeitsanalyse sollte immer von den
Fähigkeiten der Hardware ausgehen. Nur was die definitiv nicht leisten
kann, schließt man grundsätzlich aus.
Beim Rest kann man dann überlegen, ob man sich den Aufwand der
Entwicklung der entsprechenden Software antun will. Das ist aber ein
ganz anderes Thema.
Wenn du dich also dazu herablassen könntest, zukünftig einfach zu
schreiben: "In C unter Verwendung der allgemein verfügbaren Libs ist das
nicht realisierbar", wäre schon viel gewonnen. Nämlich zumindest die
objektive Darstellung des Sachverhalts.
Wenn dann noch irgendwer anders schreibt: "Die Hardware gäbe es her",
dann kann jeder selber entscheiden, ob er den Aufwand treiben möchte,
herauszufinden, woher die Lücke zwischen den beiden Sachverhalten kommt
und ob er bereit ist, den nötigen Aufwand zu ihrer Schließung zu
betreiben (was in aller Regel auf Asm-Programmierung in mehr oder
weniger großem Umfang hinausläuft)...
Ok.
Ganz konkret.
Wie wertest du ein Poti in einer Art und Weise aus, die ich mit C nicht
hinkriege? Es reicht, wenn du die Idee skizzierst.
Werd doch mal konkret. Welche Technik kann ich wegen meiner Scheuklappen
nicht sehen?
> "In C unter Verwendung der allgemein verfügbaren Libs ist das nicht
realisierbar"
In C gibt es keine 'allgemein verfügbaren Libs'. Es gibt im Zusammenhang
mit der AVR Programmierung lediglich einiges an Standard-Code, welcher
immer wieder gerne mal eingesetzt wird um sich Aufwand zu sparen. Hier
wird eben nicht immer wieder das Rad komplett neu erfunden, wenn es
erprobte und bewährte Lösungen gibt.
Abgesehen davon: Hältst du mich wirklich für so dämlich, dass damit mein
Repertoir erschöpft ist? Ich denke ich hab oft genug gezeigt, dass ich
auf Zuruf auch Lösungen aus dem Ärmel schütteln kann, für die zb im
Tutorial es noch keinen Code gibt.
Was du mir hier konkret vorwirfst, das ist, dass ich dem TO keine für
ihn massgeschneiderte Lösung präsentiere, wie er die zweite ADC Abfrage
zeitlich so in die erste schachteln kann, dass unabhängig von der
gewünschten Abtastfreuenz sich auch noch eine Poti Abfrage ausgeht. Gut.
Das kann man mir vorwerfen. Man kann mir auch vorwerfen, dass ich nicht
länger nach einer entsprechenden Lösung gesucht habe und mir da auch
nicht weiter Gedanken darüber gemacht habe. Das alles kann man mir
vorwerfen und dieser Vorwurf ist durchaus berechtigt.
Das hat aber nichts mit C zu tun! Du verwechselst ständig die
Möglichkeiten, die ich mit C habe, mit Überlegungen auf algorithmischer
Ebene. Das eine hat mit dem anderen nichts zu tun und lässt eher im
Gegenteil darauf schliessen, wie es um deine Fähigkeiten steht, etwas in
C auszudrücken. Frei nach dem Muster: wenn c-hater etwas in C nicht
hinkriegt, dann kriegt es keiner hin.(*)
Wie wäre es, wenn du da mal etwas von deinem hohen Ross runtersteigst
und nicht immer dich selbst als das Mass aller Dinge nimmst?
(*) Es gibt natürlich Dinge, die tatsächlich auf einem AVR in C nicht
mehr machbar sind, weil man beispielsweise das Timing nicht mehr
hinkriegt. Das alles wird immer wieder zugestanden, ist hier also kein
Argument.
c-hater schrieb:> Du bewertest deren Machbarkeit immer erstmal nur danach, was mit> den verfügbaren C-Libs realistisch machbar wäre.
Keiner außer Dir hat von irgendwelchen C-Libs gesprochen, die hast Du
plötzlich aus heiterem Himmel herbeigepredigt. Fällt Dir über die
Sprache C (welche übrigens gar nichts mit dem Thema des Threads zu tun
hat) nichts mehr zu "haten" ein, gehst Du stattdessen auf irgendwelche
ominösen nicht näher bezeichneten Libs los?
c-hater schrieb:>> [RC Zeitkonstante messen]> Das wäre eine Möglichkeit. Es gibt noch mehr. Wenn du weiter in den> Erinnerungen an dein Studium gräbst, fallen sie dir vielleicht auch die> anderen alle nach und nach noch ein...
Du hast hier die Möglichkeit mal was wirklich nützliches zu tun. Für
alle phantasielosen Bastler: Bitte zähle doch mal all die anderen
cleveren Möglichkeiten auf unkompliziert einen Widerstand zu messen ohne
den ADC zu bemühen.
