+viágosodtam, valaki felkapcsolta a lámpát!
A hiba a következőkben van (az UDP/HTML azért jött elő, mert a kommunikáció mikéntjéről nem volt infó. És tapogatództam egy kicsit a sötétben...):
- A soros küldés/fogadás IRQ-t használ, a Wiznet szintén. Az AVR meg csak 1 szintű IRQ-t ismer, azaz egy rutin nem szakítható meg egy másik kedvéért.
- A buffered valószínű kicsi, ami a soros küldést/fogadást csinálja (config serialin.... ill config serialout...)
- a sorosport esetén nagy sebeséget használsz, és nem bírja feldolgozni az AVR, míga 16 byte (?) UART adóvevő alapbuffere betelik.
Az RTL chipet azért írtam, mert hátha abból kiindulva valami ötlet ellopható. Itt is a vétel/adás INT rutinban zajlik, ami eléggé megfogja a procit. Nálam ami probléma volt:
- A ping utasítással tesztelve, mert ott késleltetési időket lehet látni. Ha a sorosporton 9600 bps-l kommunikáltam (GetSocket, INT jött és egyéb debug üzeletekkel), akkor a válaszidő ARP kérésnél (névfeloldás, címkeresés)~230 msec, míg a pingra válasz ~130-140 msec is volt.
Amint a sorsoport begyorsítva vagy inkább kivéve, ez leesett (kivett eset) ~55-60msec illetve 30 msec köré.
Lehet, hogy nálad a soros kommunikáció fog ennyit rajta.
A bufferelt mód valamennyit javított rajta, legalább adatvesztésem nem volt (a szabad SRAM felét vételire, a felét adásira rakd át).
A sorosport INT alapon is kezelhető, nem kell hozzá a GetKey, Inkey és egyéb függvények. Illetve a vevőpufferben van e valami azt a következő trükkel nézheted meg (időkritikusan)
Ez egy timeoutos dolog, de a timeout részt kihagyod, akkor az IF utasítás lassúságát kivéded.
Kód: Egész kijelölése
.
.
.
.
dim hulp3 as word
dim hulp1 as word
Test:
Incr Hulp3
If Hulp3 = 65000 Then
Incr Hulp1
Hulp3 = 0
End If
If Hulp1 = 25 Then
Goto Noresponse
End If
sbis USR,7
rjmp test
Vettkaraktert:
.
.
.
.
.
.
Noresponse:
.
.
.
.
.
S ami nem világos még:
- sorosporton bináris vagy karakteres adatok mennek? Nem mindegy, ugyanis az elétérés a 0 kódú karakternél van. Ez szövegvége karaktert jelent, ha szövegesen kezeled a bejövő/kimenő adatokat.
Amúgy ami még trükk lehet:
Nálam a RTL modul esetén ~1-2 MHz körül a feldolgozási sebesség nagy timeoutokat (szakadás stb) okozott. A kvarcból érdemes a sorosporti kvarcszabályt betartva (7,3728 ; 14,7456; 11,056 MHz) alkalmazni. Ez is oko(hat) adatvesztést uP-uP kommunikáció során.[/code]
,ötletem nekem is van rengeteg, csak eléggé letöri az ember lelkesedését néha ez a fránya modul. 
Köszönöm a biztatást Róbert. Rendes vagy. 
