mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Webserver: GET für Bilder kommt nicht immer


Autor: Martin M. (martin69)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich habe das Problem bei meinem Webserver, daß manche Bilder zum Teil 
nicht angezeigt werden. Es liegt definitiv daran, daß der GET-Request 
vom Browser nicht an den AVR geschickt wird!!!
Es sind nicht immer die selben Bilder und auch die Anzahl der fehlenden 
Bilder ist unterschiedlich. Ich versuche schon tagelang das Problem zu 
finden, aber ich komme nicht mehr weiter. Ich habe im Anhang das Problem 
etwas genauer geschildert. Ich hoffe jemand kann mir dabei weiter 
helfen.

Gruß
Martin

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hast du schon mal den Browser gewechselt?

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
a) Testweise umstellen auf HTTP/1.0 (sosnt laufen mehrere GET Request 
über eine Verbindung was der Webserver u.U. nhct mag)
b) Pufferüberlauf? Deshalb keine "großen" Bilder.
c) Codierungsproblem?
d) Fordere die Bilder doch mal manuell per Socket an und schau was da 
rauskommt.

Autor: Martin M. (martin69)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Benedikt K. wrote:
> Hast du schon mal den Browser gewechselt?

ich habe es auch mit dem Netscape Navigator probiert, den ich auf dem PC 
habe. Mit dem geht es allerdings überhaupt nicht, der findet den 
Webserver mit der eingegebenen IP-Adresse nicht. Da ist irgendwas 
verstellt...

Der Webserver sollte vor allem mit dem Internet Explorer funktionieren, 
da ich weltweit von verschiedenen PC´s auf diesen zugreifen möchte.

Im Anhang nochmals der HTML-Code, diesmal als separate Datei.

Autor: Martin M. (martin69)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Läubi .. wrote:
> a) Testweise umstellen auf HTTP/1.0 (sosnt laufen mehrere GET Request
> über eine Verbindung was der Webserver u.U. nhct mag)
> b) Pufferüberlauf? Deshalb keine "großen" Bilder.
> c) Codierungsproblem?
> d) Fordere die Bilder doch mal manuell per Socket an und schau was da
> rauskommt.

a) wo kann ich das umstellen?
Meinst Du die Antwort (HTTP-Header), die ich vom AVR sende:
HTTP/1.1 200\r\nContent-Type: "text/html"... in "HTTP/1.0" ändern?

b) das kann ich ausschließen.

c) was meinst Du mit Codierungsprobleme?

d) wie mache ich das? Wie schon gesagt, wenn ich im Internet-Expolorer 
die fehlenden Bilder mit Rechtsklick "Bild anzeigen" hole, dann werden 
die auch angezeigt.

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
zu 1) jepp! Und für Bilder sendest du doch hoffentlich nen anderen 
Content type??
zu 2) okay
zu 3) char vs. unsigned char z.B. kann Probleme verursachen wenn man 
Binärdateien sendet
zu 4) --> Google --> C+Sockets

Autor: Martin M. (martin69)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Läubi .. wrote:
> zu 1) jepp! Und für Bilder sendest du doch hoffentlich nen anderen
> Content type??
> zu 2) okay
> zu 3) char vs. unsigned char z.B. kann Probleme verursachen wenn man
> Binärdateien sendet
> zu 4) --> Google --> C+Sockets

1) es gibt bei mir folgende Unterscheidungen, je nach Dateityp im 
HTML-Header:
PROGMEM char FLASH_WEB_HEADER_HTM[]    = { "text/html" };
PROGMEM char FLASH_WEB_HEADER_JPG[]    = { "image/jpeg" };
PROGMEM char FLASH_WEB_HEADER_BMP[]    = { "image/bmp" };
PROGMEM char FLASH_WEB_HEADER_GIF[]    = { "image/gif" };

3) ich verwende für die Strings üblicherweise unsigned char. Aber das 
dürfte dem AVR doch egal sein, weil er die Daten nur durchschleift und 
nicht bearbeitet.

4) ich wede es mal probieren, aber vermutlich verstehe ich nur 
Bahnhof...

Autor: Läubi .. (laeubi) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Benötigt Java (www.java.com).

Dann in der Konsole aufrufen:
JAVA -jar testclient.jar http://mikrocontroller.net

Alternativ noch umleiten in eine Datei:
JAVA -jar testclient.jar http://mikrocontroller.net > output.txt


Das gibt dir dan die Sachen aus welche auch dein "Browser" empfangen 
müßte... oder einen Fehler :)
Mußt mikrocontroller.net natürlich durch die IP deines Servers erseten.

