Hallo,

Ich habe mir mal die mühe gemacht und das OpenMCP Projekt [1], welches 
eigentlich für einen ATmega2561 ausgelegt ist, auf das AVR-NET IO Board 
mit einen ATmega644, der mit 16MHz läuft, portiert. Herausgekommen ist 
eine bunte Weboberfläche zum steuern. Unterstützt wird derzeit das 
schalten der 8 Ausgänge am 25-poligen Stecker, einlesen der 4 Eingänge 
vom selbigen und das Anzeigen der Analogeingänge an den seitlichen 
Klemmen. Am 25-poligen Stecker habe ich zu Testzwecken eine Relais-Karte 
von Pollin dran die man wunderbar per Webinterface schalten kann.

An Netzwerkprotokollen wird derzeit eigentlich alles unterstützt was man 
so braucht:

- ARP, IP, UDP, TCP
- DHCP, NTP, DNS

zusetzlich sind eine menge anderer Funktionen implementiert die einen 
das leben erleichtern sollen.

Die Dokumentaion zum Sourcecode kann per Doxygen aus den Projekt heraus 
erzeugt werden, oder unter [1] eingesehen werden. Die Dokumentation ist 
an sich noch nicht vollständig, aber zu großen Teilen vorhanden.

Nach dem erstmaligen Flashen der Firmware (main.hex) versucht sich das 
Board eine IP-Adresse per DHCP zu holen und ist danach unter dieser IP 
per HTTP oder Telnet erreichbar. Sollte kein DHCP-Server antworten wird 
eine Standart IP gesetzt von 192.168.178.24/24. Ausgaben zum Bootvorgang 
erfolgen über den Seriellen Port mit 57600 8N1. Dort kann auch die IP 
nachgelesen werden worunter das Board zu erreichen ist. Per 
Weboberfläche kann man dann alles weitere einstellen ( IP-Adresse, 
MAC-Adresse, NTP, etc ... ) und steuern. Alle Einstellungen selber 
werden im EEprom gespeichert.
Deshalb nochmal: alle Werte im EEprom werden überschrieben wenn keine 
alte Konfiguration dieser Firmware gefunden würde!!!

So, genug der Worte, ich wünsche viel Spaß beim spielen und würde mich 
über Anregungen und Verbesserungsvorschläge freuen und versuche 
natürlich auch mit Rat und Tat zur Seite zu stehen bei Fragen.

CAY Dirk

[1] Link: http://wiki.neo-guerillaz.de

Hallo Dirk,

beim experimentieren mit der Software ist mir folgendes aufgefallen. Der 
NTP-Server läst sich einschalten. Nach Neustart des AVR-NET-IO wird 
"Versuche DHCP-Config zu holen" noch ausgeführt und die Zeit wird 
geholt.
Ändere ich aber die MAC-Adresse, wird "Versuche DHCP-Config zu holen" 
nicht mehr ausgeführt. Es wird die Standart IP-Adresse ausgegeben. Das 
AVR-NET-IO läst sich aber nicht auf dieser Adresse anpingen. Das 
AVR-NET-IO ist erst nach Neueinspielung der Hex-Datei wieder 
ansprechbar.

Gruß
Karl Albert

Hallo,

klingt komisch, fast so als wenn die Konfiguration im EEprom verloren 
gegangen ist. Hast du BoD aktiviert? Wenn dies nicht aktiv ist kommt es 
manchmal vor das die Daten nicht richtig im EEprom landen ist es dann zu 
komischen Sachen kommt. Und kann es sein, das wenn du das Hex-File neu 
einspielt, das EEprom auch gelöscht wird? Das würde erklären das nach 
dem einspielen wieder alles I.O. ist. Schaue dir mal nach dem einspielen 
der Software und ändern das Konfig im Menu "System/EEprom" die Daten an 
die gespeichert wurden. Dort alles Okay? Sollte in etwa so aussehen:

Config ist 2047 bytes gross, 144 byte werden benutzt. Offset 13

DHCP=on
IP=192.168.2.195
MASK=255.255.255.0
GATE=192.168.2.1
DNS=192.168.2.1
MAC=00:03:6f:55:1c:c8
NTP=on
NTPSERVER=time.fu-berlin.de
UTCZONE=+2

CA Dirk.

ÄH ... ich sehe gerade das Problem, welches eigentlich nicht wirklich 
eins ist. Erklärung:

Nach dem ersten einspielen existiert im EEprom noch keine Konfiguration, 
logisch woher auch. Es wird daraufhin eine angelegt welche aber noch 
keine Werte und Daten enthält. Daher wird auch immer versucht per DHCP 
eine zu holen solange es keinen Eintrag dafür gibt. Wenn du nun die 
MAC-Adresse änderst schreibst du die Konfiguration für DHCP u.s.w., 
dabei wird auch DHCP ausgeschaltet, weil kein  Eintrag vorhanden war 
dafür. Also nochmal beim ändern nachsehen ob ein Häckchen bei DHCP 
steht. Damit sollte es getan sein.

Jetzt ist die Frage ob es sinnvoller ist solange kein Eintrag für DHCP 
und Netzwerk vorhanden ist, DHCP auch zu Aktivieren?

CA Dirk

Hallo Dirk,

den Fehler habe ich selbst verursacht. Eine MAC-Adresse darf ja nur 
einmal im Netzwerk vorkommen. Ich wollte die Mac.Adresse welche ich vom 
AVR-NET-IO Bausatz mitbekommen habe einspielen und habe aber die Adresse 
von meinem Router genommen. Danke für deine Hilfe.

Gruß
Karl Albert

Gerne geschehen ...

An dieser Stelle muss ich gleich nochmal die Frage stellen ob es Sachen 
gibt die eingebaut werden sollten oder verbessert werden sollten. Oder 
ob bedarf besteht nach einer Anleitung wie man eigene CGIs oder 
Webseiten einbaut? Oder einfach nur ein bisschen Feedback :-).

CA Dirk

Ich wäre für eine Anleitung wie man eigene CGIs oder
Webseiten einbaut sehr dankbar!!!

mfg. -crack-

Nicht immer nur fordern Leute, Selbermachen heißt die Devise ;)

@-crack-

Da bin ich schon am arbeiten, aber leider fehlt mir die Zeit. Ich werde 
mich mal ran setzen und versuchen diese Woche noch eine kleine Hilfe zu 
schreiben. Aber im Prinzip ist es sehr einfach CGIs oder Webseiten 
einzufügen, und das mit Absicht, soll es doch auch den Einsteiger den 
Einstieg erleichtern, da viele Einsteiger ein bisschen Angst haben vor 
C.

@1Wire Fan

Interessant auf jeden Fall. Ich werde mir mal einfache 
Temperatur-Sensoren holen und was basteln.

@Simon K.

Ja, da haste recht. Wie immer sind auch die Programmierer unter Euch 
aufgefordert was beizutragen. Aber nicht jeder ist Programmierer oder 
traut sich zu etwas dazu beizutragen, aber aller Anfang ist schwer.

@PJ

Die Software steht schon im Wiki drin. Sie hat bis auf die 
Dokumentation, welche ein bisschen hinterher hinkt, eigentlich schon den 
Stand den ich haben will.

Hallo,

ich wollte mich mal wieder melden. Ich habe inzwischen angefangen die 
Doku [1] zum CGI-Inferface zu schreiben, sie ist aber noch im Aufbau, 
sprich muss noch verfeinert werden und ist nicht Korrektur gelesen. Ich 
habe auch mal angefangen mich mit den 1-Wire Interface zu beschäftigen, 
mal sehen ob die Tage was dazu zu sehen ist. Und wie immer bin ich für 
Anregungen und Kritik offen.

CA Dirk

[1] Link: 
http://wiki.neo-guerillaz.de/mediawiki/index.php/S...

Hallo Dirk,

ich bin neu in der C Programmierung. In vielen Berichte bin ich über den 
Begriff foobar gestolpert. Ist dies nur ein Platzhalter?

Karl Albert

@Karl,

jup ... hat sich bei vielen Programmierer als synonym etabliert für 
irgend etwas. Siehe:

http://de.wikipedia.org/wiki/Foobar#Foo_in_der_IT-Branche

CA Dirk

Danke für die Hinweise.

Karl Albert

Hallo,

anbei die letzte Version des OpenMCP. Im wesentlichen ist die 
Unterstützung für 1-Wire dazugekommen sowie einige kleinere 
Verbesserungen im Detail und natürlich eine bisschen Fehlerbereinigung. 
Zum Thema 1-Wire: Zu finden ist 1-Wire im Menü "IO-Ports". Derzeit 
werden nur die IDs der gefundenen Sensoren ausgeben. Der 1-Wirebus 
befindet sich am ADC2-Pin des AVR-NET IO. Kommentare und Fehlerberichte 
sind wie immer willkommen.

An dieser Stelle nochmals vielen Dank an Peter Dannegger, sein Code hat 
viel zum Verständnis von 1-Wire beigetragen.

Anschließend möchte ich nochmals auf die Doku hinweisen zu CGI und 
statische Webseiten [1] die ich geschrieben habe.

CA Dirk

[1] Link: 
http://wiki.neo-guerillaz.de/mediawiki/index.php/S...

Hallo Dirk,

habe die neue Version getestet. Lief sofort auf Anhieb. Habe bis 8 
1-Wiresensoren angeschlossen gehabt. Die Anzeige Der ID's wird in eine 
Zeile geschrieben, so dass nur die ersten 4 vollständig zu lesen waren.

Was muß ich tun um das Doxyfile lesen zu lönnen?

Gruß
Karl Albert

@Karl

Ich werde das mal ändern, habe wohl einfach nur das \r\n vergessen und 
nicht gemerkt, da ich nur einen Sensor dran habe :-).
Das Doxyfile kann man nicht lesen, es dient nur als Konfigurationsdatei 
für das Programm Doxygen. Mit diesem kann man aus den Sourcecode heraus 
eine Dokumentation erzeugen. Diese ist auch immer unter [1] einsehbar in 
der aktuellen Version wenn ich es nicht vergessen habe zu erzeugen :-). 
Die Doku ist aber nicht immer ganz aktuell, weil die Sourcen sich 
schneller schreiben lassen als die Doku, ist wohl ein Naturgesetz.

CA Dirk

[1] Link: http://wiki.neo-guerillaz.de/html

Dirk Broßwick schrieb:
> @Karl
>
> Ich werde das mal ändern, habe wohl einfach nur das \r\n vergessen und
> nicht gemerkt, da ich nur einen Sensor dran habe :-).

Hallo Dirk,

ich hab mich auf die Suche gemacht und den Fehler gefunden. In der Datei 
cgi-bin.c ist in der Zeile 797 der Zeilenumbruch. Diesen habe ich in die 
Zeile 795 vor die schließende Klammer gesetzt. Jetzt sieht es schön aus.
Auch bei der Suche nach so einfachen Dingen lerne ich etwas von C.

Gruß
Karl Albert

Hallo Karl,

ich habe mich gestern auch mal auf die suche gemacht und gleich noch nen 
paar Sachen eingefügt zu 1-Wire... zu begutachten im Anhang. Wichtig ist 
auch das ich den 1-Wire Bus auf den PB0 gelegt habe (10-poliger 
Wannenstecker), da er auf den ADC-Pin gestört hat, kann man aber in der 
Datei Hardware/1wire/1wire.h wieder ändern.

CA Dirk

Hallo Dirk,

ich benutze auch den DS1822 als Sensor. Da in der Datei 1wire.c dieser 
nicht aufgeführt ist, hätte doch die Meldung "unkown family code" 
erscheinen müssen. Das Ergebnis habe ich als Bild beigefügt.
Der DS1822 wird von anderen Programmen wie ein DS18S20 behandelt. Bei 
der Temperaturanzeige habe keine Unterschiede festgestellt.

Gruß
Karl Albert

Hallo,

das hatte ich gestern auch gemerkt, peinlicher Fehler :-). Habe es auch 
gleich verbessert ... anbei die aktuellen Sourcen.

CA

hallo!

Erstmal vielen Dank für die tolle Arbeit!

Ich habe aber ein kleines Problem mit der Firmware.
Benutze das Pollin Board mit einem Atmega644 bei 18,432 Mhz.

Wenn ich nun die Webseite aufrufe (gleich nach dem Reset des Boardes) 
geht
alles wunderbar, aber nach ca 30sek bekommt man dann keine Verbindung 
mehr oder er brauch ewig dafür.
Woran kann das leigen?

Habe es mit der Avr-libc 1.6.1 / 1.6.2 und 1.6.6 probiert und auf 
verschiedenen Compilern, immer das gleiche!


Als Anregung hätte ich noch ein paar Sachen:
- abschalten von den Protokollen die man nicht braucht, in einer 
Confdatei
  (Speicherplatz sparen)
- SD-Karten Ünterstützung


Danke und Gruß
Denny

Hallo Denny,

danke für das Feedback. Ich selber habe noch keine anderen Quarze 
ausprobiert, werde mich aber gleich mal auf den Weg machen und einen 
anderen holen und das Problem untersuchen.

Zu deinen Vorschlägen:

Bei der Möglichkeit an einem Configfile bin ich schon dran, damit man 
die einzelnen Protokolle abschalten kann (NTP, DHCP, etc. ). Kommt 
vielleicht mit der nächsten Version. SD-Kartenunterstützung wollte ich 
eigentlich nicht einbauen, da ich alles On-Board haben wollten, aber 
wenn bedarf besteht könnte man mal darüber nachdenken, braucht aber mit 
Sicherheit ordentlich Speicherplatz.

CA Dirk

@sven

Der Seitenaufbau ist leider nur unter Windows so langsam. Windows 
benutzt DELAYED_ACK, was soviel heißt das es immer 200ms wartet ob ein 
neues Packet kommt, und wenn in dieser Zeit keines kommt erst die 
Bestätigung für das vorherige sendet. Und da der Stack wegen 
Speichermangel immer auf die Bestätigung eines Packetes warte ist das 
schlecht wenn Windows das macht. Wenn ich es noch schaffe werde ich 
heute noch eine gefixte Version posten.

