Der AVR-/ARDUINO-Faden

Der chaotische Hauptfaden

Moderatoren: Heaterman, Finger, Sven, TDI, Marsupilami72, duese

Benutzeravatar
phettsack
Beiträge: 1203
Registriert: Mo 12. Aug 2013, 18:17

Re: Der AVR-/ARDUINO-Faden

Beitrag von phettsack »

DIESER Faden nennt sich ja schliesslich auch "Arduino".

Zabex spricht mir aus der Seele. Ja, ich habe auf dem C64 angefangen zu programmieren, erst in Basic, dann in Simons-Basic und irgendwann sogar in Assembler mit dem SMON. Geile Scheisse:-) Später auch den Amiga mit Assembler gequält. Jetzt, Jahre später bin ich auch ergebnisorientiert.
Und jetzt? Diese kleinen Arduino-Platinchen oder der ESP8266 für wenig Euro aus Fernost. Dank der vielen Arduino-Libraries kommt man schnell zu einem Ergebnis. Temperatur auf einem OLED anzeigen, pffft, kein Thema. Kostenpunkt keine 10€.
Diesen Shield-Hype muss man ja nun nicht unbedingt mitmachen, vielleicht für einen Prototyp. Ja, vielleicht muss man dem ein oder anderen noch vermitteln, wie es unterhalb der Arduinooberfläche abläuft.
Was oft (auch mir manchmal fehlt) ist die Verwendung von Bauteilen wie Widerständen, ZDioden usw. Das man eben ein Relais nicht direkt am GPIO anpinnen kann sondern einen Transistor braucht.
Ja, direkt mit dem AVR-Studio kann man auch programmieren, das geht auch sehr komfortabel. Die Arduino-IDE ist nun auch nicht gerade ein Eye-Candy.

Direkt mit C ist das alles sicher noch effizienter. Aber: Unbenutzte Speicherzellen werden nicht in bar ausgezahlt und wenn es zu langsam oder komplex ist, nimmt man einen Raspberry ;)

Also, zankt euch nicht und verteufelt das Kram nicht. Einfach MACHEN und sich freuen das es geht.
Profipruckel
Beiträge: 1506
Registriert: Di 13. Aug 2013, 19:10
Wohnort: Niedersachsen Süd-Ost

Re: Der AVR-/ARDUINO-Faden

Beitrag von Profipruckel »

Hightech hat geschrieben:Keine Frage! Der Adruino ist DAS Einsteigerteil für Nichtlötkolbenhalterwindowsnutzer für einen leichten Einstieg.
Ich bin Windowsbenutzer und sehe keinen Grund, mich dafür zu schämen oder rechtfertigen zu müssen, Punkt.

Einen Lötkolben kann ich halten, seit ungefähr 45 Jahren! Ganz nett dabei, dass ich aktuell bevorzugt den halte, der von einem Arduino geregelt wird: (http://www.fingers-welt.de/phpBB/viewto ... 50#p117043) Sieht das so aus, als ob ich nicht löten könnte?
Hightech hat geschrieben:Die Kollegen hier im Forum sind aber keine kleinen Töchter mehr und können sich in 10Minuten einen ISP Adapter zusammenlöten.
Ja und Nein - hier im Forum tauchen zunehmend kleine Jungs auf, die einen Transistor nicht von einem Relais unterscheiden können und einen ISP-Adapter eben nicht könnten.
phettsack hat geschrieben:DIESER Faden nennt sich ja schliesslich auch "Arduino".
Danke für den Hinweis.
phettsack hat geschrieben:Zabex spricht mir aus der Seele.
Dem schließe ich mich an, sein Beispiel mit dem Dachlattentisch trifft den Kern.
phettsack hat geschrieben:Jetzt, Jahre später bin ich auch ergebnisorientiert.
Danke, so etwa habe ich das auch formuliert, ist aber scheinbar nicht verstanden worden.

Mein Einstieg in Prozessor und Controller war per Assembler, mit viel Zeitaufwand und hinreichend Frust. Ich bin sicher, dass ich auch einen AVR in Assembler beherrschen könnte. Ich will es aber garnicht, solange Arduino meine Anforderungen erfüllen kann.
phettsack hat geschrieben:Einfach MACHEN und sich freuen das es geht.
Amen. Und mit diesem, Deinem Schlußwort, beenden wir den Glaubenskrieg Arduino gegen Rohprozessor.
Name vergessen
Beiträge: 3261
Registriert: Mo 12. Aug 2013, 19:47

Re: Der AVR-/ARDUINO-Faden

Beitrag von Name vergessen »

@ Zabex: ich denke darüber nach, wie Du die Auflösung des im Atmega48 vorhandenen ADC durch Oversampling aufzumotzen. Jetzt hast Du auf Deiner HP geschrieben, daß der den Noise mittels eines PWM-Ausgangs erzeugt wird, der über ein RC-Glied daraus eine Dreiecksspannung macht. Das muß also schonmal nicht sooo toll dreieckig sein, sonst bräuchte es noch eine KSQ -> OK.
Leider werden bei mir bereits alle 6 PWM-Ausgänge anderweitig gebraucht, da ist keiner frei. Was aber frei wäre, ist CLKO (PB0). Die Frage ist jetzt: stört es, daß der ja zwangsweise synchron zum CPU-Takt (16MHz (internes RC) oder 20MHz (externer Quarz), muß ich noch gucken) und somit ggfs. auch irgendwie synchron zum ADC-Takt rennt? Der ADC braucht ja mehrere Zyklen zum Wandeln, also rennen derweil jede Menge Dreiecke dran vorbei, so daß ich mit Pech immer dieselbe Stelle treffe und somit keinen Rauscheffekt bekomme? Deine PWM ist ja auch irgendwie an den CPU-Takt gebunden, insofern könnte die zwar auch synchron laufen, aber immerhin nicht schneller als der Sampletakt. Knicken und NE555 oder sonstige Flipflopschaltung nehmen oder egal?
Benutzeravatar
Zabex
Beiträge: 633
Registriert: Di 2. Jul 2013, 08:45
Wohnort: Aldenhoven
Kontaktdaten:

Re: Der AVR-/ARDUINO-Faden

Beitrag von Zabex »

So besonders genau ist die Oversampling Geschichte sowieso nicht. Also schlage ich vor, du suchst dir einen freien Pin, auf den du ein Rechtecksignal programmierst. An den Port dann ein simples RC Glied. Dessen Ausgang ist kein Dreieck, aber was solls. Du kannst ja die Exponentielle Verteilung durch die Kondensator Ladekurve bei der Bewertung der ADC Ergebnisse. berücksichtigen.
Ein LM324 als Dreiecksgenerator wäre eine Alternative. Ein externer 16Bit ADC auch (z. B. MCP3426, Reichelt 2,67€)
Name vergessen
Beiträge: 3261
Registriert: Mo 12. Aug 2013, 19:47

Re: Der AVR-/ARDUINO-Faden

Beitrag von Name vergessen »

Hm, eine Reichelt-Bestellung ist leider erstmal nicht in Sicht, ansonsten wären die Viecher allein schon zum auf Halde legen sinnvoll. Wäre schön gewesen, wenn noch eine eingebaute Funktion genutzt werden hätte können. :) Welche Frequenz nehme ich eigentlich am Besten? Sicher irgendwas oberhalb der Samplingfrequenz, ideal genau so lange, wie ich Messungen anhäufe? Meine Idee wäre dann jetzt, den Pin genau immer dann zu toggeln, wenn ich eine Meßreihe zusammen habe?
Benutzeravatar
reutron
Beiträge: 1953
Registriert: Mo 12. Aug 2013, 19:58
Wohnort: Gottow
Kontaktdaten:

Re: Der AVR-/ARDUINO-Faden

Beitrag von reutron »

Bei Elektor gibt es das Buch hier.....bis zum 4.4.2016

Bild
Name vergessen
Beiträge: 3261
Registriert: Mo 12. Aug 2013, 19:47

Re: Der AVR-/ARDUINO-Faden

Beitrag von Name vergessen »

Hm, ich bekomme Gutscheincode ist ungültig". Muß man das über ein Schmierphone machen?
Benutzeravatar
Münsterländer
Beiträge: 329
Registriert: Fr 11. Okt 2013, 14:55
Wohnort: Borken (bei Holland)

