Introducing the “Welcome to Xojo” Bundle!

New to Xojo and looking for guidance? We've put together a terrific bundle to welcome you! Xojo Bundle

This bundle includes six back issues of the magazine -- all of year 17 in printed book and digital formats -- plus a one-year subscription (beginning with 18.1) so you'll be learning all about Xojo for the next year. It's the perfect way to get started programming with Xojo. And you save as much as $35 over the non-bundle price!

This offer is only available for a limited time as supplies are limited, so hurry today and order this special bundle before the offer goes away!

Article Preview

Buy Now

Issue 3.3


Serial Programming For Beginners

Issue: 3.3 (January/February 2005)
Author: Aaron Ballman
Author Bio: Contrary to popular belief, Aaron gets let out of the Cave of Networking once in a while so he can work on Serial programming projects. While out of his cave, he likes to find new ways he can re-program his pickup truck using REALbasic's Serial control.
Article Description: No description available.
Article Length (in bytes): 21,985
Starting Page Number: 17
Article Number: 3310
Related Link(s): None

Excerpt of article text...

Have you ever wanted to write some software that interfaces with a physical device? For example, have you ever thought of writing a program that tells you why your "check engine" light is on? If you have, then what you want to do is some serial programming. This article is going to teach you the basics about serial programming, starting off with common definitions right through to how to structure and write your application using REALbasic.

Serial programming is the general term that is used to describe an application which communicates with a device via a serial connection. For example, if you want your application to talk directly to a modem so that you can establish a dial-up connection, or if you need to send control codes to a printer over a wire, you will be writing a serial application. The list of serial programming examples goes on and on, but all the examples have something in common which is the crux of what serial programming is all about: you are writing software that will talk via a wire of some sort to a piece of hardware.

Before we get into the topic of how to communicate between an application (also known as Data Terminal Equipment, or DTE) and a serial device (also known as Data Communications Equipment, or DCE), let's talk about what we mean by communication. Serial communications refer to the act of sending or receiving data one bit at a time. Each bit that you send is either on or off (though you will also see the terms space, 0-State and mark, 1-State to mean on and off, respectively). The speed at which you send and receive data is expressed in terms of bits per second(bps) or the baudot rate(baud rate). Each of these terms represents the rate at which you can transfer bits across the wire. Bits per second is simply the number of bits that you can send in a second. However, baud rate refers to the number of times a signal can switch from the on state to the off state in a second. Quite often these two terms mean the same thing since a bit is either on or off, but you should still keep in mind the distinction.

You may be wondering what I mean by "wire." The word wire is just a generic term used to describe the physical cable that is used for communications. It can be an RS-232 cable (which is a standard serial cable), a USB cable, etc. This article assumes that the wire used follows the RS-232 interface specification. There are really three different types of RS-232 specifications (A, B, and C), of which C is the most common. The only difference between the specs is in the voltages used to determine whether a signal is on or off. For RS-232C, the range of voltages is 3V to 12V to specify on (space), and -3V to -12V to specify off (mark). These voltages are only for the RS-232 spec; other specifications have other voltage ranges. Because of the voltages used for RS-232, the cable shouldn't be any longer than 25 feet long. There are 25 pins on an RS-232 adapter (which is why they are sometimes referred to as a 25-pin adapter), but only about nine of them are ever used. The serial port on the back of a typical PC is called a DB-9 adapter and uses the nine most common pins from the RS-232 interface and is another common device used when doing serial programming.

You transmit and receive data on pins two and three (respectively) and they are commonly known as the TXD and RXD pins. The TXD pin is used when sending data from your application to the serial device, and the RXD pin is used when the device sends data back to the application. The Data Carrier Detect(or DCD) pin is the eighth pin and is typically used by modems to detect whether a carrier is present. Basically, if the modem detects a carrier, then this line is asserted. The Data Terminal Ready (or DTR) pin is used to tell the serial device whether your application is ready or not. It is the 20th pin, and is usually turned on when your application first opens a connection to the device. If the pin is in the space state, then it is considered ready (and if it is in the marked state, it is considered not-ready). The next two pins are used to control the flow of data between your application and the serial device. Pin five is the CTS (or Clear To Send) pin, and when it is off, it means that your application can send more data to the serial device. Similarly, the fourth pin is the RTS (or Request To Send) pin. It is set to off by your application when you are ready for the serial device to send more data to you. There are other pins that do interesting things such as the sixth pin (Data Set Ready) and the 22nd pin (Ring Indicator). Some applications expect the DSR pin to be on before it will start sending data. The RI pin will be on when a ring tone is detected by the serial device and is typically only used with modems. Phew! That's a whole lot of information about the common pins and what they do. Now, to confuse the issue a bit... These pins don't always have the meanings that we just discussed. Some serial devices define a completely different set of rules for each of the pins than the standard ones you just learned about. This set of rules (along with some other bits of information we will be discussing shortly) is called a protocol, and when writing an application that talks to a serial device, you must always know the protocol. If you don't talk to the device using the correct lingo, your application won't work. The pin definitions are only a small part of the issue, and for the sake of this article, we will be assuming that the device you want to talk to follows the standard pin definitions.

...End of Excerpt. Please purchase the magazine to read the full article.