0:12
if you are a subscriber to my channel
0:14
you might have already found out that
0:16
soon I am going to start the modbus rtu
0:21
I have also created a playlist for the
0:23
same and here are some videos for you to
0:25
understand some Basics about the modbus
0:29
these videos are from some other Creator
0:31
and it explains very well what the
0:33
modbus is and why it was developed in
0:37
if you are interested in modbus do check
0:40
out these videos and I am going to skip
0:43
the basic explanation about it
0:45
I am going to use the rs485 for the
0:48
modbus communication and this is why
0:51
today's video is kind of related to
0:54
today we will see how to use the rs-485
0:58
to TTL converter with our
1:01
so what is this rs-485
1:04
to put it in simple words just like
1:09
rs-485 is a protocol for serial
1:13
compared to rs-232 it is faster and can
1:17
be used for data transmission over
1:19
longer cable lengths and in noisy
1:23
since the stm32 microcontrollers do not
1:26
support the rs-485 communication we will
1:30
use the rs-485 to TTL converter
1:33
this converter uses the max 485 chip and
1:37
converts the TTL signals to rs-485 and
1:43
the converter has pins A and B here a is
1:47
the non-inverting pin and B is the
1:49
inverting PIN say for example if the
1:52
chip is powered with 5 volts and we are
1:55
sending 0 cross 9 5 Via the uart
1:58
the max 485 chip will amplify each bit
2:02
and this is how the output on the pins A
2:04
and B is going to look like
2:07
notice that pin a is a non-inverting pin
2:10
so the signal on it is either zero or
2:15
on the other hand pin B is an inverting
2:17
pin so the signal is either 0 or minus 5
2:22
now when this data is received by
2:25
another module it will interpret a zero
2:27
or one based on these differences
2:30
if the voltage difference is maximum
2:32
between the pins it's a 1 and if the
2:35
difference is zero the bit is also zero
2:38
I hope you understood how communication
2:41
works now let's talk about the
2:44
this is how the connection looks overall
2:47
I have two mcus which are connected via
2:51
the two rs-485 to TTL converters
2:54
let's dig deep into this
2:57
picture shows the pin out of the module
3:00
on the right side we have the VCC ground
3:07
the pins A and B must be connected to
3:10
the similar pins on the other module
3:13
you can see the connections between the
3:15
corresponding A and B pins
3:18
I have already explained the purpose of
3:22
on the left side the pin Ro which stands
3:26
for receiver output must be connected to
3:28
the RX pin of the MCU
3:31
the Pindi I driver input is connected to
3:35
the TX pin of the MCU
3:37
the pins are e and d e are connected
3:42
IE stands for receiver enable it enables
3:45
the module to receive the data
3:48
but this is a low enable that means we
3:51
must pull the pin low in order to enable
3:55
similarly d e which is driver enable
3:58
enables the module to transmit the data
4:02
since this is a high enable pin we must
4:05
pull it high in order to enable the
4:09
so in order to transmit the data that a
4:12
pin must be pulled High and the re pin
4:16
similarly to receive the data the re pin
4:20
must be pulled low and d e pin also
4:24
this is why both the pins are tied
4:26
together so pulling either one of them
4:29
will also pull another pin to the same
4:32
this is the connection between the MCU
4:37
the RO pin is connected to the pier 10
4:42
the DI pin is connected to the pa9 the
4:48
and t e and r e are connected to the pin
4:51
pa8 which we will set as the output
4:55
the connection will remain similar with
5:00
let's start the queue IDE and create a
5:07
stm32f103 controller give some name to
5:11
the project and click finish
5:13
first of all we will enable the external
5:15
Crystal for the clock
5:17
the board has eight megahertz Crystal on
5:20
it and we will run it at maximum 72
5:24
then go to sys debug and enable serial
5:29
set the time-based source to systic also
5:32
now go to connectivity uart one and
5:36
enable the asynchronous mode
5:38
you can see here the pins peer 10 and
5:41
pa9 are enabled as the RX and TX pins
5:46
let's keep the board rate at 11 5 200.
5:50
we have 8-bit word length no parity and
5:55
let's go to the interrupt Tab and enable
6:00
we will use the interrupt to receive
6:04
this is it for the uart now we will set
6:06
the pin pa8 as the output pin
6:10
this is where the r e and d e pins will
6:13
be connected I am naming this pin as the
6:18
click save to generate the code
6:21
let's first create the TX and RX buffers
6:34
inside the main function we will call
6:37
the receive to idle function in
6:40
if you have been watching this channel
6:42
you know what this function does for the
6:45
rest of you guys I will leave the link
6:47
to the video in the description below
6:50
basically during receiving if the uart
6:53
sees the line idle for some time it
6:55
triggers the interrupt
6:57
this interrupt eventually calls the RX
7:00
event handler function
7:02
we will copy this event handle in our
7:04
main file and inside it we will restart
7:09
Hull disables the interrupt after one
7:12
call so we need to enable it again
7:15
now we need to send the data to the uart
7:18
so that it can be transferred via the
7:21
let's first create an index variable
7:25
we will continuously transfer the data
7:29
first we will copy this string to the TX
7:34
this string will always have the updated
7:36
value of the index variable
7:39
then we will call the function send data
7:42
to send this string to the uart
7:44
we will Define this function later
7:47
and this process will repeat every one
7:53
now let's define the send data function
8:03
as I mentioned in the beginning the r e
8:05
and d e pins set the module as receiver
8:10
before sending the data we need to set
8:13
this module as a transmitter and to do
8:15
that we have to pull the de pin as high
8:18
so here first of all we will set the TX
8:25
then we will transmit the data via the
8:29
and again we will pull the pin low so as
8:32
to enable the receiver mode
8:35
basically the module is always in the
8:38
receiver mode because we don't know when
8:40
the data might arrive
8:42
just before we send the data we put it
8:45
in the transmitter mode and after
8:47
sending it goes back to the receiver
8:50
we need to include some header files for
8:52
the S printf and the string length
8:56
all right everything is fine now
9:01
f446re as the second controller which is
9:04
connected to another module
9:07
the code used is exactly similar to the
9:11
here is the send data function
9:14
in the first controller I am sending the
9:16
string which starts with f 1 0 3.
9:20
when the data is received by the second
9:22
controller it will just modify the first
9:25
four bytes to F 4 4 6 and send the same
9:28
string back to the first controller
9:31
since I want this second controller to
9:34
only respond to the data sent by the
9:36
first one this is why the transmission
9:38
program is written in the Callback
9:41
there is nothing inside the while loop
9:45
the code is already loaded into the f446
9:48
so we will just see the f103 debugger
9:53
all right let's test this now
10:03
both the controllers are connected to
10:05
the same computer so I am fixing the St
10:08
link to this configuration
10:15
here I have put both the buffers in the
10:18
live expression let's put a break point
10:21
at the send data function
10:25
here you can see the data stored in the
10:28
TX buffer and now this data will be sent
10:32
let's put another breakpoint in the
10:38
it didn't hit the breakpoint but it's
10:40
fine here you can see the data received
10:45
we have some garbage characters also but
10:47
this is because I didn't reset the f446
10:50
and it already had the data in the RX
10:54
just ignore it for now
10:56
the data is exactly what we sent but the
10:59
103 has been replaced with four four six
11:05
we have hit the breakpoint this time but
11:07
the received data is the same
11:15
seems like the received data is not
11:19
maybe because of the breakpoints
11:22
let's remove them and run the code
11:25
all right now you can see the received
11:28
data is exactly the same that we are
11:30
sending except for the first few bytes
11:33
anyway you can clear the buffer in the
11:35
second controller after sending the data
11:37
that way it will not send the extra
11:41
that's all for this video
11:43
in the next video we will start with the
11:46
modbus and obviously we will use this
11:49
rs485 module with it
11:52
we will use stm32 as the master and read
11:55
some holding and input registers of the
11:59
the purpose of this video was just to
12:01
give an idea about how this rs-485 to
12:04
TTL module actually works
12:07
I hope everything was clear
12:09
you can download the code from the link
12:13
keep watching and have a nice day ahead