root@buildroot:~# ping -s 88 www.google.com PING www.google.com (184.108.40.206): 88 data bytes 76 bytes from 220.127.116.11: seq=0 ttl=54 time=59.833 ms 76 bytes from 18.104.22.168: seq=1 ttl=54 time=61.755 ms 76 bytes from 22.214.171.124: seq=2 ttl=54 time=58.294 ms ^C --- www.google.com ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max = 58.294/59.960/61.755 ms root@buildroot:~# ping -s 89 www.google.com PING www.google.com (126.96.36.199): 89 data bytes ^C --- www.google.com ping statistics --- 20 packets transmitted, 0 packets received, 100% packet loss
actually strange - google responds with same packet length but still saxon doesn't hear it - maybe after sending longer packet to google, serial port needs a time for "recovery" in order to listen?
Maybe not strange. When sending, if the UART outbound queue is full Linux will wait for it to empty again. When receiving, if the inbound UART queue is full characters get dropped, i.e. packet loss. 88 bytes of payload + 24 bytes of IP & ICMP header is 112 bytes - very close to the 128 buffer size, especially if some bytes need to be escaped into a 2 byte sequence. Have you tried with h/w flow control on the inbound queue?
Another option could be to reduce the mtu/mru to 75 bytes or so. TCP should be able to overcome the packet loss as long as at least some packages get through.
pip install microftp microftpcmd --host 192.168.5.7 --delay 0.3 --block 32 -v -d --user root put ~/wget /root/wget
microftpcmd --host 192.168.4.1 put saxonsoc-ulx3s-85f.bit fpga
NAON#setenv bootargs 'root=/dev/mmcblk0p1 rw console=ttyO0,115200n8 earlyprintk mem=176M vram=46M notifyk.vpssm3_sva=0xBF900000' NAON#saveenv Saving Environment to SPI Flash... Erasing SPI flash...Writing to SPI flash...done NAON#