Re: Der AVR-/ARDUINO-Faden

Beitrag von Münsterländer »

Bei mir läuft der Download vom PC problemlos. Danke für den Tipp!
ozonisator
Beiträge: 1653
Registriert: So 11. Aug 2013, 19:53
Wohnort: bei Frankfurt/Main

Re: Der AVR-/ARDUINO-Faden

Beitrag von ozonisator »

Wollte mal auf das Projekt hier: https://github.com/micronucleus/micronucleus aufmerksam machen. USB Bootloader für Attinys. Zusammen mit V-USB und einem defekten USB-Stick kann man so wunderbar einen Tastatur-Emulator bauen, der die Konsole öffnet, einen Texteditor ausführt, einen Batch Virus runterschreibt, speichert, alle Fenster schließt und den Virus ausführt :twisted:
Was auch lustig ist: das Teil unbemerkt einstöpseln, und in zufälligen Abständen ALT+F4 senden :lol:
Benutzeravatar
Fritzler
Beiträge: 12600
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Adlershof/Technologiepark
Kontaktdaten:

Re: Der AVR-/ARDUINO-Faden

Beitrag von Fritzler »

Gibt auch nen V-USB Bootloader, der sich als USBasp meldet.
Der ist dann aber natürlich etwas größer vom Code her.
Sir_Death
Beiträge: 3446
Registriert: Mo 11. Mai 2015, 22:36
Wohnort: südlich von Wien

Re: Der AVR-/ARDUINO-Faden

Beitrag von Sir_Death »

reutron hat geschrieben:Bei Elektor gibt es das Buch hier.....bis zum 4.4.2016

Bild

Cool! - Danke für den Tipp - schon gesichert.
Name vergessen
Beiträge: 3261
Registriert: Mo 12. Aug 2013, 19:47

Re: Der AVR-/ARDUINO-Faden

Beitrag von Name vergessen »

Ich doktore gerade an der 16 Bit PWM herum, um einen Analogwert zu basteln. Die läuft mit "Fast" PWM bei 16 MHz mit 244Hz, was schonmal nicht ganz so leicht zu filtern ist (die 16 Bit machen ja keinen Sinn, wenn der Ripple darauf 40mVpp ist...). Um das auch nur einigermaßen glattzubiegen brauche ich schon einen Tiefpaß 3. Ordnung, und zwar 10K-470nF-22K-220nF-47K-100nF. Das habe ich auf dem Steckbrett zusammengemurkst, kann das hinkommen oder ist da was faul?

BTW, das mit dem aktiven TP vor einiger Zeit war tatsächlich Murks, der C am OP hatte keinerlei filternde Wirkung. Habe das dann nochmal mit einem normalen Sallen-Key Filter probiert, das hat aber (wenn überhaupt) bei 1 KHz nur marginal besser geglättet als ein passiver TP 2. Ordnung, und dann bei den 244Hz angefangen zu schwingen (jede ca. 10. Welle war erheblich kleiner). Letzteres mag am Steckbrettverhau in Kombination mit dem Zusatztransistor usw. gelegen haben, oder mit Pech war die Wertekombi (aus dem Bild letztens) einfach ungünstig.
Benutzeravatar
ferdimh
Beiträge: 9420
Registriert: Fr 16. Aug 2013, 15:19

Re: Der AVR-/ARDUINO-Faden

Beitrag von ferdimh »

Kannst du mal nen Schaltplan skizzieren und hier einstellen? Ich komme da nicht ganz mit, was du versucht hast.
Benutzeravatar
Fritzler
Beiträge: 12600
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Adlershof/Technologiepark
Kontaktdaten:

Re: Der AVR-/ARDUINO-Faden

Beitrag von Fritzler »

Sallen Key ist eben nicht gleich Sallen Key.
Da kann die RC Kombi zwar rechnerisch deine gewünschte Frequenz erreichen, aber die Filtercharakteristik ist Murks oder der Sallen Key schwingt sogar.

Daher mit nem Tool ausrechnen lassen und dann auf dem Steckbrett testen.
http://sim.okawa-denshi.jp/en/OPseikiLowkeisan.htm
Benutzeravatar
ferdimh
Beiträge: 9420
Registriert: Fr 16. Aug 2013, 15:19

Re: Der AVR-/ARDUINO-Faden

Beitrag von ferdimh »

Ergänzend den Kram in SPICE simulieren und nochmal in Echt messen (insbesondere bei Filtern 3. Ordnung).
Einige Bauteilwerte sind sehr empfindlich, andere weniger. Wenn man es mit einem Emitterfolger aufbaut, unbedingt damit simulieren!
Die Nicht-ganz-1-Verstärkung eines Emitterfolgers reicht aus, um alle shcönen Berechnungen zu verbiegen.
Name vergessen
Beiträge: 3261
Registriert: Mo 12. Aug 2013, 19:47

Re: Der AVR-/ARDUINO-Faden

Beitrag von Name vergessen »

Danke für die Antworten! Das, was geschwungen hat, ist dieses Gebilde:
Bild
Wahrscheinlich ist der Abzweig direkt am OP falsch und gehört eigentlich aber hinter die Transe, aber dazu hatte ich keine Idee. Da aber der passive TP nicht schlechter ist, was soll's. Der OP war 1/4 LM324, dessen zweites Viertel vergleichend den passiven TP davor hatte. Die beiden anderen waren unbeschaltet, das würde in der Endversion natürlich nicht passieren.

Für die 16 Bit wird die Zusatztranse aber nicht benutzt, das wäre dann nur der OP als Spannungsfolger mit passivem TP davor (RCRCRC, Werte wie im vorigen Post), oder als aktiver SK-TP und einem passiven TP davor wie bei Wikipedia. Ist am Ende offenbar egal, mit dem SK brauche ich genau gleich viele Teile wie mit dem passiven TP.

Einerseits verstehe ich jetzt, weshalb die meisten Leute nur die 8 Bit PWM benutzen, andererseits nicht, wie das mit Klasse D überhaupt irgendwie funktioniert, da braucht man ja allein dafür mindestens 3,2 GHz, um da mit 16 Bit auch nur auf die 20 KHz zu kommen? :shock: Oder wird da was aus zwei 8 Bit PWM zusammengefummelt, so wie hier?

Muß ich wirklich auf 1K+100µF gehen, damit das am Ende sauber ist? :(
Benutzeravatar
Fritzler
Beiträge: 12600
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Adlershof/Technologiepark
Kontaktdaten:

Re: Der AVR-/ARDUINO-Faden

Beitrag von Fritzler »

ClassD Amps erzeugen die PWM ja analog, da haste son Problem nicht oder es wird ein "1 Bit DAC" genutzt.
Zudem bräuchteste 44kHz Samplerate und nicht 20KHz, also fast 7GHz :lol:

Sallen Key und Stromregler in einen Opamp packen ist nicht die beste Idee, das sollte schon in 2 Opamps erledigt werden und mit dem LM324 haste ja genug davon.
Wahrscheinlich ist der Abzweig direkt am OP falsch und gehört eigentlich aber hinter die Transe
Hä?
Benutzeravatar
ferdimh
Beiträge: 9420
Registriert: Fr 16. Aug 2013, 15:19

Re: Der AVR-/ARDUINO-Faden

Beitrag von ferdimh »

Dieser Tiefpass ist nicht wirklich sinnvoll. Das braucht einen exakten Folger, sonst tut das nicht. Es macht hier bei den Preisen für 4fach-Opamps auch keinen Sinn zu geizen und mit Kunstschaltungen anzufangen (und ich erwische micht ständig wieder dabei).
Ein LM324 macht bei unbeschalteten Eingängen keinen Blödsinn.
Der Trick mit den Class-D-Endstufen ist in mehreren Varianten verfügbar:
a) Sinnvoll: Analoge PWM-Erzeugung. Damit ist die Frage der Quantisierung von selbst erledigt, man kann außerdem tatsächlich gegenkoppeln.
b) Billig: Noise Shaping. Es wird kein Sägezahn zum vergleichen genutzt. Stattdessen wird ein deutlich aufwendigerer Algorithmus verwendet, der ein sehr viel hochfrequenzlastigeres Signal erzeugt (das Grundprinzip heißt Delta-Sigma-Modulation). Das funzt als Wandler 2. Ordnung ganz ok, wenn die Betriebsspannung konstant ist, und ist ein sehr guter (der Beste?) Weg, einen D/A-Wandler zu implementieren. Erst Logik, dann Tiefpass ist sehr einfach zu bauen und heilt quasi alle Krankheiten konventioneller D/A-Wandler (Bei einem klassischen R-2R-Wandler hängt die Genauigkeit im Wesentlichen von der Genauigkeit des höchstwertigen Widerstandes ab. Da das Ausgangssignal meistens nur ein Bisschen um die Mitte wackelt, kippelt das höchste Bit ständig, und ein Fehler dort ist SEHR gut hörbar.
c) Sehr billig: Dithering mit "gespiegeltem Sägezahn". Statt mit stetig steigenden Zahlen zu vergleichen, wie bei der klassischen PWM, nimmt man einen Zähler, lässt ihn immer von Null bis Vollstoff laufen, spiegelt das Bitmuster, und vergleicht damit. Bei einem 4-Bit Wandler sieht das so aus:
|:0 8 4 12 2 10 6 14 1 9 5 13 3 11 7 15:| Wenn man jetzt mit z.B. mit der 6 (<) vergleicht, ergibt sich |:1010100010101000:| Das gibt ein deutlich schnelleres Wackeln, das von der Performance mit einem Delta-Sigma-Wandler 1. Ordnung vergleichbar ist (es kommt nicht ganz ran). Das findet sich soweit ich weiß im "ach so tollen" Audioausgang vom Raspberry Pi, mit 48MHz Takt.
d) Chinastandard: Scheiß auf Auflösung. 8Bit sind für Musik vollkommen ausreichend.
Name vergessen
Beiträge: 3261
Registriert: Mo 12. Aug 2013, 19:47