CA Dirk

Hallo,

so, wie angekündigt jetzt die neue Version. Zu den Änderungen:

- DELAYED_ACK gefixt, geht jetzt auch mit Windows schnell
- config.h eingefügt um die einzelnen Softwaremodule ein/aus zu schalten 
( HTTP, TELNET, DHCP, DNS, NTP, UDP, TCP, GPIO, 1-WIRE, ADC )
- diverse Kleinigkeiten verbessert
- Telnet überarbeitet

So, wie immer viel Spass mit der neuen Version.

CA Dirk

p.s.: Über Kritik und Anregungen freue ich mich wie immer.

Hallo,

ich bin es nochmal. In der Version von gestern ist ein ungewollter Bug 
drin der die Firmware instabil macht. Schuld daran ist die Erweiterung 
des TCP-Stack bei der Behandlung von DELAYED_ACK in Bezug auf Windows. 
Zum Problem:

 Durch die Erweiterung DELAYED_ACK wird durch ein schnelles versenden 
von zwei TCP-Packeten nacheinander Windows gezwungen schneller zu 
Antworten damit die Kommunikation schneller wird. Soweit so gut. Dadurch 
wurde aber ein Fehler im Treiber für den ENC28j60 aufgezeigt der nur 
sporadisch auftrat. Das zeigte sich dadurch das sich die MCU scheinbar 
aufgehangen  hat. Hat sich aber nicht. Der ENC28j60 hatte sich 
aufgehangen. Im Treiber wurde beim versenden eines neuen Packetes nicht 
überprüft ob das vorherige schon fertig versendet worden ist und somit 
platz im Speicher war um das neue aufzunehmen. Wurde nun versucht ein 
neues Packet zu versenden während das vorherige noch versendet wird, 
stürzte der ENC28j60 ab und gab keinen mucks mehr von sich.

Das Problem ist jetzt soweit behoben. Netter Nebeneffekt sind neue 
Features für Full/Halb-duplex und Linkstate. :-)

Anbei die verbesserte Version.

CA Dirk

Hallo,

ja, das war auch meine erste Überlegung, aber eigentlich will ich keinen 
zumuten in der Registry zu spielen. Das muss auch so gehen. Ich zwinge 
Windows zu einem vorzeitigen ACK in dem ich einfach dem eigentlichen 
TCP-Packet ein ungültiges TCP-Packet welches nur ein ACK enthält 
hinterher schicke (ohne Payload). Dadurch muss Windows dann das erste 
vorzeitig bestätigen. Ich denke mal das ist eine akzeptable Lösung und 
verbraucht keine Reserven, außer ein bisschen Bandbreite.

CA Dirk

Sven K. schrieb:
> Hallo Dirk,
>
> also ich habe mich jetzt seit einer Woche mit der Firmware beschäftigt.
> Als Plattform benutze ich das Pollin Board.
> Ich benutze den letzten Softwarestand vom 23.05.2009 16:33.
> Der Telnet Server und der HTTP-Server läuft.
>
> NTP läuft nicht, egal was ich anstelle.
> Ich benutze eine IP Adresse und kein DNS Namen.
>
> Zum Test habe ich auch mal diese Zeilen genommen:
>
> unsigned long myip = IPDOT( 192l, 168l, 1l, 100l );
>
> while( 1 )
> {
> // mit IP auf Port 21 verbinden
> SOCKET = Connect2IP( myip, 21);
> // Verbindung okay ?
> if ( SOCKET != NO_SOCKET_USED ) break;
> if ( i > MAX_NTP_FAILED ) return( NTP_ERROR );
> i++;
> }
>
> So, ich erwarte also eine Client TCP Verbindung auf Port 21
> auf die IP 192.168.1.100. Es passiert aber nichts.
> Auch nicht im Netzwerkverkehr. (Wireshark)
>
> Auf dem Rechner mit 192.168.1.100 lauscht ein TCP Server auf dem Port.
>
> Diese eigene Funktion wird durch init() gestartet und
> durch printf_P kann ich auch sehen das er den Code ausführt.
>
> Hoffe Du kannst mir den entscheidenden Hinweis geben.
>
> Gruß Sven

Hallo Sven!

Hast du irgendwelche Sachen ausgeschaltet in der "Config.h"?
Also bei mir geht es mit der Firmware wunderbar. Benutze auch das Pollin 
NetIO.

Dirk will heute nochmal eine Version veröffentlichen, wo eine Menge 
Fehler
berichtigt worden sind!
Außerdem wird er noch ein SVN bereit stellen wo man immer den aktuellen
Stand bekommt.

Gruß Denny

@Sven K.

Hast du mal geschaut ob ein ARP durchkommt?

CA Dirk

Salut.

So, heute die letzte Version bevor ich in Urlaub fahre, dann habt ihr 
erst mal 2 Wochen ruhe vor mir :-). Wie Denny schon ankündigte gibt es 
einige Verbesserungen im Detail. Neues ist eigentlich nicht wirklich was 
hinzu gekommen. Die wichtigste Verbesserung betrifft direkt und indirekt 
den TCP-Stack. Der ist jetzt stabiler geworden. Das Board hängt sich 
jetzt bei Fehlern nicht mehr auf sondern bleibt nur kurz für einige 
Sekunden hängen. TCP ist halt kompliziert :-). Sonst gibt es nur 
Verbesserungen bei Telnet und einigen Treibern. Zudem möchte ich nochmal 
darauf hinweisen das man die Aktuelle Version auch immer per SVN sich 
besorgen kann. Programme dafür gibt es sogar für Windows in vielen 
Varianten. Die URL für SVN lautet.

 http://wiki.neo-guerillaz.de/usvn/svn/

Username und Passwort sind: anonymous

So, das wars erst mal.

P.s.: Sven K., probiere mal unter Telnet das ntp aus.

Hallo Dirk,

viel Spaß und gute Erholung im Urlaub. Ich habe mir verschiedene 
Projekte zum AVR Net IO von Pollin angesehen und das OpenMCP sagt mir 
von der Sourcecodestruktur zu. Leider komme ich zur Zeit mit OpenMCP 
nicht weiter, da die Netzwerkverbindungen nicht funktionieren.
( Zur Info: Alles unter Windows )
 Folgende Situation:

IP Adresse im Programmcode an meinen Netzwerkkreis angepasst, da DHCP 
nicht arbeitet. Im Sourcecode habe ich die Debugausgaben für TCP.c 
eingeschaltet.

1.) Ausgabe auf der seriellen Konsole beim Start nach einem Reset:
Microwebserver build on AVR-libc version: 1.6.6/20090309 $Id: main.c 132 
2009-05-22 3:22:47Z sharan $ $Revision: 134 $
UART initialisiert
STDOUT initialisiert
CLOCK initialisiert
Config gefunden (Pos: 0, Len: 2035, Offset: 13)
GPIO initialisiert
ADC initialisiert
1Wire Error
ENC28j60 initialisiert ( HW-Add: 00:03:6f:55:1c:c8 ) Halfduplex: Link 
ready
-+-> ARP initialisiert
 |-> UDP initialisiert
 |-> TCP (Hurrican-engine) initialisiert
 |-> Versuche DHCP-Config zu holen. DHCP-Client: DISCOVER ->Dicover 
gesendet ERROR -> Default Config
DHCP-Config Fehlgeschlagen
 |   IP     : 192.168.252.11
 |   Netmask: 255.255.255.0
 |   Gateway: 192.168.252.2
 |   DNS    : 192.168.252.2
Telnet-Server gestartet auf Port 23.
HTTP-Server gestartet auf Port 80.

Also ok bis auf DHCP ( Andere Projekte wie Uli Radig und RoBue 
funktionieren mit DHCP)

2.) Ping -t 192.168.252.11 funktioniert.
3.) Aufruf von http://192.168.252.11 Ausgabe auf der seriellen Konsole:

Kommende Verbindung auf Port 80 [SYN] auf Socket 0
VerbinduVerbindunVerbindungszuordnung auf Socket 0
Richtige reinfolge der Packete!
0 Byte befinden sich im Recivebuffer [PSH + ACK] 128 Byte empfangen
Bestaetigung gesendet [ACK]
Verbindung ist aufgebaut und READY2USE [ACK]
gEmpfang bestaetig [ACK] SendState aud READY2SEND
nÿVerbindungszuordnung auf Socket 0
Falsche reinfolge der Packete!
Verbindungszuordnung auf Socket 0
Falsche reinfolge der Packete!
Verbindungszuordnung auf Socket 0
Falsche reinfolge der Packete!
Verbindungszuordnung auf Socket 0
Falsche reinfolge der Packete!
Verbindungszuordnung auf Socket 0
Falsche reinfolge der Packete!
Verbindungszuordnung auf Socket 0
Empfang bestaetig [ACK] SendState aud READY2SEND
Kommende Verbindung auf Port 80 [SYN] auf Socket 1
VerbiVerbiVerbindungszuordnung auf Socket 1
Richtige reinfolge der Packete!
0 Byte befinden sich im Recivebuffer [PSH + ACK] 128 Byte empfangen
Bestaetigung gesendet [ACK]
Verbindung ist aufgebaut und READY2USE [ACK]
nEmpfang bestaetig [ACK] SendState aud READY2SEND
nVerbindungszuordnung auf Socket 1
Buffer Error
Verbindungszuordnung auf Socket 1
Buffer Error
Verbindungszuordnung auf Socket 1
Buffer Error
Verbindungszuordnung auf Socket 1
Buffer Error
Verbindungszuordnung auf Socket 1
Buffer Error

Keine Anzeige im Browser.

4.) Telnetverbindung zu 192.168.252.11 Ausgabe auf der seriellen 
Konsole:

Kommende Verbindung auf Port 23 [SYN] auf Socket 0
VerbiVerbindungszuordnung auf Socket 0
Richtige reinfolge der Packete!
0 Byte befinden sich im Recivebuffer [PSH + ACK] 21 Byte empfangen
Bestaetigung gesendet [ACK]
Verbindung ist aufgebaut und READY2USE [ACK]
VEmpfang bestaetig [ACK] SendState aud READY2SEND

Keine Anzeige im Telnet client ( putty )

5.) Beim dem Versuch der Telnetverbindung bricht auch der Dauerping ab 
und das Board hat sich "aufgehangen".

Hast Du oder irgend jemand eine Idee woran das liegt? Software stand 
27.5.2009 vom SVN. Bei anderen scheint es ja zu funktionieren. In der 
Hoffnung das schnell in den Griff zu bekommen und dann auch produktiv 
mitwirken zu können.

Sigurd

Hallo  Sigurd,

ich habe nach meinem Urlaub mir die Version vom 27.05.2009 geholt und 
auf mein AVR-NET-IO eingespielt. Ich habe die gleichen Erscheinungen so 
wie du sie beschrieben hast. Dann habe ich eine alte Version von vor 
meinem Urlaub eingespielt und diese zeigte auf einmal das gleiche 
Verhalten.
Nach vielen Versuchen fand ich das ich vor meinem Urlaub die Schaltung 
von einem anderen USB-Port mit Spannung versorgt hatte. Nach Umstecken 
auf den ehemaligen Port bekam ich sofort eine im Browser. Nun habe ich 
die Version vom 27.05.2009 eingespielt und siehe da, auch diese Version 
lief jetzt auf anhieb.
Ein Vergleich der Spannungen zeigte im Schlechtfall eine Spannung von 
4,4V / 2,8V und im Gutfall 4,5V / 2,9V. Wie genau die Spannung des ENC 
sein muß, weiß ich nicht.

Prüfe einmal deine Spannungen. Vielleicht hast du den Fehler dann 
gefunden.

Gruß
Karl Albert

Hallo

hat man das Pollinboard orginal zusammengebaut sollte man an der 
Spannungsversorgung mind. 8V anlegen. Ansonsten arbeitet der 7805er 
nicht richtig und die 3,3V stimmen dann auch nicht.

Gruß Denny

Hallo Karl Alber, hally Denny,

ich denke nicht, dass es an der Hardware liegt. Inzwischen habe ich auch 
Linux installiert und dort ethersex kompiliert. Das läuft auch mit allen 
Modulen. Nun stecke ich in der Zwickmühle. OpenMCP hat mir von der 
Modulaufteilung zugesagt und ist da es unter Windows kompiliert werden 
kann für mich einfacher zu handhaben. Ethersex ist auch sehr gut 
strukturiert, kann zur Zeit aber nur unter Linux gebildet werden. 
OpenMCP läuft scheinbar bei allen und bei mir funktiert die 
Netzwerkverbindung prinzipiell, ICMP echo ist ok. Sobald aber Telnet 
oder HTTP benutzt wird klemmt es. Ich dachte es sei einfach zu lösen.

Sigurd

Hallo,

so, bin wieder aus meinen Urlaub zurück. War echt klasse, kann Japan nur 
empfehlen :-).

@Sigurd

Das mit dem DHCP sieht schon komisch aus, er erhält vom DHCP noch nicht 
mal eine Antwort. Sollte eigentlich so in etwa aussehen:

 |-> Versuche DHCP-Config zu holen. 
DHCP-Client: DISCOVER ->Dicover gesendet
DHCP_MESSAGES_TYPE gefunden 02
Server-ID gefunden 0102A8C0
Leasetime gefunden 201C0000
SUBNETMASK gefunden 00FFFFFF
ROUTER gefunden 0102A8C0
DNS-Server gefunden 0102A8C0
 OFFER -> REQUEST ->DHCP_MESSAGES_TYPE gefunden 05
Server-ID gefunden 0102A8C0
Leasetime gefunden 201C0000
SUBNETMASK gefunden 00FFFFFF
ROUTER gefunden 0102A8C0
DNS-Server gefunden 0102A8C0
 ACK -> Config
DHCP-Config geholt

