View previous topic :: View next topic |
Author |
Message |
Ttelmah
Joined: 11 Mar 2010 Posts: 19540
|
|
Posted: Wed Oct 11, 2023 7:46 am |
|
|
If that is the CCS 3.3v Ethernet kit, that does actually have a proper
RS232 serial level converter 'on board'. There is a PC serial to board
cable available, that uses the 3.3mm jack to a DB9.
However that board uses the 67J60, not the 47Q83 his code was for. |
|
|
MCUprogrammer
Joined: 08 Sep 2020 Posts: 221
|
|
Posted: Wed Oct 11, 2023 7:59 am |
|
|
https://www.ccsinfo.com/product_info.php?products_id=proethkit
I shared the product page. Since there was no ready circuit with 47Q83, a problem arose every time. That's why I'm experimenting with the kit I have. My problem is that I am sending 5 bytes of data from the PIC to the device each time. When I receive this data, the device sends me 66 bytes of data. I don't have any problems when I try it with siow.exe. But when I connect the product to the machine, the value does not change at all. It seems like the RX pin is not receiving the incoming data. _________________ Best Regards...
MCUprogrammer
_______________________________
Work Hard |
|
|
temtronic
Joined: 01 Jul 2010 Posts: 9244 Location: Greensville,Ontario
|
|
Posted: Wed Oct 11, 2023 10:05 am |
|
|
hmm.. confirm the actual use of the DB9 connector pins !
From memory, 5 is ground, 2 is receive, 3 is transmit. 2 used to be transmit when they used RS-232 and DB-25 connectors
I recall the early PICkit-3s 'serial cable' was reversed...... |
|
|
MCUprogrammer
Joined: 08 Sep 2020 Posts: 221
|
|
Posted: Wed Oct 11, 2023 12:50 pm |
|
|
What I don't understand is that when I plug the cable into the PC, I receive data. However, when I plug it into the PIC's stereo jack, the function does not work even though data is received. But when I disconnect the cable from the machine, burn it to the PC, write 66 bytes to the hex section in the siow.exe program and send it, I can receive the data. The problem is that since it comes from a 66byte machine, why isn't it taken? The only thing I can think of is RX locking or a problem with the buffer. _________________ Best Regards...
MCUprogrammer
_______________________________
Work Hard |
|
|
temtronic
Joined: 01 Jul 2010 Posts: 9244 Location: Greensville,Ontario
|
|
Posted: Wed Oct 11, 2023 4:42 pm |
|
|
one possible problem is in how you program the PIC. If you have 'debug' enabled THAT will change HOW the PIC operates. I don't have that PIC or PCB but know that MPLAB had 'debug' set as the default 'build configuration'.I called Microchip and they 'patched' MPLAB so that I could select 'release' as the default.
Again, show your current code ! You may have a 'typo' or changed 'something' that another pair of eyes will see. |
|
|
MCUprogrammer
Joined: 08 Sep 2020 Posts: 221
|
|
Posted: Wed Oct 11, 2023 10:40 pm |
|
|
https://aceautomation.eu/product/rs232-to-rs485-converter/
Attached is the device I use. I connect the stereo jack com output to the com side of this device. I connect the leads coming from the machine to the +485 and -485 terminal blocks. Well, I do not use gnd and +5+12 pins. Is this true?
There are a few things I have in mind for the code today, I will try them. If not, I will share. I'm not near the PC where I wrote the code right now.
So what I'm wondering is, I'm sending 5 bytes of data. The data is in hex format. When the device receives this data, it sends me 66 bytes. I process it by making checks. I run my tests using 2 rs232 streams. I am sending 5 bytes of data from the microprocessor. I see 5 bytes of data on the screen of the Hercules program. I am sending 66 bytes of data from the Hercules program. PIC receives that data. He also does the right thing. And in siow.exe, the ICD stream prints correctly and the incoming data prints correctly. The real problem is that when connected to the machine, these 66 bnytes of data are constantly changing and coming. So I'm constantly sending 5 bytes. It keeps sending me 66 bytes. It seems like RX stops receiving data after a while. That's why I write something in certain places. The program doesn't get in there at all. Or I try to blink the LED with every character it receives. LED does not react at all. _________________ Best Regards...
MCUprogrammer
_______________________________
Work Hard |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19540
|
|
Posted: Thu Oct 12, 2023 1:43 am |
|
|
It is not clear at all what you are doing. You have suddenly now introduced
RS485 into the equation. Now the 3.3v Ethernet kit talks RS232, not RS485.
A PC will normally (with a suitable adapter), use RS232. Neither uses
RS485.
What 'machine'. What does it say it's connector supports/uses?.
RS485, is a differential bus. The A+ on each device connects to the A+
on the other devices. The A- to the A- on the other devices. RS485, also
_requires_ termination, and this must also bias the bus to ensure that
it idles correctly. The termination is described here:
[url]
https://know.innon.com/bias-termination-rs485-network
[/url]
This has to exist at each end of the bus.
Next thing though is that RS485, is half duplex. There has to be something
to turn the bus round. Now the device shown does not say how this is
done. Normally the DTR/DSR signals on RS232 are used to control this
and these have to be controlled to do this. The connection to the Ethernet
board does not offer these signals. The device you show seems to be
possibly trying to do this automatically when data is sent, but this means
that it'll only work correctly at the speed it is designed to support, and
with the packet format it is built to support.
Then the Q43, is a PPS chip. The J60 is not. With this chip you can only
use the connections listed in the data sheet. |
|
|
MCUprogrammer
Joined: 08 Sep 2020 Posts: 221
|
|
Posted: Thu Oct 12, 2023 2:02 am |
|
|
You are right. Things got out of hand. So let me explain it from the beginning to sum it up.
I am trying to make the PIC talk by using serial communication on the machine. PIC sends 5 bytes of data to the machine. When the machine receives 5 bytes of data, it sends 66 bytes of data. Each of these 66 bytes has a different meaning. Start byte, function byte, data byte, check byte and end byte.
The machine communicates via RS485. But there is RS232 on my kit. I convert it to rs485 with this convertor. So I plug the stereo jack com cable into the rs232 com side. After all, the device I use is rs232 to rs485. What does this mean? Converts 232 to 485. Do you think I'm wrong? If there was a problem, I think I would have to experience the same problem on my PC. Why do I get the correct data when I plug it into the PC? There is no rs485 output on the PC. How does it work? So, in the end, I use the rs232 to rs485 device for the machine. I use the usb to rs232 device to get the correct data to the PC. Because I don't have a com output port on the PC. That's why I use this translation. For testing purposes. And I see the 66 bytes coming in siow.exe are quite correct. Why doesn't this work on PIC?
My USB to RS232 device.
https://www.amazon.com.tr/Digitus-Converter-USB1-1-uzatma-kablosu/dp/B00CI63N6C
My rs232 to rs485 device
https://robiz.net/rs232485box
Normally, I plugged in the USB to RS232 to test it to see if the data was coming correctly. _________________ Best Regards...
MCUprogrammer
_______________________________
Work Hard
Last edited by MCUprogrammer on Thu Oct 12, 2023 2:17 am; edited 1 time in total |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19540
|
|
Posted: Thu Oct 12, 2023 2:16 am |
|
|
Key big thing you are missing is the understanding of what the difference
between RS232 and 485 'implies'.
Now RS485 is a signalling standard, so is RS232. The latter uses +/-12v
on each individual wire. The former uses differential signalling on a pair
of wires. Since most RS485 connections only have one pair of wires, Using
RS485, forces things to be half duplex, while RS232 is normally duplex.
This is a huge difference in what can be done. Means the comms has to be:
Set the bus to transmit.
Send data
Set the bus to receive
Receive data
Normally the 'set to transmit' and 'set to receive', is done by physically
operating the direction control line to the RS485 driver chip. Now the
device you have does not have such a line, so it has to be attempting to
control the direction itself. Devices that do this normally look at the
RS232 transmit line and when it operates turn the bus to transmit mode
for the time needed for a character. Has several implications:
First device needs to know the baud rate.
Then the bus will switch to receive in any gaps between characters. Means
that the biasing of the bus becomes absolutely critical.
Then there is the general one that you have to know that the bus is
not already being driven, when you go to transmit.
It'd be much easier to directly use three of the logic pins on the processor
and connect these to a standard RS485 transceiver, and change the
#use RS232 setup to operate the direction control line.
It doesn't sound as if you have termination and bias. This is _required_. |
|
|
MCUprogrammer
Joined: 08 Sep 2020 Posts: 221
|
|
Posted: Thu Oct 12, 2023 2:29 am |
|
|
Well, then, doesn't this adapter I use automatically do this job? and rs485 is half-duplex. But in the end, I convert this protocol to 485 with the converter. If I had used the rs485 integrated in the PIC, then I would have to do this control myself.
If I wanted to connect the max485 integrated to the PIC, I would make the connection as follows.
https://electronics.stackexchange.com/questions/286263/is-there-any-way-to-use-half-duplex-rs485-without-using-a-dedicated-controller-p
But is it necessary? The ready converter does this job. I write the code as if using rs232. What's the mistake I'm making here? _________________ Best Regards...
MCUprogrammer
_______________________________
Work Hard |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19540
|
|
Posted: Thu Oct 12, 2023 3:14 am |
|
|
The adapter automatically sets the bus to transmit when you transmit.
But the key is that because this means the bus goes to receive between
every character, even when the device at the other end is not sending,
the biasing of the bus becomes absolutely essential. The adapter does
not terminate or bias the bus. This is always required separately.
Also, the physical behaviour of your code has to ensure that it only
sends when the bus is able to take the data. |
|
|
MCUprogrammer
Joined: 08 Sep 2020 Posts: 221
|
|
Posted: Thu Oct 12, 2023 3:24 am |
|
|
Code: |
#include <18F47Q83.h>
#use delay(crystal = 16MHz)
#pin_select U1TX=PIN_C6
#pin_select U1RX=PIN_C7
#use rs232(UART1, etkinleştir=PIN_C5, baud=9600, receive_buffer=256,bit=8,parite=N, stop=1)
#define LCD_ENABLE_PIN PIN_D2
#define LCD_RS_PIN PIN_D0
#define LCD_RW_PIN PIN_D1
#define LCD_DATA4 PIN_D4
#define LCD_DATA5 PIN_D5
#define LCD_DATA6 PIN_D6
#define LCD_DATA7 PIN_D7
#include <lcd.c>
#define SEND_DATA_SIZE 5
#define RECEIVE_DATA_SIZE 66
void SendTask(void)
{
unsigned int8 i;
char sendDataHEX[SEND_DATA_SIZE] = {0x1B, 0xE7, 0x01, 0x03, 0x0D};
for(i=0;i<SEND_DATA_SIZE;i++)
{
putc(sendDataHEX[i]);
}
}
void main()
{
lcd_init();
int1 doSend = TRUE;
char receivedData[RECEIVE_DATA_SIZE];
enable_interrupts(GLOBAL);
while(TRUE)
{
if(doSend)
{
SendTask();
doSend = FALSE;
}
// PC'den gelen veriyi al
for (int8 i = 0; i < RECEIVE_DATA_SIZE; i++)
{
receivedData[i] = getc();
printf("%02X ", receivedData[i]);
}
doSend = TRUE;
}
} |
_________________ Best Regards...
MCUprogrammer
_______________________________
Work Hard
Last edited by MCUprogrammer on Thu Oct 12, 2023 11:44 pm; edited 3 times in total |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19540
|
|
Posted: Thu Oct 12, 2023 7:49 am |
|
|
We can't tell without knowing a lot more about the other device.
How it handles the bus?.
What it's latency from receiving the command to sending it's reply is?.
Does it send anything at all 'unprompted'?.
Have you got the biasing and terminations on the bus?.
Also, does the 232 to 485 adapter echo the transmitted bytes?.
(you can test this by attaching it to a PC with a terminal program). |
|
|
MCUprogrammer
Joined: 08 Sep 2020 Posts: 221
|
|
Posted: Thu Oct 12, 2023 8:06 am |
|
|
Yes, it reflects the incoming data to the PC. The rs232tors485 converter I have plugs into the laptop. I am running the siow.exe program. After making the relevant settings, I send 5 bytes of data from the hex section. And it prints 66 bytes of data to the screen. The only problem is that I disconnect it from the PC and insert it into the PIC card, but I cannot receive the data. I make sure to send 5 bytes of data each time. Because I print the data I send to the screen. For now, I want to connect the max485 integrated circuit to the PIC18F47q83 processor and test it. Then the dialer will be removed. So, how should I edit the code I shared? I shorted RO-C7,DI,-C6,2 and 3. Then I connected it to C5 pin as ctrl. How do you think I should revise the program now? I've never dealt with rs485 before. _________________ Best Regards...
MCUprogrammer
_______________________________
Work Hard |
|
|
gaugeguy
Joined: 05 Apr 2011 Posts: 303
|
|
Posted: Thu Oct 12, 2023 8:31 am |
|
|
Do you have an oscilloscope? You will need one to verify the hardware operation. |
|
|
|