Arduino UART Communication: Sending & Receiving Data from 10 Sensors (Digital & Analog) to LCD

Hello

I would like to do this: I want to establish communication between 2 devices after UART, e.g .:
Sensors> Arduino1> UART> Arduino2> LCD

While there is no problem with sending the command for Arduino1 to Arduino2 ... I don't know how to send variables ..

For example, I have 10 sensors, some output gives digital status 0 or 1 rest analog value.

I don't know how to send all data after UART and how to receive it so that it is clear which value comes from which sensor.

It seems to me that each sensor should be assigned a "name" send from Arduino1 after UART and simply cut it when writing to a variable in Arduino2, then send on LCD?

If there is something in it, I would ask for a link or a place where I can find information about trimming such a string, or how to look for it?


The data string may look like:

t1: 32.25 h1: 75.75 t2: 45.55 h2: 40.00 t3: 80.88 h3: 0 h4: 1

that is: temp1weigh

I would just like to send the data from the sensors remotely and display on another LCD.

best regards

You combine well. Develop your own protocol the way you like.

Equally, instead of values based on ascii, you can send bytes without tags t1, h1, etc., i.e. develop your own byte data frame, where you will know what each subsequent byte means. To such a frame you can also add a characteristic constant prefix (a byte or several) after which you will recognize the beginning of the frame and finally a byte of some checksum.

In such a frame, you can additionally reduce the number of bytes transferred by using individual bits for information that is only 1 or 0.


Instead of sending 8 bytes e.g. t1: 32,25
send two bytes with values 32 and 25
and because they will be the first two bytes after the prefix, you will know that it is the integer value and the decimal value of sensor t1, respectively.

The next bytes will concern the h1 sensor, ... etc.

I propose a format that I have successfully used for many years myself.
They are bytes separated by a special character - for me it is a colon.
for convenience when starting the message can be completed with some other character used only once.
the end of the message is standard for arduino \ n
stick binaries in bytes or wordy as you like.
Remember that analog measurements with decimal places can be sent without this decimal point and inserted into the value on the receiver side.
After receiving such a string of characters, I put the received numbers in the receiving table. array indexes correspond to the location of the number.
Do not unnecessarily send additional information what is what because it only slows down the transmission.

Once you've mastered it, you can start minimizing the amount of data sent, e.g. by switching to hexadecimal code, you can try to generate checksums and ultimately transmit data in binary.

ditomek wrote:

I propose a format that I have successfully used for many years myself.
They are bytes separated by a special character - for me it is a colon.
for convenience when starting the message can be completed with some other character used only once.
the end of the message is standard for arduino \ n

Binary and textual protocols are a terrible project. What if the byte has the character meaning of a colon?
Harmful advice.

ditomek wrote:

stick binaries in bytes or wordy as you like.

Can you say what you mean?

ditomek wrote:

Remember that analog measurements with decimal places can be sent without this decimal point and inserted into the value on the receiver side.
After receiving such a string of characters, I put the received numbers in the receiving table. array indexes correspond to the location of the number.
Do not unnecessarily send additional information what is what because it only slows down the transmission.

Once you've mastered it, you can start minimizing the amount of data sent, e.g. by switching to hexadecimal code, you can try to generate checksums and ultimately transmit data in binary.

You can't understand what you want to say. First you write "send bytes", then "to save space convert to hexadecimal" which doubles the volume. This is some gibberish.

I will add for ease that if you could distinguish numbers from numbers, and bytes from characters would make progress.

It's something like this:
255: 255: 255:
As you can see, there are bytes between colons but sent as text.
When you just start such a protocol, this presentation is the most convenient.
Then you can send 255 as FF - you save one character for three-digit numbers.
Similarly, if instead of single bytes you want to send two byte numbers like wordy etc.
Instead of: 65535: 65535: after the series you send: FFFF: FFFF:
Maybe now I will be more understandable

ditomek wrote:

It's something like this:
255: 255: 255:
As you can see, there are bytes between colons but sent as text.
When you just start such a protocol, this presentation is the most convenient.
Then you can send 255 as FF - you save one character for three-digit numbers.
Similarly, if instead of single bytes you want to send two byte numbers like wordy etc.
Instead of: 65535: 65535: after the series you send: FFFF: FFFF:
Maybe now I will be more understandable

