|
|
View previous topic :: View next topic |
Author |
Message |
Michael__ Guest
|
Communication PC --> external device |
Posted: Wed May 17, 2006 10:09 am |
|
|
Hi to all !
I have problem with understanding how this process works.
Hardware: serial port
Chip:16F913
Idea:
Building user interface on PC for direct communication with external device.
What i have:
working serial (rs232) communication with CHIP --> PC.
The external device have to check some state ( full, empty ) and display this diagram on user PC. This is not the only thing that user will be able to do. Maybe the best example for such interaction would be some printer program.
My job is to program the chip, make data transfer and to make the GUI on the PC. So i have problem with understanding, or better with organisation.
Which data should be passed from PC to CHIP and other way around etc.
Thanx in advance! |
|
|
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Wed May 17, 2006 10:42 am |
|
|
One common way to do this is to use Visual Basic to create the Windows
application program. VB has serial port functions which you can call
to talk to the PIC. You can buy VB6 on EBAY, or I suppose, you could
use a later version. I've never used the .Net version.
Then you can create your own simple communcations protocol to
communicate with the PIC. Send a certain command byte (that you
define) to request information from the PIC. Then receive the bytes
from the PIC.
It's easier to debug the communications protocol if all messages are
sent in ASCII characters. Then you can see them on a terminal program. |
|
|
Ttelmah Guest
|
|
Posted: Wed May 17, 2006 10:49 am |
|
|
You don't really give enough information (timescales involved, update speeds required, any 'emergency' handling etc.), for a full reply, but consider two scenarios:
1) The remote device sends a 'packet', containing the information it is currently reading, at a standard interval (perhaps once per second). The 'packet', comprises the actual 'data' (perhaps a 'level' reading, and some status data), as text, possibly comman deliminated. This makes the packet easy to read at the PC end.
2) Basically the same, except that the packet is sent 'on demand'. The PC sends a 'request', and the remote device replies.
The former, is how GPS position data is sent using the NMEA standard, from GPS units. The latter is how 'status' information is sent by modem units.
Both allow you to detect connection being present (if a packet is not seen within a couple of seconds, display a 'communication failure' message). The latter is better if there is a lot of data, with varying degrees of 'urgency', where you can send different requests, to read the things that need quick updates, and just occasionaly ask for the other data. The former is simpler, especially where all the data has similar importance.
A 'printer program', sounds like a poor example, since 99% of the communication in this case, is from the PC to the printer, with only very limited replies.
I'd look at the GPS approach, and send a simple 'text' message, with something like:
LEVELxx,INyy<LF>
In this case a 2 character value for 'level', and another, corresponding to some inputs.
Best Wishes |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|