Re: Der AVR-/ARDUINO-Faden

Beitrag von Name vergessen »

Fritzler hat geschrieben:Sallen Key und Stromregler in einen Opamp packen ist nicht die beste Idee, das sollte schon in 2 Opamps erledigt werden und mit dem LM324 haste ja genug davon.
Naja, der LM324 wird ohnehin voll genutzt werden, sonst hätte ich einen LM358 genommen. ;) Natürlich könnte ich noch einen nehmen, aber wenn der aktive TP eh keine Vorteile im Frequenzgang bringt, ist das wohl eher was für schwachbrüstige Signale?
Fritzler hat geschrieben:
Wahrscheinlich ist der Abzweig direkt am OP falsch und gehört eigentlich aber hinter die Transe
Hä?
Ich ging davon aus, daß der Transistor als Teil der Regelkette dann eben auch Teil des Filters werden müßte (Rückkopplung über alles), nur konnte ich mir keinen sinnvollen Punkt vorstellen, an dem der Kondensator angeschlossen werden könnte. Es kämen ja nur in Frage: am Emitter oder am Kollektor, beides kommt mir aber unrichtig vor.
ferdimh hat geschrieben:Dieser Tiefpass ist nicht wirklich sinnvoll. Das braucht einen exakten Folger, sonst tut das nicht. Es macht hier bei den Preisen für 4fach-Opamps auch keinen Sinn zu geizen und mit Kunstschaltungen anzufangen (und ich erwische micht ständig wieder dabei).
OK, also einen zweiten OP dahinter. Naja, da die minimale Verbesserung mit aktivem TP vermutlich entweder pure Einbildung oder das Produkt geänderter Drahtführung war, werde ich das also einfach lassen und passiv aufbauen, damit umgehe ich diese Probleme und Nachteile scheint das ja nicht zu haben. :)
ferdimh hat geschrieben:Ein LM324 macht bei unbeschalteten Eingängen keinen Blödsinn.
Gut zu wissen, ich fühlte mich schon etwas schuldig. :)
ferdimh hat geschrieben:Der Trick mit den Class-D-Endstufen ist in mehreren Varianten verfügbar:
a) Sinnvoll: Analoge PWM-Erzeugung. Damit ist die Frage der Quantisierung von selbst erledigt, man kann außerdem tatsächlich gegenkoppeln.
b) Billig: Noise Shaping. Es wird kein Sägezahn zum vergleichen genutzt. Stattdessen wird ein deutlich aufwendigerer Algorithmus verwendet, der ein sehr viel hochfrequenzlastigeres Signal erzeugt (das Grundprinzip heißt Delta-Sigma-Modulation). Das funzt als Wandler 2. Ordnung ganz ok, wenn die Betriebsspannung konstant ist, und ist ein sehr guter (der Beste?) Weg, einen D/A-Wandler zu implementieren. Erst Logik, dann Tiefpass ist sehr einfach zu bauen und heilt quasi alle Krankheiten konventioneller D/A-Wandler (Bei einem klassischen R-2R-Wandler hängt die Genauigkeit im Wesentlichen von der Genauigkeit des höchstwertigen Widerstandes ab. Da das Ausgangssignal meistens nur ein Bisschen um die Mitte wackelt, kippelt das höchste Bit ständig, und ein Fehler dort ist SEHR gut hörbar.
c) Sehr billig: Dithering mit "gespiegeltem Sägezahn". Statt mit stetig steigenden Zahlen zu vergleichen, wie bei der klassischen PWM, nimmt man einen Zähler, lässt ihn immer von Null bis Vollstoff laufen, spiegelt das Bitmuster, und vergleicht damit. Bei einem 4-Bit Wandler sieht das so aus:
|:0 8 4 12 2 10 6 14 1 9 5 13 3 11 7 15:| Wenn man jetzt mit z.B. mit der 6 (<) vergleicht, ergibt sich |:1010100010101000:| Das gibt ein deutlich schnelleres Wackeln, das von der Performance mit einem Delta-Sigma-Wandler 1. Ordnung vergleichbar ist (es kommt nicht ganz ran). Das findet sich soweit ich weiß im "ach so tollen" Audioausgang vom Raspberry Pi, mit 48MHz Takt.
d) Chinastandard: Scheiß auf Auflösung. 8Bit sind für Musik vollkommen ausreichend.
Oha. Gibt es Delta-Sigma-Modulations-DAs auch einzeln? Das sollte dann ja billiger sein als Hochgeschwindigkeits-DAs.
Das mit der analogen PWM-Erzeugung blicke ich leider nicht; wenn das Signal schon analog ist, braucht man doch den Wandler nicht mehr...?


Den Filterrechner habe ich mal bemüht und ich sehe auch Unterschiede im Dämpfungsfaktor; aus den probierten Werten und Ergebnissen schließe ich, daß das nicht die Dämpfung der zu sperrenden Frequenzen ist (die ist bei einem TP der Ordnung X ja immer gleich), sondern des Gesamtsignals->je niedriger desto besser. Ist 1,3 generell akzeptabel oder muß das ganz woanders liegen?

