Hallo, ich benutze den Webserver von Ulrich Radig auf der Hardware von Holger Buss. Am Webserver betreibe ich drei 1-wire Busse zur Temperaturmessung. Die Software läuft ohne SD-Karte. Die Bedienung erfolgt über das HTML-Interface. (Einstellung der IP-Adresse, Speicherdump, Verwaltung von Namen für die Dallasbausteine, Verwendung der MAC-Adresse von der Netzwerkkarte und favourite icon sind weitere Features) Quellcode, Hexdatei und Anleitung finden sich im Anhang. Ideen und Anregungen sind gern gesehen Gruß Joachim
Hallo Joachim, habe mir mal die Doku durchgelesen. Klingt alles sehr interessant. Vielleicht könntest Du in Deine Doku noch einen kleinen Schaltplan einfügen, aus dem hervorgeht, wie die Sensoren angeschlsoosen sind. Und noch ein paar Fragen: Ich habe noch nie mit derlei One-Wire-Bauteilen zu tun gehabt. Haben alle One-Wire-Chips eine auslesbare Seriennummer? Die Bitmaske wird offensichtlich wie eine Adresse verwendet. Wie wird die Bitmaske eingestellt? Wo findet man anfängertaugliche Informationen zu solchen Bauteilen? Friedrich
Und noch eine Frage: Was machst Du mit den eingesammelten Messwerten? Dienen die nur der Anzeige oder werden die irgendwie weiterverarbeitet? Friedrich P.S. Inwischen habe ich schon ein paar Infos zu 1-wire-devices gefunden.
Hallo Friedrich, der Anschluß der Sensoren ist einfach. Vom Port-Pin D6 legst Du einen Widerstand 4k7 an +5V. Die Sensoren werden dann mit DQ an D6 gelegt und GND wird noch mit 0V verbunden. Nahezu alle one-wire Bausteine haben eine Seriennummer und sind "multidrop"-fähig. Den Hinweis auf die Seriennummer und das Stichwort "multidrop" findest Du auf der ersten Seite des Datenblattes. Die erwähnte Bitmaske zeigt an, an welcher der möglichen one-wire Busleitungen der Baustein angeschlossen ist. Der Anwender braucht dabei nichts einzustellen. Zu dem Prinzip gab es bereits 1995 eine Veröffentlichung in Elrad. Die ausführlichsten und umfangreichsten Informationen gibt es jedoch beim Hersteller. http://www.maxim-ic.com/1-Wire.cfm Zur Zeit kann ich die Meßwerte nur ansehen. Eine Aufzeichnung kommt später. Der nächste Schritt soll eine Ausgabeeinheit sein, mit der ich meine Heizung steuern will. Gruß Joachim
bitte veröffentliche auch deine weiteren codebeispiele. ich bin vorallem auf den dattenlogger gespannt! vielleicht kannst die doc ja auch im wiki schreiben dann kann jeder dazu was beitragen.
Ich habe meinen Webserver noch um eine MCA-25 Kamera erweitert und einige Kleinigkeiten optimiert. Joachim
Hi Joachim erstmal ein Dank an deine super Doku etc. Nun zu meinem Problem: Habe alles Aufgebaut ausser der Temperatur Sensorik. Webserver läuft auch soweit. PING, Webseite etc. Allerdings habe ich mit der Kamera keinen Erfolg bis jetzt. Unterschied zu deiner Hardware: Ich benutze einen 11,0592 MHz Quarz. Kann es sein das es daran liegt? Hast du deine Schaltung mal damit getestet? Mir kommt es vor, als wenn die Baudrate der Kamera nicht erreicht wird. Mit Hyperterminal bekomme ich eine Verbindung mit 9600 Baud und der LOG bzw. Dump wird angezeigt.Was sollte nach der Cam init passieren? Gibt es dann trozdem noch einen LOG für Hyperterminal, oder bleibt die Frequenz der Cam erhalten? Bei mir läuft der Log weiter. Gerd
Hallo! Ich verwende auch einen 11,0592MHz Quarz. Die 460kbaud triffst du damit nur genau, wenn der UART im Doublespeed Modus läuft. Dann funktionierts auch mit der MCA25 Kamera. Gruß, Daniel
Hmm, habe die Taktfrequenz in main.h eingetragen sowie die Kamera in mca25.h defined. Komisch halt dabei, das die Kamera nicht richtig läuft. Was ist eigendlich mit den Spannungen an den Portpinnen? Die haben doch auch 5V. Zerstören die nicht die Kamera, da diese ja laut Datenblatt nur mit 3,3 bis 4,2 V betrieben werden sollte?
Hallo Gerd, die Spannung an den Ausgangsports ist mit 5V zu hoch. Das führt jedoch nicht zur Zerstörung. Das Bild bekommt dadurch einen Grünstich. Das Resetsignal ist als Opencollector unproblematisch. RxD am AVR ist ein Eingang und bei der Leitung von TxD (AVR) zu RxD (MCA-25) ist eine Klemmschaltung mit Widerstand und Diode vorgesehen. Damit ist wird geschilderte Problem behoben. Ich betreibe den Webserver mit einem 14,7456 MHz Quarz. Vorher habe ich die Webcam mit 16MHz erfolglos getestet. Die Umschaltung des Uart in den Doublespeed Modus wird in MCA25.c erledigt und berücksichtigt die verschiedenen Quarzfrequenzen. Die wenigen Codezeilen sollten m. E. stimmen.
1 | void mca25_set_460800baud(){ |
2 | _delay_ms(5); |
3 | #if SYSCLK==11059200 || SYSCLK==3686400
|
4 | USR |= (1 << U2X); // activate USART double speed |
5 | UBRR=(SYSCLK / (460800 * 8L) - 1); // Achtung: Vorteiler teilt nun |
6 | durch 8 |
7 | #elif SYSCLK==14745600 || SYSCLK==7372800
|
8 | UBRR=(SYSCLK / (460800 * 16L) - 1); // Vorteiler teilt weiterhin durch |
9 | 16
|
10 | #else
|
11 | #error "Fehler bei der Auswahl der Taktfrequenz. Es sind nur genau 4
|
12 | Quarzfrequenzen zulässig!" |
13 | #endif
|
14 | _delay_ms(5);
|
15 | }
|
Gerd, Du schreibst von einem Datenblatt. Das würde mich interessieren. Gruß Joachim
Oh, Datenblatt habe ich leider auch nicht, meinte deine Doku. ...SORRY...
So, hab jetzt die ganze Zeit getestet. Habe mal mehrer Debugmeldungen in den Source eingebaut. Genau an der Stelle, wo die Funktion: mca25_set_460800baud() aufgerufen wird, macht der Cam Init nicht mehr weiter. Scheint also doch irgedwie an dem Quarz un dem Source zu liegen.
Ich habe den Code etwas geändert und betreibe den UART nun im Doublespeed Mode bei 14,7456 MHz Takt.
1 | void mca25_set_460800baud(){ |
2 | _delay_ms(5); |
3 | //#if SYSCLK==11059200 || SYSCLK==3686400
|
4 | USR |= (1 << U2X); // activate USART double speed |
5 | UBRR=(SYSCLK / (460800 * 8L) - 1); // Achtung: Vorteiler teilt nun |
6 | durch 8 |
7 | /*#elif SYSCLK==14745600 || SYSCLK==7372800
|
8 | UBRR=(SYSCLK / (460800 * 16L) - 1); // Vorteiler teilt weiterhin durch
|
9 | 16
|
10 | #else
|
11 | #error "Fehler bei der Auswahl der Taktfrequenz. Es sind nur genau 4
|
12 | Quarzfrequenzen zulässig!"
|
13 | #endif */
|
14 | _delay_ms(5); |
15 | }
|
Die Umschaltung in den Doublespeed Mode funktioniert ohne Probleme. Spielt Deine Kamera mit einem der anderen Pakete (Simon Schulz, Uwe Radig oder Holger Buss) ? Holger Buss schreibt, daß er erfolgreich mit 11,0592 MHz getestet hat. Gruß Joachim
Das hatte ich so auch schonmal probiert, leider auch da erfolglos. Der Source von Holger Buss läuft auch nur bis zu diesem Punkt. Als wenn die Cam das nicht will. Hier mal mein Hyperterminal Log ab der CAM: MCA-25: OK +IPR: (),(1200,2400,4800,9600,19200,38400,57600,460800) OK Danach kommt nichts mehr
Danach wird auf 460800 bd umgeschaltet und die Kommunikation kann von Hyperterminal nicht mehr mitgeschrieben werden. Die Kommunikation mit 460800 bd habe ich selbst auch noch nicht mitgeschrieben. Die Rx und Tx Leitungen scheinen nicht vertauscht zu sein und der Resetimpuls scheint auch vorhanden zu sein. Ist die Betriebsspannung sauber? Die Kamera nimmt nach Berichten im Forum ca. 100 mA auf. Ein Stützeleko über der Betriebsspannung ist bei der "Diodenlösung" sicher erforderlich.
Stützelko ist eigebaut. Wie lang ist deine Leitung zur Cam? Oder wer hat Erfahrung damit, wie lang man die machen kann? Ich habe ca. 20 - 25cm an der Cam hängen. Vieleicht liegts ja daran, ansonsten weiss ich auch nicht mehr weiter.
Hallo Gerd, ich habe hier noch einen aktuellen Hinweis auf die Wichtigkeit der Stromversorgung gefunden: http://www.mikrocontroller.net/forum/read-4-251170.html#281168 In dem Forum wird auch an einigen Stellen von Problemen bei der Geschwindigkeitsumstellung berichtet. Gruß Joachim
Danke für deine Hilfe. Habe jetzt alles nochmal ganz in Ruhe angepasst. Resultat: Die Sourcecodes von Holger Buss laufen jetzt stabil. Die von dir haben immer noch dieses Problem. Hab schon versucht, die Baudraten anpassung von Holger zu nehmen, ohne Erfolg. Werd mich da morgen nochmal dransetzen. Deine Sources sind ja bei weitem Überlegen. Schön wäre da noch ne Passwort Abfrage etc. zum sicheren einloggen übers Internet und ein paar Schaltausgänge ohne PWM. Gruß Gerd
Ich habe noch einmal alle Dateien durchgesehen, die bei der Änderung der Quarzfrequenz betroffen sind. Dabei ist mir ein Fehler in der anhängenden Datei aufgefallen. Der Takt für die Wartezeiten der one-wire-Schnittstelle war auf 16MHz eingestellt und nicht an SYSCLK gebunden. Bei 14,7456 MHz gab es keine Probleme, bei 11,... ist die Wahrscheinlichkeit von irgendwelchen Seiteneffekten jedoch größer. Eine Paßwortabfrage wurde in einem der Foren bereits diskutiert. Die Schaltausgänge ohne PWM habe ich bereits realisiert. Die nächste Version ist jedoch noch nicht fertig, weil mein DCF-Dekoder noch nicht gestestet ist. Gruß Joachim
Hi Joachim, bin zwar leider noch nicht dazu gekommen, Deine Sources auszuprobieren (wart noch auf ein paar Teile), aber tolle Sache u.v. gute Doku. Was ich eigentlich sagen will: Du schreibst, dass Du einen Dcf-Empfänger einbinden möchtest. Ich denke mal, Du hast das Teil schon, aber einfacher (hardwareseitig) und v.a. billiger wäre doch die Abfrage eines Timeservers übers Netz. Man müsste zwar das Udp-Protokoll und bestimmt einige andere Sachen implementieren (woran ich scheitere), aber generell sollte es machbar sein. Ich hoffe, ich bring hier jemand auf Ideen! ;-) Gruß Sirko
Hallo Sirko, sicher ist es machbar, einen Zeitserver zum Stellen der Uhr zu benutzen. Da ich keinen Zeitserver im Intranet betreibe, müßte ich neben dem erforderlichen Protokoll, dem Webserver noch den Umgang mit der Netzmaske und dem default gateway beibringen, was ich angesichts der spärlichen Doku zum Webserver verworfen habe. Da erscheint es mir einfacher, das Zeitsignal auszuwerten und 3 Euro für einen Zeitzeichenempfänger auszugeben (aus einem preiswerten Funkwecker chinesischer Produktion ausgebaut). Gruß Joachim
Tachchen Was bedeutet eigendlich die Angabe ISA_CTRL bzw. warum heisst diese Marke in Joachims Doku/Quelltext ISP_CTRL? Holger Buss hat sie doch ISA_CTRL genannt. Gibts da Unterschiede?
ISA_CTRL bzw. ISP_CTRL steht für die verwendete Hardware und damit für die Portbelegung. In der Version 1.38 von Ulrich Radig wird ISP_CTRL benutzt. In Webcam Quellen tauchte später ISA_CTRL auf. Um Fehler zu vermeiden, sollte es nur eine Variable zur Hardwarebeschreibung geben. Bei den inzwischen verschiedenen Quellen für die Hardware von microcontroller.com gibt es Abweichungen, die bei der Kombination von Softwaremodulen zu Problemen führen können. Gruß Joachim
Hallo Joachim, ja, da hatte sich bei uns ein Tippfehler eingeschlichen. ISP_CTRL macht irgendwie in diesem Zusammenhang keinen Sinn :-) Dein Projekt finde ich sehr spannend. Ich habe es gerade mal getestet. Können wir die Files und Deine Dokumentation bei uns auf der Seite: http://www.mikrocontroller.com veröffentlichen? Mail mich doch mal diesbezüglich an. (Deine eMail-Adr könntest Du vielleicht noch in der Doku mit aufnehmen) Gruss, Holger
Hier der aktuellste Stand der Webserversoftware. Die Funktionen in Kürze: DCF77-Dekoder mit beliebig gepoltem Eingangssignal. Drei one-wire Busleitungen, ein- und ausschaltbar. Drei Ausgangsleitungen ein- und ausschaltbar. Webcam MCA-25, Funlayer und Bildformat einstellbar. Bis zu 63 Dallas-Bausteine (z.B. zur Temperaturmessung) mit Namen zu verwalten. Rote LED über PWM-Ausgang in der Helligkeit einstellbar, Statussignal der Webcam und Zeitimpuls werden aufmoduliert. IP-Adresse einstellbar, wird nach dem nächsten Reset geändert. MAC-Adresse wird aus der Netzwerkkarte übernommen. Grundeinstellungen werden mit Prüfsumme im EEPROM abgelegt Speicherdump des AVR-EEPROM oder RAM über den Webserver. Speicherdump des EEPROM der Netzwerkkarte über die serielle Schnittstelle. Alle Einstellung sind über den Webserver veränderbar. Gruß Joachim
Hallo! Die Features lesen sich wirklich interessant. Da meine Hardware allerdings auf dem Anschlusschema von Simon Schulz ( http://avr.auctionant.de/img/avr-ip-webcam_s01_sch.png ) basiert, habe ich ISP_CTRL auskommentiert. In deiner Version von WriteRTL() wird der Adressport noch mit der Bitmaske ADDR_OUTPUT 0x1f verknüpft. Die war nur in der Holger-Buss-Belegung definiert und es gab einen Compilerfehler. Ich hab das dann entsprechend hinzugefügt und er compiliert fein durch. Jetzt das Problem... Die Netzwerkkarte wird nicht initialisiert RTL8019AS: ERROR(255) Hast du (oder hat sonst jemand hier) die Sourcen mit anderer Hardware laufen? Was hab ich da übersehen? Gruß, Daniel
Hi Joachim ! Das neue Update hört sich wirklich super an. Werds nachher mal direkt ausprobieren. Ne kleine Anmerkung zu deiner Doku. Du könntest evtl. noch ein paar Screenshots der Webseiten einbauen, um mal im Vorfeld ein Bild von deiner Leistung zu bekommen und wie es überhaupt aussieht. Ansonsten Respekt und weiter so. Bis zum nächsten UPDATE ,-) MFG CHRIS
Ach, da fällt mir noch ein, was ist eigendlich mit dem Servo in deiner Software. Steht zwar im Source, wird aber nicht benutzt. Schön wäre auch noch, diese Option über die Webseite zu steuern.
Hallo Daniel, ich denke ich habe nach Betrachtung deiner Schaltung den Fehler gefunden. In RTL8019.h findest Du die Variable RTL_REG_OFFSET, die zu der Registeradresse addiert wird. Diese Variable war auf 96 gesetzt und verhinderte so das Nutzen der freien Bits an diesem Port. Ich habe neben der von Dir bereits entdeckten Maskierung der Adreßbits, den Offset deshalb auf 0 gesetzt. In deiner Schaltung sorgt die Konstante 96 dafür, daß die Leitungen /IOW und /IOR auf "1" bleiben. Als schnelle Lösung solltest Du die Konstante 96 wieder addieren und die Adressmaske ändern. Zwei der Ausgangsleitungen sind dann natürlich nicht mehr nutzbar. Gruß Joachim
Hallo Chris, von den Screenshots habe ich bisher Abstand genommen, weil dann die Dateigrößen explodieren. Die letzte Version liegt bereits über dem 1 MByte-Limit des Forums. Der Upload hat aber trotz einer Mahnung funktioniert. Einen Servo habe ich nicht. Ich benutze die rote LED zum Anzeigen der Sekundenimpulse (LED aus), zur Ausgabe des Statussignals der Kamera (LED hell) und zur Funktionsanzeige (mittlere Helligkeit, einstellbar). Die Servosteuerung über die Webseite habe ich entfernt. Ich mußte die Webseite neu machen, weil ich keinen Platz für die Javascripte hatte. Das sollte aber leicht zu ergänzen sein. Vorlagen sind dazu genügend enthalten. Gruß Joachim
Vielleicht eine dumme Frage: Was versteht man unter einem Webserver zur Temperaturmessung? MfG Wolfgang
Lies dir doch einfach mal den ersten Beitrag hier zu diesem Thema durch. Was ein Webserver weist du doch bestimmt. Er macht folgendes: Ein Nutzer stellt eine Anforderung, z.B. durch Anklicken eines Links in seinem Browser (Client). Der Browser leitet einen HTTP-Request an den im Link adressierten Webserver. Der Webserver liefert die adressierte Seite mitsamt eines Mime-Types zurück. Der Browser zeigt die übertragenen Daten entsprechend ihres Mime-Types an. Nun zur Temperaturmessung: Einer oder mehrere Temperatursensoren sind an dem Server angeschlossen. Die Nutzdaten der Sensoren werden vom Server aufbereitet und mittels TCP/IP Protokoll an die jeweilige "Request" Stelle geleitet. Diese kann z.B bei einem Freund sein. Dort kann nun z.b. die Temperatur des Fussbodens in der Küche(falls denn ein Temperatursensor eingebaut ist) abgelesen werden.
Hallo, ich hätte da mal eine kleine Frage, gibt es nicht one wire treiber Ic, mit analogen bzw. digitalen Ausgängen? Wenn ja , wäre es doch schön, wenn man diese mit in deinem Prohekt implementieren würde. Man könnte ja dann in Verbindung mit den Temeperatursensoren, zb. die Fussbodenheizung steuren, oder irgenwelche Lampen ansteuern, übers Webinterface von Hand oder über Temperatur soll / ist - werte die Heizungsstellmotoren auf oder zu fahren. Ich weiß nicht ob ich das richtig verstanden habe , in deiner Doku schreibst du, dass man die drei One wire leitung an und abschalten kann, sind diese denn auch gleichzeitig abfragbar? Gruß Peppe
Hallo, @Pepe: Die Steuerung meiner Heizung ist bei mir das angepeite Ziel. Einen DS2480, mit dem man 8 Ausgangsleitungen am one-wire Bus bekommt habe ich schon vorliegen. Die drei schaltbaren Busleitungen werden gleichzeitig abgefragt. Da jeder Thermometerbaustein bei der Temperaturwandlung etwa 1mA benötigt, ist es sinnvoll die Thermometer auf mehrere Busse zu verteilen und damit etwas Reserve zu haben. Der Server merkt sich, an welchem Port er welchen Baustein gefunden hat. @Wolfgang: Man kann den Anzeigewert digitaler Thermometer auf die verschiendesten Arten sichtbarmachen oder ausgeben. Ich mache das mit einem Webserver. Mein Ausgabegerät ist dann ein PC im heimischen Netz, oder was immer zur Verfügung steht, bzw. was die Netzinfrastruktur hergibt (Laptop über WLAN, Internetcafe über Dyndns, Handy mit Browser, VPN, etc.) Gruß Joachim
Hallo Joachim, ich habe mal ein paar Screenshots zusammen mit etwas Text auf unsere Homepage vorgestellt.... http://mikrocontroller.cco-ev.de/de/ISA_1wire.php Ist eine schöne Erweiterung für den Webserver.... Gruss, Ingo.
Hallo Ingo Wo sind denn die Bilder von der Webseite mit den Funlayern etc. Würde das auch mal gerne sehen.
Hallo, jetzt ist auf der Webseite auch ein Screenshot von der WebCam mit Funlayer. (Danke Joachim) Ausserdem sind auf den Screenshots jetzt 'echte' Temperaturdaten zu sehen... Gruss, Ingo.
@Jürgen + Joachim, ich danke euch für die Erläuterungen zum Webserver. Mit meinen Worten: Ein Webserver ist ein PC oder ein Laptop, der ständig mit dem Internet verbunden ist und der gleichzeitig Daten von z. B. Temperaturfühlern, Kameras usw. sammelt, welche ich aus der Ferne über das Internet abfragen kann. Wenn z. B. die Temperatur neben dem Ofen sehr hoch ist, sollte ich mich dann schleunigst nach Hause begeben, denn es besteht die Gefahr, dass die Bude bald abbrennt o. so ä. . richtig? MfG Wolfgang
@Wolfgang Ja, so ungefähr kann man es sehen, aber der Webserver muss nicht unbedingt ein PC oder Laptop sein. In diesem speziellen Beispiel HIER ist nämlich das besondere, das die Server Dienste auf einem µController laufen.
Hallo Joachim, ich habe mal nachgesehen und unter ds2480 finde ich nur ein 1 wire to RS232 chip, ist das richtig? oder gibt es ein chip der Digitale parallel Ausgänge hat? Wenn du das mit rs232 machen willst, dann gehe ich mal davon, das du damit eine serielle relais karte ansteuern willst? ICh habe mal ein Projekt gefunden, da aht jemand billige Funktsteckdosen aus dem Baumarkt seriel über funk angesteuert. Befehlssatz über Rs232 an µc und der hat dann die port des Fernsteuerchips angestuert, das teil habe ich mal nachgebaut und funzt sehr gut. Man könnte dann ja über den 1 wire bus den befehlssatz an den µc schicken und der steuert dann die Steckdosen. Hier ist der link zu dem Projekt: http://mitglied.lycos.de/madmax3333/ Ich habe mir Steckdosen bei Ratio gekauft, da kosten drei stück mit fernbedienung gerade mal 10 wenn die im Angebot sind, allerdings muste ich die Signale invertieren, weil in meiner Fb. ein anderer chip verbaut ist. Soll nur als Anregung dienen. Gruß Peppe
Hallo Peppe, der 8 Bit Ausgabeport ist ein DS2408. Ich hatte oben die falsche Zahl genannt. Ich will zur Ausgabe keine RS232-Schnittstelle verwenden, weil die Leitungslänge sehr begrenzt ist und ich die AVR-Schnittstelle schon mit der Kamera belegt habe. Da ich bei der Datenrate und der Schaltverzögerung keine hohen Ansprüche stelle, kann ich mit der one-wire-Schnittstelle an dieser Stelle gut leben. Das Funksteckdosenprojekt ist sehr interessant. Danke für den Link. Da mein AVR bei den I/O-Leitungen bereits ausgeknautscht ist, ist die Idee, den Fernsteuersender über den one-wire-bus fernzubedienen eine gute Alternative. Dann ist es auch einfach möglich, den Sender am optimalen Senderstandort zu platzieren. Die wenigen erforderlichen Bauteile kann man sicher noch im Handgehäuse des Senders unterbringen. Da ich acht nebeneinander liegende 24V-Stellantriebe ansteuern will, werde ich das nicht als Funklösung aufbauen. Die one-wire-Bausteine werden von der Software bereits erkannt und in der Liste aufgeführt. Die bausteinspezifischen Dinge sind jedoch noch zu schreiben. Ich habe noch eine Idee mit dem 4-Kanal-AD-Wandler DS2450. Da ich in meiner Heizung zwei elektronische Pumpen habe, die für einen konstanten Förderdruck sorgen, sollte ich über den Strom der Pumpe feststellen können, ob Heizventile geöffnet sind. Die erforderliche Potentialtrennung ist jedoch nicht trivial und unabdingbar. Deshalb habe ich das noch nicht weiterentwickelt. Gruß Joachim
Hallo Joachim, wo hast du den ds 2408 herbekommen? Soweit ich weiß bietet Reichelt den nicht an. Ich wollte meine Stellmotoren auch nicht über Funk ansteuern, aber ich könnte mir gut vorstellen diverse Lampen damit zu kontrollieren, 8 bit würden ja ausreichen um den pt2260 / pt 2262 an zusteuern. Und wenn man den ds2408 als smd Baustein verwenden würde könnte man den ja wirklich mit in der Fernsteuerung unterbringen, verfügt der Dallas über den tristate Modus? Die 24 V Stellmotoren kannst du denen mitteilen wie weit die auf und zu fahren sollen, oder können die wie meine nur auf oder zu? Meine haben eine Latenzzeit von ca. sieben Minuten, ich bin mir auch noch nicht ganz im klaren wie ich es hinbekomme, das ich auch wirklich die Temperatur einstellen kann die ich haben möchte, da die Fußbodenheizung auch eine gewisse Trägheit besitzt und die nicht ganz unerheblich ist. Sprich, wenn mein Temperaturfühler zB. 22 Grad erfasst und die Stellmotoren abstellt heizt der Boden immer noch für gut 45 min. nach. Hast du da schon ein Lösung zu? Gruß Peppe
Hallo @Joachim und alle Heizungsfreaks. Sollte man nicht einen eigenen Thread für Heizungssteuerung aufmachen bzw. unter Hausbus bzw. Hausbus in Hausautomatisierung umbenennen oder ins WIKI?. @Joachim ich wäre an einer naheren Info Deiner Heizungssteuerung interessiert(Hard/Software). Ich habe auch sowas vor in Verbindung mit ner Solaranlageninstallation. Viele Grüße Achim
Hallo Peppe, der DS2408 ist in der Tat schwierig zu beschaffen, da er sich noch nicht etabliert hat. Er hat aber auch einige "Ecken und Kanten". Der Ruhezustand der Ausgangsleitungen nach einem Reset ist für mich nicht optimal. Zur Relaissteuerung mit einem ULN-Treiber müßte ich erst alles invertieren. Ohne einen separaten Watchdog würde ich das IC auch nicht betrieben wollen. Bei einem Busfehler würde dann kein sicherer Zustand erreicht werden können. Wenn ich all das schaltungstechnisch nachrüste, steigt der Aufwand so sehr, daß es mir sinnvoll erscheint dafür einen AVR einzusetzen. Die Ausgänge des DS2408 sind als open collector ausgebildet. Die PT2260 machen m.E. keine allzuschweren Dinge. Aus 12 Eingangsleitungen wird ein serielles Telegramm gebildet. Die Anleitung steht im Datenblatt. Da der DS2408 nur 8 Leitungen hat, ist er nicht die optimale Wahl. Ich würde den PT2260 totlegen und das serielle Telegramm mit einem AVR realisieren. Die Ansteuerung würde ich über einen one-wire-Bus oder aber über eine Stromschleife vornehmen. Damit könnte man den Hardwareaufwand deutlich reduzieren. Meine Stellantriebe arbeiten thermisch (ich vermute einen PTC-Heizwiderstand der eine Ausdehnungseinheit erwärmt). Bei einem Anlaufstrom von 900mA kann man nicht mehr mit einem ULN-Treiber ansteuern, deshalb die Relais. Im Prinzip können die nur aus- oder eingeschaltet werden, wobei die Schaltzeit von der Wassertemperatur abhängig ist. Die Regelung der Fußbodenheizung mache ich zur Zeit über einen einstellbaren Wandthermostat, der als Zweipunktregler geschaltet ist. Zur Verminderung der Hysterese ist dort ein kleiner Heizwiderstand eingebaut. Das funktioniert zufriedenstellend. Andernfalls würde ich nachts bei verschiedenen Außentemperaturen eine Sprungantwort aufnehmen und versuchen daraus sinnvolle Reglerparameter zu erzeugen. @Achim: Mein System ist noch in Arbeit. Die Software mit Dokumentation (PDF)findest Du weiter oben. Bildschirmausgaben kannst Du hier http://mikrocontroller.cco-ev.de/de/ISA_1wire.php ansehen. Den Schwerpunkt lege ich auf ein HTML-Benutzerinterface, Netzwerkfähigkeit (Ethernet, TP) und die Verwendung des one-wire-Busses, der m.E. mit seinen Daten für die erforderlichen Temperaturmessungen optimal ist. Gruß Joachim
Hallo zusammen, ich habe mal eine ganz simple Frage an die Experten. Ich möchte meinen nachbau des Webservers gerne mit dem 16MHz Quarz laufen lassen. Auf die Kamera verzichte ich. Da ich überhaupt keine Ahnung von C habe und dei Datei main.h anpassen muss, benötige ich eine kleine Einweisung in das Copilieren des Codes. Ich habe mir WinAVR runter geladen. Welche Datei muss ich hier herein laden um zu compilieren? Wenn ich das Programm richtig verstehe werden die vielen Codes doch automatisch mit compiliert, oder? Wieso gibt es eigentlich immer eine C und eine h Datei? Und noch eine letzte Frage. Wird der Html Code auch auf die SD Karte gespeichert? Ansonsten finde ich das Projekt echt große Klasse! Schöne Grüße Klaus
notepade öffne und dann änderungen in main.h vornehmen. dann auf Copilieren, fertig. Die html seite kann auch im flash gespeicher wertdem. (webpage.c oder so) @Joachim würd mich auch über eine 16 mhz version ohne kamera als hexfile freun. Serielle baudrate 9600. Mein webserver läuft mit holgers code, doch mit deinem bekomm ich ihn nicht ans laufen.
Hallo, wenn ich dein source code maken will, bekomme ich immer die Fehlermeldung : uart.c:35: Fehler: zu viele Argumente f├╝r Funktion ┬╗fdevopen┬½ make: *** [uart.o] Error 1 ich habe lediglich die Taktfrequenz geändert auf 11.1 MHZ in der Main.h woran liegt das ich benjutze den compiler von winavr. Schan mal danke im vorraus. Gruß Peppe
@123 notepade öffne und dann änderungen in main.h vornehmen. dann auf Copilieren, fertig. Hallo, Wo finde ich "compilieren" im Menü von WinAVR-Notepade?
@123 nur dass wir uns richtig verstehen, du meinst das "Programmers Notepad" aus der WinAVR Installation!? Ich habe dieses vor mir und sämtliche Menüpunkte nach compiliern durchsucht. Endweder bin ich blind oder b... Blind bin ich nicht ;-) Gib mir bitte mal nen Tip
Ich edetiere mit dem normalen Nodepad und compeliere dann unter der Eingabeaufforderung ( Windows) Gruß Peppe
@Peppe wie machst du dass? kannst du mir weiterhelfen? Was muss ich genau in die Eingabeaufforderung schreiben?
Beim PN unter "Tools" -> "Make all" compiliert es. "clean" nimmt die Compileränderungen zurück, wenn du nur noch deine .c und .h brauchst. "program" würde es über AVRdude und ISP-Schnittstelle auf den Controller übertragen, wenn alles im makefile dafür passt. Gruß Elektrikser
Hi, wie bekomme ich denn die gesamte source ins Programm geladen ? Immer wenn ich auf öffnen gehe kann ich maximal eine datei auswählen. Aber eigentlich geht es doch auch über die Konsole, nur da bekomme ich immmer die Fehlermeldung: uart.c: In function `UART_Init': uart.c:35: Warnung: Verarbeiten des Argumentes 1 von ┬╗ fdevopen┬½ von inkompatib lem Zeigertyp uart.c:35: Fehler: zu viele Argumente f├╝r Funktion ┬╗fdevopen┬½ make: *** [uart.o] Error 1 Woran kann das liegen, ist mein Compiler zu alt?? hat sonst auch immer funktioniert. @ Klaus ich habe das immer so gemacht, indem ich in den ordner gewechselt bin in der meine source liegt und dann make eingegeben. Ach ja du muß natürlich zuvor den gcc compiler installiert haben. Gruß Peppe
Hallo Peppe, Du brauchst nicht die gesamten Sourcen ins Programm laden. Erst einmal packst Du das Zip-File mit den Quellendateien aus. Dann startest Du den Notepad aus dem WinAVR-Packet. Mit dem Notepad öffnest Du nun z. B. main.c, oder ein anderes .c bzw. .h file. Nun gehst Du zu "Tools" und betätigst "make all". Der Compiler sucht sich dann im Verzeichnis der geöffneten main.c die Datei makefile und findet dort alles was zu tun ist, insbesondere alle Dateien, die zu dem Projekt gehören. Im ersten Versuch probierst Du, die Quellen so zu übersetzen, wie Du sie erhalten hast. Wenn das fehl schlägt, musst Du deinen Compiler in Ordnung bringen. Dann kannst Du dich ans Ändern machen. @Klaus Es gibt die Möglichkeit eine SD-Karte zu nutzen. Ich habe das bisher jedoch nicht probiert, da der Platz im ATmega32 noch nicht erschöpft ist. Gruß Joachim
@ JaochimB
Danke für die Info,
ich habe das jetzt so gemacht wie du es mir beschrieben hast.
und ersteinmal nichts in der source geändert und mein Glück versucht,
doch leider erfolglos. Beim kopilieren kommen eine Menge von Fehler.
Die sehen z.b. so aus:
Compiling: main.c
avr-gcc -c -mmcu=atmega32 -I. -g -Os -funsigned-char
-funsigned-bitfields -fpack-struct -fshort-enums -Wall
-Wstrict-prototypes -Wa,-adhlns=main.lst -std=gnu99 main.c -o main.o
In Datei, eingefügt von main.h:17,
von main.c:29:
./avr/signal.h:36:2: Warnung: #warning "This header file is obsolete.
Use <avr/interrupt.h>."
In Datei, eingefügt von main.h:23,
von main.c:29:
rtl8019.h:87:1: Warnung: "ISR" redefined
In Datei, eingefügt von main.h:16,
ich habe schon den ordner avr mit in den source ordner kopiert, komme
dann ein stückchen weiter beim kompilieren aber dann kommen diese
Fehler....
Gruß Peppe
Hallo Peppe, mein "Programmers Notebook" ist Version 2.0.5.48. Der avr-gcc ist Version 3.4.3 und die AVR-libc hat die Version 1.2.3. Vergleich doch einmal Deine Versionen. Evtl. brauchst Du ein update. Gruß Joachim
Hi Joachim, ich habe alles neuere Versionen, hatte mir Winavr neu runtergeladen, eventuell zu neu? Ciao Peppe
Hallo, @ Joachim ich habe jetzt eine ältere Version von Winavr installiert und mit der geht es, vielen Dank für deine Hilfe. Gruß Peppe
Hallo, ich habe das selbe Problem. Wo kann ich die ältere Version bekommen? Grüße Klaus
Danke für den Hinweis. Offensichtlich liegt das Versionsproblem bei mir. Ich werde das in der nächsten Ausgabe berücksichtigen und dann alles mit dem aktuellsten Compiler lauffähig machen. Gruß Joachim
Angehängte Dateien:
-
Fuse.JPG
31 KB
Hallo, ich habe den Webserver von Ulrich Ratig nachgebaut und in Betrieb genommen. Er lief auf Anhieb! Nachdem ich auf die Temperaturüberwachung von Joachim Börke gestoßen bin, habe ich das Quarz auf ein 11,0592 Mhz getauscht und die verschiednen Softwareversionen aus den Beitragägen dieses Forums eingespielt. Leider kann ich keinen Ping mehr zum Server senden oder die Adresse anwählen. Woran kann das liegen? Auf der Platine leutet die rote und grüne LED. Die IP Adresse meines PC lautet 192.168.99.9 Sub Net: 255.255.255.0 Die einstellung meiner Fuse Bits findet ihr im Anhang, liegt es vielleicht an denen? Das Programm spiele ich mit Pony Prog ein. Ich nutze zum überspielen immer den Butto "Write Device". Habt ihr eine Idee was ich falsch mache? Danke für die Hiefe vorab Tobias
Hast du im Programm deine Quarzfrequenz richtig angegeben? (SYSCLK in der main.h) Gruß Elektrikser
HI, @ Tobias , hast du die cam auch angeschlossen? Ich habe festgestellt, das wenn die cam nicht angeschlossen ist, dann bootet der Webserver nicht zuende, erst wenn die cam angeschlossen ist,dann fährt er vollständig hoch, kannst ja mal im hyperterminal nachsehen wie weit deiner kommt. Gruß Peppe
@Peppe Hallo Peppe, die cam habe ich noch nicht angeschlossen. Ich bekomme sie erst in der nächsten Woche. Das Hyper Terminal habe ich angeschlossen und bekomme nur wirre Zeichen. Hängt das wirklich an der nicht angeschlossenen cam? Tobias
Kann ich auch bestätigen. Deaktivier mal im Programm die Cam. (#define USE_MCA25_CAM 0 in der mca25.h)
#define USE_MCA25_CAM 0 kann ich nicht finden aber #define USE_MCA25_CAM 1. Wenn ich das deaktiviere bekomme ich neue Fehler beim Compilieren. meine Programmversion ist die Datei "060118_Source1.38_jb04.zip". Nutzt du eine andere?
Autsch! Do hättest einfach aus der "1" eine "0" machen müssen, wie in der Klammer.;) Es lässt sich bei mir dann kompilieren, bis auf das "fdevopen" in der uart.c. Da mosert Winavr(20060125), das zu viele Argumente da wären.
Hey, Super!! Vielne Dank für die Unterstützung. Zwar bekomme ich über das terminal weiter nur Datenmüll, aber über das Lan ist alles o.k. Schöne Grüße Tobias
"Es lässt sich bei mir dann kompilieren, bis auf das "fdevopen" in der uart.c. Da mosert Winavr(20060125), das zu viele Argumente da wären." das problem hab ich auch gehabt da muss du in der uart.c den übergabeparameter ändern: fdevopen (uart_putchar, NULL); da hat sich was in der lib geändet. schau mal unter: http://www.nongnu.org/avr-libc/ das steht es genauer beschireben,
hallo,
Erstmal großes lob an alle beteiligten!!
Hab die Platine von mikrocontroller.com, der Server läuft mit der SW
von holger ohne probleme. Den Temperaturwebserver bekomme ich aber
nicht ans laufen.
Ich hab schon alle versionen ausprobiert, dort natürlich alle
Einsellungen getätigt. Der Server läuft auch s.h log der seriellen
Verbindung. Aber ich kann ihn nicht über's lan erreichen. Mit
holger's code war was kein Problem.
ich habe ein 16Mhz Ouartz und keine cam oder 1-wire oder Dcf...
hatt jemand den webserver mit der hw zum laufen bebracht?
In der neusten Version fehlt glaube ich in der httpd.c : #include
"webcam/mca25.h" sonst kann man die cam nicht abschalten.
Hier das Log des terminal programms. Vielleicht kann jemand ein Log
schicken wo der server läuft.
Danke
93LC46 Dump:
00 01 02 03 04 05 06 07 - 08 09 0A 0B 0C 0D 0E 0F
0000: 90 00 00 00 00 00 00 00 - 00 00 00 00 00ø
93LC46 Dump:
00 01 02 03 04 05 06 07 - 08 09 0A 0B 0C 0D 0E 0F
0000: 90 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
................
0010: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
................
0020: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
................
0030: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
................
0040: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
................
0050: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
................
0060: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
................
0070: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
................
RTL8019AS: Okay 34
MAC: 00:00:00:00:00:00
IP : 192.168.99.199
EEPROM Dump:
00 01 02 03 04 05 06 07 - 08 09 0A 0B 0C 0D 0E 0F
0000: FF FF FF FF FF FF FF FF - FF FF FF FF FF FF FF FF
................
0010: FF FF FF FF FF FF FF FF - FF FF FF FF FF FF FF FF
................
0020: FF FF FF FF FF FF FF FF - FF FF FF FF FF FF FF FF
................
0030: FF FF FF FF FF FF FF FF - FF FF FF FF FF FF FF FF
................
0040: FF FF FF FF FF FF FF FF - FF FF FF FF FF FF FF FF
................
0050: FF FF FF FF FF FF FF FF - FF FF FF FF FF FF FF FF
................
0060: FF FF FF FF FF FF FF FF - FF FF FF FF FF FF FF FF
................
0070: FF FF FF FF FF FF FF FF - FF FF FF FF FF FF FF FF
................
@ 123: Bei Holger wird die Mac-Adresse im Quelltext festgelegt und ist eine Konstante. Bei mir wird die Mac-Adresse aus dem 93LC46 EEPROM auf der Netzwerkkarte gelesen und dann verwendet. Deine Netzwerkkarte liefert jedoch keine EEPROM-Daten (d.h. nur "00"). Folgerichtig wird die Mac-Adresse auf 00:00:00:00:00:00 gesetzt. Ist auf Deiner Netzwerkkarte ein RTL8019 und ein 93LC46 mit 8 Pins in der Nähe des RTL8019? Wenn keine Cam angeschlossen ist, hängt das Programm bei der Initialisierung. Du müßtest dann das Programm mit abgeschalteter Webcam neu übersetzen (die Zeile #define USE_MCA25_CAM 1 in der Datei webcam/mca25.h mit // auskommentieren) Gruß Joachim
erstmal vielen Dank für die Antwort. Auf der Netzwerkkarte ist ein eeprom. Ich glaub es wird auch ausgelesen. Würde der Server mit der Mac-Adresse 00:00:00:00:00:00 auch gehn? In Deiner ersten Code-version müsste man ja eigentlich nur die Quartz-Frequenz ändern und dann sollte es gehn. tut es aber nicht. Bei der neusten Version hab ich USE_MCA25_CAM 0 gesetzt. und in der httpd.c die "webcam/mca25.h" includet da sonst die precompiler "if" nichtig ist, aber damit geht es auch nicht. Es kommt noch eine Fehlermeldung gegen falscher Quartzfrequenz, die habe ich auskommentier da die ja nur wichtig ist, wenn man die Cam verwendet. Die Ausgabe der Seriellen Sieht gut aus oder was müsste da noch kommen? Danke 123
Hallo 123, der 93LC46 Dump zeigt, daß das EEPROM, abgesehen von der ersten Stelle überall "00" enthält. Entweder ist es tatsächlich leer, oder es wird nicht ordentlich gelesen. Das AVR-EEPROM ist unprogrammiert, das ist beim ersten mal in Ordnung. Später steht in der ersten Zeile eine evtl. gesetzte neue IP-Adresse, etc.. Die MAC-Adresse 00:00:00:00:00:00 funktioniert auch. Man muß nur aufpassen, daß kein anderes Ethernetgerät im Netzwerk mit der selben MAC-Adresse arbeitet. Bei Mainboards mit TP-Anschluß habe ich schon beobachtet, daß die MAC-Adr. ebenfalls auf 00.. stand. Das läßt sich jedoch einfach prüfen: In der MSDOS-Eingabeaufforderung "arp -a" eingeben und man bekommt den arp-cache gezeigt. Auf meiner Hardware laufen die Versionen von Holger mit und ohne Webcam und auch meine Versionen. Hast Du den Server über die Adresse 192.168.99.199 angesprochen? Auf der seriellen Schnittstelle wird beim Start die aktuelle IP-Adresse ausgegeben. Gruß Joachim
Hi, ich habe exakt das gleiche Problem wie 123, allerdings habe ich einen 7 Mhz Quarz drin. Auch bei mir wird der EEPROM anscheinend nicht korrekt ausgelesen. Die MAC bleibt 00:00:00:00:00:00. Ich habe nochmal am Rechner nachgeprüft: die Einstellungen der NIC scheinen alle korrekt zu sein jumperless, IRQ 9 etc. Das DOS-Tool zeigt die MAC der Karte auch an. Bloss eben im Webserver selber nicht. Im Hyperterminal kann ich alles bis zum Initalisieren der Cam mitlesen. aber anpingen geht nicht. Ich habe noch eine 2. NIC ausprobiert, wo ich allerdings das EEPROM entfernen musste, weil sonst nicht der IRQ-9 gewählt werden konnte. Mit der habe ich genau das gleiche Problem. Die Act-LED leuchtet bei Pings sogar, aber mehr auch nicht. Ideen? Joachim, gäbe es nicht die Möglichkeit irgendeine statische IP vorzugeben wie bei Holgers Version, falls das EEPROM nicht ausgelesen werden kann ? Gruß smiler
Hallo,
bei mir funktioniert der Webserver mit Cam und Temperaturmessung
sehr gut im Kabel- Netzwerk sobald ich in aber aus dem W-Lan
anspreche fangen die Probleme an, und er hängt sich auf .
Liege ich richtig, das dies die Folge des nicht vollständig
Implementierten TCP- Stacks ist, wodurch keine automatische
Paketwiederholung erfolgt ?
Hat es schon jemand geschafft über eine W-LAN Bridge diesen
Webserver zu betreiben ?
Ich bräuchte ein Webserver der auch mit einer bestehenden Wlan Bridge
von 1,4 Km zurecht kommt (Good Packets / Dropped Packets ca. 100/1)
Danke für eine Antwort
Gruß Hans
@ smiler
- - > allerdings habe ich einen 7 Mhz Quarz drin
du meinst aber sicher 7,3728 sonst klappt das mit der
Initalisieren der Cam nicht und der Wepserver hängt.
- - > IP vorzugeben
in der Main.c Zeile 41 gibst du mit :
unsigned char MYIP[] = {192,168,99,199};
die erste Adresse vor, diese wird auch verwendet wen kein Eeprom auf
der Netzwerkkarte mehr vorhanden ist .
Zumindest ist das bei mir so
Kann mir jemand zum testen ein hexfile mit 16 MHz ohne alles(keine kam...) compilieren? Vielen Dank
- - > 123 Da bei 16 Mhz aber weder die Cam noch der One-Wire-Bus funktioniert hat die Version von Joachim eigentlich für dich doch wenig Sinn. Für ohne alles ist die Version von Holger doch O.K. oder was meinst du mit ohne alles ? Joachim Version macht nur Sinn mit : 14745600, 11059200 oder 7372800
- - - > 123 One-Wire-Bus geht wohl doch noch mit 16 Mhz Hier eine 16Mhz Testversion Ohne Cam aber mit One-Wire-Bus Start IP 192.168.2.66
vielen Dank für den code, leider geht er auch nicht. muss ein 1-wire-Sensor angeschlossen sein oder geht es auch ohne? Die Ausgabe auf der seriellen sieht aus wie immer nur die ip ist natürlich anderst. Hab nochmals Holgers code getestet der geht einwandfrei, also an der Hw kann es nicht liegen.
---> muss ein 1-wire-Sensor angeschlossen sein oder geht es auch ohne? muss nicht angeschlossen sein geht auch ohne . Ist dein Rechner in der selben IP Gruppe ? (192.168.2.xx) Stecker vom Programmadapter abgezogen ?
Vielen dank der Tipp mit der IP Gruppe war ein Volltreffer!! Aber warum??
Hallo, @ Joachim ich wollte moch mal auf die Geschichte mit der Heizungssteuerung kommen und fragen, ob mal nicht ein anderen Prozessor benutzen kann um diesen dann an den 1 wire Bus, als slave anzuschließen, und die freien Ports des µc als Ausgangsport zu benutzen um damit wiederum die Stellmotoren zu steuern. Gruß Peppe
Hallo Smiler, im Programm ist eine statische IP-Adresse vorgesehen. Die wird nur dann überschrieben, wenn im AVR-EEPROM eine IP-Adresse mit gültiger Prüfsumme steht. Hallo Peppe, der one-wire-slave in Software ist ein interessantes Projekt. Zur Relaisansteuerung erscheint mir das inzwischen sinnvoller als der DS2408. Ich habe da aber noch nichts realisiert. Dein Link zu den Funksteckdosen hat mich dazu gebracht, für 9,99 ein Set mit drei Funksteckdosen und einer Fernbedienung zu kaufen (siehe Bild). Von der Fernbedienung habe ich eine zweiadrige Leitung zu meinem AVR-Webserver gelegt. Nun kann ich die Fernbedienung, bei Erhaltung aller Funktionen, dazu veranlassen, jeden möglichen Code zu senden. Ich muß nur noch etwas an der Bedienerschnittstelle und der Doku machen. Die Steckdosen haben einen sehr schlechten Empfänger. Wenn die Teile zu nah beieinander sind, beeinflussen sich die Empfänger gegenseitig. Die Chinesen haben offensichtlich eine Empfängerschaltung aus der Anfangszeit der Röhrentechnik verwendet. Inzwischen gibt es eine Ausgangsschaltstufe, die per I2C-Bus vom Webserver angesteuert werden kann. Die Leiterplatte kann zwar nicht so weit vom Server abgesetzt werden, ist aber offensichtlich bereits fertig. http://www.mikrocontroller.net/forum/read-4-306681.html#new Gruß Joachim
Angehängte Dateien:
-
Zuschnitt5246klein.JPG
160 KB
Hallo Peppe, hier die Steckdosen. Der Encoder im Sender ist übrigens ein 2262. Gruß Joachim
Hi Joachim, ich habe die selben Steckdosen, das mit der Empfangsqualität kann ich nur bestätigen, ist echt mieserabel. Ich habe auch schon die Ansteuerung fertig um den 2262 anzusteuern. man kann den Schlatplan von der Homepage die ich mal gepostet habe nicht 1 zu 1 übernehmen, da der 2262 noch ein extra pin besitzt für send enabel und diese Steckdosen nicht auf low sondern auf high reagieren , oder anders herum, weiß ich nicht mehr so genau? hat mich aufjedenfall ein ganzen Samstagabend gekostet bis ich das herausgefunden hatte... Habe dann das Programm für den At so belassen und die Ports mit hilfe von Transistoren invertiert. Ich habe zwar den Source von Mistercrd erhalten, allerdings ist der in Assembler geschrieben und da habe ich noch gar keine Ahnung von. Naja wird sich nächstes Semester ändern... Was nicht so glücklich an der Lösung ist, dass man keine Rückmeldung über den Schaltzustand erhält und das wäre meiner Meinung nach sehr wichtig, gerade weil die Dinger so unzuverlässig schalten... Wäre trotzdem an deiner Lösung interessiert. Gruß und schönen Sonntag Peppe
Hallo Peppe, der Fernsteuersender arbeitet im Ein-/Aus-Betrieb. Wenn die Ausgangsleitung des 2262 low ist, wird nicht gesendet, bei high wird gesendet. Der Ausgang des 2262 wird über 15k auf den Sender geschaltet. Ich schalte mit dem Ausgangsport eine 12V-Leitung über 15k und eine Diode ebenfalls auf den Sender. Das erfordert am Prozessor nur eine Portleitung, dazu noch zwei Transistoren, einige Widerstände und besagte Diode. Ich wiederhole das Datentelegramm jeweils 6 mal. Das hat bisher gut funktioniert. Den Code stelle ich noch zur Verfügung. Gruß Joachim
Hallo Joachim, was fällt dir zu meinem Problem (weiter oben) ein ? TCP- Stacks / W-Lan /Paketwiederholung Danke .... HH
Hallo Hans, der Webserver braucht unbedingt fehlerfreie Ethernet-Verbindungen, da keine Paketwiederholungen vorgesehen sind. Um das zu realisieren. müßte man den TCP/IP-Stack erweitern oder austauschen. Hier: http://www.mikrocontroller.net/forum/read-4-251170.html#313204 gibt es eine Portierung von uIP. In der Portierung ist zwar die Paketwiederholung noch nicht eingebaut, es gibt aber Quellen dafür. Gruß Joachim
Hallo,
nachdem mein Webserver, ohne Cam, schon einmal lief, habe ich mir jetzt
eine Cam besorgt und angeschlossen.
Leiser kann ich keine LAN Verbindung mehr aufbauen.
Ein ping geht auch ins leere.
Über den seriellen Anschluss erhalte ich die folgende Meldung:
93LC46 Dump:
00 01 02 03 04 05 06 07 - 08 09 0A 0B 0C 0D 0E 0F
0000: 90 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
................
0010: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
................
0020: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
................
0030: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
................
0040: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
................
0050: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
................
0060: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
................
0070: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
................
RTL8019AS: Okay 34
MAC: 00:00:00:00:00:00
IP : 192.168.99.199
EEPROM Dump:
00 01 02 03 04 05 06 07 - 08 09 0A 0B 0C 0D 0E 0F
0000: FF FF FF FF FF FF FF FF - FF FF FF FF FF FF FF FF
................
0010: FF FF FF FF FF FF FF FF - FF FF FF FF FF FF FF FF
................
0020: FF FF FF FF FF FF FF FF - FF FF FF FF FF FF FF FF
................
0030: FF FF FF FF FF FF FF FF - FF FF FF FF FF FF FF FF
................
0040: FF FF FF FF FF FF FF FF - FF FF FF FF FF FF FF FF
................
0050: FF FF FF FF FF FF FF FF - FF FF FF FF FF FF FF FF
................
0060: FF FF FF FF FF FF FF FF - FF FF FF FF FF FF FF FF
................
0070: FF FF FF FF FF FF FF FF - FF FF FF FF FF FF FF FF
................
MCA-25:
Die IP meines PC's ist die 192.168.99.10.
Liegt es an der fehlenden MAC Adresse?
Kann mir jemand helfen?
Tobias
Hallo, ich habe jetzt unter mca25.h die Camera auf 0 gesetzt. Jetzt kann ich den Webserver weder erreichen. Woran kann das liegen. Ist di eKamera defekt? Tobias
wenn die cam nicht geht bleibt der sever hängen s.h. post weister oben.
ich hatte das gleiche problem. bei mir war die stromversorgung zu schwach. mal mit dem oszi nachmessen. gruss ecki
@elkokiller Hallo Tobias, Die "00" im 93LC46-Dump zeigen, das das EEPROM auf der Netzwerkkarte fehlt, vom AVR nicht gelesen wird oder komplett mit "00" gefüllt ist, oder.... Der EEPROM Dump zeigt, daß noch kein one-wire Chip gelesen wurde und die IP-Adresse noch nicht verstellt wurde. Das AVR-EEPROM ist noch unprogrammiert. Gruß Joachim
Bei mir läuft der Webserver mit der mca25 nur wenige Minuten, dann "hängt" er sich auf. Ich hab einen WD eingebaut aber das ist nur eine Notlösung. Hat jemand eine Idee warum der Serverbetrieb so instabil werden kann? Gruß Eckard
Ich habe inzwischen das Fernsteuern von Funksteckdosen ergänzt. Die Beschreibung und die Software habe ich auf meiner Webseite abgelegt. avr.börke.de Wer das mit dem Umlaut nicht hinbekommt: börke=xn--brke-5qa Gruß Joachim
@ Joachim Hallo Joachim, ich habe gerade deinen Bericht auf deiner Homepage gelesen, mir ist nocht nicht ganz klar wie du jetzt die Fernsteuerung ansteuerst. Verbindest du PB 4 direkt mit dem Sender ( und Ground natürlich) oder verwendest du noch ein Transistor als Schaltstufe. Ein kleiner Schaltplan wäre recht Hilfreich. hast du auch schon eine Grafische Oberfläche zum Webserver geschrieben. Gruß Peppe
Hallo, ich bin es noch mal , wer lesen kann ist klar im Vorteil, hatte es ganz überlesen, das du es mir schon mal grob geschildert hattest. wie du den Senderbaustein ansteuerst. Leistungstreiber am At port und ab auf den Sender... Hast du die Software schon beim Webserver implementiert? Gruß Peppe
Hallo Peppe, mit dem Portsignal schalte ich einen npn-Transistor, der einen pnp-Transistor an 12 V schaltet. +5V am Eingang ergibt dann +12V am Ausgang. Eine Schaltskizze folgt noch. Ich habe schon alles im Webserver integriert. Ich werde nächstes Wochenende das Quelltextpaket fertig haben. Gruß Joachim
Hallo Joachim, gehe mal davon aus dass du den zweite Transistor zur doppelten negation benutzt. Ich habe in deiner Source gelesen dass der Quelltext für 14,... Mhz ausgelegt ist. kann ich das über das Teilerverhältniss am ende deines Quelltextes ändern? Oder passt dann die gesamte Bitfolge nicht mehr? Wo und was hast du studiert, also welche Fachrichtung? Ich bin jetzt im vierten Semester an der Fh Münster engeschrieben. Und höre gerade Mikroprozessortechnik, sind aber noch ganz am Anfang und somit basiert mein Wissen noch hauptsächlich auf dem was ich hier so lese. Wäre alles ein bisschen einfacher wenn ich schon weiter währe. Schon einmal danke für die viele Arbeit die Du dir machst. Gruß Peppe
Hallo Peppe, ich habe die Pulserzeugung auf eine Warteschleife zurückgeführt, die etwa 370us dauert. Alle anderen Abhängigkeiten erzeugt das Programm. Du mußt bei einer anderen Taktfrequenz nur diese eine Schleife anpassen. Den Rechengang habe ich hoffentlich verständlich beschrieben. Das Schaltbild habe ich auf meiner Webseite eingefügt. Wenn das Ausgangssignal low ist, dann fließt kein Strom auf der 12V-Schiene, so dass man die 12 V auch aus der Batterie nehmen könnte. Wenn meine Batterie leer ist, werde ich die Versorgungsspannung der Fernbedienung aus dem Webserver nehmen. Ich habe Elektrotechnik / Fachrichtung Informationstechnik an der FH Hannover studiert. Gruß Joachim
Hallo Joachim, in deiner Source zur Warteschleifen erzeugung multiplizierst du die 14 mit 370. Jetzt sehe ich gerade den Wald vor lauter Bäumen nicht. Steht die 14 jetzt für 14 MHZ , demnach müßte ich wenn ich mit 4 Mhz Takt arbeite ,dann den Wert für 4 * 370 eintragen. Gruß Peppe
Hallo Peppe, bei 14 MHz bekommt der Prozessor 14 Takte pro us. Bei 370 us habe ich deshalb 14 Takte/us * 370 us = 5180 Takte. Gruß Joachim
Hallo Joachim Börke, ich habe bei der Heizungssteuerung mit den Dallas-Sensoren oft das Problem, dass die Werte nicht korrekt angezeigt werden (Differenz bis zu 3-5 Grad im Vergleich zu den originalen Heizungs-Sensoren). Die DS1820 sind m.E. sehr gut, um Luft oder Flüssigkeiten zu messen, allerdings sind sie nur bedingt geeignet als Anlegesensor, um z.B. von einem Rücklauf (Kupferrohr) die genaue Temperatur zu ermitteln. Trotzt dicker Isolierung der Sensoren. Oder hast Du die Sensoren in einer Tauchhülse direkt "ins Wasser getaucht" ? Gruss, Pete
Hallo Pete, mit der Ansprechverzögerung der Sensoren kann ich gut leben. Ich befestige den Sensor (PR35-Gehäuse) mit Gewebeklebeband auf dem Rohr. Die flache Seite liegt dabei am Rohr. Dann kommt die Isolierung darüber, und sorgt dafür, daß der Sensor praktisch immer die Rohrtemperatur hat. Man könnte den Wärmeübergang noch etwas verbessern, wenn man die Wärme in den mittleren Pin einleiten würde. Bei Dallas gibt es einen Applikationsbericht dazu. Mit einer Tauchhülse kommt man besser an Temperaturen innerhalb des Kessels. Wenn aber keine freie Tauchhülse vorhanden ist, muß die Lösung entfallen. Mit Wärmeleitpaste kann man sicher auch noch etwas verbessern. Gruß Joachim
Hallo Joachim ich habe inzwischen díe Sendertreiberstufe gebaut und mich mal daran gesetzt den Source von Dir in die Source des Webservers einzupflegen. Leider funktioniert es nicht richtig. Ich kann zwar auf dem Webserver aktionen ausführen,diese werden auch wohl übernommen, glaube ich, aber die Steckdosen schalten nicht. ich habe den Ausgang PB4 vom webserver genommen, so wie es aussieht spreche ich diesen auch an, wenn ich mein Skop an den Ausgang anschliese und auf einstellung setzten klicke(auf dem Webinterface) sehe ich, dass am PB4 Daten ankommen. Leider habe ich kein Speicherskop und kann somit nicht sehen was da genau rauskommt. Die Verstärkerstufe funktioniert auch, die Fernbedienung sowieso. Was ich mir vorstellen könnte wäre falsche Anpassung der Funk.S meiner seits, ich habe ein 11,1 MHz Quarz an dem Webserver und ich habe die Zyklenberechnung auf 1015 gesetzt, ist das richtig? Die Anzahl wie oft ein Paket gesendet wird, wurde von Dir mit der Variablen Var übergeben, ich habe es fest auf 6 gesetzt: anstelle von: lds r22,VAr habe ich dann ldi r22, 6 in den Quelltext geschrieben. Ich hoffe das ist richtig, ich habe es so verstanden, dass der Inhalt von VAr in das Register R22 geschrieben wird, folglich setzte ich mit Ldi, ins R22 die Konstante 6. Könntest du bitte mal in ein Blick in meine Source verfen und mal schauen, was da flasch ist. Vielen Dank Lg Peppe
Hallo Peppe, die Hardware läßt sich einfach prüfen. Dazu betätigt man eine Taste auf der Fernsteuerung und beobachtet die LED der Fernsteuerung. Anschließend löst man ein Telegram vom Server aus. Die LED muß nun für die Dauer des Telegramms etwa mit der gleichen Helligkeit leuchten. Die Berechnung des Zählerwertes mit 1015 ist nachvollziehbar. In meinem Kommentar steht 14 Zyklen/MHz. Das muß heißen 14 Zyklen/us. Da das Toleranzfenster für den Signalempfang recht groß ist, habe ich bei 14,75.. MHz mit 14 gerechnet. Damit liegen meine Zeiten ca. 5% unter Deinen. Wichtig ist, daß das Sendeprogramm nicht durch einen Interrupt unterbrochen wird und das der eingestellte Code stimmt! In dem Einschub in webpage.c ist m.E. noch ein Fehler in der Zeile für Steckdose E. Wenn Du anstelle der Variablen VAr eine Konstante 6 vorsiehst, sollte das unproblematisch sein. Gruß Joachim
Danke für die rasche Antwort, den Feher in der Webpage.c habe ich schon gefunden gehabt. Ich bin noch nicht so ganz hinter deine Adressierung gestiegen. 0x10,0x05,0x51 das dritte Byte (0x51 bzw 0x54) steht für ein und aus, demnach steht das Erste für die Adresse und das Zweite für die Dose. Sehe ich das richtig, das ich einfach von hex in Bin umrechnen muß, für die einzelnen Schalterstellungen in den Steckdosen? Also die Hardware passt, das konnte ich mit meinem Skop nachmessen, leider kann ich die Pakete nicht vergleichen, die der µc und der 2262 schicken. Hast du noch eine Idee woran es liegen könnte. Was mich wundert, wenn ich die Hacken am Webserver nicht verändere, und auf Einstellung übernehme klicke, dass dann der Webserver trotzdem irgendwas raus schickt, was ja eigentlich nicht sein dürfte. Gruß Peppe
Hallo Peppe, Details zur Dekodierung kannst Du hier nachlesen: avr.xn--brke-5qa.de/Funksteckdosen.htm Es werden 12 "BITS" übertragen. Jedes dieser "BITS" hat drei Zustände, die als 00, 01 und 11 abgebildet werden. So kommt man auf 24 Bit, die in drei aufeinanderfolgenden Byte abgelegt sind. Die ersten 10 Bit werden mit den DIL-Schaltern eingestellt. Die folgenden 10 Bit legen die Steckdose (A..E) fest und die verbleibenden 4 Bit dienen zum Ein- bzw. Ausschalten. DIL-Schalter und Steckdosenkennung bewegen sich also über die Bytegrenzen hinweg. Nur die letzten 4 Bit sind einfach zuzuordnen (Ein = x1, Aus = x4). Falls das Timing, das nur durch Widerstände festgelegt wird, nicht ganz stimmt, könnte man durch Änderung um 5-10% evtl. Erfolg haben. Das Problem mit dem Webserver sehe ich mir in deinen Quellen noch einmal an. Gruß Joachim
Hallo Joachim, danke für die Erklärung, das mit der Adressierung ist mir jetzt klar. Der Sender funktioniert jetzt, ich habe einen 14 Mhz Qurz eingelötet und die Source dahingehend wieder geändert, damit klappt es sehr gut. Die Antenne die in dem Teil verbaut ist habe ich rausgeschmissen und dafür eine Teleskop Antenne angeschlossen, diese habe ich nun auf ca. Lambda halbe eingestellt, die Reichweite ist jetzt viel besser.Werde morgen abend mal ein wenig mehr damit testen... Leider ist irgendwie noch der wurm in meiner Webpage.c drin. Die Einstellungen kann ich nur einmal ändern und muß dann erst auf ein anderen "Einstellung setzten" Button klicken damit ich die nächste Aktin tätigen kann. Kann ich eigentlich mit der "alten Source" dynamische Html seiten auf der mmc karte ablegen? den so ist es doch ein wenig umständlich immer gleich den gesammten µc neu zu flashen wenn man mal eine Funktion hinzufügen will, oder geht das erst mit der V1.40? Noch mal vielen Dank für dein Bemühen. Gruß Peppe
Hallo Peppe, das mit der Antenne ist eine gute Idee. Eine etwas höhere Reichweite könnte ich auch gebrauchen. Der 1.38-Source interpretiert die HTML-Seiten von der MMC-Karte nicht. Deshalb lassen sich dort nur statische Seiten ablegen. Das von Dir geschilderte Problem hatte ich auch schon. Es ist darauf zurückzuführen, dass die Variablen im Empfangspuffer nur unzureichend gescannt werden. Da mit jedem HTML-request auch die aufrufende Seite mit den dann überholten Parametern genannt wird, wird der Parameter zwar im Aufruf korrekt angegeben, gescannt wird jedoch der überholte Parameter aus der aufrufenden Seite. In meinem aktuellen Quellcode ist das beseitigt. Ich muß jedoch noch ein Stabilitätsproblem lösen, bevor ich die neue Version verbreite. Gruß Joachim
Hallo Joachim, Also meine Erfahrung mit der Antenne ist bombig, der Server steht im Erdgeschoss und ich kann damit im Gesamten Haus die Dosen schalten ( ca, 100 m^2 Pro Etage. Auch die Lampen im Garten sind erreichbar.ich habe die AM - Platine von der Platine abgelötet und in ein Sub - D 9 gehäuse gebaut, daran die Antenne und von ausen ans Gehäuse. Wenn ich die SOftware soweit fertig habe wie ich das möchte wollte ich mich daran machen noch ein Display mit anzubinden, das will ich dann aber über ein Atmega-8 ansteuern, die Daten soll es dann über den Uart bekommen, oder über den I2c Bus. Weißt du ob schon jemand software für Can Bus geschrieben hat, bezüglich Leitungslänge... Gruß Peppe
Hallo Joachim, ich habe mich noch ein wenig mit dem Webserver auseinander gesetzt und ein wenig rum programmiert. Ich habe nun eine seperate Seite eingepflegt und noch mehr Ports hinzugefügt. Jetzt habe ich mal wieder ein kleines Problem, wenn ich zuviel in der httpd.c stehen habe, treten merkwürdige dinge auf. 1. Die Zustände der Checkboxen werden nicht mehr gespeicheter 2. Die html seiten werden nicht mehr richig übertragen, dies äussert sich so, dass der Webserver dieverse Daten nicht mehr überträgt, wie z.B. agline = center und die Hintergrundfarbe. Muß man noch irgendwas erweitern oder eine Variable vergrößern?? Gruß Peppe P.s. Die Hintergrundfarbe habe ich auf blau gesetzt, weil ich sehen wollte ob mein I-Exlporer die Seiten aus dem Cache holt oder die wirklich neu lädt....
Angehängte Dateien:
-
Uhrzeit.PNG
414 Bytes
Hallo,
ich habe die Quellen von Joachim Börke (1.38-04) auf dem ISA-Ctrl-Board
(vorerst ohne weitere externe Hardware) am Laufen und nun folgendes
Problem:
Wenn ich auf die Seite "Einstellungen" im Browser anwähle, erscheint die
Maske zur Eingabe der Uhrzeit wie im Anhang.
Jetzt habe ich testweise mal in webpage.c in Page4[]= die Zeile der
Stunde ("2 name=VAh size=2 value=%VAh") in "2 name=VAh size=2
value=%VAm" (also Minuten) geändert. Dann wird die Eingabemaske
prinzipiell richtig (natürlich mit den falschen Daten) angezeigt.
Was läuft hier schief?
Hallo Friedhelm, ich führe das Problem auf Schwierigkeiten mit dem Interupt-System zurück. Bei minimalen Änderungen an anderen Stellen im HTML-Code treten gelegentlich auch unerklärliche Fehler auf. Ich bin dabei, den TCP/IP-Stack gegen uiP zu tauschen. Damit läuft das ganze deutlich stabiler und es wird praktisch kein Interupt benötigt. Gruß Joachim
Hallo, ich habe nun den TCP-IP-Stack gegen uip von Adam Dunkels getauscht und noch einige Funktionen hinzugefügt. Die Software läuft auf einem ATmega32 mit 14,7456 MHz. Es jetzt möglich eine oder mehrere Schaltuhren zu definieren und damit Portleitungen oder Funksteckdosen zu schalten. Außerdem können Thermostate definiert werden, die ihre Isttemperatur von einem one-wire-Thermometer erhalten und einen Port oder eine Funksteckdose schalten. Damit bin ich der Heizungssteuerung einen Schritt näher gekommen. Viel Spaß damit. Evtl. hat jemand weitere gute Ideen dazu. Gruß Joachim
Hallo Joachim, das ist echt super! Leider stehe ich ein wenig auf dem Schlauch was die Codierung der Funksteckdosen auf dem Webinterface angeht. Ist das die Abbildung der Dipschalter? Gruß Peppe
Hallo Peppe, ich gebe die 12-Bit-Codierung ein. Das Codierschema mit Beispielen findest Du hier: http://avr.xn--brke-5qa.de/Funksteckdosen.htm Die ersten 10 Bit entsprechen den Codierschalterstellungen. Die beiden letzten Bits dienen zum Ein- bzw. Ausschalten. Wichtig ist, das nur die Zustände "0" und "F" genutzt werden. Das "1"-Signal kommt nicht vor. Für die Düwi-Steckdosen ist das Codierschema etwas anders: http://avr.xn--brke-5qa.de/ARCTECHsteckdosen.htm Gruß Joachim
Hallo Peppe, ich habe noch eine Bedienungsanleitung hinzugefügt und die Ermittlung des Schaltcodes noch einmal ausführlicher erläutert. http://avr.xn--brke-5qa.de/E-Funk.htm Gruß Joachim
Hallo, ich habe gerade mein ISA_Ctrl v1.0 wieder entdeckt und wollte gerne anfangen mir daraus eine kleine Wetterstation zu bauen. Habe mich hier schon ein bißchen eingelesen. Aber was sich so in 2 Jahren alles geändert hat das ist echt zu viel. Deswegen hoffe ich das mich hier einer mal auf den neusten Stand bringt. Also meine Fragen. 1. Ich möchte den ISA-Ctrl bei mir gerne wieder beleben. Er soll möglichst viel können. Lohnt sich der Umstieg auf den Atmega 644? Wenn ja welche Änderungen an Platine und so muss ich vornehmen? 2. Wenn ich mehrer Temperatursensoren anschliessen will was brauche ich dafür für Hardware? ( Frage so genau weil ich nur gerne 1x mal bei Reichelt bestellen wollte) 3. Ich möchte gerne vernünftige Temperaturmessungen machen sollte ich da auf diese 1-wire Technik einsteigen? Wenn ja wie? Cu kami
Hallo Stefan, zu Deinen Fragen: 1. Der ATmega644 ist pinkompatibel zum ATmega32. An der Leiterplatte sind deshalb keine Änderungen erforderlich. Der ATmega644 kann jedoch (noch) nicht mit Ponyprog programmiert werden. Es gibt aber andere Lösungen die bereits beschrieben sind. Die Version 1.40 der Webserversoftware erfordert den ATmega zwingend. Die Software in diesem Thread läuft bis jetzt noch auf einem ATmega32. 2. Bezogen auf die Software aus diesem Thread wird für jede Meßstelle ein DS1820-Thermometer benötigt (DS1820, DS18S20, DS18B20 etc.). An einer Busleitung werden mehrere Thermometer parallel angeschlossen. Jede Busleitung benötigt einen Pullup-Widerstand. Drei Busleitungen werden von der Software unterstützt. 3. Was verstehst Du unter vernünftig? Ich halte es für vernünftig, die Temperatur an der jeweiligen Meßstelle zu digitalisieren und dann alle Werte digital über einen Bus zu übertragen. Die Genauigkeit, die Auflösung und der Temperaturbereich der DS18[x]20 reicht mir dabei aus. Der Einstieg ist einfach. Leitung legen, Sensor anschließen, Pullup verschalten. Gruß Joachim
Hallo Joachim, ich habe mich gestern auch mal wieder mit dem Webserver beschäftigt. Das hast du echt mal richtig gut hinbekommen. Ich hatte das mit den Objekten erst nicht ganz verstanden aber dann habe ich deine Anleitung gefunden und dann hats funktioniert. Echt super. Ich muß mir noch ein passenden Quarz besorgen, mit 14.0 MHZ läuft das nicht so wirklich gut. Mal schauen wie schnell Reichelt liefert... Wie ausgelastet ist der Server mit dem Ausbau (Funk, ds1820, und Dcf77). schön wäre noch ein Rückkanal über die Fstd Fernbedienung. Stelle mir das so vor das man den Empfangsteil einer Steckdose benutzt an den Atmega anschliest und der die Schaltbefehle auswertet und weiter leitet... Da ja nicht immer ein Pc läuft wäre man man ein wenig unabhängiger und hätte trotdem immer den aktuellen Zustand der Aktoren im Webinterface. Viele Grüße Peppe
Hallo Joachim, Also ich habe nun meine Kamera voll im Betrieb klappt alles super Controller läuft auch sehr stabil. Habe mir nun 2 DS18S20 geholt und den DQ Pin mit DQ4 verbunden und den GND Pin mit GND. Benutze deinen Sourcecode 060118_Source1.38_jb04.zip und habe nur als Änderungen die Taktrate auf 7,372800 Mhz eingestellt da ich keinen anderen passenden Quarz mehr habe. Leider kriege ich gar keine Rückmeldung von den Dallas Sensoren ich habe schon einen 1 kOhm Widerstand, 3,3 kOhm und 4,7 Ohm getestet. Keine Abhilfe es wird mir auf meiner Website nix angezeigt nicht mal eine Seriennummer. Wie kann ich das lösen? Wäre klasse wenn du oder jemand mir helfen könnte. Weiß nicht weiter. Vielen Dank Cu Stefan
Hallo Stefan, auf der Einstellungsseite kann man die Busleitungen einzeln Ein-/ bzw. Ausschalten. An dem entsprechenden Auswahlfeld muß ein Haken sein. Die Widerstände im Bereich von 1k bis 4k7 sollten ausreichen. Ist der DS18S20 richtig angeschlossen? Die Version 04 ist nicht mehr aktuell. Nimm besser die Version 05: http://www.mikrocontroller.net/attachment/22318/070409_Source0.90_jb05.zip Gruß Joachim
Hi Danke für die Antwort. Wie sollte ich den die Widerstände dimensionieren ist das egal was ich da zwischen 1-4,7kOhm nehme? In Einstellungen ist bei allen 3 Feldern ein Haken. Wie finde ich den die Seriennummer? oder zeigt er die automatisch unter Temperaturen anzeigen und dann #01 an? Kann man den DS18S20 irgendwie falsch anschliessen? Kann ich den die neue Software mit einem 7,327 Mhz Quarz betreiben? Bis jetzt hat der dann nie gestartet? Muss ich irgendwas im Quellcode aktivieren wenn ich die DS18S20 einsetze? Cu Stefan
Hi so mal eben zum aktuellen Stand. Also ich habe einen 14,74 Quarz jetzt eingebaut und einen 1 kOhm zwischen dem One-Wire Ports. Außerdem habe ich deine aktuellste Version jb05 aufgespielt. Ohne Änderung direkt das HEX File. Ich kann die Hauptseite s.htm sehen wenn ich die IP 192.168.99.98 aufrufe. Aber ich kann nicht die Linke Menü seite sehen die baut er einfach nicht auf. Wenn ich die Datei cam.jpg direkt öffne kriege ich ein Bild der Webcam. Mehr klappt aber auch nicht. Ich habe dann ein paar ältere Version von deiner Software getestet und dabei festgestellt das ich manchmal die Seriennummer der DS18S20 angezeigt kriege einmal hatte ich sogar eine Temperatur von 85 °C aber nur sehr kurz. Ich weiß nicht woran es liegt das das ganze so schlecht läuft. Vielleicht kannst du mir ja einen Tipp geben. Habe außerdem keine Funkuhr oder sonst noch irgendwas außer Cam und einem DS18S20 angeschlossen. Cu Stefan
Hallo Stefan, ich würde zuerst die Fuses, die Betriebsspannung und die Beschaltung des Resetanschlusses prüfen. (Die Kamera braucht u. U. recht viel Strom) Weitere Seiten in der Version 05 können mit c.htm, t.htm und s.htm aufgerufen werden. Die Uhr läuft auf Quarzbasis, solange kein DCF-Signal vorliegt. Damit kann man prüfen, ob der Quarz auf einer konstanten Frequenz schwingt. Hat die Netzwerkkarte einen RTL8019 Chip (ideal) oder ist dort etwas anderes verbaut? Wird die MAC-Adresse aus der Netzwerkkarte gelesen? Gruß Joachim
@ Joachim Börke hast du msn messenger? hasis55 ät hotmail punkt com
Moin Joachim, Mit den Fuses meinst du doch die Fuse-Bits in PonyProg oder? Wie sollen die den eingestellt werden? Ich nutze dafür so ein kleines Netzteil von Pollin wieviel Volt/Ampere sollte ich den haben? Die Kamera läuft ja 100% nur die Temperatursensoren kriege ich nicht angemeldet. Muss ich also das DCF nicht abschalten? Die Netzwerkkarte hat einen RTL8019 Chip sollte also klappen, und die MAC-Adresse habe ich auch nicht anders eingestellt sollte also von der Karte geholt werden. Frage ist nun wie kriege ich die Temperatursensoren angemeldet. und warum baut sich bei deiner 05 version nicht der rechte Teil auf? Cu Stefan
Hi also noch mal zusätzlich zu dem Netzteil. Das hat als Ausgang: 1,5/3/4,5/6/7,5/9/12 V bei 0,5 A reicht das für Temperatur und Cam ? Cu Stefan
JoachimB wrote: > Der ATmega644 kann jedoch > (noch) nicht mit Ponyprog programmiert werden. Wenn ich mal kurz einmischen darf... Die Version vom Mai diesem Jahres, hat sehr wohl den 644 in der Deviceliste....
nochmal kleine aktuallisierung also Webcam und Temperatursensoren laufen jetzt aber nur mit deiner Version 04. Die 05 kriege ich nicht zum Laufen. Vielleicht kannste mir dabei ja weiterhelfen? Cu Stefan
ich sitz auch schon den ganzen tag hier und versuch raus zu bekommen was nach dem interrupt vom rtl geschehen soll welches register zu lesen ist um an die daten zu kommen. Hab mir ulrichs code schon zieg mal durch gesehen ebenso andere wie vom web51 usw nur werd einfach nicht schlau daraus
Hallo Stefan, die Fuses CKOPT und EESAVE sollten programmiert (d.h. auf „0“ gesetzt) sein. Das Anmelden der Dallasbausteine geht automatisch. Jede vom Programm erkannte Dallasseriennummer wird im Flash gespeichert. Das Netzteil mit 500 mA sollte ausreichen. Ich erinnere mich, dass der Betriebsstrom der Kamera höher ist als der Strombedarf der übrigen Schaltung (stand in einem der Threads). Falls die Kamera Spannungseinbrüche erzeugt, könnte das zu ähnlichen Fehlern führen. @ Holger: vielen Dank für die Information. Das erleichert den Umstieg auf den 644 sehr. @ commtel Aus den Quellcodes auf die Architektur des NIC schließen zu wollen ist sicher nicht einfach. Der RTL8019 ist m.E. unzureichend beschrieben. Zu den NE2000 - Karten gibt es auch nur unzureichende Informationen. Such doch einmal nach "DP8390". Der Chip ist ebenfalls NE2000 - kompatibel und es gibt gute Dokumentationen dafür. Gruß Joachim
Moin Joachim, danke schön für die Antwort Wie gesagt die Temperatursensoren und das alles klappt auch die Webcam läuft super. Halt nur deine neue Version 05 läuft nicht bei mir. Da lädt der sich beim Aufbau der Seite immer tot und die Temperatursensoren findet er auch nicht. Kann ich als Ansteuerung für Funksteckdosen jedes Modell nehmen? Praktiker hat ab morgen nämlich ein Set für 6,99 oder gehen nur die auf deiner Seite? Cu Stefan
Hallo Stefan, die Funksteckdosen werden meistens auf 433 MHz angesprochen, unterscheiden sich aber im Ansteuercode. Wenn Du Modelle nutzt, die anders angesteuert werden, empfiehlt es sich den Code auszulesen (ich habe das mit einem Funkgong gemacht und beschrieben). Wenn die Pulslängen stimmen und es sich um einen Code mit 24 Daten- und einem Syncbit handelt lassen sich die Codes vom Webserver erzeugen. Andernfalls muß das Programm erweitert werden. Gruß Joachim Ich verwende zum Ansehen der Seite einen IE version 6 unter Win98. Was verwendest Du?
Hi ich verwende Firefox unter WinXP. Ich denke ich schaue dann mal lieber das ich eines deiner Funksteckdosen Sets auftreibe. Das andere wird mir glaube ich zu kompliziert. Sag mal kennst du dich aus mit dem Aufnehmen von Analogen Messwerten (Wie Helligkeitssensor, oder Drehimpulsgeber) kann man das an den Atmega 32/Atmega 644 anschliessen? Gibts dafür Anleitung, weil wenn ich das richtig sehe gibt es von den Dallas-1 wire keine großartigen anderen Sensoren. Ich möchte mir nämlich eine kleine Wetterstation darausbauen. Deswegen wollte ich da gerne noch andere Sensoren anschliessen. Cu Stefan
Ich verwende nur im Webserver nur einen analogen Eingang, mit dem ich das DCF77-Signal einlese. Dadurch kann ich die 1/0-Schwelle einstellbar machen und ein Logiksignal mit einem Hub von ca. 0,75 V sicher auswerten. Im AVR-Tutorial auf dieser Site gibt es dazu ergänzende Infos. Dallas bietet übrigens umfangreiche Beschreibungen zum Thema Wetterstation. Goggle gibt mit den Stichworten "Dallas Wetterstation" bereits reichlich Quellen an. Gruß Joachim BTW: Ich habe gestern eine Pollin Funkfersteuerung für 3,50 erworben. Der Sender ist sicher verwendbar. Die Kodierung habe ich nach Ansehen der Bilder und Ziffern im Datenblatt erst teilweise verstanden. Der Encoder HS1527 von HuaXin birgt noch einige Geheimnisse.
Hi ja da hast du recht. Sehe das jetzt auch das es da gute Seite zu gibt aber auch hier im Forum ist ja schon was zu dem Thema. Nur glaube ich das ich erstmal dabei bleibe einen KTY mir anzeigen zu lassen, weil so einen Drucksensor für 19 € finde ich für den Einstieg zu teuer. Kannst du mir vielleicht sagen, wie man das bestimmt was man da, wie Anschliessen muss und wieviele Analoge Bauteile kann ich an den ATmega 32 überhaupt anschliessen? Das mit deiner Website ist echt komisch, der baut einfach die Sidebar nicht auf die anderen Seite wie c.htm oder t.htm laufen aber. Planst du eigentlich den Softwareumstieg auf den ATmega 644? Die 2 Fuses-Bits muss ich doch in PonyProg setzen (Also Haken dahin machen) oder? Wenn ich die NICHT setze dann kriege ich immer Write successful sonst immer Write failed. Woran kann das liegen? Cu Stefan
Hi falls du noch lust hast könntest du mir weiterhelfen mit dem programmieren des ISA-Ctrl. Vielen Dank Cu Stefan
Hallo Stefan, möchtest du wissen, wieviele Pine noch am Atmega frei sind oder willst du wissen mit welchem strom du den Atmel belasten kannst? Zur Frage nach den freien Pinnen, hier ist der Schaltplan des Webservers da kann man gut drauf erkennen was noch frei ist und was belegt ist. http://mikrocontroller.cco-ev.de/files/ISA-Ctrl_Schaltplan.pdf Zum Thema Stromentnahme, meine ich was von 20 mA im Kopf zu haben, aber da solltest du vorsichtshalber noch mal in die Spec des Atmegas schauen. Hoffe ich konnte Dir helfen, wenn nicht frag einfach nochmal... Gruß Peppe
Hallo Stefan, die Fuse CKOPT muß gesetzt sein, weil die Quarzfrequenz bei 14 MHz liegt. Weitere Details dazu findest Du im ATmega32 Datenblatt. Die Fuse EESAVE macht das Leben leichter, weil beim Neuprogrammieren das EEPROM nicht gelöscht wird. (Im EEPROM speichere ich die Dallas-Bausteindaten). Ich programmiere über die serielle Schnittstelle mit Ponyprog. Du mußt dein Programmierverfahren so in den Griff kriegen, dass Du die Fuses setzen kannst. (Evtl. Software kalibrieren?) Da der ATmega32 nun nahezu voll ist, werde ich im nächsten Schritt einen Atmega644 einsetzen. Da Ponyprog den nun auch programmieren kann, wird der Umstieg noch einmal leichter sein. Am ATmega32 bzw. 644 stehen 8 Analogeingänge zur Verfügung. Im Tutorial und im Datenblatt ist das erklärt. Ich habe nicht vor, analoge Peripherie an den Prozessor anzuschließen. Dadurch, dass die 1-wire-Schnittstelle funktioniert, kann ich ausreichend viele Digitalthermometer anschließen. Andere Analoggrößen lassen sich auch über den 1-wire-Bus einlesen (z. B. Druck und Thermoelementspannungen). Relais werde ich auch nicht ansteuern. Mit der Möglichkeit Funksteckdosen zu schalten habe ich eine wesentlich komfortablere Lösung. Ich brauche keine Leitungen zu legen und habe perfekte Netztrennung. Zur Pinbelegung kannst Du einiges in der Anleitung zur Softwareversion 04 nachlesen. Gruß Joachim
Hallo Joachim, Ich habe nun deine Software Version 05 fast stabil zum Laufen gekriegt. Was mich noch stört ist: 1. Ab und Zu überträgt er keine Messwerte von den Temperatursensoren. 2. Das Kamerabild hat in der Version 05 deutlich mehr dicke Balken als in der Version 04 3. Wo kann man den solche Drucksensoren und so finden? 4. Die Fuses setze ich nun richtig aber wie kriege ich einen stabileren Betrieb des ATmega32 hin? Der hat doch noch ab und zu das ich den spannungslos machen muss um den wieder zum Laufen zu kriegen. Vielleicht anderer Quarz? 5. Hast du sonst noch irgendwelche Tipps für den besseren Betrieb? Vielen Dank schon mal für die ganzen Tipps CU Stefan
Der Atmega het einen Reset Pin und auf dem Board ist ein Resettaster vorgesehen, brauchst nicht immer Spannungsfrei machen... Ich habe den Atmega nun seit ca 4 Wochen am stück laufen ohne unterbrechungen. Allerdings habe ich die Cam nicht mit dran. Was den Quarz angeht mußt du schon genau den drin haben den du auch in der Source angegeben hast. Hast du auch die richtigen Kondensatoren am Quarz? Welche du nehemen mußt steht im Datenblatt des Quarzes. Peppe
Hi Zusammen, ich sitze vor den Quellcodes und kriege sie nicht kompiliert. (Das Hexfile der Version (060118_Source1.38_jb04.zip) läuft auf meiner Hardware) Mit dieser Version wollte ich nun an den Sourcen weiterarbeiten, aber leider bringen meine WinAVR Versionen ständig Fehlermeldungen beim Kompilieren. 060118_Source1.38_jb04 Die älteste von 2003 bringt ständig folgende Fehler: 1.) "undefined reference to '_delay_ms'" --- kann ich ja fast nachvollziehen weil delay.h jetzt unter utils/delay.h - aber.... 2.) "undefined reference to 'pgm_read_byte'" und bei allen anderen pgm_read_xxxx aufrufen! ....Meine aktuelle Version WinAVR 20070525 bringt aber die gleichen Meldungen + Fehler bei allen eeprom_write/read_ Aufrufen.... 070409_Source0[1].90_jb05.zip Aus Verzweiflung habe ich dann auch diese Version probiert! Die bringt aber eine andere Meldung: 1.) mca25.c:109: error: conflicting types for 'memcmp_P' --- und bricht ab.. Nun meine beiden Frage: 1) Welche WinAVR Version habt ihr für die entsprechenden Pakete benutzt? Oder sind wirklich noch Fehler in den Quellen? Oder stelle ich mich einfach nur zu blöde an? 2) Auf Joachims inet-Seite mit der Doku steht der Dallas DS18B20 als unterstützt drin - im Quellcode von Source0[1].90_jb05 habe ich aber nur die remaincounter Berechnung für die S-Version gesehen. Oder hab ich nicht genau genug hingeguckt??? Vielen Dank im Voraus für die erleuchtenden Antworten... Thomas Neumann
... und Version 05 mit uIP bringt den Fehler (dafür extra nochmal WinAVR-20060125 installiert) sendmail.c:149: error: structure has no member named `fp' betrifft die Zeile und Folgende if (FileOpen(File_Name, 'r', &(tcp_socket->fp))) Ich glaube jetzt hab ich alle durchprobiert Immernoch ratlos ??? Danke Thomas
Hallo Thomas, die Version 070409_Source0.90_jb05.zip läßt sich mit folgendem Compiler übersetzen: Version des WinAVR-Paketes: WinAVR-20060125 Version des Compilers: avr-gcc (GCC) 3.4.5 Version der Bibliothek : avr-libc 1.4.3 Die Version 060118_Source1.38_jb04 habe ich mit einem Vorgänger bearbeitet. Die von Dir genannten Fehlermeldungen habe ich auch schon bekommen. WinAVR20070525 führt offensichtlich neue umfangreichere Typprüfungen durch. Zu dem von Dir geschilderten Fehler: sendmail.c:149: error: structure has no member named `fp' fällt mir auf, dass es in meinen Sourcen keine Datei "sendmail.c" gibt. Hast Du u. U. die Version 1.40 von H. Buss bearbeitet? Zu den Dallas-Thermometern folgendes: Die Software 070409_Source0.90_jb05.zip unterstützt beide Thermometervarianten. Das findest Du in der Datei OWImain.c in den Abschnitten "Bearbeitung des DS1820 / DS18S20" und "Bearbeitung des DS18B20 / DS1822". Gruß Joachim
Hi Joachim, danke für die schnellen Tips. 0.90 läuft jetzt bzw. läßt sich compilieren :)) Hast ntürlich recht... Version 1.4 war xxxV1_40_IB - hab gerade den Überblick verloren wer IB ist :( Dankeschön Thomas
Hallo, das 1Wire Thema interessiert mich sehr. Leider habe ich nur eine 3Com Netzwerkkarte zur Verfügung. Diese funktioniert mit 1.40 und 1.39 tadellos. Die 1Wire devices sind aber auf Code 1.38 aufgebaut, der wiederum keine 3Com Karten unterstützt(?). Ich verwende einen ATmega644 mit SD-Karte und mca25. Von C habe ich praktisch keine Ahnung, somit sind meine Versuche die OWI sourcen im Code 1.40 einzubauen gescheitert bzw. 1.38 für Unterstütung der 3Com Karte zu kompelieren. Hat einer von euch Profis einen Tip wie ich das angehen sollte? Danke, Gerhard
Hi, ich würde mal sagen, dass du dir erst einmal C aneignen solltest und mit einem kleineren Projekt startest. Das Projekt hier ist nicht gerade etwas für Anfänger. Fang am besten erst einmal an mit einem Controller eine Led zum blinken zu bringen, erst mit einem Delay dann mit einem Timerinterrupt. Tasten abfragen, ganze Register auslesen und beschreiben, einzelne Bits, auslesen beschreiben. Ich weiß ja nicht ob du überhaupt schon mal programmiert hast, wenn nicht, wirst du dir wohl zuerst ein gutes C Buch zulegen müssen und dich mit den Grundlagen vertraut machen. Was sind Funktionen wie werden diese aufgerufen, mit und ohne Rückgabewert. Zeigerarithmetik, Struckturen. Variablen, Variablentypen... Hinzu kommt, die Sourcen sind fertig geschrieben und selbst für jemanden der C im großen und ganzen beherrscht ist es nicht ganz einfach sich in die ganzen Funktionen einzuarbeiten, da vergehen schon mal ein paar Stunden und Tage. Ich will Dich nicht entmutigen, aber das hier ist echt nicht einfach. Den Server in Betrieb zunehmen ist eins, aber an den Sourcen zu schrauben ist ein Thema für sich.
@ Joachim Börke: Hallo Joachim, ich habe auf Deiner Homepage den Hinweis gesehen, dass seitdem die Wetterinfos in die DCF-Daten dekodiert werden, Deine Uhr schlecht synchronisiert. Normalerweise sollte das aber keinen Einfluß haben. Habe ich aber schob öfter gehört, dass das bei DCF-Uhren stört. Nun, ich habe Deinen Source nicht angesehen, aber evtl. wertest Du die ersten 14 Bits mit aus? Ich werte nur die Minutenmarke aus (immer 0) und dann erst ab Bit 15 und natürlich die Parities. Bit 1 bis 14 wandern in den Mülleimer. Habe den Einfluß der Wetterdaten bei mir nicht bemerken können. Weiter habe ich auf Deiner Homepage die Beschreibung der Zustände zum Empfang der Daten gelesen. Fand ich sehr spannend, also erstmal nur das Signal abtasten, wenn es erwartet wird (jede volle Sekunde) und dann nur einmal das Signal 150ms nach der vollen Sekunden abtasten und es dann auszuwerten. Weil ich es ganz klever fand, habe ich solch eine Auswertung mal programmiert. Hat auch fuktioniert, aber ich hatte sehr oft ungültige Zeiten, da die Paritprüfung ja nur wenig abdeckt zur Datensicherheit. Wenn der Empfang gestört ist, treten so häufig Fehler auf, die durch die Parityprüfung nicht entdeckt werden, dass dann auch oft "Müll" als Uhrzeit entsteht. Es wird ja nur ein Sample aus dem Signal gezogen. Wenn es arg gestört ist, dann ist das ungünstig. Mein Tip, die echte Impulslänge auswerten. D.h. es muß wirklich die Zeitdauer der Trägerabsenkung gemessen werden und über diese Zeit ermittelt werden, ob es eine 0 oder 1 war. Wenn die Zeit nicht 100/200 ms war, dann die Daten verwerfen und von vorne. Klappt wesentlich besser. Es wird dann natürlich schwieriger synchronisiert, aber es gibt ganz ganz selten Datenmüll. Bei mir klappt das so hervorragend. Habe den Code von Peter Dannegger genommen und etwas modifiziert. War neugierig, wie es mit deiner beschriebenen Methode klappt, aber nun ist mir klar, dass unsicherer ist, wenn die Impulslängen nicht als "Datensicherheit" genutzt werden. Das wollte ich nur mal zum besten geben.
@ 900ss: Hallo, die Wetterdaten haben zur Folge, dass die abgebildete Uhr nicht mehr synchronisiert. Über den verwendeten Algorithmus kann ich nur Vermutungen anstellen. Mein Dekoder ist davon nicht betroffen. Mit meinem Dekoder synchronisiere ich zuerst auf den Sekundenanfang. 150 ms später prüfe ich das Signal. Das ist der optimale Zeitpunkt um die Daten abzutasten. Bei einem verlängerten "0-Bit" (über 150 ms), einem zu kurzen "1-Bit" (unter 150 ms) oder einem Störimpuls zum Abtastzeitpunkt habe ich einen Bitfehler, mit dem ich gut leben kann. Neben der Parität prüfe ich alle Ziffern und alle Zahlen auf Einhaltung des Wertebereiches. Dabei habe ich noch keine Fehlsynchronisation gehabt. Die Information wird in der Zeit von 0,1 s bis 0,2 s nach Sekundenbeginn übertragen. Die verbleibenden 0,9 s sind für die Daten nicht von Interesse und werden deshalb auch nicht betrachtet. Ein Vorteil meiner Lösung besteht darin, dass kein Interrupt benötigt wird und das es ausreicht, das Programm alle 10 - 20 ms aufzurufen. Gruß Joachim
JoachimB wrote: > @ 900ss: > > die Wetterdaten haben zur Folge, dass die abgebildete Uhr nicht mehr > synchronisiert. Über den verwendeten Algorithmus kann ich nur > Vermutungen anstellen. > Mein Dekoder ist davon nicht betroffen. Ich hatte es so verstanden, dass die Uhr mit Deiner Software nicht mehr synchronisiert. > > Mit meinem Dekoder synchronisiere ich zuerst auf den Sekundenanfang. 150 > ms später prüfe ich das Signal. Das ist der optimale Zeitpunkt um die > Daten abzutasten. Bei einem verlängerten "0-Bit" (über 150 ms), einem zu > kurzen "1-Bit" (unter 150 ms) oder einem Störimpuls zum Abtastzeitpunkt > habe ich einen Bitfehler, mit dem ich gut leben kann. Sicher mit einem 1-Bit Fehler kann man leben. Das fangen ja die Paritybits ab. Aber bei mir waren "Mehrbit" Fehler nicht selten und das kann man ja leider nicht mehr ohne großen Aufwand abfangen. > Neben der Parität prüfe ich alle Ziffern und alle Zahlen auf Einhaltung > des Wertebereiches. Dabei habe ich noch keine Fehlsynchronisation > gehabt. Da kommt dann schon mal nachmittags um 14:30:00 eine Zeit von 19:46:13 raus (nur Beispiel). Für Arbeitnehmer nicht schlecht ;-) Aber das stört mich eben. > > Die Information wird in der Zeit von 0,1 s bis 0,2 s nach Sekundenbeginn > übertragen. Das Prinzip ist schon klar. Allerdings sieht es bei mir besser aus, wenn ich wirklich die Impulslänge messe. Dann kann auch nach 150ms (deine Methode) kein Störimpuls das Ergebnis verfälschen, sondern der Fehler wird erkannt, da ja die Impulslänge nicht paßt. Die verbleibenden 0,9 s sind für die Daten nicht von > Interesse und werden deshalb auch nicht betrachtet. Würde auch zu unnötigen Störungen führen. > > Ein Vorteil meiner Lösung besteht darin, dass kein Interrupt benötigt > wird und das es ausreicht, das Programm alle 10 - 20 ms aufzurufen. Ich habe es auch so gelößt, dass kein Interupt nötig ist. Die Impulslänge kann man ja auch mit 10ms "Polling" messen. Nun ja, ich wollte nur einen Tip loswerden. Interessant finde ich Deine Lösung auch (und den Webserver erst :-). Und ich war verwirrt, dass Deine Uhr nicht synchronisiert. Aber ist ja nicht die mit Deiner Software. Ich habe aber schon öfter gehört, dass sich DCF77-Uhren seit den Wetterdaten nicht mehr synchronisieren. Was die da nur gemacht haben.
Hallo Joachim, bei der "alten" Software-Version gab es noch eine Super-Dokumentation, bei der neuen mit TCP/IP-Stack uIP 0.90 leider (fast) gar nicht mehr. Kannst Du bitte hier wenigstens den passenden Schaltplan veröffentlichen? Vielen Dank, Thomas
Hallo Thomas, bei den ersten Versionen ließ sich alles im einem MByte unterbringen. Bei der letzen Version wurde die Beschreibung zu umfangreich. Ich habe die Doku deshalb im Web zusammengefasst. Unter avr.börke.de (Umlautdomain!) findest Du auch die Schaltbilder. Gruß Joachim
Hallo Joachim, Danke für die Antwort. Aber die Seite kenne ich selbstverständlich schon. Ich hatte gehofft, es gäbe da einen zusammenfassenderen Schaltplan. Speziell zu one-wire habe ich leider nichts gefunden. Da hast Du doch außer den Temperaturbausteinen auch noch andere verwendet, oder? Wie werden die wo angeschlossen? Thomas
Hallo Thomas, die one-wire-Bausteine sind sehr einfach anzuschließen. Die GND-Leitung wird mit GND des Controllers verbunden. Die Signalleitung DQ wird mit der Portleitung verbunden. Die benutzte Portleitung wird dann noch mit einem Widerstand 2k2 an +5V gelegt. Mehrere one-wire-Bausteine werden parallel geschaltet. Das ganze ist so einfach, dass ich auf eine separate Zeichnung verzichtet habe. Gruß Joachim
Hollo Joachim, ich möchte Dich bzw. Euch auf den Thread -> Beitrag "AVR für wenig Geld im LAN" hinweisen. Dort geht es um einen Bausatz von Pollin, der mit einem ATmega32 und einem ENC28J60 ausgestattet ist. Es funktionieren modifizierte Programme der Webserver von SimonK und Ulrich Radig. Zumindest 2 Personen (z.B. ich) haben Interessen an einer Einbindung von 1-Wire, wie es bei Deinem Webserver der Fall ist. Leider ist er "nur" für den Realtek-Baustein geschrieben und leider zum 2. haben wir beide (auf jeden Fall ich) z.Z. zu wenig Ahnung, um den C-Code umzuschreiben bzw. den nötigen Treiber einzufügen. Könntest Du (oder andere) helfen? Es könnte auch sein, dass das hex-File zu lang für den ATmega32 wird. Man müsste evtl. manche Sachen deaktivieren (z.B. Kamera?). Gruß RoBue
Hallo RoBue, der Bausatz von Pollin ist sehr interessant. Leider konnte ich ihn im Webshop nicht finden. Die Übersetzungsprobleme hängen mit dem Compiler zusammen. Die letzte Version der Software habe ich im April 2007 mit der Version WINAVR 20060125 übersetzt. Das sollte auch heute noch funktionieren. Inzwischen wurde WINAVR mehrfach verbessert. Die AVR-Versionen von 2007 ließen sich unter WIN98SE nur mit Problemen installieren. Es waren umfangreiche Anpassungen der Quellen an die Compileränderungen erforderlich. Der neuste Compiler WINAVR 20080610 läßt sich wieder problemlos installieren. Der übersetzte Quelltext benötigt nun 1360 Bytes mehr Speicher, als der ATmega bereithält. Ich habe vor, neben dem neusten Compiler zukünftig den ATmega644 und den ENC28J60 zu verwenden und auf die neueste uiP-Version umzustellen. Das dauert aber angesichts der WINAVR-Überraschungen noch etwas. Gruß Joachim
Hallo Joachim, toll, dass Du auf meine Anfrage reagiert hast. Also liegt das Problem beim Compiler. Der AVR-NET-IO ist mit dem 2. Webserver von U.Radig ziemlich kompatibel (2 Leitungen des ENC-Bausteins müssen getauscht werden - in der Software oder auf der Hardware). SimonK hat seine Software auf AVR-NET-IO angepasst. Da ist sogar noch einiges im ATmega32 an Platz frei. Ich habe auch schon etwas damit herumexperimentiert und die Weboberfläche erweitert, aber meine Kenntnisse in C sind nur ganz oberflächlich. Ich arbeite mich gerade ein wenig ein. Super ist auch deine Anleitung. Sie hat mir einiges verdeutlicht. Toll, dass Du Dir diese Mühe gemacht hast. Wäre es möglich die Software von SimonK mit Deiner zu kombinieren, also Deine 1-Wire-Erweiterung und evtl. Deine Weboberfläche auf die Grundroutinen von SimonK aufzusetzen. Es würden mir z.B. 8 Sensoren reichen, Ihre Kennung könnte man per Hand in den Quellcode eintragen (oder ins EEPROM schreiben) um Platz zu sparen, evtl. 4 weitere Messeingänge (0/1) und 8 Schaltausgänge (0/1). Das größte Problem ist für mich dabei die 1-Wire-Einbindung. Siehst Du eine Möglichkeit, mir dabei zu helfen oder es selbst mal zu probieren? Ich könnte mir vorstellen (als relativer Laie gesprochen), dass Du wohl am ehesten weißt, wo man da ansetzen muss. Evtl. würde mir ein Grundgerüst reichen. Irgendwie kriege ich beide Systeme halt nicht zusammengepackt. Gruß RoBue PS: Ich schicke Dir gerne den Code von SimonK
Hallo RoBue, ich habe jetzt 2 Tage mit meiner Anpassung rumgetestet aber die 1Wire Sensoren werden nicht erkannt. Die Probleme haben sich immer mehr angehäuft. Kurz was ich gemacht habe: - Basis ist der aktuelle ETH32 Webserver code von Urlich Radig - dann den code für AVR Net i/o angepasst und getestet : geht - dann habe ich von Joachim den code für 1Wire aus 1.38 jb 04 genommen - anpassung an makefile und header dateien etc. - im Detail kann ich es nicht auflisten Probleme machen: 1. geht der 1 Wire auch mit 16 MHZ (wegen der timeing Geschichten, angepasst habe ich es) 2. Ich vermute ei Pointer problem, da mir einmal meine ip configuration zerschrieben wurde. 3. Atmega32 Flash ist voll, alles möglich aus der Webpage rausgeworfen um auf der RS232 debuggen zu können. 4. Aktivieren der Busleitungen portd.3 -6 ohne die webpage interaktion 5. Das ablegen der ROM IDs bzw. der Speicherverwaltung im EEprom (pointer) Aktueller Stand: Ich habe es auch compiliert bekommen die software läuft auch aber keine ROM Id ausgelesen und folglich auch keine Temperatur. Falls Joachim oder irgendwer Tips geben kann wäre ich dankbar. Gruß mr_energy (juan dot nospam at lycos dot de)
Hallo mr_energy, wir sind wohl gerade die Einzigsten, die sich für die 1-Wire-Erweiterung zu interessieren scheinen. Wir sollten uns einigen, in welchem Thraed wir unsere Erfahrungen austauschen. Hier oder beim AVR-NET-IO. Zu mir: Ich bin auch noch nicht so arg weit gekommen. Ich denke, wir sollten bei dem Grundgerüst von Simons Webserver bleiben. Da sind noch am ehesten Reserven drin und die Sourcen laufen mit meinem WinAVR. Außerdem komme ich langsam aber sicher doch hinter die Struktur. Schön wäre trotzdem für uns, wenn uns dabei Simon oder/oder Joachim helfen würden. Ich habe gelesen, dass Du auch mit BASCOM arbeitest. Ich habe 2 interessante Seiten gefunden -> http://heldt-intern.dyndns.org/index.php -> http://members.home.nl/bzijlstra/software/examples/enc28j60.htm Vielleicht machen wir doch mit BASCOM weiter, wenn uns die C-Profis nicht weiterhelfen (wollen/können). Da klappt 1-Wire problemlos. Ich habe z.Z. nur die Demo-Version von BASCOM und kann deswegen die langen Programme nicht testen. Gruß RoBue
Hallo RoeBue und mr_energy, wenn der lauffähige Code von SimonK im Netz zur Verfügung steht, bin ich an einem Link interessiert. Ich habe bereits einmal den TCP-IP-Stack im meiner Software ausgetauscht. (Von Ulrich Radig's 1.38 auf uiP 0.9) Das ist eine überschaubare Sache, wenn man die Schnittstellen kennt. Da ich uiP 1.0 für sinnvoll halte, habe ich vor das zu tun. Meine Software arbeitet im wesentlichen ohne Interupts. Ein Dreh- und Angelpunkt ist deshalb die "Zeitwirtschaft". Nach zeitintensiven Aktionen, die einige Millisekunden dauern können, wird geprüft ob eine Aktion des DCF77-Dekoders fällig ist. Wenn die DS1820-Bausteine mit der Temperaturwandlung beschäftigt sind, wird die Kontrolle an uiP gegegeben. Das Zweite ist die Datenverwaltung. Die Daten zu den one-wire-Bausteinen werden im EEPROM abgelegt. Jeder Datensatz enthält 16 Byte. Im "Datensatz 0" stehen die IP-Adresse und einige Einstellwerte. Die verbleibenden 127 Datensätze stehen für Dallas-IC's, Thermostaten, Ausgangsleitungsbescheibungen, Schaltuhren oder Funksteckdosencodes zur Verfügung. Die Schaltverknüpfungen sind ebenfalls im Datensatz abgelegt. Die variablen Daten (Schaltzustand und Temperatur) liegen im RAM. Zu jedem EEPROM-Datensatz gehören 2 Byte im RAM. Ein Interrupt wurde als Notlösung vorgesehen, um bei Abstürzen der Kamera oder bei nicht vorhandener Kamera, das Aufhängen des Systems vermeiden zu können. Fragen zur Software will ich Euch gern beantworten. Gruß Joachim
Hallo Joachim, das wäre wirklich absolut super! Den Code schicke ich Dir hiermit. Es ist soweit alles einegstellt. WinAVR geht auch. In dem Zip-File habe ich noch einige wichtie Infos aus dem Thread von Simon eingebunden (README_aus...). Mir würde schlicht und ergreifend ein 1-Wire-Port reichen, z.B. PortB2/PB0. Der Rest der Portleitungen ist belegt (ENC-Baustein). Mehr als 8 Sensoren müssen es auch nicht sein. Brauchst Du einen Schaltplan? Liebe Grüße, RoBue Übrigens: rbuehler at vr minus web dot de
Nun antworte ich mir selber, da keine weiteren Einträge dazugekommen sind. Es geht immer noch um das AVR-NET-IO von Pollin und Routinen für 1-Wire (z.B. von Joachim). Allen Anschein haben sich doch einige für die Sourcen interessiert. Kommt da noch etwas an Reaktion? Ich bin nun auch etwas weiter gekommen und kann Werte in eine weitere Tabelle eintragen (siehe Anhang). Was mir jetzt fehlt und wohl auch anderen Probleme macht, sind lauffähige 1-Wire-Routinen. Die, die ich gefunden habe, laufen auf meinem (neuen) WinAVR nicht und die von Joachim sind für mich noch etwas zu kompliziert. Kann mir einer weiterhelfen (schreiben, modifizieren oder auch nur erklären)? - Ich bräuchte eine Init-Routine (Aufruf in main.c), die den 1-Wire-Bus initialisiert, durchsucht und den Code der gefundenen Bausteine in irgendeiner Variablen (oder eeprom) ablegt. - Eine zweite Routine, die zu bestimmten Zeiten ca. 1*pro min die Sensoren abfragt und die Werte irgendwo ablegt (Variable). Ort/Aufruf: main.c? - Eine 3., die dann die Temperaturwerte aufgeteilt in Vorzeichen, Zehner, Einer, Nachkommastelle aus der Variablen ausliest und in die html-Tabelle einbaut (httpD.c). Schaut euch dazu den Anhang von mir an. Er enthält eine modifizierte Datei "httpD.c" des Webservers von Simon, in der auch einige Erklärungen von mir stehen. Falls Euch dabei die Haare zu Berge stehen, dann bedenkt, dass das meine ersten Gehversuche in C sind und ich relativ glücklich bin, wenigstens das geschafft zu haben. Grüßle, RoBue
Hallo zusammen ich bin "lanfristig" auch an einem Webserver mit 1-Wire Unterstützung interessiert. Ich habe bisher eine Standolonelösung von da > http://www.siwawi.arubi.uni-kl.de/avr_projects/tempsensor/index.html diese funktioniert problemlos. Man könnte eventuell diese in den Webserver einbauen. Ein eigener Thread "Webserver & 1-Wire" wäre sicherlich ne gute Sache bzw, in der Artikelsammlung die Ergebnisse festhalten. Ich würde mich da auch beteiligen, wenn ich da mehr in dieser Thematik drin bin. Viele Grüsse Achm
Hallo Ach(i?)m, ein neuer Thread wäre sicher sinnvoll, da ich zur Zeit mich durch drei verschiedene kämpfe. Wer macht ihn auf? Nun aber konkret zu Deiner Lösung: Traust Du Dir zu, die 1-Wire-Routine in die main-Schleife von Simons Programm einzubauen? Die Werte sollten dann irgendwo im Format - Vorzeichen (1 Byte) - Zehner (1 Byte) - Einer (1 Byte) - Nachkommastelle (1 Byte) vorliegen, also z.B. -|2|1|7 für -21,7 Grad. Die Routinen in dem von dir genannten Beitrag sind realtiv alt (2205), also für die neueren Compiler sehe ich da schon wieder Probleme. Es ist echt ätzend, wenn man als Anfänger nicht nur mit den Befehlen an sich, sondern auch noch mit verschiedenen "Dialekten" kämpfen muss. Soweit ich weiß sind z.B. einige der Routinen (delay, crc) in WinAVR integriert - oder? Braucht man sie dann trotzdem noch? Kann man sie ersetzen? Ich müsste dann nur wissen WO Du diese Daten ablegst, dann könnte ich sie relativ leicht (hoffentlich) in den Webserver einbauen. Den Teil würde ich dann versuchen zu übernehmen. Hoffentlich nehme ich dabei das Maul nicht zu voll, aber ich denke, das wäre ein machbarer Anfang. Gruß RoBue
Hier weitere Details zum Aufbau meiner Webserversoftware. Das System ist recht komplex und birgt das Risiko der Fehleranfälligkeit. Um ein möglichst stabiles System mit hoher Leistungsfähigkeit zu bekommen, wurde deshalb auf erprobte Softwarebausteine zurückgegriffen. Der TCP-IP Stack wurde in der ersten Variante aus der Software 1.38 von Ulrich Radig entnommen. Dann wurde auf uIP 0.9 umgestellt, um die Bedienung WLAN-fähig zu machen. Im Augenblich wird auf uIP 1.0 umgestellt. Die one-wire-Software entstammt aus einer Applikation von Atmel in der die vollständigen Programme mit erstklassiger Dokumentation und allen Varianten zur Verfügung gestellt werden. Die Kamerasoftware ist durch Reengeneering entstanden und stammt aus dem Forum. Der DCF77 Dekoder basiert auf einer Hardwareemulation zu der von den Entwicklern des DCF77-Zeitcodes erstellten Dekoderhardware. Die allgemein verfügbaren Dekoderprogramme sind ungeeignet, weil sie oftmals "Alleinnutzer" ihres uP-Systems sind und alle Ressourcen belegen. Alternativ belasten Sie ihre Systeme mit Interupts, die Auswirkungen auf alle anderen Softwareteile haben. Die Dekoder erzwingen meistens Signale in bestimmter Polarität, was bei der Problemlösung für zusätzliche Forenbeiträgen sorgt und gegen eine möglichst universelle Verwendung spricht. Der Programmablauf. Bei der Initialisierung wird der 16-Bit-Zähler-1 als freilaufender Zähler programmmiert. Nachfolgend wird der Zähler nur noch gelesen. So ergibt sich eine quarzgenaue Zeitreferenz. Nach der Initialisierung geht das Programm in eine Endlosschleife. In dieser Schleife werden nacheinander der TCP/IP-Stack, der DCF77-Dekoder und das one-wire-Interface (OWI) bedient. Der DCF77-Dekoder tastet das Signal in 10ms Schritten ab. Bei einer Bitlänge von 100ms handelt es sich um eine Überabtastung. Beim Programmstart liest der Dekoder den freilaufenden Zähler aus und kennt damit den aktuellen Zeitpunkt. Zu diesem Zeitpunkt werden 10ms addiert. So ergibt sich der Zeitpunkt, an dem die nächste Aktion fällig ist. Bei jedem Aufruf des Dekoders wird geprüft, ob der vorbestimmte Zeitpunkt erreicht oder überschritten wurde. Wenn die Zeit ereicht ist, führ der Dekoder den nächsten Schritt aus. Wenn dabei der Sekundenanfang abgetastet wurde, werden z.B. 150ms bis zur nächsten Folgeaktion addiert. Programme, deren Laufzeit über 10ms liegt, rufen den Dekoder auch zwischendurch auf. Das Dekoderprogramm darf beliebig oft aufgerufen werden. Der TCP/IP-Stack muss alle 500ms bedient werden und berechnet sich daraus die längeren Zeitabläufe, wie sie z.B. für die Bedienung des ARP benötigt werden, selbst. Der Mechanismus für die Zeitbestimmung ist der Gleiche wie oben beschrieben. Das one-wire-Interface, dessen Software im Verzeichnis OWI steht, arbeitet wie folgt. Zuerst werden die Bausteine auf dem Bus identifiziert und die Seriennummern ermittelt. Für jede Seriennummer, die im EEPROM noch nicht hinterlegt ist, wird ein 16-Byte Datensatz im EEPROM angelegt. Danach wird allen Bausteinen das Kommando zur Temperaturwandlung gegeben. Der Bus wird dazu auf "1" geschaltet und liefert so den Betriebsstrom für die angeschlossenen Thermometer, die gleichzeitig ihre Temperatur messen. In den nächsten 800ms findet am Bus nichts statt, damit die Thermometer nicht gestört werden. Anschliessend werden alle Datensätze von 1 bis n bearbeitet. Bei einem Thermometer wird die Temperatur ausgelesen und in einem Zwischenformat im RAM abgelegt. Dazu stehen für jeden Datensatz 2 Byte zur Verfügung. Das Zwischenformat ist platzsparend und unabhängig vom Thermometer (DS1820, DS18B20, DS18S20, DS1822). Bei einem Schaltausgang wird die Schaltbedingung geprüft und gfs. die Portleitung gesetzt oder, wenn es sich um eine Funksteckdose handelt, der Einschalt- oder Ausschaltcode gesendet. Wenn der Datensatz einen Thermostaten oder eine Schaltuhr beinhaltet, werden die entsprechenden Aktionen ausgeführt. Ein Zyklus benötigt 800ms und die Zeit für die Bausteinbearbeitung (etwa 75 pro Sekunde). Das bedeutet, das Steueraktionen in spätestens 2 Sekunden ausgeführt sind. Für eine Heizung ist das ausreichend. Bei der Integration weiterer Funktionen muß die Software in die eitabläufe des Servers eingebunden und dazu in Segmente mit einer Laufzeit von einigen Millisekunden unterteilt werden. Bei Erweiterungen um Internetdienste ist die uIP-Schnittstelle zu bedienen. Die Ein- und Ausgabedaten sind an die HTML-Schnittstelle und / oder die interne Datenverwaltung anzubinden. Interupts sind zu vermeiden, weil das übrige System keinen Schutz gegen zufällige Unterbrechungen bietet und deshalb instabil werden könnte. Die Organisation der Daten. Die Daten zur Hardwareperipherie werden im EEPROM gespeichert. Dazu wird das EEPROM in Datensätze mit jeweils 16 Byte eingeteilt. Die Datensätze werden von 1 bis 127 (für den ATmega32) indiziert. Unter Satz 0 werden die IP-Adresse und Einstelldaten abgelegt. Jeder am Bus erkannte Dallasbaustein wird mit seiner Seriennummer als Datensatz abgelegt. Über das HTML-Interface kann der Baustein dann noch mit einem Namen versehen werden. Die Datensätze können aber auch andere Daten enthalten, wie z.B. Daten zu einer Schaltuhr, Einstelldaten eines Thermostaten, Codes einer Funksteckdose, etc. Die Einstellungen werden ebenfalls über das HTML-Interface vorgenommen. Zu jedem Datensatz gibt es 2 Byte im RAM für variable Daten. Dort werden die letzte gemessene Temperatur und Schaltzustände abgelegt. Ich denke, dass es mit dieser Darstellung einfacher sein sollte Änderungen oder Erweiterungen am Code durchzuführen. Gruß Joachim
Hallo Joachim, danke für Deine ausführlichen Informationen. Ich habe gerade etwas wenig Zeit, sie alle mal für mich auszuwerten. Aber ich setze mich bald wieder dran. Ich wollte mich nur mal melden und bedanken. Meine Situation: Wie gesagt ich bin absoluter Neuling in C. Und ich habe nicht nur Probleme, den Code zu verstehen, leider gibt es immer wieder Probleme mit den Code-Varianten oder Dialekten (wenn ich das mal so ausdrücken darf). Mein WinAVR (neueste Version) schluckt nicht alle Codes anstandslos. Deinen kann ich z.B. nicht ohne Fehlermeldungen compilieren bzw. er bricht einfach ab. Letzten Endes wäre es vermutlich das Einfachste, wenn Simon Deine 1-Wire-Routinen in seinen Webserver integriert, oder Du den Stack und die ENC-Rotinen in Deinen. Ihr kennt Euch mit Euren Programmen am besten aus! Dieses Einbauen muss noch gar keine Ausgabe für das Webinterface bedeuten (da bin ich jetzt ein gutes Stück weitergekommen), sondern einfach (?) die Verknüpfung beider Programme bzw. Programmteile zu einem compilierbaren Code mit den richtigen include- und makefile-Anweisungen für den WinAVR. Trotzdem versuche ich natürlich, auch selbst eine Lösung zu finden - wen ich wieder mehr Luft (Zeit) habe. Melde mich dann wieder. Grüße, RoBue
Hallo Joachim! Ich habe mit Aufmerksamkeit deinen Artikel über den Webserver gelesen, ich habe aber daheim nur die von Ulrich Radig entworfenene Platine [http://www.ulrichradig.de/home/index.php/avr/eth_m32_ex]. Ist die Software Kompatibel? oder sind sehr umfangreiche Änderungen von nöten? lg Ralf
Hallo Ralf, die Platine von Ulrich Radig arbeitet mit dem ENC28J60, der über den SPI-Bus angesteuert wird. Die nächste Version meiner Software sollte deshalb dazu kompatibel sein. Gruß Joachim
Hallo Joachim! Danke für deine Antwort... Wann wird es denn ungefähr so weit sein?! lg Ralf
Hallo, ich habe auch eine Frage. Habe soeben mein erstes ETH Board von Pollin zusammengelötet und mit der Software von RoBue zum Laufen gebracht. Danke dafür. Als nächstes wollte ich das Gerät in meinen IP Range bringen also 192.168.228.XXX. Dazu habe ich die IP Adresse in der config.h passend abgeändert. Nur leider kann ich den damit programmierten Mega32 nicht erreichen. Habe ich etwas übersehen? Gruß, Joeeee
Hallo Joachim! Wollte mal fragen, wie weit du mit der implementierung für den ENC28J60 gekommen bist, da ich momentan nur auf der Stelle trete...
Hallo! Ich habe heute meinen Webserver zur Steuerung der Funksteckdosen erweitert. Funktioniert jetzt super. Allerdings ist Dir bei der doku auf der Homepage ein Fehler passiert. Im Schaltplan der Transistorstufe steht "Port D4" - sollte aber "Port B4" heißen. Bin nach längerem herumsuchen draufgekommen. Grüße Gerhard
Hallo Gerhard, vielen Dank für den Hinweis, ich habe das gerade berichtigt. Gruß Joachim
hallo, habe da mal ne Frage und zwar hab ich das pollin avrnetio board und habe nun benutze die software von RoBue. heute habe ich 1 1-wire sensor zum testen angeschlossen, wie hier beschreiben, aber ich bekomme keinen wert angezeigt??? woran kann das liegen oder muss man erst noch die id des DS1820 irgendwo eintragen??? oder geht das automatisch??? schon mal danke
Hallo Joachim, erstmal ein ganz dickes Lob für die hervorragende Arbeit! Ich arbeite mich die letzten Tage durch diesen Thread und die einschlägigen µC-Seiten und bin total begeistert. Ich würde das eingentlich direkt nachbauen, deine Ankündigung, dass du eine Implementierung für den ENC28J60 integrieren willst lässt mich aber nachfragen. Der kleine ETH_M32_EX von Ulrich Radig ist so kompakt und würde mir besser gefallen als die wohl bewährte aber etwas betagte ISA-Lösung. Hast du die Integration des ENC28J60 verworfen oder lohnt es sich noch etwas zu warten? Gruß, Frank
Hallo Frank, das Projekt liegt erst einmal auf Eis. Ich hatte schon vor längerem an der ENC28J60-Variante gearbeitet. Es gibt aber noch nichts Veröffentlichungswürdiges dazu. Einen Termin kann ich noch nicht nennen. Gruß Joachim
Hi Joachim, I am Gabor Ondi from Hungary. I bought MCA-30. I try communication with MCA-30 on PC. When I send "monitoring-command". camera send back 80x60 picture. It's fine, but after I send "get camera info" to MCA-30. Camera send back this message: "<camera-info version="1.0" SW-version="CXC125766 R1B"><memory free="591" free-images="10" stored-images="0" fun-layer="18"/></camera-info>" What is the problem ? ( may be stored-images="0" ??? ) Could You help me, in this problem ? Best Regards, Gabor Ondi.
Hi Gabor, your question is referring to the protocol between camera and server. For further information have a look to this link: http://avr.auctionant.de/avr-ip-webcam/index.html Best regards Joachim
Hallo Joachim, ich habe mal meine "alte" Hardware (ISA-Ctrl Webserver) rausgekramt und will die wieder in Betrieb setzen. Bislang läuft da die vorletzte Version von I. Busker (Webserver V1.39 IB). Nun will ich aber Deine Version mit uip-Stack darauf laufen lassen. Gibt es eine aktuelle Dokumentation (analog der in _jb04)? @all, Ich brauche keine Webcam, kein Dcf und (für den Anfang?) keine owi-Schnittstelle. Ich möchte nur digitale E/A nutzen. Die verschiedenen Erweiterungen sind an vielen Stellen in der Software verteilt und ich habe keine einfache Möglichkeit gefunden, diese zu deaktivieren. Gibt es evtl. eine abgespeckte Version? Ich habe zum Test mal das vorkompilierte mitgelieferte Hex-File auf den M32 geflasht. Es ist keine weitere Peripherie angeschlossen. Leider wird nur der Menu-Frame auf der linken Seite angezeigt und nicht der Rest? Kann das an ggf. falsch gesetzten Fuses liegen? Danke, Thomas
Hallo, inzwischen habe ich mitbekommen, dass es leider keine aktuellere Doku gibt, nur die im Netz. Schade, das Word-Dokument war deutlich übersichtlicher und informativer. Die nichtbenötigten Komponenten wie Webcam und DCF habe ich auch rauskonfiguriert und der Webserver läuft erstmal. :) Nun habe ich noch folgende Probleme: 1. In inithardware.c wird u.a. die IP-Adresse eingestellt:
1 | if (!OWI_ComputeCRCn(Feld,8)) { // Wenn CRC ok, |
2 | |
3 | VAi = Feld[0]; |
4 | VAj = Feld[1]; |
5 | VAk = Feld[2]; |
6 | VAl = Feld[3]; |
7 | |
8 | VA3 = Feld[4]; // Anzeigeoptionen setzen |
9 | DALLAS[0][0] = Feld[5]; // aktive Busleitungen setzen |
10 | VAR = Feld[6]; // refresh-Zeit für Temperaturmessungen setzen |
11 | }
|
12 | else { // wenn CRC nicht ok, default-Werte benutzen |
13 | VAi = 192; |
14 | VAj = 168; |
15 | VAk = 99; |
16 | VAl = 199; |
17 | VA3 = 0; // alle Bausteine anzeigen |
18 | DALLAS[0][0] = OWI_PIN_5; // aktive Busleitung ist D5 (evtl. mehrere durch | verknüpfen) |
19 | VAR = 3; // refresh-Zeit für Temperaturmessungen auf 3 s setzen |
20 | }
|
21 | |
22 | /* If uIP should use a fixed IP address, the settings are set in the
|
23 | * uipopt.h file. If not, the macros uip_sethostaddr(),
|
24 | * uip_setdraddr() and uip_setnetmask() should be used instead.
|
25 | |
26 | uip_hostaddr[0] = (VAi << 8) | VAj;
|
27 | uip_hostaddr[1] = (VAk << 8) | VAl;
|
28 | */
|
So wie ich das verstehe, wird entweder die Adresse (aus dem EEPROM?) ausgelesen oder eine default 192.168.99.199 benutzt. In uipopt.h ist aber eine andere IP-Adresse (192.168.99.98) definiert und diese wird auch genutzt, wenn:
1 | #define UIP_FIXEDADDR 1
|
Das hat den Effekt, dass beim ersten Start der Webserver unter 192.168.99.98 erreichbar ist, aber auf der Startseite 192.168.99.199 angezeigt wird. Wenn man nun
1 | #define UIP_FIXEDADDR 0
|
setzt, sollte ja der default-Wert aus inithardware.c (siehe oben) benutzt werden. Ein Enablen der Zeilen
1 | uip_hostaddr[0] = (VAi << 8) | VAj; |
2 | uip_hostaddr[1] = (VAk << 8) | VAl; |
(entspricht uip_sethostaddr()) reicht aber nicht aus. Der Webserver ist nicht erreichbar. Müssen die beiden anderen Funktionen uip_setdraddr() und uip_setnetmask() auch noch explizit aufgerufen werden? Ich möchte gern, dass die Werte aus der inithardware.c genutzt werden. 2. Ich möchte beim Start des Webserver gern die aktuell benutzte IP-Adresse und MAC_Adresse über die serielle Schnittstelle ausgeben lassen. Wie kann ich beide Werte im Kontext von main.c erreichen? 3. Funksteckdosen: Welche Hardware wird verwendet? Ein RF-Link-Sender-433MHz oder wird eine Fernbedienung "missbraucht"? Wie wird die Hardware angeschlossen? Ich hoffe, mir kann jemand helfen. Danke. Thomas
Hallo, so, Problem 1 ist gelöst. Die Implementierung in inithardware.c war unvollständig (komisch, dass es bei Joachim funktioniert hat?) und in main.c darf der Aufruf von checkEEPROMip erst NACH uip_init erfolgen. Dann klappt es auch mit UIP_FIXEDADDR 0 und auch Problem 2 ist gelöst. Jetzt bleibt noch Problem 3, die Ansteuerung der Funksteckdosen: Wenn ich das richtig lese: "Die Fernbedienung wird vom Mikrocontroller gesteuert, indem das im Controller erzeugte Modulationssignal über die Schaltstufe auf den Sender gegeben wird.", wird der Encoder HX2262 ignoriert und das Signal direkt vom Mikrocontroller an den Sender gesendet. Oder? "Es müssen nur zwei Leitungen (GND und Sender) vom Controller zur Fernbedienung geführt werden." -> Sender heißt in dem Fall DOUT (Pin17) am HX2262? Danke Thomas
Hallo Thomas, der Webserver ist beim ersten Mal über die Default-Adresse erreichbar. Die IP-Adresse kann dann über die entsprechende HTML-Seite geändert werden und wird im EEPROM abgelegt und mit einer Prüfsumme versehen. Beim Neustart wird die Prüfsumme kontrolliert und dann die geänderte IP-Adresse verwendet. Eingriffe in den uip-code hatte ich nicht vorgesehen. zum Problem Nr. 3: Der Controller erzeugt ein Signal, das dem am DOUT-Pin des HX2262 entspricht. Dieses Controller-Signal schaltet den Sender ein und aus. Viele Grüße Joachim
Hallo Joachim, Danke für die Antwort. Ich dachte schon, hier liest gar keiner mehr. ;) Funksteckdosen: Also wenn ich das richtig verstehe, genügt eigentlich ein RF Sender. Kann ich da auch z.B. den hier: http://www.watterott.com/de/RF-Link-Sender-434MHz nehmen? Ich habe nämlich auf meiner (zu schlachtenden) Fernbedienung keinen HX2262 drauf und da wird es schwer, den DOUT-Pin zu finden. Danke Thomas
Wieso ist es schwer den Dout-Pin des HX2262 zu finden, ein Blick ins Datenblatt vom HX2262 reicht um zu wissen wo der Pin liegt usw. Du meinst wohl den Signalweg, der den 433 Sender ansteuert, wenn kein HX verbaut ist. Irgendwas ähnliches wird verbaut sein. Also etwas das einen Impuls auslöst oder ähnlich dem HX2262 eine Impulskette. Darauf konzentrieren, messen.
Hallo, ich krame mal wieder den alten Thread hoch. ;) Jahrelang lag die Hardware ungenutzt rum. Nun will ich sie für ein kleines Projekt wiederbeleben. Dabei ist zu Thermostat und Schaltuhr folgende Frage aufgekommen: Beide schalten ja nach Temperatur bzw. Zeit. Nur WAS schalten die? Also wo/wie kann man das festlegen? Unter Schalter, so habe ich das verstanden, kann man nur festlegen, welches Objekt sie aktiviert bzw. ob sie manuell, also dauerhaft aktviert sind. Aber beide machen doch nur Sinn, wenn man damit z.B. einen Port oder eine Funksteckdose o.ä. schaltet.
Hm, Lesen hilft. ;) Auf der Seite: http://avr.börke.de/Objekte.htm ist unten alles erklärt... Offensichtlich schalten diese Objekte nicht direkt irgendwelche Ausgänge, sondern nur andere Objekte wie bspw. Portleitungen. So, mal sehen wie aufwendig (oder nicht ;)) es ist, das so umzuprogrammieren, dass A5 und A6 wahlweise auch als Eingang in der Objektliste angezeigt werden. So wie die Dallas-Bausteine, nur eben als 0/1 Wert.
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.