Für mich stellt sich die Frage was zu für ein Netzwerk verwendest. Es 
sollte zumindest ein NACK vom DHCP kommen. Beim Pollin-Board verwendest 
du die Standarthardware mit einem ATmega644?
Beim Rest sieht es auch so aus als wenn es Probleme mit dem Netzwerkchip 
gibt, da er wohl Packete Verschluckt. Hast du mal eine ältere Version 
vom OpenMCP genommen. Und Versuche mal in der Network.c im System/net/ 
Verzeichnis die folgende Zeile in die network.c in Zeile 103 
einzutragen.

enc28j60EnableFullDuplex();

so das er versucht auf jedenfall Fullduplex zu verwenden.

CA Dirk

P.s. Werde nachher mal eine neue Version vom OpenMCP auf das SVN packen 
wo man in der Config.h zusätzlich Full/Halfduplex wählen kann.

Hallo Dirk,

Danke für die Antwore. Ich bin im Moment etwas eingespannt und komme 
nicht immer zum "Basteln". Daher erfolgen die Rückmeldungen hier nur 
sporadisch.

Also ich benutze das Standard Pollin board mit ATMega644. Den 
Fullduplexmode werde ich ausprobieren, sobald ich etwas Zeit habe. Was 
mich stuzig macht ist, daß die gleiche Hardware mit anderen "Webservern" 
funktioniert auch DHCP. Ich werde aber dran bleiben und weiter 
berichten. Vielleicht liegt es wirklich an meiner 
Hardwarezusammenstellung. Um den Switch auszuschließen ( 1GBit D-Link) 
habe ich das Board nun direkt an die Fritzbox angeschlossen ( 100MBit ). 
Die Boardhardware schließe ich auf Grund des Verhaltens aus. Ich benutze 
allerdings einen Bootloader. Der macht aber bei allen anderen Projekten 
keine Probleme.

Alter Versionen von OpenMCP habe ich noch nicht probiert.
Wann wurde den die FIFO Speicherung hinzugefügt?

Viele Grüße
Sigurd

@Sigurd

Okay. Die FIFO wurde im März 2008 hinzugefügt und macht eigentlich auch 
keine Probleme. Das mit dem Bootloader wäre mal interessant. Denn der 
benutzt ja auch Register beim Booten die auch vom OpenMCP benutzt 
werden. Vielleicht macht das ja Probleme. Kannst ja mal versuchen den 
Bootloader abzuschalten wenn das geht, sonst würde mir nix weiter 
einfallen.

CA Dirk

Hallo Dirk,

ich habe alles ausprobiert. Keine Änderung. Ich werde nun noch einmal 
das ganze Projektbasierend auf build 152 neu aufsetzen . Mal sehen was 
sich dann tut. Debugging ware eingeschaltet für ethernet.c und dhcp.c. 
Jede sekunde kommt eine Meldung IRQ Empfang eingeschaltet gefolgt von 
der Meldung IRQ Empfang abgeschaltet. Ist das normal?


Sigurd

Hallo,

Das mit der IRQ-Meldung ist normal, denn bei jeden Zugriff auf 
Netzwerkresourcen wird der Empfang gesperrt damit bei der Abfrage der 
Verbindungen nix dazwischen funkt. Und zugreifen tun der telnetserver 
und der httpserver um auf neue Daten zu checken. Ich musste aber 
feststellen das die DEBUG-Ausgaben gefährlich sind, da die Ausgaben per 
printf passieren. Wenn jetzt Ausgaben im Interrupt gemacht werden geht 
das total schief. Also lieber nicht verwenden, das muss ich wohl nochmal 
überarbeiten. Ich habe aber in den Logs die du mir geschickt hast 
gesehen das du Halfduplex verwendest und auch jedesmal das EEprom neu 
geschrieben wird wenn du startest. Hast du mal an den Fuses gespielt für 
Brownoutdetection? Es ist ratsam das BOS eingeschaltet ist. Oder löscht 
du jedes mal auch das EEProm beim flashen?

CA Dirk

Hallo Marco,

wo liegt das Problem? Bei der Implementierung oder wie du es anstellen 
sollst. Am besten wäre es sicherlich ein eigenes Modul dafür zu 
schreiben. Hast du dich schon mit dem CGI-Interface auseinander gesetzt?

CA Dirk

Hallo,

sorry, habe den Post übersehen. Eigentlich will ich keine 
Programmieraufgaben für andere Leute erledigen, dazu ist meine Zeit 
schon so zu knapp. Ich bin aber gerne bereit Hilfestellung zu leisten.
Die Überschrift kannst du in der apps/httpd/files_data.h ändern. Die 
Bezeichnungen für die Ausgänge findest sich in der apps/httpd/cgi-bin.c 
ab Zeile 550 in etwa. Für das Automatische setzen der Ausgänge würde 
sich das Cron-Interface anbieten. Allerdings arbeitet es nur im 
Minutenraster. OpenMCP mit Cron-Funktion/Interface kannst du im 
aktuellen SVN finden, ich werde es aber demnächst auch die aktuelle 
Fassung hier posten.
Aber deine Aufgabenstellung sieht eher danach aus als wenn das schon 
fast ein eigenes Modul wird. Und das wird leider ein bisschen Aufwand 
mit deiner Aufgabenstellung.

CA Dirk

@Marco,

ich kann mich mal bei Gelegenheit daran setzen, aber kein versprechen 
machen das das zum Datum XY fertig wird. Spielt ja auch keine Rolle wenn 
du schon seid Monaten daran bastelst ;-).

CA Dirk

Dirk Broßwick schrieb:
> Salut.
>
>....
>
> Zudem möchte ich nochmal
> darauf hinweisen das man die Aktuelle Version auch immer per SVN sich
> besorgen kann. Programme dafür gibt es sogar für Windows in vielen
> Varianten. Die URL für SVN lautet.
>
>  http://wiki.neo-guerillaz.de/usvn/svn/
>
> Username und Passwort sind: anonymous
>
> So, das wars erst mal.
>
> P.s.: Sven K., probiere mal unter Telnet das ntp aus.

Hallo Dirk - habe Checkout mit SVN auf 
http://wiki.neo-guerillaz.de/usvn/svn/ versucht, leider Fehlschlag ... 
mache ich was falsch?
----------------------------
Checkout from http://wiki.neo-guerillaz.de/usvn/svn, revision HEAD, 
Fully recursive, Externals included
Repository moved temporarily to '/usvn/login/'; please relocate
----------------------------

dann mit geänderter URL:
----------------------------
Checkout from http://wiki.neo-guerillaz.de/usvn/login, revision HEAD, 
Fully recursive, Externals included
The OPTIONS response did not include the requested 
activity-collection-set;
this often means that the URL is not WebDAV-enabled
----------------------

Was nu ?

Danke im voraus!

Hallo,

die Adresse die ich angeben habe ist für das Webinterface gedacht, damit 
man erst mal rein sehen kann. Dort erfährt man dann auch den Link für 
den Checkout. Dieser würde dann heißen:

http://wiki.neo-guerillaz.de/usvn/svn/webserver2561

Damit sollte es dann mit jeden gängigen SVN-Tool gehen.

CA Dirk

Dirk Broßwick schrieb:
> Hallo,
>
> die Adresse die ich angeben habe ist für das Webinterface gedacht, damit
> man erst mal rein sehen kann. Dort erfährt man dann auch den Link für
> den Checkout. Dieser würde dann heißen:
>
> http://wiki.neo-guerillaz.de/usvn/svn/webserver2561
>
> Damit sollte es dann mit jeden gängigen SVN-Tool gehen.
>
> CA Dirk
Habe login mit anonymous versucht, lande bei

http://wiki.neo-guerillaz.de/usvn/svn/

Zugriff verweigert!

Der Zugriff auf das angeforderte Verzeichnis ist nicht möglich. Entweder 
ist kein Index-Dokument vorhanden oder das Verzeichnis ist 
zugriffsgeschützt.

Sofern Sie dies für eine Fehlfunktion des Servers halten, informieren 
Sie bitte den Webmaster hierüber.
Error 403
wiki.neo-guerillaz.de
Sun Jul 26 15:04:37 2009
Apache/2.2.3 (Linux/SUSE)

Sorry!

> Habe login mit anonymous versucht, lande bei
>
> http://wiki.neo-guerillaz.de/usvn/svn/
>
> Zugriff verweigert!
>
> Der Zugriff auf das angeforderte Verzeichnis ist nicht möglich. Entweder
> ist kein Index-Dokument vorhanden oder das Verzeichnis ist
> zugriffsgeschützt.
>
> Sofern Sie dies für eine Fehlfunktion des Servers halten, informieren
> Sie bitte den Webmaster hierüber.
> Error 403
> wiki.neo-guerillaz.de
> Sun Jul 26 15:04:37 2009
> Apache/2.2.3 (Linux/SUSE)
>
> Sorry!

Hallo,

habe es eben nochmal von 3 Rechnern aus versucht mit einen SVN-Programm 
einen checkout zu machen, kein Problem. Selbst per Webinterface geht es 
wunderbar wenn ich http://wiki.neo-guerillaz.de/usvn/svn/webserver2561/ 
aufrufe und als Username und Passwort "anonymous" eingebe. Mit einen Was 
benutzt du für ein SVN-Programm ?

CA Dirk

@Marco Dittmann,

siehe mal einfach in der ntp.h nach, und dort

  #define GMT_TIME_CORRECTION 3600  //1 Stunde in Sekunden

nach

  #define GMT_TIME_CORRECTION 7200  //2 Stunden in Sekunden

ändern.

Das zum Zeitproblem. Beim anderen muss ich heute Abend erst mal einen 
blick rein werfen in die Sourcen. Und als Gegenfrage, wo hast du deine 
Änderungen gemacht?

CA Dirk

Hallo, ich habe wie einer der Vorposter auch das Problem, dass per DHCP 
keine Adresse zugewiesen wird.
Als DHCP-Server habe ich ebenfalls eine Fritz Box im Netz.

Um auszuschließen, dass die Problematik irgendwas mit der Fritz Box zu 
tun hat, habe ich deren DHCP ausgeschaltet und den DHCP-Server von hier: 
http://ruttkamp.gmxhome.de/dhcpsrv/dhcpsrv.htm eingesetzt.

Dieser Server bekommt wohl die DHCP-Anfrage meines AVR-Net und 
beantwortet sie mit einem Broadcast, aber trotzdem meldet OpenMCP 
"DHCP-Config fehlgeschalgen".

Hier das Log des DHCP-Servers:
[08/06/2009 17:32:45] Adapter 0 has recognized an incoming request
[08/06/2009 17:32:45] DHCP message = DHCPDISCOVER
[08/06/2009 17:32:45] client identifier (option 61) is not recognized
[08/06/2009 17:32:45] Lookup client data for physical address "00-03-6F 
55-1C-C8" / client_id "00-03-6F-55-1C-C8"
[08/06/2009 17:32:45] Client 00-03-6F-55-1C-C8 is not configured
[08/06/2009 17:32:45] Perform auto configuration
[08/06/2009 17:32:45] IPPOOL_1: 192.168.210.10-14
[08/06/2009 17:32:45] Auto configuration succeeded: IP-Addr = 
192.168.210.10
[08/06/2009 17:32:45] Response: offer the configured IP address (lease 
time = 86400)
[08/06/2009 17:32:45] Sending a broadcast response to the client

Hallo Marc,

sorry, das ich den Post nicht gleich gelesen habe. Aber so wie ich das 
sehe versteht keiner dein Problem genau und kann mit dem Code nix 
anfangen. Ich persönlich finde den Code (main.c & httpd.c) mehr als 
unübersichtlich und auch nicht leserlich.
Wenn ich es noch richtig in Erinnerung habe wolltest du 2 Relais 
abwechselnd schalten in bestimmten zeitlichen Abständen, und das einmal 
mit Automatik oder Manuell und das steuerbar per Webinterface. Ich habe 
eben mal versucht den Code zu überfliegen ... ich blicke bei den, sorry 
für die Worte, ich weiß das es nicht dein Projekt/Code ist, einfach 
nicht durch. Vor allem wo was geändert wird und wo was her kommt.

CA Dirk

Hallo Marco,

ist dir mal aufgefallen das die Variable time1 in der main.c nur ein 
char ist, und gar nicht so hoch zählen kann und deshalb der Vergleich 
mit dem Wert aus dem Array (typ int) ein bisschen albern ist? Versuch 
mal ein int daraus zu machen.

CA Dirk

p.s. Werde morgen mal genau reinschaun, aber jetzt nach der schicht habe 
ich keine lust mehr dazu.

Hallo,

in der main.c. Dort ist eine variable time1 als unsigned char 
deklariert.

unsigned char time1=0;

mach daraus mal

unsigned int time1=0;

CA Dirk

Hallo Hopfrl,

die Ausgabe erfolgt schon mit 0.1 Grad. Dazu sei aber noch angemerkt das 
nicht alle Typen auch diese genauigkeit unterstützen. Welchen 
Temp-Sensor verwendest du denn ? Ich tippe mal auf den DS18S20?

CA Dirk

Salut,

Abhilfe schafft da z.b. ein DS18B20 so wie ich sie verwende. Bei mir in 
der Wohnung zeigen sie schön brav auf das 1/10 Grad genau an. Ein DS1822 
sollte auch noch gehen.

CA Dirk

P.S. Darf ich mal fragen ob du schon selber versucht hast OpenMCP zu 
übersetzen, und wenn ja unter welchen Betriebssystem?

Salut Char0n,

ja, es tut sich noch einiges beim Projekt :-). Auf dem AVR-NETIO werden 
derzeit der ATmega644/644P/1284P unterstützt sowie das myEthernet mit 
dem ATmega644P und dem Orginal OpenMCP mit dem ATmega2561/AT90CAN128. 
Der Code wird/wurde Aufgeräumt und besser Strukturiert. Allerdings hingt 
die Doku derzeit hinterher, so das ich diese Versionen erst mal nur per 
SVN bereit stelle.

CA Dirk

Moin Dirk,


