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.
:
Bearbeitet durch User
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ß
Rene schrieb: > Wenn keine Abtastung von 20kHz möglich ist, welche Frequenz ist maximal > umsetzbar? was steht denn im Datenblatt?
@ 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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
Irgendwie beschleicht mich das Gefühl, dass ihr hier weit oberhalb des Erkenntnishorizonts des TOs diskutiert.
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.
@c-hater Für einen Troll schreibst Du eindeutig zuviel Text. Das können andere wesentlich besser.
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.
:
Bearbeitet durch User
Wie wäre es mit einem ATtiny261 anstatt des ATmega8? Seine 'High Frequency PWM' mit 64 MHz könnte den externen DAC ersetzen.
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 ;)
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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?
:
Bearbeitet durch User
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.
Rene schrieb: > Die DA-Wandlung erfolgt übrigens nun nicht mehr mittels Baustein, > sondern mit einer "R2R Leiter". kalibiert?
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.