Hi! I think that bit-bang code should use internal buffering which is optimized for bit-bang task, i.e. buffer should be sent not by size consideration but by bit-bang inherent logic as it is already done for sync bit-bang mode of ft232r.
Moreover, from this point of view, bit-bang logic (including buffering) should be separated from and should not depend on transmission/receiving logic. For example, FT232R driver in ft232r_write() has pieces of bit-bang logic and ft232r/libusb transport mixed together -- code that creates a byte in form "combine some fixed value and signal bit mask" and code that puts this byte to output. The same is in remote_bitbang_write(). So, some common part can be implemented as a generic bit-bang code. вт, 4 трав. 2021 о 21:36 Tim Newsome <[email protected]> пише: > On Tue, May 4, 2021 at 12:51 AM Andreas Fritiofson < > [email protected]> wrote: > >> It feels entirely unnecessary to implement a buffering mechanism if the C >> library already has a perfectly good implementation. >> > > Agreed, but apparently it's not standard on Windows. I'm like a fish out > of water in Windows development, but Googling suggests the problem is that > windows sockets just have a different interface than file descriptors, so > you can't use fread/fwrite/fflush on them. > > I think either live with the performance degradation*, or reimplement the >> mentioned change to use socket calls only on windows, via a common wrapper >> and some autotools magic. >> > > It seems less painful to implement the buffering in OpenOCD, and that has > the bonus that the performance improvement will work on Windows, too. I > already did this for the writing, which gets you most of the performance > back: > 1 file changed, 33 insertions(+), 11 deletions(-) > > * the TCP socket should be buffering small writes as well, via the Nagle >> algorithm. Is perhaps TCP_NODELAY set on the socket? >> > > Not AFAICT from reading the source. In my case the socket is to a process > on the same machine, so there may be some implicit flushing going on in the > kernel for that kind of scenario. > > Tim > >> -- wbr, ReAl
