Hi Robert, I have many years of embedded development experience which naturally includes making PC's talk to hardware. I also have a contract development side business where one of my projects was developing an energy mgmt system for controlling/monitoring HVAC equipment in apartment buildings. PIC uC were used on the hardware side and Delphi on the PC side.
Microchip makes many variations of PIC uC's giving you a very wide selection of I/O and most have one or more 2-wire serials ports built in. This means that the part contains a uart which takes care of shifting in and assembling the bits into a byte. You can poll the port to determine when a new byte is available or run it in interrupt mode to be notified when the next received byte is ready or when its time to send. The ports use standard I/O pins on the device which means they are TTL level 0-VCC (typ. 5V). A PC's standard COM port implements RS323 which is a protocol standard that dictates both electrical levels as well as bit timing patterns. In RS232 a logic '0' is +3 to +15V and logic '1' is -3 to -15v. Typically you'll see +/-9V coming out of a PC. Therefore to connect a PIC to a PC you need some sort of level shifting circuit. The simplest solution is to use a Maxim MAX232 chip which is a TTL to RS232 driver/receiver chip. That will convert the TTL signal levels coming out of the PIC into RS232 which you can then connect directly to the transmit/receive pins on the PC COM port (Pins 2/3). Look at the Microchip (www.microchip.com) and Maxim (www.maxim-ic.com) websites. Both have many app notes available. If you go the PIC route, there is a great book I recommend called "Programming and Customizing PICmicro Microcontrollers" by Myke Predko published by McGraw-Hill ISBN 0-07-136172-3. It explains everything you would need to know about using and programming a PIC and includes a small section on interfacing with a PC. On the PC side, I use TurboPower AsynchPro which is now in public domain. There's a little learning curve, particularly if your going to be using doing pattern detection, running multiple serial ports simultaneously or running at very high speeds but in general its very easy to use and as I remember there are plenty of examples, and if you run into trouble just post some more questions and I or others will help you out. Alternatively, if you have MS Visual Studio or VB, you can install MSCOMM OCX and use it from Delphi (not sure what the licensing issues are if you're going to redistribute). It's probably a little easier to use than AsynchPro, but only a tad and no were near as sophisticated and capable. Last thing you need to think about is the messaging protocol between the uC and the PC. RS232 takes care of the how the bits are passed between the two; you need to develop a protocol for the message themselves. If you're only going to be talking to a single device and the electrical environment is clean and the baud rate is low (<= 9600) and you're only going to be getting data from the device when you ask for it, then you could simply get away with passing simple ASCII text between the two. For example, transit a letter 'G' (for Get) to the PIC and in return it would return a string of data terminated by a <CR>. As someone else already mentioned, depending on the type of data you're talking about, the PIC may have to convert it in a printable for such as hex. You could also have the PIC convert the data into human readable form. If the entire conversation between the PC and PIC is in human readable form, you could then use Hyperterm (included with Windows) as your sole communication tool and not have to do any PC programming at all. It's crude but definitely doable. Most sophisticated protocols involve passing pure binary data ($00-$FF) between the PC and the device. These protocols typically contain an envelope portion which controls message delivery and a payload section which contains the actual data being delivered. For example, a protocol I used in the HVAC system looked something like this: <SOH> <LEN> <DST> <CMD> <Opt1> <Opt2> .. <Optn> <CRC1> <CRC2> The <SOH> byte is $01. The PIC is running a state machine waiting for a message to appear on the cable it. Since the PIC could wake up in the middle of a message, it needs to know where the beginning of a message it and does so by looking for the <SOH> byte, ignoring everything else until it see's it. The <LEN> byte tells the PIC how many bytes to expect. The <DST> byte is an id of the device the message is intended for. This is applicable when there are more than on device hanging on the same communication cable. They're all listening (like a party line) and all see the same message but only the guy with the matching assigned ID actually responds to the message. The <CMD> byte is a command identifier and instructs the PIC code what to do. The codes and what they do is up to you but you might have something like: $00 = Reset $01 = Get Version $02 = Get Data $03 = Configure ... The <Optx> bytes are additional bytes are needed by the particular command. For example, the Configure command ($03) would probable take additional parameters which would be passed in these bytes. The <CRC> bytes are for data integrity. They could be a simple 16bit checksum or a more sophisticated 16bit CRC. The idea is that the PC calculates the CRC for the entire message and appends the bytes to the end. The PIC upon receiving the message recalculates the CRC based on the message received and compares its two bytes to the two bytes it received in the message. If they don't agree then it indicates that the message was corrupted during transmission. This could happen due to a hardware or noise problem. In either case, the PIC should not act on the message. Depending on the design, the PIC might send back an <ACK> ($06) character as an acknowledgement to the PC that it received the message correctly. Typically after sending the message, the PC would wait a second or so for the <ACK> to appear and if it did not, then either retransmit the message or declare an error to the user. Finally, after completing the command, the PIC would construct its own response message as above and send it back to the PC which would then verify the message integrity (via the CRC) and then parse the response. In the response message, the <CMD> byte would be a result code (such as $00=OK, $01=Failed, ...) and the <Optx> bytes would be optional result data. Without knowing your application I can't say which way it better but it sounds like you could probably get away with sending simple ASCII text back and for to start. Hope this has been helpful and not more info than you were looking for. Scott Kellish SoftSystem Solutions LLC [EMAIL PROTECTED] I have a contract development biz where one of my projects was -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Meek Sent: Sunday, July 23, 2006 9:44 AM To: 'Borland's Delphi Discussion List' Subject: RE: Serial Port and USB I/O...some additional OT questions in thisarea I was taking a look at Asynch from TurboPower...now Open Source...and it seems that it wouldn't be difficult at all to handle simple asynchronous instructions via a serial port or even USB w/serial adapter. My question has more to do with hardware than anything else. What I'm attempting to do is write my own program for handling very simple bio-feedback data. What this entails are one to x number of lightweight micro-volt sensors which are affixed by adhesives to various points on the body, ( usually the forehead, mandible, or temples, and in some cases fingers and/or wrists ). A battery operated computer board which I'm building from supplies readily available at Radio Shack, measures the changes in resistance between two or more of these paired contact sensors and emits a signal which I then wish in turn to read and show via visual and auditory feedback. This will be accomplished via a retentive scope-type display that plots a graph, a single point visual which moves up, down, left, and right, in its response to the same signals, as well as a user-set, continuous sound that travels up and down the scale in relation to the signal. The data will also be saved and stored as a stream in a local database for re-play and analysis. Secondary to its uses for personal bio-feedback will be the ability to provide variant wake level cues via sending micro-shocks back thru the sensors to the person's skin at pre-programmed and AI-controlled intervals, ( in response to dynamically measured sensor data ), for lucid dreaming experimentation, and pain control. Not being an electronics wizard myself, ( the most complicated electronic device I ever built was a specialized light-meter for measuring grey values as used in the Zone system during darkroom work on b/w photographic negatives ), I have a friend working out the hardware design for me. Unfortunately, he is has unknowledgeable about computers as I am in electronic control and measurement systems and so I need to find out the signal characteristics this hardware can submit via the serial port, as well as what it can expect in return! So I was hoping someone who has some experience with these areas might be able to contact me off-list and give me a few pointers in this area so that I can then in turn ensure the hardware handles the necessary signals. If so please contact me at the e-mail address below: [EMAIL PROTECTED] from Robert Meek dba Tangentals Design CCopyright 2006 Proud to be a moderator of "The Delphi Lists" at elists.org "When I examine myself and my methods of thought, I come to the conclusion that the gift of Fantasy has meant more to me then my talent for absorbing positive knowledge!" Albert Einstein -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mick Arundell Sent: Saturday, July 22, 2006 8:35 PM To: [email protected] Subject: Re: Serial Port and USB I/O Serial ports are/can be treated as files WriteLn(PortName, 'here, read this'); Mick > Date: Fri, 21 Jul 2006 15:48:43 -0400 > From: "Rainer von Saleski" <[EMAIL PROTECTED]> > Subject: Serial Port and USB I/O > To: "Borland's Delphi Discussion List" <[email protected]> > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset="Windows-1252" > > This is going to sound awfully stupid ... but I've searched the > Delphi help to no avail. > > How do I do I/O to/from a serial port? And/or to a USB device? > > I understand interrupt handlers, used them in Borland Pascal, so > they must be present somewhere. But I can't find them! > > Where do I look? Someone please get me started! > > Thanks, > Rainer > > > ------------------------------ _______________________________________________ Delphi mailing list -> [email protected] http://www.elists.org/mailman/listinfo/delphi _______________________________________________ Delphi mailing list -> [email protected] http://www.elists.org/mailman/listinfo/delphi _______________________________________________ Delphi mailing list -> [email protected] http://www.elists.org/mailman/listinfo/delphi
