 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
Forum Index : Microcontroller and PC projects : Failed attempt at a FTP server.
  Page 3 of 3 |
|||||
| Author | Message | ||||
| lizby Guru  Joined: 17/05/2016 Location: United StatesPosts: 3378 |
Thanks. I had intended to wrap it in an MMBasic/DOS program so I could handshake and confirm that the checksum matched, but I can't figure out how to terminate PLINK from the CMM2 so that it would return to MMBasic. Web searches suggested Ctrl-C, Ctrl-D, ESC, "quit", but none of those work, so I just send BEL (chr$(7)) and terminate in DOS with Ctrl-C, Ctrl-C from the keyboard. I added a few tweaks. The program notes that receipt has begun. I changed the buffer size to 5,200,000 and the LOC() test to LOC(5100000). That allows the file I set up to transmit in two chunks. It's still the case that it takes about 5 times as long to write the file to the SD card as it does to receive it. I also added CTS on pin 37, so that it is asserted when XON is sent, and de-asserted when XOFF is sent. This would allow a piece of hardware which recognized CTS but not XON/XOFF to function. So with a 5+ megabyte buffer and software controlled CTS, how big would a file have to be for hardware CTS to make even a second's worth of difference in the time to transmit and save? Geoff wrote the buffer-sizing function into MMBasic, I think Grogster first clued me into its significance from the programmer's point of view, and Peter Mather did whatever was necessary to make the buffer able to use nearly the full 5+ megabytes of data memory on the CMM2. Thanks to all. Option explicit Dim string xon=Chr$(17),xoff=Chr$(19),ack=Chr$(6),nak=Chr$(21),a$,b$,c$,d$,fn$ Dim integer i%,j%,k%,l%,m%,n%,cksum%,oldloc%,baud%,nChar%,pCTS%=37 dim float t!,ttx!,tmr! baud%=1843200 ' 115200 230400 460800 1843200 'Open "com1:"+Str$(baud)+",2000000" As #1 Open "com1:"+Str$(baud)+",5200000" As #1 fn$="tst.txt" print "Trying to get "+fn$ open "\"+fn$ for output as #2 print #1,fn$+xon; pin(pCTS%)=1 ' clear to send oldloc%=0 cksum%=0 nChar%=0 timer=0 do while loc(#1) = 0 and timer < 10000: loop ' wait 10 seconds for transmission if loc(#1) = 0 then print "File Not Received: "+fn$+"--exiting" print #1,chr$(7); ' tried ^C,^D,ESC,"quit"+chr$(13)+chr$(10); ' EOT pause 1000 end else print "Receiving "+fn$ endif timer=0 t!=0 ttx!=0 tmr!=timer do l%=loc(#1) if l%=0 then ' transmission done if cksum%>0 then ' something received print #1,str$(nChar%)+","+str$(cksum%)+xoff pin(pCTS%)=0 ' not clear to send print " Bytes, checksum: "+str$(nChar%)+","+str$(cksum%)+xoff exit do else pause 2000 ' allow more time for start-up if loc(#1) = 0 then ' nothing received print "File Not Received--exiting" ' exit do print #1,xon; pin(pCTS%)=1 ' clear to send endif endif elseif l%>5100000 or oldloc%=l% then ' this block is done; xoff and write to SD card print #1,xoff; pin(pCTS%)=0 ' not clear to send ttx!=ttx!+(timer-tmr!): print "*"; do while loc(#1) > 0 ' clear all characters from buffer b$=input$(255,#1) j%=Len(b$) For i%=1 To j% c$=Mid$(b$,i%,1) cksum%=cksum%+Asc(c$) nChar%=nChar%+1 Next i% print #2,b$; loop print #1,xon; pin(pCTS%)=1 ' clear to send tmr!=timer endif oldloc%=l% pause 1000 ' wait a second loop t!=timer print #1,chr$(7); ' tried ^C,^D,ESC,"quit"+chr$(13)+chr$(10); ' EOT pause 200 on error skip 1 close #1 on error skip 1 close #2 print nChar%;" Characters; ";t!/1000;" seconds; ";ttx!/1000;" seconds transmitting; checksum: ";cksum% print int(nChar%/(t!/1000));" bytes per second total; ";int(nChar%/(ttx!/1000));" bytes per second (to transmit)" PicoMite, Armmite F4, SensorKits, MMBasic Hardware, Games, etc. on fruitoftheshed |
||||
Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 7938 |
I suspect XON/XOFF is only very inefficient with small buffers. It gets messy if you are sending binary data of course as you need some sort of protocol. Or you can cheat and send them as 9-bit characters if your system will let you. :) Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| lizby Guru Joined: 17/05/2016 Location: United StatesPosts: 3378 |
Perhaps it would be inefficient with small buffers, but why would you use a small buffer on a CMM2 when you have 5 megabytes to play with? No protocol needed for sending binary data to the CMM2--XON and XOFF only go from CMM2 to the sender, and in general only go from receiver to sender, so there's no conflict with the data being sent. PicoMite, Armmite F4, SensorKits, MMBasic Hardware, Games, etc. on fruitoftheshed |
||||
TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 6283 |
Flow control doesn't have to be a handicap. As we have seen, with a large receive buffer, things are not slowed down significantly. The problem is when the other end relies on a small hardware fifo buffer, sometimes as small as 16 bytes and the flow control signals have little hysteresis. The ESP firmware seems to require the handshake line checked every 2 or 3 bytes. That prevents the transmit buffer from getting used hence the very inefficient file sending rates. A buffer of slightly over 1024 bytes would allow many of the YMODEM etc protocols to run at full speed. The default 256 bytes on MMBasic matches the string length nicely and allows standard XMODEM to work as it should. When I started on the FTP exercise, I was expecting the ESP to use a 2048 byte buffer because the data sheet specifies that as the maximum upload packet size. I was wrong. Jim VK7JH MMedit |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 7938 |
Ah... that would be a problem, Jim. I wonder if it would be better to bit-bang on the ESP and use a software defined buffer? Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| Page 3 of 3 |
|||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
