Does rs232 accept long data and char together?

[dxsdxs]

Hi, I have a program about motor control, which is connected with labview and pic16f88. I tried to use rs232 to send command by letter(char) and distance by number(int). This program can do the movement correctly, but I can't find a way out of giving the distance. For now it just moves in constant how can I give the number by “getc” while I need the command too. Does anyone have a good idea about that? I don‘t need an exact code, just some ideas or tips.
Thanks for any reply.

[dyeatman]

For numbers you have to perform and Int to ASCII conversion
before transmit then convert back on the other end.
_________________
Google and Forum Search are some of your best tools!!!!

[temtronic]

With any serial reception it's best to use an ISR and buffer. CCS provides a very good working example called ex_sisr.c in the examples folder.
You'll have to parse the data based on your input data format.

hth
jay

[gpsmikey]

You should convert all your information you are sending to ascii characters and unless you are very sure what the receiving side is doing, as a general rule, make sure they are in the printable range (if you send characters that are in the control character range (0x0D for example, the receiving side may think it is indeed a CR and deal with it that way instead of as intended. Even Microsoft got bitten with that one years ago with their backup utility to floppies - when it hit floppy 0x0d, it crashed the backup program). The digit 0 is 0x30 - you need to convert your data to ascii digits then convert it back again on the other end.

mikey
_________________
mikey
-- you can't have too many gadgets or too much disk space !
old engineering saying: 1+1 = 3 for sufficiently large values of 1 or small values of 3

[Ttelmah]

I think it may be worth elucidating a little:

The async serial connection just handles bytes (assuming you have 8bits selected). Nothing else.

What you 'do' with these, is down to you.

It is (for instance), possible to send the contents of a block of memory, containing numbers, strings etc., as just the 'raw' data from this memory, byte by byte. However the problem is 'what happens if something goes slightly out of sync'. So Just as a piece of paper, where you could draw loads of different hieroglyphic symbols, but the more complex these get the easier it is to misinterpret one, we tend to 'simplify' and use a limited set of standard symbols. Generally the English alphabet. The same happens in computer communication, with the commonest 'set' used, being ASCII (American Standard Code for Information Interchange). This gives every common letter/number in the alphabet, and some special 'control' values, standardised values. So '0' (the digit zero), has the code 0x30 etc.. So one could then send your 'character', and 'number', as codes 0x4E 0x30 0x31 0x32, which are the codes for "N012". Key thing is that serial receive programs understand these codes, so a program like Hyperterminal, would display N012 when these codes are received. Normally you'd standardise on certain things, so (for instance), it is common to separate values with commas, and end the line with a line feed or carriage return (codes 0x10, and 0x13). Now, 'C' contains a number of standard functions to convert internal numbers into 'ASCII' representations, and convert ASCII back.

printf("%Ld",variable);

will output the ASCII text representation of the decimal value of the 'long' number stored in 'variable'.

printf("%04LX", variable);

will output the same number in _hex_, with leading zeros.

There are several different format strings, and 'modifiers' (like 'L' for 'long'), and you really need to get a basic C textbook.

Then going to other way, there are functions like 'atol' (ASCII to long), which will take a string comprising a number of ASCII characters, and convert it to a 'long' to store in the PIC.

So realistically I'd say you need to do some very basic C reading, on the commands to convert to/from ASCII for output.input. The manual at the least.

Sending values separated using commas, is normally called CSV format, and I know labview can be set to handle this.

Now the earlier posters have basically said exactly what you have to do both to actually receive the data, and the key pointers for the translation needed.

Best Wishes

[SherpaDoug]

Your title says long data and you mention ints. I hope you realize that CCS ints default to 8 bits.
_________________
The search for better is endless. Instead simply find very good and get the job done.

[dxsdxs]

[dxsdxs]

[dxsdxs]

[dxsdxs]

[Ttelmah]

The key point here is that the PIC can only do one thing at a time.
Unlike 99% of modern PC's, there is no multiprocessing. The serial has less than two characters of hardware buffering, so what happens if data is arriving, while you are doing something else?. This is what ex_sisr.c handles. It allows you to expand the buffering using an interrupt driven circular buffer, so data is not lost, while you are doing other things. This is exactly how serial is handled on the PC, where there is a little more hardware buffering on modern chipsets, but it is still worth having more software buffering, so data is not lost while you are doing disk I/O, writing to the screen etc..
Your code still has to keep up, and still has to do the decoding, but if it falls behind a little, at places, the software buffer gives a little extra margin.

I doubt if any of the 'long term' professional programmers here design _without_ buffers....

Best Wishes