leider funktioniert GPIO bei mir nicht, habe deshalb einmal ein Log vom 
Start und den EEPROM Inhalt gezogen:

--------------------------

OpenMCP ...

UART Initialisiert

STDOUT Initialisiert

CLOCK Initialisiert

LED_core Initialisiert

Config Initialisiert

EXTINT Initialisiert

TWI (0 Devices) Initialisiert

GPIO Initialisiert

ADC Initialisiert

1-WIRE Error

MMC/SD Error

SHELL Initialisiert

THREAD Initialisiert

ENC28j60 (Rev.: 6) initialisiert ( HW-Add: a2:c4:6f:66:c1:b5) 
Fullduplex: Link ready

-+-> ARP initialisiert

 |-> UDP (Tornado-engine) initialisiert

 |-> TCP (Hurrican-engine) initialisiert

 |   IP     : 194.01.2.210

 |   Netmask: 255.255.255.0

 |   Gateway: 194.01.2.50

 |   DNS    : 194.01.2.50

 |-> NTP-Server Zeit aktualisieren: fehlgeschlagen

HTTP-Server gestartet auf Port 80.

Telnet-Server gestartet auf Port 23.

-----------------------

Das EEPROM zeigt:

DHCP=off
IP=194.01.2.210
MASK=255.255.255.0
GATE=194.01.2.50
DNS=194.01.2.50
MAC=a2:c4:6f:66:c1:b5
ETH_FLDX=on
CRON_ENTRY_00=-1 -2 "gpio toggle 3"
NTP=on
NTPSERVER=time.fu-berlin.de
UTCZONE=+1

Meine Erwartungshaltung wäre, alle zwei Minuten togglet der Port 3.

Tut er nicht, was bitte mache ich falsch ?

Danke!

Vergessen einzuloggen ... obrige Antwort stammt von mir.

CA Dirk

@John

danke nochmal für den Hinweis, habe eben gesehen woher der Fehler 
stammen könnte. Habe das wiki zu Cron so eben aktualisiert.

CA Dirk

Dirk Broßwick schrieb:
> @John
>
> danke nochmal für den Hinweis, habe eben gesehen woher der Fehler
> stammen könnte. Habe das wiki zu Cron so eben aktualisiert.
>
> CA Dirk


Hallo Dirk, vielen Dank.

Ich habe da noch eine kleine Anregung(en).

Zur Verdeutlichung:

Die Lösung ist super, und ich würde sie gerne "as it is" zur Steuerung 
meines Garagentors und des Schwimmbeckens (Pumpen / Temperaturabfrage) 
einsetzen.

Für das Gragentor bräuchte ich einen ,5 Sekunden Impuls (als Taster)

Für die Pumpen einen Radio Button (Ein/Aus).

Die Temperatur würde ich mir notfalls selbst umrechnen (im Kopf) oder 
ich würde mir im EEPROM die Temperaturkurven der PTCs hinterlegen.

Aber im WebDesign bin ich eine totale Niete - Null Ahnung.

Wäre es nicht möglich, Deine Testanwendung so zu erweitern, dass 8 Radio 
Buttons, bzw. die Begung mit einem Impuls oder Dauer On/OFF direkt über 
HTML konfigurierbar und dann auch für DUAs nutzbar wären.

Damit wäre Dein Web-Server (mit 8 Radio Buttons) der Durchbruch für 
viele, die ebenfalls nicht das Know How haben, Deine Anwendung zu 
verändern.

Viele Grüße vom John

Salut ...

Die Entwicklung an OpenMCP läuft noch, hat im Sommer aber aus Prinzip 
nachgelassen. Aber da jetzt die kalte und dunkle Jahreszeit wieder kommt 
werde ich wohl wieder etwas mehr Zeit haben das Projekt weiter zu 
verfolgen.

CA Dirk

Salut Benjamin,

Ich vermute mal das in der passenden config.h im Bereich vom HTTP-Server 
noch eingestellt ist das er nur Dateien von SD-card laden soll. Schau 
mal einfach da rein. Leider kann ich gerade nicht sagen wie das #define 
dazu jetzt heisst da ich unterwegs bin.

Ca Dirk

Salut ...

ja, jetzt ist die interessante Frage was du im Makefile und in der 
entsprechenden config.h eingestellt hast. Bist du das [1] hier mal durch 
gegangen? Hast du die passende Hardware eingestellt? Was für Module hast 
du eingestellt?

CA Dirk

[1] http://wiki.neo-guerillaz.de/mediawiki/index.php/S...

Hi Dirk,

ich versuche gerade openMCP zusammen mit dem Ethernet-Bootloader (siehe 
hier: Beitrag "Re: Atmega via Ethernet flashen") zum Laufen zu 
bringen. Jedes für sich alleine hab ich zum Laufen gebracht, nun scheint 
es aber an ein Paar Bytes Größe zu hapern. Bei meinem Versuch das 
openMCP Image zu verkleinern, hab ich in der config.h einiges 
auskommentiert (LED's, Shell, LCD, DCF77, etc.) aber beim make'en wird 
immer noch ALLES kompiliert und schließlich brichts auch meistens ab 
wegen fehlender Abhängigkeiten, z.B:

system/sensor/temp.o: In function `TEMP_readUDPtemp':
U:\Unternehmen\NET-IO\OpenMCP/system/sensor/temp.c:339: undefined 
reference to `LED_off'

Ich benutze die openMCP Version vom 26.9.2010.

Hättest Du irgendein Tipp für mich?

Achja, ich benutze den Pollin AVR-NETIO mit einem ATMEGA644p.

viele Grüße,
Ethan

@Ethan

jup ... versuche mal am besten eine Version aus dem SVN. Dort sind die 
meisten Fehler schon bereinigt. Alternativ kann ich heute mal eine 
Aktuelle Version als .zip drauf packen. Ansonsten einfach mal 
auskommentieren :-). Die Versionen nach dem August sind alle ein 
bisschen buggy da ich im August ein kleines Problem hatte mit meinem 
Rechner ( Festplatte, krypto und so ) und viele Änderungen verloren 
gegangen sind. Eine Möglichkeit ist es auch den AVG-GCC 4.2.4 zu nehmen 
statt einen aktuellen wie dem 4.3.4, der erzeugt kleineren Code.

CA Dirk

Hallo,

ich benutze jetzt die SVN Version, nach einigen Tagen Bastelei (auch mit 
diversen anderen Sachen) bin ich soweit ganz happy, nur eines stört mich 
momentan sehr: Die NTP Funktion scheint fast nie zu gehen. Ich hab schon 
sehr oft verschiedene NTP Server eingetragen, jedesmal werden die 
Einstellungen auch übernommen und in der EEconfig angezeigt, aber ich 
hab bis jetzt (von ca. 50 Versuchen an 3 Tagen) nur ein einziges Mal 
erlebt daß Datum/Uhrzeit plötzlich gestimmt haben. Ich tue auch jedesmal 
den unteren Frame neuladen (benutze Firefox, muß andauernd die einzelnen 
Frames refreshen weil fast alles nur aus dem Cache genommen wird wenn 
ich rumklicke) Ich krieg auch nirgends irgendein feedback ob der Server 
überhaupt eine NTP Abfrage macht oder wie dieser gelaufen ist.

Wie kann ich die NTP Funktion am besten debuggen?

viele Grüße,
Ethan

Hab jetzt die RS232 Konsoel dranhängen und beim Booten kommt immer:

NTP-Server Zeit aktualisieren: fehlgeschlagen

Aber warum?

Ich rast bald aus... jetzt hat er es mal wieder geschafft, dann mußte 
ich aber wegen was anderem resetten und jetzt hab ich bestimmt 50 Mal 
resettet und jedesmal ..."fehlgeschlagen". Nach etwa 5 Sekunden. Woran 
kann das nur liegen? DNS zu langsam? Timeout zu kurz? Sonst ne Idee?

@Ethan

Ich habe das Problem auch schon festgestellt, allerdings nur in 
Verbindung mit 1GE Switches, warum auch immer. Ich suche selber noch den 
Fehler. Wenn sich da was tut wird man das merken.

CA Dirk

Hi Dirk,

Danke für den Hinweis, ich hab tatsächlich ein 1GE Switch dran, mal 
testen ob es mit einem 100er dazwischen besser klappt. Ansonsten guck 
ich mich mal im Code um, vielleicht mal mehrere Poll-Versuche mit NTP 
machen (kann ja auch im Hintergrund weiterlaufen) und Timeouts 
verlängern.

Gruß,
Ethan

Also ein 100er Hub hilft da auch nicht, hab auch FDX und HDX probiert, 
verschiedenste Server probiert und dabei mit Wireshark mitgeloggt, auf 
dem PC einen NTP Server installiert und von einem Linux rechner aus 
getestet, und dabei festgestellt: Der OpenMCP client sendet überhaupt 
keine Anfrage raus! Da kann natürlich auch keine Antwort kommen :-(

@Ethan,

ich hab heute Nacht mal eine neue SVN-Version rauf geschoben, probiert 
die mal bitte aus. Bei mit trat das Problem jetzt so nicht mehr wirklich 
auf.

CA Dirk

Hi Dirk,

hab mir grad die neue per SVN geholt, aber leider immer noch das 
Problem.
Hab jetzt Telnet aktiviert und bin reingegangen und gebe immer wieder 
"ntp de.pool.ntp.org" ein aber nur 1 aus 10 Mal funktioniert es:

Und, los geht's...!!! ("help" hilft :-))
> ntp de.pool.ntp.org
Hole Zeit von de.pool.ntp.org
Fehler
> ntp de.pool.ntp.org
Hole Zeit von de.pool.ntp.org
Neue Zeit: 21:12:32
>

Wenn ich die IP Adresse von meinem Arbeitsplatz-PC angebe, kommt dort 
gar keine Anfrage an. Also scheint es irgendwo zu haken bevor das erste 
NTP Paket rausgeht. Evtl die DNS Abfrage? Aber wenn ich die IP direkt 
eingebe müßte keine DNS erfolgen oder?

Gruß,
Ethan

@Ethan,

so, ich habe das mal mit deinen NTP-Server probiert ... de.pool.ntp.org 
. Dabei habe ich festgestellt das bei weitem nicht alle NTP-Server das 
kleine NTP auf UDP-Port 37 beherrschen. Die DNS-Anfragen werden alle 
richtig beantwortet, aber jedes mal mit einer anderen IP um eine 
Lastverteilung zu machen. Ich selber benutze immer time.fu-berlin.de da 
dort auch das kleine NTP angeboten wird.
Man könnte auch richtiges NTP einbauen, aber das ist ungleich 
komplizierter da dort auch eine Zeitmessung gemacht wird wie lange z.B. 
ein Packet braucht und so weiter um das mit zu berücksichtigen.

Also kein Fehler im eigentlichen sinne ...

CA Dirk

P.S.: Probieren kannst du das mit den IPs wenn du mal "dns 
de.pool.ntp.org" eingibst und das mehrmals.

Hi Dirk,

daß man unter der pool-ip laufend wechselnde IP's kriegt war mir klar, 
das ist da der Sinn eines Pools. Aber obwohl ich nach SNTP Infos gesucht 
hatte, wurde überall nur gesagt "SNTP ist ein etwas einfacheres NTP" 
aber nirgends hab ich Details gefunden, z.B. daß es über einen anderen 
Port läuft. Wenn ich das gewußt hätte, hätt ich gezielter nach dem 
Problem suchen können.

OK dann bin ich ja jetzt viel schlauer :-) vielen Dank für Deine Hilfe!

Vielleicht implementiere ich trotzdem noch einen RTC-Chip, denn die 
Uhrzeit-Abhängigkeit beim Datenloggen ist ja doch recht kritisch...

Was ich als nächstes angehen möchte ist eine Erweiterung der 
Graph-Funktionalität, z.B. hätte ich gerne einen zusätzlichen Graphen 
mit 1 Minute Auflösung für die letzten 60 Minuten, sowie mehrere (z.B. 
7) Tage rückwirkend abfragbar. Vielleicht versuche ich auch die Daten 
als CSV auf der MMC ablegen zu lassen, damit sie einfacher am Rechner 
importiert werden können. Und schließlich die Hauptaufgabe die ich mit 
dem Board realisieren will: Eine Wärmepumpensteuerung (dazu brauchts im 
Prinzip nur noch 3 Schaltausgänge 230V die ich mit Triacs oder 
Doppel-Thyristoren realisieren will), samt Konfig-Interface unter 
welchen Bedingungen (Temp-Sensor, Zeitspanne) welcher Ausgang wie zu 
schalten ist.

viele Grüße,
Ethan

EDIT: Wieso ist eigentlich aus dem Web-Netzwerkkonfig die 
Duplex-Wahlmöglichkeit rausgeflogen?

@Ethan

Das mit den Voll/Halbduplex habe ich raus genommen weil das eh keiner 
mehr brauchst, eigentlich hat jeder zu hause einen Switch. Und es hat 
ein paar Byte Flash gespart, da das Projekt eh gerade mal so in einen 
644 passt :-).

CA Dirk

P.S.: Was für einen RTC-Chip benutzt du? Ich wollte die Tage noch 
Support für den DS1307 einbauen.

Hab mir noch keinen RTC rausgesucht, war bisher nur eine spontane Idee. 
Der DS1307 ist nicht gerade billig, nach kurzem Blick im RS-Katalog 
erscheint mir z.B. der ISL1208IB8Z deutlich günstiger, ausserdem bin ich 
eher ein SMD-Fan. Hab mich aber noch nicht damit auseinandergesetzt, hab 
nur kurz nach I2C und 3.3V/5V und Batteriepuffer geguckt.

Hallo,

den DS1307 gibts auch als SMD ;-) und nicht sooo teuer...

http://www.reichelt.de/?ACTION=3;ARTICLE=58150;PROVID=2402

Gruß Sven

