structs and serial?

Go To Last Post
13 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Howdy.

I've followed the tutorial for interrupt driven comms, and i have all that working.

Thing is i want to sent some int values from the pc to the micro.

Would it be possible to do it with structures?, eg

struct {
int value1;
int valu2;
} mystruct;

could i send this from the pc and have the micro recieve it?. If so how?

Thanks

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Assuming that its RS232 that you've got working, then you can send any data you like - 8 bits at a time. HOWEVER, be aware that sending raw int values isn't necessarily straight forward: the length of the int type may be different between the 2 environments, also the order of the bytes making up the int may also be different.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Convert your integer values to their ascii strings with sprintf() on the PC. Send down the RS232.
Receive the ascii strings and convert back to integers with gets() and atoi().

This is not at all efficient, but it is straightforward. You do not have to worry about integer width, endian-ness or whether the PC is using software flow control.

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

mhmm.

well i've had some success just sending 8 bit ints down (eg chars).

Problem is i really need 2. I've been trying to avoid using strings, as i'm scared they will be too slow. It needs to act 'real' time like from the pc.

(it's interfacing with live output from a game).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Perhaps your players have very fast reaction times.

Try doing the strings at 9600 baud, and see if you think this is too slow. You will be sending up to six characters instead of two. i.e. 6ms instead of 2ms. Not all integers will be 5 digit so you will possibly have a shorter wait. The two conversions could cost you up to 1us for the PC and 20us for the AVR.

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

lol not off players really, speeds of cars.

I'll give it a shot and see. (spose it's not bad cause pc side i already have things as strings, for debug purposes).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

On the sending side, send two bytes MSB first.
Use arithmetic to get them.
On the receiving side, receive two bytes MSB first.
Use arithmetic to combine them.
The tricky bit is the sign if the receiver
doesn't use 16 bit shorts or ints.
In that case,

extern unsigned char read();
unsigned hi, lo, val;
hi=read();
lo=read();
if(hi>=128) hi-=256;
val=lo+256*hi;

Iluvatar is the better part of Valar.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

beautrepp wrote:

Thing is i want to sent some int values from the pc to the micro.

Check the length of the int datatype in your PC environment if you aren't already specifying it e.g. by using datatypes such as int16_t.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

caviar wrote:
beautrepp wrote:

Thing is i want to sent some int values from the pc to the micro.

Check the length of the int datatype in your PC environment if you aren't already specifying it e.g. by using datatypes such as int16_t.

More importantly check the range of values you want to transfer.

Pick an appropriate data type at each end.
Find the bytes to send with arithmetic.
Send the bytes MSB first.
Receive the bytes MSB first.
Reassemble the bytes with arithmetic.
Using arithmetic allows one to ignore
the byte orders of the machines.
Using ASCII strings is a special case of this.

To avoid certain maintenance issues,
one might want to use a common header file.
It would include the range of values
and the sending and receiving data types.

Iluvatar is the better part of Valar.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
I've been trying to avoid using strings, as i'm scared they will be too slow

I'm with David on this one - stop and do a speed budget. To transfer a 16 bit int will involve two byte transfers if you send it in binary and up to 5 byte transfers if you send it in ASCII (plus a terminator). The advantage of ASCII is that human beings have some chance of quickly and easily seeing what's going on! (and there's no worries about byte ordering - you itoa() at one end and atoi() at the other). A 6:2 reduction in bandwidth may be worthwhile and if this slows things too much just consider upping from 9600 baud to 19200 or 38400 or whatever.

Cliff

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

sending binary numbers on serial between computers is commonly done with ASCII to avoid endian problems.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
sending binary numbers on serial between computers is commonly done with ASCII to avoid endian problems.

Certainly, endianness (is that a word?) is a consideration, but very few "real" protocols will tolerate the transmission time overhead. E.g., there are a LOT of ModbusRTU installations.

That said, I often use "ASCII Hex" in my apps to be able to "read" the transmissions. So 54321 decimal is 0xd431 and I'd send it "D431". It helps to make packets fixed-width, and the conversion routines are tighter/faster than internal binary==>ASCII and vice versa.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Quote:
I've been trying to avoid using strings, as i'm scared they will be too slow

I'm with David on this one - stop and do a speed budget. To transfer a 16 bit int will involve two byte transfers if you send it in binary and up to 5 byte transfers if you send it in ASCII (plus a terminator). The advantage of ASCII is that human beings have some chance of quickly and easily seeing what's going on! (and there's no worries about byte ordering - you itoa() at one end and atoi() at the other). A 6:2 reduction in bandwidth may be worthwhile and if this slows things too much just consider upping from 9600 baud to 19200 or 38400 or whatever.
Also, even at 38400, transmission time will dwarf computation time.
If 7 bytes (you might need a sign) is too slow,
you can find the two bytes to send with arithmetic.
Just don't use unions or pointer coercions to get them.

Iluvatar is the better part of Valar.