Und ich habe mit dem Tool den schwingenden Filter probiert. In meiner Anordnung errechnet der eine Schwingfrequenz von 159 Hz... paßt zwar nicht ganz zu den 244Hz, reicht aber wohl. War ja klar, daß ich da wieder genau die Sch*iße treffe. :( Hätte ich die Kondis beide mit 15n benutzt, hätte das nicht geschwungen. Gut, andererseits weiß ich jetzt, daß bei einem SKF C2 anscheinend niemals kleiner sein darf als C1, sonst schwingt es. Ist ja auch schon was. Warum steht sowas eigentlich nirgends? Naja, es stimmt immerhin mit dem Text von TI überein, wo man immer C2=2*C1 nehmen soll.

Mann mann, ich glaube, 1K und 100µF wären bequemer, aber die Reaktionszeit davon ist mit 0,7s eher mau, und selbst dann dämpft es nicht gut genug... abgesehen davon: spricht eigentlich etwas gegen Elkos?

Á propos Elkos: beim Gucken, was andere Leute so machen, habe ich gesehen, daß die mit Widerständen von 330 Ohm aufwärts loslegen; hat das, trotz des folgenden OPs, Vorteile, so niedrige Widerstände (und entsprechend größere Kondensatoren) zu benutzen?
Benutzeravatar
Marsupilami72
Beiträge: 2874
Registriert: Mo 4. Nov 2013, 23:48
Wohnort: mittendrin

Re: Der AVR-/ARDUINO-Faden

Beitrag von Marsupilami72 »

reutron hat geschrieben:Bei Elektor gibt es das Buch hier.....bis zum 4.4.2016

Bild
Ich hab die Aktion voll verpennt, kann mir einer das Pdf zuschicken (ganzliebguck ;) ?
Zuckermais
Beiträge: 71
Registriert: So 11. Aug 2013, 15:47

Re: Der AVR-/ARDUINO-Faden

Beitrag von Zuckermais »

nö, die sind mit einem Wasserzeichen versehen. Das fällt auf, wenn ich das jemanden zusende.

Zuckermais
Benutzeravatar
Marsupilami72
Beiträge: 2874
Registriert: Mo 4. Nov 2013, 23:48
Wohnort: mittendrin

Re: Der AVR-/ARDUINO-Faden

Beitrag von Marsupilami72 »

Dass ich das nicht weiter verteile, sollte wohl selbstverständlich sein.

Ich habe das PDF aber schon von einem anderen User bekommen - das Thema hat sich also erledigt.
Benutzeravatar
ferdimh
Beiträge: 9420
Registriert: Fr 16. Aug 2013, 15:19

Re: Der AVR-/ARDUINO-Faden

Beitrag von ferdimh »

atürlich könnte ich noch einen nehmen, aber wenn der aktive TP eh keine Vorteile im Frequenzgang bringt, ist das wohl eher was für schwachbrüstige Signale?
Der aktive Tiefpass hat (genau wie sein LC-Äquivalent) gegenüber RC massive Vorteile im Frequenzgang, wenn er richtig dimensioniert ist. Dafür ist genau die gegebene "Schwingneigung" verantwortlich.
Ein RC-Tiefpass hat einen "weichen" Knick. Wenn man davon mehrere kaskadiert, hat man mehrere weiche Knicke.
Das Draufsetzen einer Resonanz drückt einen härteren Knick rein, indem es erst hochdrückt (Tiefpass fällt ab, Resonanz steigt) und dann runterdrückt (Resonanz fällt ab, Tiefpass auch). Das macht Filter möglich, die einer Mauer sehr nahe kommen. Mit RC hat man immer einen weichen Übergang.
Ich ging davon aus, daß der Transistor als Teil der Regelkette dann eben auch Teil des Filters werden müßte (Rückkopplung über alles), nur konnte ich mir keinen sinnvollen Punkt vorstellen, an dem der Kondensator angeschlossen werden könnte. Es kämen ja nur in Frage: am Emitter oder am Kollektor, beides kommt mir aber unrichtig vor.
Es gibt auch ohne keinen "richtigen" Punkt dafür. Der Emitter wäre von der Phasenlage her richtig, ist aber hochohmig und damit tabu(Aller Strom, der da fließt, fließt auch durch die Last). Man könnte versuchen eine "am wenigsten falsche" Lösung zu finden, aber auf die Schmerzen habe ICH keine Lust.
Das mit der analogen PWM-Erzeugung blicke ich leider nicht; wenn das Signal schon analog ist, braucht man doch den Wandler nicht mehr...?
Wenn ich meine Leistungsstufe mit PWM bauen will (aus Wirkungsgradgründen), dann brauche ich nunmal ne PWM aus einem analogen Signal. PWM ist mehr als "Billiger DAC-Ersatz von Mikrocontrollern". Das ist ja letzten Endes die Idee des Class-D. Dass das irgendwie Digital und Toll sein soll haben Marketingstrategen angedichtet.
Den Filterrechner habe ich mal bemüht und ich sehe auch Unterschiede im Dämpfungsfaktor; aus den probierten Werten und Ergebnissen schließe ich, daß das nicht die Dämpfung der zu sperrenden Frequenzen ist (die ist bei einem TP der Ordnung X ja immer gleich), sondern des Gesamtsignals->je niedriger desto besser. Ist 1,3 generell akzeptabel oder muß das ganz woanders liegen?
Der Frequenzgang muss Sinn ergeben und zur Anwendung passen. Wenn das Ding eh beliebig träge sein darf (was ich langsam vermute) ist die Güte egal, und man kann tatsächlich jeden beliebigen Wert verwenden.
Ein Hochpass vor einem Hochtöner in einer Box wird eher eine hohe Güte haben, weil der Hochtöner nach unten hin weniger kann (die Überhöhung kompensiert das etwas), der dazugehörige Tiefpass aber eine niedrige (dafür evtl eine Ordnung mehr), weil der Frequenzgang des Tieftöners in der Regel sowieso zu hohen Frequenzen hin langsam ansteigt (Die Membran fängt an zu machen, was sie will -> Resonanzen -> mehr Dampf). Der langsam fallenden Tiefpass kompensiert das so.
Name vergessen
Beiträge: 3261
Registriert: Mo 12. Aug 2013, 19:47

Re: Der AVR-/ARDUINO-Faden

Beitrag von Name vergessen »

ferdimh hat geschrieben:Der aktive Tiefpass hat (genau wie sein LC-Äquivalent) gegenüber RC massive Vorteile im Frequenzgang, wenn er richtig dimensioniert ist. Dafür ist genau die gegebene "Schwingneigung" verantwortlich.
Ein RC-Tiefpass hat einen "weichen" Knick. Wenn man davon mehrere kaskadiert, hat man mehrere weiche Knicke.
Das Draufsetzen einer Resonanz drückt einen härteren Knick rein, indem es erst hochdrückt (Tiefpass fällt ab, Resonanz steigt) und dann runterdrückt (Resonanz fällt ab, Tiefpass auch). Das macht Filter möglich, die einer Mauer sehr nahe kommen. Mit RC hat man immer einen weichen Übergang.
Aha, OK. Ich habe die Bildchen vom Frequenzgang zwar verglichen, aber diesen Unterschied nicht gesehen, muß ich wohl nochmal gucken!
ferdimh hat geschrieben:Es gibt auch ohne keinen "richtigen" Punkt dafür. Der Emitter wäre von der Phasenlage her richtig, ist aber hochohmig und damit tabu(Aller Strom, der da fließt, fließt auch durch die Last). Man könnte versuchen eine "am wenigsten falsche" Lösung zu finden, aber auf die Schmerzen habe ICH keine Lust.
Hm, naja, immerhin habe ich dann keine offensichtliche Lösung übersehen. :) Ist auch für die Anwendung nicht wichtig genug, sich da so viel Arbeit zu machen, mir fehlt halt nur komplett das Gefühl für das analoge Zeug, da muß ich mich reinfinden und offenbar erstmal alle Fallen ausprobieren. :)
ferdimh hat geschrieben:Wenn ich meine Leistungsstufe mit PWM bauen will (aus Wirkungsgradgründen), dann brauche ich nunmal ne PWM aus einem analogen Signal. PWM ist mehr als "Billiger DAC-Ersatz von Mikrocontrollern". Das ist ja letzten Endes die Idee des Class-D. Dass das irgendwie Digital und Toll sein soll haben Marketingstrategen angedichtet.
Ah, OK. Daß man PWM auch analog erzeugen kann, klar; ich hatte das so gelesen, daß das irgendwie zur DAC-Wandlung gehören könnte.
ferdimh hat geschrieben:Der Frequenzgang muss Sinn ergeben und zur Anwendung passen. Wenn das Ding eh beliebig träge sein darf (was ich langsam vermute) ist die Güte egal, und man kann tatsächlich jeden beliebigen Wert verwenden.
Naja, im Dezisekundenbereich sollte es schon noch liegen, schneller wäre nett, aber mehr auch nicht. Ich versuche eher, hinter die ganze Sache zu blicken und Ahnung zu bekommen, was wofür wichtig ist. Ich habe jetzt den TP 3. Ordnung mit 10K->1µF->22K->470nF->47K->220nF, damit sehe ich unter dem ganzen Rauschen keinen Sägezahn mehr und es reagiert noch schnell genug, kann also so bleiben.
ferdimh hat geschrieben:Ein Hochpass vor einem Hochtöner in einer Box wird eher eine hohe Güte haben, weil der Hochtöner nach unten hin weniger kann (die Überhöhung kompensiert das etwas), der dazugehörige Tiefpass aber eine niedrige (dafür evtl eine Ordnung mehr), weil der Frequenzgang des Tieftöners in der Regel sowieso zu hohen Frequenzen hin langsam ansteigt (Die Membran fängt an zu machen, was sie will -> Resonanzen -> mehr Dampf). Der langsam fallenden Tiefpass kompensiert das so.
Die Güte ist also die Schräge der Kurve? Ich dachte, das wäre immer 60dB / Oktave? Zwar habe ich schon gelesen, daß mit höherer Güte die Peaks (bzw. Täler) steiler und dafür schmaler werden, aber wie paßt das zusammen mit der Angabe XdB / Oktave?
Ist schon etwas frustrierend, wenn man tagelang über Filter liest und dann trotzdem die einfachsten Dinge nachfragen muß. :(
Benutzeravatar
ferdimh
Beiträge: 9420
Registriert: Fr 16. Aug 2013, 15:19

Re: Der AVR-/ARDUINO-Faden

Beitrag von ferdimh »

´Die Güte ist also die Schräge der Kurve? Ich dachte, das wäre immer 60dB / Oktave? Zwar habe ich schon gelesen, daß mit höherer Güte die Peaks (bzw. Täler) steiler und dafür schmaler werden, aber wie paßt das zusammen mit der Angabe XdB / Oktave?
Nein.
Zwei getrennte Baustellen.
a) Die Steigung der Kurve weit oberhalb der Grenzfrequenz (wir betrachten hier jetzt nur Tiefpässe!) . Die hängt nur von der Filterordnung ab.
b) Das Verhalten um die Grenzfrequenz rum. Hier ist die Auslegung des Filters entscheidend. Ein Butterworth versucht so flach zu sein wie möglich, ein Tschebyscheff lässt eine Welligkeit zu (hat dafür einen härteren Knick), ein Bessel ist für Phasenverhalten optimiert. Bei einem Tiefpass 2. Ordnung gibt es nur einen Buckel, desen "Hubbeligkeit" durch die Güte beschrieben wird. Je höher die Güte (=1/Dämpfung) desto spitzer piekt es da raus. Man kann jetzt natürlich mehrere Filter mit verschiedenen Grenzfrequenzen und Güten kaskadieren, so dass noch im Durchlassbereich der erste Peak liegt, danach folgt steiler Abfall, der aber von der nächsten Filtersektion wieder aufgefangen wird (es geht auf die nächste Resonanz zu), usw. Bei ausreichend "sportlicher" Auslegung kommen dabei Filter raus, die 20kHz noch mit -3dB durchlassen, aber bei 22kHz schon 60dB oder so dämpfen. Als Anschauungsobjekt habe ich hier mal den Frequenzgang einer Soundkarte aus dem Netz gezogen; der steile Knick ist deutlich sichtbar, die Welligkeit vorher auch:
Bild
Name vergessen
Beiträge: 3261
Registriert: Mo 12. Aug 2013, 19:47