Autor: Martin M. (martin69)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Läubi .. wrote:
> Benötigt Java (www.java.com).
>
> Dann in der Konsole aufrufen:
> JAVA -jar testclient.jar http://mikrocontroller.net
>
> Alternativ noch umleiten in eine Datei:
> JAVA -jar testclient.jar http://mikrocontroller.net > output.txt
>
>
> Das gibt dir dan die Sachen aus welche auch dein "Browser" empfangen
> müßte... oder einen Fehler :)
> Mußt mikrocontroller.net natürlich durch die IP deines Servers erseten.

Java hab ich gerade installiert. Und auch Deine jar-Datei downgeloaded. 
Wie ich jetzt weiter vorgehen muß, ist mir nicht ganz klar. Ich habe mal 
die jar-Datei doppel-geklickt, aber es tut sich nicht viel.
Konsole? Meinst Du die, die man beim Rechtsklick auf das Symbol unten 
anklicken kann (siehe Bild)? Den Durchblick habe ich leider nicht so 
besonders...

Autor: Martin M. (martin69)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich habe nun mal bei "start" => "ausführen" folgendes eingegeben:
JAVA -jar c:\testclient.jar http://192.168.178.21 > c:\output.txt

Es erscheint kurz ein Fenster, das aber wieder zu geht. Wenn ich es mit 
der Stop-Taste anhalte, dann stehen dort Inhalte meiner HTML´s. Aber es 
ist schwierig, die Stop-Taste zum richtigen Zeitpunkt zu drücken. Was 
muß ich machen, daß das Fenster offen bleibt?

Die von mir angegebene Datei c:\output.txt wird übrigens nicht erzeugt.

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
bei ausführen 'cmd' eingeben

Autor: Martin M. (martin69)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Läubi .. wrote:
> bei ausführen 'cmd' eingeben

Ich habe nun die Seiten aufgerufen, bei der die Sache mit den Bildern 
kommen sollte:
JAVA -jar c:\testclient.jar http://192.168.178.21/grafik.htm?stockwerk=2 
> c:\output.txt


jetzt hat es geklappt. Vielen Dank für den Tipp!
Das output-File sieht genau so aus wie die HTML-Datei, die der Webserver 
gesendet hat. Und nun???

Übrigens: Die Sache mit "HTTP/1.0" geht nicht. Da gehen selbst die 
HTML-Seiten nicht mehr vernünftig (Frames, ...). Bilder gehen überhaupt 
nicht mehr.

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ruf mal ein Bild ab (umleiten per > test.jpg) und schau dann ob es 
richtig ankommt (also vieleicht mal in der Bildbearbeitung öffnen).

>Übrigens: Die Sache mit "HTTP/1.0" geht nicht. Da gehen selbst die
>HTML-Seiten nicht mehr vernünftig (Frames, ...). Bilder gehen überhaupt
>nicht mehr.
Sehr komisch, was für nen Webserver benuzt du den?

Autor: Martin M. (martin69)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Läubi .. wrote:
> ruf mal ein Bild ab (umleiten per > test.jpg) und schau dann ob es
> richtig ankommt (also vieleicht mal in der Bildbearbeitung öffnen).

hab ich mit einem GIF gemacht (siehe Anhang). Dateigröße von Original 
auf SD-Karte ist identisch mit dem Output-File. Aber das Output-Bild 
geht nicht. Der Anfang der Datei ist identisch, dann kommt nur Mist bei 
der Output-Datei. Aber als ich die Bild-Datei mit dem Browser 
angefordert habe, wurde dieses dort korrekt angezeigt. Komisch...

> Sehr komisch, was für nen Webserver benuzt du den?
Marke Eigenbau. ATMega128 + XPORT Direkt+. Ich sende die Bilder 1:1 an 
den XPORT. Der XPORT macht TCPIP draus.

Ich habe mal mit Wireshark geschaut, was unterschiedlich ist, wenn ich 
die Bilder nicht vom Webserver nehme, sondern von meiner Homepage:

Werden die Bilder von der Homepage geholt, dann läuft das irgendwie 
parallel. Während die HTML-Datei vom Webserver geholt wird, werden 
parallel dazu schon die GET´s für die Bilder von der Homepage 
ausgegeben.
Wenn alles im Webserver ist (HTML und Bilder), dann wird erst das HTML 
komplett geholt und anschließend die Bilder mit GET angefordert. Leider 
halt nicht von allen, die sich im HTML befinden.

