Mir ist aufgefallen, dass wenn ich das I2C-Display anspreche, andere Funktionen gestört sind. Das betrifft u.A. den Sinusgererator (für den 25Hz Pilotton). Ich musste das für die Unterspannungsanzeige mit einer if-else-millis()-Orgie lösen, die das Display wirklich nur einmal anspricht wenn die Unterspannung da ist oder eben nicht. Das stört nicht weiter, da die Anzeige Unterspannung nur im Fehlerfall auftritt und für eine Periode den Pilotton verbeult. Wenn ich mir den Audiopegel als Zahlenwert darstellen lassen will, bekomme ich aber ein Problem, weil dieser Wert sich ja häufig ändert. wie löst man das? Der Sketch ist dort hochgeladen: Beitrag "<rotary.h> mit bool "ein" und Ausschalten." LG old.
:
Gesperrt durch Moderator
Aus der W. schrieb: > wie löst man das? Indem mal mal guckt, wie die I²C-Library funktioniert: Ist si polling- oder interrrupt gesteuert? Ansonsten muss man sich sowas halt selber bauen. Arduino bedeutet nicht, dass die Funktionen optimal gebaut sind, sondern, dass sie akzeptabel funktionieren. Da kann es auch passieren, dass sie blockierend arbeiten.
Mehr als 2 mal die Sekunde braucht man kein Display updaten. Schneller liest kein Mensch. Ansonsten sollte man statt millis() lieber etwas vernüntfiges nehmen und gleich auf ein Echtzeitsystem wechseln (FreeRtos). Oder sich zumindest mit Interrupts anfreunden. Vielleicht sollte man sich auch im Voraus die Anforderungen klarmachen, bevor man anfängt auf einem kleinen Arduino zu prokeln.
Wenn Deine I2C-Library blockierend arbeitet dann musst Du dafür sorgen daß es die niedrigste Priorität bekommt, sprich alles andere was kritisch vom Timing ist muß in einen Interrupt. Dann kann I2C (und anderes unkritische Zeug) in der main loop herumtrödeln so sehr es will.
Gibt es denn für mich die Möglichkeit zumindest den 25Hz Sinus aus der Blockade rauszunehmen? LG old.
PittyJ schrieb: > Mehr als 2 mal die Sekunde braucht man kein Display updaten. Schneller > liest kein Mensch. Das ist doch wohl ein schwaches Argument. Guck dir mal an, wie das Spektrum eines 25Hz Pilottones aussieht, wenn er "nur" 2 mal in der Sekunde verunstaltet wird.
Bernd K. schrieb: > sprich alles andere was > kritisch vom Timing ist muß in einen Interrupt. Mal davon abgesehen, dass ich dazu nicht fähig bin … Der 25Hz Sinus muss ja ständig da sein und es würde nichts anderes mehr funktionieren. LG old.
Bernd K. schrieb: > Wenn Deine I2C-Library blockierend arbeitet dann musst Du dafür sorgen > daß es die niedrigste Priorität bekommt Das sagst du einem Arduino-User der es nicht mal schafft seine Code Kreation übersichtlich zu formatieren? Wie soll er mit deinen vagen Tips die Auslastung seines Arduinos auf die Reihe bringen?
OMG schrieb: > Das sagst du einem Arduino-User der es nicht mal schafft seine > Code Kreation übersichtlich zu formatieren? > > Wie soll er mit deinen vagen Tips die Auslastung seines Arduinos > auf die Reihe bringen? Eben. Ist ein Luxusproblem, die Pegelanzeige im Display ist nicht wirklich nötig. Für mich ist der Code übrigens so übersichtlich. Der Journalstreifenstiel a la Registrierkasse von stefanus ist gut gemeint aber nicht so meins. Ich werde sowieso die LM13700 für die ALC über einen PWM-Pin steuern. (Anders kann ich das gar nicht. Das Glück ist mit die Dummen.) LG old.
Aus der W. schrieb: > Mal davon abgesehen, dass ich dazu nicht fähig bin … > Der 25Hz Sinus muss ja ständig da sein und es würde > nichts anderes mehr funktionieren. Dann pack die Erzeugung des Sinus in einen Timer-Interrupt. Wie machst Du das überhaupt? DDS mit Lookuptabelle und ADC? Tu das in nen Timer-Interrupt und fertig!
Aus der W. schrieb: > Der 25Hz Sinus muss ja ständig da sein und es würde > nichts anderes mehr funktionieren. Hier siehst du ein Beispiel, wie du dich an den Timer0-Interrupt, der auch für millis() den Takt bereit stellt, einklinken kannst. https://learn.adafruit.com/multi-tasking-the-arduino-part-2/timers Dann kannst du im 1ms Takt einen Software DDS-Generator für die 25Hz-Ausgabe aktualisieren.
Aus der W. schrieb: > Mir ist aufgefallen, dass wenn ich das I2C-Display anspreche, > andere Funktionen gestört sind. > Das betrifft u.A. den Sinusgererator (für den 25Hz Pilotton). Das passiert eben, wenn man alles in der Mainloop hintereinander klatscht und keine Interrupts verwendet. Packe den Sinus einfach in einen Timerinterrupt, dazu sind Interrupts ja da.
Aus der W. schrieb: > Mir ist aufgefallen, dass wenn ich das I2C-Display anspreche, > andere Funktionen gestört sind. Dann solltest du I2C-LCD-Lib ankucken, warum das passiert. Somit lernst du auch etwas. Das erleichtert dir die Zukunft. Es könnte auch Problem mit der Schaltung sein: z.B. Lib wartet auf Busy, aber Pin R/~W ist fest an GND und somit kein Lesen aus LCD überhaupt möglich. Dann wartet Lib so lange, bis irgendein Mechanismus für Fehlerbehandlung die Versuche zu lesen umgeht. Selbstverständlich macht Mikrocontroller während diesen Leseversuchen nichts anderes und somit ist das Programm blockiert.
:
Bearbeitet durch User
Maxim B. schrieb: > Somit lernst > du auch etwas. Das lerne ich nicht mehr und mir fehlt auch das Talent dazu. Entweder bekomme ich Hilfe oder eben nicht. Was ich noch nicht getestet habe ist, ob der Rotaty mit seinen Interrupts, bei parallelem Display, mir auch den Sinus plattmacht. LG old.
Aus der W. schrieb: > Das lerne ich nicht mehr und mir fehlt auch das Talent dazu. > Entweder bekomme ich Hilfe oder eben nicht. Falls ich den Thread "richtig" gelesen habe: Dir wurde gesagt, woran es liegt, und was zu tun ist. Der Ball ist jetzt bei dir.
Aus der W. schrieb: > Maxim B. schrieb: >> Somit lernst >> du auch etwas. > > Das lerne ich nicht mehr und mir fehlt auch das Talent dazu. Warum beschäftigst Du Dich dann überhaupt mit solchen extrem speziellen Tätigkeiten wie µC-Programmierung die nun wirklich normalerweise nur von Leuten ausgeübt werden die da irgend nen inneren Drang oder Interesse für die Materie haben? Das ist ungefähr so als ob Du sagst Du möchtest gerne Deiner Verwandtschaft was auf dem Klavier vorspielem aber Du hast keine Lust es zu lernen und auch kein Talent dazu. Ja WTF, warum denn dann??? Warum nicht was anderes stattdessen, etwas was Dich auch interessiert? > Entweder bekomme ich Hilfe oder eben nicht. Die hast Du bekommen. Viele Stichworte zum Googeln und konkrete Vorschläge.
Bernd K. schrieb: > Warum beschäftigst Du Dich dann überhaupt mit solchen extrem speziellen > Tätigkeiten wie µC-Programmierung Vermutlich wurde er von einem Arduino Vermarkter dazu gebracht. Die erzählen ja der ganzen Welt, dass die Programmierung ganz einfach ist und dass man eigentlich gar keine Fachkräfte mehr braucht, weil das jede Putzfrau kann.
Was zu tun ist, habe ich getan. Die Unterspannungsanzeige funktioniert. Für die Audiopegelanzeige habe ich LEDs, die definitiv besser sind als eine sich ändernde Zahl auf einem trägen Display. Jedenfalls weiß ich jetzt weshalb ich mir für die Unterspannungsanzeige einen Abbrechen musste. Auch die Lautstärkeeinstellung mit dem Rotary werde ich nicht ausführen, weil ich eine ALC dafür "programmiere". Natürlich ohne I2C, Interrupt und wie immer in der void loop. Und jetzt wird erstmal nur noch gelötet ... LG old.
Bernd K. schrieb: > Warum beschäftigst Du Dich dann überhaupt mit solchen extrem speziellen > Tätigkeiten wie µC-Programmierung die nun wirklich normalerweise nur von > Leuten ausgeübt werden die da irgend nen inneren Drang oder Interesse > für die Materie haben? Das was ich mit dem Arduino machen kann ist schon weit mehr als ich mir je erträumt habe. > Das ist ungefähr so als ob Du sagst Du möchtest > gerne Deiner Verwandtschaft was auf dem Klavier vorspielem aber Du hast > keine Lust es zu lernen und auch kein Talent dazu. Ja WTF, warum denn > dann??? Warum nicht was anderes stattdessen, etwas was Dich auch > interessiert? Was wollt Ihr denn? Ihr baut doch vorgekochte Analogschaltungen an den Prozessor ohne zu verstehen wie die Analogschaltung arbeitet? Da kommt doch auch keiner und sagt, Du darfst das nicht. LG old.
Aus der W. schrieb: > Das was ich mit dem Arduino machen kann ist schon weit mehr als > ich mir je erträumt habe. Da dann ist ja alles in Ordnung. Hier bist du an die Grenzen gestoßen. Ist nicht weiter schlimm.
Aus der W. schrieb: > Was wollt Ihr denn? Ihr baut doch vorgekochte Analogschaltungen > an den Prozessor ohne zu verstehen wie die Analogschaltung > arbeitet? Da kommt doch auch keiner und sagt, Du darfst das > nicht. Du musst nicht von Dir auf andere schließen. Viele haben die Elektronik von der Pike an gelernt. Ich spreche hier von einer vollständigen Ausbildung oder ein Studium.
Aus der W. schrieb: > Das lerne ich nicht mehr und mir fehlt auch das Talent dazu. Das ist nicht schlimm: jemand sollte auch Straßen putzen. Wenn alle Akademiker wären, wer sollte das tun?
Christian H. schrieb: > Du musst nicht von Dir auf andere schließen. Viele haben die Elektronik > von der Pike an gelernt. Ich spreche hier von einer vollständigen > Ausbildung oder ein Studium. Und? Bis vor kurzem konntet Ihr weder mit einem XOR eine Frequenz verdoppeln, noch danach einen Sinus formen. Also mal den Ball flach halten. Beitrag "Frequenzverdoppeln 74XXX Gatter ?" Beitrag "Wie aus Rechteck im Bereich von 100KHz bis 2MHz Sinus machen (5V)." LG old.
Aus der W. schrieb: > Und? Bis vor kurzem konntet Ihr weder mit einem XOR eine > Frequenz verdoppeln, noch danach einen Sinus formen. > Also mal den Ball flach halten. "Ihr" gleich alle? Was soll diese Verallgemeinerung?
Christian H. schrieb: > "Ihr" gleich alle? Ja, auch Du bist gemeint. Hattest zwei Jahre Zeit eine Lösung zu finden. Und auch der Fehler in der Zeichnung vom selbsternannten Elektronikkompendium hält sich wacker. Mit falschem Grundwissen kommt man halt nicht drauf. LG old.
Aus der W. schrieb: > Hattest zwei Jahre Zeit eine Lösung zu finden. Ich wünsche Dir viel Spaß, Dein Problem selber zu lösen.
Lesen und Verstehen tust Du nicht. Von der Pike an. Beitrag "Re: I2C "blockiert" Arduino" Leere Worte, nichts dahinter. Wie so oft.
Angehängte Dateien:
-
223-238.png
8 KB
Aus der W. schrieb: > Auch die Lautstärkeeinstellung mit dem Rotary Um auszuschließen, dass der Rotary mit seinen Interrupts den Arduino blockiert, habe ich die Displayansteuerung deaktiviert. Bild. Die Frequenz lässt sich verstellen, der 25Hz Pilot bleibt davon unbeeindruckt. Es liegt also ausschließlich an der <LiquidCrystal_I2C.h>. Ich werde nach Alternativen dafür suchen und sie testen. LG old.
Aus der W. schrieb: > Ich werde nach Alternativen dafür suchen und sie testen. Die Alternative lautet: Die Erzeugung der 25Hz muss offensichtlich anders implementiert werden da sie in der jetzigen Form unzuverlässig ist. Es hat absolut nichts mit I2C zu tun, Du hast falsche Vorstellungen davon wie das normalerweise funktionieren und zusammenspielem muss, deshalb kommst Du zu falschen Diagnosen. Es ist die 25Hz-Erzeugung die hier offensichtlich falsch implementiert ist. __ PS: Der Code im anderen Thread auf den Du verweist ist ein vollkommen unleserlicher Müllhaufen, Du könntest den zumindestens mal halbwegs anständig formatieren und einrücken und nen einheitlichen Klammerstil anwenden damit man ihn überhaupt ansatzweise lesen kann wenn Du mit uns darüber diskutieren möchtest. Es zeugt von einer unaussprechlichen Fehleinstellung wenn Du glaubst Du kannst so einen unleserlich hingerotzten Müllhaufen ins Forum rotzen um es allen potentiellen Helfern extra schwer zu machen weil sie ertmal knietief durch den Müll waten müssen um irgendwas darin zu sehen und dann dennoch zu erwarten prompt geholfen zu bekommen! Es ist fast so als ob Du bevor Du Deine Schuhe zum Reparieren der Absätze zum Schuhmacher bringst vorher nochmal durch 20cm tiefen Schlamm und Matsch und anderen Dreck gestiefelt wärst und sie dann direkt in dem massiv verdreckten Zustand dort auf den Ladentisch knallst daß der Dreck 2 Meter weit in alle Richtungen fliegt anstatt vorher wenigstens mal kurz wenigstens den gröbsten Dreck zu entfernen, es würde schon reichen sie vor der Tür nochmal kurz ordentlich abzuklopfen, nicht mal das hast Du gemacht! Also mach das gefälligst, mach das wenigstens halbwegs grob sauber bevor Du das hier vorlegst! Das ist eine Unhöflichkeit sondersgleichen! Was ist falsch gelaufen mit euch Arduino-Typen daß ihr alle so unterwegs seid, daß ihr selbst so grundlegende Dinge nicht merkt? Wenn es aber so ist daß Du gar keine Hilfe willst dann hör auf Deine Selbstgespräche hier zu posten!
:
Bearbeitet durch User
Bernd K. schrieb: > Die Alternative lautet: Die Erzeugung der 25Hz muss offensichtlich > anders implementiert werden Nö, dass betrifft auch andere Funktionen die der Prozessor ausführen muss. Komisch, dass die Putzfrau das dem Programmierer erst schreiben muss. Bernd K. schrieb: > wenn Du glaubst Du kannst so einen unleserlich > hingerotzten Müllhaufen ins Forum rotzen um es allen potentiellen > Helfern extra schwer zu machen weil sie ertmal knietief durch den Müll > waten müssen um irgendwas darin zu sehen und dann dennoch zu erwarten > prompt geholfen zu bekommen! Du erkennst weder das Problem noch die Folgen und hast keine Lösung. Da wirft der Programmierer halt Nebelkerzen. Übrigens hat User stefanus hat den Sketch doch für Euch mundgerecht bearbeitet. Also meckere nicht rum! Die Lösung der Putzfrau das Display nur dann anzusprechen wenn nötig, hat das Problem gelöst. Mag sein, dass es bessere Alternativen gibt. Die Putzfrau meistert das Ding auch so. Bernd K. schrieb: > Wenn es aber so ist daß Du gar keine Hilfe willst dann hör auf Deine > Selbstgespräche hier zu posten! Die Programmierer mit Erfolgen zu piesacken und ihnen zu Zeigen, dass es auch ohne sie geht, macht der Putze durchaus Freude. :) Die Putzen teilen ihre Erfahrungen im Internet und kommen so zum Erfolg. Beitrag "Re: I2C "blockiert" Arduino" LG old.
Aus der W. schrieb: > Nö, dass betrifft auch andere Funktionen die der Prozessor > ausführen muss. Die sind aber vielleicht nicht so zeitkritisch wie die saubere 25Hz Erzeugung. Hat was mit Priorisierung zu tun ... Häng das Ding in einen Timer0-Interrupt mit rein und gut ist.
Aus der W. schrieb: > Du erkennst weder das Problem noch die Folgen und hast keine Lösung. Das sagt der Mann(?), welcher weder das Problem begreift, noch die Lösung umsetzen kann. Denn sonst könnte nicht so ein irriger Ansatz folgen.. Aus der W. schrieb: > Es liegt also ausschließlich an der <LiquidCrystal_I2C.h>. > Ich werde nach Alternativen dafür suchen und sie testen. Klarer Fall: Problem nicht begriffen.
Bernd K. schrieb: > Was ist falsch gelaufen mit euch Arduino-Typen daß ihr > alle so unterwegs seid, daß ihr selbst so grundlegende Dinge nicht > merkt? Wieder das übliche Arduino Bashing. Die neurotische Fehlanpassung eines einzelnen wird gegen Arduino gerichtet, und alle User in einen Topf geworfen. Warum versuchst mich mit diesem ***** in einen Topf zu werfen? Welche Befriedigung verschafft dir das? Eins kann ich dir versprechen: Auch in den Arduino Foren wird zu einer lesbaren Formatierung erzogen. Und solche ***** bekommen dort heftigen Gegenwind, überleben dort nicht lange, oder passen sich an.
Arduino Fanboy D. schrieb: > Klarer Fall: > Problem nicht begriffen. Klarer Fall: Bug in der <LiquidCrystal_I2C.h>. Das hier darf gar nicht auftreten. STK500-Besitzer (Gast) hat ja erklärt wo es hakt. Der AD9850 wird auch seriell angesprochen und das ohne Auswirkungen auf andere Programmteile. Arduino Fanboy D. schrieb: > lesbaren Formatierung Für mich ist die lesbar. Und wenn ich das kann, können das andere auch. Ich weiß nicht aus welcher Dekade Eure Formatierung stammt. Möglicherweise nutzte man damals Registrierkassen mit Kassenrolle als Terminal. Die Arduino-Umgebung erlaubt mehr als 10 Zeichen pro Zeile und das nutze ich auch der Übersichtlichkeit halber. Ganze Zeilen für Anmerkungen und Leerzeilen vermeide ich, Zeilen werden nummeriert um schnell Programmteile zu finden. Ausschweifende Erklärungen werden unten angehangen. Da ich einen Sketch erweitert habe, ist das noch nicht durchgängig so. LG old.
Aus der W. schrieb: > Arduino Fanboy D. schrieb: >> lesbaren Formatierung > > Für mich ist die lesbar. Und wenn ich das kann, können > das andere auch. Dieser Meinung ist der Joseph G aka bome bei seinem 8-Bit-Retro-Computer auch...
Aus der W. schrieb: > Bug in der <LiquidCrystal_I2C.h>. Wow! Wie bist du darauf gekommen? Kannst du den Bug zeigen? > Das hier darf gar nicht auftreten. Ich hoffe, das ist nicht die einzige Begründung. Hey, da ist ein Bug und ich weiß das ganz genau, weil er nicht auftreten dürfte. So hast du es hoffentlich nicht gemeint.
Aus der W. schrieb: > Für mich ist die lesbar. Aus dem Code: > }}} Am Ende von Funktionen: > }; An den linken Rand geklebt. Aus der W. schrieb: > Und wenn ich das kann, können das andere auch. Nicht jeder will sich deine durchgekauten Kaugummi in den Mund stecken. Meine Sicht: Wer anderen das Lesen erschwert, will keine Hilfe. Aus der W. schrieb: > Klarer Fall: > Bug in der <LiquidCrystal_I2C.h>. Klarer Fall, Irrtum in der Sache. Aus der W. schrieb: > STK500-Besitzer (Gast) hat ja erklärt wo es hakt. Hat er, du aber seinen Beitrag nicht verstanden. Und darum geht die Lösung auch an dir vorbei. Rundrum: Keinerlei Einsicht zu erkennen.
Arduino Fanboy D. schrieb: > Rundrum: Keinerlei Einsicht zu erkennen. Bei Dir auch nicht. Und? Mir egal, Hilfe kommt von Dir eh nicht. Auch nicht mit der Formatierung von stefanus. Ich komme mit allen Formatierungen zurecht, egal ob der Code so }}} oder so } } } geschrieben wurde. Schaltpläne, auch französische und fritzing sind für mich kein Problem. LG old.
Aus der W. schrieb: > Klarer Fall: > Bug in der <LiquidCrystal_I2C.h>. > Das hier darf gar nicht auftreten. > STK500-Besitzer (Gast) hat ja erklärt wo es hakt. > > Der AD9850 wird auch seriell angesprochen und das > ohne Auswirkungen auf andere Programmteile. Old, das von dir geschilderte Problem (Störung des 25Hz-Sinus durch LiquidCrystal_I2C) ist generell nicht trivial zu beheben. Es stellen sich da Fragen nach zum Beispiel den längsten Zeiten von Interrupt-Unterdrückung in den Bibliotheken. Bug ist zudem ein hartes Wort. Es bedeutet ja nicht, nicht den Wünschen entsprechend, sondern nicht der Spezifikation entsprechend. Und die Arduino-Bibliotheken sind (wie viele andere) notorisch unterspezifiziert. Seriell ist auf dem Atmega328P auch nicht ganz so zeitkritisch wie I2C, weil die USART nicht direkt aus UDR sendet sondern UDR zum Senden erst in ein shift register kopiert, während die TWI-Unit direkt aus TWDR die Bitpegel generiert. LG, Sebastian
:
Bearbeitet durch User
Stefanus F. schrieb: > Wow! Wie bist du darauf gekommen? Mit dem Oszilloskop. > Kannst du den Bug zeigen? Nein. Aber Der Gast hier könnte das möglicherweise: Beitrag "Re: I2C "blockiert" Arduino" LG old.
Aus der W. schrieb: > Hilfe kommt von Dir eh nicht. Sie kommt nicht an. Der Sender kann machen, was er will, wenn der Empfänger taub ist. Man lese nur, was der STK500-Besitzer gesagt hat, und was du daraus gemacht hast. > Klarer Fall: > Bug in der <LiquidCrystal_I2C.h>. Bernd K. (prof7bit) postet die richtige Lösung, und was machst du draus? > Klarer Fall: > Bug in der <LiquidCrystal_I2C.h>. Was soll ich dazu noch sagen? Außer, dich auf die Diskrepanz hinzuweisen. Auswerten musst du das gesagte schon selber. Und ja, Formatierung ist Geschmackssache! Zwei wesentliche Linien, es gibt: Den 1TBS und den, wo die zusammengehörigen Geschweiften in einer Spalte stehen. Den ersten kann ich lesen, den zweiten bevorzuge ich selber. Aber, was du ablieferst ist weit jenseits davon. Ich kann nur raten, entweder verstehst du den Sinn dahinter nicht, oder du verweigerst die Einsicht.
Sebastian W. schrieb: > Old, das von dir geschilderte Problem (Störung des 25Hz-Sinus durch > LiquidCrystal_I2C) ist generell nicht trivial zu beheben. Es stellen > sich da Fragen nach zum Beispiel den längsten Zeiten von > Interrupt-Unterdrückung in den Bibliotheken. Dann ist es ratsam nicht generell ein I2C Display zu verwenden, sondern nur wenn das aufgrund mangelnder I/O-Pins absolut notwendig ist. Und dann halt tunlichst darauf achten, das Display nicht bei jeder loop neu zu beschreiben, was man beim parallelen Anschluss ja machen darf. Wenn ich da jetzt keine Lösung gefunden hätte, müsste eben ein zweiter Atmega, nur für die Audioanwendungen, auf die Leiterplatte. Wobei ich dann ein größeres Gehäuse ... LG old.
Aus der W. schrieb: >> Kannst du den Bug zeigen? > Nein. Aber Der Gast hier könnte das möglicherweise: > Beitrag "Re: I2C "blockiert" Arduino" Das Problem wurde dir schon aufgezeigt! Es ist nicht die LiquidCrystal_I2C.h Wie das Arduino Wire Lib funktioniert ist dokumentiert(halbwegs) und sie liegt im Quellcode vor. Wie schon gesagt, die Lösung steckt hier: Beitrag "Re: I2C "blockiert" Arduino" ---- Mach was draus, oder lass es.
Aus der W. schrieb: > Sebastian W. schrieb: >> Old, das von dir geschilderte Problem (Störung des 25Hz-Sinus durch >> LiquidCrystal_I2C) ist generell nicht trivial zu beheben. Es stellen >> sich da Fragen nach zum Beispiel den längsten Zeiten von >> Interrupt-Unterdrückung in den Bibliotheken. > > Dann ist es ratsam nicht generell ein I2C Display zu verwenden, > sondern nur wenn das aufgrund mangelnder I/O-Pins absolut > notwendig ist. Und dann halt tunlichst darauf achten, das > Display nicht bei jeder loop neu zu beschreiben, was man > beim parallelen Anschluss ja machen darf. Wenn ich deinen Quellcode richtig verstehe, dann erzeugst du den 25Hz-Sinus indem du bei jedem Durchlauf durch loop() den Duty-Faktor eines PWM-Signals anpasst, richtig?
1 | pwmDuty = 128 +126 * sin(micros() * 0.000157); |
2 | analogWrite(5, pwmDuty); // 25Hz PWM an Pin12 Atmega |
Und dabei beobachtest du auf dem Oszilloskop Artefakte, korrekt? Wie sieht die Störung des 25Hz-Sinus Analogsignals denn auf dem Oszi genau aus? Es kann nämlich auch an Überlagerungen zwischen der PWM-Frequenz und der loop()-Rate liegen ... LG, Sebastian
Aus der W. schrieb: > Es liegt also ausschließlich an der <LiquidCrystal_I2C.h>. > Ich werde nach Alternativen dafür suchen und sie testen. Eine Alternative wäre, dass du die LCD-Zugriffsorgie weg lässt und durch eine kompakte Übertragung von deinen anzuzeigenden Bytes ersetzt. Dazu legst du dir das Zeugs vorher im Speicher zurecht und schickst dann einen Befehl ans LCD. Die Übertragung machst du direkt nachdem der 25Hz Generator mit Daten versorgt wurde. Dann jittert das LCD Update aber nicht der Generator. Mit dem Logikanalysator klärst du vorher, ob die LCD-Übertragung zeitlich zwischen zwei Generator-Updates passt - sollte aber bei 400kBit/s auf dem I2C kein Problem sein, solange du nicht Kommandos mit langer Ausführungszeit schickst (z.B. Return Home Commando)
Sebastian W. schrieb: > Wenn ich deinen Quellcode richtig verstehe, dann erzeugst du den > 25Hz-Sinus indem du bei jedem Durchlauf durch loop() den Duty-Faktor > eines PWM-Signals anpasst, richtig? >
1 | > pwmDuty = 128 +126 * sin(micros() * 0.000157); |
2 | > analogWrite(5, pwmDuty); // 25Hz PWM an Pin12 Atmega |
3 | >
|
Ohne die ständige sin-Berechnung würde es dem AVR doch langweilig werden.
Sebastian W. schrieb: > Es stellen > sich da Fragen nach zum Beispiel den längsten Zeiten von > Interrupt-Unterdrückung in den Bibliotheken. Wenn diese I2C-Library allerdings irgendwelche Interrupts blockiert dann wäre sie in der Tat fehlerhaft und deren Autor als vollkommen unfähig enttarnt und müsste nochmal 4 bis 6 Monate lang in die Ohrfeigenmaschine eingespannt werden für die Straftat sowas zu veröffentlichen.
Bernd K. schrieb: > Wenn diese I2C-Library allerdings irgendwelche Interrupts blockiert dann > wäre sie in der Tat fehlerhaft und deren Autor als vollkommen unfähig > enttarnt und müsste nochmal 4 bis 6 Monate lang in die Ohrfeigenmaschine > eingespannt werden für die Straftat sowas zu veröffentlichen. Die Lib benutzt selber Interrupts, für den Verkehr mit der TWI Einheit. Wie es auch Serial tut und der Timer für millis() und seine Brüder. Sperrt sie also nicht. Zumindest nicht lange. Diese Interruptlaufzeiten scheinen kein Problem zu sein. Was allerdings blockiert, ist die Wire::endTransmission() Methode. Während sie auf das Ende der I2C Kommunikation wartet, ist allerdings genug Zeit für andere Interrupts.
Arduino Fanboy D. schrieb: > Was allerdings blockiert, ist die Wire::endTrannsmission() Methode. > Während sie auf das Ende der I2C Kommunikation wartet, ist genug Zeit > für andere Interrupts. Dagegen ist ja auch nichts einzuwenden. Blockierende Methoden blockieren nun mal, das liegt in der Natur ihrer Sache. Solange sie dabei alle anderen Interrupts unbeeinträchtigt lässt ist das auch vollkommen OK. Man muss halt wissen wie man in seinen Programm mit blockierenden Methoden umzugehen hat und wie man den Rest seines Programms dann gestaltet damit er immer noch funktioniert. Im Falle des OP schlage ich vor daß er seine DDS in einem Timer-Interrupt verfrachtet, am besten einen der ein ganzzahliges Vielfaches von 100Hz (=4*25) ist, dann kann er auch ne simple Lookuptabelle für den ersten Quadranten nehmen anstatt den Sinus immer und immer wieder zu Fuß auszurechnen.
:
Bearbeitet durch User
Bernd K. schrieb: > Man muss halt wissen wie man in seinen Programm mit blockierenden > Methoden umzugehen hat und wie man den Rest seines Programms dann > gestaltet damit er immer noch funktioniert. So ist es wohl.... (aber hier nicht gegeben(?)) Bernd K. schrieb: > Im Falle des OP schlage ich vor daß er seine DDS in einem > Timer-Interrupt verfrachtet, am besten einen der ein ganzzahliges > Vielfaches von 100Hz (=4*25) ist, dann kann er auch ne simple > Lookuptabelle für den ersten Quadranten nehmen anstatt den Sinus immer > und immer wieder zu Fuß auszurechnen. Timer0 läuft mit knapp unter 1000Hz (auf 16MHz AVR Arduinos) Der hat noch 2 Interruptquellen frei. Alternativ: Die anderen Timer verwenden...
Carl D. schrieb: > Ohne die ständige sin-Berechnung würde es dem AVR doch langweilig > werden. Ja, L und R muss er auch ständig aus Summen und Differenzsignal berechnen. Mir wird dieser Thread auch langweilig. Es tut sich nichts bis auf ein paar Trolle, die sich trollen. Heute habe ich die Unterspannungserkennung und den Taster auf A1 und den Reset vom AD9850 auf A0 gelegt. Jetzt habe ich einen PWM-Pin frei für die LS-Steuerung. Das genügt mir für heute. Als nächstes versuche ich dann eine Spannung über die PWM bei gedrücktem Pushbutton Rotary für die Lautstärke zu bekommen. Als übernächstes den Wert in den Speicher zu schreiben um ihn beim Wiedereinschalten zu bekommen. Damit bin ich erstmal beschäftigt. Als Muster zur Orientierung habe ich ja die Frequenzeinstellung. Übrigens braucht der AD9850 den Reset nur beim Einschalten. Die Frequenzeinstellung macht der ohne Reset und kommt auch nach dem Drehen am Rotary ohne Reset mit der eingestellten Frequenz. Das zur Info. Ich könnte also auch mit dem bool "start" einmal die Frequenz schreiben lassen und den Resetpin an GND löten. Das spart einen Pin. LG old.
Aus der W. schrieb: > Ich musste das für die Unterspannungsanzeige mit einer > if-else-millis()-Orgie lösen Du mußtest nicht, sondern Du wolltest es so. Wenn Du mal die Funktion des Codes beschreiben würdest, könnte man das sicher viel einfacher lösen. Aus der W. schrieb: > Klarer Fall: > Bug in der <LiquidCrystal_I2C.h>. > Das hier darf gar nicht auftreten. Klarer Fall, daran liegt es also garantiert nicht. Wie kommt einer bloß darauf, Quelltext als PNG zu posten. Jeder, der länger als 3 Tage programmiert, weiß, daß das als Sakrileg empfunden wird. Was stört Dich an C oder INO? Überhaupt zerlegt niemand Zahlen händisch in dezimal, bestenfalls für sehr kleine MCs (ATtiny13). Man benutzt z.B. sprintf().
:
Bearbeitet durch User
PittyJ schrieb: > Mehr als 2 mal die Sekunde braucht man kein Display updaten. > Schneller > liest kein Mensch. Hat nichts mit dem Prpblem zu tun (der hat keinen plan) > > Ansonsten sollte man statt millis() lieber etwas vernüntfiges nehmen und > gleich auf ein Echtzeitsystem wechseln (FreeRtos). > Oder sich zumindest mit Interrupts anfreunden. Ein RTOS jemandem zu empfehlen, der keine Ahnung hat warum lahme Operationen anderes blockieren, sehr Sinnfrei > > Vielleicht sollte man sich auch im Voraus die Anforderungen klarmachen, > bevor man anfängt auf einem kleinen Arduino zu prokeln. Jepp. Einfach nur Jepp.
PittyJ schrieb: > Vielleicht sollte man sich auch im Voraus die Anforderungen klarmachen, > bevor man anfängt auf einem kleinen Arduino zu prokeln. Das hat nichts mit der Größe zu tun, mit dem falschen Programmaufbau bricht auch ein 64Bit 8-Kerner zusammen. Nur verlangt der Autor, daß jeder Helfende die Funktion des Programmes gefälligst aus seinem Kraut und Rüben Code zurück entwickeln soll. Ohne Beschreibung keine Hilfe, so einfach ist das.
Aus der W. schrieb: > Übrigens braucht der AD9850 den Reset nur beim Einschalten. > Die Frequenzeinstellung macht der ohne Reset und kommt > auch nach dem Drehen am Rotary ohne Reset mit der eingestellten > Frequenz. Da hatte ich den Reset noch nicht an GND gelötet. > Ich könnte also auch mit dem bool "start" > einmal die Frequenz schreiben lassen und den Resetpin an GND > löten. Das spart einen Pin. Noch besser: Reset vom AD9850 an GND, die Zeilen den Reset betreffend aus dem Code löschen, das war es schon. Der Sketch schiebt beim Start sowieso die Frequenz in den AD9850 und macht den Reset überflüssig. LG old.
Angehängte Dateien:
-
252-254.png
17 KB
Peter D. schrieb: > Ohne Beschreibung keine Hilfe, so einfach ist das. Klick mal auf den link in Zeile 252 du Schlaumeier. Sebastian W. schrieb: > Wenn ich deinen Quellcode richtig verstehe Zeile 254. Im Code. Für Euch kann man sich nur noch fremdschämen. Leider sind die Zeilennummern nicht in der Codeansicht sichtbar. Deshalb als PNG. (Bemängele ich nicht zum ersten mal.) LG old.
Wieso nennt der sich eigentlich "Aus der Werkstatt", das ist doch eher "Aus der Anstalt". Und es liegt nicht an den Röhren, der kann das auch digital.
Aus der W. schrieb: > Klick mal auf den link in Zeile 252 du Schlaumeier. Ich fange ein Buch auch immer hinten an zu lesen... *** Der Code bricht einfach mit Einrückungsregeln, die ich gewohnt bin. z.B. wozu gehören die geschweiften Klammern?
1 | lcd.setCursor(0,1); lcd.print(hertz);}} |
*** storeMEM() funktioniert erst wenn showFreq() aufgerufen wurde. Ein fiese Falle. *** Copy & Paste Programmierung... Das wird doch sicher alles sehr ähnlich verwendet.
1 | bool clip; |
2 | unsigned long cstart; |
3 | unsigned long cist; |
4 | unsigned long causverz = 200; // MF Clippanzeige |
5 | bool voll; |
6 | unsigned long vstart; |
7 | unsigned long vist; |
8 | unsigned long vausverz = 500; // MF Vollaussteuerung |
9 | bool sum; |
10 | unsigned long sumstart; |
11 | unsigned long sumist; |
12 | unsigned long sumausverz = 1000; // MF Summensignal |
13 | bool diff; |
14 | unsigned long diffstart; |
15 | unsigned long diffist; |
16 | unsigned long diffausverz = 1000; // MF Differenzsignal |
*** Magische Konstanten wie z.B. -356 -> Das macht es einfach schwer den Code zu lesen.
yesitsme schrieb: > z.B. wozu gehören die geschweiften Klammern? Gehe ich recht in der Annahme, dass Du die Arduino- Umgebung nicht auf Deinem Rechner hast? Für das Weitere siehe Seiten 16 und 17, Kap. 7 Analoger Input - Output im Arduino- Programmierhandbuch von DK2JK. Gibt es frei im Netz. LG old.
Carl D. schrieb: >> pwmDuty = 128 +126 * sin(micros() * 0.000157); Allein für diese eine Codezeile würde ich gern mal das listing sehen...
Aus der W. schrieb: > Programmierhandbuch von DK2JK http://www.ov-meschede.de/wp-content/uploads/2018/05/Arduino-Programmierhandbuch.pdf
Aus der W. schrieb: > Für das Weitere siehe .....im Arduino- > Programmierhandbuch von DK2JK. Gibt es frei im Netz. Da solltest du dir mal die Quellcode Formatierung anschauen. Der/Die/Das kann das. Selbst Strg-T macht das besser(als du). Aus der W. schrieb: > dass Du die Arduino- > Umgebung nicht auf Deinem Rechner hast? Lade dein Programm in die IDE und drücke Strg-T Kostet nichts und tut kaum weh.
Moin, äxl schrieb: > Carl D. schrieb: >>> pwmDuty = 128 +126 * sin(micros() * 0.000157); > > Allein für diese eine Codezeile würde ich gern mal das listing sehen... Da muesste wohl noch ein Additionstheorem mit rein, sonst wird das bestimmt zu schnell... Duck&Wech WK
Aus der W. schrieb: > Klick mal auf den link in Zeile 252 du Schlaumeier. Da passiert nichts, in einem PNG kann man keinen Link anklicken. Warum willst Du es einem immer maximal schwer machen? Links gehören in das Posting und nicht in irgendwelche Anhänge. Und auch immer gleich an den Anfang, damit man sehen kann, worauf sich eine Frage bezieht. Das mit den Zeilennummern stört keinen. Die meisten öffnen einen Anhang eh in ihrer Lieblings-IDE und schauen, ob es überhaupt compiliert und welche Warnungen es gibt. Du solltest daher immer Zeilennummern angeben, auf was sich Deine Frage bezieht. Aber erstmal AStyle drüber jagen zu müssen, das ist mir dann doch zu blöd. Und ja, die meisten hier haben kein Arduino installiert, können aber trotzdem auf C Fragen sehr fundiert antworten und Tips geben. Mit Anblaffen wird das aber nix.
Willst Du stereo auf Mittlewelle senden/empfangen? Was genau hast Du vor? BTW: Was sich der Richard AD7C da ausgedacht hat: die Frequenz als String im EEPROM zu speichern/ zu lesen, ist tatsächlich so gewollt? Diese rx/1000%10 usw für die Darstellung der einzelstellen auch? Da sieht mir einiges sehr, na - sagen wir mal - "ungelenk" aus. Das bitgeklappere zum DDS-Chip hin ist notwendig oder lässt sich hier die SPI -Schnittstelle verwenden, Ich habe jetzt das Datenblatt des DDS Chips nicht gelesen, aber das wird ja wohl eine "normgerechte" SPI-Ansteuerung sein, sodass man doch sicher auch die SPI-Hardware des Arduinos verwenden kann, oder? Aus der W. schrieb: > Das betrifft u.A. den Sinusgererator (für den 25Hz Pilotton). Du solltes Dir angewöhnen, die Leute ein wenig zu teasern / zu spoilern, indem Du beschreibst, was du eigentlich machen willst. Deine Ausführungen wirken ansonst sehr aus dem Zusammenhang gerissen, niemand wird sich ernsthaft erst einmal durch deinen Blog wühlen wollen... So könntest du den einen oder anderen, der sich besser in der Arduino-Programmierung auskennt, hinterm Ofen vorlocken und bräuchtest nicht eingeschnappt mit "entweder ich bekomme Hilfe oder eben nicht" reagieren. Das ist eindeutig der falsche Ansatz und die falsche Basis. Ich, in zweiter Generation, der im exessiven AFU-Umfeld aufwuchs, kann da sehr gut mit umgehen, weil ich weis, wie die "alten Funkamateure" (bestes Beispiel für mich -> Fred ex.DM2CND, ex.Y23ND, sk.DL1RON) ticken und wie exentrisch/eigenbrötlerisch/uneinsichtig eben viele von jenem Schlage sind/waren und die wahren "Qualitäten" eben oft für andere im Verborgenen blieben. Das ist in der Tat sehr schade. Äxl DG1RTO
Leute, lasst ihn doch einfach sterben. Er weiß sowieso alles besser. Wer am laufenden Band gegen alle Hinweise meckert hat verloren. Aus die Maus.
Peter D. schrieb: > Da passiert nichts, in einem PNG kann man keinen Link anklicken. Da muss man halt die .ino Datei für öffnen. Der Einzige User mit Grips hier ist stefanus. LG old.
äxl schrieb: > Was sich der Richard AD7C da ausgedacht hat: Ist absolut genial. tnx fr sharing. LG old.
äxl schrieb: > niemand > wird sich ernsthaft erst einmal durch deinen Blog wühlen wollen... Vor allen Dingen muss ich den erst noch verfassen. Freut mich, dass du dich schon im Vorhinein darüber ärgerst, hi hi.
Aus der W. schrieb: > Der Einzige User mit Grips hier ist stefanus. Ich habe mehr Langeweile als Grips.
http://c-quam.blogspot.com/2015/10/c-quam-pruefsender.html Was bist du denn für einer?!? Aus der W. schrieb: > Freut mich, dass du dich schon im Vorhinein darüber ärgerst, hi hi. Ich ärgere mich nicht über deinen BLOG, ich bin wohl eher einer der jenigen, der Dir versucht, deine sozialen Defizite aufzuzeigen. Und das, wie ich finde, auf eine freundschaftlich-nette Art und Weise. Wenn Du deinen eigenen Blog nicht kennst, mich statt dessen von der Seite anblaffst, dann lege ich auf eine weitere Konversation keinen Wert. HAM-Spirit hin oder her. Habe ich nicht nötig. Baue Du weiterhin grüne Leuchtdioden in alte Anzeigeröhren ein und such Dir'n anderen Dummen, an dem Du deine schlechte Laune auslassen kannst. Zu blöd, nen IIC-Oled zusammen mit'm 25Hertz DDS laufen zu lassen, aber hier die grosse Fresse haben? Du machst dich hier gerade total lächerlich und stellst dich in ein Licht, dessen Du augenscheinlich mehr als gerecht wirst. Da ich nicht in diesem Schatten stehen mag, bin ich zu diesem Thema raus. komplett. Viel Spaß beim gemeinsamen Hobby. kopfschüttelnd. Äxl DG1RTO
Warum Du nicht einfach per PWM ein 25Hz Rechteck-Signal generierst und mit Deiner Rest-Pilotton-Schaltung in einen Sinus umwandelst erschließt sich mir nicht. Scheint doch sowieso konstant zu sein, warum also ein Sinusgenerator per Programm. Wahrscheinlich bin aber auch ich einer von denen ohne Grips :-)
äxl schrieb: > Carl D. schrieb: >>> pwmDuty = 128 +126 * sin(micros() * 0.000157); > > Allein für diese eine Codezeile würde ich gern mal das listing sehen... Ja, das ist maximal Ressourcen verbrauchend. Wird jede 1ms ein neuer Wert für 25Hz berechnet, dann sind das nur 40 Stützstellen. Das geht ganz einfach mit einem Array und die umständliche float Sinus-Berechnung entfällt komplett.
1 | #include <avr\io.h> |
2 | |
3 | uint8_t sintab[] = { 0, 20, 39, 58, 75, 90, 103, 113, 121, 125, |
4 | 127, 125, 121, 113, 103, 90, 75, 58, 39, 20, |
5 | 0, -20, -39, -58, -75, -90, -103, -113, -121, -125, |
6 | -127, -125, -121, -113, -103, -90, -75, -58, -39, -20, |
7 | };
|
8 | |
9 | void int_1ms(void) // to be called from the 1ms interrupt |
10 | {
|
11 | static uint8_t step25; |
12 | if (step25 >= 40) |
13 | step25 = 0; |
14 | OCR0A = 128 + sintab[step25]; |
15 | step25++; |
16 | }
|
Man sieht auch sehr schön, daß nur eine Viertelwelle berechnet werden muß. Der Rest ergibt sich durch Spiegelung bzw. Vorzeichenumkehr. Man könnte daher die Tabelle auch auf 10 Einträge reduzieren und die beiden Subtraktionen in Echtzeit machen. Durch den Aufruf im Timerinterrupt gibt es auch keinen Jitter mehr durch andere Tasks.
äxl schrieb: > lege ich auf eine weitere Konversation keinen > Wert. Das freut mich sehr. :) Hugo H. schrieb: > Warum Du nicht einfach per PWM ein 25Hz Rechteck-Signal generierst und > mit Deiner Rest-Pilotton-Schaltung in einen Sinus umwandelst erschließt > sich mir nicht. Scheint doch sowieso konstant zu sein, warum also ein > Sinusgenerator per Programm. Der Semir hat mir netterweise einen Sinus geschenkt. Warum soll ich dann einen Reckteck nehmen? Je harmonischer der Pilotsinus ist, desto besser ist das. Die Oberwellen landen ja im Differenzsignal. LG old.
Peter D. schrieb: > Das geht ganz einfach mit einem Array Danke Dir, werde ich demnächst mal testen. Wird eher zum WE passieren. LG old.
Oh manno... Das mit der Tabelle kam in diesem Thread schon gefühlte 100 mal vor! Bei "Sinus und µC" muss das doch das erste sein, was einem da einfällt. Am Rande: Wie kann jemand (du) so arrogant sein und dann das Prinzip einer "Lookup Table" nicht kennen. Ob es da wohl noch mehr Lücken gibt? Ob du dir da wohl mit deiner eigenen Einstellung (Halsstarrigkeit) im Wege rum stehst?
Peter D. schrieb: > Da passiert nichts, in einem PNG kann man keinen Link anklicken. Warum > willst Du es einem immer maximal schwer machen? > Links gehören in das Posting und nicht in irgendwelche Anhänge. Und auch > immer gleich an den Anfang, damit man sehen kann, worauf sich eine Frage > bezieht. ich hatte mir mal die Mühe gemacht, in den Quellen war keine falsche Einrückung weder in der Arduino IDE noch in Notepad++ Ich frage mich so langsam auch was uns der TO da mitteilen will Links in PNG, kein Bezug auf was er meint..... trolliger oder "do**er" gehts ja kaum noch Irgendwann wird ihn JEDER ignorieren weil es die Mühe nicht lohnt! PS: lcd.setCursor(0,1); lcd.print(hertz);}} habe ich an keiner Stelle gefunden
:
Bearbeitet durch User
Joachim B. schrieb: > PS: lcd.setCursor(0,1); lcd.print(hertz);}} > > habe ich an keiner Stelle gefunden Im ersten Post ist ein Link auf einen anderen Thread, dort wiederum in dessen ersten Post ist Code angehängt, um den geht es. Dort kommt die obige Zeile drin vor und auch tausend andere Verbrechen gegen die Leserlichkeit, der ganze Code ist eine Serie von Faustschlägen ins Gesicht eines jeden wohlwollenden Lesers.
:
Bearbeitet durch User
Bernd K. schrieb: > Im ersten Post ist ein Link auf einen anderen Thread, dort wiederum in > dessen ersten Post ist Code angehängt, um den geht es. Dort kommt die > obige Zeile drin vor und auch tausend andere Verbrechen gegen die > Leserlichkeit. da soll einer drauf kommen "OMG" Joachim B. schrieb: > Irgendwann wird ihn JEDER ignorieren weil es die Mühe nicht lohnt!
Peter D. schrieb: > ... Das geht ganz einfach mit einem Array und die umständliche > float Sinus-Berechnung entfällt komplett. ... > Man sieht auch sehr schön, daß nur eine Viertelwelle berechnet werden > muß. Perle für die Schweine...
Peter D. schrieb: > Durch den Aufruf im Timerinterrupt gibt es auch keinen Jitter mehr durch > andere Tasks. Du hast vergessen, (ihm) aufzuzeigen, wie er die Routine in den Timerint. bekommt, aufdass diese auch alle 1msek aufgerufen wird... Den Rotary Encoder kann man da auch gleich mit reinbasteln, wenigstes ein Flag setzen.
äxl schrieb: > aufzuzeigen, wie er die Routine in den > Timerint Aus meiner Wühkiste:
1 | /**
|
2 | *
|
3 | * Timertick Interrupt
|
4 | *
|
5 | * Genutzt wird die Arduino Voreinstellung des Timers
|
6 | *
|
7 | * Intern arbeitet der uebliche AVR Arduio mit Timer0 Overflow Interrupts,
|
8 | * um die Werte für millis(), delay() usw zu erzeugen. Leider koennen wir
|
9 | * darum diesen Overflow Interrupt nicht für eigene Zwecke nutzen.
|
10 | *
|
11 | * Der Vorteiler wird auf 64 gesetzt und da Timer0 ein 8 Bit Timer ist,
|
12 | * erfolgt alle (16000000/64/256)ms ein Compare Interrupt.
|
13 | * Bei einem Uno, also alle 0,977ms
|
14 | * Bei einem 8MHz Pro Mini alle 1,953ms
|
15 | *
|
16 | * Hier am Beispiel eines UNO
|
17 | * Der genutzte Kanal kann auch weiterhin für PWM verwendet werden, erzeugt
|
18 | * dann aber bei Wertänderungen einen Jitter im ISR Timimg
|
19 | *
|
20 | */
|
21 | |
22 | |
23 | |
24 | volatile unsigned int ticks = 0; |
25 | |
26 | void setup() |
27 | {
|
28 | DDRB |= _BV(PB5); |
29 | OCR0A = 42; // Wert ist egal |
30 | TIMSK0 |= _BV(OCIE0A); |
31 | TIFR0 |= _BV(OCF0A); |
32 | }
|
33 | |
34 | void loop() {} |
35 | |
36 | |
37 | ISR(TIMER0_COMPA_vect) |
38 | {
|
39 | if(++ticks>=1000U) |
40 | {
|
41 | PINB = _BV(PB5); // toggle pin |
42 | ticks=0; |
43 | }
|
44 | }
|
Sehr interessant, wie hier einem erwiesenen Rotzlöffel geduldig geholfen wird. Respekt an alle, die sich die fremde Spucke aus dem Gesicht wischen und höflich weiterhelfen.
Kastanie schrieb: > und höflich weiterhelfen. Der spuckt und pieselt gegen den Wind. Irgendeinem anderen mag der Thread allerdings helfen. Sowohl auf fachlichen, als auch auf sozialem Gebiet. Meine Oma sagte damals schon: > Selbst den größten Idioten kann man gebrauchen. > Und sei es auch nur als abschreckendes Beispiel.
Kastanie schrieb: > Sehr interessant, wie hier einem erwiesenen Rotzlöffel geduldig geholfen > wird. stimmt, manchmal hat man Langeweile oder muss den Kopf von eigenen Problemen ablenken. Andererseits ist es nicht ausgeschlossen das Hilfe nicht dem Rotzlöffel hilft sondern anderen die den Thread finden.
Ich finds kacke, wie sich manche hier benehmen dürfen. Das vorweg. Sehr ärgerlich finde ich, dass die Riege der Funkamateure durch dieses unempathische Verhalten eines einzelnen OM verunglimpft wird. Dabei kenne ich aus jenem Kreis genug, die ihr hohes Bildungsniveau auch im sozialen Umfeld mitführen. Andererseits kenne ich jetzt wenigstens einen, bei dem das nicht so ist. Also: #isso; Haken drann. Sehr befremdlich, dass ein durchaus interessantes Thema (AM-Stereo hatte ich noch nicht auf dem Schirm - scheint ja aber eh vorbei zu sein) bei mir jetzt gleich negativ besetzt ist. Aber: ich kehre wieder zum Tagesgeschäft zurück, ich bin noch nicht in Rente... Gruß Äxl PS: kann man das benötigte Sendesignal nicht direkt im µC erzeugen?
Ein Autofahrer hört im Radio: > "Ein Geisterfahrer auf der A44!" Sagt der Fahrer: > "Was? Einer? Hunderte!"
äxl schrieb: > PS: > kann man das benötigte Sendesignal nicht direkt im µC erzeugen? Es wird wahrscheinlich leichter wenn man einen µC mit DAC wählt und nicht mit PWM als DAC-Ersatz rummachen muss. Dann könnte man wohl irgendwas erzeugen das man nachher nur noch hochmischen muss, das müsste noch im Rahmen der Leistungsfähigkeit eines nicht allzu lahmen µC sein sag ich mal so aus dem Bauch raus. SSB genauso.
Moin, äxl schrieb: > PS: > kann man das benötigte Sendesignal nicht direkt im µC erzeugen? Ich lehn' mich mal etwas aus dem Fenster und sag': Das koennte wahrscheinlich sogar der ATMega328 machen. Wenn man den z.B. mit 16MHz takten wuerde, koennte ich mir vorstellen mit dem ADC 2 (Audio-)Kanaele mit jeweils 15.625kHz Abtastrate und 8 bit zu digitalisieren, die dann entsprechend zu matrizieren, und den ganzen anderen C-QUAM Affenzirkus zu machen und dann mit einer niedrigen ZF von vielleicht z.B. 39.0625kHz mit ein paar Bit parallel auf ein R2R Netzwerk gehen, danach halt filtern und hoch mischen. Wenn die Pins ausreichen koennt' man vielleicht sogar in der ZF-Lage mit I und Q Komponente rausgehen und mit einem komplexen Mischer sich das Auftreten von Spiegelfrequenzen schenken/abschwaechen. Wenn man die ganze Signalverarbeitung in einem (Timer-)IRQ-Handler macht, bleibt sogar noch bisschen CPU-Power uebrig um Displays, I2C- und SPI-Peripherie zu bedienen... Hab's aber nur mal schnell ueberschlagen - wie gut der ADC sich so hurtig umschalten laesst, dass ein Stereosignal dabei rumkommt, muesst' man mal ausprobieren. Assembler sollt' man halt koennen. Und digitale Signalverarbeitung. Gruss WK
Dergute W. schrieb: > ADC sich so > hurtig umschalten laesst, dass ein Stereosignal dabei rumkommt Der ADC gibt nichts raus der vergleicht/misst nur. Hast Du den Thread verfolgt?
äxl schrieb: > Du hast vergessen, (ihm) aufzuzeigen, wie er die Routine in den > Timerint. Wozu, kann man doch zurückblättern und nachlesen ... Wolfgang schrieb: > Hier siehst du ein Beispiel, wie du dich an den Timer0-Interrupt, der > auch für millis() den Takt bereit stellt, einklinken kannst. > https://learn.adafruit.com/multi-tasking-the-arduino-part-2/timers
Moin, Hugo H. schrieb: > Der ADC gibt nichts raus der vergleicht/misst nur. Das glaube ich nicht, Tim. > Hast Du den Thread verfolgt? Das glaube ich schon, Tim. Gruss WK
Dergute W. schrieb: > Das glaube ich nicht, Tim. Glauben heißt nicht(s) Wissen - passt also :-), Weka. "Tim" scheint einer eher labilen Phantasie zu entspringen ... :-) - hast Du irgendwelche Probleme?
:
Bearbeitet durch User
Aus der W. schrieb: > Sebastian W. schrieb: >> Wenn ich deinen Quellcode richtig verstehe > Zeile 254. Im Code. Für Euch kann man sich nur noch fremdschämen. Ok, ich hab mir den ganzen Thread noch einmal durchgelesen und gebe zu, dass ich mit > Old, das von dir geschilderte Problem (Störung des 25Hz-Sinus durch > LiquidCrystal_I2C) ist generell nicht trivial zu beheben. Es stellen > sich da Fragen nach zum Beispiel den längsten Zeiten von > Interrupt-Unterdrückung in den Bibliotheken. auf dem Holzweg war. Ich muss gestehen, dass ich mir beileibe nicht vorstellen konnte, dass jemand die Chuzpe *) besässe, seine Verzerrung einer nicht nebenläufig erzeugten Sinus-Schwingung durch den zwischenzeitlichen Aufruf von einfach länger dauernden Bibliotheksroutinen eben diesen Routinen als "Bug" anzulasten. LG, Sebastian *) lt. Wikipedia "eine Mischung aus zielgerichteter, intelligenter Unverschämtheit, charmanter Penetranz und unwiderstehlicher Dreistigkeit"
Dergute W. schrieb: > Ich lehn' mich mal etwas aus dem Fenster ... Ich bin froh, wenn ich irgendwann mal eine FL2K-Lösung dafür hinbekomme … Ist bisher daran gescheitert von gnuradio in win10 auf fl2k zu kommen. Habe ich momentan auch keine Lust zu. Meine jetzige Lösung, die ich gerade zum 2.Mal aufbaue, sieht so aus: Neues C-QUAM Verfahren entwickelt, welches einen Phasenmodulator für CQU erlaubt. (Das hatte ich für den "Butter Cookies TX" entwickelt.) Arduino --> AD9850 wird mit (L-R)*(L+R+1), das ist der Kniff und wird Niederfrequent generiert, Pulsweitenmoduliert. (Unmittelbare PM über das Register kann ich nicht, es ist auch fraglich ob das qualitativ mit der geringen Bitbreite geht.) Für PWM besitzt der AD9850 einen ausgezeichneten Komparator. Ein Toggelflipflop macht aus der PWM --> PM. (Motorola erzeugt übrigens diese, mit (L-R)*(L+R+1) modulierte PM, hochfrequent. Das muss man erkennen.) Diese Phasenmodulierte Frequenz wird wieder verdoppelt und ergibt den C-QU-Träger in TTL. Von 100KHz bis 2MHz, wie man im Sketch sieht. Dann kommt die AM dazu --> CQUAM. LG old.
Moin, Aus der W. schrieb: > Ich bin froh, wenn ich irgendwann mal eine FL2K-Lösung > dafür hinbekomme … > Ist bisher daran gescheitert von gnuradio in win10 auf > fl2k zu kommen. Habe ich momentan auch keine Lust zu. Ja, das sind dann natuerlich die Superluxusloesungen. Mitm 328er waere natuerlich nur 8-bit Audio sinnvoll und mangels DAC der ZF-Out auch bisschen krueckig... Aber ist ja eh "nur Mittelwelle" ;-) Gruss WK
Dergute W. schrieb: > Mitm 328er waere > natuerlich nur 8-bit Audio sinnvoll und mangels DAC der ZF-Out auch > bisschen krueckig... Deshalb auch analog mit Arduino und AD9850 Comfort. Da gibt es keine Abstriche bei. LG old.
Angehängte Dateien:
-
Display-LEDs.jpg
77 KB
Aus der W. schrieb: > Als nächstes versuche ich dann eine Spannung über die > PWM bei gedrücktem Pushbutton Rotary für die Lautstärke > zu bekommen. Das hat geklappt. :) Ein Pushbutton-Rotary passt noch auf die Frontplatte neben dem Display. Für ein gutes Tandempoti ist zu wenig Platz in dem Gehäuse, welches ich verwenden möchte. Anbei auch die aktuelle ino. > Als übernächstes den Wert in den Speicher > zu schreiben um ihn beim Wiedereinschalten zu bekommen. > Damit bin ich erstmal beschäftigt. Als Muster zur Orientierung > habe ich ja die Frequenzeinstellung. LG old.
Angehängte Dateien:
-
lst-LM13700N.jpg
140 KB
Auf dem Spannungsversorgungsboard habe ich noch Platz für das elektronische Tandempoti mit dem LM13700N gefunden, welches vom Arduino gesteuert wird. Ist etwas eng geworden ... Oben die 3,5mm Klinke ist der Stereo-Audio-Eingang. LG old.
Aus der W. schrieb: > Was zu tun ist, habe ich getan. Du bist eigentlich an einem Punkt, an den du auf C umsteigen solltest. Die Arduino libs sind oft in c oder c++ geschrieben, dabei hoffnungslos aufgeblasen, was du für dein konkretes Projekt alles gar nicht brauchst. Hier schrieb jemand, dass sie funktionieren, aber nicht optimal sind. Es macht hinterher auch mehr Spaß, weil du dann auch z.B. deinen Code sehr einfach auf einen anderen, vielleicht auf einen Tiny, Controller portieren kannst. Arduino ist sicher gut für den Anfang, aber irgendwann ist es erstmal eine Sackgasse, weil dir dann das elementare Verständnis fehlt. Wenn du dann ein tieferes Verständnis hast, kannst du sicher das eine oder andere Projekt damit vielleicht schneller verwirklichen. In jedem Fall bist du persönlich schon an die Grenze von Arduino gestoßen. Du musst nun etwas mehr über den Controller lernen, wie dieser arbeitet und das kannst du besser mit C und mit dem Atmel Studio. Im Simulator kannst du dann z.b. sehen wie die Register stehen, was dein Befehl auslöst. Auch wenn du dich jetzt noch sträubst, du kommst nicht drum rum.
F. F. schrieb: > Du bist eigentlich an einem Punkt, an den du auf C umsteigen solltest. Er hat doch schon geschrieben daß er sich nicht mit der Materie auseinandersetzen will. Er will nur Legosteine zusammenstecken. Und wenn wie im vorliegenden Fall die Noppen zufällig auf der anderen Seite sind ist natürlich Lego schuld an der Misere, denn das Umdrehen des Bausteins und richtig herum einsetzen würde schon den Rahmen sprengen. Also nimmt er Heißkleber. So versteh ich das.
:
Bearbeitet durch User
Moin, F. F. schrieb: > Auch wenn du dich jetzt noch sträubst, du kommst nicht drum rum. Doch, das glaube ich schon. Man muss auch mal akzeptieren, dass jemand lieber mit Heisskleber rumbatzelt, als mit einer Programmiersprache. Da find' ich nix verwerfliches dran. Gruss WK
F. F. schrieb: > Du bist eigentlich an einem Punkt, an den du auf C umsteigen solltest. Irrtum in der Sache! Das Problem liegt hier: Der TO hat einen Stock so weit im Hintern, dass er sich daran verschluckt. F. F. schrieb: > Hier schrieb jemand, dass sie funktionieren, aber nicht optimal sind. Wer? Ich würde sagen, dass hier der Nachweis geführt wurde, dass die Arduino Libs nicht das Problem sind, sondern die innere Einstellung des TO. Und da kann auch kein Atmelstudio was gegen machen. --- Und überhaupt, warum sollte man vom modernen C++ auf C umsteigen wollen/sollen? Damit gewinnt man nun wirklich keinen Blumentopf. F. F. schrieb: > Auch wenn du dich jetzt noch sträubst, du kommst nicht drum rum. Auch da irrst du dich.
Arduino Fanboy D. schrieb: > Und überhaupt, warum sollte man vom modernen C++ auf C umsteigen > wollen/sollen? Damit gewinnt man nun wirklich keinen Blumentopf. Ne muss er nicht, keiner, aber du weißt wo dieses Thema hin führt. Viele Programme und somit Beispiele für Mikrocontroller sind nun mal in C geschrieben (Assembler hier außen vor gelassen; c-hater, deine Beschwerde wird schon hier förmlich zur Kenntnis genommen) und nur deshalb habe ich zunächst C angeführt. Natürlich kann man auch weiter Heißkleber nehmen, aber ich denke das Interesse kommt ganz von alleine. Das war was ich damit ausdrücken wollte.
F. F. schrieb: > Die Arduino libs sind oft in c oder c++ geschrieben, dabei hoffnungslos > aufgeblasen, was du für dein konkretes Projekt alles gar nicht brauchst. Das ist nicht mein Bier. Mir wurde gesagt: Nimm ein I2C-Display, da hast Du weniger Verdrahtungsaufwand und zusätzliche Ein- Ausgänge frei. Offenbar gibt es unbekannte Nebenwirkungen. Wichtig ist, dass die libs funktionieren. Ich bin da einfach nur Nutzer. Die Mehrzahl der Nutzer wird wohl kein Problem mit der I2C lib für das Display haben, deshalb wird der Bug wohl nicht gefixt werden. Nun mal mein Autovergleich: Der mehr als zufriedene Nutzer eines Dieselfahrzeuges hört im ÖR, dass sein Diesel eine Dreckschleuder sei und glaubt das sofort. Jetzt ist er plötzlich unzufrieden, will Geld und klagt rum. Tatsächlich versucht der Hersteller noch irgendwelche Änderungen, damit alle wieder glücklich sind. Davon seit Ihr weit entfernt. Da kommt Niemand und sagt im übertragenen Sinne: Autofahrer lerne erstmal Doppelplus-Zeh bevor Du ein neues Auto kaufst. Für größere Projekte nehme ich dann halt den Mega und klemme das Display wieder parallel an. Wo es geht versuche ich libs zu vermeiden. Den meisten analogen Kram kann ich selbst an den Arduino über die Analogeingänge bzw. PWM-Ausgänge hängen. LG old.
Aus der W. schrieb: > Wichtig ist, dass die libs funktionieren. Tun sie doch auch - einzeln. Dass zusammengewürfelte Software in Kombination oft Probleme macht, ist nicht neu. An solchen Punkten erkennt man halt, wie tief ein Programmierer in die Materie einsteigen kann. Da trennt sich die Spreu vom Weizen.
Stefanus F. schrieb: > ist nicht neu. Ist neu. Ich bin mir auch sicher, dass der Bug behoben werden kann, wenn willige Arduino Programmierer darauf aufmerksam werden. LG old.
Aus der W. schrieb: > Ich bin mir auch sicher, dass der Bug behoben werden kann na dann mach' es! Du hast schließlich Interesse daran.
Stefanus F. schrieb: > Aus der W. schrieb: >> Ich bin mir auch sicher, dass der Bug behoben werden kann, >> wenn willige Arduino Programmierer darauf aufmerksam werden. > > na dann mach' es! Du hast schließlich Interesse daran. Ich bin kein Programmierer. Bist Du einer? LG old.
F. F. schrieb: > Natürlich kann man auch weiter Heißkleber nehmen, aber ich denke das > Interesse kommt ganz von alleine. > Das war was ich damit ausdrücken wollte. Klar, C++ ist Heißleber, und Heißkleber ist scheiße, warum noch gleich? Weil Heißkleber eben scheiße ist. Lies dir dieses noch mal durch: Aus der W. schrieb: > Ich bin mir auch sicher, dass der Bug behoben werden > kann, wenn willige Arduino Programmierer darauf aufmerksam werden. Der hat immer noch nicht begriffen, das die LCD Lib nicht sein Problem ist. Wie kommst du {Autor: F. F. (foldi)} auf die absurde Idee, das ein Atmel Studio, oder C daran was ändern können? Absurd! Einfach absurd, die Annahme. F. F. schrieb: > aber du weißt wo dieses Thema hin führt. Warum fängst du dann damit an? Ich möchte mal behaupten, dass alle hier, außer du und der TE begriffen haben, worum es geht. Wo es "wirklich" klemmt. Und das hat ganz sicher nichts mit C oder C++ oder einer beliebigen IDE zu tun.
Arduino Fanboy D. schrieb: > Der hat immer noch nicht begriffen, das die LCD Lib nicht sein Problem > ist. Ja, offensichtlich. Eigentlich fehlt jetzt nur noch, den Entwickler der LCD Lib zu beschimpfen.
Etwas Zeit zur Nachbesserung sollte man schon geben, bevor man schimpft. LG old.
Aus der W. schrieb: > Etwas Zeit zur Nachbesserung sollte man schon geben, Erwartest du jetzt im Ernst, dass der Autor oder jemand anderes die Bibliothek (nur für dich) ändert? Da kannst du lange warten.
Ich denke, es wird bald eine neue lib oder ein Update dafür geben. LG old.
Aus der W. schrieb: > Ich denke, es wird bald eine neue lib oder ein Update dafür geben. Du bist echt schräg drauf. Was rauchst du?
Aus der W. schrieb: > Ich denke, es wird bald eine neue lib oder ein Update dafür > geben. > > LG > old. Wozu? Der Code tut exakt das, was er soll und genau wie beschrieben. Der "Bug" sitzt 50 cm vor dem Monitor.
Harry L. schrieb: > Wozu? Damit man einen Sketch nicht umkrempeln muss, wenn man ein serielles Display verwenden will. [Ironie] > Der Code tut exakt das, was er soll und genau wie beschrieben. > > Der "Bug" sitzt 50 cm vor dem Monitor. Klar der User und die Autofahrer sind schuld. Programmierer sind unfehlbare Götter. [/Ironie] LG old.
Stefanus F. schrieb: > Der Mann veräppelt uns doch! Nö, er hat nur keine Kompetenz auf diesem Gebiet. Siehe Kompetenzlevel 1 In: https://de.wikipedia.org/wiki/Kompetenzstufenentwicklung Aber die Nase ganz weit oben. Der "Bug" sitzt 50 cm vor dem Monitor. Auf Level 8 im OSI Schichtenmodell.
Stefanus F. schrieb: > Der Mann veräppelt uns doch! Von mir gibt es als Lösung einen funktionierenden Sketch. Umständlich aber läuft. Und von Euch? Unausgegorene Vorschläge die bisher zu nichts führten. LG old.
Dann verharre weiterhin in deinem Irrtum. Denn die Einsicht kann nur in deinem Kopf entstehen.
Stefanus F. schrieb: > Der Mann veräppelt uns doch! das habe ich auch öfter gedacht, kaum zu glauben das er ein RFS Techniker ist, Zitat Goldblum, "es gibt nicht was ein Fernsehtechniker nicht kann", bis dahin glaubte ich das weil ich keinen so komischen Kollegen kennengelernt hatte.
Joachim B. schrieb: > kaum zu glauben Ach, da mache dir mal keine Sorgen. Dieses Maß der Borniertheit, hat nichts mit dem Berufsstand RFS Techniker zu tun.
Aus der W. schrieb: > Offenbar gibt es unbekannte Nebenwirkungen. Nein, alle Wirkungen sind allgemein bekannt und gut dokumentiert. Wie man das in seiner Software berücksichtigt ist ebenfalls bekannt, nur Dir offensichtlich nicht, aber nur weil Du etwas nicht kennst und auch nichts darüber lernen willst wird es noch lange nicht "unbekannt". Und jetzt hör endlich auf hier so kindisch rumzutrotzen. das ist doch vollkommen lächerlich. > deshalb wird der Bug wohl nicht gefixt werden. Nein, diese Lib ist vollkommen in Ordnung, Deine Firmware hat einen Bug. Das wurde Dir aber schon lang und breit erklärt, inklusive Code der das fixt. Vollkommen lächerlich was Du hier abziehst.
:
Bearbeitet durch User
Eine Beleidigung reiht sich an die Nächste. Schaukeln sich gegenseitig hoch.
Bernd K. schrieb: > Das wurde Dir aber schon lang und breit erklärt, > Das wurde behauptet. inklusive Code der das > fixt. Unvollständige Brocken. Und lies nochmal den Startbeitrag. Eine Problemlösung ist das noch lange nicht, wenn nur der Sinus während der Anzeigeänderung sauber bleibt. Man muss schon etwas an der I2C Sache ändern, wenn nicht das Nächste Problem in den Startlöchern stehen soll. Beitrag "Re: I2C "blockiert" Arduino" Der Modulator läuft auch ohne Anzeige der Stellung des elektronischen Potis oder einer Pegelanzeige. (Sauber Einpegeln geht sowieso nur mit den LEDs.) Kommt Zeit kommt Lösung dafür, ich habe damit Zeit. LG old.
Offenbar gibt es diverse I2C libs für das Display. https://forum.arduino.cc/index.php?PHPSESSID=nph3ge5n8g5av6l91l6b8dbon2&topic=449451.msg3092231#msg3092231 Ich werde demnächst mal eine andere, aktuellere lib testen. LG old.
Aus der W. schrieb: > Eine Beleidigung reiht sich an die Nächste. Schaukeln sich gegenseitig hoch. Und du bist daran gaaaaanz unschuldig. > Kommt Zeit kommt Lösung dafür, ich habe damit Zeit. Trollblocker schrieb: > Warum wird der Troll seit Tagen gefüttert? Aus der W. schrieb: > Man muss schon etwas an der I2C Sache ändern, wenn nicht > das Nächste Problem in den Startlöchern stehen soll. Dann tu das! Oder benutze eine andere Lib. Dir wurden bereits Gründe für deine Probleme erklärt und Lösungsmöglichkeiten vorgeschlagen. Nun ist DEINE Initiative gefragt. Dein Verhalten wird hier niemanden dazu bewegen Code für dich zu schreiben. Du solltest vielleicht ein Unternehmen beauftragen - gegen Geld, versteht sich.
Aus der W. schrieb: > Offenbar gibt es diverse I2C libs für das Display. > > https://forum.arduino.cc/index.php?PHPSESSID=nph3ge5n8g5av6l91l6b8dbon2&topic=449451.msg3092231#msg3092231 > > Ich werde demnächst mal eine andere, aktuellere lib testen. Es ist nicht schlimm, wenn deine Kompetenzen auf anderen Gebieten liegen. Es ist aber unschön anzusehen, wie jemand, dessen Programmierkompetenzen schwächer ausgebildet sind, als die so mancher Putzfrau, die getätigte Aussage, dass die LCD Lib hier unschuldig ist, in den Wind schlägt. Keine dieser Libs wird dein Problem lösen. So wie dir auch die Kenntnis über eine LUT fremd war, ist es auch mit dem denken in Nebenläufigkeiten. Und damit hapert es dann auch beim herstellen eben genau dieser Nebenläufigkeiten. Das alte Mantra: > Ich benötige ein Zeitraster. > Dann verwende ich einen Timer. Ist noch nicht in deinen Hirnwindungen verankert. Wenn das einmal sitzt, dann gibts auch keine Probleme mehr mit dem I2C Display. Tipp: > Der Kopf ist rund, > damit das denken die Richtung ändern kann.
Aus der W. schrieb: > Unvollständige Brocken. Natürlich. Erwartest du, dass hier jemand deine Arbeit für dich erledigt? > Man muss schon etwas an der I2C Sache ändern Nein, der Fehler steckt im Gesamtkonzept. Die I²C Sache könnte man auch ändern, aber nicht ohne das Programm insgesamt anders zu strukturieren. Wie, das wurde Dir von mehreren Leuten ausreichend erklärt. Wenn du das nicht verstehst, dann ist das schade und nicht unser Fehler.
Stefanus F. schrieb: > nicht unser Fehler Sobald Du in dieser Gruppe auftrittst, bist Du ein anderer Mensch. A. M. schrieb: > Oder benutze eine andere Lib. Ach da schau her!
Stefanus F. schrieb: > Nein, der Fehler steckt im Gesamtkonzept. Als ob das Sketch-Konzept davon abhängt, ob man ein paralleles oder serielles Display verwendet. Das ist der Witz des Abends. LG old.
Der Witz des Abends ist, dass du immer noch knallhart den eigentlichen Fehler leugnest. Der Fehler ist, dass die Zeit, die für die Kommunikation mit dem Display drauf geht, die Erzeugung des Signals beeinträchtigt. Das darf schon nicht sein. Völlig egal, welche Schnittstelle verwendet ist und wie schnell oder langsam sie ist. Denn kein Display kann ganz ohne Zeitbedarf kommunizieren. Ein schnelleres (paralleles) Display macht das Problem nicht weg, sondern nur kleiner. Der eigentliche Fehler liegt in der Art und Weise wie dein Programm das Signal generiert. Das muss unabhängig von anderen Threads deines Programms werden. Multitasking und Timer-Interrupts sind hier die Zauberwörter, mit denen du dich befassen solltest.
Stefanus F. schrieb: > Erwartest du, dass hier jemand deine Arbeit für dich > erledigt? ARBEIT? Das ist hier Hobby. Auch wenn ich mal für einen User eine Simu (Ltspice) anfertige oder ans laufen bringe, so mach ich das sehr gerne. Wir haben da wohl sehr unterschiedliche Einstellungen zur Hilfe im Forum, deshalb passt das nicht. ______________________________________________________________ Fortschritt am Modulator: Ich mache gerade das Sallen-Key für die VCAs fertig. LG old.
Hi >Wir haben da wohl sehr unterschiedliche Einstellungen zur >Hilfe im Forum, ... An welcher Stelle hast du schon mal hier im Forum geholfen? MfG Spess
Aus der W. schrieb: > ARBEIT? Das ist hier Hobby. Wenn ich etwas nicht selber machen kann oder will, und dass dann von jemand anderem machen lasse, dann ist das für denjenigen normalerweise Arbeit. Für mich bedeutet Arbeit nicht zwangsläufig Beruf, sondern eher eine Tätigkeit, die man nicht zur reinen Freude macht. Arbeit ist für mich auch Gartenpflege, Putzen, Waschen, Kochen, Kindererziehung. Wenn ich deinen Quelltext verbessern würde (oder die Lib), dann würde ich das nur tun, um mir etwas zu meinem knappen Gehalt dazu zu verdienen. Das wäre dann für mich eindeutig Arbeit. Angenommen, die Lib wäre fehlerhaft: Der Autor der Lib hat diese vielleicht im Rahmen seines Hobbies bei irgendeiner Bastelei geschrieben. Wenn der Mensch beim nächsten Projekt auf das gleiche Problem stößt, wird er es wahrscheinlich verbessern und veröffentlichen. Darauf kannst du warten. Was allerdings wohl kaum passieren wird ist, das jemand anderes diesen Code für dich verbessert. Das müsste dann schon aus sportlichem Ehrgeiz oder endloser Langeweile heraus passieren. Die Wahrscheinlichkeit, geht jedoch gegen Null weil zu viele Faktoren zusammen treffen müssten: 1) jemand müsste auf das gleiche Problem stoßen 2) mit einer gleichen oder zumindest fast gleichen Anwendungen 3) und der Kompetenz, es zu verbessern 4) und der dazu nötigen Zeit 5) und der dazu nötigen Lust 6) und er müsste sein Werk veröffentlichen 7) und du müsstest auf diese Veröffentlichung aufmerksam werden Da kannst du gleich darauf hoffen, im Lotto Millionär zu werden.
Stefanus F. schrieb: > Wenn ich deinen Quelltext verbessern würde (oder die Lib), dann würde > ich das nur tun, um mir etwas zu meinem knappen Gehalt dazu zu > verdienen. Das wäre dann für mich eindeutig Arbeit. Ich sagte ja schon: Aus der W. schrieb: > Wir haben da wohl sehr unterschiedliche Einstellungen zur > Hilfe im Forum, deshalb passt das nicht. Stefanus F. schrieb: > Was allerdings wohl kaum passieren wird ist, das jemand anderes diesen > Code für dich verbessert. Das müsste dann schon aus sportlichem Ehrgeiz > oder endloser Langeweile heraus passieren. Die Wahrscheinlichkeit, geht > jedoch gegen Null weil zu viele Faktoren zusammen treffen müssten: > > 1) jemand müsste auf das gleiche Problem stoßen > 2) mit einer gleichen oder zumindest fast gleichen Anwendungen > 3) und der Kompetenz, es zu verbessern > 4) und der dazu nötigen Zeit > 5) und der dazu nötigen Lust > 6) und er müsste sein Werk veröffentlichen > 7) und du müsstest auf diese Veröffentlichung aufmerksam werden In meinem Bereich mache ich das. Und wenn es keine Programmierer mit meiner Einstellung gäbe, hätten wir kein Arduino. LG old.
Aus der W. schrieb: > Ich sagte ja schon: Wir haben da wohl sehr unterschiedliche Einstellungen Ja, sieht so aus. Macht nichts, Vielfalt ist gut. Ich würde Dir empfehlen, dich nicht zu sehr auf eine Lib zu versteifen. Die ist nämlich nicht schlecht oder fehlerhaft. In deinem Fall muss die Lösung darin bestehen, das Konzept des Programms zu ändern.
Stefanus F. schrieb: > Ich würde Dir empfehlen, dich nicht zu sehr auf eine Lib zu versteifen. Tue ich auch nicht. Ich werde jetzt mal die ALC "programmieren". Damit muss ich mir dann auch keine Gedanken machen, wie man den letzten VCA-Spannungswert speichert. Die Arduino-ALC bietet deutlich mehr als eine rein analoge mit RC-Zeitkonstante. Sie wird genau das tun, was Mensch am Poti machen würde. LG old.
Aus der W. schrieb: > Und wenn es keine > Programmierer mit meiner Einstellung gäbe, hätten wir > kein Arduino. Wenn es nur Programmierer mit Deiner Einstellung gäbe säßen die alle noch vor dem Rechenschieber und würden sich beschweren daß noch keiner den Computer erfunden hat! Bzw. sie wüßten gar nicht daß es den in einer anderen Realität gegeben hätte und würden sich dann halt über irgendwas anderes beschweren. Zum Beispiel daß die Zahlen alle auf dem Kopf stehen. Und den Vorschlag ihn einfach richtig rum zu halten würden sie ignorieren und stattdessen vom Hersteller verlangen den "Bug" zu fixen während sie sich notdürftig Brillen konstruieren mit denen man alles um 180° verdreht sieht.
:
Bearbeitet durch User
Angehängte Dateien:
-
arduino-pwm-dc.jpg
98 KB
Bernd K. schrieb: > Wenn es nur Programmierer mit Deiner Einstellung Nicht meine Einstellung zum Programmieren, sondern zur Analogtechnik. Aus der W. schrieb: > Fortschritt am Modulator: > Ich mache gerade das Sallen-Key für die VCAs fertig. Ist fertig, Siehe Bild. Jetzt kommt der passende ALC-Sketch. So macht das Freude. :) Die Leiterplatte unten ist der Ersatz für den Pushbutton-Rotary auf den ich noch warte. LG old.
"Ach, ich mach lieber was anderes" "Bleibt der Ton eben verzerrt" "Einer wird sich schon finden" Zu piepen echt... Du bist eben der einzige, der n DDS mit sin() in der Main erzeugt und sich am Ende wundert, das es 'hoplert'. Der Pilotton hoplert auch, wenn Du ne UART-Ausgabe machen würdest oder Befehle auf der seriellen empfangen wollen würdest oder auf ne Eingabe warten wölltest. also: immer quasi. Aber schimpfen. Schnell noch ein Foto "seht her - ich bin nicht ganz blöd, ich kann 'einen ALC' löten". Etwas mehr Demut wäre schon angebracht. Kein Problem, wenn man etwas nicht kann. Dann aber auch dazu stehen, Hilfe annehmen, sich interessiert zeigen und sich wenigstens ansatzweise mit der Thematik beschäftigen. Stattdessen poltert Du hier hier durch die Gegend. Langsam muss ich wirklich schmunzeln. Erinent mich an den Typen, der im Dunkeln sein 2Euro Stück unter der Strassenlaterne sucht, obwohl er genau weiss, es 100 Meter weiter verloren zu haben. Problem: dort ist es dunkel und er würde es dort ohne Licht nicht finden. gg Viel Spass noch weiterhin. Sehr unterhaltsam. ÄxlDG1RTO
äxl schrieb: > Erinent mich an den Typen, der im Dunkeln sein > 2Euro Stück unter der Strassenlaterne sucht, obwohl er genau weiss, es > 100 Meter weiter verloren zu haben. Problem: dort ist es dunkel und er > würde es dort ohne Licht nicht finden. Sehr schön und treffend.
Aus der W. schrieb: > Für größere Projekte nehme ich dann halt den Mega und klemme das > Display wieder parallel an. Wo es geht versuche ich libs zu > vermeiden. Nein, das bringt genau 0,nix. Dein Problem ist, zu erkennen, welches sind zeitkritische Tasks, die in einen Interrupt gehören und welche nicht.
äxl schrieb: > Stattdessen poltert Du hier hier durch die Gegend Ich nenne ein solches Verhalten mittlerweile "rumtrumpen". Denn der Trump verhält sich ähnlich. ------- Seit 40 oder 50 Jahren bestehende Style Guides werden mit einem Fingerschnippen beiseite gewischt. Hier stehen sicherlich weit über 300 Mannjahre Programmiererfahrung als Berater zur Seite. Die Beratung wird nicht verstanden und der jeweilige Überbringer mit Häme überschüttet. Die Schuld wird überall gesucht, wirr argumentiert, aber das eigene Denken nicht im geringsten angezweifelt. --------- Es ist zum fremdschämen....
äxl schrieb: > "Ach, ich mach lieber was anderes" "Bleibt der Ton eben verzerrt" "Einer > wird sich schon finden" > Zu piepen echt... > Du bist eben der einzige, der n DDS mit sin() in der Main erzeugt und > sich am Ende wundert, das es 'hoplert'. Was lügst Du denn hier rum? Erstens bin ich nicht der Einzige und zweitens arbeiten die Sketche, welche ich hier gepostet habe, ufb. Das zur Richtigstellung. äxl schrieb: > Schnell noch ein Foto Freut mich, dass Die Veröffentlichungen von mir, solche Typen wie Dich, ärgern. Dann mache ich alles genau richtig.
Aus der W. schrieb: > zweitens arbeiten > die Sketche, welche ich hier gepostet habe dann ist doch alles gut, warum dann dieser Thread? Aus der W. schrieb: > Mir ist aufgefallen, dass wenn ich das I2C-Display anspreche, > andere Funktionen gestört sind. ja kenne ich, mir fällt auch auf das was gestört ist wenn ICH Fehler mache :)
:
Bearbeitet durch User
Arduino Fanboy D. schrieb: > Seit 40 oder 50 Jahren bestehende Style Guides werden mit einem > Fingerschnippen beiseite gewischt. > > Hier stehen sicherlich weit über 300 Mannjahre Programmiererfahrung als > Berater zur Seite. Die Beratung wird nicht verstanden und der jeweilige > Überbringer mit Häme überschüttet. > > Die Schuld wird überall gesucht, wirr argumentiert, aber das eigene > Denken nicht im geringsten angezweifelt. Er könnte sofort in die Elektronik-Entwicklung der Automobilindustrie einsteigen. Läuft genau so! :-D SCNR
Joachim B. schrieb: > dann ist doch alles gut, warum dann dieser Thread? Das steht, wie so oft, im Startbeitrag. Bis eine Lösung kommt, nutze ich den Thread um den Bastelfortschritt zu dokumentieren. LG old.
Arduino Fanboy D. schrieb: > Hier stehen sicherlich weit über 300 Mannjahre Programmiererfahrung als > Berater zur Seite. Guter Witz zum Wochenanfang. :)))
Das lässt sich leicht umgehen... . Leider nicht mit den fertigen Libs. ... Dein sin() verbrennt zu viel Takte Deine i2c lib arbeitet mit delays... Hier hilft nur ein i2c per polling oder ISR mit Low priority Und dein DDS müsste mit lookuptable und ISR Update umgebaut werden. Dann kannst den uC in den Schlaf legen und Trotzdem funktioniert alles ^^ Anders gesagt... Werf die i2c und dds Libs weg und schreib sie selbst neu
Aus der W. schrieb: > Etwas Zeit zur Nachbesserung sollte man schon geben, > bevor man schimpft. Das ist aber sehr freundlich von Dir - wie viel hast Du denn für die Lib bezahlt?
Hi >Bis eine Lösung kommt, nutze ich den Thread um den >Bastelfortschritt zu dokumentieren. Wem? MfG Spess
Hff schrieb: > Deine i2c lib arbeitet mit delays... Danke für die Info. Ach duch schei … delay steht bei mir seit den ersten Gehversuchen mit Arduino auf der "niemals verwenden" Liste. Das man sich delay dann doch noch über eine lib reinholen kann, ist dann schon bitter. "Delay" rauswerfen war übrigens meine erste Modifikation am VFO-Sketch hier. LG old.
Aus der W. schrieb: > Hff schrieb: >> Deine i2c lib arbeitet mit delays... > > Danke für die Info. > Ach duch schei … > delay steht bei mir seit den ersten Gehversuchen mit Arduino > auf der "niemals verwenden" Liste. > Das man sich delay dann doch noch über eine lib reinholen kann, > ist dann schon bitter. > > LG > old. bringt nichts es zu vermeiden wenn man die libs nicht kennt da es zig diverse libs gibt... hier eine davon :
1 | uint8_t I2C::sendByte(uint8_t i2cData) |
2 | {
|
3 | TWDR = i2cData; |
4 | unsigned long startingTime = millis(); |
5 | TWCR = (1<<TWINT) | (1<<TWEN); |
6 | while (!(TWCR & (1<<TWINT))) |
7 | {
|
8 | if(!timeOutDelay){continue;} |
9 | if((millis() - startingTime) >= timeOutDelay) |
10 | {
|
11 | lockUp(); |
12 | return(1); |
13 | }
|
14 | |
15 | }
|
16 | if (TWI_STATUS == MT_DATA_ACK) |
17 | {
|
18 | return(0); |
19 | }
|
20 | uint8_t bufferedStatus = TWI_STATUS; |
21 | if (TWI_STATUS == MT_DATA_NACK) |
22 | {
|
23 | stop(); |
24 | return(bufferedStatus); |
25 | }
|
26 | else
|
27 | {
|
28 | lockUp(); |
29 | return(bufferedStatus); |
30 | }
|
31 | }
|
das "timeOutDelay" kann man auf 0 setzen ... aber das wird dann für die geräte witzig es gibt hier also je nach menge der I²C Daten lange schleifen mit immer wiederholenden warteschleifen man kann sowas auch per polling betreiben und zwischendurch immer was anderes tun .. oder per ISR oder man legt fest das die anderen aufgaben durch eine ISR priorisiert werden ( DDS ) dann kann man die warteschleifen ggf tollerieren
hfhd schrieb: > man kann Bis ich so etwas kann, bleibe ich bei meiner Lösung. Ich möchte den Modulator erstmal fertig machen und der ALC-Sketch ist noch nicht komplett. LG old.
I²C Implementierungen sind häufig blockierend, egal ob mit delay() oder anderen Warteschleifen. Ich würde sie deswegen nicht herabwerten. Man muss das immer Kontext der Anwendung sehen, für die das ursprünglich entwickelt wurde.
Arduino Fanboy D. schrieb: > Hier stehen sicherlich weit über 300 Mannjahre Programmiererfahrung als > Berater zur Seite. Die Beratung wird nicht verstanden und der jeweilige > Überbringer mit Häme überschüttet. Der TO erwartet auch keine Beratung, sondern eine sofortige Lösung seines persönlichen Problems. Die Forengemeinschaft hat sofort alles wegzulegen und den Arduino-Sketch des TO so umzuschreiben, dass er genau das macht, was der TO wünscht. Das ganze natürlich nicht gegen Bezahlung.
ich persönlich würe ja alles zeitkritische in eine isr verschieben und zeitintensive berechnungen versuchen durch look-up-tables oder andere optimierungen zu ersetzen. ich glaube das hatte hier noch keiner vorgeschlagen.
Sven K. schrieb: > ich glaube das hatte hier noch keiner > vorgeschlagen. Das war eigentlich das zentrale Element aller Antworten von Anfang an, in epischer Breite ausgearbeitet, begründet und sogar mit funktionierenden Codebeispielen garniert, oder versteh ich den Witz grad irgendwie nicht?
Karl Valentin schrieb:
> "Es ist schon alles gesagt, nur noch nicht von allen"
SCNR,
WK
Bernd K. schrieb: > oder versteh ich den Witz grad > irgendwie nicht? ich hätte den sarkasmus durchaus deutlicher kennzeichnen können - das stimmt schon. aber so könnte der threadstarter vielleicht denken es ist eine ernstgemeinte antwort und denkt vielleicht darüber nach.
hfhd schrieb: > dann kann man die warteschleifen ggf tollerieren Genau! Das ist der Punkt. Das ist zu tolerieren. Bedingt aber eben, dass der 25Hz Sinus asynchron zu loop() erzeugt werden will. Aber das geht nicht in den Schädel des TO. Ihm hat keine Kompetenz um überhaupt in die LCD Lib zu schauen, aber genug um zu beurteilen, dass sie kaputt ist. Hff schrieb: > Anders gesagt... Werf die i2c und dds Libs weg und schreib sie selbst > neu Unfug, da nicht das Problem. Aus der W. schrieb: > Bis eine Lösung kommt, .... Kannst du warten bis du schwarz wirst. Der Lösungsweg steht ein Dutzend mal hier im Thread. Du bist es, der sie umsetzen muss. Du wartest also auf dich selber.
Sven K. schrieb: > ich persönlich würe ja alles zeitkritische in eine isr da in dem Sketch eigentlich fast alles zeitkritisch ist, wünsche ich viel Spaß beim Verschieben.
Der AVR mit seiner simplen Interrupt-Architektur hat halt seine Grenzen. Die Summe des Verweilens in den Interrupt-Routinen ergibt den schlimmsten Fall bezüglich zetlicher Unsicherheit. Viel besser sind da Prozessor-Architekturen die Interrupt-Ebenen(levels) haben. Da bekommt die zeitkritischste Routine den höchsten Level. Die kann dann immer alle anderen Interrupts unterbrechen. Die zeitliche Unsicherheit liegt dann bei der Befehlsdauer vom längsten Befehl(einige Takte).
:
Bearbeitet durch User
Arduino Fanboy D. schrieb: > Aber das geht nicht in den Schädel des TO. Wann geht denn in Deinen Schädel, dass es da noch andere Zeitkritische Dinge gibt? Kannst Du den Sketch nicht nachvollziehen? Verstehst Du die Abläufe da nicht? Anders kann ich mir Deine wenig hilfreichen Antworten nicht erklären.
Aus der W. schrieb: > da in dem Sketch eigentlich fast alles zeitkritisch ist, Warum hast Du die Sachen dann überhaupt erst in die main loop gepackt wenn es zeitkritisch ist? > wünsche ich viel Spaß beim Verschieben. Wo ist das Problem? Es ist doch alles eine einzige lange Wurst, Du schneidest die zeitkritischen Teile raus aus der Wurst und packst sie in einen Interrupt. Fertig.
aber wenn ich so viele zeitkritische sachen habe - optimiere ich dann nicht mal irgendwo? es fängt ja schon bei der benutzung von "digitalWrite()" an... das ist glaube ich die langsamste funktion zum setzen / löschen eines pins die ich kenne.
Aus der W. schrieb: > Arduino Fanboy D. schrieb: >> Aber das geht nicht in den Schädel des TO. > > Wann geht denn in Deinen Schädel, dass es da noch andere > Zeitkritische Dinge gibt? Kannst Du den Sketch nicht nachvollziehen? > Verstehst Du die Abläufe da nicht? Anders kann ich mir Deine > wenig hilfreichen Antworten nicht erklären. Dein Programm sieht aus, wie ein Haufen gebrauchter zugeschissener Unterhosen. Da wühl mal schön selber drin rum. Oder zeige was ansprechend formatiertes. > dass es da noch andere Zeitkritische Dinge gibt? Kann ja sein .. Ein Problem nach dem anderen ... Aber wenn man bei der ersten Hürde schon so abkackt, die Flinte in den Sand steckt, und den Kopf ins Korn wirft, dann sehe ich schwarz für deine 25Hz
Während Ihr blöd rummotzt, habe ich die ALC fertig gemacht. Ein absolutes Highlight. Ist definitiv ein "must have" am Modulator. Der Sketch ist einfach nur genial geworden. :) Ich werde noch eine Pilottonabschaltung bei monophonen Sendungen programmieren. Pilot an, Pilot aus, kann ich mir ja problemlos im Display anzeigen lassen. LG old.
Aus der W. schrieb: > Ein absolutes Highlight. Yep. Eine ganze Seite globale Variable sah ich schon sehr lange nicht mehr. leo
leo schrieb: > Eine ganze Seite globale Variable sah ich schon sehr lange nicht > mehr. Und die Formatierung. Formidable!
Stefanus F. schrieb: > Und die Formatierung. Formidable! Da schließe ich mich an - Gratulation! Immer wieder erfrischend, so etwas zu sehen :-) Ich frage mich nur, ob es wohl manchen Zeitgenossen körperliche Schmerzen verursacht, wenn sie die "Automatische Formatierung" anklicken? Wenn ich schon am Lästern bin :-) - scharf ist diese Sequenz (fast genial):
1 | if (d < -50 || d > 50){diff = HIGH;} //Differenzsignal |
2 | else {diff = LOW;} |
3 | if (diff == LOW) // MonoFlop für Differenzsignalanzeige |
4 | {diffist = millis(); |
5 | if (diffist - diffstart > diffausverz) |
6 | {boolblau = LOW;}} |
7 | else{diffstart = millis(); boolblau = HIGH;} |
8 | if ((boolblau && ein) == HIGH){digitalWrite(ledblau,HIGH);} |
9 | else {digitalWrite(ledblau,LOW);} |
:
Bearbeitet durch User
Aus der W. schrieb: > Freut mich, dass Die Veröffentlichungen von mir, solche Typen > wie Dich, ärgern. Dann mache ich alles genau richtig. äxl schrieb: > Sehr unterhaltsam. warum sollte es mich ärgern, wenn Du dich hier zum Hampelmann machst? Mit Verlaub: ich bin hier schon ne Weile mit dabei, um gut zu wissen, wie es hier läuft. Aber eben auch, wie es eben genau NICHT läuft. Nämlich so, wie Du es hier feierst. Das beste: Am Ende schreibt Dir doch ein gelangweilter dein Programm fix und fertig. Nur, um deine Reaktion darauf zu testen. Also: weitermachen ;) Axel Rühl DG1RTO
Aus der W. schrieb: > Während Ihr blöd rummotzt,.... Mal ganz ehrlich, Deine Formatierung des Quelltextes ist schon Augenkrebs. Wenn Du damit zurecht kommst Deine Sache, aber bei dieser Formatierung darfst Du keine Hilfe erwarten. Den Quelltext zu lesen tut man sich nicht freiwillig an.
Äxl schrieb: > Am Ende schreibt Dir doch ein gelangweilter dein Programm fix und > fertig. Das Programm ist fertig und läuft. Es kommen nur noch weitere Updates. Die ALC ist es wert nachgemacht zu werden, auch für andere Modulatoren. Ihr kommt mir vor wie Analphabeten, die einen Text nicht lesen können, sich aber zum Aussehen äußern. Zeno schrieb: > bei dieser > Formatierung darfst Du keine Hilfe erwarten Die Formatierung ist eine Ausrede wie Schaltbild angeblich unleserlich oder so. Bekannt. Gähn. LG old.
Ich bin immer noch der Meinung, daß I2C zum Betrieb des LCDs eine unglückliche Wahl war. Wenn es schon seriell sein soll, wäre HW SPI die günstigere Lösung zu unblockierendem Betrieb. Mit einem 8MHz getaktetem HC164 SR wäre ein Byte in einer einzigen us übertragen. So etwas ließe sich elegant in eine Timer getakteten ISR verstecken wo es niemand bemerkt. Mit einem gepufferten ISR LCD Treiber liefe die LCD Bedienung total im Hintergrund. Derselbe Timer ISR könnte die Pilotton Werte aus einer LUT im Flash beisteuern. Der ganze Code wäre so super einfach auf diese Art und der uC würde sich in der Haupt Loop langweilen oder könnte die DDS Bedienung elegant ermöglichen. Ich habe schon den Eindruck, daß man das arme Pferd von hinten aufzäumte...
Aus der W. schrieb: > Die Formatierung ist eine Ausrede wie Schaltbild angeblich > unleserlich oder so. Bekannt. Gähn. Zeig doch bitte mal ein selbst entwickeltes Schaltbild oder gar zusätzlich ein Layout - das wäre wirklich mal interessant - nur so, zum Vergleich :-)
Platinen Frickler schrieb: > Ich bin immer noch der Meinung, daß I2C zum Betrieb des LCDs eine > unglückliche Wahl war. Spielt in diesem Sketch keine Rolle mehr. Hugo H. schrieb: > wenn sie die "Automatische Formatierung" > anklicken? Mach es doch für Dich wenn es Dir hilft, den Inhalt zu verstehen. LG old.
Aus der W. schrieb: > Mach es doch für Dich wenn es Dir hilft, den Inhalt zu verstehen. Vielleicht würde es Dir helfen zu verstehen, was Du da programmiert hast.
Kann man den Thread nicht mal schließen? Der "Meister" kapiert's eh nicht mehr und niemand will seine Löthaufen sehen, für die er "seine Lösung" gefunden hat. Wenn's doch eh für ihn funzt -> zu damit. "Man kann einem Menschen nichts lehren, man kann ihm nur helfen, es in sich selbst zu entdecken" - Galileo Galilei
könnte zu, stimmt. andererseits ist es auch amüsant, weil jeden zweite offenbar "neue" Leute auf diesen Thread stossen. Ich find gut, dass wir jetzt nicht mehr bis Freitags warten müssen. Auch will ich den sehen, der nicht alles liest, sondern ihm stattdessen den 25Hz Pilotton in die ISR packt, den Rest glattzieht und alles noch schön formatiert und sich wundert, weshalb das noch niemand getan hat. Denn "so blöd kann doch keiner sein" gg Schönen Abend Äxl
Äxl schrieb: > könnte zu, stimmt. Ja, das tut weh den Baufortschritt zu sehen, wenn man selbst so etwas nicht kann oder nicht mitmachen will. Ich mache einen anderen Thread auf und ein Blog dazu kommt auch. Es gibt eben Motzer und Macher hier im Forum. LG old.
Carl D. schrieb: > Und vereinzelt auch Rumheuler. Beitrag "Arduino ALC" Ist auch zum Heulen, dass der Pushbutton Rotary noch nicht eingetroffen ist. Möchte endlich die Frontplatte fertig machen ... Aus der W. schrieb: > Ich mache einen anderen Thread auf Da würde das passen: https://www.mikrocontroller.net/forum/codesammlung LG old.
Hmm... man könnte auch ein Rechtecksignal erzeugen und durch einen Tiefpass leiten... dann braucht man keinen bösen ISR.
Aus der W. schrieb: > Carl D. schrieb: >> Und vereinzelt auch Rumheuler. > > Beitrag "Arduino ALC" > > Ist auch zum Heulen, dass der Pushbutton Rotary noch nicht > eingetroffen ist. Möchte endlich die Frontplatte fertig > machen ... > q.e.d.
yesitsme schrieb: > Hmm... man könnte auch ein Rechtecksignal erzeugen Wegen eines I2C Displays auf das man nur einmal beim Einstellen der Frequenz schaut und welches sich nach 20 Minuten eh abschaltet? Der Sinus vom Semir bleibt. Ist absolut top, alles andere wäre ein technischer Rückschritt. LG old.
Dann ist das ja auch kein Problem, wenn sich beim Einstellen der Frequenz die Frequenz ändert und zusätzlich auch kurz der Sinus verdellt ist. Warum wird hier Seitenlang über kein Problem diskutiert?
yesitsme schrieb: > Warum wird hier Seitenlang über kein Problem diskutiert? Weil manch Einer ein Podium benötigt...
Aus der W. schrieb: > Der Sinus vom Semir bleibt. Paranoia? Angstzustände? Werde mal wach! Dir will doch keiner deinen Sinus weg nehmen. Egal welches Etikett da drauf klebt. War da nicht was wg. Aussetzern, beim Betrieb mit I2C Displays? Das ist es doch, wo du das Handtuch wirfst, versagst, und deine neurotische Fehlanpassung ausleben musst.... Keiner will deinen ineffektiven Sinus haben.... Den kannste gerne behalten.
Arduino Fanboy D. schrieb: > War da nicht was wg. Aussetzern, beim Betrieb mit I2C Displays? Die sind doch irrelevant, wie wir gerade gelernt haben.
Aus der W. schrieb: > Zeno schrieb: >> bei dieser >> Formatierung darfst Du keine Hilfe erwarten > > Die Formatierung ist eine Ausrede wie Schaltbild angeblich > unleserlich oder so. Bekannt. Gähn. Ne Dein Quelltext ist schlichtweg unleserlich. Du vergißt anscheinenden, das jeder der Dir helfen soll sich erst mal in Deine "Denke" hinein versetzen muß, um überhaupt erst einmal zu verstehen was Du da machst. Fremde Gedankenzüge nachvollziehen ist schon schwer genug und wenn man dann noch den Quelltext auseinander puzzeln muß wird es noch schwerer. Da hat man dann ganz schnell keine Lust mehr. Es kann doch wohl nicht so schwer sein, z.B. alle if Schleifen in einem einheitlichen Stil zu formatieren. Es ist auch eine Frage der Höflichkeit, das man denen, von denen man Hilfe haben möchte, das Leben - sprich lesen des Sourcecodes - nicht unnötig erschwert. Aber offensichtlich willst Du keine Hilfe haben.
Thread beobachten
Seitenaufteilung abschalten