- Clear Serial Buffer Vb Net Worth
- Clear Serial Buffer Vb Net Present Value
- Clear Serial Buffer Vb Net Promoter
- Clear Serial Buffer Vb Network
- Clear Serial Buffer Vb Net Server
- Clear Serial Buffer Vb Net Acces
Serial Communication with VB.Net
Im a noob at c so all I see is long code and that's all i have to work with, please give me a really basic example, the serial buffer normally gets outputted to the lcd screen, but the lcd is 16, 1 and fills up and stops any more input and even puts in strange chars if i try to add more in so maybe i need to use the lcd.clear but then it might. Graphics, VB.NET If you draw a very complex drawing in a form's Paint event handler, the user may see the drawing flicker as different parts are drawn. You can eliminate that flickering by using double buffering.
One of the thing I really miss while using VB.Net is the lack of serial communication support.Yes, you can use VB6's MsComm32.ocx but if you, like me, have installed VB.Net on a separate hard disk you may experience some problems installing and using it in design mode.
Don't forget moreover that if you use that control, you must register it on user machine when you deploy your application, loosing the 'XCopy installation mode' provided by VB.Net.
With this class you can easily use serial communication using native VB.Net and API features.
Before describing you how to use the class, let me point out that I've just written it as a demonstration of VB.Net interface to serial communication, you'd probably need to customize it for your special 'Rs232' needs.
Initializing and Opening the Com port
Create an instance of CRs232 then set COM parameters before invoking the Open method
Here's an example:
Dim moRS232 as New Rs232()
With moRs232
.Port = 1 '// Uses COM1
.BaudRate = 2400 '// 2400 baud rate
.DataBit = 8 ‘// 8 data bits
.StopBit = Rs232.DataStopBit.StopBit_1 '// 1 Stop bit
.Parity = Rs232.DataParity.Parity_None '// No Parity
.Timeout = 500 '// 500 ms of timeout admitted to get all required bytes
End With
'// Initializes and Open
moRS232.Open()
You can, optionally control the state of DTR/RTS lines after the Port is open
'// Set state of RTS / DTS
moRS232.Dtr = True
moRS232.Rts = True
In case of an error/problems an exception is raised, so i suggest you to enclose the code within a Try...Catch block.
Transmitting data to COM Port
The class has 2 buffers one for Tx and one for Rx, to transmit data just set the TxData property with the informations you wish to send then invoke the Tx method.
example:
moRS232.Write(txtTx.Text)
Receiving data from COM Port
Just invoke the Rx method passing it the number of bytes you want to read from COM port, then read the Rxdata property.
example:
moRS232.Read(10) '// Gets 10 bytes from serial communication buffer
Dim sRead as String=moRs232.InputStreamString
Please note that thread is blocked for the period of time set by Timeout property and that in case the class cannot read all required bytes from COM buffer a Timeout exception is raised.
If the number of bytes to read is omitted, the class assumes 512 bytes have to be read from buffer.
The class is very simple and surely misses some error control, but as prefaced I just wanted to give you an example of what you can do with VB.Net without resorting to ocx'es or other 3rdy parties controls
More details
The zip file that you can download here includes also a small Windows Form example that can help you understand how to use my class.
How to use the sample
If not enough character are received inside allocated timeout, you will have an error and you will se what has been read from serial port. RTS and DTR checkboxes will allow you to change the status of RTS and DTR lines respectively. Enabling events Events are signaled by a CommEvent event, and you can use Mask parameter to detect what event has occurred, if you set a number of character into Bytes to read texbox, as soon as those character arrives into serial port you will get a CommEvent that you can use to get received characters. |
Enjoy !
Corrado Cavalli
corrado@mvps.org
You can download latest version here (example requires Visual Studio 2003)
Previous version is available here
To load my project on Visual Studio 2002
- Remove Form1
- Set added form as startup form
All code is freely redistributable, just let me know if you enjoy using it....
Project History
1st Public release Beta2 (10/08/2001)
Rev.1 (28.02.2002)
1. Added ResetDev, SetBreak and ClearBreak to the EscapeCommFunction constants
2. Added the overloaded Open routine.
3. Added the modem status routines, properties and enum.
4. If a read times out, it now returns a EndOfStreamException (instead of a simple Exception).
5.Compiled with VS.Net final
Rev.2 (01.03.2002)
Added Async support
Rev.3 (07.04.2002)
Minor bugs fixed
Rev.3a (05/05/2002)
Fixed BuildCommmDCB problem
Rev.4 (24/05/2002)
Fixed problem with ASCII Encoding truncating 8th bit
Rev.5 (27/05/2002)
Added IDisposable / Finalize implementation
Rev.6 (14/03/2003)
Fixed problem on DCB fields Initialization
Rev.7 (26/03/2003)
Added XON/XOFF support
Rev.8 (12/07/2003)
Added support to COM port number greater than 4
Rev.9 (16/07/2003)
Added CommEvent to detect incoming chars/events(!)
Updated both Tx/Rx method from Non-Ovelapped to Overlapped mode
Removed unused Async methods and other stuff.
Rev.10 (21/07/2003)
Fixed incorrect character handling when using EnableEvents()
Rev.11 (12/08/2003)
Fixed some bugs reported by users
Rev.12 (01/09/2003)
Removed AutoReset of internal buffers and added PurgeBuffer() method
Rev.13 (02/09/2003)
Update internal stuff now using Win32Exception instead of GetLastError+FormatMessage APIs
Rev.14 (14/09/2003)
Added IsPortAvailable() function (thanks to Tom Lafleur for the hint)
Revised some API declaration
Fixed some problems with Win98/Me OS (thanks to Alex Komissarov for the feedback)
Rev.15 (24/09/2003)
Fixed bug introduced on rev.14 (sorry for that...)
Rev.16 (16/10/2003)
Added SetBreak/ClearBreak methods for sending break signal over the line.
Rev.17 (02/11/2003)
Fixed incorrect field on COMMCONFIG Structure.
Rev.18 (03/03/2004)
Fixed bug causing troubles accessing already in use ports (folks, thanks for the feedback!)
Rev.19 (08/04/2004)
Fixed bug on DTR property (thanks to Charles-Olivier Théroux)
Rev.20 (12/07/2004)
CommEvent is no more raised on a secondary thread (please note that this is valid only if event handler is not associated with a static method)
pEventsWatcher now uses a background thread
Rev.21 (24/10/2004)
Fixed EscapeCommFunction declaration
Fixed incorrect Pariti enum entry
Rev.22 (05/03/2005)
Fixed memory leak causing random program termination without any message.
Thanks to Ralf Gedrat for testing this scenario.
Rev.23 (05/04/2005)
Fixed bug DisableEvents not working bug (Thanks to Jean Bédard)
Rev.24 (20/04/2005)
Fixed memory leak on Read() method
Added InBufferCount property
IsPortAvailable method is now shared (Thanks to Jean-Pierre ZANIER for the feedback)
back to home page
You don't have to understand the basics to use the serial port Butunderstanding it may help to determine what is wrong if you run intoproblems. This section not only presents new topics but also repeatssome of what was said in the previous section How the Hardware Transfers Bytes but in greater detail.
Intro to Serial
The UART serial port (or just 'serial port for short' is an I/O (Input/Output) device.
An I/O device is just a way to get data into and out of a computer.There are many types of I/O devices such as the older serial ports andparallel ports, network cards, universal serial buses (USB), andfirewire etc.Most pre-2007 PC's have a serial port or two (on older PC's). Eachhas a 9-pin connector (sometimes 25-pin) on the back of the computer.Computer programs can send data (bytes) to the transmit pin (output)and receive bytes from the receive pin (input). The other pins arefor control purposes and ground.
The serial port is much more than just a connector. It converts thedata from parallel to serial and changes the electrical representationof the data. Inside the computer, data bits flow in parallel (usingmany wires at the same time). Serial flow is a stream of bits over asingle wire (such as on the transmit or receive pin of the serialconnector). For the serial port to create such a flow, it mustconvert data from parallel (inside the computer) to serial on thetransmit pin (and conversely).
Most of the electronics of the serial port is found in a computer chip(or a part of a chip) known as a UART. For more details on UARTssee the sectionWhat Are UARTS? But you may want to finish this section first so that you willhopefully understand how the UART fits into the overall scheme ofthings.
Pins and Wires
Old PC's used 25 pin connectors but only about 9 pins wereactually used so later on most connectors were only 9-pin. Each ofthe 9 pins usually connects to a wire. Besides the two wires used fortransmitting and receiving data, another pin (wire) is signal ground.The voltage on any wire is measured with respect to this ground. Thusthe minimum number of wires to use for 2-way transmission of data is3. Except that it has been known to work with no signal ground wirebut with degraded performance and sometimes with errors.
There are still more wires which are for control purposes (signalling)only and not for sending bytes. All of these signals could have beenshared on a single wire, but instead, there is a separate dedicatedwire for every type of signal. Some (or all) of these control wiresare called 'modem control lines'. Modem control wires are either inthe asserted state (on) of +5 volts or in the negated state (off) of-5 volts. One of these wires is to signal the computer to stopsending bytes out the serial port cable. Conversely, another wiresignals the device attached to the serial port to stop sending bytesto the computer. If the attached device is a modem, other wires maytell the modem to hang up the telephone line or tell the computer thata connection has been made or that the telephone line is ringing(someone is attempting to call in). See sectionPinout and Signals for more details.
RS-232 (EIA-232, etc.)
The serial port (not the USB) is usually a RS-232-C, EIA-232-D, orEIA-232-E. These three are almost the same thing. The original RS(Recommended Standard) prefix officially became EIA (ElectronicsIndustries Association) and later EIA/TIA after EIA merged with TIA(Telecommunications Industries Association). The EIA-232 specprovides also for synchronous (sync) communication but the hardware tosupport sync is almost always missing on PC's. The RS designation iswas intended to become obsolete but is still widely used and will beused in this howto for RS-232. Other documents may use the fullEIA/TIA designation, or just EIA or TIA. For info on other(non-RS-232) serial ports see the section Other Serial Devices (not async RS-232)
Since the computer needs to communicate with each serial port, theoperating system must know that each serial port exists and where itis (its I/O address). It also needs to know which wire (IRQ number)the serial port must use to request service from the computer's CPU.It requests service by sending an interrupt voltage on this wire.Thus every serial port device must store in its non-volatile memoryboth its I/O address and its Interrupt ReQuest number: IRQ. See Interrupts. The PCI bus has its own system ofinterrupts. But since the PCI-aware BIOS sets up these PCI interruptsto map to IRQs, it seemingly behaves just as described above. Exceptthat sharing of PCI interrupts is allowed (2 or more devices may usethe same IRQ number).
I/O addresses are not the same as memory addresses. When an I/Oaddresses is put onto the computer's address bus, another wire isenergized. This both tells main memory to ignore the address andtells all devices which have I/O addresses (such as the serial port)to listen to the address sent on the bus to see if it matches thedevice's. If the address matches, then the I/O device reads the dataon the data bus.
The I/O address of a certain device (such as ttyS2) will actually be arange of addresses. The lower address in this range is the baseaddress. 'address' usually means just the 'base address'.
The serial ports are named ttyS0, ttyS1, etc. (and usuallycorrespond respectively to COM1, COM2, etc. in DOS/Windows). The /devdirectory has a special file for each port. Type 'ls /dev/ttyS*' tosee them. Just because there may be (for example) a ttyS3 file,doesn't necessarily mean that there exists a physical serial portthere.
Which one of these names (ttyS0, ttyS1, etc.) refers to whichphysical serial port is determined as follows. The serial driver(software) maintains a table showing which I/O address corresponds towhich ttyS. This mapping of names (such as ttyS1) to I/O addresses(and IRQ's) may be both set and viewed by the 'setserial' command.See What is Setserial. This doesnot set the I/O address and IRQ in the hardware itself (which isset by jumpers or by plug-and-play software). Thus which physical portcorresponds to say ttyS1 depends both on what the serial driver thinks(per setserial) and what is set in the hardware. If a mistake hasbeen made, the physical port may not correspond to any name (such asttyS2) and thus it can't be used. See Serial Port Devices /dev/ttyS2, etc. for more details.
When the serial port receives a number of bytes (may be set to 1, 4,8, or 14) into its FIFO buffer, it signals the CPU to fetch them bysending an electrical signal known as an interrupt on a certain wirenormally used only by that port. Thus the FIFO waits until it hasreceived a number of bytes and then issues an interrupt.
However, this interrupt will also be sent if there is an unexpecteddelay while waiting for the next byte to arrive (known as a timeout).Thus if the bytes are being received slowly (such as from someonetyping on a terminal keyboard) there may be an interrupt issued forevery byte received. For some UART chips the rule is like this: If 4bytes in a row could have been received in an interval of time, butnone of these 4 show up, then the port gives up waiting for more bytesand issues an interrupt to fetch the bytes currently in the FIFO. Ofcourse, if the FIFO is empty, no interrupt will be issued.
Each interrupt conductor (inside the computer) has a number (IRQ) andthe serial port must know which conductor to use to signal on. Forexample, ttyS0 normally uses IRQ number 4 known as IRQ4 (or IRQ 4). Alist of them and more will be found in 'man setserial' (search for'Configuring Serial Ports'). Interrupts are issued whenever theserial port needs to get the CPU's attention. It's important to dothis in a timely manner since the buffer inside the serial port canhold only 16 incoming bytes. If the CPU fails to remove such receivedbytes promptly, then there will not be any space left for any moreincoming bytes and the small buffer may overflow (overrun) resultingin a loss of data bytes.
There is no Flow Control to prevent this.
Interrupts are also issued when the serial port has just sent out allof its bytes from its small transmit FIFO buffer out the externalcable. It then has space for 16 more outgoing bytes. The interruptis to notify the CPU of that fact so that it may put more bytes in thesmall transmit buffer to be transmitted. Also, when a modem controlline changes state, an interrupt is issued.
The buffers mentioned above are all hardware buffers. The serial portalso has large buffers in main memory. This will be explained later
Interrupts convey a lot of information but only indirectly. Theinterrupt itself just tells a chip called the interrupt controllerthat a certain serial port needs attention. The interrupt controllerthen signals the CPU. The CPU then runs a special program to servicethe serial port. That program is called an interrupt service routine(part of the serial driver software). It tries to find out what hashappened at the serial port and then deals with the problem such atransferring bytes from (or to) the serial port's hardware buffer.This program can easily find out what has happened since the serialport has registers at IO addresses known to the serial driversoftware. These registers contain status information about the serialport. The software reads these registers and by inspecting thecontents, finds out what has happened and takes appropriate action.
Data (bytes representing letters, pictures, etc.) flows into andout of your serial port. Flow rates (such as 56k (56000) bits/sec)are (incorrectly) called 'speed'. But almost everyone says 'speed'instead of 'flow rate'.
It's important to understand that the average speed is often less thanthe specified speed. Waits (or idle time) result in a lower averagespeed. These waits may include long waits of perhaps a second due toFlow Control. At the other extremethere may be very short waits (idle time) of several micro-secondsbetween bytes. If the device on the serial port (such as a modem)can't accept the full serial port speed, then the average speed mustbe reduced.
Flow control means the ability to slow down the flow of bytes in awire. For serial ports this means the ability to stop and thenrestart the flow without any loss of bytes. Flow control is neededfor modems and other hardware to allow a jump in instantaneous flow rates.
Example of Flow Control
For example, consider the case where you connect a 33.6k externalmodem via a short cable to your serial port. The modem sends andreceives bytes over the phone line at 33.6k bits per second (bps).Assume it's not doing any data compression or error correction. Youhave set the serial port speed to 115,200 bits/sec (bps), and you aresending data from your computer to the phone line. Then the flow fromthe your computer to your modem over the short cable is at 115.2k bps.However the flow from your modem out the phone line is only 33.6k bps.Since a faster flow (115.2k) is going into your modem than is comingout of it, the modem is storing the excess flow (115.2k -33.6k = 81.6kbps) in one of its buffers. This buffer would soon overrun (run outof free storage space) unless the high 115.2k flow is stopped.
But now flow control comes to the rescue. When the modem's buffer isalmost full, the modem sends a stop signal to the serial port. Theserial port passes on the stop signal on to the device driver and the115.2k bps flow is halted. Then the modem continues to send out dataat 33.6k bps drawing on the data it previous accumulated in itsbuffer. Since nothing is coming into this buffer, the number of bytesin it starts to drop. When almost no bytes are left in the buffer,the modem sends a start signal to the serial port and the 115.2k flowfrom the computer to the modem resumes. In effect, flow controlcreates an average flow rate in the short cable (in this case 33.6k)which is significantly less than the 'on' flow rate of 115.2k bps.This is 'start-stop' flow control.
In the above simple example it was assumed that the modem did no datacompression. This could happen when the modem is sending a filewhich is already compressed and can't be compressed further. Nowlet's consider the opposite extreme where the modem is compressing thedata with a high compression ratio. In such a case the modem mightneed an input flow rate of say 115.2k bps to provide an output (to thephone line) of 33.6k bps (compressed data). This compression ratio is3.43 (115.2/33.6). In this case the modem is able to compress the115.2 bps PC-to-modem flow and send the same data (in compressed form)out the phone line at 33.6bps. There's no need for flow control hereso long as the compression ratio remains higher than 3.43. But thecompression ratio varies from second to second and if it should dropbelow 3.43, flow control will be needed
In the above example, the modem was an external modem. But the samesituation exists (as of early 2003) for most internal modems. There isstill a speed limit on the PC-to-modem speed even though this flowdoesn't take place over an external cable. This makes the internalmodems compatible with the external modems.
In the above example of flow control, the flow was from the computer toa modem. But there is also flow control which is used for theopposite direction of flow: from a modem (or other device) to acomputer. Each direction of flow involves 3 buffers: 1. in the modem2. in the UART chip (called FIFOs) and 3. in main memory managed by theserial driver. Flow control protects all buffers (except the FIFOs)from overflowing.
Under Linux, the small UART FIFO buffers are not protected by flowcontrol but instead rely on a fast response to the interrupts theyissue. Some UART chips can be set to do hardware flow control toprotect their FIFOs but Linux (as of early 2003) doesn't seem tosupport it. FIFO stand for 'First In, First Out' which is the way ithandles bytes in a queue. All the 3 buffers use the FIFO rule butonly the one in the UART is named 'FIFO'. This is the essence of flowcontrol but there are still some more details.
Symptoms of No Flow Control
Understanding flow-control theory can be of practical use. Thesymptom of no flow control is that chunks of data missing from filessent without the benefit of flow control. When overflow happens,often hundreds or even thousands of bytes get lost, and all incontiguous chunks.
Hardware vs. Software Flow Control
If feasible, it's best to use 'hardware' flow control that uses twodedicated 'modem control' wires to send the 'stop' and 'start'signals. Hardware flow control at the serial port works like this:The two pins, RTS (Request to send) and CTS (Clear to send) are used.When the computer is ready to receive data it asserts RTS by putting apositive voltage on the RTS pin (meaning 'Request To Send to me').When the computer is not able to receive any more bytes, it negatesRTS by putting a negative voltage on the pin saying: 'stop sending tome'. The RTS pin is connected by the serial cable to another pin onthe modem, printer, terminal, etc. This other pin's only function isto receive this signal.
For the case of a modem, this 'other' pin will be the modem's RTS pin.But for a printer, another PC, or a non-modem device, it's usually aCTS pin so a 'crossover' or 'null modem' cable is required. Thiscable connects the CTS pin at one end with the RTS pin at the otherend (two wires since each end of the cable has a CTS pin). For amodem, a straight-thru cable is used.
For the opposite direction of flow a similar scheme is used. For amodem, the CTS pin is used to send the flow control signal to the CTSpin on the PC. For a non-modem, the RTS pin sends the signal. Thusmodems and non-modems have the roles of their RTS and CTS pinsinterchanged. Some non-modems such as dumb terminals may use otherpins for flow control such as the DTR pin instead of RTS.
Software flow control uses the main receive and transmit data wires tosend the start and stop signals. It uses the ASCII control charactersDC1 (start) and DC3 (stop) for this purpose. They are just insertedinto the regular stream of data. Software flow control is not onlyslower in reacting but also does not allow the sending of binary dataunless special precautions are taken. Since binary data will likelycontain DC1 and DC3 characters, special means must be taken todistinguish between a DC3 that means a flow control stop and a DC3that is part of the binary code. Likewise for DC1.
It's been mentioned that there are 3 buffers for each direction offlow (3 pairs altogether): 16-byte FIFO buffers (in the UART), a pairof larger buffers inside a device connected to the serial port (suchas a modem), and a pair of buffers (say 8k) in main memory. When anapplication program sends bytes to the serial port they first getstashed in the transmit serial port buffer in main memory. The othermember of this pair consists of a receive buffer for the oppositedirection of byte-flow. Here's an example diagram for the case ofbrowsing the Internet with a browser. Transmit data flow is left toright while receive flow is right to left. There is a separate bufferfor each direction of flow.
For the transmit case, the serial device driver takes out say 15 bytesfrom this transmit buffer (in main memory), one byte at a time andputs them into the 16-byte transmit buffer in the serial UART fortransmission. Once in that transmit buffer, there is no way to stopthem from being transmitted. They are then transmitted to themodem or (other device connected to the serial port) which also has afair sized (say 1k) buffer. When the device driver (on orders fromflow control sent from the modem) stops the flow of outgoing bytesfrom the computer, what it actually stops is the flow of outgoingbytes from the large transmit buffer in main memory. Even after thishas happened and the flow to the modem has stopped, an applicationprogram may keep sending bytes to the 8k transmit buffer until itbecomes full. At the same time, the bytes stored in the FIFO continueto be sent out. Bytes stored in the modem will continue to be sentout the phone line unless the modem has gotten a modem-to-modem flowcontrol stop from the modem at the other end of the phone line.
When the memory buffer gets full, the application program can't sendany more bytes to it (a 'write' statement in a C-program blocks) andthe application program temporarily stops running and waits until somebuffer space becomes available. Thus a flow control 'stop' isultimately able to stop the program that is sending the bytes. Eventhough this program stops, the computer does not necessarily stopcomputing since it may switch to running other processes while it'swaiting at a flow control stop.
The above was a little oversimplified in three ways. First, some UARTscan do automatic hardware flow control which can stop the transmissionout of the FIFO buffers if needed (not yet supported by Linux).Second, while an application process is waiting to write to thetransmit buffer, it could possibly perform other tasks. Third, theserial driver (located between the memory buffer and the FIFO) hasit's own small buffer (in main memory) used to process characters.
For many situations, there is a transmit path involving severallinks, each with its own flow control. For example, I type at atext-terminal connected to a PC and the PC (under my control) dialsout to another computer using a modem. Today, a 'text-terminal' islikely to be just another PC emulating a text-terminal. The main(server) PC, in addition to serving my text-terminal, could also havesomeone else sitting at it doing something else. Note that callingthis PC a 'server' is not technically correct but it does serve theterminal.
The text-terminal uses a command-line interface with no graphicaldisplay. Every letter I type at the text-terminal goes over theserial cable to my main PC and then over the phone line to thecomputer that I've dialed out to. To dial out, I've used thecommunication software: 'minicom' which runs on my PC.
This sounds like a simple data path. I hit a key and the byte thatkey generates flows over just two cables (besides the keyboard cable):1. the cable from my text-terminal to my PC and 2. the telephone linecable to some other computer. Of course, the telephone cable isactually a number of telephone system cables and includes switchesand electronics so that a single physical cable can transmit manyphone calls. But I can think of it like one cable (or one link).
Now, let's count the number and type of electronic devices eachkeystroke-byte has to pass thru. The terminal-to-PC cable has aserial port at each end. The telephone cable has both a serial portand a modem at each end. This adds up to 4 serial ports and 2 modems.Since each serial port has 2 buffers, and each modem one buffer, thatadds up to 10 buffers. And that's just for one direction of flow.Each byte also must pass thru the minicom software as well.
Clear Serial Buffer Vb Net Worth
While there's just 2 cables in the above scenario, if external modemswere used there would be an additional cable between each modem andit's serial port. This makes 4 cables in all. Even with internalmodems it's like there is a 'virtual cable' between the modem and itsserial port. On all these 4 links (or cables), flow control takesplace.
Clear Serial Buffer Vb Net Present Value
Now lets consider an example of the operation of flow control.Consider the flow of bytes from the remote computer at the other endof the phone line to the screen on the text-terminal that I'm sittingat. A real text-terminal has a limit to the speed at which bytes canbe displayed on its screen and issues a flow control 'stop' from timeto time to slow down the flow. This 'stop' propagates in a directionopposite to the flow of bytes it controls. What happens when such a'stop' is issued? Let's consider a case where the 'stop' waits longenough before canceling it with a 'start', so that it gets thru tothe remote computer at the other end of the phone line. When it getsthere it will stop the program at the remote computer which is sendingout the bytes.
Let's trace out the flow of this 'stop' (which may be 'hardware' onsome links and 'software' on others). First, suppose I'm 'capturing'a long file from the remote computer which is being sentsimultaneously to both my text-terminal and to a file on my hard-disk.The bytes are coming in faster than the terminal can handle them so itsends a 'stop' out its serial port to a serial port on my PC. Thedevice driver detects it and stops sending bytes from the 8k PC serialbuffer (in main memory) to the terminal. But minicom still keepssending out bytes for the terminal into this 8k buffer.
When this 8k transmit buffer (on the first serial port) is full,minicom must stop writing to it. Minicom stops and waits. But thisalso causes minicom to stop reading from the 8k receive buffer on the2nd serial port connected to the modem. Flow from the modem continuesuntil this 8k buffer too fills up and sends a different 'stop' to themodem. Now the modem's buffer ceases to send to the serial port andalso fills up. The modem (assuming error correction is enabled) sendsa 'stop signal' to the other modem at the remote computer. This modemstops sending bytes out of its buffer and when its buffer gets full,another stop signal is sent to the serial port of the remote computer.At the remote computer, the 8-k (or whatever) buffer fills up and theprogram at the remote computer can't write to it anymore and thustemporarily halts.
Clear Serial Buffer Vb Net Promoter
Thus a stop signal from a text terminal has halted a program on aremote computer computer. What a long sequence of events! Notethat the stop signal passed thru 4 serial ports, 2 modems, and oneapplication program (minicom). Each serial port has 2 buffers (in onedirection of flow): the 8k one and the hardware 16-byte one. Theapplication program may have a buffer in its C_code. This adds up to11 different buffers the data is passing thru. Note that the smallserial hardware buffers do not participate directly in flow control.Also note that the two buffers associated with the text-terminal'sserial port are going to be dumping their contents to the screenduring this flow control halt. This leaves 9 other buffers that maybe getting filled up during the flow control halt.
If the terminal speed limitation is the bottleneck in the flow fromthe remote computer to the terminal, then its flow control 'stop' isactually stopping the program that is sending from the remote computeras explained above. But you may ask: How can a 'stop' last so longthat 9 buffers (some of them large) all get filled up? It seldomhappens, but it can actually happen this way if all the buffers werenear their upper limits when the terminal sent out the 'stop'.
But if you were to run a simulation on this you would discover that it'susually more complicated than this. At an instant of time some linksare flowing and others are stopped (due to flow control). A 'stop'from the terminal seldom propagates back to the remote computer neatly asdescribed above. It may take a few 'stops' from the terminal toresult in one 'stop' at the remote computer, etc. To understand whatis going on you really need to observe a simulation which can be donefor a simple case with coins on a table. Use only a few buffers andset the upper level for each buffer at only a few coins.
Does one really need to understand all this? Well, understanding thisexplained to me why capturing text from a remote computer was loosingtext. The situation was exactly the above example but modem-to-modemflow control was disabled. Chunks of captured text that were supposedto also get to my hard-disk never got there because of an overflow atmy modem buffer due to flow control 'stops' from the terminal. Eventhough the remote computer had a flow path to the hard-disk withoutbottlenecks, the same flow also went to a terminal which issued flowcontrol 'stops' with disastrous results for the branch of the flowgoing to a file on the hard-disk. The flow to the hard-disk passedthru my modem and since the overflow happened at the modem, bytesintended for the hard-disk were lost.
The device driver for the serial port is the software thatoperates the serial port. It is now provided as a serial module.From kernel 2.2 on, this module will normally get loaded automaticallyif it's needed. In earlier kernels, you had to have kerneldrunning in order to do auto-load modules on demand. Otherwise theserial module needed to be explicitly listed in /etc/modules. Beforemodules became popular with Linux, the serial driver was usually builtinto the kernel (and sometimes still is). If it's built-in don't letthe serial module load or else you will have two serial driversrunning at the same time. With 2 drivers there are all sorts oferrors including a possible 'I/O error' when attempting to open aserial port. Use 'lsmod' to see if the module is loaded.
When the serial module is loaded it displays a message on the screenabout the existing serial ports (often showing a wrong IRQ). But oncethe module is used by setserial to tell the device driver the(hopefully) correct IRQ then you should see a second display similarto the first but with the correct IRQ, etc. SeeSerial ModuleSee What is Setserial for more info onsetserial.
Clear Serial Buffer Vb Network
The serial port istoday (2011) sort of obsolete on PCs (and often called a 'legacy'device) but it is still in use on some older computers and is used inimbedded systems, for communication with routers and point-of-saleequipment, etc. The serial port is slowand after about 2005 most new PC's no longer had them. Most laptopsand Macs discontinued them even earlier. During the era when some newPC's came with serial ports and others didn't, the PC's that didn'thave serial ports were euphemistically called 'legacy-free'. However,while PC's today no longer have serial ports, some do have them builtinto a 'legacy' modem (which plugs into a telephone line). Such a serial portonly works with the modem and can't be used for any other device. Thereason they have such a 'built in' serial port is that analog modemsare designed to only work thru a serial port.
The physical serial port on the back of a PC (including the chip itsconnected to inside the PC), must pass data between the computer andan external cable. Thus it has two interfaces: the serial-port-tocable and the serial-port-to-computer-bus. Both of these interfacesare slow. First we'll consider the interface via external cable tothe outside world.
The conventional RS-232 serial port is inherently low speed andis severely limited in distance. Ads often read 'high speed' but itcan only work at 'high speed' over very short distances such as to amodem located right next to the computer. Compared to a network card,even this 'high speed' is actually low speed. All of the RS-232serial cable wires use a common ground return wire so thattwisted-pair technology (needed for high speeds) can't be used withoutadditional hardware. More modern interfaces for serial ports existbut they are not standard on PC's like the RS-232 is. See Successors to RS-232. Some multiport serialcards support them.
It is somewhat tragic that the RS-232 standard from 1969 did not usetwisted pair technology which could operate about a hundred timesfaster. Twisted pairs have been used in telephone cables since thelate 1800's. In 1888 (over 120 years ago) the 'Cable Conference'reported its support of twisted-pair (for telephone systems) andpointed out its advantages. But over 80 years after this approval bythe 'Cable Conference', RS-232 failed to utilize it. Since RS-232was originally designed for connecting a terminal to a low speed modemlocated nearby, the need for high speed and longer distancetransmission was apparently not recognized. The result was that sincethe serial port couldn't handle high speeds, new types of serialinterfaces were devised that could: Ethernet, USB, Firewire, etc.The final outcome was the demise of the serial port which due to it'sancient technology became obsolete for high speed uses.
Clear Serial Buffer Vb Net Server
The serial port communicates with the computer via the PCI bus,the LPC bus, X-bus, or ISA bus. The PCI bus is now 32 or 64 bits wide,but the serial port only sends a byte at a time (8 bits wide) which isa waste of PCI bus bandwidth. Not so for the LPC bus which has only a4-bit wide bus and thus provides an efficient interface. The ISA busis usually 16-bits wide and the efficiency is intermediate as comparedto efficient LPC and inefficient PCI.