Ethan Arnold schrieb:
> Hab mir noch keinen RTC rausgesucht, war bisher nur eine spontane Idee.
> Der DS1307 ist nicht gerade billig, nach kurzem Blick im RS-Katalog
> erscheint mir z.B. der ISL1208IB8Z deutlich günstiger, ausserdem bin ich
> eher ein SMD-Fan.

Tatsächlich... ich sollte doch öfters auch mal bei Reichelt vergleichen. 
Bei RS kostet der über 3 EUR zzgl. MwSt.

Hi Dirk,

Okay, hab grad eh was dort bestellt und hab nen DS1307 gleich 
mitgenommen. Wenn da also Support für in der Mache ist... wär cool :-)

Gruß,
Ethan

Hi Dirk,

sagmal, wie kann ich dafür sorgen daß der Anfang des EEPROMs unbenutzt 
bleibt? Dort wird nämlich auch vom Bootloader config abgelegt und die 
beiden überschreiben sich gegenseitig. Ich hab schon versucht in der 
eeconfig.c einmal die "pos" und einmal die "offset" raufzusetzen (von -1 
auf 255) aber das ändert nichts, es wird immer noch angezeigt "offset: 
13" in der eemem.cgi abfrage. (Wieso eigentlich 13??? wenn es eigentlich 
0 sein müßte?)

Gruß,
Ethan

Kann es sein daß die Unixzeit (TIME.time) falsch ist? Ich versuche nun 
schon seit fast 8 Stunden ein einfaches cgi hinzubekommen was einfach 
nur "[unixtimestamp,temperatur]" liefert, also z.B. [1293315620,-11.50] 
für jetzt gerade (sogar aktuelle temperatur ;-) aber wenn ich folgendes 
mache:

struct TIME nowtime;
CLOCK_GetTime(&nowtime);
TEMP_Sensor2String(i, TEMPSTRING);
printf_P(PSTR("[%lu000,%s]\r\n"), nowtime.time, TEMPSTRING);

erhalte ich immer eine Zahl die viel zu hoch ist, nämlich statt 1,29 
milliarden erhalte ich immer über 4 milliarden, zählt zwar regelmäßig im 
sekundentakt hoch aber trotzdem falsch (wäre im Jahr 2038). Ich sitze 
nun echt seit 5-6 Stunden nur an dieser Zahl :-(((

@Ethan,

Offset 13 bezieht sich auf die Positionangabe, an dieser befindet sich 
eine Signatur das es sich um eine Config von OpenMCP handelt. Schau mal 
in die eeconfig.h, dort siehst du die Signatur.

Ja, das mit der Unixtime ist so eine Sache. Es ist genau genommen UTC. 
Also ab 1900 gezählt, das Problem ist das das kleine NTP UTC ausliefert 
und nicht Unixzeit. Unixzeit ist zudem auch Vorzeichenbehaftet, UTC 
nicht. Vielleicht sollte ich nochmal Extra darauf hinweisen. Eigentlich 
wollte ich auch Unixzeit implementieren, aber die Implementierung davon 
ist so besch**ert das ich das verworfen habe und UTC genommen habe. UTC 
geht aber auch bis ca 2036 :-).

CA Dirk

Hi Dirk,

aha, das erklärt so einiges :-) aber wieso ist die Konvertierung so 
schwer? Man muß doch nur eine Konstante abziehen (2,2 Milliarden und ein 
Paar Zerquetschte) oder? Ich probier's mal...

Bitte sag doch auch was dazu, wie ich den belegten EEPROM bereich 
verschieben kann! Ich hab den Bausatz nämlich immer noch am 
Schreibtisch-PC hängen obwohl er dringend in den Keller müßte um dort zu 
überwachen... das einzige was mir noch zu meinem Glück fehlt ist das 
funktionierende Ethernet-Flashen.

Gruß,
Ethan

@Ethan,

Tu was du nicht lassen kannst um aud UnixZeit zu kommen :-).

Den EEprombereich kannst du in eeconfig.c Zeile 178 verändern (Funktion 
makeConfig), dort die Variable Pos, die steht derzeit auf 0. Du kannst 
die Position dort ändern. Dazu musst du das EEprom löschen und OpenMCP 
einmal neu starten damit die Config an der neuen Position angelegt wird.

Hab grad einen dritten DS18xxxx Sensor angeschlossen und konfiguriert, 
und dabei einen Bug (glaube ich) entdeckt: Wenn der Sensor abgezogen 
wird, also nicht mehr erreichbar ist, wird im Config und im Templogger 
nicht "n/a" angezeigt wie es sein müßte, sondern -0.5°C angezeigt.

Hi tt,

Das aktuellste veröffentlichte hexfile das ich kenne ist das hier: 
http://www.mikrocontroller.net/attachment/51592/openMCP.zip (siehe 
Beitrag hier im Thread vom 27.5.2009). Aber wenn Du schon einen 
Programmer hast, wo ist das Problem sich win-avr zu besorgen und es 
selbst aus dem svn-checkout zu kompilieren? Hat bei mir ziemlich auf 
Anhieb geklappt (auch für den Net-io), mußte nur eine Handvoll 
Einstellungen in der config.h machen.

Gruß,
Ethan

Wenn die MMC Card im betrieb entfernt wird, stürzt openMCP unweigerlich 
sofort ab, auch wenn die Karte vor dem Wiedereinstecken nicht 
beschrieben wird. Was kann ich tun um das zu verbessern? Die Karte hat 
ja einen Sensorkontakt, wird der denn nicht abgefragt?

Ethan Arnold schrieb:
> Die Karte hat ja einen Sensorkontakt, wird der denn nicht abgefragt?

Mal durchgemessen ob der auch am EXT Veränderungen anzeigt? Tut er 
nämlich bei mir nicht.

Du meinst, ob beim ziehen/stecken der Karte der Pegel sich ändert? Ja, 
tut er. PD7 ist +3.6V bei gezogener Karte und 0V bei gesteckt.

Übrigens stürzt openmcp bei mir leider recht oft auch so ab, scheinbar 
umso schneller (teilweise schon nach 1-2 minuten) je intensiver die 
Webseiten abgefragt werden. Wenn ich per Javascript und Livechart alle 2 
Sekunden eine kurze cgi (gibt per http 16 Zeichen aus) aufrufe, läufts 
selten länger als ne stunde.

Vielleicht liegt es an 2 oder mehr gleichzeitigen http-requests? Ich hab 
unten die Statusframe auf autorefresh alle 30sek und die templogger 
grafik auf alls 60sek, und die livechart holt sich alle 2 sekunden ein 
paar bytes. Ist da irgendwas bekannt?

@Ethan,

bei der MMC gibt es nix zu verbessern, es sei denn man baut 
Hotplug-Support ein. Und es Hilft auch nix wenn man vor dem nächsen 
schreiben/lesen die Karte wieder einsteckt, denn die MMC will auch 
initialisiert werden was nicht ganz trivial ist.

Zu dem Problem mit dem Abstützen: OpenMCP b.z.w. das AVRNETIO ist kein 
Supercomputer oder gar ein vollwertiger Webserver der XY Anfragen in der 
Sekunde verarbeiten kann. Deshalb alles immer schön der Reihe nach. Und 
sicher das OpenMCP abstürzt? Woran machst du das fest?

Ich bin zwar immer bemüht alles nach besten Wissen und Gewissen zu 
machen aber ich kann leider nicht vorhersehen was der Benutzer damit 
anstellt. OpenMCP an sich ist schon recht Stabil von meiner Seite aus, 
ich selber verbringe sehr viel Zeit damit und treibe auch ordentlich 
Aufwand nach Fehlern und Schwachstellen zu suchen.
Hast du denn mal versucht raus zu bekommen Wo oder bei welcher Aktion 
denn der Controller stehen bleibt? Bleibt er denn wirklich stehen? Geht 
Ping noch? Blinkt die LED1 auf dem ADD-ON? Da du selber schon Code 
eingefügt hast: Verbrauchst du vielleicht zu viel RAM und erzeugt einen 
Stackoverflow der in bestimmten Situationen auftritt? Arbeitest du mit 
Interrupts in deinem Code? Fängst du auch alle erdenklichen Fehler ab im 
Programm?

CA Dirk

Hi Dirk,