Wenn die Bilder von der Homepage kommen, dann sehe ich die Bilddaten im 
Datenstream irgendwie nicht. Da kommen kaum Daten von meiner Homepage. 
Die Bilddaten fangen ja mit "GIF89a" an, den String hab ich nicht 
entdeckt. Entweder fängt die Winshark nicht ein oder es ist irgendwie 
komprimiert.

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Aber als ich die Bild-Datei mit dem Browser
> angefordert habe, wurde dieses dort korrekt angezeigt. Komisch...

Evtl. spielt dir der Browser-Cache einen Streich.. ;-)

> Die Bilddaten fangen ja mit "GIF89a" an, den String hab ich nicht
> entdeckt. Entweder fängt die Winshark nicht ein oder es ist irgendwie
> komprimiert.

..sind die Daten nicht Base64 (oder wie das nochmal hieß..) codiert?

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das parrallele Abrufen ist "normal" siehe:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html

Martin M. wrote:
> Wenn alles im Webserver ist (HTML und Bilder), dann wird erst das HTML
> komplett geholt und anschließend die Bilder mit GET angefordert. Leider
> halt nicht von allen, die sich im HTML befinden.
Sende im Header mal explizit bei jeder Anfrage
Connection: close
zu senden.

Bei Tests mit dem Browser ist das immer sone Sache --> Stichwort Cache

Autor: Läubi .. (laeubi) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Das Problem mit dem nicht darstellbaren Bild liegt vermutlich an der 
Console... Sorry daran hatte ich nicht gedacht.

Im Anhang mal ein erweitertes Programm.
Aufruf:
 java -jar testclient.jar test.jpg test2.jpg
  Vergleicht zwei Dateien Byteweise und gibt die Unterschiede aus
 java -jar testclient.jar http://test.de/bild.jpg
  Lädt die Datei und speichert sie unter dem angegebenem Dateinamen byte 
genau ab, zeigt zudem Header informationen des Servers an.

Autor: Martin M. (martin69)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
den Cache hatte ich bereits ausgeschaltet. Somit holt der Browser 
jedesmal die Bilder vom Webserver.

Das mit dem erweiterten Programm teste ich morgen Abend mal aus. Vielen 
Dank. Ich melde mich dann morgen Abend wieder.

Autor: Martin M. (martin69)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jetzt hab ich die neue JAR-Datei ausprobiert. Beim Holen der Datei vom 
Webserver gibt es folgende Statusmeldung:

Connect...
Encoding:  null
Type:  image/gif
Length:  9916
=== Header fields ===
null:  [HTTP/1.1 200]
CONTENT-LENGTH:  [9916]
Content-Type:  [image/gif]
Connection:  [close]
Read...
Done!

Sieht doch gut aus, oder?

Wenn ich die Originaldatei mit der empfangenen vom Webserver vergleiche, 
dann gibt es keine Fehlermeldung bezüglich Unterschiede:

Datei 1: C:\fehler\output.gif 9916bytes
Datei 2: C:\fehler\sd_karte.gif 9916bytes

Ist auch im grünen Bereich....


Das Problem ist ja nicht, daß die Bilder falsch übertragen werden, die 
auf der Seite nicht angezeigt werden. Sondern der GET-Request kommt 
nicht vom Browser von den fehlenden Bildern. Somit werden die Daten der 
fehlenden Bilder auch nicht vom Webserver gesendet.

Das "Connection: close" hab ich übrigens schon immer so drin.

Hast Du nun noch ne Idee, was man machen könnte?

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also das sieht soweit okay aus. Ich würde dann das Problem mal im 
Bereich des Browsers suchen. Hast du ne möglichkeit alle Request an den 
Webserver zusätzlich per RS232 an den PC zu senden oder sonstwie zu 
loggen?
Ich bin erstmal beim Sport melde mich vorraussichtlich so gegen halb 11 
nochmal, werde dann die Sotware so erweitern das die auch ne Website 
anzeigen kann, vieleicht bringt das Klarheit.

Autor: Martin M. (martin69)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich kann mittels Schieberegister- und Gattergrab die Quelle für den 
USB-Anschluß auf der Platine umschalten. Ich kann dann z.B. die TX- oder 
RX-Signale vom XPORT auf der USB-Schnittstelle ausgeben und mit dem PC 
aufzeichnen. Allerdings muß ich hierbei die Geschwindigkeit zwischen 
XPORT und AVR reduzieren, denn da fahre ich derzeit über 230 kBit/s. Ist 
aber kein riesiges Problem. Ich kann z.B. mit 57,6 arbeiten. Dann geht 
halt alles etwas langsamer.

