ist denn uns bekannt, was wir in der Datei verändern müssen?
IP, Submaske, Gateway und Port in Memory schreiben und lesen
Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen
Aufgrund technischer Veränderungen ist der Mailverkehr innerhalb des Forums (Private Nachrichten) nur noch eingeschränkt möglich. Die Einschränkung ist notwendig, um zusätzliche Betriebskosten für das Forum zu vermeiden. Näheres zu den Hintergründen im Thread "Aktuelles zum Forum".Wir bitten um Verständnis.
Hinweis kann nach Kenntnisnahme deaktiviert werden!
-
-
"einfach" ein timeout in die richtige Warteschleife einfügen.
Möglicherweise könnte eine andere Version könnte helfen.
Eins könntest Du noch versuchen:
Dim _TCP_NOWAIT_SEND as Byte
_TCP_NOWAIT_SEND=1 'oder=0??
sie wird abgefragt und ändert dann die vorgehensweise. Mein Assembler ist schwach das verständniss der .OBJ quasi nicht vorhanden.
Mir fehlt auch der Einstiegspunkt: Was passiert zwischen dem Bascom Befehl SETTCP und der LBX Routine _SENDTCP(_LINE ???) -
Du solltest jetzt mal ein Bascom Programm zeigen, bei welchem der Fehler nachvollziehbar ist. ( nicht ein paar Zeilen Code, sondern ein komplettes Programm!)
Kopiere dir das DHCP Sample Programm von MCS, ändere CPU und Hardware nach deinen Erfordernissen.
Tritt der Fehler dabei auf, dann hänge den Quelltext in deinem Thread bei MCS an und beschreibe, wo das Programm stehen bleibt.
Mark wird das schon wahrnehmen und sich drum kümmern.Code first, think later - Natural programmer -
katipefendi schrieb:
Wenn ich es normal laufen lasse d.h. OHNE DHCP, sondern Statische IP, dann funktioniert es und ich habe ein anderes Bild am Cs Port
und wenn ich in Dynamischen IP sprich DHCP Funktion aufrufe, dann sieht mein Bild plötzlich ganz anders aus
DS1Z_QuickPrint6.png
Die Funktion DHCP verwendet ja den UDP und ich denke da wird der Fehler sein. Denn ganz oben wird ja nur der TCP verwendet.
Ich hab' das Zitat etwas vermurkst, tut mir leidRaum für Notizen
-----------------------------------------------------------------------------------------------------
-----------------------------------------------------------------------------------------------------Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von tschoeatsch ()
-
Er macht ja auch mit der Rechenzeit fast nichts anderes als die Sokets abzufragen und während des settcp gar nichts anderes als auf eine "Freigabe" zu warten.
Läßt er sich Pingen wenn er hängt ? Wenn ja mit der neuen oder der alten IP?
Machte das _TCP_NOWAIT_SEND einen Unterschied? -
Pluto25 schrieb:
Läßt er sich Pingen wenn er hängt ?
Pluto25 schrieb:
Machte das _TCP_NOWAIT_SEND einen Unterschied?
-
@katipefendi hast du mal den Vorschlag von @six1 probiert?
Auch wenn du wenig Zeit hast (wie wir alle hier) solltest du mal selber etwas testen.
Einen fertigen Code wirst du hier bestimmt nicht bekommen, auch wenn es manchmal bei einfachen Sachen so ist.
Auch die Profis unter uns (dazu zähle ich mich nun absolut nicht) haben nicht immer eine Lösung parat.
Viele Dinge muss man dann halt selbst in die Hand nehmenEine Lösung habe ich nicht, aber mir gefällt Ihr Problem. -
djmsc schrieb:
hast du mal den Vorschlag von @six1 probiert?Ja
-
"ich konnte damit nichts anfangen sorry"
Ja Du sollst ja auch nichts damit anfangen sondern Dein Wiz . Ich weiß auch nicht was sie tut; nicht mal ob es ein Bit oder ein Byte ist.
Ich hab nur herrausgefunden, dass sie abgefragt wird. Keine Ahnung ob's hilft. Aber als Versuch ist es einfach: Irgendwo weit oben (bei den anderen Dim's ) Dim _TCP_NOWAIT_SEND as Byte (oder Bit) hinschreiben und vor dem Settcp: _TCP_NOWAIT_SEND=1(oder 0). Mit etwas Glück sorgt sie dafür das er nicht mehr bis in alle Ewigkeit auf irgend etwas wartet und damit das Ganze blockiert.
Dann ist mir ein Lösungsansatz für Deine "Holzhammermethode" eingefallen: Vor dem Settcp einen Timer starten der nach 100ms? einen Interrupt auslöst, dessen Routine dann den Cs auf High zwingt. -
Pluto25 schrieb:
Dann ist mir ein Lösungsansatz für Deine "Holzhammermethode" eingefallen: Vor dem Settcp einen Timer starten der nach 100ms? einen Interrupt auslöst, dessen Routine dann den Cs auf High zwingt.
Raum für Notizen
-----------------------------------------------------------------------------------------------------
----------------------------------------------------------------------------------------------------- -
Pluto25 schrieb:
Dann ist mir ein Lösungsansatz für Deine "Holzhammermethode" eingefallen: Vor dem Settcp einen Timer starten der nach 100ms? einen Interrupt auslöst, dessen Routine dann den Cs auf High zwingt.
-
tschoeatsch schrieb:
Und auch in der isr bisschen wartet (ausnahmsweise).
-
Passt doch. Starte den timer, in der isr dazu zählst du eine Variable hoch, wird nach x isr-Aufrufen mit dieser Variablen der Wert x erreicht, dann in der isr Cs=1:wait 1: disable timer0: return
Der Wert für x richtet sich nach der Wartezeit, die du verstreichen lassen willst, bis am Cs gefummelt wird und natürlich nach der Überlaufzeit von timer0.Raum für Notizen
-----------------------------------------------------------------------------------------------------
----------------------------------------------------------------------------------------------------- -
sobald Start Timer0 kommt, dann spring es in die Routine, bevor SETTCP erreicht wird
BASCOM-Quellcode
geht auch nicht -
Na dann noch ne Potion härter: Vom Pin B.4 150 Ohm zu einem bisher freien Pin (ich nenn ihn mal a.3) und von da aus zum Cs.
Im Programm
config Porta.3 as input
reset porta.3 'Damit der Pullub nicht stört
In der Isr (dann wenn genug Zeit vergangen ist)
DDRA = DDRA or 8 ' a.3 wird Ausgang
set porta.3 ' Damit der Cs die 3,3V bekommt die er auch dann hat wenn Du ihn in der Hand hast
Nach dem settcp
DDRA = DDRA and $F7 ' a.3 wird wieder Eingang damit wieder mit dem Wiz kommuniziert werden kann
reset porta.3 ' Damit der Pullub nicht stört
PS wie lange braucht die set tcp im Normalfall (also wenn sie funktioniert)? vielleicht mal ein Print timer1 davor und danach ausgeben lassen. Timer0 prescale 1024 braucht ca 16ms bis zum Überlauf vielleicht reicht das.
Mehrfach aus ihr herrausspringen (mit der isr) halte ich für bedenklich.
Ein I2C verträgt das ganz schlecht wie das mit dem SPI ist weiß ich nicht. -
six1 schrieb:
Du solltest jetzt mal ein Bascom Programm zeigen, bei welchem der Fehler nachvollziehbar ist. ( nicht ein paar Zeilen Code, sondern ein komplettes Programm!)
Kopiere dir das DHCP Sample Programm von MCS, ändere CPU und Hardware nach deinen Erfordernissen.
Tritt der Fehler dabei auf, dann hänge den Quelltext in deinem Thread bei MCS an und beschreibe, wo das Programm stehen bleibt.
Mark wird das schon wahrnehmen und sich drum kümmern.
-
schau mal bitte hier:
mcselec.com/index2.php?option=…59&page=viewtopic&t=14204Code first, think later - Natural programmer -
Mark hat den Fehler gefunden und eine Lösung veröffentlicht.
mcselec.com/index2.php?option=…e=viewtopic&p=76505#76505Code first, think later - Natural programmer -
Super, jetzt klappt es endlich.
Vielen Dank an alle, die mir geholfen haben.