Webserver ATmega32/644DIP ENC28J60

Ich habe den Thread jetzt so ziemlich durch. Alle Achtung - schönes 
Teil!!!

Was mich noch interessieren würde:
1. Was macht ihr mit Ding - also wofür setzt ihr es ein?
2. Wie sieht es mit dem Stromverbrauch aus - wieviel Leistung zieht das 
Teil?

Bei längerer Abwesenheit soll bei mir das Haus (Alarmkontakte, 
Heizungssystem usw) beobachtet werden können.
Wäre ja dann von jedem Internetcafe aus möglich.
http://hreg.dyndns.org  (Entwicklungsstand, wenn er läuft)

@Thilo M.

Wie misst du die Temperatur -> anlog durch NTC / PTC oder direkt mir 
Digitalen-ICs (DS1620 …)?

Die Temperaturmessungen erfolgen mit PT100 in Vierleiterschaltung, Die 
Messschaltung läuft soweit als Prototyp, die Linearisierung erfolgt per 
Software: Beitrag "PT100 Berechnung der Temperatur @ Widerstand"
Bin grade dabei, den Regler zusammenzubauen, darum sind die Wesites auf 
dem Server noch so primitiv.
Wenn das Ganze fertig ist werde ich mich hier melden, da kann der eine 
oder Andere vielleicht auch was mit anfangen. (Geplant: 8 
Temperaturmesstellen, 2 Schaltausgänge 220V, 4 Heizungsmischer => je 2 
Schaltausgänge 220V, 4 PI-Regler => Schaltregler, LC-Display, Webserver 
per I²C oder RS232, Speisung evtl. per Solarpanel und Batterie).

Ach ja: die Temperaturen auf dem Webserver sind Festwerte, da hängt 
logischerweise noch kein Regler dran! ;)

Kurze Zwischenfrage.

Wo bekommt man eigentlich die Buchse für die Stromversorgung her. Bei 
Reichelt und bei Segor ist mit der Suche nach 'SCD-014-A' nichts zu 
finden.
Könnte ich da wohl einen kleinen Tipp bekommen?

Besten Dank im Voraus

Ich habe die 'HEBW 21' von Reichelt benutzt. Bischen gebastel, weiß 
nicht ob Ulrich die im Sinn hatte? Geht aber.

Wie sieht es mit dem Stromverbrauch aus?

Und hat evtl. jemand Interesse das Ganze mit einem Mega128 oder CAN128 
aufzubauen? Ich spiele mit dem Gedanken das zu portieren und dann evtl. 
Platinen fertigen zu lassen.

Wie wäre der CP2200 von Silabs als Alternative zum ENC28J60? Der müsste 
etwas schneller sein, denke ich. Klar hat der auch nur 10Mbit/s auf der 
Ethernet-Seite, aber die Kommunikation zum uC sollte durch das parallele 
Interface ne Ecke flotter sein.

>Klar hat der auch nur 10Mbit/s auf der Ethernet-Seite, aber die >Kommunikation 
zum uC sollte durch das parallele Interface ne Ecke flotter >sein.

Also ich habe das Gefühl, dass der so "langsam" ist weil hier nur ein 
TCP-Ping-Pong gespielt wird (geringe Resourcen der AVRs). Es wird immer 
nur eine Nachricht gesendet, erste wenn die Bestätigung kommt wird die 
nächste Nachricht gesendet.

Problem dabei scheint zu sein, dass sich Windows viel Zeit lässt. Mit 
einem Browser unter Linux geht es deutlich schneller.

Es würde wahrscheinlich mehr bringen den Stack etwas zu optimieren, 
statt den CP einzusetzen. Aber der hat vielleicht noch andere Vorteile 
(Energie, Interruptbeslastung, bei UDP gibt es vielleicht auch einen 
Geschwindigkeitsvorteil...).

steffen.

Hallo Thilo,

es bleibt natürlich jedem selbst überlassen was er mit dem WebServer 
macht... IMHO fehlt dem Vorschlag, den WebServer im Internet zu 
betreiben um z.B. Haustechnik damit zu regeln oder auch nur zu 
überwachen, allerdings ein Sicherheitshinweis. Ich würde mir das 2 mal 
überlegen.

Gruß
Sebastian

Hast du natürlich Recht.
Den Türöffner oder Hauptschalter werde ich damit sicher nicht bedienen! 
;)
Soll hauptsächlich zum Ansehen der Parameter sein, Bedienung erfolgt 
dann wohl nur übers LAN daheim.

@Ulrich:

Das war KEINE Kritik irgendwelche Art an der Software!!! Mit den 
Möglichkeiten der verwendeten AVRs (insbes. der Ram-Beschränkung) geht 
das einfach nicht anders.

Vielleicht noch als Hinweis für Mitleser, die nicht so "tief" in der 
Materie stecken:
Beim TCP wird jede Information (Nachricht) bestätigt. Das heisst wenn 
ich eine bestimmte Anzahl an Bytes sende, bekomme ich dafür die 
Bestätigung, dass sie richtig empfangen wurden - wenn nicht, wird nach 
einer bestimmten Zeit die gleiche(!) Information noch mal gesendet. Um 
die Netzlast nun etwas zu verringern, gibt es die Möglichkeit, dass man 
mehrere Pakete auf einmal sendet und auf eine einzelne Bestätigung 
wartet. Dies wäre die Stelle, an der eine Optimierung 
Geschwindigkeitsvorteile bringen würde. Nachteil daran ist, dass der 
Inhalt jedes gesendeten Paketes zwischengespeichert werden muss, damit 
ein neues Senden möglich ist. An dieser Stelle kommt nun der notwendige 
(von Ulrich erwähnte) RAM ins Spiel. Wenn eine Nachricht etwa 500-Byte 
Nutzdaten enthält und der Controller nur 2kByte insgesamt hat, kann man 
es sich nicht leisten, viele Nachrichten zwischenzuspeichern.

dann bis zur nächsten mail,
steffen.

Kann man das Ganze denn noch sicher(er) machen? Es wäre schon von 
Vorteil, wenn man damit auch Einfluss nehmen, d.h. irgendetwas steuern 
könnte...

Wenn ich damit nur aus dem LAN zuhause schalten kann, kann ich die paar 
Meter gerade noch laufen...