Das wäre super, wenn Du da ne Möglichkeit hättest.

Autor: Läubi .. (laeubi) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Sonst wenn du noch etwas Ram frei hast mach dir nen Ringpuffer für 10 
Anfragen (get reicht denke ich), und schreib den Puffer raus wenn man ne 
spezielle Seite abruft (log.txt) oder so. Gff ist auch ne SoftUART ne 
Option, würde zumindest helfen von "Protokoll unabhängiger" Seite die 
Sache zu betrachten.

Neue Version im Anhang:
Doppelklick oder Aufruf via commandozeile ohne Parameter startet den 
Minibrowser. Aber nicht zuviel erwarten der kann nur HTML kein 
JavaSkript/Cookoies, CSS nur eingeschränkt etc. ;)

Hier noch ne Vermutung da ich den XPORT nicht kenne:
ggf erlaubt dieser nur eine begrenzte Anzahl verbindungen, durch dein 
close zwingst du aber den Browser mehrere zu öffnen...
Versuchs mal mit 'Keep-Alive' anstelle von 'close' du müßtest dann über 
eine Verbindung nur mehrere Request abarbeiten, vieleicht machst du das 
aber sowieso schon wie gesagt ich weiß nicht wie das mit dem XPORT 
abläuft.

Autor: Martin M. (martin69)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Läubi .. wrote:
> Sonst wenn du noch etwas Ram frei hast mach dir nen Ringpuffer für 10
> Anfragen (get reicht denke ich), und schreib den Puffer raus wenn man ne
> spezielle Seite abruft (log.txt) oder so. Gff ist auch ne SoftUART ne
> Option, würde zumindest helfen von "Protokoll unabhängiger" Seite die
> Sache zu betrachten.
das ist ne gute Idee.

> Neue Version im Anhang:
> Doppelklick oder Aufruf via commandozeile ohne Parameter startet den
> Minibrowser. Aber nicht zuviel erwarten der kann nur HTML kein
> JavaSkript/Cookoies, CSS nur eingeschränkt etc. ;)
nicht schlecht! Der Browser ist echt gut geworden. Werde später mal 
meinen Webserver testen. Bin gerade nicht in meinem "Bastelzimmer".

> Hier noch ne Vermutung da ich den XPORT nicht kenne:
> ggf erlaubt dieser nur eine begrenzte Anzahl verbindungen, durch dein
> close zwingst du aber den Browser mehrere zu öffnen...
> Versuchs mal mit 'Keep-Alive' anstelle von 'close' du müßtest dann über
> eine Verbindung nur mehrere Request abarbeiten, vieleicht machst du das
> aber sowieso schon wie gesagt ich weiß nicht wie das mit dem XPORT
> abläuft.
Der XPORT hat einen Webserver integriert, aber dann muß man die 
Internetseiten mit JAVA machen, wenn man über die Schnittstelle mit dem 
AVR Daten austauschen möchte. Das ist mir zu aufwändig, mich da 
einzuarbeiten. Daher nutze ich die Webserver-Funktionalität des XPORT 
nicht. Die Daten vom AVR werden nur 1:1 durchgeschleift. C kann ich 
einigermaßen programmieren (wenn auch nicht perfekt), aber es ist für 
mich einfacher, die HTML-Seiten je nach Randbedingung im AVR aufzubauen.
Der AVR kann nur 1 Connection handeln, so habe ich das zumindest 
programmiert. Wie soll ich das trennen mit mehreren Kanälen? Ich sende 
doch nur die Daten auf einen GET-Request. Ich wüßte nicht, wie ich das 
machen sollte, wenn es da mehrere GET-Requests parallel geben würde.

Wo muß ich das "keep alive" senden? Nur bei den Bildern oder auch beim 
HTML-File? Und wie wird die Verbindung dann am Ende geschlossen? Müßte 
ich nach der Übertragung ein "close" irgendwie übertragen?

Ich weiß, daß meine Lösung des Webservers vielleicht nicht gerade die 
beste ist, aber für meine Software-Kenntnisse ist er gar nicht so 
schlecht geworden. Ich kann den Stand der Rolläden abfragen (oben, 
unten) und kann übers Internet die Rolläden bedienen, wenn ich mal nicht 
zu Hause bin. Es wäre halt gut, wenn die Bilder auch auf dem Webserver 
wären. Wenn ich diese auf meine Homepage "auslagere" ist das etwas 
"primitiv".