It's not so beautiful. While if you send the whole thing as text, this colon has some sense (except that you can't tell the beginning of the frame), you can't convert it to a binary form. This is what JacekCz mentioned - what if the binary representation of a given data has an ASCII colon code?

ditomek wrote:

It's something like this:
255: 255: 255:
As you can see, there are bytes between colons but sent as text.
When you just start such a protocol, this presentation is the most convenient.
Then you can send 255 as FF - you save one character for three-digit numbers.
Similarly, if instead of single bytes you want to send two byte numbers like wordy etc.
Instead of: 65535: 65535: after the series you send: FFFF: FFFF:
Maybe now I will be more understandable

Stopgap. Nail the kennel to the curve of the shed. And that the shack has decayed boards, let's support it with a pole.

You combine some horrendous protocol, and therefore you combine that you haven't asked yourself elementary questions about what it really is (textual or binary), what is the "contract" between the transmitter and the receiver, for example, dedicated / universal use, the recipient is a machine or a human, etc.
Secondly, once again, "I will invent a better, more round wheel than others have invented." Thirdly, words are important, as one speaks imprecisely, one always makes imprecision (only one-way implication)

After many years, we add ideology to the practice curve, that's our nature.

In general, any well described protocol will do its job. It is best to create such a protocol from the beginning for your own device (contrary to appearances, it will not take much time), because then you can take into account the specificity of a given device (e.g. frequency of data transmission, amount of data), specificity of the transmission channel (bandwidth, reliability of data delivery, delays) as also your own preferences. It can be a protocol based on sending ASCII characters, but it can be based on sending binary values (I personally prefer the latter solution)

It's important to:
- the beginning of the data frame is easy to detect by the receiver (it can be a fixed start byte, 4-byte line break, etc.)
- easy-to-specify frame size - either explicitly (e.g. sent immediately after the start byte), or by defining the end of the frame (stop byte, 4-byte line break, etc.), or both at once.
- the correctness of the data in the frame is easy to check (checksum, according to the standard CRC algorithm or even the sum of all modulo 256 bytes)
- exactly described meaning of data bytes transmitted in the frame (location, size, range of valid values)

arturt134 wrote:

In general, any well described protocol will do its job. It is best to create such a protocol from the beginning for your own device (contrary to appearances, it will not take much time), because then you can take into account the specificity of a given device (e.g. frequency of data transmission, amount of data), specificity of the transmission channel (bandwidth, reliability of data delivery, delays) as also your own preferences. It can be a protocol based on sending ASCII characters, but it can be based on sending binary values (I personally prefer the latter solution)

Creating your own protocol is a very bad idea in 98% of cases. There are so many binary / text existing protocols that it is not worth creating another. Own protocol generally means problems with imple- mentation errors, lack of ready-made tools, integration problems etc. I do not recommend.

A proprietary protocol generally hampers the life of competitors .... Of course, sometimes devices must support standard protocols (e.g. Modbus), because these are the market requirements, but all service commands are sent in non-standard and implicit protocols. Besides, somehow I can't imagine implementing Modbus to send 4 bytes of data between two devices designed by me and not cooperating with other devices from other manufacturers. It's just using a cannon to kill a fly.

In the previous post I tried to clarify what a good transmission protocol should have. Instead of writing your own, you can take it ready, maybe my description will help in choosing the best one.

@JacekCz what your post is for You want to laugh at me or help a friend solve a problem.
I have the impression that you are more interested in the first one and do not understand why.
What I put in the post is just a fragment of what I have been successfully using in my projects for years. Does it irritate you that it works?
The full format is similar to modbus (I also use division into functions, data blocks and error checking) basically the only difference is the characters separating the fields and the way the checksum is calculated. And that the project is mine, I have no restrictions on the format.
Sure I could reach for a ready modbus library but then I wouldn't learn anything.
In addition, My protocol is more friendly because I do not use hexadecimal number coding and in any terminal emulator you can see what's going on.
This is really helpful during startup.
It is very convenient to process this data in python because there are ready functions for exploding data and placing them in an array.
In fact, you only need three lines of code.
But it would probably be better if I caught something from the others or reach for cash ... standard thinking of an arduin.
@tmf a colon separates fields, between the colon there are 1 to 3 "0-9" characters making up one number - exactly a byte
It is not possible that the colon will become a number because I send ascii characters. The beginning of the frame is from "=", the end is immortal \ n
I don't understand your fears.

grko wrote:

Creating your own protocol is a very bad idea in 98% of cases. There are so many binary / text existing protocols that it is not worth creating another. Own protocol generally means problems with imple- mentation errors, lack of ready-made tools, integration problems etc. I do not recommend.

Exactly
Right now, there is a thread about MQTT at uK next to the poem, I support it and I even read ambitiously, I couldn't help. The authors of the new implementation "forgot" to explicitly state that there is a limit to the number of variables.

ditomek wrote:

@JacekCz what your post is for You want to laugh at me or help a friend solve a problem.
I have the impression that you are more interested in the first one and do not understand why.
What I put in the post is just a fragment of what I have been successfully using in my projects for years. Does it irritate you that it works?

FIRST with any reliable protocol is a strict and full specification.
Specifications not offend, but amateur, it's a shot in the knee if you want to convince to the protocol.
edit: plus problems reported by colleagues.


As for faith, "works for me." It works in the hands of the author - we probably know it - still not enough, what is more, in the hands of the same author, when he returns to the project after a long time, in intuitively changed conditions (especially without documentation or with inaccurate documentation). The same person sitting down to the code from X years ago is basically like a second independent programmer, with all the resulting problems.

ditomek wrote:

But it would probably be better if I caught something from the others or reach for cash ... standard thinking of an arduin.

This is the essence of mature or professional software, use a recognized library THIS IS NOT A SHAME. there is some (useful) hardship in it, because you have to get into it, feel better than you do (sometimes you also have to have a critical opinion about it), etc.

I am not an arduinist and the style of doing "libraries" is a disaster.

I have my sociological observation. In the world of PHP / JS is the point of glory writing in your own way again, something that has repeatedly proven implementations. You can guess a lot about psychology, maybe it's too weak to understand the library extension points, APIs, etc. ... I feel undervalued, etc ...
In the Java world, such a programmer would be killed by laughter, a completely different style there.
As we are talking about sociology: in the arduino world one writes "I have such codes" which are pasted without understanding.

In conclusion: "write your own way" psychology occurs only in some IT segments

ditomek wrote:

@tmf a colon separates fields, between the colon there are 1 to 3 "0-9" characters making up one number - exactly a byte
It is not possible that the colon will become a number because I send ascii characters. The beginning of the frame is from "=", the end is immortal \ n
I don't understand your fears.

You mix. If the protocol is completely based on ASCII then there is no problem. You wrote that you can send this data in binary form - you can't do it without special solutions. Currently, we have ready for almost every occasion and the only thing you need to do is choose the right existing protocol that best meets our expectations. Inventing the wheel again brings nothing.

Added after 5 [minutes]:

arturt134 wrote:

A proprietary protocol generally hampers the life of competitors .... Of course, sometimes devices must support standard protocols (e.g. Modbus), because these are the market requirements, but all service commands are sent in non-standard and implicit protocols.

Supporter of "Security through obscurity"? It has been laughed at many times. You will clear a sensible protocol once, the introduction of weirdos will be more difficult for the author of the project than for the person who wants to disagree. You need to make life harder for your competition - from this you have protocols with data encryption, authentication, etc. Ready solutions have at least security analyzes done. In an author's solution, it is usually the case that the author believes in the security of his solution, without having any evidence for it.

There is only one right way.

Each case is different and one cannot claim to be one protocol or another. The designer decides about this fact, because only he has full information about the project, including the restrictions it must overcome. Therefore, in one case he will decide to use ready-made protocols, and in another he will create his own.

The argument that there is a lack of ready-made tools, while the programmer is fluent in C (or other universal) is unsuccessful because he is able to write his own tool quickly. Similarly with implementation errors.

Therefore, let's finish the discussion in this area, focusing on prompting the author who has not spoken yet.
In addition, the author is a beginner and it is worth helping him create his own protocol to broaden his skills, which in the future will allow him to consciously choose the optimal solution for each subsequent project.

@tmf I do not mix, I wrote to the author that after mastering the art of sending messages, ascii can switch to binary transmission.
Read my post again and I'm sure everything will be clear now.
In fact, maybe I used too many mental shortcuts and now I have to explain everything ...
for me EOT

Thank you very much for the hints - for the moment I have to let go of the topic ... if I find a moment I will come back to it and probably if something does not work I will ask
Thank you so much again.

Instead of renting a wheel, use e.g. http://www.billporter.info/2011/05/30/easytransfer-arduino-library/