Du mußt die Leistung des Servers nicht derart herunterspielen, mir ist 
durchaus bewußt was hier auf kleinem Raum geleistet wird und bitte 
verstehe meine Fragen nicht im Sinne von "wasn das fürn scheiss, dat 
läuft ja net" sondern ich bin Dir extrem dankbar für das Ganze und ich 
finds ungemein nützlich und interessant und eine super Basis für meine 
eigenen ersten Schritte in der Weiterentwicklung für eigene Zwecke. Ich 
hab schon Mitte der 80er Jahre als Jugendlicher den Atari 800XL (6502, 
64k RAM, ähnlich dem C64) in Maschinensprache programmiert (hatte keinen 
Assembler oder gar C Compiler, da gabs keine Variablen und define's und 
Labels, da wurde jeder Befehl von Hand auf Papier in Zahlen übersetzt, 
Sprünge manuell berechnet, und per for...next...poke x,y Schleife in den 
Speicher geschrieben. Ich bin aber nicht die ganze Zeit so freakig 
geblieben g ich hab viel Elektronik-Allgemeinwissen und hab auch 1 
Jahr auf PIC entwickelt aber das ist auch schon Jahre her. Daher ist 
jetzt AVR von der Grundsache her bekannt aber ich muß mich erst 
einarbeiten. Aber es ist mir schon klar daß der Atmega mit einem 
einzigen html-Seitenabruf für 1-2 Sekunden alle Hände voll zu tun hat 
und man nicht viel mehr verlangen kann. Tue ich auch nicht.

Ich mache das Abstürzen daran fest, daß überhaupt keine http Anfrage 
mehr beantwortet wird, nie mehr. Ping reagiert auch nicht mehr. Das 
Addon Board hab ich nicht daher auch keine LED, hab nur die MMC gemäß 
Schaltplan des Pollin Addon Boards angeschlossen. Kann aber mal checken 
ob die LED blinken würde wenn sie da wäre, dazu muß ich aber erstmal die 
LED wieder mit reinnehmen und neu compilen+flashen. Die einzigen 
Aktionen die ich mache sind http Abfragen also kann ich nicht genauer 
sagen woran es hängt. Ich hab als einzige eigene Erweiterung eine 
Abwandlung Deines cmd_onewire als cgi ergänzt, sonst nichts. Aber auch 
wenn ich die gar nicht benutze taucht das Problem auf. Wenn ich gar 
keine http anfragen schicke dann läuft das Teil meistens problemlos 
durch, auch über Nacht. Aber wenn ich irgendeine Seite offenlasse dann 
wird die untere Statuszeile alle 30sek per REFRESH neu geladen, und wenn 
ich die templogger Seite offenlasse dann auch die Grafik alle 60sek, und 
wenn ich das stundenlang so lasse dann komme ich fast immer zurück und 
finde ein "Zeitüberschreitung" auf dem Bildschrim und der AVR reagiert 
auf gar keine http Anfrage mehr (und kein Ping). Ausser den REFRESH in 
den html-header einzubauen hab ich an der templogger Sache nix geändert.

Zum Thema MMC, wie wäre es mit einem Interrupt wenn die Karte 
eingesteckt wird und dann kann sie ja neu initialisiert werden? Oder ist 
das einfacher gesagt als getan? Ich wollt Dich eh fragen, schreibst Du 
bei jedem Datei-Schreibvorgang auch den Verzeichniseintrag fertig (also 
"Datei schließen") oder läßt Du die Datei offen? Ersteres hat den 
Vorteil erhöhter Ausfallsicherheit (bei Stromausfall oder Kartenziehen) 
aber den Nachteil daß das Flash auf der Karte ziemlich oft beansprucht 
wird und irgendwann Schaden nehmen wird.

viele Grüße,
Ethan

Meine angepaßte cgi (auf Grundlager Deiner cmd_onewire), liefert Daten 
für einen Livechart wie hier 
(http://www.highcharts.com/studies/live-server.htm) beschrieben:

#include <avr/pgmspace.h>
#include <avr/version.h>
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <math.h>

#include "config.h"

#include "apps/httpd/cgibin/cgi-bin.h"
#include "system/sensor/temp.h"
#include "system/clock/clock.h"

#include "livedata.h"

void init_cmd_livedata( void )
{
#if defined(HTTPSERVER_ONEWIRE)
  cgi_RegisterCGI( cgi_livedata, PSTR("livedata.cgi"));
#endif
}

void cgi_livedata( void * pStruct )
{
  struct TIME nowtime;
   int i;
  char TEMPSTRING[10]="\0";

  for ( i = 0 ; i < 1 ; i ++ ) // TEMP_MAX_SENSORS
  {
    CLOCK_GetTime( &nowtime );
    nowtime.time-=2208988800L; // nowtime provides utc (from 1900), correction for unixtime
    TEMP_Sensor2String(i, TEMPSTRING);      
    
    printf_P(PSTR("[%lu000,%s]"), nowtime.time, TEMPSTRING); 
    
  }
}

Vielleicht nochmal kurz meine gezielte Frage: Was passiert wenn mehrere 
http Anfragen sich überlappen, z.B. wenn die Startseite (die ja aus 
Frames besteht und daher schon von Haus aus 4 Anfragen parallel kommen) 
geladen wird? Werden die Anfragen gepuffert und versucht nacheinander 
abzuarbeiten oder ist während dem Abarbeiten einer Anfrage der Webserver 
"auf dem Ohr taub"? Ich hab auch sehr oft den Fall daß die obere 
Menüzeile und/oder die untere Statuszeile einfach leer ist und auch 
nicht nachgeladen wird, muß den Inhalt ständig mit rechtsklick/"Frame 
neu laden" wieder ranholen.

Hm ... interessant wäre wo der Controller stehen bleibt. Es wäre 
praktisch wenn du da mal ein bisschen forschen könntest. Oft kommt es 
auch vor das Ethernetcontroller einfach hängen bleibt. Am besten mal 
eine LED dran bauen und sehen was passiert.
 Die MMC könnte man Theoretisch im Interrupt initialisieren, aber das 
würde das Timing des System stark kompromittieren und das will ich nicht 
machen.
 Ich selber versuche immer eine Datei nur kurz zu öffnen und gleich 
wieder zu schließen. Zum einen spart das Speicher, weil ich dann nur 
Speicher auf den Stack brauche nicht die Dateiinformationen speichern 
muss. Zum anderen ist das sicherer wenn irgend etwas mal abstürzt. Der 
MMC stört das auch nicht im geringsten, die Internen Controller der MMC 
kümmern sich um die gleichmäßige Auslastung der Speicherzellen so das 
von dort keine Gefahr droht. Also keine sorge das deine MMC mal deshalb 
kaputt geht.
 Nochmal zum HTTP-Server. Der TCP/IP Stack kann mehrere Verbindungen 
annehmen, aber der HTTP-Server immer nur eine gleichzeitig bearbeiten, 
und erst wenn er eine fertig bearbeitet hat kann die nächste in angriff 
genommen werden. So kann es z.b. leicht passieren das eine schon 
angenommene Verbindung in den Timeout läuft und geresetet wird ohne das 
auch nur ein Byte übertragen worden ist. Auf der Benutzerseite sieht das 
dann wie nicht erreichbar aus. Wenn dann noch alle Sockets belegt sind 
kann es passieren das der Controller für eine Zeit nicht zu erreichen 
ist bis alle Verbindungen in den Timeout gelaufen sind.
 Am besten hier und da nochmal ein bisschen probieren.

CA Dirk

Hi Dirk,

die MMC muß ja nicht ständig im Interrupt initialisiert werden, es geht 
ja nur darum daß falls sie mal gezogen werden sollte, der Betrieb ja 
ohnehin gestört ist und da kann der Betrieb auch ruhig ruhen (von mir 
aus auch einen Vollreset machen, wäre vielleicht einfacher) wenn die 
Karte dann wieder eingesteckt wird. Fragst Du den Steckkontakt überhaupt 
irgendwo ab oder müßte ich das komplett selbst implementieren?

Ich werd mal ne blinkende LED anbauen und vielleicht noch etwas debug 
ausgaben über den Comport. Die Ethernet LED's blinken jedenfalls 
weiterhin. Hattest Du eine Watchdog implementiert? Ich hab jetzt 
jedenfalls 12h uptime weil ich über Nacht keine Webseite aufgerufen hab 
also bin ich mir sehr sicher daß es daran liegt, es sei denn Du siehst 
in meinem CGI code (der immer maximal 10mins läuft) etwas gefährliches.

Gruß,
Ethan

Ich vermute inzwischen daß es ein Hardwareproblem sein könnte, denn ich 
hab inzwischen gelesen daß man sie SPI Leitungen ziemlich kurz halten 
sollte und eine 3,3V Pegelanpassung mittels Widerständen (wie beim 
Pollin addon) nicht optimal ist. Bei mir hängt die SD Karte momentan 
fliegend an bis zu 10cm langen Einzeldrähten. Ich werd die also auch mal 
etwas ordentlicher verdrahten und dann weitersehen.

Also die LED blinkt weiterhin, aber das ist auch das einzige 
Lebenszeichen.

Ping antwortet nicht und es werden keine Daten mehr auf SD-Karte geloggt 
(hab in temp_json debug output über die uart eingefügt).

Hallo Dirk,

hat die aktuelle Version im svn eigentlich ein Problem mit Windows?
Ich kann weder mit http noch telnet zugreifen, nur Ping geht.
Unter Linux funktioniert jedoch alles einwandfrei.
Mit Wireshark sehe ich, dass mein Board nicht auf das SYN-Paket 
reagiert. Die SYN-Pakete unter Linux und Windows sehen eigentlich 
ziemlich gleich aus, bis auf die Windowsize. Die ist unter Windows 16384 
und unter Linux 5480 Byte, stört das?

Achso: ich benutze ein AVRNetIO ohne Zusatzboard mit dem ATmega644. 
Software aus dem svn von heute Vormittag mit einer kleinen Änderung in 
der  uart_1.c , hier muss stehen:

#if !defined(__AVR_XMEGA__) && defined(__AVR__) && !defined(__AVR_ATmega644P__)

So steht's in der ZIP-Datei, die ich gestern geladen habe, die ist wohl 
vom 26.12.
Mit der ZIP-Version geht es auch unter Linux nicht wirklich, Telnet 
geht, die Webseite erscheint nur teilweise. Hab ich nicht weiter 
untersucht, sondern dann aus dem svn geladen.

Hi Uwe,

welches Windows benutzt Du denn? XP, Vista, Win7?
Bei mir unter Win7 x64 klappts einwandfrei, benutze eine ca. 10 Tage 
alte SVN Version, glaub aber nicht daß sich inzwischen was geändert hat.

Gruß,
Ethan

Hallo Ethan,

ich benutze Win XP Home SP3, Win7 könnte ich morgen mal probieren.
Ubuntu 10.10 macht keine Probleme.
Habs mit zwei Rechnern und zwei Routern probiert.
Momentan ist das Teil über http://ulegan.dyndns.org zu erreichen.

Gruß
Uwe

Also ich komm bei Dir drauf. Wird irgendeine Inkompatiblität sein die 
nur in deiner Kombination zum Tragen kommt.

Hallo Uwe,
 also ich habe genau das gleiche Problem, ich komme "nicht" auf deine 
Seite und habe auch mit XP SP3 kompiliert. Von intern funktioniert meine 
Seite, von der Arbeit aber nicht. Jetzt ist es 21:05 meine Seite ist

monte70.dyndns.org

@Dirk , das mit dem "&& !defined(_AVR_ATmega644P_)" habe ich auch 
gemerkt das fehlt glaube ich im SVN.

Ich habe auch das Net-IO und Add on mit dem "644" ohne p

Kann jemand mal probieren?

Gruss

Hallo Carsten,

komme jetzt um 22:30 nicht auf deinen Server. Allerdings auch nicht mit 
Linux.
Es ist übrigens egal, ob ich mit Linux oder WinAVR unter Windows 
compiliere, trotz unterschiedlicher Compilerversionen und libc's.
Heute haben es offenbar mehrere probiert, auf meinen Server zuzugreifen. 
Die Netzwerk-LED hat mehrmals heftig geblinkt.
Hat keiner Probleme gehabt?

Uwe

@all

ja, habe nach euren Hinweis jetzt auch gesehen das da noch etwas im SVN 
Fehlt :-). Ist mir wohl durch die Lappen gegangen. Habe es eben 
nachgereicht. Zu euren Servern. Ich habe beide erreicht ohne Probleme, 
sowohl

http://ulegan.dyndns.org/ als auch
http://monte70.dyndns.org

.
Der erste hat jetzt eine Uptime von ca 6h und der Zweite von 16h. 
Interessanterweise laufen sogar die Uhren komplett synchron. Es wäre mal 
interessant zu wissen was ihr für Rechner benutzt, b.z.w. euer 
Betriebssystem.

CA Dirk

Edit: Betriebssystem, Ubuntu 10.4 und WindowsXP SP2 in einer VM.

Habe es gerade selbst nochmal mit Windows XP versucht, ging nicht. Aber 
dabei gab es wohl einen Neustart des Boards, denn beim anschliessenden 
Versuch unter Linux zeigte es eine Uptime von wenigen Sekunden.
Das passierte um 16:27 schon einmal, da war ich es aber nicht selbst...

Bei mir funktioniert:
Ubuntu 10.10 und Ubuntu 10.04 sowie Windows 2000 auf 3 verschiedenen 
Rechnern
Es gehen nicht:
2 Rechner mit Windows XP Home SP3 bzw. XP Professional SP3

Alle Rechner sind im lokalen Netzwerk. Es macht keinen Unterschied, ob 
ich direkt zugreife, oder über den Umweg mit dyndns.org.

Uwe

Hallo,

nach sehr langer Zeit habe ich wieder Zeit gefunden und mal 
reingeschaut. Das Projekt hat sich ja toll weiter entwickelt. Ich hoffe, 
dass ich mich jetzt wieder mit dem Projekt weiter beschäftigen kann.

Die Server:
http://monte70.dyndns.org/ und
http://ulegan.dyndns.org/
habe ich sofort erreicht. Bei der Seite ulegan fehlt aber die Fußzeile.
Ich habe XP Professional Sp3 und Mozilla Firefox benutzt.

Gruß
Karl Albert

Hallo, also mein openMCP funktioniert nur sporadisch von "Außen",

ich habe jetzt mal zwei OneWire Sensoren angebaut echt super.

Ich komme aus meinem Hausnetz immer auf den Server über die Dyndns 
Adresse.

Heute habe ich von meinem Onkel versucht (Linux und XP) ohne Erfolg.

Über die Testseite von dyndns sieht bei mir alles gut aus.
http://www.dyndns.com/support/tools/openport.html

Kommt einer von euch auf die Server von Dirk? ich nicht ?grübel?

http://www.neo-guerillaz.de:81
http://www.neo-guerillaz.de:82
http://www.neo-guerillaz.de:83

LG Carsten

@Carsten,

die drei Boards von mir sind wegen DNS-Problemen bei meinem dyndns z.Z. 
nicht zu erreichen. Das muss ich mal in einer langen Session fixen ...

CA Dirk

Hallo Carsten,

deinen Server konnte ich noch nie erreichen, weder Linux noch XP. Aber 
der Port 80 ist offen.
Inzwischen habe ich einen Rechner im lokalen Netzwerk gefunden, mit dem 
ich den Server auch unter XP erreichen kann.
Interessanterweise sehen dessen SYN-Pakete anders aus, als bei den 
anderen. Ich denke auch, dass mein NetIO SYNACK-Pakete verschickt, aber 
der PC empfängt sie nicht, auch Wireshark zeigt sie nicht.
Ich habe versucht, zusätzliche Debugausgaben einzubauen, dazu musste ich 
den UART Tx-Buffer vergrößern. Meistens stürzt der Server jedoch 
trotzdem mitten in der Ausgabe ab. Derzeit habe ich den größeren Buffer 
noch aktiviert, aber keine Ausgaben. Damit scheint das Teil instabiler 
zu werden. Es kommen meistens nicht alle Frames an.
Ich hab mir jetzt ATmega1284 bestellt, die haben 16k RAM, vielleicht 
läuft's dann besser.
Uwe

Ich hatte anfangs Probleme die TFTP Pakete an meinem PC (Win7) zu 
empfangen, bis ich die Windows-Firewall deaktivierte (bzw. anschließend 
eine Regel dafür einrichtete). Wenn sie an der Firewall hängenbleiben 
dann werden sie auch in Wireshark nicht angezeigt. Ist ein banales 
Problem aber doch häufiger als man denkt.

Hallo Ethan,
habe mal die Firewall deaktiviert, was aber erwartungsgemäss nichts 
bringt. Das Problem tritt ja schon beim Aufbau der TCP-Verbindung auf. 
Der PC schickt ein Paket mit gesetztem SYN-Flag an den Server. Daraufhin 
sollte der ein Paket mit SYN- und ACK-Flag zurückschicken. Diese Antwort 
sehe ich mit Wireshark nicht. Zusätzliche Debugausgaben über die 
serielle Schnittstelle zeigen mir aber, dass das Paket zusammengebaut 
und zumindest an die Funktion sendEthernetframe übergeben wird. 
Allerdings kann ich nicht das komplette Paket über die serielle senden, 
dabei stürtzt der Server komplett ab. Ob das ein Timing- oder 
RAM-Problem ist, weiss ich nicht. Ich weiss auch nicht, ob das Paket auf 
der Ethernet-Schnittstelle rauskommt.

Uwe

@Uwe

Die Debug-Ausgaben gehen nicht im Interruptbetrieb, da die Routinen zur 
Ausgabe per RS232 selber Interrupts benutzen. Aber Inetressant das 
selbst keine Antworten beim PC ankommen. Welche Version benutzt du von 
OpenMCP, die aus dem SVN? Die Sourcen dort sind aktueller als die aus 
der .zip. Kannst ja mal versuchen diese zu benutzen.

CA Dirk

Jetzt gehts...
Die TCP-Header passen nicht!
Wo werden die im PC verarbeitet und wenn sie nicht genehm sind 
verworfen? Etwa im Netzwerk Treiber? Das würde erklären, warum es auf 
den meisten Rechnern geht und bei anderen, mit gleichem Betriebssystem 
aber anderer Netzwerkhardware und damit anderen Treibern, nicht.
Offenbar hab ich da zwei besonders empfindliche Exemplare.

Was passt nicht (zumindest meinen Rechnern):
Im SYN+ACK Paket stehen am Ende die Optionen. Die sind 12 Byte lang, 
aber es werden nur die ersten 9 Byte beschrieben. Dazu sind noch Nullen 
drin, ein leerer Platz muss aber mit 0x01, Wireshark nennt das NOP, 
gefüllt werden. Zudem enthalten eben die letzten 3 Byte Müll.
In einem ACK Paket stehen normalerweise keine Optionen. Wenn aber hier 
am Ende noch ein paar eigentlich überflüssige Byte gesendet werden darf 
da nicht '\0Hurrican' drin stehen, sondern der Bereich gehört mit 0x01 
gefüllt.
Aslo folgende Änderung in tcp.c, in der Funktion MakeTCPheader:

    if ( TCP_sockettable[ Socket ].ConnectionState == SOCKET_SYNINIT )
    {
      // beschreibe das Optionfeld mit MSS = MAX_TCP_Datalenght wenn der SYN ausgehandelt wird
      TCP_packet->TCP_Options[0] = 0x02;
      TCP_packet->TCP_Options[1] = 0x04;
      TCP_packet->TCP_Options[2] = ( MAX_TCP_Datalenght >> 8 ) & 0x00ff ;
      TCP_packet->TCP_Options[3] = MAX_TCP_Datalenght & 0x00ff ;
      TCP_packet->TCP_Options[4] = 0x01;
      TCP_packet->TCP_Options[5] = 0x01;
      TCP_packet->TCP_Options[6] = 0x04; SACK permitted, was bedeutet das?
      TCP_packet->TCP_Options[7] = 0x02;
      TCP_packet->TCP_Options[8] = 0x01;
      TCP_packet->TCP_Options[9] = 0x01;
      TCP_packet->TCP_Options[10] = 0x01;
      TCP_packet->TCP_Options[11] = 0x01;
      }
    else
    {
      // lasse Optionfeld leer wenn kein SYN
      TCP_packet->TCP_Options[0] = 0x01;
      TCP_packet->TCP_Options[1] = 0x01;
      TCP_packet->TCP_Options[2] = 0x01;
      TCP_packet->TCP_Options[3] = 0x01;
      TCP_packet->TCP_Options[4] = 0x01;
      TCP_packet->TCP_Options[5] = 0x01;
      TCP_packet->TCP_Options[6] = 0x01;
      TCP_packet->TCP_Options[7] = 0x01;
      TCP_packet->TCP_Options[8] = 0x01;
      TCP_packet->TCP_Options[9] = 0x01;
      TCP_packet->TCP_Options[10] = 0x01;
      TCP_packet->TCP_Options[11] = 0x01;
  }

Optimal ist das sicher nicht, die überflüssigen Byte sollte man besser 
weglassen. Dazu muss man aber die TCP_HEADER_LENGHT modifizieren, die 
aber als Konstante definiert ist. Daraus eine Variable hab ich noch 
nicht hinbekommen, hatte zuviele Nebenwirkungen.

So, für heute reicht es mir. Morgen suche ich mir mal Literatur über den 
Aufbau von TCP-Headern. Verstanden hab ich's nämlich noch nicht...

Uwe

P.S. Die Namensgebung mit _LENGTH und _LENGHT hat mich reichlich 
verwirrt. Das sollte man mal aufräumen

@Uwe,

Der Headeraufbau ist RFC-Konform. Das Optionfeld wird mit einer 0x00 
abgeschlossen. Demzufolge ist ein 12-Byte Optionsfeld welches mit 0x00 
beginnt richtig, weil die Daten danach nicht mehr beachtet werden. 0x01 
ist einfach nur ein NOP und macht nix, wenn man das bis zum ende des 
Optionfeldes rein schreibt ohne die Options mit 0x00 zu terminieren hat 
das Optionfeld kein Ende und es gibt wirklich Probleme wenn die Treiber 
das nicht richtig machen (RFC793 Page 18).

Es ist aber durchaus möglich, dass Du die empfindlichsten, zu Deutsch: 
miesesten Treiber der Welt erwischt hast. D.h. Deine Kombination ist die 
erste in 2000+ D/L die mit einem RFC konformen Aufbau nicht zurecht 
kommt - kann sein.
Dies könnte man ausschließen, indem man auf dem gleichen Rechner eine 
andere Netzwerkkarte in Betrieb nimmt.

Ich bin der Meinung, das bei 2000+ D/L solche Fehler rein statistisch 
längst aufgetreten sein sollten. Aber die Gretchenfrage bleibt: Warum 
können andere zugreifen?

CA Dirk

P.S.: Du kannst gerne die Sourcen nach Fehlern durchsuchen, wie auch 
immer geartet, und den korrigierten Sourcecode zum einpflegen mir geben, 
bin ja auch nicht perfekt. Aber ein plumpes "Das sollte man mal 
aufräumen" geht mal gar nicht. Hilfe anbieten JA, aber peitschen NEIN.

@Hans
Du machst wahrscheinlich gar nichts falsch, du hast nur die falsche 
Hardware-Betriebssystem Konfiguration.
Hab mir dieses HEX-File auch gerade mal geladen, es zeigt bei mir auch 
das oben von mir beschriebene Problem.
Probier mal einen anderen PC oder ein anderes Betriebssystem.

@Dirk
Hab mir das RFC793 angeschaut und kann deine Aussage bezüglich des 
Optionsfelds nur bestätigen.
Ich habe mir einfach die Antworten verschiedener Webserver angesehen, 
die hatten zumindest im SYN-ACK-Paket nie eine 0 stehen. Es scheint also 
nicht üblich zu sein, das Optionsfeld so zu begrenzen, auch wenn es 
ausdrücklich erlaubt ist.
In ACK Paketen fehlt das Optionsfeld ganz, bzw es werden nur Nullen 
eingefügt, damit die Headerlänge ein vielfaches von 4 Byte ist 
(Padding).

Trotzdem funktioniert meine obige Lösung und schaden tut sie auch nicht.
Allerding hab ich die SACK-Option wieder entfernt, nachdem ich ungefähr 
verstanden habe, was das ist.

Ausserdem wollte ich dich nicht kritisieren, schon garnicht Peitschen... 
Mich hat es nur mehrfach verwirrt, das ich TCP_HEADER_LENGTH beim Suchen 
nicht finde. Es heist bei dir TCP_HEADER_LENGHT.

Ich werde mal weiter forschen, ob man das mit den Headern optimieren 
kann und dabei ein bischen aufräumen.

Gruß
Uwe

Es steht auch überall "SECOUND" statt "SECOND" in den Sourcen. Dirk ist 
halt kein Englischguru ;-) dafür hat er bei anderen Sachen echt 
gepunktet! Die Modularität kann sich echt sehen lassen.

