How to get limitless data with UART

[Zek_De]

Hi guys ,I want to get data respectively throttle and direction with Uart ,device to device.How can I manage or do you have a library

[temtronic]

Simple, use an serial ISR with buffer. I suggest looking at the CCS supplied ex_sisr.c in the example folder.
I'd need a LOT mor einformation to guide you though.
Jay

[Ttelmah]

That is just basic comms.

What resolution are you going to send?. So (for instance) 0 to 99 for the throttle. If you are going to always include 'direction' with every transmission, consider just sending a signed value. A single byte signed int8, could give you -128 to +127 for reverse/forward.
If you are later going to want to send other data on the same link, then you'd need a 'marker' to say that this is the throttle setting.
If the link is potentially 'noisy' (most radio links etc., are), then some form of error checking. Could just be to send the byte twice, the second with the bits inverted. If the two values don't match, reject the data.
There is not going to be any 'library' for something like this, since it is totally down to what you want to do. You have the built in code to handle the UART for you.
If it wants to be 'human readable' as well, then just send as ASCII text.
Something really basic and easy to interpret, would be 'TxxC/n"
'T' for 'throttle'. XX two hex digits giving a signed int8. C a single checksum character (consider the XOR of the two previous nibbles), then the line feed. Very easy to interpret. Has reasonable error detection (any single bit changing can be detected - you just XOR the three nibbles together and if the result is not zero the data is invalid). Makes it easy to add further commands later.

[temtronic]

What is not known are the 'devices'. Those will determine what kind of code you have to cut.
Assuming the PIC is in between (device 1<>PIC<>device 2), it just has to move data from one device to the other ? Or both ways ? Simple, easy, basic PIC101 stuff however it's all in the details, like the format and speed of devices UARTs, handshaking, does the PIC have to parse and translate the 'datastream'.
No mention of what hardware yet, but I'll suggest the PIC18F46K22 as the PIC to choose as it has 2 hardware UARTS and LOTS of memory, both code space and RAM. Whatever PIC is chosen it should have 2 hardware UARTS !
Hmm.. 'UART' is kind of a 'generic' term for serial communications with a tremendous number of options or variations. Then there's the actual 'interface' requirements. Are they both TTL ? Maybe one is true RS-232, the other some unique MFR format ?
So ...lots of questions ! More details of the devices is necessary and what is required for the PIC to do.
The more you supply, the better we can guide you.

Jay

[Zek_De]

Thanks for replies,

[Zek_De]

I am still confused.

TxxC\n

first -> \n is necessary?

second ->How is algorithm necessary at receive side

if(a[0] == 'T)
{
get xx
}'

In this case what does it do C here

[temtronic]

You really need to look at a few of the 100s of examples that CCS supplies in the 'examples' folder, some in the manual as well as those in the 'code library' (the other forum) here.
As well you need to start off with a '1Hz LED' program. This will confirm your hardware (PIC, programmer, test bed, etc.) are all working.
Don't worry about your final program until you get the basics up and running.

Jay

[Ttelmah]

I'm afraid you have a lot of learning to do.

I was suggesting this as a very basic protocol.
The /n marks the end of a line, making it easy to know 'where you are'.
The C is the checksum. As already explained, unless the line is 'perfect', it is always worth having some way of testing if the data is right.

As Temtronic says, you have a huge amount of really basic learning to do first. Walk before run.

[Zek_De]

But I need get value respectively 4 byte. I am thinking it, this always seems random data receiving, as a result this is asynchronous, if I lucky it will come respectively.

[temtronic]

show us exactly the data you expect to get, what the 2 devices are.
It's -20*C here so I don't mind helping..heck I'd code it all for you IF you'd come here and shovel my 4 car driveway for me !

[Ttelmah]

It is nothing to do with the data being asynchronous. It is to do with your data needing a structure.
That is what I was suggesting. You need to design a _protocol_. A format that allows you to work out 'where' you are in the received data. This is the point about using text and a line feed as a terminator. You can then look through the data for this and work out work out what things are because of their relationship to this marker.
Language requires syntax. You can't just send values and assume the receiver will always keep in sync.

[temtronic]

re:

[Ttelmah]

I have a 'nasty' suspicion, that 'limitless data' here is undelimited data.
If so, the poster needs to 'think again'.

If you send 'raw' data without any form of delimiter, then it is possible to get it working 'sometimes', and 'for a while'. However as soon as even one glitch occurs in the comms, you have no ability to know this has happened, and no ability to recover. Result. Garbage. Even worse, since devices will switch on at different times, it may well be impossible to even start successfully receiving. This fits with what he is describing.

The key point about a 'protocol', is to add the parameters to make such recovery possible.

I also suspect he is probably sending much larger values than are really needed. A throttle position for example is unlikely to really offer accuracies warranting using an int16.

[temtronic]

hmm.. English is such a 'fun' language,kinda wonder how anyone actually learns it let alone understand it !
If Mr T is right, the datastream may be
.....TtPpTtPpTtPp.......
where
T is the 1st byte of throttle data
t is the 2nd byte of throttle data
P is the 1st bytle of position data
p is the 2nd byte of position data

IF this is true, there is NO way of decoding the datastream into 2 correct 16 bit variables.

However IF there IS a pause or slight delay between the data, say,.
...dTtPpdTtPpd.....
then it is possible to 'sync' and decode the datastream. 'd' has to be a consistant delay,say 2x the bit width of the data.My remote energy control systems use this technique for the past 30+ years communicating over 15 MILES of copper wire so I know it works, very reliably.

We still need for information though,happy to help if I can, and I do like a challenge !

Jay

[Zek_De]

Guys thanks to all information. Here is 16.30, I couldn't write yesterday because of I dıd sleep. I read all writing and so helpful for me, now I will work on it and I will show the results. Jay said about signed or unsigned. I want to use to send 'sprintf' and my values int16.