'----------------------------------------------------------------------------------------
'    Name:  Serial_2STOP_Bits.TIG
'    Type:  Tiger-BASIC(tm) Source Code
' Purpose:  Demo for serial transmission with 1.5, 2 or more STOP bits
'
'  (C) - Copyright Wilke Technology, P.O.Box 1727, D-52018 Aachen, Germany
'----------------------------------------------------------------------------------------
'
' Thank you for using BASIC Tigers in your products. If you have questions, ideas
' or special needs, please contact your next distributor or the Tiger support team
' and visit our web site:
'
'	Wilke Technology GmbH
'	The Tiger Support Team
'	P.O.Box 1727,       D-52018 Aachen, Germany
'	Krefelder Str. 147, D-52070 Aachen, Germany
'
'	email: support@wilke-technology.com  (english)
'	email: support@wilke.de              (german)
'	Phone: +49 (241) 918 900    Mo to Fr, 7:00 to 16:00 (GMT)
'	Fax:   +49 (241) 918 9068
'
' New information, new drivers and free downloads see:
'
'	www.wilke-technology.com	     (english)
'	www.wilke.de                         (german)
'
' Sincerely,
'
'	Your Tiger Support Team
'
'----------------------------------------------------------------------------------------
'
' The requirement of 2 (or more) STOP bits in a serial ASYNC transmission is quite
' seldom today. Though, it still can happen.
'
' More than 1 stop bit (1.5, 2, 3) has been necessary in the days of slowly working
' devices (as mechanical units), to allow the receiving unit to assemble and process a
' byte and to get ready for receiving the next data byte.
'
' Following example code shows how to connect equipment that needs more than 1 stop bit
' with a BASIC Tiger / TINY Tiger.
'
' The point is, that in the receiving path of the serial connection there is absolutely
' no need to change anything. Any stream of bytes coming in serially with 1 or more
' stop bits is received without problems. It is always OK to have any number of
' stop bits - or in other words delay time - between 2 subsequent data bytes.
' As the BASIC Tiger only  n e e d s  1 stop bit, any additional delay time is
' fine and gets re-synchronised automatically (async transmission).
'
' The case is different in the other direction. The indication of "2 stop bits"
' signals that the other device needs this minimum of 2 stop bits. Transmitting
' only 1 stop bit and starting right away the next transmitted byte would overrun
' the other sides receiving circuit.
'
' So we have to add at least 1 more stop bit. Again, it is always OK to add more than
' that, as we are in an async type transmission, and each sides receiving devices
' re-synchronise byte by byte.
'
' With this said, we can easily use such code fragments to connect serially to a
' 2 stop bit (and 9600 Bd, 8 Data + Parity) partner for example:
'
'----------------------------------------------------------------------------------------

'------------- code fragment "Receive Data" -------------

GET #SER, #1, 0, RECEIVE$	' <-- receive serial data as normal. Nothing special !



'------------- code fragment "Send Data" ----------------

STRING A$(100)
LONG N

A$ = "Hello World"

FOR N = 0 TO LEN (A$)-1		' send a STRING of characters 1 by 1 byte with some
  PUT #SER, #1, MID$(A$,N,1)	' delay in between.
  WAIT_DURATION 3		' A minimum of 2 msec delay guarantees more than
NEXT				' 2 stop bits in a 9600 baud, 8 data + parity transmission