@Hans / Peter
Das mit den Leuchtdioden stimmt so.

@Ethan
Die Modularität gefällt mir auch, das ist der wesentliche Grund, warum 
ich mich dafür interessiere. Die TCP-Stacks von Ulrich Radig und uip von 
Adam Dunkel scheinen, zumindest unter Windows, besser zu funktionieren, 
aber da finde ich alles recht unübersichtlich.

@Hans,

anbei mal ein .hex zum testen auf dem AVR-NET-IO mit einem 644P und 
ADD-ON. Schau mal bitte ob das so geht bei euch.

CA Dirk

Hab kein 'P' ...
Oder sollte es auch auf einem normalen ATmega644 laufen?
Dann probier ich's heute abend aus.

Uwe

@Hans ...

naja, immerhin ein Teilerfolg :-). Da es jetzt ein bisschen geht wäre 
mal ein Wireshark-log interessant für mich. Was ich auch gerne noch 
wissen wollen würde wäre was ihr genau für Hardware verwendet bei den 
Netzwerkkarten und ob hier noch andere Software wie Firewalls oder so am 
laufen habt. Interessant wäre auch zu wissen was für einen Switch ihr 
benutzt.

CA Dirk

Hab das Hex-File auch mal ausprobiert, geht nicht unter Windows, aber 
unter Linux. Liefert zwar ein '403 File not found!', denke das sucht auf 
der SD-Karte. Telnet geht unter Linux, unter Windows nur Ping. Es kommt 
weiterhin keine Antwort auf das SYN-Paket.
Netzwerkkarte hier ist eine 'Realtek RTL8168/811 PCI-E Gigabit Express' 
onboard auf einem Foxconn Mainboard. BS ist XP-Home .
Router ist eine Fritzbox 7170.
Der zweite Problemrechner ist ein Dell Latitude D830 Notebook.
Da geht weder der Broadcomm Gigabit Netztwerk-Anschluss, noch das Dell 
Wireless 3945 WiFi® 802.11a/g Wlan. BS hier ist XP-Pro.
Ausser der Windows Firewall ist auf beiden Rechnern nichts aktiv.

Hab mal meine geänderte tcp.c und tcp.h angehängt. Die gehen bei mir 
unter Windows, allerdings immer noch langsamer als unter Linux.

Ich hab das Optionsfeld bei SYN-ACK-Paketen auf 4 Byte gekürzt, nur noch 
die MSS steht drin. Alle anderen Pakete haben kein Optionsfeld mehr.
Damit gibt es keine 0-Bytes mehr. Die werden bei mir offenbar wie NOP's 
behandelt und sind nicht das eigentliche Problem. Das Problem sind die 3 
letzten Byte, die alten Müll enthalten, bzw. der String 'Hurrican'.

Uwe

So ... habe mal ein bisschen gespielt, die Version von heute Mittag 
hatte noch Fehler gehabt, da wurde noch Müll im Optionfeld mitgeliefert. 
Jetzt die bereinigte Version für den 644 und den 644P. Bitte mal 
Probieren.

CA Dirk

@Dirk
Das Programm von 0:50 funktioniert. Webserver liefert 'HTTP 403 
verboten', Telnet geht. SYN-ACK Pakete kommen an.
Aber warum hast du das Optionsfeld auf 16 Byte vergrössert?
Da steht ausser den 4 Byte beim SYN-ACK Paket nie was drin.

Uwe

@Uwe,

schon mal gut des es geht.Ich habe das Optionfeld auf 16 vergrößert 
damit ich RTT machen kann welches 10Byte im Optionfeld braucht, damit 
kann der gegenüber die Latenz messen was die Verbindung beschleunigen 
kann. Ich werde ich Scourcen heute Abend mal in das SVN packen.

CA Dirk

@Hans

Wenn du das ADDON hast brauchst du nur die Dateien die in der. Zip oder 
im SVN liegen unter SD-CARD auf die kopieren und fertig. Wenn kein ADDON 
vorhanden ist wird ein eigenes .hex benötigt wechelches man sich selber 
bauen kann wenn ich heute nacht die Sourcen aktualisiere.

CA Dirk

@Hans

gerne gemacht. Aber die Testfirmware von heute Nacht ist nicht stable, 
da sie noch kleine Fehler im Tcp-Stack enthält die ich letzte Nacht noch 
ausgebügelt habe im Zusammenhang mit den Änderungen.

CA Dirk

Salut ...

Die neue Version liegt auf dem SVN, die .zip Dateien sind auch auf den 
aktuellen Stand der Dinge.

CA Dirk

Hallo, was mir noch aufgefallen ist.

Ich habe also auch nochmal neu übersetzt, und gestartet. Danach kein 
zugriff auf die IP-Adresse bzw. dyndns Adresse. ?? -> Meine FritzBox 
steht auf DHCP und hat einen zweiten OpenMCP eingetragen. Nach löschen 
aus der FB und Konfiguration des OpenMCP auf die Richtige IP geht bei 
mir alles.

XP (SP3), Realtek RTL8169/8110 Family Gigabit

Gruss Carsten

@Carsten,

schließe ich daraus das bei dir DHCP nicht richtig geht ?

CA Dirk

@Dirk

Nein das glaube ich nicht, meine Fritzbox kommt da glaube ich etwas aus 
dem Tritt. In der FB ist der OpenMCP fest mit seiner Portfreigabe 
eingetragen, wenn ich neu übersetzt habe und starte hat die FBox eine 
neue IP vergeben.

Also Achtung beim einschalten -> IP Adresse überprüfen

LG

Hallo,

nur zur Info: Der Microcontroller ATMEGA1284P-PU ist bei Pollin wieder 
lieferbar.

Gruß
Karl Albert

Hallo,

ich habe mir die aktuellen Sourcen von openMCP aus dem SVN gezogen und 
bin über die Dateien:

./system/net/n_buffer.h
./system/net/n_buffer.c

gestolpert. Kann jemand bestätigen, dass diese Dateien für das Projekt 
nicht benötigt werden?

Frank

@Frank,

ja, die Dateien werden "noch" nicht benötigt, aber damit sie nicht 
verloren gehen sind sie mit im SVN.

@Gast,

nein gibt es nicht, da sich bis jetzt auch noch keiner dazu geäußert hat 
was geht und was nicht.

Mit der SD-Karte ist das so ein leidiges Thema das es mal anzupacken 
gilt.
Zu den GPIO, da bin ich noch dabei, da ich darüber gestolpert bin das 
die Eingänge, namentlich die Tasten, gegen Low schalten aber keine 
Pullups besitzen. Ich muss mir dazu noch ein Interface ausdenken wie man 
generisch die Pullups einschaltet auf dem Xmega und dem mega über das 
gleiche Interface. Aber da ich jetzt meine freien Tage genieße werde ich 
wohl ein bisschen weiter machen bei OpenMCP.

CA Dirk

Michael schrieb:
> Ich versuche hinzukriegen, dass das Board Schaltzustände, Messerte
> (1-Wire) und so periodisch (z.B. jede Stunde) an ein Formular (auf einem
> beliebigen Webserver) mit GET übergiebt. Dort kann man dann fein alles
> in einer DB ablegen. Wer kann mich hier mal in die richtige Richtung
> schubsen? Wo muss ich ansetzen? Meine C-Kenntnisse sind recht
> bescheiden, aber ich bin lernwillig.
>
> Freue mich über jede Anregung. Außerdem würde ich gerne zur Diskussion
> stellen, ob man eine solche Funktionalität nicht korrekterweise über
> einen vornehmen Webservice (SOAP) realisieren sollte.

Hast du schon in Erwägung gezogen sowas mit Cacti zu erledigen? Ich habe 
vor ein paar Wochen ca. 2h (inkl. Einarbeitung) gebraucht und habe dann 
ein System laufen gehabt, dass etwas über 30 Werte von verschiedenen 
openMCP Boards pollt und visualisiert. Konkret gemacht habe ich das über 
die in openMCP schon vorhandenen Funktionen und ein bißchen Perl 
dahinter:

1.) Webseite von openMCP (Eingänge, Ausgänge, Sensoren, ...) anfordern
2.) Webseite mit Perl-Script parsen, die geparsten Werte entsprechend 
für Cacti Poller-Scripte aufbereiten und ausgeben.
3.) Perl-Scripte aus Cacti heraus zyklisch aufrufen lassen
4.) sich über schöne RRD Grafiken freuen.

Den ganzen Rest kannst du dann aus den Round-Robin-Datenbanken beliebig 
generieren, zur Not ein paar separate Perl-Scripte die dir deinen 
Webservice realisieren wenn du über das was Cacti alles kann noch mehr 
benötigst.

Michael

