Der AVR-/ARDUINO-Faden
Moderatoren: Heaterman, Finger, Sven, TDI, Marsupilami72, duese
Re: Der AVR-/ARDUINO-Faden
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.
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.
-
- Beiträge: 1506
- Registriert: Di 13. Aug 2013, 19:10
- Wohnort: Niedersachsen Süd-Ost
Re: Der AVR-/ARDUINO-Faden
Ich bin Windowsbenutzer und sehe keinen Grund, mich dafür zu schämen oder rechtfertigen zu müssen, Punkt.Hightech hat geschrieben:Keine Frage! Der Adruino ist DAS Einsteigerteil für Nichtlötkolbenhalterwindowsnutzer für einen leichten Einstieg.
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?
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.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.
Danke für den Hinweis.phettsack hat geschrieben:DIESER Faden nennt sich ja schliesslich auch "Arduino".
Dem schließe ich mich an, sein Beispiel mit dem Dachlattentisch trifft den Kern.phettsack hat geschrieben:Zabex spricht mir aus der Seele.
Danke, so etwa habe ich das auch formuliert, ist aber scheinbar nicht verstanden worden.phettsack hat geschrieben:Jetzt, Jahre später bin ich auch ergebnisorientiert.
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.
Amen. Und mit diesem, Deinem Schlußwort, beenden wir den Glaubenskrieg Arduino gegen Rohprozessor.phettsack hat geschrieben:Einfach MACHEN und sich freuen das es geht.
-
- Beiträge: 3261
- Registriert: Mo 12. Aug 2013, 19:47
Re: Der AVR-/ARDUINO-Faden
@ 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?
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?
Re: Der AVR-/ARDUINO-Faden
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€)
Ein LM324 als Dreiecksgenerator wäre eine Alternative. Ein externer 16Bit ADC auch (z. B. MCP3426, Reichelt 2,67€)
-
- Beiträge: 3261
- Registriert: Mo 12. Aug 2013, 19:47
Re: Der AVR-/ARDUINO-Faden
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?
Re: Der AVR-/ARDUINO-Faden
Bei Elektor gibt es das Buch hier.....bis zum 4.4.2016
-
- Beiträge: 3261
- Registriert: Mo 12. Aug 2013, 19:47
Re: Der AVR-/ARDUINO-Faden
Hm, ich bekomme Gutscheincode ist ungültig". Muß man das über ein Schmierphone machen?
- Münsterländer
- Beiträge: 329
- Registriert: Fr 11. Okt 2013, 14:55
- Wohnort: Borken (bei Holland)
Re: Der AVR-/ARDUINO-Faden
Bei mir läuft der Download vom PC problemlos. Danke für den Tipp!
-
- Beiträge: 1653
- Registriert: So 11. Aug 2013, 19:53
- Wohnort: bei Frankfurt/Main
Re: Der AVR-/ARDUINO-Faden
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
Was auch lustig ist: das Teil unbemerkt einstöpseln, und in zufälligen Abständen ALT+F4 senden
Was auch lustig ist: das Teil unbemerkt einstöpseln, und in zufälligen Abständen ALT+F4 senden
- Fritzler
- Beiträge: 12600
- Registriert: So 11. Aug 2013, 19:42
- Wohnort: D:/Berlin/Adlershof/Technologiepark
- Kontaktdaten:
Re: Der AVR-/ARDUINO-Faden
Gibt auch nen V-USB Bootloader, der sich als USBasp meldet.
Der ist dann aber natürlich etwas größer vom Code her.
Der ist dann aber natürlich etwas größer vom Code her.
Re: Der AVR-/ARDUINO-Faden
reutron hat geschrieben:Bei Elektor gibt es das Buch hier.....bis zum 4.4.2016
Cool! - Danke für den Tipp - schon gesichert.
-
- Beiträge: 3261
- Registriert: Mo 12. Aug 2013, 19:47
Re: Der AVR-/ARDUINO-Faden
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.
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.
Re: Der AVR-/ARDUINO-Faden
Kannst du mal nen Schaltplan skizzieren und hier einstellen? Ich komme da nicht ganz mit, was du versucht hast.
- Fritzler
- Beiträge: 12600
- Registriert: So 11. Aug 2013, 19:42
- Wohnort: D:/Berlin/Adlershof/Technologiepark
- Kontaktdaten:
Re: Der AVR-/ARDUINO-Faden
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
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
Re: Der AVR-/ARDUINO-Faden
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.
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.
-
- Beiträge: 3261
- Registriert: Mo 12. Aug 2013, 19:47
Re: Der AVR-/ARDUINO-Faden
Danke für die Antworten! Das, was geschwungen hat, ist dieses Gebilde:
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? 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?
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? 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?
- Fritzler
- Beiträge: 12600
- Registriert: So 11. Aug 2013, 19:42
- Wohnort: D:/Berlin/Adlershof/Technologiepark
- Kontaktdaten:
Re: Der AVR-/ARDUINO-Faden
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
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.
Zudem bräuchteste 44kHz Samplerate und nicht 20KHz, also fast 7GHz
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.
Hä?Wahrscheinlich ist der Abzweig direkt am OP falsch und gehört eigentlich aber hinter die Transe
Re: Der AVR-/ARDUINO-Faden
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.
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.
-
- Beiträge: 3261
- Registriert: Mo 12. Aug 2013, 19:47
Re: Der AVR-/ARDUINO-Faden
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: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.
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.Fritzler hat geschrieben:Hä?Wahrscheinlich ist der Abzweig direkt am OP falsch und gehört eigentlich aber hinter die Transe
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: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).
Gut zu wissen, ich fühlte mich schon etwas schuldig.ferdimh hat geschrieben:Ein LM324 macht bei unbeschalteten Eingängen keinen Blödsinn.
Oha. Gibt es Delta-Sigma-Modulations-DAs auch einzeln? Das sollte dann ja billiger sein als Hochgeschwindigkeits-DAs.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.
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?
- Marsupilami72
- Beiträge: 2874
- Registriert: Mo 4. Nov 2013, 23:48
- Wohnort: mittendrin
Re: Der AVR-/ARDUINO-Faden
Ich hab die Aktion voll verpennt, kann mir einer das Pdf zuschicken (ganzliebguck ?reutron hat geschrieben:Bei Elektor gibt es das Buch hier.....bis zum 4.4.2016
-
- Beiträge: 71
- Registriert: So 11. Aug 2013, 15:47
Re: Der AVR-/ARDUINO-Faden
nö, die sind mit einem Wasserzeichen versehen. Das fällt auf, wenn ich das jemanden zusende.
Zuckermais
Zuckermais
- Marsupilami72
- Beiträge: 2874
- Registriert: Mo 4. Nov 2013, 23:48
- Wohnort: mittendrin
Re: Der AVR-/ARDUINO-Faden
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.
Ich habe das PDF aber schon von einem anderen User bekommen - das Thema hat sich also erledigt.
Re: Der AVR-/ARDUINO-Faden
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.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?
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.
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.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.
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.Das mit der analogen PWM-Erzeugung blicke ich leider nicht; wenn das Signal schon analog ist, braucht man doch den Wandler nicht mehr...?
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.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?
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.
-
- Beiträge: 3261
- Registriert: Mo 12. Aug 2013, 19:47
Re: Der AVR-/ARDUINO-Faden
Aha, OK. Ich habe die Bildchen vom Frequenzgang zwar verglichen, aber diesen Unterschied nicht gesehen, muß ich wohl nochmal gucken!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.
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: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.
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: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.
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: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.
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?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.
Ist schon etwas frustrierend, wenn man tagelang über Filter liest und dann trotzdem die einfachsten Dinge nachfragen muß.
Re: Der AVR-/ARDUINO-Faden
Nein.´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?
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:
-
- Beiträge: 3261
- Registriert: Mo 12. Aug 2013, 19:47
Re: Der AVR-/ARDUINO-Faden
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.
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.
-
- Beiträge: 240
- Registriert: Mo 16. Feb 2015, 13:50
Re: Der AVR-/ARDUINO-Faden
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.
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.
-
- Beiträge: 173
- Registriert: Fr 1. Jan 2016, 20:43
- Wohnort: Freie Feldlage (Ja, da wo das Treffen ist))
Re: Der AVR-/ARDUINO-Faden
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.
Wobei [DCF77] die Insanz der Library ist (Die Variable, die du mit .getTime() benutzt).
Grüße Kenakapheus
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;
Grüße Kenakapheus
-
- Beiträge: 240
- Registriert: Mo 16. Feb 2015, 13:50
Re: Der AVR-/ARDUINO-Faden
Hallo
Erst mal Danke für die Antwort.
komme Heute leder nicht dazu das zu Probieren.
melde mich wenn ich es probiert habe
Erst mal Danke für die Antwort.
komme Heute leder nicht dazu das zu Probieren.
melde mich wenn ich es probiert habe
-
- Beiträge: 3261
- Registriert: Mo 12. Aug 2013, 19:47
Re: Der AVR-/ARDUINO-Faden
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...
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...
-
- Beiträge: 173
- Registriert: Fr 1. Jan 2016, 20:43
- Wohnort: Freie Feldlage (Ja, da wo das Treffen ist))
Re: Der AVR-/ARDUINO-Faden
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
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
Re: Der AVR-/ARDUINO-Faden
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ß.
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ß.
-
- Beiträge: 3261
- Registriert: Mo 12. Aug 2013, 19:47
Re: Der AVR-/ARDUINO-Faden
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.
Re: Der AVR-/ARDUINO-Faden
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
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
-
- Beiträge: 240
- Registriert: Mo 16. Feb 2015, 13:50
Re: Der AVR-/ARDUINO-Faden
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.
Erstmal Danke für die Antworten
Leider kann ich die nächten Wochen an dem Projekt nicht weitermachen.
Die Gesundheit fordert andere Prioritäten.
Re: Der AVR-/ARDUINO-Faden
Moin moin,
ich bin gerade einwenig am verzweifeln.
So funktioniert der Code und die Hintergrundbeleuchtung geht nach einiger Zeit wieder aus.
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
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();
}
}
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();
}
}
Aufjedenfall geht die Hintergrundbeleuchtung nicht wieder aus.
Wo liegt das Problem im Code?
Grüße
Re: Der AVR-/ARDUINO-Faden
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
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
Re: Der AVR-/ARDUINO-Faden
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.
Und auch die LED leuchtet in diesem Fall dauerhaft, obwohl der PIN auf 5V liegt.
Grüße
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;
}
Grüße
Re: Der AVR-/ARDUINO-Faden
Da fällt mir ein Fehler ins Auge:
Ist der Klassiker, dort findet auch eine ungewollte Zuweisung statt. Nimm "==", das geht besser.
MfG. Andreas
Code: Alles auswählen
if (lichtan = 1);{
MfG. Andreas
Re: Der AVR-/ARDUINO-Faden
Uuupps habe ich auch überlesen - passierte mir auch immer wieder.andreas6 hat geschrieben:Da fällt mir ein Fehler ins Auge:
Ist der Klassiker, dort findet auch eine ungewollte Zuweisung statt. Nimm "==", das geht besser.Code: Alles auswählen
if (lichtan = 1);{
MfG. Andreas
Da gibt es einen super Tipp von Meister Zabex:
Code: Alles auswählen
if (1==lichtan)
Code: Alles auswählen
if (1=lichtan)
Re: Der AVR-/ARDUINO-Faden
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...
wenn die Bedingung zutrifft, rennt es gleich in ein Semikolon.
Danach kommt ein Block, der auf jeden Fall ausgeführt wird...
- Bauteiltöter
- Beiträge: 254
- Registriert: So 11. Aug 2013, 17:37
Re: Der AVR-/ARDUINO-Faden
Oder aber, man überlässt dem Compiler das Flüchtigkeitsfehlersuchen und hört auch auf ihn.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.
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);{
^
Code: Alles auswählen
test.c:5:14: warning: suggest braces around empty body in an ‘if’ statement [-Wempty-body]
if(fehler=1);{
^
Re: Der AVR-/ARDUINO-Faden
Das wäre super, wenn das ginge! - Irgendwer einen Tipp wie?
- Bauteiltöter
- Beiträge: 254
- Registriert: So 11. Aug 2013, 17:37
Re: Der AVR-/ARDUINO-Faden
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?
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?
Re: Der AVR-/ARDUINO-Faden
Danke an alle helfenden
So klappst jetzt perfekt
Grüße
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
Re: Der AVR-/ARDUINO-Faden
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...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?
- zauberkopf
- Beiträge: 9524
- Registriert: So 11. Aug 2013, 15:33
- Wohnort: gefährliches Halbwissen
Re: Der AVR-/ARDUINO-Faden
Ü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.
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.
- Geistesblitz
- Beiträge: 1934
- Registriert: Di 5. Nov 2013, 17:53
- Wohnort: Dresden
Re: Der AVR-/ARDUINO-Faden
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.
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.
- Fritzler
- Beiträge: 12600
- Registriert: So 11. Aug 2013, 19:42
- Wohnort: D:/Berlin/Adlershof/Technologiepark
- Kontaktdaten:
Re: Der AVR-/ARDUINO-Faden
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.
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.
- Geistesblitz
- Beiträge: 1934
- Registriert: Di 5. Nov 2013, 17:53
- Wohnort: Dresden
Re: Der AVR-/ARDUINO-Faden
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.
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.