Re: Der AVR-/ARDUINO-Faden

Beitrag von Name vergessen »

Aha, das ist das also! Dann beschreiben diese Bildchen also diesen Übergang.

Es macht also nur Sinn, an der Güte zu feilen oder die Filterart zu ändern, wenn man mit der Grenzfrequenz in die Nähe der wegzufilternden Frequenz muß. Wenn es aber egal ist, ob vor der zu filternden Frequenz noch etwas beeinflußt wird oder nicht, kann man nur die Ordnung erhöhen und/oder die Grenzfrequenz senken. In meinem Fall (244Hz) ist also schon ab einer Grenzfrequenz von ca. 200Hz egal.
Jede zusätzliche Filterordnung halbiert die Restwelligkeit, also müßte unter dem Noise bei mir noch eine Welle liegen, die erst bei einem anständigen Aufbau sichtbar wird, also entweder brauche ich mindestens noch eine Stufe oder die Grenzfrequenz muß noch eine Dekade runter.
frickelfred56
Beiträge: 240
Registriert: Mo 16. Feb 2015, 13:50

Re: Der AVR-/ARDUINO-Faden

Beitrag von frickelfred56 »

Hallo zusammen

Ich versuche gerade mir ein Schaltmodul zu Basteln, welches zu Sonnenaufgang und Untergang schaltet.
dazu habe ich das DCF77 Modul (http://playground.arduino.cc/Code/DCF77) mit der Berechnung der Sonnenauf -
Untergangzeit zusammengeschaltet. ( http://www.arduinoforum.de/arduino-Thre ... teuerungen ) Danke für den Code. Das klappt auch alles .
Und hier nun mein Problem?
Für die Umschaltung zwischen Sommer und Winterzeit benötige ich das Entsprechende DCF Signal (Bit 17 oder 18 ) im DCF Protokoll.

Hier ein kurzer Ausschnittt aus Der Datei DCF77.cpp

//convert the received buffer into time
time.Second = 0;
time.Minute = rx_buffer->Min-((rx_buffer->Min/16)*6);
time.Hour = rx_buffer->Hour-((rx_buffer->Hour/16)*6);
time.Day = rx_buffer->Day-((rx_buffer->Day/16)*6);
time.Month = rx_buffer->Month-((rx_buffer->Month/16)*6);
time.Year = 2000 + rx_buffer->Year-((rx_buffer->Year/16)*6) -1970;
latestupdatedTime = makeTime(time);
CEST = rx_buffer->CEST;
//Parity correct
return true;
} else {
//Parity incorrect
return false;
}

Wenn ich den Code richtig verstanden habe, stellen die Var CST und CEST die gesuchten Variablen dar ?

Wie kann ich auf die Variablen von der Arduino Sketch Ebene zugreifen.

Danke für die Antworten und soory für den (Ewig) Langen Text.
Kenakapheus
Beiträge: 173
Registriert: Fr 1. Jan 2016, 20:43
Wohnort: Freie Feldlage (Ja, da wo das Treffen ist))

Re: Der AVR-/ARDUINO-Faden

Beitrag von Kenakapheus »

Hi,

ohne weiteres geht das leider nicht, die Variable ist im Objekt als Privat markiert und daher nicht von außen sichtbar.

ABER...
Mit etwas gefrikel geht es schon.

Ich habe leider gerade keinen Compiler zum überprüfen da, aber eigentlich sollte das so klappen.
Wenn nicht Poste doch bitte mal die Fehlermeldung und den gesamten Sketch.

Code: Alles auswählen

struct overlay_s {
	bool initialized;	
	static int dCF77Pin;
	static int dCFinterrupt;
	static byte pulseStart;
	static time_t previousUpdatedTime;
	static time_t latestupdatedTime;           	
	static  time_t processingTimestamp;
	static  time_t previousProcessingTimestamp;		
	static unsigned char CEST;
} *dcf_overlay = (overlay_s *)(&DCF77);

unsigned char CEST = dcf_overlay->CEST;
Wobei [DCF77] die Insanz der Library ist (Die Variable, die du mit .getTime() benutzt).

Grüße Kenakapheus
frickelfred56
Beiträge: 240
Registriert: Mo 16. Feb 2015, 13:50

Re: Der AVR-/ARDUINO-Faden

Beitrag von frickelfred56 »

Hallo
Erst mal Danke für die Antwort.
komme Heute leder nicht dazu das zu Probieren.
melde mich wenn ich es probiert habe
Name vergessen
Beiträge: 3261
Registriert: Mo 12. Aug 2013, 19:47

Re: Der AVR-/ARDUINO-Faden

Beitrag von Name vergessen »

Hm... das ist alles diese Arduino-Sprache? Damit kenne ich mich nicht aus, aber bei C++ würde der einfach in der abgeleiteten Klasse eine neue Variable aufmachen, die dann intern aber nicht benutzt wird. Somit gäbe es keine Fehlermeldung, aber der Wert wäre immer 0.

Andernfalls wäre das "private:" ja auch ziemlich witzlos.

Da müßte man schon die Header der Lib ändern und zumindest mal protected daraus machen, dann könnte man immerhin mit Zugriffsfunktionen arbeiten (oder einfach gleich in dem Header noch die passende Zugriffsunktion eintragen). OK, wir sind ja auf einem µC, da könnte man jetzt gucken, wo der die Variable hinlegt und manuell in Assembler darauf zugreifen, dagegen kann sich der Compiler ja nicht wehren, aber das muß man dann dauernd selber nachprüfen, ob das noch die richtige Adresase benutzt, bei einem größeren Projekt will man das nicht...
Kenakapheus
Beiträge: 173
Registriert: Fr 1. Jan 2016, 20:43
Wohnort: Freie Feldlage (Ja, da wo das Treffen ist))

