Thread: [Flashforth-devel] FF 5.x - Xon Xoff with Teraterm
Brought to you by:
oh2aun
Menu
▾
▴
flashforth-devel
|
From: om1zz <om...@vo...> - 2015-05-18 10:23:44
|
Hi, I've been using Teraterm and Ca-42 dongle under XP.
I set TX, RX buffer to 511, and RX OFF FILL to 128.
dspic33fj at 40MHz Fcy, latest FF.
Running 115k2, 8N1, Xon/Xoff is set in the serial settings.
When uploading a code (ie float.txt) it uploads ~520 lines fines and then
abs 1- emitnzeros \ print n-steps - 1 leading zeros 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
Is there any experience how to set the stuff such it works withou a need for character and line delays (which when set to 1ms and 100ms works fine), plz?
I.
|
|
From: om1zz <om...@vo...> - 2015-05-18 10:35:24
|
The issue below has been with copy/paste into the terminal window. When uploading the file with Send File I get after ~13 lines: ok<#,ram> -fpmath |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||... I. >Hi, I've been using Teraterm and Ca-42 dongle under XP. >I set TX, RX buffer to 511, and RX OFF FILL to 128. >dspic33fj at 40MHz Fcy, latest FF. > >Running 115k2, 8N1, Xon/Xoff is set in the serial settings. >When uploading a code (ie float.txt) it uploads ~520 lines fines and then > > abs 1- emitnzeros \ print n-steps - 1 leading zeros 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 > >Is there any experience how to set the stuff such it works withou a need for character and line delays (which when set to 1ms and 100ms works fine), plz? >I. > |
|
From: Peter J. <pe...@me...> - 2015-05-18 11:08:52
|
When building the Tcl/Tk version of ff-shell, I found that I needed a 1ms pause between characters, else I would occasionally experience buffer over-runs on a PIC24. Both the Python and Tcl versions of ff-shell wait for the microcontroller to return a carriage-return before sending subsequent lines when sending a file. It's more certain than an end-of line delay that you mention below (and it's quicker, mostly). Could you try ff-shell.tcl to see if it behaves well? Regards, Peter J. On 18/05/15 20:35, om1zz wrote: > The issue below has been with copy/paste into the terminal window. > When uploading the file with Send File I get after ~13 lines: > ok<#,ram> > -fpmath |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||... > I. > > >> Hi, I've been using Teraterm and Ca-42 dongle under XP. >> I set TX, RX buffer to 511, and RX OFF FILL to 128. >> dspic33fj at 40MHz Fcy, latest FF. >> >> Running 115k2, 8N1, Xon/Xoff is set in the serial settings. >> When uploading a code (ie float.txt) it uploads ~520 lines fines and then >> >> abs 1- emitnzeros \ print n-steps - 1 leading zeros 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 >> >> Is there any experience how to set the stuff such it works withou a need for character and line delays (which when set to 1ms and 100ms works fine), plz? >> I. >> > ------------------------------------------------------------------------------ > One dashboard for servers and applications across Physical-Virtual-Cloud > Widest out-of-the-box monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable Insights > Deep dive visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > _______________________________________________ > Flashforth-devel mailing list > Fla...@li... > https://lists.sourceforge.net/lists/listinfo/flashforth-devel |
|
From: Mikael N. <mik...@fl...> - 2015-05-18 12:21:32
|
I am using the ff-shell.py from the ff distribution. It is the only program I found to work reliably with USB-to-Serial converters. Use the #send filepath/filename command to send a file to ff reliably without any delays. The #send command waits for a newline from the PIC before sending the next line. In addition I have XON/XOFF configured. I have not tried it under windows but I think it should be possible to run Python programs in Windows. The Python pyserial lib is required. Another option that usually works with any terminal program is to use CTS/RTS HW flow control. You have to wire a pin for the CTS signal to USB-Serial converter for this. The problem with most converters is that they do not support XON/XOFF well because they have so large buffers that the XOFF is not transfered until it is too late. BR Mike |
|
From: om1zz <om...@vo...> - 2015-05-18 13:04:05
|
Peter, Mikael, thanks for the info! I've tried the python ff-shell under XP with no luck (it throws some errors). There is a small editor/loader called Forfiter, I used to use in past. You can set cr/nl delay to, for example, 1000ms, and any upcoming 'ok' will bypass that delay then. The Forfiter works fine with amforth, but with FF there is an issue - the FF does not return 'ok' after each line when it receives lines (amforth does). So with single liners it works nice (it receives 'ok' and goes immediately to the next line), but with comments and words defs over many lines it simply waits 1000ms at each line until the final 'ok' arrives. Would it be possible to print 'ok' after each line received in FF?? I. |
|
From: Mikael N. <mik...@fl...> - 2015-05-18 14:55:49
|
I considered to print OK after every line but then I did not want to change the old behaviour. So I made the ff-shell to just wait for newlines. The approach with Amforth would not work with FF anyway. Thats because the block write to flash may occur in the middle of a word. In contrast Amforth does not have any such block write. I think it writes each cell separately to flash, thus always having a constant delay. But you can try to modify QUIT to print OK after every line. BR Mike On 18.05.2015 16:03, om1zz wrote: > Peter, Mikael, thanks for the info! > I've tried the python ff-shell under XP with no luck (it throws some errors). > > There is a small editor/loader called Forfiter, I used to use in past. > You can set cr/nl delay to, for example, 1000ms, and any upcoming 'ok' will bypass that delay then. > The Forfiter works fine with amforth, but with FF there is an issue - the FF does not return 'ok' after each line when it receives lines (amforth does). > So with single liners it works nice (it receives 'ok' and goes immediately to the next line), but with comments and words defs over many lines it simply waits 1000ms at each line until the final 'ok' arrives. > Would it be possible to print 'ok' after each line received in FF?? > I. |
|
From: om1zz <om...@vo...> - 2015-05-18 15:07:19
|
Mike, the flashing behaviour will not change in FF. By sending ok with each line you just provide a syncing with terminal. Now you may have 300lines of comments without any ok (any sync), or a word def 300 lines long also without any sync thus the overruns occur. Igor. ______________________________________________________________ > Od: Mikael Nordman <mik...@fl...> > Komu: <fla...@li...> > Datum: 18.05.2015 16:56 > Předmět: Re: [Flashforth-devel] FF 5.x - Xon Xoff with Teraterm > >I considered to print OK after every line but then I did not want to >change the old behaviour. So I made the ff-shell to just wait for newlines. > >The approach with Amforth would not work with FF anyway. >Thats because the block write to flash may occur in the middle of a word. >In contrast Amforth does not have any such block write. I think it >writes each cell separately to flash, thus always having a constant delay. > >But you can try to modify QUIT to print OK after every line. > >BR Mike > >On 18.05.2015 16:03, om1zz wrote: >> Peter, Mikael, thanks for the info! >> I've tried the python ff-shell under XP with no luck (it throws some errors). >> >> There is a small editor/loader called Forfiter, I used to use in past. >> You can set cr/nl delay to, for example, 1000ms, and any upcoming 'ok' will bypass that delay then. >> The Forfiter works fine with amforth, but with FF there is an issue - the FF does not return 'ok' after each line when it receives lines (amforth does). >> So with single liners it works nice (it receives 'ok' and goes immediately to the next line), but with comments and words defs over many lines it simply waits 1000ms at each line until the final 'ok' arrives. >> Would it be possible to print 'ok' after each line received in FF?? >> I. > >------------------------------------------------------------------------------ >One dashboard for servers and applications across Physical-Virtual-Cloud >Widest out-of-the-box monitoring support with 50+ applications >Performance metrics, stats and reports that give you Actionable Insights >Deep dive visibility with transaction tracing using APM Insight. >http://ad.doubleclick.net/ddm/clk/290420510;117567292;y >_______________________________________________ >Flashforth-devel mailing list >Fla...@li... >https://lists.sourceforge.net/lists/listinfo/flashforth-devel > |
|
From: om1zz <om...@vo...> - 2015-05-18 15:28:58
|
The idea: to send "ok' from FF when \r\n arrived AND rx_buffer is empty AND there is no flashing or other background task running AND ... So the actual delay with sending ok after \r\n receive is managed by FF.. I. ______________________________________________________________ > Od: "om1zz" <om...@vo...> > Komu: Mikael Nordman <mik...@fl...>, <fla...@li...> > Datum: 18.05.2015 17:07 > Předmět: Re: [Flashforth-devel] FF 5.x - Xon Xoff with Teraterm > >Mike, the flashing behaviour will not change in FF. >By sending ok with each line you just provide a syncing with terminal. >Now you may have 300lines of comments without any ok (any sync), or a word def 300 lines long also without any sync thus the overruns occur. >Igor. > > > >______________________________________________________________ >> Od: Mikael Nordman <mik...@fl...> >> Komu: <fla...@li...> >> Datum: 18.05.2015 16:56 >> Předmět: Re: [Flashforth-devel] FF 5.x - Xon Xoff with Teraterm >> >>I considered to print OK after every line but then I did not want to >>change the old behaviour. So I made the ff-shell to just wait for newlines. >> >>The approach with Amforth would not work with FF anyway. >>Thats because the block write to flash may occur in the middle of a word. >>In contrast Amforth does not have any such block write. I think it >>writes each cell separately to flash, thus always having a constant delay. >> >>But you can try to modify QUIT to print OK after every line. >> >>BR Mike >> >>On 18.05.2015 16:03, om1zz wrote: >>> Peter, Mikael, thanks for the info! >>> I've tried the python ff-shell under XP with no luck (it throws some errors). >>> >>> There is a small editor/loader called Forfiter, I used to use in past. >>> You can set cr/nl delay to, for example, 1000ms, and any upcoming 'ok' will bypass that delay then. >>> The Forfiter works fine with amforth, but with FF there is an issue - the FF does not return 'ok' after each line when it receives lines (amforth does). >>> So with single liners it works nice (it receives 'ok' and goes immediately to the next line), but with comments and words defs over many lines it simply waits 1000ms at each line until the final 'ok' arrives. >>> Would it be possible to print 'ok' after each line received in FF?? >>> I. >> >>------------------------------------------------------------------------------ >>One dashboard for servers and applications across Physical-Virtual-Cloud >>Widest out-of-the-box monitoring support with 50+ applications >>Performance metrics, stats and reports that give you Actionable Insights >>Deep dive visibility with transaction tracing using APM Insight. >>http://ad.doubleclick.net/ddm/clk/290420510;117567292;y >>_______________________________________________ >>Flashforth-devel mailing list >>Fla...@li... >>https://lists.sourceforge.net/lists/listinfo/flashforth-devel >> > |
|
From: om1zz <om...@vo...> - 2015-05-18 18:52:20
|
This is a quick hack for TerTerm - Upload to FF, while waiting on OK (sync) and interrupting the upload when FF sends ?? (currently only ?). The serial settings comes from the active TT session.
Tried at 921k, it works, but not fully tested, as I do not have OK at end of each line from FF, so it waits 500ms and continues.
With OK it will immediately follow with the next line.
The FF decides when it sends the OK upon receive of the line - that establishes the syncing with Terminal.
During a normal TT session click on Control>Macro, select this Macro (save below source to ie. file "FFupload.ttl"), select file to upload and select if you want to skip empty lines.
; TeraTerm Macro Script for FlashForth Upload
; Serial is set within the active TT session
; Opens a file, reads each line, and sends the line to FF
; while waiting on "OK" or "??" after the \r\n sent
; IgorM 5/2015
:Main
Yes = 1 ; for YesNoBox result
No = 0 ; for YesNoBox result
BlankLine = 0
call OpenFile
call ReadFile
call CloseFile
END
:OpenFile
FileNameBox 'Choose the file to upload'
FileChosen = result
if FileChosen = Yes then
FileOpen fhandle inputstr 0
else
end
endif
RETURN
:ReadFile
YesNoBox 'Do you want to skip blank lines?' 'Skip blanks?'
SkipBlanks = result
while 1
; Read a line from the file..
filereadln fhandle line
EndOfFile = result
if EndOfFile = Yes then
break
endif
StrLen line
LineLen = result
if SkipBlanks = Yes then
if LineLen = BlankLine then
continue
endif
endif
sendln line
timeout = 0 ; 0 secs
mtimeout = 300 ; 300msecs
wait "OK" "??" ; wait on OK or error
;if result = 0 break ; timeout, currently it simply timeouts
;if result = 1 goto ok ; OK detected - sync
if result = 2 break ; exit if ?? from FF
; Repeat until the end of the file.
endwhile
RETURN
:CloseFile
FileClose fhandle
RETURN
;-----------------------------------------------------------
I.
|
|
From: Mikael N. <mik...@fl...> - 2015-05-18 20:41:39
|
You could try using waitln "" to wait for the newline instead of OK BR Mike On 18.05.2015 21:52, om1zz wrote: > This is a quick hack for TerTerm - Upload to FF, while waiting on OK > (sync) and interrupting the upload when FF sends ?? (currently only > ?). The serial settings comes from the active TT session. > Tried at 921k, it works, but not fully tested, as I do not have OK at > end of each line from FF, so it waits 500ms and continues. > With OK it will immediately follow with the next line. > The FF decides when it sends the OK upon receive of the line - that > establishes the syncing with Terminal. > During a normal TT session click on Control>Macro, select this Macro > (save below source to ie. file "FFupload.ttl"), select file to upload > and select if you want to skip empty lines. > > > ; TeraTerm Macro Script for FlashForth Upload > ; Serial is set within the active TT session > ; Opens a file, reads each line, and sends the line to FF > ; while waiting on "OK" or "??" after the \r\n sent > ; IgorM 5/2015 > > :Main > Yes = 1 ; for YesNoBox result > No = 0 ; for YesNoBox result > BlankLine = 0 > call OpenFile > call ReadFile > call CloseFile > END > > :OpenFile > FileNameBox 'Choose the file to upload' > FileChosen = result > if FileChosen = Yes then > FileOpen fhandle inputstr 0 > else > end > endif > RETURN > > :ReadFile > YesNoBox 'Do you want to skip blank lines?' 'Skip blanks?' > SkipBlanks = result > > while 1 > > ; Read a line from the file.. > > filereadln fhandle line > EndOfFile = result > > if EndOfFile = Yes then > break > endif > > StrLen line > LineLen = result > > if SkipBlanks = Yes then > if LineLen = BlankLine then > continue > endif > endif > > sendln line > > timeout = 0 ; 0 secs > mtimeout = 300 ; 300msecs > wait "OK" "??" ; wait on OK or error > ;if result = 0 break ; timeout, currently it simply timeouts > ;if result = 1 goto ok ; OK detected - sync > if result = 2 break ; exit if ?? from FF > > ; Repeat until the end of the file. > > endwhile > RETURN > > :CloseFile > FileClose fhandle > RETURN > ;----------------------------------------------------------- > > I. > > > ------------------------------------------------------------------------------ > One dashboard for servers and applications across > Physical-Virtual-Cloud > Widest out-of-the-box monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable > Insights > Deep dive visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > _______________________________________________ > Flashforth-devel mailing list > Fla...@li... > https://lists.sourceforge.net/lists/listinfo/flashforth-devel |
|
From: om1zz <om...@vo...> - 2015-05-18 20:57:32
|
Does the FF send a new line when ready to receive an another line? ______________________________________________________________ > Od: Mikael Nordman <mik...@fl...> > Komu: <fla...@li...> > Datum: 18.05.2015 22:42 > Předmět: Re: [Flashforth-devel] TeraTerm Macro for Upload to FF > >You could try using > > waitln "" > >to wait for the newline instead of OK > >BR Mike > > >On 18.05.2015 21:52, om1zz wrote: >> This is a quick hack for TerTerm - Upload to FF, while waiting on OK >> (sync) and interrupting the upload when FF sends ?? (currently only >> ?). The serial settings comes from the active TT session. >> Tried at 921k, it works, but not fully tested, as I do not have OK at >> end of each line from FF, so it waits 500ms and continues. >> With OK it will immediately follow with the next line. >> The FF decides when it sends the OK upon receive of the line - that >> establishes the syncing with Terminal. >> During a normal TT session click on Control>Macro, select this Macro >> (save below source to ie. file "FFupload.ttl"), select file to upload >> and select if you want to skip empty lines. >> >> >> ; TeraTerm Macro Script for FlashForth Upload >> ; Serial is set within the active TT session >> ; Opens a file, reads each line, and sends the line to FF >> ; while waiting on "OK" or "??" after the \r\n sent >> ; IgorM 5/2015 >> >> :Main >> Yes = 1 ; for YesNoBox result >> No = 0 ; for YesNoBox result >> BlankLine = 0 >> call OpenFile >> call ReadFile >> call CloseFile >> END >> >> :OpenFile >> FileNameBox 'Choose the file to upload' >> FileChosen = result >> if FileChosen = Yes then >> FileOpen fhandle inputstr 0 >> else >> end >> endif >> RETURN >> >> :ReadFile >> YesNoBox 'Do you want to skip blank lines?' 'Skip blanks?' >> SkipBlanks = result >> >> while 1 >> >> ; Read a line from the file.. >> >> filereadln fhandle line >> EndOfFile = result >> >> if EndOfFile = Yes then >> break >> endif >> >> StrLen line >> LineLen = result >> >> if SkipBlanks = Yes then >> if LineLen = BlankLine then >> continue >> endif >> endif >> >> sendln line >> >> timeout = 0 ; 0 secs >> mtimeout = 300 ; 300msecs >> wait "OK" "??" ; wait on OK or error >> ;if result = 0 break ; timeout, currently it simply timeouts >> ;if result = 1 goto ok ; OK detected - sync >> if result = 2 break ; exit if ?? from FF >> >> ; Repeat until the end of the file. >> >> endwhile >> RETURN >> >> :CloseFile >> FileClose fhandle >> RETURN >> ;----------------------------------------------------------- >> >> I. >> >> >> ------------------------------------------------------------------------------ >> One dashboard for servers and applications across >> Physical-Virtual-Cloud >> Widest out-of-the-box monitoring support with 50+ applications >> Performance metrics, stats and reports that give you Actionable >> Insights >> Deep dive visibility with transaction tracing using APM Insight. >> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y >> _______________________________________________ >> Flashforth-devel mailing list >> Fla...@li... >> https://lists.sourceforge.net/lists/listinfo/flashforth-devel > > >------------------------------------------------------------------------------ >One dashboard for servers and applications across Physical-Virtual-Cloud >Widest out-of-the-box monitoring support with 50+ applications >Performance metrics, stats and reports that give you Actionable Insights >Deep dive visibility with transaction tracing using APM Insight. >http://ad.doubleclick.net/ddm/clk/290420510;117567292;y >_______________________________________________ >Flashforth-devel mailing list >Fla...@li... >https://lists.sourceforge.net/lists/listinfo/flashforth-devel > |
|
From: Mikael N. <mik...@fl...> - 2015-05-19 03:58:42
|
Yes. On 18.05.2015 23:57, om1zz wrote: > Does the FF send a new line when ready to receive an another line? |
|
From: om1zz <om...@vo...> - 2015-05-19 06:07:48
|
Great!!! With wait #13 ?? it waits on a newline coming from FF after each line of code FF has processed as well as an error message, if any (I modded ? to ??). The float.txt uploads in 14 seconds with no error (921k6, dspic33, 40MHz Fcy, serial usb CA-42 clone). :) The script needs some finetunig, as the upload now stops at each error which may not be an error.. :) IM. ______________________________________________________________ > Od: Mikael Nordman <mik...@fl...> > Komu: <fla...@li...> > Datum: 19.05.2015 05:59 > Předmět: Re: [Flashforth-devel] TeraTerm Macro for Upload to FF > >Yes. > >On 18.05.2015 23:57, om1zz wrote: >> Does the FF send a new line when ready to receive an another line? > > >------------------------------------------------------------------------------ >One dashboard for servers and applications across Physical-Virtual-Cloud >Widest out-of-the-box monitoring support with 50+ applications >Performance metrics, stats and reports that give you Actionable Insights >Deep dive visibility with transaction tracing using APM Insight. >http://ad.doubleclick.net/ddm/clk/290420510;117567292;y >_______________________________________________ >Flashforth-devel mailing list >Fla...@li... >https://lists.sourceforge.net/lists/listinfo/flashforth-devel > |
|
From: om1zz <om...@vo...> - 2015-05-19 08:23:23
|
This is v0.2 of the script, it removes blank lines and comments if required, stops and asks on ?? error. You have to mod the ? to ?? in the asm. Uploads the 665 lines long float.txt in 8 seconds (921k, pic33, Fcy 40MHz) fine ;) Still beta, no warranties of any kind :) ; TeraTerm Macro Script fro FlashForth ; Serial set within TT session ; Opens a file, reads each line, and sends the line to FF ; while waiting on "OK" or "??" after the \r\n sent ; IgorM c 5/2015 ; v.0.2 :Main Yes = 1 ; for YesNoBox result No = 0 ; for YesNoBox result BlankLine = 0 call OpenFile call ReadFile call CloseFile END :OpenFile FileNameBox 'Choose a file to upload' FileChosen = result if FileChosen = Yes then FileOpen fhandle inputstr 0 else end endif RETURN :ReadFile YesNoBox 'Do you want to skip blank lines and comments?' 'Skip?' SkipBlanks = result while 1 ; Read a line from the file.. filereadln fhandle line EndOfFile = result if EndOfFile = Yes break StrLen line LineLen = result if SkipBlanks = Yes then if LineLen = BlankLine continue strscan line '\' if result = 1 continue if result > 1 then strremove line result LineLen-result+1 endif endif sendln line timeout = 1 ; 1 sec wait #13 "??" ; wait on OK(\n) or an Error ?? if result = 0 break ; timeout ;if result = 1 goto _ok ; OK detected if result = 2 then ; exit if ?? Error from FF YesNoBox 'Error - Do you want proceed w/ Upload?' 'Continue?' if result = No break endif ; Repeat until the end of the file.. endwhile RETURN :CloseFile FileClose fhandle RETURN ;----------------------------------------------------------- ______________________________________________________________ > Od: om1zz <om...@vo...> > Komu: Mikael Nordman <mik...@fl...>, <fla...@li...> > Datum: 19.05.2015 08:08 > Předmět: Re: [Flashforth-devel] TeraTerm Macro for Upload to FF > >Great!!! > >With > >wait #13 ?? > >it waits on a newline coming from FF after each line of code FF has processed as well as an error message, if any (I modded ? to ??). > >The float.txt uploads in 14 seconds with no error (921k6, dspic33, 40MHz Fcy, serial usb CA-42 clone). >:) > >The script needs some finetunig, as the upload now stops at each error which may not be an error.. :) > >IM. > >______________________________________________________________ >> Od: Mikael Nordman <mik...@fl...> >> Komu: <fla...@li...> >> Datum: 19.05.2015 05:59 >> Předmět: Re: [Flashforth-devel] TeraTerm Macro for Upload to FF >> >>Yes. >> >>On 18.05.2015 23:57, om1zz wrote: >>> Does the FF send a new line when ready to receive an another line? >> >> >>------------------------------------------------------------------------------ >>One dashboard for servers and applications across Physical-Virtual-Cloud >>Widest out-of-the-box monitoring support with 50+ applications >>Performance metrics, stats and reports that give you Actionable Insights >>Deep dive visibility with transaction tracing using APM Insight. >>http://ad.doubleclick.net/ddm/clk/290420510;117567292;y >>_______________________________________________ >>Flashforth-devel mailing list >>Fla...@li... >>https://lists.sourceforge.net/lists/listinfo/flashforth-devel >> > >------------------------------------------------------------------------------ >One dashboard for servers and applications across Physical-Virtual-Cloud >Widest out-of-the-box monitoring support with 50+ applications >Performance metrics, stats and reports that give you Actionable Insights >Deep dive visibility with transaction tracing using APM Insight. >http://ad.doubleclick.net/ddm/clk/290420510;117567292;y >_______________________________________________ >Flashforth-devel mailing list >Fla...@li... >https://lists.sourceforge.net/lists/listinfo/flashforth-devel > |
|
From: Mike M. <mi...@mo...> - 2015-05-19 19:59:07
|
I have been casually following the thread about TeraTerm.
I use TeraTerm on Windows, CoolTerm on OSX.
I have been using hardware handshake, with NO delay. I use a
USB-to-serial adapter using the FTDI chipset, which seems to get the
handshake right.
I has been a couple of years since I wrote these, so I hope I am
including all of the changes.
To do this, I have modified the UART driver. I use UART #2, FC_TYPE=2
I also have FC_TYPE=0 defined using the PIC's handshake control, but
that does not work very well.
I am using FF 4.8 on the PIC24FJ256GB110, so I map I/O pins:
<snip> in config file:
;;; UART2 configuration
;.equ BAUDRATE2, 38400 ; Serial baudrate UART2,
comment if not used
.equ BAUDRATE2, 115200 ; Serial baudrate UART2,
comment if not used
.equ FC2_TYPE, 2 ; ; 0 = UART CTS/RTS, 1 =
XON/XOFF, 2=(CTS)/RTS software
.equ AUTOBAUD2, 0 ; 0 = to use fixed baudrate
; 1 = Autobaud, First char
after reset must be 'U' (0x55)
;;; UART2 Peripheral pin mapping
.ifdecl RPINR19
.equ U2TXPIN, 17 ; RP17 pin 50
;.equ U2RXPIN, 10 ; RP10 PIN 49
.if FC2_TYPE == 0 ; UART controls RTS, CTS
.equ RPINR19VAL, 0x200a ; msb: U2CTS RP32, lsb: U2RXPIN RP10
.equ U2RTSPIN, 31 ; RP31 (RF13) pin 39 output
.else ; we control RTS, CTS
.equ RPINR19VAL, 0xff0a ; msb: (U2CTS RP32), lsb: U2RXPIN RP10
; we are controlling RTS, CTS
.equ U2RTSPORT, LATF
.equ U2RTSTRIS, TRISF
.equ U2RTSPIN, 13 ;RF13 (RF31) pin 39 output
.equ U2CTSPIN, 12 ;RF12 (RPI32) pin 40 input (not
implemented)
.endif
.endif
<snip> in FF.s:
.ifdecl BAUDRATE2 ; UART2
.ifdecl _U2RXREG
__U2RXInterrupt:
push.s
.ifdef CMAIN
lnk #ISTKSIZ
.endif ; CMAIN
.ifdef PEEPROM
push TBLPAG
.endif
inc2 W14, W14
__U2RXInterrupt0:
bclr IFS1, #U2RXIF
bset iflags, #istream ; Indicate UART activity.
mlit handle(U2RXQUEUE_DATA)+PFLASH
rcall CQUEUE_TOQ ; Space available ? false =
queue is full
cp0 [W14--]
bra z, U2RX_ERR1
bclr U2STA, #OERR
mov U2RXREG, W0 ; get chr
.if (CTRL_O_WARM_RESET == 1); Console only
cp W0, #15
bra z, RESET_FF_1
.endif
.if FC2_TYPE == 1
btsc iflags, #fFC2
bra U2_SKIP_FC_1
cp W0, #XOFF
bra z, __U2RXInterrupt3
.endif
U2_SKIP_FC_1:
mov W0, [++W14]
mlit handle(U2RXQUEUE_DATA)+PFLASH
rcall CQUEUE_TO ; Put to character queue
btsc iflags, #fFC2
bra U2_SKIP_FC_2
.if FC2_TYPE == 1
mov rbuf_wr2, W0
and W0, #0xf, W0
bra nz, __U2RXInterrupt3
__U2RXInterrupt2:
btsc U2STA, #UTXBF ; buffer full?
bra __U2RXInterrupt2
mov #XOFF, W0
mov W0, U2TXREG ; send chr
bset iflags, #ixoff2
.else
.if FC2_TYPE == 2
mov #RX2_OFF_FILL, W0
cp rbuf_lv2
bra n, __U2RXInterrupt3
bset U2RTSPORT, #U2RTSPIN ; RTS low
.endif
.endif
U2_SKIP_FC_2:
__U2RXInterrupt3:
btsc U2STA, #URXDA ; bit #0, data available
bra __U2RXInterrupt0
__U2RXTXIRQ_END:
bra __U1RXTXIRQ_END
U2RX_ERR1:
btss U2STA, #TRMT
bra U2RX_ERR1
mov U2RXREG, W0
mov #'|', W0
mov W0, U2TXREG ; send
bra __U2RXInterrupt3
__U2TXInterrupt:
push.s
.ifdef CMAIN
lnk #ISTKSIZ
.endif ; CMAIN
.ifdef PEEPROM
push TBLPAG
.endif
add W14, #2, W14
bclr IFS1, #U2TXIF ; clear interrupt flag
__U2TXInterrupt0:
btsc U2STA, #UTXBF ; uart buffer full?
bra __U2TXInterrupt3 ; buffer full
mlit handle(U2TXQUEUE_DATA)+PFLASH ; yes buffer ready
rcall CQUEUE_FROMQ ; Character available ?
false = no
cp0 [W14--]
bra z, __U2TXInterrupt3 ; queue empty
mlit handle(U2TXQUEUE_DATA)+PFLASH
rcall CQUEUE_FROM ; Get from character
queue
mov [W14--], W0
mov W0, U2TXREG ; Send chr
__U2TXInterrupt3:
bra __U1RXTXIRQ_END
.endif
.endif
<snip>
wait_silence:
rcall LOCKED
.if FC2_TYPE == 1
btsc U2STA, #UTXBF ; buffer full?
bra wait_silence
mov #XOFF, W2
mov W2, U2TXREG ; send chr
bset iflags, #ixoff2
.else
.if FC2_TYPE == 2
bset U2RTSPORT, #U2RTSPIN ; RTS low
.endif
.endif
.if FC2_TYPE == 1
wbtil:
bclr iflags, #istream
; The delay here should be 10 character times long
; times = Fcy/baud*40
; MJM mov #(FCY/BAUDRATE1*40), W2 ; This loop takes about
5 milliseconds @ 27 Mips
mov #13333, W2 ; This loop takes about 5 milliseconds
@ 27 Mips
wbtil2:
btsc iflags, #istream ; Check for UART activity.
bra wbtil ;
dec W2, W2 ;
bra nz, wbtil2 ;
.endif
return
<snip>
;;; Initialise UART2
.ifdecl BAUDRATE2
.ifdecl _U2RXREG
.if FC2_TYPE == 2 ; remap pins override tris
bclr U2RTSTRIS, #U2RTSPIN
bclr U2RTSPORT, #U2RTSPIN ; RTS high
.endif
.ifdecl RPINR19
mov #RPINR19VAL, W0 ; lsb is RX
mov W0, RPINR19 ; msb: (U2CTS), lsb: U2RX
mov #0x0005, W0 ; U2TX #5
mov.b WREG, RPOR0+U2TXPIN
.if FC2_TYPE == 0 ; UART RTS control MJM
mov #0x0006, W0 ; U2RTS #6
mov.b WREG, RPOR0+U2RTSPIN
; enable hdwe CTS/RTS
bset U2MODE, #UEN1 ; enable hdwe CTS/RTS MJM
.endif
.endif
;// Assign U2TX to pin RP17 (pin #50, RF5) MJM
; RPOR15bits.RP30R = 5; // 5 is code for U2TX
;// Assign U2RX to pin RP10 (pin #49, RF4)
; RPINR19bits.U2RXR = 10;
bclr PMD1, #U2MD ; enable UART2 clk
bset U2MODE, #UARTEN ; enable UART2
.ifdecl BRGH
bset U2MODE, #BRGH ; fast baud rates
.endif
mov #BAUD_DIV2, W0
mov W0, U2BRG
bset U2STA, #UTXEN
.ifdecl AUTOBAUD2
.if (AUTOBAUD2 == 1)
bset U2MODE, #ABAUD
WARM_ABAUD2:
btsc U2MODE, #ABAUD
bra WARM_ABAUD2
bclr IFS1, #U2RXIF
.endif
.endif
bset IEC1, #U2RXIE ; enable U2 interrupts
bset IEC1, #U2TXIE
.endif
.endif
<snip>
.pword paddr(RX1Q_L)+PFLASH
.ifdecl BAUDRATE2 ; UART2
.ifdecl _U2RXREG
U2TXQUEUE_L: ; ( -- queue-addr ) Leave the address of the queue for
UART2
.byte NFA|INLINE|5
.ascii "u2txq"
.align 2
U2TXQUEUE:
mlit handle(U2TXQUEUE_DATA)+PFLASH
return
U2TXQUEUE_DATA:
.word txqueue2
.word TX2_BUF_SIZE-1
.pword paddr(U2TXQUEUE_L)+PFLASH
U2RXQUEUE_L:
.byte NFA|INLINE|5
.ascii "u2rxq"
.align 2
U2RXQUEUE:
mlit handle(U2RXQUEUE_DATA)+PFLASH
return
U2RXQUEUE_DATA:
.word rxqueue2
.word RX2_BUF_SIZE-1
.pword paddr(U2RXQUEUE_L)+PFLASH
TX2_L: ; ( c -- ) Put a character to U2TXQ
.byte NFA|3
.ascii "tx2"
.align 2
TX2:
rcall PAUSE
rcall IDLE_
rcall TX2Q
cp0 [W14--]
bra z, TX2
rcall BUSY_
rcall U2TXQUEUE
rcall CQUEUE_TO ; Put to character queue
rcall U2TXQUEUE
rcall CQUEUE_FROMQ ; Character available ? false = no
mov [W14--], W0
sub #2, W0 ; If there are less than 2 chars
bra nn, TX2_2 ; in TX queue,
bset IFS1, #U2TXIF ; clr interrupt flag
TX2_2:
return
.pword paddr(TX2_L)+PFLASH
TX2Q_L: ; ( -- flag ) Leave false flag if
U2TXQ is full.
.byte NFA|4
.ascii "tx2?"
.align 2
TX2Q:
mlit handle(U2TXQUEUE_DATA)+PFLASH
goto CQUEUE_TOQ ; Space available ? false = queue
is full
.pword paddr(TX2Q_L)+PFLASH
RX2_L:
.byte NFA|3
.ascii "rx2"
.align 2
RX2:
rcall PAUSE
rcall RX2Q
cp0 [W14--]
.if FC2_TYPE == 2 ; MJM
bra nz, RX2_1 ; MJM
bclr U2RTSPORT, #U2RTSPIN ; RTS high
bra RX2
RX2_1:
.else
bra z, RX2 ; MJM
.endif
mlit handle(U2RXQUEUE_DATA)+PFLASH
rcall CQUEUE_FROM ; Get from character
queue
return
.pword paddr(RX2_L)+PFLASH
RX2Q_L:
.byte NFA|4
.ascii "rx2?"
.align 2
RX2Q:
rcall BUSY_
mlit handle(U2RXQUEUE_DATA)+PFLASH
rcall CQUEUE_FROMQ ; Character
available ? false = no
cp0 [W14]
bra nz, RX2Q1
rcall IDLE_
btss iflags, #fFC2
bra RX2Q1
.if FC2_TYPE == 1
btst iflags, #ixoff2
bra z, RX2Q1
bclr iflags, #ixoff2
mlit XON
rcall TX2
.else
.if FC2_TYPE == 2
cp0 rbuf_lv2 ; buffer empty?
bra nz, RX2Q1
bclr U2RTSPORT, #U2RTSPIN ; RTS high
.else ; FC2_TYPE == 0 UART handshake
cp0 rbuf_lv2 ; buffer empty?
bra nz, RX2Q1
mov U2RXREG, W0 ; get chr, dump
.endif
.endif
RX2Q1:
return
.pword paddr(RX2Q_L)+PFLASH
.endif
.endif
<snip>
.pword paddr(RX1Q_L)+PFLASH
.ifdecl BAUDRATE2 ; UART2
.ifdecl _U2RXREG
U2TXQUEUE_L: ; ( -- queue-addr ) Leave the address of the queue for
UART2
.byte NFA|INLINE|5
.ascii "u2txq"
.align 2
U2TXQUEUE:
mlit handle(U2TXQUEUE_DATA)+PFLASH
return
U2TXQUEUE_DATA:
.word txqueue2
.word TX2_BUF_SIZE-1
.pword paddr(U2TXQUEUE_L)+PFLASH
U2RXQUEUE_L:
.byte NFA|INLINE|5
.ascii "u2rxq"
.align 2
U2RXQUEUE:
mlit handle(U2RXQUEUE_DATA)+PFLASH
return
U2RXQUEUE_DATA:
.word rxqueue2
.word RX2_BUF_SIZE-1
.pword paddr(U2RXQUEUE_L)+PFLASH
TX2_L: ; ( c -- ) Put a character to U2TXQ
.byte NFA|3
.ascii "tx2"
.align 2
TX2:
rcall PAUSE
rcall IDLE_
rcall TX2Q
cp0 [W14--]
bra z, TX2
rcall BUSY_
rcall U2TXQUEUE
rcall CQUEUE_TO ; Put to character queue
rcall U2TXQUEUE
rcall CQUEUE_FROMQ ; Character available ? false = no
mov [W14--], W0
sub #2, W0 ; If there are less than 2 chars
bra nn, TX2_2 ; in TX queue,
bset IFS1, #U2TXIF ; clr interrupt flag
TX2_2:
return
.pword paddr(TX2_L)+PFLASH
TX2Q_L: ; ( -- flag ) Leave false flag if
U2TXQ is full.
.byte NFA|4
.ascii "tx2?"
.align 2
TX2Q:
mlit handle(U2TXQUEUE_DATA)+PFLASH
goto CQUEUE_TOQ ; Space available ? false = queue
is full
.pword paddr(TX2Q_L)+PFLASH
RX2_L:
.byte NFA|3
.ascii "rx2"
.align 2
RX2:
rcall PAUSE
rcall RX2Q
cp0 [W14--]
.if FC2_TYPE == 2 ; MJM
bra nz, RX2_1 ; MJM
bclr U2RTSPORT, #U2RTSPIN ; RTS high
bra RX2
RX2_1:
.else
bra z, RX2 ; MJM
.endif
mlit handle(U2RXQUEUE_DATA)+PFLASH
rcall CQUEUE_FROM ; Get from character
queue
return
.pword paddr(RX2_L)+PFLASH
RX2Q_L:
.byte NFA|4
.ascii "rx2?"
.align 2
RX2Q:
rcall BUSY_
mlit handle(U2RXQUEUE_DATA)+PFLASH
rcall CQUEUE_FROMQ ; Character
available ? false = no
cp0 [W14]
bra nz, RX2Q1
rcall IDLE_
btss iflags, #fFC2
bra RX2Q1
.if FC2_TYPE == 1
btst iflags, #ixoff2
bra z, RX2Q1
bclr iflags, #ixoff2
mlit XON
rcall TX2
.else
.if FC2_TYPE == 2
cp0 rbuf_lv2 ; buffer empty?
bra nz, RX2Q1
bclr U2RTSPORT, #U2RTSPIN ; RTS high
.else ; FC2_TYPE == 0 UART handshake
cp0 rbuf_lv2 ; buffer empty?
bra nz, RX2Q1
mov U2RXREG, W0 ; get chr, dump
.endif
.endif
RX2Q1:
return
<snip>
QUIT1:
rcall check_sp
rcall CR
rcall TIB
mov [W14++], [W14] ; dup
rcall TIBSIZE
mlit HOLD_SIZE ; Reserve for hold buffer
rcall MINUS
rcall ACCEPT
.if WRITE_METHOD == 2
.if FC2_TYPE == 1
mov #XOFF, W2
mov W2, U2TXREG ; send chr
bset iflags, #ixoff2
.endif
.endif
rcall SPACE_
rcall INTERPRET
rcall STATE
cp0 [W14--]
bra nz, QUIT1
.if WRITE_METHOD == 2
btss iflags1, #edirty ; If dirty then write after
timeout in PAUSE
.endif
rcall DP_TO_EEPROM
rcall XSQUOTE
.byte 3
.ascii "ok "
.align 2
rcall TYPE
rcall PROMPT
bra QUIT0
return
Mike Miller WB6TMH
Moon Valley Circuits
Glen Ellen, CA 95442
|
|
From: Mikael N. <mik...@fl...> - 2015-05-19 21:48:43
|
I tried the PICs internal HW FC but it did not work well with FF so I skipped it. The FF UART routines and HW flow control have been reworked slightly since you used them. I am using the HW FC with a microstickII and microstickplus MCP2200 UART USB bridge and it works really well. On 19.05.2015 22:44, Mike Miller wrote: > I have been casually following the thread about TeraTerm. > > I use TeraTerm on Windows, CoolTerm on OSX. > > I have been using hardware handshake, with NO delay. I use a > USB-to-serial adapter using the FTDI chipset, which seems to get the > handshake right. > I has been a couple of years since I wrote these, so I hope I am > including all of the changes. > > To do this, I have modified the UART driver. I use UART #2, FC_TYPE=2 > I also have FC_TYPE=0 defined using the PIC's handshake control, but > that does not work very well. |
|
From: om1zz <om...@vo...> - 2015-05-19 20:45:08
|
>I have been using hardware handshake, with NO delay. I use a >USB-to-serial adapter using the FTDI chipset, which seems to get the >handshake right. The TeraTerm macro (in my today's post) works with zero uart transmit delays and with no flow control set in TT serial setting. I am using an obsolate CA-42 ArkMicro based usb dongle under XP (as there is none x64 driver for 7) wired w/ rx/tx/gnd only. The handshake is done via \n sent by FF. I set FF rx/tx buffers to 511. Works fine here at 921k with dspic33 @40MHz. As I am a big fan of wireless I use normally HC-05 BTooth dongles with all my dev boards. The issue with these cheap BT dongles is they do not propagate cts/rts so hw handshake cannot be used.. Thus a good working sw handshake would come in handy :) I've ebayed today 2xftdi232rl 1xPL2303TA 1xCP2102 usb serial dongles to play with (hopefully they all will work with 7-8 x64). Also I want to investigate whether the Xon/Xoff problem comes from the usb dongles or from Teraterm itself, as I can see in the TT's log the FF sends the XOFF from time to time.. Igor |
|
From: Mikael N. <mik...@fl...> - 2015-05-19 21:52:33
|
I have been using the RN41 and RN42 Bluetooth tranceivers. These support HW flow control and have worked really well. Here is my youtube video where you can see it in use. https://www.youtube.com/watch?v=bt0S_pLQOvA :-) On 19.05.2015 23:44, om1zz wrote: > As I am a big fan of wireless I use normally HC-05 BTooth dongles with all my dev boards. > The issue with these cheap BT dongles is they do not propagate cts/rts so hw handshake cannot be used.. > Thus a good working sw handshake would come in handy :) > > I've ebayed today 2xftdi232rl 1xPL2303TA 1xCP2102 usb serial dongles to play with (hopefully they all will work with 7-8 x64). > Also I want to investigate whether the Xon/Xoff problem comes from the usb dongles or from Teraterm itself, as I can see in the TT's log the FF sends the XOFF from time to time.. > Igor |
|
From: om1zz <om...@vo...> - 2015-05-19 22:09:07
|
>I have been using the RN41 and RN42 Bluetooth tranceivers. >These support HW flow control and have worked really well. BT module inside a HF receiver - such a creative approach :) BTW the BT antenna should be placed at least lambda/4 from a nearest conductive object :) |
|
From: <exp...@vn...> - 2015-05-19 23:01:09
|
Hello Igor, I have tried your TT macro with 18F26K22@64MHz, 38400bps, FT230X, Win7. Unfortunately it was not efficient to get rid of the delays. Have you any idea why this is? BR Attila Herman |
|
From: om1zz <om...@vo...> - 2015-05-20 06:11:07
|
Hi Attila, I think it could be because the 18F is slow to process the incoming data, somehow. Its speed is 16MHz and it is an 8bitter. Also double check the size of rx/tx buffers, I use 511 for both (if that fits into the ram, of course). Igor. > >Hello Igor, > >I have tried your TT macro with 18F26K22@64MHz, 38400bps, FT230X, Win7. >Unfortunately it was not efficient to get rid of the delays. >Have you any idea why this is? > >BR >Attila Herman l > |
|
From: om1zz <om...@vo...> - 2015-05-20 07:23:56
|
Hi Attila, I've done following experiment (dspic33fj128gp802): 1. rx buffer = 127, tx buffer = 15 2. Fcy 16.588MHz (internal oscillator and PLL) 3. baud 921k600 8N1, zero transmit delays, no flow control 4. CA-42 clone usb serial 4. I did 8 uploads of float.txt, once it stops here: : emitnzeros ( n -- ) 8 constant precision exponent?precision ?? otherwise it uploads fine, in 14 seconds: finit ok<#,ram> Fcy ok<#,ram> 16588 -3.23248e-10 fe. -323.24807E-12 ok<#,ram> 16588 Still the dspic33 is a bit faster as it is a 16bitter. Igor. >Hi Attila, >I think it could be because the 18F is slow to process the incoming data, somehow. >Its speed is 16MHz and it is an 8bitter. >Also double check the size of rx/tx buffers, I use 511 for both (if that fits into the ram, of course). >Igor. > >> >>Hello Igor, >> >>I have tried your TT macro with 18F26K22@64MHz, 38400bps, FT230X, Win7. >>Unfortunately it was not efficient to get rid of the delays. >>Have you any idea why this is? >> >>BR >>Attila Herman >l >> > |
|
From: om1zz <om...@vo...> - 2015-05-20 09:44:32
|
This is v.0.3 update patch: 1. save your TT settings with your transmit delays into 'teraterm.ini' 2. save your TT settings with zero transmit delays into 'teraterm_ztrd.ini' 3. when working in TT window directly it uses your delays so you can copy/paste your source code 4. when using below macro it sets delays to zero, after the upload it restores the ini back to the one with your delays 5. if you may know how to set transmit delays in the macro it could be used instead of rather heavier 'restoresetup' Still beta, no warranties of any kind :) Igor ; TeraTerm Macro Script for FlashForth ; Serial set within TT session ; Opens a file, reads each line, and sends the line to FF ; while waiting on "\n" or "??" from FF to handshake ; IgorM c 5/2015, No warranties of any kind ; v.0.3 :Main Yes = 1 ; for YesNoBox result No = 0 ; for YesNoBox result BlankLine = 0 restoresetup 'teraterm_ztrd.ini' call OpenFile call ReadFile call CloseFile restoresetup 'teraterm.ini' END >This is v0.2 of the script, it removes blank lines and comments if required, stops and asks on ?? error. >You have to mod the ? to ?? in the asm. >Uploads the 665 lines long float.txt in 8 seconds (921k, pic33, Fcy 40MHz) fine ;) >Still beta, no warranties of any kind :) > > ; TeraTerm Macro Script fro FlashForth > ; Serial set within TT session > ; Opens a file, reads each line, and sends the line to FF > ; while waiting on "OK" or "??" after the \r\n sent > ; IgorM c 5/2015 > ; v.0.2 > > :Main > Yes = 1 ; for YesNoBox result > No = 0 ; for YesNoBox result > BlankLine = 0 > call OpenFile > call ReadFile > call CloseFile > END > > :OpenFile > FileNameBox 'Choose a file to upload' > FileChosen = result > if FileChosen = Yes then > FileOpen fhandle inputstr 0 > else > end > endif > RETURN > > :ReadFile > YesNoBox 'Do you want to skip blank lines and comments?' 'Skip?' > SkipBlanks = result > > while 1 > > ; Read a line from the file.. > > filereadln fhandle line > EndOfFile = result > > if EndOfFile = Yes break > > StrLen line > LineLen = result > > if SkipBlanks = Yes then > if LineLen = BlankLine continue > strscan line '\' > if result = 1 continue > if result > 1 then > strremove line result LineLen-result+1 > endif > endif > > sendln line > > timeout = 1 ; 1 sec > wait #13 "??" ; wait on OK(\n) or an Error ?? > > if result = 0 break ; timeout > > ;if result = 1 goto _ok ; OK detected > > if result = 2 then ; exit if ?? Error from FF > YesNoBox 'Error - Do you want proceed w/ Upload?' 'Continue?' > if result = No break > endif > > ; Repeat until the end of the file.. > > endwhile > RETURN > > :CloseFile > FileClose fhandle > RETURN > ;----------------------------------------------------------- > > |
|
From: om1zz <om...@vo...> - 2015-05-21 18:13:46
|
An another result: Teraterm with my macro, 115k2, dspic33, Fcy=16.6MHz, rxbuf=127, zero transmit delays HC-05 Bluetooth dongle, 115k2 8N1 uploads float.txt in 21secs.. I. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X