Man kann zwar auch Bilder auf dem XPORT Direct+ ablegen, aber wenn man 
die Serverfunktionalität deaktiviert, dann kann man nicht mehr auf diese 
zugreifen. Heißt: wenn ich die HTML´s vom AVR sende, dann müssen auch 
die Bilder von AVR gesendet werden. Ne Unterscheidungsmöglichkeit gibt 
es da laut Hersteller nicht.

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Im Header statt
connection: close
connection: keep-alive

Das hat zur Folge das der Browser eine Verbindung aufbaut, einen Request 
absendet (header endet ganz normal) aber Verbindung wird nicht 
geschlossen. Du sendest dem Brwoser die Datei, hierbei ist aber 
Content-Length ein Plicht - Feld (logisch sonst weiß der Bowser nicht 
wo die eine Datei endet und die andere aufhört), auf der noch offenen 
Verbindung sendet der Brwoser dann weitere Requests die du wiedrum 
beantwortest, bis der Server die verbindung schließt weil er alles 
geladen hat. Dies signalisiert er dir in der Art das er seinerseits mit 
dem lezten Request ein "Connection: close" im Header sendet.
Du als server hast natürlich auch jederzeit die Möglichkeit zu sagen: 
Schluß ich mag nicht mehr, du DARFST aber jederzeit die Verbindung 
trozdem offen lassen auch wenn der Browser sagt er macht zu also wenn 
mans nicht zu genau nimmt kann man IMMER keep-alive senden, die 
Gegenstelle wird dann von sichaus die Verbindung schließen ;)
Falls man (z.B. bei einer dynamischen Website) nicht von anfang an weiß 
wie groß die ist gibt es die Möglichkeit des "chuncked encodings".

Das Problem könnte jezt folgendes sein wenn du NICHT erlaubst die 
Verbindung weiter zu benutzen:
- Der Brwoser holt sich die HTML Seite
- findet X Bilder
- Versucht das erste zu laden --> du sagst er darf die Verbindung nicht 
weiterverwenden.
- deshalb wird versucht eine zweite/dritte/vierte/Xte Verbindung 
aufzubauen, der XPORT stellt fest das schon eine offen ist und weisst 
die Verbindungsanforderung zurück und dein Brwoser bricht das laden 
aller weiteren Bilder ab da er denkt der Server sei nicht verfügbar.

Autor: Martin M. (martin69)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe die Kommunikatuion zwischen AVR und XPORT auf 115200 Baud 
herunter gesetzt und die Daten aufgezeichnet.

Die Daten mit close mit dem HTML mit mehreren Bildern:
close_gesendet.txt
close_empfangen.txt

Aber ich habe die beiden Dateien nicht bei einer Aktion aufgezeichnet, 
sondern nacheinander. Es kann sein, daß bei den beiden Tests 
unterschiedliche Bilder nicht angezeigt wurden.


Läubi .. wrote:
> Im Header statt
> connection: close
> connection: keep-alive

habe ich gemacht, aber das Ganze wird noch schlimmer. Selbst bei einem 
HTML mit einem einzigen Bild gibt es Probleme. Das Bild wird nicht 
angezeigt.
keep_alive_gesendet.txt
keep_alive_empfangen.txt
=> Es kommt kein GET für das Bild!!!
Mit close wird das Bild problemlos angezeigt.

Und wenn ich eine Seite mit dem Internet-Explorer aufrufe, blockiert der 
mir dauerhaft die Verbindung zum Webserver und mit Deinem testclient.jar 
geht dann nichts mehr....

Das mit der Längenangabe ist kein Problem. Bei den Bildern erhalte ich 
die Info beim Auslesen der SD-Karte. Die HTML´s bastle ich im externen 
RAM zusammen und frage vor dem Senden die Länge mit strlen() ab.

Autor: Martin M. (martin69)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nachtrag:
das mit der genannten Seite mit dem einen Bild geht definitiv nie (Bild 
wird nie angezeigt):
rolladen.jpg
8.244 Bytes

Bei der Startseite ist auch ein Bild drauf. Dieses wird ab und zu mit 
Deinem Mini-Browser angezeigt, manchmal aber nicht:
logo.gif
3.257 Bytes

Eventuell gibt es da auch noch einen Zusammenhang mit der Bildgröße und/ 
oder HTML-Größe. Ich habe mal das rolladen.jpg auf 694 Bytes 
verkleinert. Wird aber trotzdem nicht angezeigt.

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ahang fehlt vermutlich ;)

Autor: Martin M. (martin69)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
sorry. Nun der fehlende Anhang...

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.