Re: Der AVR-/ARDUINO-Faden

Beitrag von Kenakapheus »

Hi,

nein das ist ganz normales C/C++, aber wie kommst du darauf das der Code die Klasse ableitet?
Die Variablen im Struct stehen genauso in der Klasse werden nur gebraucht damit der Compiler weiß wo der Wert steht.

Im Prinzip habe ich genau das vor was du als 2. vorgeschlagen hast:
Der Code greift einfach auf das richtige Byte im RAM zu. Allerdings überlasse ich das ausrechnen der genauen
Adresse dem Compiler, somit müsste sich schon was an der Lib ändern damit der Trick nicht mehr klappt.

Grüße Kenakapheus
Blueloop
Beiträge: 148
Registriert: Mo 12. Aug 2013, 17:59
Wohnort: Ettlingen

Re: Der AVR-/ARDUINO-Faden

Beitrag von Blueloop »

Warum so kompliziert, man kann doch einfach die LIB ändern, die kommt ja eh als Sourcecode.
Ist auf jedenfall besser als so ein Hack da zu basteln. Natürlich gehts beim nächsten Update der Lib nichtmehr, aber da kann man sich ja einen Kommentar in seinen Code Stricken der auf die notwendige Anpassung hinweist, damit man das in 5 Jahren noch weiß.
Name vergessen
Beiträge: 3261
Registriert: Mo 12. Aug 2013, 19:47

Re: Der AVR-/ARDUINO-Faden

Beitrag von Name vergessen »

Ah, OK, ich hatte angenommen, das sei nicht echtes C++ und habe daher gar nicht auf die Syntax geachtet. Du machst einfach einen Cast (reinterpret_cast) in ein außer dem "private:" identisches struct, das würde das automatisieren, stimmt, müßte so gehen. Blueloops Einwand gilt natürlich trotzdem (da die lib wahrscheinlich nicht vorkompiliert geladen wird, dürften auch geänderte Compileroptionen nicht vorkommen), ist nur die Frage, ob die überhaupt noch geupdated wird und wenn ja, ob das struct verändert wird. ich schreibe an solche Stellen immer ein "#warning <Grund>", das sieht man spätestens beim Neukompilieren, den alten Code guckt man ja nicht komplett durch bei einer Änderung.
Benutzeravatar
xoexlepox
Beiträge: 4815
Registriert: So 11. Aug 2013, 19:28
Wohnort: So etwa in der Mitte

Re: Der AVR-/ARDUINO-Faden

Beitrag von xoexlepox »

Falls du nicht an dem Library-Code herumschrauben möchtest, sehe ich noch drei weitere Möglichkeiten:

1) Wenn ich es beim kurzen Überfliegen richtig mitbekommen habe, liefert die Lib den aktuellen Zeitpunkt sowohl als UTC, als auch als "offizielle" Zeit. Wenn du davon die Differenz bildest, bekommst du auch heraus, ob es nun Sommerzeit ist, oder nicht.

2) Womit wird denn das Modul zur Sonnenaufgangsberechnung "gefüttert"? Das Sinnvollste wäre doch UTC, dann baucht man sich um diesen ganzen Mist der Zeitumstellung keine Gedanken zu machen ;)

3) Wenn du das Datum hast, sollte es kein großes Problem sein, daraus zu bestimmen, ob das nun Sommerzeit ist, oder nicht. Etwas fummelig wird dabei zwar die nächtliche fehlende (oder überzählige) Stunde, aber zu diesen Zeiten ist die Sonne sicher unter dem Horizont ;)
frickelfred56
Beiträge: 240
Registriert: Mo 16. Feb 2015, 13:50

Re: Der AVR-/ARDUINO-Faden

Beitrag von frickelfred56 »

Hallo zusammen

Erstmal Danke für die Antworten
Leider kann ich die nächten Wochen an dem Projekt nicht weitermachen.
Die Gesundheit fordert andere Prioritäten.
Myvesdin
Beiträge: 45
Registriert: Sa 5. Apr 2014, 10:20

Re: Der AVR-/ARDUINO-Faden

Beitrag von Myvesdin »

Moin moin,

ich bin gerade einwenig am verzweifeln.

Code: Alles auswählen

#include <DS1307RTC.h>
#include <Wire.h> 
#include <LiquidCrystal_I2C.h>
#include <Time.h>

LiquidCrystal_I2C lcd(0x27,20,4);  // set the LCD address to 0x27 for a 20 chars and 4 line display
uint8_t heart[8] = {0x0,0xa,0x1f,0x1f,0xe,0x4,0x0};
uint8_t battlowest[8] = {0xe,0x1f,0x11,0x11,0x11,0x11,0x11,0x1f};
uint8_t battlower[8] = {0xe,0x1f,0x11,0x11,0x11,0x11,0x1f,0x1f};
uint8_t battlow[8] = {0xe,0x1f,0x11,0x11,0x11,0x1f,0x1f,0x1f};
uint8_t battmid[8] = {0xe,0x1f,0x11,0x11,0x1f,0x1f,0x1f,0x1f};
uint8_t batthigh[8] = {0xe,0x1f,0x11,0x1f,0x1f,0x1f,0x1f,0x1f};
uint8_t batthighest[8] = {0xe,0x1f,0x1f,0x1f,0x1f,0x1f,0x1f,0x1f};



int val = 0;
int abruf = 0;
long licht = 0;
int lichtan = 0;
int letztstunde = 0;
int letztminute = 0;
int battery = 0;



void setup()
{
  lcd.init();                      // initialize the lcd 
  pinMode(6, INPUT);
  //digitalWrite(6, HIGH);    //Button
  pinMode(13, OUTPUT);
  lcd.noBacklight();
  lcd.createChar(1, heart);
  lcd.createChar(2, battlowest);
  lcd.createChar(3, battlower);
  lcd.createChar(4, battlow);
  lcd.createChar(5, battmid);
  lcd.createChar(6, batthigh);
  lcd.createChar(7, batthighest);
  lcd.home();
  lcd.write(1);  
  tmElements_t tm;  //Uhrzeit
  RTC.read(tm);
  lcd.setCursor(0,3);
  if (tm.Hour < 10){lcd.print("0");};
  lcd.print(tm.Hour);
  letztstunde = tm.Hour;
  lcd.print(":");
  if (tm.Minute < 10){lcd.print("0");};
  lcd.print(tm.Minute);
  letztminute = tm.Minute;

}

void loop()
{

  abruf = abruf + 1;

 
  
  if (abruf > 5000){
    tmElements_t tm;
    RTC.read(tm);     //Zeit
    if (letztstunde == tm.Hour){}
      else
       {
        lcd.setCursor(0,3);
        if (tm.Hour < 10){lcd.print("0");};
        lcd.print(tm.Hour);
        letztstunde = tm.Hour;
        }
     if (letztminute == tm.Minute){}
      else
       {
        lcd.setCursor(3,3);
        if (tm.Minute < 10){lcd.print("0");};
        lcd.print(tm.Minute);
        letztminute = tm.Minute;
        }   
    abruf = 0;
    }
    val = digitalRead(6);
  if (val == 0){        //Button
    lcd.backlight();
   //digitalWrite(13,1);
    lichtan = 1;
    licht = 0;
    }
  //val = digitalRead(6);
  if (lichtan = 1);{
    licht = licht +1;
    }
  if (licht > 320000){
    licht = 0;
    lichtan = 0;
    lcd.noBacklight();
    }

}
So funktioniert der Code und die Hintergrundbeleuchtung geht nach einiger Zeit wieder aus.

Code: Alles auswählen

#include <DS1307RTC.h>
#include <Wire.h> 
#include <LiquidCrystal_I2C.h>
#include <Time.h>

