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.
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.
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.
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?
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:> 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!
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
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.
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().
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.
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.
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.
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
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:> 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.
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.
voidint_1ms(void)// to be called from the 1ms interrupt
10
{
11
staticuint8_tstep25;
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.
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
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.
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.
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?
ä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?
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?
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.
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.
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.
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.
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.
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.
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!
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.
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.
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.
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.
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 :)
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?
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_tI2C::sendByte(uint8_ti2cData)
2
{
3
TWDR=i2cData;
4
unsignedlongstartingTime=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_tbufferedStatus=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?
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).
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.
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
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.
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?
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.
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