Ich habe in den letzten Tagen mal ein (weiteres) openMCP kompatibles
Board erstellt, dass meine Anforderungen etwas besser erfüllt als die
bisherigen Lösungen. Mein Hauptanliegen war Kommunikationsfähigkeit auf
hohem Niveau (Ethernet, RS232) und darüber hinaus möglich große
Flexibilität und einfache Erweiterbarkeit. Die Grunddaten sind wie
folgt:

- Boardgröße 100*80
- einseitiges Layout (eine Brücke, ich hatte keinen Bock mehr weiter zu
routen)
- alles mit bedrahteten Bauteilen um die Grobmotoriker unter uns
Hobbylötern ausreichend ins Projekt mit einbinden zu können ;-). Ich
mache demnächst aber auch mal eine Variante in SMD.
- läuft grundsätzlich auch mit einem ATMega 32, empfohlen wird aber ein
644er
- Ports A,C und D sind auf Pfostenleisten an den Platinenrand geführt
zur Verwendung mit Flachbandkabel an Pfostensteckern oder zur einfachen
Montage von Daughterboards. An Pin 1 und 2 von Port D hängt noch der
Max232 für RS232 (wie beim AVR-Net-IO). Wenn man die UART nicht benötigt
ist Port D komplett nutzbar - einfach MAX232 nicht bestücken.
- Die Daughterboards (1* 100x80 oder 2 * 50x80) können auch auf
Lochraster aufgebaut werden, Pfostenleisten stehen im 2,54er Raster
- An Port B hängt im Wesentlichen der ENC26J60 für Ethernet und der ISP
Connector (wie beim AVR-Net-IO auch).
- Netzteil ist für den Betrieb mit LowDrop Reglern ausgelegt. Im
Prototyp steckt noch ein 7805 (deshalb auch der Kühlkörper auf dem
Bild). Für den 3,3 Volt Zweig ist schon ein LF33 (pinkompatibel zu 78xx
Reglern) verbaut. Der 5 Volt Regler kann auch eins zu eins gegen z.B.
einen LF55 LowDrop ausgetauscht werden.
- Die Dallas 1Wire Anbindung funktioniert wie auch auf dem AVR Net IO
über die 3polige Pfostenleiste.
- Im Gegensatz zum AVR-Net-IO habe ich dem Board mal einen separaten
Resettaster spendiert - gefällt mir persönlich einfach besser.
- openMCP läuft ohne Änderungen mit den Einstellungen für das AVR-Net-IO
- für den Ethernetanschluss habe ich mich für den Mag-Jack SI-60024-F,
wegen günstiger Verfügbarkeit z.B. bei CSD, entschieden. Ich denke aber
im Moment noch darüber nach ggf. eine Möglichkeit zum "jumpern" auch für
andere Pinouts für die Modular-Buchsen vorzusehen.

Vielleicht fällt ja noch dem ein oder anderen etwas ein was als nettes
Feature mit ins bestehende Konzept (kommunikativ, einfach erweiterbar
und flexibel) passt, dass würde ich dann noch kurzfristig mit einbauen.

Zur Zeit muss ich eh noch ein paar Änderungen am Layout machen - habe
die LED's etwas dämlich verdrahtet.

Achso, Stromaufnahme liegt voll bestückt bei ca. 200 mA.


BG

Michael

Michael schrieb:
> Das Board soll periodisch
> (cron-Job) an ein get-Formular senden...

das würde man grundsätztlich auch hinbekommen, die Voraussetzungen in 
openMCP sind ja vorhanden durch die scriptfähigkeit des cronmodules. 
warum stört dich denn das pollen?

bg

michael

Michael schrieb:
> Am elegantesten wäre sicher ein Webservice (SOAP)

Ich persönlich finde SOAP da eher hinderlich, insbesondere unter dem 
Aspekt Aufwand-Nutzen-Relation. Wenn du wirklich echtes SOAP machen 
willst mußt du ja auch noch richtig von Seiten des Protokolls nachlegen. 
Wäre mir persönlich dafür warscheinlich zu aufwendig. Ich bin im 
MC-Bereich gerne so minimalistisch wie möglich unterwegs - ansonsten 
kann ich ja gleich was "embbedetes" mit einem ordentlichen linux drauf 
nehmen. Wie dem auch sei - meine Philosophie weiter verfolgend, deine 
Bedenken bzgl. des Portforwardings aber berücksichtigend ;-) könnte ich 
mir eine "Zwischenschicht" in Form eines Scripts das hausintern läuft 
(kein echtes SOAP ;-) ) vorstellen. Das Script fragt die Daten auf dem 
MC ab und schickt diese dann auf den externen Server, hier würde ich 
dann aber das Gefrickel (welches du ja schon intern hättest) mit GET 
extern sein lassen und direkt in eine DB schreiben aus der dann der 
Webserver die Grafiken macht. Hier würde ich im übrigen schon wieder 
cacti vorschlagen.

BG

Michael

Michael schrieb:
> Meine Frage ging eher in die Richtung wie sieht ein erster Lösungsansatz
> aus, damit ich openMCP so erweitere, dass es periodisch Daten (z.B.
> Werte von 1-Wire-Sensoren) an ein get-Formular überträgt.

falls dir der crondienst nicht gefällt schau mal hier, da wurde 
letztlich ein http-client implementiert

http://son.ffdf-clan.de/include.php?path=forumsthr...

Die die in der config.h ziemlich am Anfang steht, die Datei findest du 
nach dem entpacken der Sourcecodes im Stammverzeichnis.

Ich finde es macht Sinn sich mit dem (oder ähnlichen) Projekt(en) an 
sich ein bißchen auseinander zu setzen. Ganz unabhängig davon welche 
eigenen Fähigkeiten/Voraussetzungen (Programmierung, Elektronik, etc) 
man mitbringt. Der eigentliche Trick bei solchen Projekten ist meines 
Erachtens, dass man seine eigenen Fähigkeiten ausbaut, festigt oder auch 
auffrischt. Wenn man auf der Suche nach einen out-of-the-box 
funktionierenden System ist, werden die persönlichen Erwartungshaltungen 
hier warscheinlich enttäuscht. Es ist im weitestens Sinne ein 
unspezialisiertes System welches großen Potential in Richtung 
Spezialisierung hat, da bleibt es nicht aus, dass man zur Lösung seines 
spezifischen Problems noch ordentlich Gehrinschmalz, Zeit, Lust und 
Laune investieren muss. Was ich letztlich damit sagen will, selbst ist 
der Mann oder die Frau. Hier geht es nicht darum fertige Lösungen zu 
erhalten sondern durch eigenes Verstehen, Ausprobieren und Erweitern mit 
Spass Lösungen zu entwickeln. Voraussetzung dafür ist meines Erachtens, 
dass man zumindest willens und in der Lage sein sollte die ganz 
grundlegenden Funktionsprinzipien wie die zentrale Steuerdatei 
(config.h) aufzufinden und schonmal erste eigene Experiment angestellt 
zu haben. Wenn das schwer fällt gibt es entweder ein Problem mit der 
Grundmotivation oder es fehlt noch an ganz grundsätzlichem Verständnis 
für die Funktionsweise von solchen Systemen (Hardware, Software, etc) - 
dann sollte man besser erstmal weiter vorne anfangen und später hier 
weiter machen. Nur meine bescheidene Meinung.

@@Mx Wx (mxwx) und Michael,

ich habe den OpenMCP um die Sachen teilweise schon erweitert über die 
ihr da diskutiert habt.

SOAP wollte ich auch mal machen, ist aber wie oben schon gesagt, viel zu 
aufwändig. Ich habe mich für REST WebServices entschieden, also simples 
HTTP GET/POST.  POST habe ich nachgerüstet, das konnte O-MCP noch nicht.

Darin ist auch ein HTTP Client enthalten, der sich OnEvent (i.e. 
Umfallen eines dig. IOs) per TCP an einen Server verbindet und diesen 
Event sofort dort abliefert. Per cron Daten irgendwo abliefern dürfte 
nicht das Problem sein.

Übertragungsprotokoll ist ein eigen definiertes XML (JSON ist gerade in 
Arbeit) mit dem sich der gesamte NETIO steuern und abfragen lässt - eine 
Art Fernwirkprotokoll für den gesamten NETIO nach diesem Muster: 
http://.../netio?PORTA1=1&PORTB1=2&PIN2&ANO="123"...... . Dann kommt 
XML/JSON zurück. Eine Spezifikation ist vorhanden.
(Ja, es überschneidet sich mit den Fähigkeiten des OpenMCP).

Als Übertragung wird - wie gesagt - REST Service als HTTP- GET 
verwendet. Die ganzen HTML Pages sind abgeschaltet, denn Darstellung ist 
m.E. keine Aufgabe eines uC.

Wer mitmachen möchte oder auch nur meinen Code verbessern möchte, ist 
herzlich eingeladen. Mail reicht. Im Moment ruht allerdings diese Arbeit 
wg. anderer, höher priorer Dinge.

Den Client aus dem zitierten Thread 
http://son.ffdf-clan.de/include.php?path=forumsthr... habe ich auch 
untersucht und verworfen. OpenMCP ist um Klassen besser.


Gruß
Gerd

Hi zusammen,
ich benutze den OpenMCP schon etwas länger und bin auch begeistert von 
dem Projekt.

Einige Dinge sind mir aufgefallen, die ich mal in den Raum werfen wollte 
und die u.U. auch die Probleme Anderer in dem Thread hier u.U. erklären 
könnten.

Mir fiel auf, das der TCP Stack  m.E. recht langsam ist und, wenn man 
sich mit Wireshark den Trace gegen einen Windows Client betrachtet, auch 
voller Merkwürdigkeiten. Ich glaube auch nicht, das man für Windows auf 
dem TCP Stack eine Extrawurst drehen muss wie oben in dem Thread (und im 
Quellcode) behauptet wurde.
Ich habe einfach mal einen TCP/HTTP Trace eines Firefox/Windows gegen 
einen TOMCAT untersucht und doch einige Unterschiede festgestellt.
(Ja, man kann einen uC nicht gegen ein TOMCAT vergleichen, aber es ging 
hier nur um das was auf dem Draht geschieht)

-  OpenMcp benutzt niemals ein TCP- PUSH Flag. Warum eigentlich nicht?
    TOMCAT benutzt das immer. Könnte das die Ursache für die 
eigenartigen Effekte unter windows sein ?
-  HTTP GET wird immer erst mit "HTTP ... 200 Document follows" 
beantwortet, bevor der eigentilche Inhalt kommt. Das ist doch gar nicht 
nötig.
-  Der Ethernetbuffer ist sehr klein. Nur irgendwas um 70 byte. Warum so 
wenig ?  Solange genug RAM da ist, kann man es doch nutzen.
    (Simples verdoppeln oder verdreifachen ging voll daneben, der Stack 
startet gar nicht mehr)

Was meint ihr ?
Gruß
Gerd

- Nachtrag :

Ausgehende TCP Verbindungen funktionieren auch nicht. Es gibt dafür eine 
Funktion "Connect2IP()", die aber leider gegen ein 'netcat' (auf 
Windows) nicht funktioniert.

Hi Gerd,

also ich meine... ich finds super daß Du Verbesserungsvorschläge 
bringst, aber ausser Dir wird sie vermutlich niemand einarbeiten... also 
wenn Du den Code verbessern könntest/würdest (und so wie es sich anhört 
hast Du dafür schonmal gute Voraussetzungen) wären Dir alle MCP-Nutzer 
dankbar!

Mir ist auch schon aufgefallen (siehe oben) daß der HTTP Server bei mir 
oft (mehrmals pro Tag) abschmiert (leider habe ich kaum konkrete 
Anhaltspunkte woran es liegen könnte, außer daß bei einem anderen 
ähnlichen Webserver-Ansatz dieses Problem nicht besteht) - ich kann 
nicht ausschließen daß es ein eigenes Problem ist wegen Hardware oder 
eigenen SW-Änderungen (wobei diese minimal sind).

Viele Grüße,
Ethan

Ich habe auch schon versucht, mit dem Autor Dirk Broßwick Kontakt 
aufzunehmen, um mit ihm die Probleme zu diskutieren. Denn i.A. hat sich 
der Autor einer Software sich ja was dabei gedacht, das er es so macht 
und nicht anders.

Aber nach einem Erstkontakt im Januar meldet er sich seit 8 Wochen nicht 
mehr ...

Mindestens einen potentiellen Pufferüberlauffehler im TCP- Stack meine 
ich entdeckt zu haben, der für sporadische Fehler die Ursache sein 
könnte, aber wie gesagt, das würde ich gerne mit Dirk erst selbst 
besprechen, bevor ich hier "auf die Tonne haue".

Gruß
Gerd

Ethan Arnold schrieb:
> Mir ist auch schon aufgefallen (siehe oben) daß der HTTP Server bei mir
> oft (mehrmals pro Tag) abschmiert

das hatte ich sporadisch auch bei einigen Aufbauten. Ich habe das mal 
angefangen zu tracen und zunächst mal noch unspezifisch auf defekte 
IP-Pakete zurück geführt. Jedenfalls hatte ich in der Simulation beim 
Verschicken von defekten IP-Paketen schnell "Erfolg" beim abschießen 
:-). Das kann aber noch nicht die ganze Lösung sein. Damals habe ich das 
Problem schnell lösen wollen und habe erstmal einfach einen Cron-Job 
eingerichtet der das MCP jeweils nach 15 Minuten resettet. Und wie das 
halt mit solchen schnellen Fixes ist, das läuft seitdem mit dem "Fix" 
problemlos und wird wohl deshalb in nächster Zukunft auch nicht mehr 
angepackt. Mal sehen vielleicht ja doch :-).

Beste Grüße

MxWx

Hallo!

Würde gerne mal das Board in Betrieb nehmen. Dazu müsste ich den richten 
µC besorgen.

Weiß jemand, welche die aktuellste Version ist?
Wo ich sie finde?
Und für welchen Controller sie geschrieben ist?

Danke für Antwort.