LiquidCrystal_I2C lcd(0x27,20,4);  // set the LCD address to 0x27 for a 20 chars and 4 line display
uint8_t heart[8] = {0x0,0xa,0x1f,0x1f,0xe,0x4,0x0};
uint8_t battlowest[8] = {0xe,0x1f,0x11,0x11,0x11,0x11,0x11,0x1f};
uint8_t battlower[8] = {0xe,0x1f,0x11,0x11,0x11,0x11,0x1f,0x1f};
uint8_t battlow[8] = {0xe,0x1f,0x11,0x11,0x11,0x1f,0x1f,0x1f};
uint8_t battmid[8] = {0xe,0x1f,0x11,0x11,0x1f,0x1f,0x1f,0x1f};
uint8_t batthigh[8] = {0xe,0x1f,0x11,0x1f,0x1f,0x1f,0x1f,0x1f};
uint8_t batthighest[8] = {0xe,0x1f,0x1f,0x1f,0x1f,0x1f,0x1f,0x1f};



int val = 0;
int abruf = 0;
long licht = 0;
int lichtan = 0;
int letztstunde = 0;
int letztminute = 0;
int battery = 0;



void setup()
{
  lcd.init();                      // initialize the lcd 
  pinMode(6, INPUT);
  //digitalWrite(6, HIGH);    //Button
  pinMode(13, OUTPUT);
  lcd.noBacklight();
  lcd.createChar(1, heart);
  lcd.createChar(2, battlowest);
  lcd.createChar(3, battlower);
  lcd.createChar(4, battlow);
  lcd.createChar(5, battmid);
  lcd.createChar(6, batthigh);
  lcd.createChar(7, batthighest);
  lcd.home();
  lcd.write(1);  
  tmElements_t tm;  //Uhrzeit
  RTC.read(tm);
  lcd.setCursor(0,3);
  if (tm.Hour < 10){lcd.print("0");};
  lcd.print(tm.Hour);
  letztstunde = tm.Hour;
  lcd.print(":");
  if (tm.Minute < 10){lcd.print("0");};
  lcd.print(tm.Minute);
  letztminute = tm.Minute;

}

void loop()
{
 battery = analogRead(A0);    //DAT HIER
  
  abruf = abruf + 1;

 
  
  if (abruf > 5000){
    tmElements_t tm;
    RTC.read(tm);     //Zeit
    if (letztstunde == tm.Hour){}
      else
       {
        lcd.setCursor(0,3);
        if (tm.Hour < 10){lcd.print("0");};
        lcd.print(tm.Hour);
        letztstunde = tm.Hour;
        }
     if (letztminute == tm.Minute){}
      else
       {
        lcd.setCursor(3,3);
        if (tm.Minute < 10){lcd.print("0");};
        lcd.print(tm.Minute);
        letztminute = tm.Minute;
        }   
    abruf = 0;
    }
    val = digitalRead(6);
  if (val == 0){        //Button
    lcd.backlight();
   //digitalWrite(13,1);
    lichtan = 1;
    licht = 0;
    }
  //val = digitalRead(6);
  if (lichtan = 1);{
    licht = licht +1;
    }
  if (licht > 320000){
    licht = 0;
    lichtan = 0;
    lcd.noBacklight();
    }

}
Sobald man aber "battery = analogRead(A0);" in den Loop einfügt hängt sich der Arduino auf oder so
Aufjedenfall geht die Hintergrundbeleuchtung nicht wieder aus.

Wo liegt das Problem im Code?

Grüße
Sir_Death
Beiträge: 3446
Registriert: Mo 11. Mai 2015, 22:36
Wohnort: südlich von Wien

Re: Der AVR-/ARDUINO-Faden

Beitrag von Sir_Death »

Hmmm...

Ich hab leider gerade keinen Arduino zur Hand um deinen Source auszuprobieren.
Aber wenn ich bisher nicht alles falsch verstanden habe, braucht "analogRead" relativ lange zur Durchführung (im Gegensatz zu anderen Befehlen)
Hast du einfach schon mal abgewartet? - Einerseits, ob deine Minutenanzeige hochzählt - dann hat er sich nicht aufgehängt, und andrerseits, ob das Backlight nicht doch irgendwann ausgeht.
Oder setz einfach mal den Vergleichswert für deine Backlight-Zeit kleiner.

P.S. Ich bin selber nur ein fürchterlicher Arduino-Programmierer - gibt hier sicher einige, die das viel besser können. Aber für dein Backlight Google mal nach "non blocking delay" http://playground.arduino.cc/Code/AvoidDelay - dann hast du eine fixe Verzögerung, die nicht von Programmlaufzeiten abhängig ist.

Für die RTC würde ich dir eher die DS3231 empfehlen als die DS1307 - da kannst du gleich ohne RTC arbeiten.
Wie man den Arduino leichter mit der RTC Synchron bekommt - schau dir die hier verlinkte Library an (letzte 2 Absätze des Textes) https://arduino-hannover.de/2015/02/25/ ... s-arduino/

Ich hoffe, die Tipps helfen dir.

lg.
Sir_Death
Myvesdin
Beiträge: 45
Registriert: Sa 5. Apr 2014, 10:20

Re: Der AVR-/ARDUINO-Faden

Beitrag von Myvesdin »

Moin,

Die Zeitanzeige läuft wie normal weiter.
Auch die gemessene Spannung ändert sich und stimmt überein.

Nur das erneute Ausschalten der Displaybeleuchtung geht nicht.

Code: Alles auswählen

if (val == 0){        //Button
    lcd.backlight();
   digitalWrite(13,1);
    lichtan = 1;
    licht = 0;
    }
Und auch die LED leuchtet in diesem Fall dauerhaft, obwohl der PIN auf 5V liegt.

Grüße
andreas6
Beiträge: 4157
Registriert: So 11. Aug 2013, 15:09

Re: Der AVR-/ARDUINO-Faden

Beitrag von andreas6 »

Da fällt mir ein Fehler ins Auge:

Code: Alles auswählen

