CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to support@ccsinfo.com

How to get limitless data with UART
Goto page 1, 2  Next
 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
Zek_De



Joined: 13 Aug 2016
Posts: 100

View user's profile Send private message

How to get limitless data with UART
PostPosted: Thu Dec 28, 2017 7:56 am     Reply with quote

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



Joined: 01 Jul 2010
Posts: 9081
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Thu Dec 28, 2017 8:17 am     Reply with quote

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



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Thu Dec 28, 2017 8:20 am     Reply with quote

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



Joined: 01 Jul 2010
Posts: 9081
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Thu Dec 28, 2017 10:14 am     Reply with quote

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



Joined: 13 Aug 2016
Posts: 100

View user's profile Send private message

PostPosted: Thu Dec 28, 2017 11:18 am     Reply with quote

Thanks for replies,
Quote:
Something really basic and easy to interpret, would be 'TxxC/n.

This is good solution for me, I examine this.

By the way my direction and throttle are int 16

You guys are the best.
Zek_De



Joined: 13 Aug 2016
Posts: 100

View user's profile Send private message

PostPosted: Thu Dec 28, 2017 11:52 am     Reply with quote

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



Joined: 01 Jul 2010
Posts: 9081
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Thu Dec 28, 2017 11:57 am     Reply with quote

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



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Thu Dec 28, 2017 12:48 pm     Reply with quote

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



Joined: 13 Aug 2016
Posts: 100

View user's profile Send private message

PostPosted: Thu Dec 28, 2017 1:36 pm     Reply with quote

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



Joined: 01 Jul 2010
Posts: 9081
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Thu Dec 28, 2017 2:12 pm     Reply with quote

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



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Thu Dec 28, 2017 2:14 pm     Reply with quote

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



Joined: 01 Jul 2010
Posts: 9081
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Thu Dec 28, 2017 6:26 pm     Reply with quote

re:
Quote:
my direction and throttle are int 16

Signed or unsigned ? For direction it could make sense that the variable is signed, for throttle unsigned is the logical choice.

We still have zero information as to the format the data is being sent from 'device 1' and the hardware involved. UART means Universal Asynchronous Receiver Transmitter, it does NOT say HOW this is achieved. While some feel UART means a device configured for 8 databits, 1 start, 1 stop, 9600 baud, using RS-232 logic levels (2 states), in my energy control systems I use 22 bits, 2 start, 1 stop, 22 baud using +-60 volt logic levels (three states).
To help any further we need to know the 'device 1' and 'device 2' specifications. Make/model /product numbers.....
I understand English is not everyone's first language but the more you tell us the easier it is for us to help
Jay
Ttelmah



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Fri Dec 29, 2017 3:27 am     Reply with quote

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



Joined: 01 Jul 2010
Posts: 9081
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Fri Dec 29, 2017 6:37 am     Reply with quote

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



Joined: 13 Aug 2016
Posts: 100

View user's profile Send private message

PostPosted: Fri Dec 29, 2017 7:17 am     Reply with quote

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.
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
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