If you don't mind indulging me, please give the site another try. I've made a temporary change to txTCP to test your idea:
repeat while _size > 0
'wait for room in the W5100 to send some of the data
repeat until (freespace.word[0] [color=red]=> 1024[/color])
readIND((_S0_TX_FSRO + (_socket * $0100)), @temp0, 2)
freespace.byte[1] := temp0.byte[0]
freespace.byte[0] := temp0.byte[1]
chunksize := _size <# freespace.word[0]
Is it a reasonable thing to leave in the code, do you think?
Yes. With a static 2k buffer, I think this works very well. Tim seems to implement support for different buffer sizes, and I believe the optimum would be min(mtu,buffersize) instead of static 1024.
I'm working on a major rewrite of the driver, but each time I work on it, the rewrite just grows larger. I'll try to finish something usable within the week, implementing your buffer hysteresis in it as well.
I've changed the structure of the code, so the Indirect and SPI driver utilizes the same code base, making future driver development much easier and less error prone.
While you're at it, there are a lot of places that have multiplications by a power of two (i.e. xxx * $800). These would be much more efficiently implemented as shifts.
repeat until (freespace.word[0] > tx_mask_S[_socket] >> 1)
It is not the buffer size that is the primary concern, but maximum tcp segment size, as long as it does not exceed the buffer size. With the code above, the W5100 may start sending strange packet sizes, e.g. buffer size of 4096, and the W5100 sends 1500 + 548, 1500 + 548 ... I would prefer to fill one segment and then transmit, there is no idea to demand a larger amount of data than that.
Comments
Buffer hysteresis. I like that.
-Phil
Yes. With a static 2k buffer, I think this works very well. Tim seems to implement support for different buffer sizes, and I believe the optimum would be min(mtu,buffersize) instead of static 1024.
I've changed the structure of the code, so the Indirect and SPI driver utilizes the same code base, making future driver development much easier and less error prone.
-Phil
It is not the buffer size that is the primary concern, but maximum tcp segment size, as long as it does not exceed the buffer size. With the code above, the W5100 may start sending strange packet sizes, e.g. buffer size of 4096, and the W5100 sends 1500 + 548, 1500 + 548 ... I would prefer to fill one segment and then transmit, there is no idea to demand a larger amount of data than that.
-Phil