Ich denke auch, dass der Passwortschutz ausreicht.
Auf meiner HP habe ich ja auch Passwortgeschützte Ordner, dort waren 
auch noch keine illegalen Aktivitäten oder Zugriffe zu verzeichnen.
Und wenn den Domainnamen keiner kennt, wird gar nicht erst probiert zu 
hacken. Außerdem lohnt der Aufwand nicht, hier eine Brutforce-Attacke zu 
starten, nur um jemandem das Licht auszuschalten, oder?
Aber das Passwort/Username noch zusätzlich zu verschlüsseln, da sind der 
Phantasie kaum Grenzen gesetzt ...

Hallo,

also ich sehe das mit der Sicherheit ein bisschen anders. Klar, solange 
es um ein Bastelprojekt geht, kann einem das ziemlich egal sein, aber 
wenn man, wie erwähnt, den AVR webserver ins Internet - oder auch in ein 
Intranet bringt um Messdaten zur verfügung zu stellen oder sogar 
Steuerungsaufgaben davon erledigen lassen will, wäre ich persönlich 
damit ehr vorsichtig.

Username/Passwort:
hält einem "man in the middle attack" nicht stand. Im  Internetcafe oder 
über einen Öffentlichen Hotspot (noch schlimmer) besteht die 
Möglichkeit, dass jemand mithört.

Brutforceattack:
- das rausfinden von passwörtern mittels Wörterbuch - Backtrack CD 
einlegen und los gehts, ist nicht wirklich aufwendig.

Warum sollte jemand bei mir das Licht an und ausschalten wollen:
Im einfachsten Fall aus dem gleichen Grund aus dem Viren geschrieben 
werden und sich der Hund die ... leckt - weil es geht. Und wenn jemand 
erstmal auf den Geschmack gekommen ist, vielleicht schaltet er ja das 
Licht 1000 / Minute an und aus.

SynFlood Attack:
der Webserver ist selbst mit einfachsten mitteln "aus dem Verkehr" zu 
ziehen, steht also nicht mehr zur verfügung.

Keiner kennt meine IP, meinen DNS Namen:
Wenn man sich mal die Logfiles der Firewall ansieht - leider sind die 
meisten billig DSL router nicht gerade gesprächig - kann man 
feststellen, das auch schonmal wahllos drauflos probiert wird. Einem 
Angreifer könnte es ja egal sein bei wem er 1000 mal Lich an und 
ausschaltet, er macht es einfach egal wo.

Mir ist noch nie was passiert:
Ich hatte auch noch nie einen Virus, trotzdem habe ich einen 
Virenscanner im Einsatz.

Firewall & VPN:
yep, das hilft, aber z.B. die Firewall die den AVR vor dem erwähnten 
synflood attack schützt gibt's nicht beim ISP umsonst dazu wenn man 
einen DSL Vertrag abschließt. VPN Geräte bekommt man umsonst garnicht 
(die preiswerteste Variante die ich kenn ist OpenVPN). Um einen 50 EUR 
Webserver zu schützen müßte man dann schon recht tief in die Tasche 
greifen. Außerdem stellt sich dann natürlich die Frage ob ich bei dem 
Aufwand nicht gleich einen "normalen" WebServer installieren sollte.

Ich will das Projekt hier nicht madig machen, sondern lediglich 
aufzeigen welche Probleme sich bei dem "Produktiveinsatz" ergeben 
können. Ob die Sicherheitsrisiken relevant sind oder nicht, muß letzten 
Endes jeder für sich selbst endscheiden.

Gruß
Sebastian

@ John-eric:
guck mal bei http://www.embedit.de rein.
Die haben die Teile verfügbar, habe dort auch bestellt.

Hallo,

@all
Ich verfolge dieses Projekt schon seit längerem mit großem Interesse.
Seit einiger Zeit hab ich den Webserver in der ein wenig modifizierten 
Version 30 am rennen. Nun wollte ich einmal einen mega8 über RS232 
anbinden und übers Web steuern. Auf dem mega8 läuft im großen und ganzen 
die main usart und cmd von Uli.
Ich habe nun ein Problem mit der Kommunikation. Ich sende vom Webserver 
aus z. B. LED1on und möchte dann, dass am mega 8 die entsprechende LED 
angeht. Übers Terminal funktioniert das ganze schon super, nur der 
Webserver und der mega 8 mögen noch nicht so ganz. Ich hatte das 
Problem, dass der Webserver ständig über USART seinen Status abgibt. Der 
mega8 kennt diese Befehle nicht und antwortet mit Error (der Webserver 
antwortet auf den Error mit einem weiteren Error usw. -> 
Endlosschleife). Das hab ich bereits behoben. Allerdings gibt es ein 
Problem, wenn ich in der main das usart_write("Ready\r\n\r\n");) bzw. 
usart_write("ERROR\r\n\r\n"); auskommentiere (im Webserver und mega8). 
Bekannte Befehle wie HELP und ? oder LED1on funktionieren. Sobald ich 
aber einen unbekannten Befehl sende wird dieser zurückgegeben (Echo) und 
ein z.B. HELP oder andere bekannter Befehle funktionieren nicht mehr, 
erst nach einem Reset.
Ich hab die main - while - Schleife auch schon mal auf

1

  while(1)

