Communicating between two microcontrollers

Hi,

what you ask for is called "protocol".

There are many standard protocols .. which you may use. Which one is suitable for you depends on your requirements.
If you chose a standard protocol .. you may be able to find a free library .. so you don´t need to write all the code on your own.

Klaus

KlausST said:

Hi,

what you ask for is called "protocol".

There are many standard protocols .. which you may use. Which one is suitable for you depends on your requirements.
If you chose a standard protocol .. you may be able to find a free library .. so you don´t need to write all the code on your own.

Klaus

Click to expand...

Thank you dear Klaus.
Could you please tell me some of them.(I mean protocols names)
And What do you mean "requirements"? Let me give you more details about project. each transmitting includes one byte and I want to send char, int and float types.

Also I need a protocol witch is independent of serial interface type. I mean all of USART, SPI and TWI support that.

Send your data in character streams, delimited with an ascii character
that separates a frame of data with each element in frame delimited
by, typically, a "," or some such ASCII character. So you would have a
start of frame character(s), and data separated by another ASCII char
of choice. Also typical is end of frame CRC bytes for validation of the
frame at receiving end.

Google "introduction to data frame"

An example protocol (in this case CAN protocol) :



In this case one can define what bytes in the data belong to what variable/value, and the receiving end
knows that construction and extracts the data elements. If one has variable length data then delimiter
characters simple to use. otherwise if the data is fixed length elements one creates a map on xmiting
end and receiving end know what that map looks like. The map being the frame construction.

This is a very broad topic with many characteristics and methods.

Hi,

I recommend you to read through some "what is a communication protocol" tutorials / documents / internet sites..

In short:
To communicate you need
* an interface: like mouth, lungs, tongue, voice, air, ears .. In your case: this is the UART
(Often UART is falsely named as a protocol)
* a protocol: For human communication it is the language: like English, Mandarin, Spanish ... in your

There are many languages ... each has it´s good and bad .. and it´s the same with data protocols: there are many, each with good and bad.

A data protocol describes the meaning of the bits, whole bytes, or a set of bytes ... but also some communication specifics like a pause.
Equivalent to: tones, letters, words, sentences, signs ..and pauses.

itsdifficulttoreadwithoutspaces
it´s more simple to read with spaces
bu tits mor ehar dtorea dift hespac esarea tthewr ongpo sit ions
(you see what I mean?)

***
Your requirements:
* transfer speed
* what different messages do you like to send?
For example one message could be a single byte. Like 0x41. Which means the integer value of 65 and maybe representing a temperature.
But with a single byte you are limited to 256 different values.
AND you get into trouble if you want to send 65 maybe for representing a voltage of 65V.

So in your case .. if you just want to send text to a 2x16 display ... then the simplest way would be to just transmit the 32 characters in a row (no gap inbetween) then send a pause of let´s say 50ms.

example:
This message needs to have exactly 32 bytes of data.

Klaus

added: Wikipeda list of automation protocols: https://en.wikipedia.org/wiki/List_of_automation_protocols
Not all are UART based!!

Fun fact:
Fro a mircorcontorler ti si alomst imossipble ot raed scuh scmralbed txet, btu hmunas acn. ;-)

danadakk said:

Send your data in character streams, delimited with an ascii character
that separates a frame of data with each element in frame delimited
by, typically, a "," or some such ASCII character. So you would have a
start of frame character(s), and data separated by another ASCII char
of choice. Also typical is end of frame CRC bytes for validation of the
frame at receiving end.

Google "introduction to data frame"

An example protocol (in this case CAN protocol) :

View attachment 194793

Click to expand...

Thank you danadakk. But there are two concerns. first if i need to do some process in my variables at destination microcontroller, changing variables to string is not suitable. Also it seems that a lot of bytes may need to be added to our main data.

Dear Klaus thanks a lot for your detailed and useful answer And also dear Danadakk.
Both of you suggested to convert data to string or characters. Danadakk suggested start and end characters and you suggested to use pause. OK very useful suggestions I will first study your links about protocols and also try to use pause and also delimitation characters to see the result.
But if in a project we need to do some process on our variables at the destination MCU we would not convert data to string and it seems better to use one of the standard protocols as you mentioned.
Best regards

Data can be converted to string and then back again at destination, thats just code
in C/C++. Extended libs have all those f()'s in them to make life easy.

Simpler if frame is fixed byte length variables, you place them in a sequence that your
destination pulls apart, to recover the numeric using pointer to read. Example, you have
a 4 byte float in data stream, you know its the n'th variable and how many bytes in frame
to its first byte. So you declare recv variable as a float, point to first byte, and read into
recv variable. It reads the 4 bytes as the float for you. This all works as long as data, each
element/variable, is always fixed in length, hence map of where it is in frame always same.
Otherwise strings and their conversion way to/from string way to go.

You still have CRC at frame end, and a sequence at beginning to denote frame start. CRC important
for error handling due to link error.

If you use a standard protocol for framing, design can be hacked easily. But most designs
do not care. Of course custom framing requires some effort to hack your design. Just a
consideration, one thats not minor in high security work, in an electronic tooth brush not
so much.


Regards, Dana.

Masoud85 said:

Both of you suggested to convert data to string or characters.

Click to expand...

No. I did not suggest it. I just gave an example.
I clearly wrote "if you just want" ....
* "IF" means I don´t know ... it can be or not
* "YOU WANT" means ... it´s YOUR decision what to transmit

Instead I recommended you to do some research on existing protocols.
AND I asked you to give what YOU want to transmit (your requirements. Your messages)

AFTER you gave your application informations ... we can give recommendations.

Masoud85 said:

But if in a project we need to do some process on our variables at the destination MCU we would not convert data to string and it seems better to use one of the standard protocols as you mentioned.

Click to expand...

Yes, this is the informatios you need to decide before we go the next step...
Take your time to find out waht you need. Tak e a piece of paper and a pencil ...

Klaus

Maybe I’m wrong, but this discussion seems to be heading off into the weeds. OP originally asked about distinguishing different types of parameters, and then people start talking about hacking and ASCII delimiters and toothbrushes.

Also, OP, you can’t send a float using “one byte”. And why do you have even different data types for different
parameters?

KISS

I’d suggest a protocol where you send, say, a 36 bit stream. First 2 bits identifiy data type (byte, float, etc.) . Next 2 bits identify parameter: frequency, voltage, etc. Last 32 bits are data . Maybe a checksum, if necessary. But maybe the parameter type and data type can be linked.

But, as previously said, you need to fully define exactly what you need.

OP Original post :

How can M32 explain to M8 that what is each data witch has sent? Imagine M32 sends frequency, voltage and other variables to M8 consecutively and repeatedly.

Click to expand...

Sure looks like a protocol discussion to me, and security and related issues, like error handling, certainly play in protocol design, or not.
My apologies mentioning the toothbrush was upsetting, I will stick to toasters in the future.

OH, NO! NOT TOASTERS!!

My point was, the OP asked how to distinguish different message content; they didn’t ask about security or checksums or any of that other stuff. This type of answer just clouds the issue.

OP is implementing a COM link, prudent to do error checking/CRC. And we dont know complete application,
what is being controlled (besides just LCD), is there a human saftety factor, equipment protection, best to
at least expose consideration and let OP decide if its pertinent. Same considerations on security. Give OP the
considerations, let them decide.

I think we agree to disagree.