Interfacing PIC to PC

[serially100]

At the moment I have a PIC in a circuit where it's monitoring faults (the outputs of various comparators) and lighting LEDs when a fault occurs.

However, i want to get rid of the LEDs and serially send the fault "byte" to my PC and program it to display the fault in a window.

I will obviously have to do some programming to get the PC to read bytes in at an input port, and display the relevant response on the screen.

I am wondering if anyone knows of the most simple and suitable PC program for this?

I hear that Visual Basic is good for this but wondered if there were better ideas? (I am using Windows Vista Home Premium Operating System.)

 

[itsmoked]

You are probably screwed then and will have to use VB. VB while huge, and weird, is pretty easy to use.

Does your computer even have a serial port?

Keith Cress
Flamin Systems, Inc.-

http://www.flaminsystems.com

 

[geekEE]

I agree that VB would be pretty easy to use.

Is this for an application that an end-user will see or is this just an application for some in-house debugging? If it's just for in-house, you can just output entire strings to the serial port and use HyperTerminal to display them. Alternatively, I've used the VBA, which is built into Excel to read the serial port and display results.

Oh, and if you don't have a serial port on your computer, there are some USB to serial adapter cables from FTDI (available at Digi-Key) that should work. There's even one with TTL inputs so that you don't need to have an RS232 transceiver on your PIC board (although you probably already do).

 

[geekEE]

Oops. I meant to say those FTDI cables are available from Mouser, not DigiKey.

 

[MacGyverS2000]

The FTDI cables are also available online for <$10

Dan - Owner

http://www.Hi-TecDesigns.com

 

[itsmoked]

Go to my site.
Go to downloads.
Download MTTTY.

Never use Hyper terminal again..

Keith Cress
Flamin Systems, Inc.-

http://www.flaminsystems.com

 

[GonzaloEE]

Just complementing the good suggestions already posted.
If you feel like programming, you may try VB, C or Java to build you own customized PIC GUI apps.
I used to debug modems with a simple VB app I just coded some years ago. Script files with AT-commands could be downloaded to the modem, and responses were formatted either in TXT, CSV or Excel (HTML tables, actually). The VB Comm Module may help you on arranging some ‘smart’ dialogues between PIC and PC.

The same could be done with C and Windows APIs for COM control and setup. You can work with all lines, even using DTR, DSR or RTS as alternative communication ports.
Windows APIs let you managing COM ports like any R/W file, using functions with self-explanatory names like fopen, send, receive, close, etc.
I/O files are treated the same way, so you can download script files to your PIC, or upload log files from your PIC to your PC. I’ve used the lccWin32 compiler and COM API functions from their API help. Keith’s MTTTY looks like a great option to avoid messing with C, anyway.

I’ve also used the old Hyperterminal for years as a quick debugging GUI, while the uC takes care of all text ‘make-up‘. Some ASCII characters are well-known: Care Return=13, Line Feed=10, etc., though you can also clear the console with ASCII 12d, get tabulated data with ASCII 9, or even beep the PC buzzer with ASCII 7.

I agree FTDI is an excellent tool for faster data rates, real-time monitoring or the like.

Good Luck!

 

[serially100]

Thankyou for these excellent replies. I am in the process of looking into all of them, and thankyou for your download, itsmoked, which now sits on my PC, with me experimenting with it.

As well as sending bytes to a PC and getting the PC to interpret them and display fault information, I also want to hook up voltmeters to my PC so that I can read multiple volt readings straight onto the PC, and display them in a table in a window whenever I click a button.
-This has come about due to problems recording multiple volt readings with a pen and paper....

....due to a recent problem where various voltages had to be taken to enable a designer to tweak up circuit components.....the designer saw no "pattern" in the voltage readings and so could not engineer a modification of circuitry -and resorted to insisting that the tester must have repeatedly recorded readings incorrectly.

Since I have found the following book on Visual Basic which appears to address these problems, I am going for that at the moment……

“Visual Basic for Electronics Engineering Applications 5.0, 6.0, VBA, .NET, 2005”


Also, I have downloaded a free Visual Basic 2005 Express Edition from….

http://www.microsoft.com/express/2005/download/offline.aspx

 

[itsmoked]

You are welcome. Use it to your health!

Read voltages? Get a good little USB oscilloscope! They will let you record the voltages AND show you the actual patterns.