if (lichtan = 1);{
Ist der Klassiker, dort findet auch eine ungewollte Zuweisung statt. Nimm "==", das geht besser.

MfG. Andreas
Sir_Death
Beiträge: 3446
Registriert: Mo 11. Mai 2015, 22:36
Wohnort: südlich von Wien

Re: Der AVR-/ARDUINO-Faden

Beitrag von Sir_Death »

andreas6 hat geschrieben:Da fällt mir ein Fehler ins Auge:

Code: Alles auswählen

if (lichtan = 1);{
Ist der Klassiker, dort findet auch eine ungewollte Zuweisung statt. Nimm "==", das geht besser.

MfG. Andreas
Uuupps habe ich auch überlesen - passierte mir auch immer wieder. :lol:
Da gibt es einen super Tipp von Meister Zabex:

Code: Alles auswählen

if (1==lichtan) 
schreibst du dort dann nur

Code: Alles auswählen

if (1=lichtan) 
wirft er dir automatisch einen Fehler aus! - geht natürlich nur mit Konstanten - nicht wenn du 2 Variablen vergleichst.
Benutzeravatar
ferdimh
Beiträge: 9420
Registriert: Fr 16. Aug 2013, 15:19

Re: Der AVR-/ARDUINO-Faden

Beitrag von ferdimh »

Das auf das If folgende Semikolon macht die Funktionalität auch nicht besser.
wenn die Bedingung zutrifft, rennt es gleich in ein Semikolon.
Danach kommt ein Block, der auf jeden Fall ausgeführt wird...
Benutzeravatar
Bauteiltöter
Beiträge: 254
Registriert: So 11. Aug 2013, 17:37

Re: Der AVR-/ARDUINO-Faden

Beitrag von Bauteiltöter »

Sir_Death hat geschrieben: Da gibt es einen super Tipp von Meister Zabex: [...]wirft er dir automatisch einen Fehler aus! - geht natürlich nur mit Konstanten - nicht wenn du 2 Variablen vergleichst.
Oder aber, man überlässt dem Compiler das Flüchtigkeitsfehlersuchen und hört auch auf ihn.
Mit -Wall liefert der nämlich schön brav:

Code: Alles auswählen

gcc test.c -Wall test.c: In function ‘main’:
test.c:5:2: warning: suggest parentheses around assignment used as truth value [-Wparentheses]
  if(fehler=1);{
  ^
Mit -Wextra gibt es dann auch gleich noch:

Code: Alles auswählen

test.c:5:14: warning: suggest braces around empty body in an ‘if’ statement [-Wempty-body]
  if(fehler=1);{
              ^
Beide Fehler lassen sich so ganz einfach vom Compiler finden. -Wall und -Wextra sollte man immer gesetzt haben. Scheinbar macht das die Arduino-Umgebung nicht von alleine... aber man kann das bestimmt nachholen.
Sir_Death
Beiträge: 3446
Registriert: Mo 11. Mai 2015, 22:36
Wohnort: südlich von Wien

Re: Der AVR-/ARDUINO-Faden

Beitrag von Sir_Death »

Das wäre super, wenn das ginge! - Irgendwer einen Tipp wie?
Benutzeravatar
Bauteiltöter
Beiträge: 254
Registriert: So 11. Aug 2013, 17:37

Re: Der AVR-/ARDUINO-Faden

Beitrag von Bauteiltöter »

Google nach "arduino IDE compiler switch" bringt diesen Post bei Stackoverflow hervor: http://stackoverflow.com/questions/2803 ... piler-flag

Darin heißt es, dass zumindest bei 1.5.x die Datei ".\Arduino\hardware\arduino\avr\platform.txt" die Kommandozeilenparameter definiert.

Außerdem steht da, welches Format eine "platform.local.txt" im selben Verzeichniss haben muss um extra Compiler-Schalter anzugeben. So wie ich das sehe, muss -Wall -Wextra auf jeden Fall bei compiler.c.extra_flags und compiler.cpp.extra_flags ergänzt werden. Ansonsten kennt sich vielleicht hier jemand besser mit der Arduino-IDE aus?
Myvesdin
Beiträge: 45
Registriert: Sa 5. Apr 2014, 10:20

Re: Der AVR-/ARDUINO-Faden

Beitrag von Myvesdin »

Danke an alle helfenden
So klappst jetzt perfekt

Code: Alles auswählen

{
  
  
  abruf = abruf + 1;

 
  
  if (abruf > 5000){
    battery = analogRead(A0);
    tmElements_t tm;
    RTC.read(tm);     //Zeit
    if (letztstunde == tm.Hour){}
      else
       {
        lcd.setCursor(0,3);
        if (tm.Hour < 10){lcd.print("0");};
        lcd.print(tm.Hour);
        letztstunde = tm.Hour;
        }
     if (letztminute == tm.Minute){}
      else
       {
        lcd.setCursor(3,3);
        if (tm.Minute < 10){lcd.print("0");};
        lcd.print(tm.Minute);
        letztminute = tm.Minute;
        }   
    abruf = 0;
    }
    val = digitalRead(6);
  if (val == 0){        //Button
    lcd.backlight();
   //digitalWrite(13,1);
    lichtan = 1;
    licht = 0;
    }
  //val = digitalRead(6);
  if (lichtan == 1){
    licht = licht +1;
    }
  if (licht > 230000){
    licht = 0;
    lichtan = 0;
    lcd.noBacklight();
    }
}

Grüße
Sir_Death
Beiträge: 3446
Registriert: Mo 11. Mai 2015, 22:36
Wohnort: südlich von Wien

Re: Der AVR-/ARDUINO-Faden

Beitrag von Sir_Death »

Bauteiltöter hat geschrieben:Google nach "arduino IDE compiler switch" bringt diesen Post bei Stackoverflow hervor: http://stackoverflow.com/questions/2803 ... piler-flag

Darin heißt es, dass zumindest bei 1.5.x die Datei ".\Arduino\hardware\arduino\avr\platform.txt" die Kommandozeilenparameter definiert.

Außerdem steht da, welches Format eine "platform.local.txt" im selben Verzeichniss haben muss um extra Compiler-Schalter anzugeben. So wie ich das sehe, muss -Wall -Wextra auf jeden Fall bei compiler.c.extra_flags und compiler.cpp.extra_flags ergänzt werden. Ansonsten kennt sich vielleicht hier jemand besser mit der Arduino-IDE aus?
Ich habe mich heute mit der Plattform.local.txt gespielt - leider ohne irgendein Ergebnis.. mal schauen, ob ich mich nochmal mit der platform.txt spiele...
Benutzeravatar
zauberkopf
Beiträge: 9524
Registriert: So 11. Aug 2013, 15:33
Wohnort: gefährliches Halbwissen

Re: Der AVR-/ARDUINO-Faden

Beitrag von zauberkopf »

Übrigens, Franz, der Sondengott, hat was beim AVR festgestellt :
Wenn man den AVR als Taktquelle mißbraucht, ist der Takt nicht frei von Jitter, sondern ist mit einem geringen behaftet, je nach dem was die CPU gerade macht.
Das ist ihm aufgefallen, als er versuchte einen RDA1846 mit dem Takt vom AVR zu versorgen.
Der nachgemessener Jitter ist zwar extrem klein, aber reicht aus, um den RDA aus dem Konzept zu bringen. Dieser benötigt nämlich eine extrem saubere Taktquelle.
Benutzeravatar
Geistesblitz
Beiträge: 1934
Registriert: Di 5. Nov 2013, 17:53
Wohnort: Dresden

Re: Der AVR-/ARDUINO-Faden

Beitrag von Geistesblitz »

So, ich hab da mal etwas, wo ich ein wenig Hilfe brauch:

Ich bin schon seit längerem dabei, nach und nach eine Elektronik für eigene DC-Servos zu basteln. Einen funktionsfähigen Regler hab ich dafür auch schon aufgebaut, jetzt befasse ich mich allerdings etwas mehr mit dem Thema serielle Kommunikation, wo bei mir sicherlich auch noch etwas Nachholbedarf besteht.

Momentan ist es so, dass der Controller über SPI mit einem Magnetsensor kommuniziert (dieser schickt an sich nur die rohen Positionsdaten zurück, 14 Bit Auflösung hat das Teil, die übrigen 2 Bit enthalten auch Informationen, die hier aber nicht weiter wichtig sind) und über einen USB-UART-Wandler mit dem PC. Dort hab ich auch ein relativ simples Programm in LabView (mag ich eigentlich nicht, war für die Aufgabe aber das Einfachste) zusammengehackt, welches die Sollwerte an den Controller schickt, Istwerte empfängt und beides schön in einem kontinuierlich laufenden Diagramm anzeigt.

Die Kommunikation soll jetzt aber ausgebaut werden, sodass ich außer den Sollpositionen auch Betriebsmodi und Reglerparameter einstellen und auslesen kann, außerdem sollen mehrere Teilnehmer an einem Bus hängen können. Könnte man das auch noch mit UART machen und sich ein System zur Adressierung ausdenken oder ist es sinnvoll auf I²C zu wechseln? Das hätte auch den Vorteil, dass man eventuell einen Master mit dem PC über UART verbinden könnte und der dann über I²C mit den Reglermodulen redet.

Vielleicht bilde ich mir aber auch nur ein, dass das sinnvoll wäre. Kann mir da vielleicht einer helfen? Ich merk auch gerade, dass ich bei UART auch gar nicht wüsste, wie man bei mehreren Teilnehmern die Datenleitungen verdrahten müsste, damit es zu keinen Kollisionen kommt, bei welchen die Controller sich gegenseitig räuchern.
Zuletzt geändert von Geistesblitz am So 24. Jul 2016, 23:55, insgesamt 1-mal geändert.
Benutzeravatar
Fritzler
Beiträge: 12600
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Adlershof/Technologiepark
Kontaktdaten:

Re: Der AVR-/ARDUINO-Faden

Beitrag von Fritzler »

Schreib doch bitte das nächste mal mit Absätzen...
Da kricht man ja Augenkrebs!

AVRs haben nen 9Bit UART und das 9. Bit kann für MUltimaster und Adressierungen am UART genutzt werden -> mal das DB eines atrmega durchlesen.
Benutzeravatar
Geistesblitz
Beiträge: 1934
Registriert: Di 5. Nov 2013, 17:53
Wohnort: Dresden

Re: Der AVR-/ARDUINO-Faden

Beitrag von Geistesblitz »

So besser?

Ich hab mir bisher noch kein Datenblatt eines AVR komplett durchgelesen, dafür ist mir das einfach zu viel. Ich werd aber mal nach der Stelle gucken, die du ansprichst, auch wenn ich mir noch nciht so recht vorstellen kann, wie das funktionieren soll.

Jedenfalls bin ich noch weiter dabei, mich zu informieren, und I²C erscheint mir da doch sinnvoller. Hab hier auch eine Quelle gefunden, nach welcher es wohl ganz gut gehen soll, AVRs als Slave zu konfigurieren. Muss ich beizeiten mal ausprobieren.
Antworten