2

  {

3

4

    if (usart_status.usart_ready)

5

    {

6

7

      cmd_exec(&usart_rx_buffer[0]);

8

      usart_status.usart_ready =0;

9

    }

beschränkt. Dann muss ich aber in der LED1on - Funktion irgendein 
usar_write("blablub"); haben sonst wird die LED1on nur ein einziges mal 
ausgeführt.

Also irgendwie hab ich den Eindruck, dass nach dem Empfang eines Strings 
auch ein String ausgegeben werden muss. Aber warum?? Das ist in meinem 
Fall schädlich, da die beiden Controller sonst in einer USART 
Endlosschleife hängen bleiben.

Ich hoffe mir kann jemand helfen. Dank im Voraus.

Stefan

PS: Ist mein erste uC Projekt in C.

Hier für alle die gleich den ganzen Bausatz des Webservers Bestellen 
wollen eine kleine Hilfe um die Bauteile etwas schneller in den 
Warenkorb zu legen als das von Hand möglich ist.

Also viel Spass mit der "OneClick in shopping cart" –Methode

P.S.:  evtl. müsst Ihr in euren Browser JavaScript erlauben

Sorry die aber die andere reichelt.htm hat einen Fehler aber diese 
funktioniert.

@Christian

"Pico 0,5A" gibt es wohl nicht (Sicherung).

Sonst: Geile Idee.

Doch die gibt es! Das ist nur eine Rückfrage von reichelt weil die 
Bestellmenge 0 ist alle anderen Bauteile sind ja schon ordentlich im 
Warenkorb.

Bestellmege 0 bei der Sicherung weil sie in Layout-Version ja noch nicht 
dabei ist.

Hallo,
mein System läuft jetzt auch. Echt tolles Projekt!
Nur wollte ich jetzt das LCD-Display nach der Schaltung von Ulrich 
anschließen. In der config.h habe ich   "#define USE_SER_LCD    1" 
gesetzt. Aber ich erhalte keine Anzeige.
Hatte aber kein 74AC164N da und habe einen 74HCT164 genommen. Kann es 
daran liegen?

Gruß

Martin

Hallo Ulrich,
vielen Dank für den Hinweis! Das war es. Ich betreibe den 644 mit 20 
Mhz. habe  den Wert von Busy_Wait auf 10000 gesetzt und schon habe ich 
eine Anzeige!
Gruß

Martin

Hallo Ulrich,
da der ATMEGA 644 auch als 20 MHz Version gibt, kann man dann nicht 
statt der festen Busy_Wait Vorgabe folgende Zeile in der lcd.h 
aufnehmen:   #define BUSY_WAIT        0.000375*SYSCLK
?

Gruß
Martin

Und wo ist dein Problem, Micha?

Hallo Micha,

wenn die Daten nicht in ein Packet passen wird der Rest doch eigentlich 
automatisch ins nächste Packet gepackt! Wie fügst du denn die aktuellen 
Daten in das Packet ein ? Wenn du die Variablen %VA... in die Seite 
packst, die dann beim kopieren der Daten vom Flash in den Puffer durch 
aktuelle Werte ersetzt werden sollte es eigentlich keine Probleme geben.

Gruss Sascha
_________________________________________________________________
http://sw-penig.dnydns.org:8080/wetter.htm

Habe gestern meine Reichelt Bestellung erhalten.

@Ulrich
Bei der Erstellung von „reichelt.htm“ habe ich mich an deine liste, aus 
dem Worddokument, in deiner Layout-zip gehalten.
1.  R8 ist in eagle aber 2K und in der Liste 2,7K damit auch bei der 
Bestellung
2.  JP1, JP2, JP3 sind laut liste Rastermaß 1,27 -> passen also nicht
 Ist es egal bei R8 ob der Wert 2K oder 2,7K ist?
Bei den JP`s habe ich bei reichelt nur SL 1X36G 2,54 als kleinste 
alternative gefunden mit 0,17€ sogar günstiger als in deiner Liste ;-)

Im Anhang habe ich die geänderte reichelt.htm.
Wenn R8 doch 2K sein soll einfach die  Bestellnummer in 1/4W 2,0K 
ändern.

PS.: kann man die alten reichelt.htm löschen damit nicht neue Leser die 
alten Versionen Verwenden?

Hallo,

R8 mit 2,7K ist richtig ich werde die Liste sofort aktualisieren.

Gruß
Ulrich

Hallo

ich möchte mir für die Einbaubuchse (HEBW 21) einen passenden 
Hohlstecker mitbestellen welcher ist da der Richtige (Reichelt).
HS 21-9 oder
HS 21-14
oder passen beide?

Kann mir bitte mal einer die Fuse-Einstellungen in HEX für einen 
ATmega644 geben.
Im orginal hat der
EXT: FF
HIGH:  99
LOW: 62

mit AVR-OSPII (547) ausgelesen

oder kann ich die aus dem makefile so verwenden

1

#Fuse settings for ATmega644

2

ifeq ($(MCU), atmega644)

3

  FUSE_BITS = -u -U lfuse:w:0xff:m -U hfuse:w:0xdf:m

4

  HEX_FILE_NAME = MEGA644

5

endif

EXT: FF
HIGH:  df
LOW: ff

mit WinAVR Version 20070525 oder der neuen 20071221

http://sourceforge.net/project/showfiles.php?group_id=68108

Hallo Ulrich und alle,
ich habe die Ansteuerung des ENC überarbeitet, dürfte deutlich schneller 
sein, da die Bankumschaltung wirklich nur wenn nötig geschieht, also 
nicht bei den gespiegelten Registern:
Beitrag "Re: I/O über Ethernet mit einem ENC28J60"
Beitrag "ENC28J60 correct value of PHLCON and mirrored registers"
Vielleicht will das jemand in dieses Projekt mit einarbeiten.

z.B.
  //config NIC LEDs
  enc28j60PhyWrite(0x14,0x047A);

besser:
  enc28j60_write_phy(ENC28J60_PHY_PHLCON, 0x3472);
//cave: Table3-3: reset value is 0x3422, do not modify the reserved 
"3"!!
//RevA Datasheet page 9: write as '0000', see RevB Datasheet: write 
0011!

Hi Ulrich,

kleine Kritik :(

In enc28j60.c wird _delay_ms() verwendet. An sich ja nicht
schlimm, aber man muss da höllisch aufpassen.

The maximal possible delay is 262.14 ms / F_CPU in MHz.

Bei 16MHz z.B. darf das delay also maximal 16ms sein.
Sonst gibt es falsche delays. Ich empfehle das Kapitel
zu _delay_ms() in der avrlibc Doku mal zu lesen. Da gibt
es noch ein paar andere Fallen bei _delay_ms().

So könnte man das Problem erstmal entschärfen:

void Delay_ms(unsigned int time)
{
 while(time--) { _delay_ms(1); }
}

Gruß
 Holger

@ulrich:

Tolles Video :-)

Weiter so.

Steffen.

Hi Ulrich, klasse Video!

[Kritik] habe gelernt, die Drähte der Bauteile VOR dem Löten 
abzukneifen, um Spannungen und die daraus folgende Whiskerbildung zu 
vermeiden [/Kritik]

Für Bastler nicht unbedingt notwendig, da die Projekte meist nicht für 
Langzeiteinsatz gedacht sind.

Trotzdem: geniales Teil, wird demnächst in meinem Heizungsregler platz 
finden! ;-)

Ist auch bei bleihaltigem Zinn schlimm genug, mit Bleifreiem gibt's ja 
noch keine Langzeiterfahrung.
Wie gesagt, bei Bastlern nicht so tragisch.

Wir haben sehr viele Ausfälle deswegen auf Karten, die so zwischen 20 
und 30 Jahren alt sind.

Das Bleifreie kennen ich noch gar nicht, bin auch nicht besonders scharf 
drauf! ;)

Die Platinen sind meistens doppelseitig. Die meisten Probleme gibt's bei 
dichter Bestückung und unter den Bauteilen (bevorzugt ICs mit 
Keramik-Gehäuse).
Oft sind auch die Drähte umgebogen (maschinelle Bestückung) und berühren 
bei höheren Temperaturen (Wärmeausdehnung) die benachbarte Leiterbahn.

Die kalten Lötstellen gibt's eher bei Produktionsfehlern wie Vibrationen 
bei der Verzinnung oder schlechtenm (billigem) Platinen- und 
Bauteilmaterial. Also nicht zittern beim Löten, vorher 'nen Kurzen 
kippen! ;)

Holla,
@Nik: Du hast Dir zwar viel gedacht, aber ich denke mal, dass Deine Idee 
wenig bringt, denn der Mega kann auch ein paar 16-Bit-Befehle:
addw
cmpw

Man müsste das mal im Assembler-Text anschauen.
und beim  Herabzählen auf 0  braucht man gar keinen expliziten 
Vergleich, denn da wird nur das Z-Flag abgefragt (z.B. bne  branch if 
not equal).

Im Übrigen könnte man Deine Idee auch für Zahlen über 256 realisieren, 
denn die oberen 8 Bits bleiben ja jeweils 256 mal gleich. Aber das 
bringt nur was auf Kernen, die wirklich nur 8-Bit-Befehle haben.

Der Code ist schon ziemlich kompakt, man könnte nur etwas eleganter 
schreiben:
while(len--){
  // write data
  SPDR = *data++
  while(!(SPSR & (1<<SPIF))){};
}

Aber genau so steht es ja in meinem File!

Ich bezweifle jetzt mal, dass Dein Code hier schneller ist.


@Simon K.:
Ich habe überhaupt nichts von den Erratas erwähnt oder vorgeschlagen. 
Aber Du hast recht, so weit ich mich erinnere, sind in Pascals Code die 
Errata noch nicht eingeflossen.


@Ulrich
Aha, Du hast Das .c-File komplett übernommen und nur das .h-File 
angepasst, sehr gut!

Das Video erinnert mich an eine Serie in meiner Kindheit, in der viel 
Handwerkliches gezeigt wurde,  ohne Worte, nur mit Hintergrundmusik.
Was das im WDR? Kennt das noch jemand?



Ich habe gestern mal die ASM-Outputs des Simon-Codes angeschaut, da gibt 
es noch deutliches Optimierungspotential bei den höheren Ebenen.

Oft werden 32-Bit-Variablen mühsam aus Bytes montiert, um dann wieder in 
Bytes zerlegt zu werden. Eigentlich müssten nur 4 Bytes kopiert 
werden...

Supi, mein Server läuft auch. Respekt und Dank an dieser Stelle!

Ein Problem nur mit dyndns:

dynamic-DNS-Account mit Router-IP eingerichtet, im Router DDNS und 
Portforwarding (Port 80 TCP&UDP) aktiviert. Wenn ich nun meine 
dyndns-URL aufrufe, meldet in stack.c die Funktion check_packet() 
"Erzeuge ARP Reply" über die DEBUG-Ausgabe - mehr passiert nicht.
Provider ist Kabel-Deutschland.

Was mach ich falsch oder wieso klappt es nur im lokalen Netz?

Nachtrag:
Mit Router-IP meinte ich die mir vom ISP vergebene IP ;-)

@ eProfi und Simon K.

Ich hab die Idee von Nik Bamert mal in meinen Code einfliessen lassen 
(leicht geaendert , da man den code von nik auch noch optimieren 
koennte) und habe es getestet.

100 Byte Udp Echo x 1000 wiederholungen

-> ca 8,5 % schneller bei mir

Ich hätte da auch einen Vorschlag zur Optimierung.
Hier mal für enc28j60_write_buffer()

Die Originalschleife ergibt folgenden Code

   while(len--){
  SPDR = *buffer++;
  while(!(SPSR & (1<<SPIF)));
    }

Das ASM Listing:

  while(len--){
    //send data
    SPDR = *buffer++;
    4e90:  80 81         ld  r24, Z
    4e92:  8e bd         out  0x2e, r24  ; 46
    while(!(SPSR & (1<<SPIF)));
    4e94:  0d b4         in  r0, 0x2d  ; 45
    4e96:  07 fe         sbrs  r0, 7
    4e98:  fd cf         rjmp  .-6        ;
    4e9a:  31 96         adiw  r30, 0x01  ; 1
    4e9c:  61 50         subi  r22, 0x01  ; 1
    4e9e:  70 40         sbci  r23, 0x00  ; 0
    4ea0:  8f ef         ldi  r24, 0xFF  ; 255
    4ea2:  6f 3f         cpi  r22, 0xFF  ; 255
    4ea4:  78 07         cpc  r23, r24
    4ea6:  a1 f7         brne  .-24       ; 0x4e90


Eine do Schleife ergibt viel besseren Code:

  do{
    SPDR = *buffer++;
    len--;
    while(!(SPSR & (1<<SPIF)));
  }while(len);


Das ASM Listing:

  do{
    //send data
    SPDR = *buffer++;
    4e8e:  81 91         ld  r24, Z+
    4e90:  8e bd         out  0x2e, r24  ; 46
    len--;
    4e92:  61 50         subi  r22, 0x01  ; 1
    4e94:  70 40         sbci  r23, 0x00  ; 0
    while(!(SPSR & (1<<SPIF)));
    4e96:  0d b4         in  r0, 0x2d  ; 45
    4e98:  07 fe         sbrs  r0, 7
    4e9a:  fd cf         rjmp  .-6        ; 0x4e96
          } while(len);
    4e9c:  61 15         cp  r22, r1
    4e9e:  71 05         cpc  r23, r1
    4ea0:  b1 f7         brne  .-20       ; 0x4e8e


Die Schleife enthält schon mal zwei Befehle weniger.
Das beste ist aber, das zwei Befehle schon ausgeführt werden
während das SPI Modul noch am shiften ist.

Gruß
 Holger

Nochmal zu dyndns von 4 Postings weiter oben:

Ich habe IP 91.65.221.64 genommen, die dyndns ermittelt hat, die 
gleiche, wie sie auch z.B. www.myip.ch anzeigt. Ist doch die Richtige, 
oder? Oder was ist die IP vom lokalen Netz?
Hier ein Auszug aus der Status-Page des Routers:

Geräteinformation:

LAN
MAC-Adresse  00-15-E9-E3-56-5F
IP-Adresse  192.168.0.1
Subnetzmaske  255.255.255.0
DHCP-Server  Aktiviert

WAN
MAC-Adresse  00-15-E9-E3-56-5E
Verbindung    DHCP Verbundener Client.

Verbleibende Lease-Time  00:50:05
IP-Adresse  91.65.221.64
Subnetzmaske  255.255.254.0
Gateway  91.65.221.254
Domain Name Server  83.169.184.33, 83.169.184.97

Danke & Gruß Frank

Sorry für die vielleicht naive Fragerei! Was ich aber nicht verstehe: 
192.168.0.1 ist doch praktisch die Standard-IP jedes Routers, wie soll 
xyz.dyndns.org dann ausgerechnet meinen finden?

@ Frank

für die Beantwortung externe Anfragen braucht dein WEB-Server die IP des 
Router's nicht zu wissen, denn der Router fragt ja per ARP in dein 
lokales Netz wo sich das Gerät mit der im Portforwarding eingerichteten 
lokalen Adresse befindet.
Bei mir funktioniert allerdings auch keine Anfrage aus dem lokalen Netz 
an meine öffentliche IP - irgendwas scheint der Router (T631) da nicht 
richtig zu händeln!?

Wenn ich den externen Seitenabruf meines WEB-Servers testen will, gehe 
ich immer über einen externen Proxy (z.B. über JAP).

Sascha
______________________________________________
http://sw-penig.dyndns.org:8080/wetter.htm

Hi,

hier könnte man noch etwas Zeit schinden:

void enc28j60_send_packet(unsigned int len, unsigned char *buffer)
{
  unsigned int tmp;
  //still sending ?
  //wait max 50*10 = 500ms:
  for(tmp=0; tmp<500; tmp++){
    if (!(enc28j60_read_address(ENC28J60_REG_ECON1) & 
(1<<ENC28J60_BIT_TXRTS))){
      //send finished -> tx packet
      break;
    }
    //tx not finished yet, wait 10ms
    _delay_ms(1);
  }

Warum 10ms warten wenn man auch nur 1ms warten kann ;)

Und hier mal eine Senderoutine zum nachdenken:

 SPDR = *buffer++;
 len--;

 unsigned char by;

 do
  {
   by = *buffer++;
   len--;
   while(!(SPSR & (1<<SPIF)));
   SPDR = by;
  }while(len);

 while(!(SPSR & (1<<SPIF)));

Schneller dürfte es kaum noch gehen. Der größte
Teil der Schleife wird ausgeführt während das
SPI Modul noch am schieben ist.

Gruß
 Holger

@ Holger

    warum nicht gleich in ASM

    hier mal mit den Registern aus deinem Posting weiter oben ...

//    len = r22,r23
//    *buffer = Z



    subi    r22,0x01
    suci    r23,0x00    ;len--   //wg. Abruchbedingung
loop:
    ld      r24,Z+      ;temp=*buffer++
wait:
    in      r0, 0x2d
    sbrs    r0, 7
    rjmp    wait        ;while(!(SPSR & (1<<SPIF)))
    out     0x2e, r24   ;SPDR = temp
    subi    r22, 0x01
    sbci    r23, 0x00
    brcc    loop        ;while(len--) //!Abruch der Schleife bei -1

-> erledigt alles innerhalb der der SPI-Ausführungszeit

Gruss
Sascha

>Bei mir funktioniert allerdings auch keine Anfrage aus dem lokalen Netz
>an meine öffentliche IP - irgendwas scheint der Router (T631) da nicht
>richtig zu händeln!?

Das hatten wir mal in einem anderen Thread. Das Thema war das gleiche.
Damals war es aber AFAIR ein AVM-Router.
Vielleicht liegt es an der DYNDNS-Freigabe im Router...

@ sascha

>    warum nicht gleich in ASM

Wozu ?
Das hat der Compiler draus gemacht:

 SPDR = *buffer++;
    4e8c:  f9 01         movw  r30, r18
    4e8e:  81 91         ld  r24, Z+
    4e90:  8e bd         out  0x2e, r24  ; 46
    4e92:  62 0f         add  r22, r18
    4e94:  73 1f         adc  r23, r19
 len--;

 unsigned char by;

 do
  {
   by = *buffer++;
    4e96:  21 91         ld  r18, Z+
   len--;
   while(!(SPSR & (1<<SPIF)));
    4e98:  0d b4         in  r0, 0x2d  ; 45
    4e9a:  07 fe         sbrs  r0, 7
    4e9c:  fd cf         rjmp  .-6        ; 0x4e98
    SPDR = by;
    4e9e:  2e bd         out  0x2e, r18  ; 46
  }while(len);
    4ea0:  e6 17         cp  r30, r22
    4ea2:  f7 07         cpc  r31, r23
    4ea4:  c1 f7         brne  .-16       ; 0x4e96



while(!(SPSR & (1<<SPIF)));
    4ea6:  0d b4         in  r0, 0x2d  ; 45
    4ea8:  07 fe         sbrs  r0, 7
    4eaa:  fd cf         rjmp  .-6        ; 0x4ea6

Sieht doch perfekt aus.
 Holger

@ Holger

Ja den buffer-Pointer als Abbruchbedingung zu verwenden ist auch ne 
Möglichkeit. Kürzer u. schneller wird's nun auf keinen Fall mehr - 
ausser bei den keineren ATMega-Typen, da ist das SPSR noch im Bereich wo 
ein direktes prüfen des Bit's im IO-Reg. möglich ist - aber das weiß der 
Compiler auch!



@ STK500-Besitzer

im T631 steckt auch Hardware von AVM - am DYNDNS kann's nicht liegen, 
denn der T631 hat keine DYNDNS-Client.

Gruss
Sascha

dyndns-klappt jetzt:

Zumindest bei mir (Router D-Link DI-524) hing es einfach am MAC-Filter 
"Nur Computern mit den aufgelisteten MAC-Adressen ist der Zugriff 
erlaubt", in dem musste ich den AVR-Server noch eintragen....

@ Simon K.

>Es ist aber problematisch, wenn man erst auf das Interruptbit wartet und
>dann ne SPI-Sendung losschickt.

Stimmt, aber ich denke du hast das

 SPDR = *buffer++;

oben über der Schleife übersehen. Das ist die erste Sendung
bevor das Interruptbit abgefragt wird. Nur deshalb funktioniert
die Schleife überhaupt.

Ich sagte ja: Man muss ein wenig drüber nachdenken ;)

Gruß
 Holger

Moin,

hier noch eine optimale Leseschleife für enc28j60_read_buffer()

  //read data & store in buffer:
   unsigned char by;

  SPDR = 0x00;
        len--;

   do
    {
    while(!(SPSR & (1<<SPIF)));
       by=SPDR;
    SPDR = 0x00;
       *buffer++ = by;
       len--;
    }while(len);

  while(!(SPSR & (1<<SPIF)));
        *buffer = SPDR;


Prinzip genau wie bei der Schreibschleife aus meinem obigen Posting.
Beitrag "Re: Webserver ATmega32/644DIP ENC28J60"

Der größte Teil der Schleife wird abgearbeitet während das SPI
Modul noch am schieben ist.

Schluß mit dem trödeln ;)
 Holger

@ Dirk
>die diskussion zum SPI-Speed hatten wir 2006 schon mal gehabt und hatten
>auch Code entwickelt. Interessant ist auch der Link im Beitrag selbst,
>wo der Code analysiert wird, an realen übertragungen.

Hi Dirk,

ich teste meine Codes an realen Übertragungen ;)

Hier mal ein paar Messergebnisse für enc28j60_write_buffer();
Gemessen bei 16MHz CPU Takt und ungefähr 1300 Bytes pro buffer.

Die Originalroutine mit while(len--)
     3.0ms

Meine erste verbesserte Version mit do{}while(len);
     2.4ms

Meine letzte optimierte Version
     2.0ms

Deine Codes sehen meinen schon recht ähnlich.
Da waren wohl die gleichen Gedankengänge am Werk.
Beim WinAVR ist es oft besser fußgesteuerte do{}while();
Schleifen zu verwenden wenn es geht. Der Schleifenzähler
sollte dabei auch runterzählen.

Das bringt aber nicht immer was. Da muss man ein bißchen
rumprobieren und öfter mal ins ASM-Listing schauen.

Ich hab auch schon mit Schleifen rumprobiert die
SPIF gar nicht mehr abfragen. Einfach mit genügend
NOP auffüllen. Da tritt einem aber der Compiler
oft in den Hintern weil er an den Schleifen
rumoptimiert. Am sinvollsten wäre wohl irgendwas mit
Inline Assembler. Aber dazu bin ich zu faul :(


Gruß
 holger

Hallo,

I2C wäre da noch frei! Ich komuniziere mit anderen Prozessoren über ein 
RFM12 Module dabei wird das SP-Interface über Software emuliert.

Gruß
Ulrich

Wenn du die serielle Schnittstelle nicht für printf o. ä. benötigst, 
kannst du auch diese verwenden. Sollte schnell und einfach zu machen 
sein. Wenn du eine strenge Master-Client Kommunikation aufbaust, können 
dann auch mehrere Teilnehmer kommunizieren.

Steffen.

Hallo,

für größere Leitungslängen ist auf alle Fälle eine serielle Übertragung 
mit RS485 Schnittstelle sinnvoll, da gibt's am wenigsten Probleme. Ich 
habe an meinem Webserver per RS485 über ca. 30m 2-Draht-Leitung (nur 
Halbduplex) noch 2 weitere AVR-Controller dran hängen.

Gruss

Sascha

____________________________________________
http://sw-penig.dyndns.org:8080/wetter.htm

Hallo,

In meinem Forum auf meiner HP habe ich schon das Problem gelöst max. 
10sek

Gruß
Ulrich

Hallo!
Kann mir vielleicht einer sagen wie ich diese Fehlermeldung wegbekomme ?

1

httpd.o: In function `httpd_header_check':

2

httpd.c:158: undefined reference to `strcasestr_P'

3

httpd.c:159: undefined reference to `strcasestr_P'

4

httpd.c:160: undefined reference to `strcasestr_P'

5

httpd.c:183: undefined reference to `strcasestr'

6

httpd.c:189: undefined reference to `strcasestr'

7

httpd.c:200: undefined reference to `strcasestr'

8

\newStack1_0_43/httpd.c:204: undefined reference to `strcasestr'

Schonmal vielen Dank!

Hallo
Der Fehler trat beim compilieren von Ulrich Radigs neuem Source Code 
auf.

Funktioniert mit der neuen Compiler-Version.
Vielen Dank für die Hilfe.

Hallo
habe aus einem alten Projekt nen Code, der sich meineserachtens sehr 
einfach in den des Webservers integrieren lässt. Hierbei handelt es sich 
um das Auslesen des ds1621 Temperatursensors.
Ich hab ihn jetzt auf das Mindeste gekürzt. Nur weiß ich jetzt nicht, 
wie ich das mit den Timern machen soll, da ich mich mit denen nicht so 
richtig auskenne. Im Prinzip muss das I2C_delay auf den Timer vom 
Webserver angepasst werden.

Hat einer ne Idee


Grüße Henning

sry, Hier der Anhang, etwas verspätet

Hallo,
ich habe Probleme mit der neuen Version 1.0.43. Ich betreibe das System 
mit dem 644 und mit der Taktfrequenz 14.7456MHz. Ohne LCD Display 
erhalte ich über die RS232 folgende Ausgabe:
System Ready
NIC init:
danach nichts mehr. Selbst über ein Ping ist er nicht erreichbar!
Wenn ich das LCD-Display aktiviere erhalte ich weder eine Anzeige noch 
eine Ausgabe über die RS232:
Mit den alten Version 1.0.40 klappt alles. Muss ich noch etwas 
zusätzlich ändern?

Gruß
Martin

Hallo Uli,
leider finde ich die angeführten Stellen nicht im Quelltext. Du meinst 
doch die "enc28j60_Init" in der enc28j60.c! Aber da und auch wo anders 
finde kein delay_us.
Ich benutze das Layout von Henning mit dem Magjack!
Gruß
Martin

Hallo Henning,
ja alle Brücken sind drinnen. Das Board klappt ja mit der Version 
1.0.40! Auch die Taktfrequenz ist richtig eingestellt.
Sind mit der neuen Version evtl. die Bauteil Toleranzen bei bestimmten 
Teilen kritischer?

Gruß
Martin

Hallo,
vielen Dank für die Hilfen. Konnte den Fehler nicht finden. Nach dem bei 
meinen Board von Ulrich die Version auch nicht funktionierte habe ich 
noch einmal den Quellcode geladen und auf die IP-Adressen angepasst. 
Jetzt klappt es! Bei der ersten Anpassung muss mir irgendwo ein Fehler 
unterlaufen sein.
So jetzt werde ich versuchen die Kamera anzusteuern.

Gruß
Martin

Hallo,

habe das mit dem Wertebereich der Variable für die Servoposition noch 
nicht ganz begriffen

volatile unsigned char servo_pos;// min = 28/1ms max = 56/2ms


was ist hiermit gemeint?:
// min = 28/1ms max = 56/2ms

Kann mir da jemand genaueres zu sagen?
evntl. mit Beispiel

danke schonmal

Günni

Also heisst, wenn er bis zum rechten Anschlag drehen soll

servo_pos = 28;
servo_go_pos();

und wenn er bis zum bis zum linken Anschlag drehen soll:

servo_pos = 56;
servo_go_pos();

????

und was ist dann mit servo_pos = 0; ?? das soll doch eigentlich die 
mittelstellung sein, oder?

>und was ist dann mit servo_pos = 0; ?? das soll doch eigentlich die
>mittelstellung sein, oder?

Wie wärs mit 42 ?

Naja, wundere mich halt, weil Ulrich in der servo_init die servo_pos 0 
gesetzt hat und das liegt ja anscheinend nicht im zulässigem Bereich

Hallo, habe das Servo nur zum Test ganz Primitiv eingebunden:

1

if(strcasestr_P((char*)&eth_buffer[a],PSTR("LED3=3"))!=0){tmp |=(1<<PA2);}

2

          if(strcasestr_P((char*)&eth_buffer[a],PSTR("LED4=4"))!=0){tmp |=(1<<PA3);}

3

          if(strcasestr_P((char*)&eth_buffer[a],PSTR("LED5=5"))!=0){tmp |=(1<<PA4);}

4

          if(strcasestr_P((char*)&eth_buffer[a],PSTR("LED6=6"))!=0){tmp |=(1<<PA5);}

5

          if(strcasestr_P((char*)&eth_buffer[a],PSTR("LED7=7"))!=0)

6

                    {

7

                    tmp |=(1<<PA6);

8

                    servo_pos = 29;

9

                    servo_go_pos();

10

                    }

Nun passiert folgendes: Sobals man die Checkbox markiert hat und auf 
Senden klickt, bewegt sich das Servo um 2-3° und dann stürzt der ganze 
Server ab.

Woran kann das liegen??

Grüße

>Nun passiert folgendes: Sobals man die Checkbox markiert hat und auf
>Senden klickt, bewegt sich das Servo um 2-3° und dann stürzt der ganze
>Server ab.
>Woran kann das liegen??

Netzteil zu schlapp ?

Hi Ulrich,

ich hab da eine unschöne Stelle im httpd gefunden.
In http_data_send()

 b = ((*http_entry[index].new_page_pointer+3)-48)*10;

oder genauer nur dies hier

 *http_entry[index].new_page_pointer+3

Da scheint es nicht eindeutig zu sein was der Compiler
zuerst machen soll. Erst den Pointer + 3 und dann
den Wert aus dem Speicher holen, oder erst den Wert
aus dem Speicher holen und DIESEN dann + 3.
WinAVR macht es so wie geplant. WinARM bevorzugt
Methode 2 und prompt geht es schief.

Zwei Klammern mehr und alles ist eindeutig:

 b = ((*(http_entry[index].new_page_pointer+3))-48)*10;


Achso, und das hier ist auch nicht schön.
Auch in http_data_send()

char var_conversion_buffer[10];

str_len = strnlen(var_conversion_buffer,MAX_VAR_ARRAY);

MAX_VAR_ARRAY ist glaub ich für was anderes gedacht ;)


Gruß
 Holger

>Die Stelle konnte ich nicht finden:
>b = ((*http_entry[index].new_page_pointer+3)-48)*10;

Upps, kannst du ja auch nicht. Ist ja nicht dein Originalcode.
Den Fehler hab ich mir selber eingebrockt.

Entschuldigung bitte für die Falschmeldung :(

Beim nächsten mal pass Ich besser auf.
Holger

Hallo, ich weiß nichtmehr weiter, es scheitert immer an den einfachsten 
Sachen.
Folgendes: Die If Anweisung wird durchgeführt, aber Hinterher führt er 
auch noch die Else Anweisung durch . Ist doch irgendwie komisch, oder? 
Macht der Compiler da irgendwas komisches draus?

1

          if(strcasestr_P((char*)&eth_buffer[a],PSTR("LED7=7"))!=0){tmp |=(1<<PA6);}

2

                    if(strcasestr_P((char*)&eth_buffer[a],PSTR("LED8=8"))!=0)

3

                    {

4

                    tmp |=(1<<PA7);

5

                    servo_pos = 255;

6

                    servo_go_pos();

7

                    }

8

                    else

9

                    {

10

                    servo_pos = 0;

11

                    servo_go_pos();

12

                    }

Kann mir jemand weiterhelfen??

Grüße

Hat sicher erledigt...

Grüße

Hi Ulrich,

ich hätte da mal wieder einen Vorschlag :(

arp_timer_call(); verbrät unnötig Rechenzeit im Timerint.
Außerdem besteht die Gefahr das ein ARP Eintrag gelöscht
wird obwohl er eigentlich noch gebraucht wird !

Ich würde es einfach hier mit eintragen:

void eth_get_data (void)
{
  if(eth.timer)
  {
    tcp_timer_call();
    arp_timer_call();
    eth.timer = 0;
  }


Gruß
 holger

Hallo,

da ich in der letzten Zeit kaum etwas µC-artiges gemacht habe, war ich 
doch etwas überrascht, dass nun schon Version 53(?) aktuell ist. Zuletzt 
habe ich irgendwas um die 40 verwendet.

Da ich recht viel Aufwand in meine httpd gesteckt habe, die Frage, ob 
ich die stack.c/h und enc28j60.c/h einfach so austauschen kann oder hat 
sich auch an den Schnittstellen zwischen den Modulen was geändert?

Gruß
Steffen.

Funktioniert der aktuelle Code von Ulrich (7.1.2008) noch mit einem 
atmega32?

Ich hab folgendes Problem ich habe mit der fertigen hex von Ulrich einen 
erfolgreichen test gemacht das geht wunderbar. Wenn ich dann versuch 
noch mal selbst zu kompilieren (makefile MCU = atmega32) geht nix mehr.

Bin ich nur zu blöd oder hab ich was übersehen oder geht das einfach 
nicht?

Gruss Sven

Hey danke für die schnelle Hilfe, das war genau mein Problem.
Ich find das Projekt echt super ok die Hardware von dir benutz ich nicht 
ich hatte da noch was eigenes rumfahren. Aber die Software ist super, 
Hut ab Ulrich.

Mit freundlichen Grüßen Sven

Hallo zusammen,

so jetzt hab ichs endlich geschafft den Server mit AVR Studio zum Laufen 
zu bringen...
Falls jemand so wie ich lieber mit dem AVR Studio arbeitet, kann er das 
Projekt im Anhang verwenden (ist die momentan aktuelle Version 1.0.54).

Schöne Grüße und macht weiter so!

Ich war einige Zeit offline.

"Sicher, dass das überhaupt etwas an Rechenleistung braucht? Ich bin mir
ziemlich sicher, dass der Compiler hier nur noch die Zugriffsreihenfolge
in den Speicher beachtet, wenn er Variablen in oder aus Register/n 
holt."

Dann schau Dir mal das Assemblerlisting an, es werden etliche unnötige 
'clr' und 'or' verbraten.

Ich mache solche Zugriffe immer mit Unions, da weiß der Compiler gleich, 
was ich meine:

#define lo 0
#define hi 1
union {unsigned long l;unsigned int i[2];unsigned char c[4]} test;
oder mittels typedef
und die Zugriffe dann mit test.l=0x12345678  test.i[hi] oder test.i[lo] 
oder test.c[0]



@Holger, @Sascha
Überraschung:
while((len--))
ist für WinAVR nicht gleich mit dem viel schneller ausgeführten
while((len=len-1)),
hier verwendet er das vom sbic gesetzte Z-Flag für den Branch!

Ich sehe überall noch Optimierungspotential.

Versuchsweise mal das versucht:
while((len.c[hi]--))
  while((len.c[lo]--)){
    send...
  }
Das habe ich schreiben können, wie ich wollte (auch mit do..while), er 
hat nie das Zero-Flag direkt ausgewertet. Trotzdem es so noch schneller 
ginge, hat der Compiler es immer langsamer gemacht.

Übrigens ist empfohlen (für bessere Lesbarkeit), doppelt zu klammern, 
wenn man ein non-bool-Wert als bool verwendet.

Noch was:
Es lohnt sich einfach nicht, wegen 10 Bytes Code eine Sub zu callen.
Zuerst versuchte ich, Zeit zu sparen, indem ich die untersten Level mit
inline
in die nächst höheren Ebenen einzubinden.
Das macht er zwar, aber anders als ich mir das vorgestellt hatte.
Er verwendet für die Übergabe die std-Register (r24 & co), lediglich der 
Call und der Ret werden eingespart.

Wesentlich besser ist es, die unteren Level z.B. als
#define enc28j60_read_address( ....
anzugeben, dann werden sie wirklich eingebunden und die Register 
individuell und optimal verwendet.

>Übrigens ist empfohlen (für bessere Lesbarkeit), doppelt zu klammern,
>wenn man ein non-bool-Wert als bool verwendet.

Was heisst "ist empfohlen"? Wer empfiehlt das?  Hast du einen Link, in 
dem solche Tipps gegeben werden? Gibt es da einen Standard? Würde mich 
mal interessieren, was sonst noch so gibt.

Gruß
Steffen.

Hi Ulrich,

Ich hätte da (wieder :( mal einen Vorschlag.
Es geht um das %END was da bei den Arrays im Flash
immer abgefragt wird. Man kann das umgehen.

Beim NTP habe ich es mal rausgenommen und
über sizeof(NTP_Request) einfach die Länge mit
dem Compiler abgefragt. Funktioniert.
Siehe geänderter Code für ntp.c im Anhang.

Beim httpd dürfte es etwas schwieriger werden
da man mit dem Pointer auf das Objekt nicht
mit sizeof() die Länge abfragen kann.
Da müsste wohl noch die Längenangabe in die
struct http_table mit rein. Diese müsste man
in httpd_header_check() eintragen lassen.

Oder gleich in webpage.h machen

  typedef struct
  {
    const char *filename;    //Dateiname der Seite
    PGM_P page_pointer;      //Zeiger auf Speicherinhalt
                unsigned int size;              //Größe des Objektes
  } WEBPAGE_ITEM;

WEBPAGE_ITEM WEBPAGE_TABLE[] = // Befehls-Tabelle
{
  {"index.htm",Page1,sizeof(Page1)},
  {"Status.htm",Page4,sizeof(Page4)},

Der Vorteil wäre das Grafiken aus dem Flash
schneller geladen werden könnten weil nicht
bei jedem Byte auch gleich noch auf %END gecheckt wird.

Über http_entry[index].http_header_type könnte man dann
entscheiden: Ist das ne HTM die geparst werden muss oder
kann ich die Grafik einfach so in den Puffer kopieren ?
Ein weiteres Problem ist dann natürlich: Passt die Grafik
komplett in den Puffer, oder müssen mehrere Stückchen
gesendet werden.

Hört sich kompliziert an und ist auch nur mal was
zum nachdenken.

PS: Ändere in der Status.htm doch mal "Sart" auf "Start" ;)

Gruß
 Holger

>Ähem, wofür gibt es in C eigentlich den String-Ende-Terminator?

Ein Bild ist kein String. Da kommen Nullen an allen möglichen
Stellen vor ;)

>Nein, aber für eine Webseite würde das funktionieren.

Da hast du recht.

Hallo,

Das mit der Endmakierung ist wie schon gesagt auf die Bilder 
zurückzuführen. Da diese ja keine Strings sind aber in der gleichen 
Routine verarbeitet werden. Da ich sowieso immer das % Abfrage für 
dynamische Inhalte ist dahingestellt ob ein anderes verfahren viel mehr 
bringt.

Gruß
Uli

@Ulrich Radig

Sind die Versandkosten für die Serverplatine statisch oder lassen sie 
sich noch nach unten korrigieren?
Eine Warensendung würde es doch auch tun oder?

thnx

Hi Ulrich,

hab das mit der Abfrage von %END jetzt viel einfacher gelöst:

//Müssen Variablen ins Packet eingesetzt werden? ===> %VA@00 bis %VA@09
if (b == '%')
{
  //wurde das Ende des Packetes erreicht?
  //Verbindung TCP Port kann beim nächsten ACK geschlossen werden
  //Schleife wird abgebrochen keine Daten mehr!!
  if (strncasecmp_P("END",http_entry[index].new_page_pointer,3)==0)
      {
        tcp_entry[index].app_status = 0xFFFD;
        //a++;
        break;
      }

  if (strncasecmp_P("VA@",http_entry[index].new_page_pointer,3)==0)

So wird bei den Grafiken nicht bei JEDEM Byte komplett auf %END 
gecheckt.

Gruß
 holger

Diese Methode mit der Untersuchung auf "%" ist besonders sinnvoll, wenn 
man mehrere Abfragen hat (%END, %VA@xx, %VI@xx, ...). Vielleicht ist es 
auch sinnvoll, unterschiedliche Methoden für Daten mit und ohne "%" zu 
implementieren. So spart man sich die Abfragen und die Pakete können 
komplett ausgenutzt werden.

Steffen.