Keith Cress
kcress -

http://www.flaminsystems.com

 

[dastechnik]

alternatively, you can test to start those small interfacing programs using liberty basic language, it looks like VB code but easier, you can test the evaluation version @t

http://www.libertybasic.com/

 

[richs]

Hiya-

I've recently gone to mingw which is a minimal port of the gnu C complier for the windows o/s. I've had good luck with programming the serial port with it. It's a free, as in beer, compiler and pretty easy to set up.

One of the nice things is that I can whomp up an app in C, and form an executable. I can take the executable and go from an XP version of windoze and take the same executable onto an windoze 98 box. Some of the other gnu ports required dragging along libraries with it. I used to use DJGPP (google if interested), but dragging along the run time files wasn't fun.

The lcc-win32 looks nice, but the web site states that you need a license to use it commercially. Being a good software citizen I wouldn't want to use the free version for commercial operations........

Just a little tid-bit of information. Hoping it will help.

Cheers,

Rich S.

 

[MacGyverS2000]

Not specifically PIC related, but for years we've been using CodeVision for most of our embedded development work on various Atmel processors. After running across a bug or two that were not handled properly (IMHO), a buggy IDE with some odd quirks, etc. we just recently decided to slowly shift over to the free GCC tools under Atmel's free AVR Studio... so far, I've been much happier.

The AVR Studio IDE still has some quirks to it, but I expect that from a free product, and the compiler hasn't let us down yet. It also handles the ELF file format, which includes processor fuse settings in the hex file, something CodeVision could never seem to handle... no more documentation specifying what fuses to burn, giving manufacturing a chance to make a mistake, now it's all in the code (PIC allows the same thing).

Dan - Owner

http://www.Hi-TecDesigns.com

 

[itsmoked]

Nice info guys!

richs; Please tell me C not C++?

What about Puketa, (I mean Vista)? Any chance gnu C works with that?

Keith Cress
kcress -

http://www.flaminsystems.com

 

[GonzaloEE]

To get something up quickly, you may try:
- Hyperterminal, and stdio.h resources (printf, putch, etc.) on PIC
- VB applet to format raw data from PIC USART
- Java applet with serial library included, to do the same above.
Good luck.

 

[MacGyverS2000]

To get something up quickly, you may try:
- stdio.h resources (printf, putch, etc.) on PIC

You've never programmed in C for a small processor, have you... ;-)

The stdio library alone will often eat up 20-30k of memory, not something useful when the processor only has access to 4-8k total.

As the OP suggested, sending a handful of bytes using a custom protocol is the proper way to go with this one.

Dan - Owner

http://www.Hi-TecDesigns.com

 

[richs]

To itsmoked:

Sorry for the lengthy time to reply. I've been "critical path" with code that I didn't write for a couple of months now and haven't been able to get back here.

Right now, I'm doing some "run test times" so I have a second!

Mingw that I use is good old C, not that new 'fangled C++ stuff.

From the website:
"MinGW refers to a set of runtime headers, used in building a compiler system based on the GNU GCC and binutils projects. It compiles and links code to be run on Win32 platforms... providing C, C++ and Fortran compilers plus other related tools."

Hummmmmm, Fortran. Wasn't there a thread around here about Fortran?

Anyway, no thank you to C++. All the overhead with the constructors and destructors makes it a no joy for real time programming.

It might have some uses with a multi programmer situation with the code and data modularity. On that subject, I'm faced with code that crosses functional modules all over the place, so a little enforced modularity would have been good, although with a PIC, C++ wouldn't cut it. Have to be enforced by the programmer...... But I digress.

No, I use good old C for the mingw stuff.

Cheers,

Rich S.

 

[itsmoked]

Great Rich! Good to know. Good luck on your project.

Keith Cress
kcress -

http://www.flaminsystems.com

 

[GonzaloEE]

macgyvers2000, I've used stdio with Hitech PICC compiler for years with PICmicros of down to 8K ROM. Of course it's a reduced version of standard stdio. Instead of stdout, the compiler lets you call your own custom putch/getch routines to cue the uC UART, so things like:
"printf("temperature %f\r\n",Sample);" are possible with a PIC16F886 of just 8KB. Great for quick debugging with Hyperterminal.

20k-30k stdio? maybe for ARM and up