Hallo Forum! Ich bin neu hier und auch erst seit kurzem hat mich das Mü-Fieber gepackt. Ein absolut wertvolles Hobby und wahnsinnig interessant. Als erstes will ich mich aber vorstellen. Mein Name ist Thomas B. aus Österreich und bin beruflich in der Industrieautomatisierung tätig. Seit Dezember 2014 befasse ich mich in meiner Freizeit mit Realisierungen in der Welt der Mikrocontroller. Verwende hauptsächlich ATmegas (zB 168) und programmiere in C auf Atmel Studio 6.2. Mein aktuelles Projekt, eine Störmeldeanzeige via Display 2x16 und Blitzlicht für unsere Wasserversorgungsanlage. Es werden Werte und Störungen erfasst, ausgewertet und angezeigt. Die Anlage funktioniert zu meiner vollen Zufriedenheit, hier im Anhang der Quellcode. Ich muss zugeben, daß diese Art der Programmierung mit den while-Schleifen nicht ideal ist, aber ich habs nicht besser hinbekommen. Nun möchte ich die Anlage mit Anbindung an das Internet, zur Ferndiagnose erweitern. Über das I2C Bus, soll ein 2. ATmega168 mit dem Status beschrieben werden, ausgewertet und über UART in ein UART-LAN Converter weiter gesendet werden. Dazu habe ich einige Ansätze, jedoch keine Lösung. Ich wende mich an euch um dieses Vorhaben zu diskutieren, um zu lernen und letztendlich eine funktionierende Lösung zu haben. Ich möchte mich in den bestehenden und noch kommenden Beiträgen einbringen und helfen wo ich kann. Würde mich sehr freuen, über Resonanz und Menschen die sich meinen quälenden Wissensdurst annehmen. m_168
>Über das I2C Bus, soll ein 2. ATmega168 mit dem >Status beschrieben werden, >ausgewertet und über UART in ein UART-LAN Converter weiter gesendet >werden. Wozu? Nimm lieber einen ATMega mit zwei UARTs. Dann sparst du das I2C Geraffel.
Stimmt. Ich hab mir leider den UART für das Display verbaut. Ich habe HW mäßig keine andere Möglichkeit, ausser alles neu zu machen.. Lieber den komplizierten Weg, da lernt man mehr :-)
Hallo Thomas dein Projekt gefällt mir jetzt schon. Da ich auch mit dem I2C Bus arbeite können wir uns vielleicht ergänzen. Habe hier einiges zu laufen. Kannst ja mal nach "modulares Board" suchen. Dort habe ich schon ein Teil meiner Hardware drin. Es sind auch einige Programme dazu. Habe einiges zum Thema geschrieben. Habe auch einiges zum Multitasking auf dem AT 1284 geschrieben. Bin dabei es mit dem I2C Bus zu verbinden und verschieden Sachen zu nutzen. achim
Achim, schön zu hören (lesen). Den Artikel "modulares Board" habe ich mir kurz angesehen und bin total begeistert. Tolle Aktion! Das Thema "Multitasking" ist eben der springende Punkt... ich werde mir etwas Zeit nehmen, mich damit auseinander zu setzten. Im meinem Fall habe ich mit vorgestellt, den Controller als Slave Transmitter, über Interrupt vom Master anzuspechen. Der Controller sendet 1 Statusbyte (Bitfeldkonfiguration) und 2 Byte geteilter ADC Wert. Am Master IC wird der 2x8 Bit ADC Wert wieder zusammen geführt und das Statusbyte ausgewertet. Danach über UART versendet. Der Vorteil besteht darin, daß nur dann eine Kommunikation stattfindet, wenn auch ein Anfrage dafür vorliegt. m_168
Sieh dir mal diese Seiten an. http://playground.boxtec.ch/doku.php/tutorials/start Dort habe ich die Sachen zum Multitasking beschrieben. Bitte nicht verwchseln mit ROS und so. Mein Ziel dabei ist es, etwas einfaches zu machen, was man nachvollziehen kann. Habe auch die Tasterentprellung von Peter dazu schon fertig und im Einsatz. Dann kannst du dir noch die Seiten von Timo Gruss suchen. Der hat den 1284 als Master und den 2313 als Slave drin. Meine Seite ist noch lange nicht fertig. Habe noch so ca. 20 fertige Hardware Teile. Besonders das schalten von Spannungen (230V)und Triax, Displays (4x20 und Graphik), Drehgeber, Fernbedienung fehlt noch. achim
@Thomas B. (m_168) > code_HM_V1_12.txt (4,75 KB, 6 Downloads) Warum schicktst du uns nicht einfach die originale Datei mit dem Originalen Namen.c. Dann wird die nämlich auch schön angezeigt? >Ich bin neu hier und auch erst seit kurzem hat mich das Mü-Fieber >gepackt. Naja. >Seit Dezember 2014 befasse ich mich in meiner Freizeit mit >Realisierungen in der Welt der >Mikrocontroller. Also ein Greenhorn. >Die Anlage funktioniert zu meiner vollen Zufriedenheit, hier im Anhang >der Quellcode. Die Einrückungen sind defekt. Die sollte man als Leerzeichen vom Editor einfügen lassen, nicht als echte Tabs. >Ich muss zugeben, daß diese Art der Programmierung mit den >while-Schleifen nicht ideal ist, ??? > aber >ich habs nicht besser hinbekommen. Für den Anfang ist das OK. >Ferndiagnose erweitern. Über das I2C Bus, soll ein 2. ATmega168 mit dem >Status beschrieben werden, >ausgewertet und über UART in ein UART-LAN Converter weiter gesendet >werden. Bleib mal bei einem uC. Damit hast du als Anfänger mehr als genug zu tun. Das Auslager einer derartig einfachen Funktion auf einen 2. uC macht mehr Aufwand als es direkt zu erledigen. Man kann auch einen Software-Uart nutzen.
Hallo Falk. Danke für deine Kommentare und Hinweise. Jawohl, Greenhorn :-) (übersetzt: grün hinter den Ohren..) Die Originaldatei habe ich nicht zur Hand, weil auf anderen Computer zuhause... Das TXT File ist aus meiner Dokumentation. Natürlich gibt es wohl viele Möglichkeiten, einige habe ich geprüft und verworfen. Müsste ich das Gerät noch einmal bauen, würde ich einiges anders machen.... Um eine Uart Kommunikation sinnvoll aufzubauen, müsste das Programm auch rund laufen. Aufgrund der "Warte Funktionen", wird der Prozessablauf im Störungsfall aber immer wieder angehalten. Das war auch so beabsichtigt, jedoch für eine direkte Ausgabe über UART nicht sinnvoll. Einen 2. uC zu verwenden hat auch den Grund, um die Anlage mit einigen Funktionen erweitern zu können (zB Durchflusswerte, Temperaturen, FailSave Operationen, Umschaltungen, GSM Modul,...was auch immer...) Ich finde ausserdem, man sollte dem TWI ausreichend Aufmerksamkeit schenken, weil das einem viele Möglichkeiten auftut. Letztendlich geht es nicht immer darum den einfachsten Weg zu gehen, sondern um sich den Herausforderungen zu stellen. m_168
Thomas B. schrieb: > Letztendlich geht > es nicht immer darum den einfachsten Weg zu gehen, sondern um sich den > Herausforderungen zu stellen. > m_168 Wenn ich Dein Chef wäre, hättest Du jetzt einen Anschiss bekommen. Im Beruf geht es darum, die vorgegebene Aufgabe mit den geringsten Kosten und der bestmöglichen Qualität zu lösen, und Arbeitszeiten sind auch Kosten. fchk
An Frank K. Ich weiß zwar nicht inwieweit mir das weiterhilft, aber musste vielleicht einfach mal gesagt werden! Genau so ist es! Da erzählst du mir nichts neues, bin selber in einer beruflichen Situation, wo es nur darum geht. Diese Anakdote bezieht sich aber aufs lernen. In der Schule macht man doch auch Aufgaben die auf einen Lernerfolg ausgerichtet sind und nicht auf Effizienz. Dachte nicht dass es hier um Belehrungen zu Charaktereigenschaften und Idealismus geht, trozdem danke für dein Kommentar, ich wede mich mit "Weisen" Sprüchen etwas zurück halten. m_168
Thomas B. schrieb: > Ich muss zugeben, daß diese Art der Programmierung mit den > while-Schleifen nicht ideal ist, aber > ich habs nicht besser hinbekommen. Sieh mal jede überwachte Funktion als kleinen Zustandsautomaten. Zur Zeit sind die Zustände und deren Übergange a) nicht sauber herausgearbeitet, und b) wird bei einigen Zuständen in einigen Automaten auf den nächsten Übergang gewartet, ohne dass die anderen Automaten weiter bedient werden. Um dass zu "beheben" müsstest Du dir aber Gedanken über die gleichzeitige Darstellung aller Zustände auf den Display machen. So könnte man zum Beispiel bei mehreren Fehlerfällen gleichzeitig auf einem Teil des Displays die Fehler nacheinander und zyklisch anzeigen ... Thomas B. schrieb: > Über das I2C Bus, soll ein 2. ATmega168 mit dem Status beschrieben > werden, ausgewertet und über UART in ein UART-LAN Converter weiter > gesendet werden. Dazu habe ich einige Ansätze, jedoch keine Lösung. 1. Es gibt die Möglichkeit, per Software-UART jeden Pin als UART-TX bzw. RX zu verwenden. 2. Im Übertragungsprotokoll auf jeden Fall eine Checksum vorsehen. Bits auf Leitungen kippen immer wieder gerne mal um. 3. TWI/I2C ist ein interessantes Feld. Der Atmega168 kann sowohl Master als auch Slave in Hardware. Das macht es aber nicht unbedingt einfacher. In jedem Fall würde ich mir an Deiner Stelle (falls nicht schon vorhanden) einen Logicanalyser zulegen (Ich habe seit langem einen Saleae-Klon aus China, und seit kurzem einen originalen Saleae Logic Pro 16). Zudem: Wie lang soll die Leitung zwischen den beiden uC werden? Bei langen Leitungen kommen andere, auch interessante, Effekte ins Spiel ... So weit erst einmal. Viel Erfolg! LG, Sebastian
:
Bearbeitet durch User
Hallo Sebastian. Herzlichen Dank für dein Feedback. Die Funktionen mit den Zuständen wollte ich ursprünglich mit einer switch-case ausführen, danach habe ich mit Interrupts gearbeitet. Alles verworfen, weil zu viele Probleme auftraten. Die Anzeige macht ganz genau dass was sie soll und beinhaltet keinerlei Kompromisse. Aufgrund von Prioritäten und verschiedene Behandlungen (quittierbar, nicht quittierbar, nur Alarm rücksetzten/nicht quittieren,....) musste eine ganz spezielle Lösung entwickelt werden, ohne die Übersicht zu verlieren. (Zum besseren Verständnis siehe pdf im Anhang) Die Möglichkeit eines S-UART ist mir bewusst, sehe aber mit der TWI Methode trotzdem mehr Möglichkeiten. Das ganze geschieht mit Erweiterungsplatinen und dadurch spielen Leitungslängen keine Rolle. Sebastian Wangnick schrieb: > TWI/I2C ist ein interessantes Feld. Der Atmega168 kann sowohl Master > als auch Slave in Hardware. Das macht es aber nicht unbedingt einfacher. Deswegen bin ich hier.... Logicanalyser ist eine wunderbare Sache und wer hat der hat. Ich leider nicht, komme aber dz noch mit meinem Oszi ganz gut zurecht.
@ Thomas B. (m_168) >quittierbar, nur Alarm rücksetzten/nicht quittieren,....) musste eine >ganz spezielle Lösung entwickelt werden, ohne die Übersicht zu >verlieren. (Zum besseren Verständnis siehe pdf im Anhang) Nicht wirklich übersichtlich. Auch die komplexesten Abläufe kann man recht übersichlich in einem Zustandsdiagramm darstellen. Das solltest du tun, du willst ja was lernen. Siehe Statemachine. >Logicanalyser ist eine wunderbare Sache und wer hat der hat. Ich leider >nicht, komme aber dz noch mit meinem Oszi ganz gut zurecht. Na immerhin. Damit kommt man auch recht weit. Aber so ganz ohne "schnelle Augen" (Oszi, Logicanalyzer) kommt man heut nicht mehr allzu weit, auch als Bastler mit uCs.
Hallo Falk, ich muss dir absolut recht geben, es sei eine gute Angewohnheit, auch bei kleinen überschaubaren Dingen eine ordendliche Sturktur abzubilden. In diesem Fall erstellte ich zumindest eine Anweisungsliste und eine Funktionstabelle. Wie erwähnt versuchte ich es damals mit der switch-case Methode, kam aber nicht sehr weit.. Der Artikel über FSM wird mir helfen, in Zukunft Programmstrukturen besser abzubilden und somit den Prozessor am laufen zu halten. Danke dafür! Ich nehme es mir zu Herzen und werde versuchen das Programm dahingehend abzuändern und hoffe damit eine Basis für meine weiterführende Kommunikation zu gewinnen. m_168
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.