Kellerassel_1
Mitglied
Diesen Code benutze ich.
Anleitung Arduino mit DCF77-Modul und RTC Echtzeituhr DS3231
Vielen Dank für den Tipp
Anleitung - Arduino mit GPS-Modul, Zeitabgleich
Arduinouhr mit einem GPS-Modul abgleichen. In diesem Thema wird der Aufbau und die Programmierung beschrieben.
www.rc-modellbau-portal.de
norju
Mitglied
Moin BAXL, irgendwann soll ein erfolgreiches Experiment auch einmal in die reale Nutzungswelt überführt werden. Dafür möchte einen im Handel erhältlichen ATmega328P mit Arduino Bootloader einsetzen. Nun ist mir aufgefallen, dass die Pin-outs vom ATmega328P im Arduino-Uno-Board und dem im Handel nicht direkt vergleichbar sind. Die Meisten kann ich logisch übersetzen. Bei Pin 14 bis Pin 19 erschließt sich mir jedoch weder logisch noch aus der Interpretation ihrer Beschreibung heraus, ob deren Beschaltung vom Arduino-Board 1:1 übertragbar ist. Im Arduino-Board sind z. B. nur bestimmte Pins für die PWM-Nutzung geeignet. Im Datenblatt habe ich keine genaue Angabe darüber gefunden ausser, dass für externe Merkmale 6 PWM-Kanäle zur Verfügung stehen. Kein Hinweis darüber, um welche Pins es sich tatsächlich handelt. Weißt Du mehr?
Meinst Du den hier:
www.researchgate.net
wolles-elektronikkiste.de
Fig. 2 : Pins of microcontroller AT mega328
Download scientific diagram | Pins of microcontroller AT mega328 from publication: SMART GRID INTEGRATION WITH REVERSE SUPPLYPROVIDE WITH NATURAL ENERGYRESOURCE UTILIZATION | The increasing complexity of the existing power grid due to rapid population growth, development in technology...
www.researchgate.net
ATmega328P standalone betreiben • Wolles Elektronikkiste
Ich zeige euch verschiedene Wege, wie ihr das Herzstück des Arduino UNO, den ATmega328P, "standalone" programmiert. Das spart Platz, Kosten und Akku.
wolles-elektronikkiste.de
Zuletzt bearbeitet:
norju
Mitglied
Ja, das entspricht dem Ergebnis meines Vergleiches. Ich hatte mir das Datenblatt des Atmega 328P bei Reichelt heruntergeladen und mit dem Arduino-Board abgeglichen. Die Gegenüberstellung aus Wolles Elektronikkiste gibt das sehr gut wieder. Die PWM-fähigen Pins sind leider auch hier nicht erkennbar. Es kann aber auch sein, dass ich die in Klammerm gesetzten Pin-Beschreibungen nicht richtig deute.
Hmm mehr kann ich jetzt ad hoc auch nicht sagen. Probiere es einfach aus.
norju
Mitglied
Mir scheint, doch noch eine Erklärung gefunden zu haben. Nach Abgleich aller Pin-Erläuterungen des Datenblattes sind offensichtlich alle Pins, die das Kürzel "OC...." enthalten (z. B. OC2B, OC0B, OC2A usw.), für eine PWM-Nutzung geeignet. Das würde sich mit dem Arduino-Zeichen "~" der Stiftleisten decken.
Die Erklärung ist top. Ich habe daraufhin nach OC1B gesucht und bin auf folgendes Bild gestoßen. Da sind die Tildezeichen zu sehen.
Zuletzt bearbeitet:
Davon lebt die Community - sich gegenseitig helfen. Danke dass Du Dein Wissen geteilt hast.Wieder etwas klargestellt
BastlWastl
Mitglied
Moin liebe Leute.
Ich habe über Weihnachten mal mit Arduino Nano und dem DCF77-Modul von Reichelt zusammen mit einem Steckbrett gespielt, um so einen ersten Entwurf für eine mögliche Zeitbasis für eine WSPR-Bake zu erzeugen. Dabei ist mir folgendes aufgefallen:
a) das DCF77-Modul muss ganz weg von dem Steckbrett, ansonsten gibt es kein gültiges Signal aufgrund von Störungen durch Arduino selber und anderer Baugruppen. Ich habe deshalb dieses Modul auf die Fensterbank platziert und mittels ehemaliger Telefonleitung (ca. 2m, 4-adrig) an das Steckbrett angeschlossen. Ergebnis: sauberer TTL-Pegel sichtbar auf dem Scope und der Interrupt auf dem Arduino wird auch sicher flankengesteuert ausgelöst.
b) das DCF77-Modul wird bei mir ohne zusätzliche Signalaufbereitung, wie etwa Impulsformer mittels Komparator, MOSFET, etc. oder so, betrieben
c) ich habe bei mir die eingangs hier aufgeführte SW (leicht angepaßt) genommen und verwendet; die Flankentriggerung hört hier auf steigende Flanken, d.h. im Code ist "true" eingestellt. Leider gab es hier keine Synchronisation, auch nach dem Warten von mehr als einer halben Stunde und anderen möglichen Veränderungen im Code.
d) die Interrupt-Funktionalität hatte ich vorher mittels einer kleinen ISR überprüft und die LED auf dem Arduino damit aufleuchten lassen. Hierbei hatte ich die von Arduino aufgegebene ISR hier einfach verwendet und es blinkete nach kurzer Zeit von 10-20sec lustig auf dem Arduino.
e) in der Library DCF77 (von Thjis Eelenbaas 2012) habe ich mich dann umgesehen und festgestellt, dass die dortige Inititalisierung der Interrupt-Routine etwas veraltet aussah, weshalb ich dann zu Testzwecken einfach den empfohlenen Funktionsaufruf für HW-Interrupts dort eingebaut habe. Ergebnis: die Synchronisation setzt mit dieser Änderung sicher zwischen 2:20Min und 2:40Min ein.
Siehe auch das nachfolgende Code-Schnipsel aus "DCF77.cpp" mit meinen Änderungen:
Falls also jemand noch immer Schwierigkeiten mit dieser HW/SW-Kombination haben sollte, könnte diese Erfahrung vielleicht ein wenig weiterhelfen. Ich drücke in jedem Falle die Daumen.
Schöne Grüße
BastlWastl
P.S. Als nächstes werde ich noch einen NEO-6MV2 (GPS6MV2) mit anhängen, um zusätzlich noch die GPS-Zeit und meinen genauen Standort als weitere Möglichkeit für meine Zeitbasis für meinen WSPR-Bake zu erhalten. Planung: DCF77-Modul und GPS-Modul sollen zukünftig draußen an der Hauswand wetterfest und stabil außerhalb von Störquellen angebracht werden. Ja, es ist 'overkill', aber mir gefällt es so...
Ich habe über Weihnachten mal mit Arduino Nano und dem DCF77-Modul von Reichelt zusammen mit einem Steckbrett gespielt, um so einen ersten Entwurf für eine mögliche Zeitbasis für eine WSPR-Bake zu erzeugen. Dabei ist mir folgendes aufgefallen:
a) das DCF77-Modul muss ganz weg von dem Steckbrett, ansonsten gibt es kein gültiges Signal aufgrund von Störungen durch Arduino selber und anderer Baugruppen. Ich habe deshalb dieses Modul auf die Fensterbank platziert und mittels ehemaliger Telefonleitung (ca. 2m, 4-adrig) an das Steckbrett angeschlossen. Ergebnis: sauberer TTL-Pegel sichtbar auf dem Scope und der Interrupt auf dem Arduino wird auch sicher flankengesteuert ausgelöst.
b) das DCF77-Modul wird bei mir ohne zusätzliche Signalaufbereitung, wie etwa Impulsformer mittels Komparator, MOSFET, etc. oder so, betrieben
c) ich habe bei mir die eingangs hier aufgeführte SW (leicht angepaßt) genommen und verwendet; die Flankentriggerung hört hier auf steigende Flanken, d.h. im Code ist "true" eingestellt. Leider gab es hier keine Synchronisation, auch nach dem Warten von mehr als einer halben Stunde und anderen möglichen Veränderungen im Code.
d) die Interrupt-Funktionalität hatte ich vorher mittels einer kleinen ISR überprüft und die LED auf dem Arduino damit aufleuchten lassen. Hierbei hatte ich die von Arduino aufgegebene ISR hier einfach verwendet und es blinkete nach kurzer Zeit von 10-20sec lustig auf dem Arduino.
e) in der Library DCF77 (von Thjis Eelenbaas 2012) habe ich mich dann umgesehen und festgestellt, dass die dortige Inititalisierung der Interrupt-Routine etwas veraltet aussah, weshalb ich dann zu Testzwecken einfach den empfohlenen Funktionsaufruf für HW-Interrupts dort eingebaut habe. Ergebnis: die Synchronisation setzt mit dieser Änderung sicher zwischen 2:20Min und 2:40Min ein.
Siehe auch das nachfolgende Code-Schnipsel aus "DCF77.cpp" mit meinen Änderungen:
Code:
/**
* Start receiving DCF77 information
*/
void DCF77::Start(void)
{
attachInterrupt(digitalPinToInterrupt(dCF77Pin), int0handler, CHANGE); // neu
//attachInterrupt(dCF77Pin, int0handler, CHANGE); // alt
// geändert gem. Arduino-Vorgabe 2021-12-30
}Schöne Grüße
BastlWastl
P.S. Als nächstes werde ich noch einen NEO-6MV2 (GPS6MV2) mit anhängen, um zusätzlich noch die GPS-Zeit und meinen genauen Standort als weitere Möglichkeit für meine Zeitbasis für meinen WSPR-Bake zu erhalten. Planung: DCF77-Modul und GPS-Modul sollen zukünftig draußen an der Hauswand wetterfest und stabil außerhalb von Störquellen angebracht werden. Ja, es ist 'overkill', aber mir gefällt es so...
Hi @BastlWastl ,
ich habe just meine "alte" Schaltung aus meiner Sammelkiste geklaubt und einfach angeschlossen. Es dauerte keine 5 Minuten, da hatte ich ein Signal. Die Schaltung ist an einem USB-Steckernetzteil angeschlossen und die Antenne liegt knapp 15 cm vom Nano entfernt. Es gibt viele Ursachen, warum man keinen Empfang hat. Die Empfangssituation an sich - ich sitze hier auf einer Anhöhe, wie sauber die Spannungsversorgung ist und möglicherweise die Beschaltung am Nano.
Gute Flanken sind mit entscheidend, bezugnehmend auf b). Ich habe allerdings auch nur einen simplen Widerstand als Zusatzbeschaltung.
Zu c.) das hängt vom Modul ab. Ich habe lange gesucht, bis mir ein Modul bezüglich der Spezifikation passte. Es war auch etwas Glück dabei, dass das Modul aus dem Stand so funktionierte.
Die Sache mit dem Interrupt werde ich aber auch nochmal ausprobieren. Ich möchte die Schaltung noch um einen NRF24l01 erweitern und die Uhrzeit auf einen anderen Nano übertragen. Da habe ich damals aufgehört, weil ich keine Lust mehr hatte und mir die Muße fehlte. Ich finde es aber schön, jetzt ( hoffentlich ) eine zusätzliche Verstärkung mit an Bord zu haben.
Viele melden sich an und lassen ihr Problem lösen und sind dann schnell auch wieder weg. Manchmal haben wir Glück und einer gibt noch zum Besten ob und wie ein Problem bei ihm gelöst wurde und woran es schlußendlich lag. Doch das sind leider nur wenige Ausnahmen.
Gruß
BAXL
Edit:
Die Sache mit dem GPS-Modul habe ich ebenfalls ausprobiert, was allerdings gewisse Nachteile hat. Die Position der Aufstellung ist da leider noch kibbeliger als beim DCF77, weil idR. eine einigermaßen freie Sicht zum Satlliten erforderlich ist. Das hat man beim DCF77-Modul nicht unbedingt. Mir ist auch schon in den Sinn gekommen, die Uhrzeit aus dem Internet zu beziehen, doch soweit bin ich noch nicht, da ist die Software etwas umfangreicher und auf den ersten Blick (für mich) nicht ganz so leicht zu durchschauen ist. Zumindest im Moment noch nicht.
ich habe just meine "alte" Schaltung aus meiner Sammelkiste geklaubt und einfach angeschlossen. Es dauerte keine 5 Minuten, da hatte ich ein Signal. Die Schaltung ist an einem USB-Steckernetzteil angeschlossen und die Antenne liegt knapp 15 cm vom Nano entfernt. Es gibt viele Ursachen, warum man keinen Empfang hat. Die Empfangssituation an sich - ich sitze hier auf einer Anhöhe, wie sauber die Spannungsversorgung ist und möglicherweise die Beschaltung am Nano.
Gute Flanken sind mit entscheidend, bezugnehmend auf b). Ich habe allerdings auch nur einen simplen Widerstand als Zusatzbeschaltung.
Zu c.) das hängt vom Modul ab. Ich habe lange gesucht, bis mir ein Modul bezüglich der Spezifikation passte. Es war auch etwas Glück dabei, dass das Modul aus dem Stand so funktionierte.
Die Sache mit dem Interrupt werde ich aber auch nochmal ausprobieren. Ich möchte die Schaltung noch um einen NRF24l01 erweitern und die Uhrzeit auf einen anderen Nano übertragen. Da habe ich damals aufgehört, weil ich keine Lust mehr hatte und mir die Muße fehlte. Ich finde es aber schön, jetzt ( hoffentlich
) eine zusätzliche Verstärkung mit an Bord zu haben.Viele melden sich an und lassen ihr Problem lösen und sind dann schnell auch wieder weg. Manchmal haben wir Glück und einer gibt noch zum Besten ob und wie ein Problem bei ihm gelöst wurde und woran es schlußendlich lag. Doch das sind leider nur wenige Ausnahmen.
Gruß
BAXL
Edit:
Die Sache mit dem GPS-Modul habe ich ebenfalls ausprobiert, was allerdings gewisse Nachteile hat. Die Position der Aufstellung ist da leider noch kibbeliger als beim DCF77, weil idR. eine einigermaßen freie Sicht zum Satlliten erforderlich ist. Das hat man beim DCF77-Modul nicht unbedingt. Mir ist auch schon in den Sinn gekommen, die Uhrzeit aus dem Internet zu beziehen, doch soweit bin ich noch nicht, da ist die Software etwas umfangreicher und auf den ersten Blick (für mich) nicht ganz so leicht zu durchschauen ist. Zumindest im Moment noch nicht.
Zuletzt bearbeitet:
norju
Mitglied
Moin Arduino-Community.
Zum Thema: Töne, Tonfolgen und Melodien mit dem Arduino hätte ich eine ergänzende Info für Euch. Für mich war es eine neue Erkenntnis.
Bei meinen Experimenten, die DCF77-Funkuhr auch mit einer Weckfunktion auszustatten, war deren ursprünglicher Aufbau zusätzlich mit einem Piezo-Lautsprecher auszustatten.
Hierzu stehen reichlich Beispiel-Sketches unter Verwendung eines Piezo-Lautsprechers zur Verfügung. Alle mir bekannten Versionen gehen von einer direkten Verbindung zwischen einem Ausgabe-Pin und dem Piezo-Lautsprecher aus. So weit so gut.
Kommt jedoch die gleichzeitige Nutzung eines LCD-Displays mit I2C-Ansteuerung ins Spiel, dann tauchen plötzlich unerklärliche Störungen während einer Ton-Ausgabe auf:
Die Lösung: Den Ausgabe-Pin mit einer kleinen Treiberstufe beschalten. Hierfür reicht im ersten Ansatz ein beliebiger NPN-Transistor mit einem 1k-Basiswiederstand und einem 220K-Kollektorwiederstand aus. Siehe da, das LCD-Display bleibt sauber.
Zum Thema: Töne, Tonfolgen und Melodien mit dem Arduino hätte ich eine ergänzende Info für Euch. Für mich war es eine neue Erkenntnis.
Bei meinen Experimenten, die DCF77-Funkuhr auch mit einer Weckfunktion auszustatten, war deren ursprünglicher Aufbau zusätzlich mit einem Piezo-Lautsprecher auszustatten.
Hierzu stehen reichlich Beispiel-Sketches unter Verwendung eines Piezo-Lautsprechers zur Verfügung. Alle mir bekannten Versionen gehen von einer direkten Verbindung zwischen einem Ausgabe-Pin und dem Piezo-Lautsprecher aus. So weit so gut.
Kommt jedoch die gleichzeitige Nutzung eines LCD-Displays mit I2C-Ansteuerung ins Spiel, dann tauchen plötzlich unerklärliche Störungen während einer Ton-Ausgabe auf:
- Einzelne Display-Zeilen flackern, oder
- es tauchen unerwünschte Zahlen/Buchstaben an beliebiger Stelle des Displays auf, oder
- bis hin zur vollständigen Vermüllung aller nicht genutzten Display-Positionen mit seltsamen Hieroglyphen.
Die Lösung: Den Ausgabe-Pin mit einer kleinen Treiberstufe beschalten. Hierfür reicht im ersten Ansatz ein beliebiger NPN-Transistor mit einem 1k-Basiswiederstand und einem 220K-Kollektorwiederstand aus. Siehe da, das LCD-Display bleibt sauber.
norju
Mitglied
Moin Arduino-Community,
ich benötige von Euch Spezialisten einmal einen Denkanstoß und zwar geht es um die Pin-Zuweisung in einem Sketch. Die in der Arduino-Welt existierenden Pin-Nummern werden so, wie sie auf den Stiftleisten aufgeführt sind, auch mit ihrer Pin-Bezeichnung im Sketch zugewiesen. Diese Zuweisungen sind z. B. erforderlich, wenn im Sketch Ein- und Ausgangssignale (Taster, Signaleinspeisung oder LED-Ansteuerungen) verarbeitet werden sollen.
Nun habe ich gelernt, dass es hinsichtlich der Pin-Outs für Arduino und Atmega328 insbesondere bei den Ports „PB“ und „PD“ Abweichungen voneinander gibt (siehe anliegendes Bild).
Als Beispiel hier einmal der Pin-Nr. 14:
Bisher habe ich keine Hinweise/Ratschläge recherchieren können, die ein Aussage darüber treffen, ob:
ich benötige von Euch Spezialisten einmal einen Denkanstoß und zwar geht es um die Pin-Zuweisung in einem Sketch. Die in der Arduino-Welt existierenden Pin-Nummern werden so, wie sie auf den Stiftleisten aufgeführt sind, auch mit ihrer Pin-Bezeichnung im Sketch zugewiesen. Diese Zuweisungen sind z. B. erforderlich, wenn im Sketch Ein- und Ausgangssignale (Taster, Signaleinspeisung oder LED-Ansteuerungen) verarbeitet werden sollen.
Nun habe ich gelernt, dass es hinsichtlich der Pin-Outs für Arduino und Atmega328 insbesondere bei den Ports „PB“ und „PD“ Abweichungen voneinander gibt (siehe anliegendes Bild).
Als Beispiel hier einmal der Pin-Nr. 14:
- Im Arduino nennt er sich „digital 8“
- Im Arduino328 heißt er „PB0“
- Im Arduino nennt er sich „digital 9“
- Im Atmega328 jedoch PB1
Bisher habe ich keine Hinweise/Ratschläge recherchieren können, die ein Aussage darüber treffen, ob:
- Die Pin-Zuweisung von mir anzupassen ist oder
- Der Compiler beim Hochladen eine Übersetzung vornimmt, da in dem Prozess auf einen externen Atmega328 verwiesen wird.
Anhänge
norju
Mitglied
Moin Leute,
hat Niemand einen Tipp für mich? Es mag vielleicht banal erscheinen, doch als Neuling auf diesem Gebiet fühle ich mich doch etwas verunsichert. Ihr wisst, bei einem gravierenden Systemwechsel, wie der von mir geplante Umstieg von der Arduino- auf die Atmega-Welt, ist sowieso mit reichlich Fehlermeldungen zu rechnen. Da möchte ich wenigstens die Differenzen der unterschiedlichen Pin-Bezeichnungen vermeiden. Der Arduino soll dann für weitere Experimente wieder frei werden.
Viele Grüße norju
hat Niemand einen Tipp für mich? Es mag vielleicht banal erscheinen, doch als Neuling auf diesem Gebiet fühle ich mich doch etwas verunsichert. Ihr wisst, bei einem gravierenden Systemwechsel, wie der von mir geplante Umstieg von der Arduino- auf die Atmega-Welt, ist sowieso mit reichlich Fehlermeldungen zu rechnen. Da möchte ich wenigstens die Differenzen der unterschiedlichen Pin-Bezeichnungen vermeiden. Der Arduino soll dann für weitere Experimente wieder frei werden.
Viele Grüße norju
norju
Mitglied
Moin Baxl, die teilweise voneinander abweichenden Pin-Nummern sind mir so weit klar. Darüber hatten wir ja auch sch kommuniziert.
Mir ist jetzt nur nicht so recht klar, ob ich die von den Abweichungen betroffenen Pin-Nummern auch im Sketch entsprechend anpassen muss, bevor der Sketch auf den Atmega übertragen wird. Es könnte ja auch sein, dass der Arduino eine entsprechende Anpassung vornimmt, wenn er als ISP fungiert und ihm dabei signalisiert wird, um welchen Ziel-Typ es sich handelt.
Mir ist jetzt nur nicht so recht klar, ob ich die von den Abweichungen betroffenen Pin-Nummern auch im Sketch entsprechend anpassen muss, bevor der Sketch auf den Atmega übertragen wird. Es könnte ja auch sein, dass der Arduino eine entsprechende Anpassung vornimmt, wenn er als ISP fungiert und ihm dabei signalisiert wird, um welchen Ziel-Typ es sich handelt.