Connecting a RS485 module to OBC hardware

[RobertK66]

Let's use this place for code questions regarding the usage of the RS485 interface on OBC Y+ connector.

[RobertK66]

What’s missing in your code from branch https://github.com/RobertK66/obc_1769_core/tree/STP is:
You have to control the DIR Pin of your RS485 Interface. This is called RS485_TX_RX and you find it on page 6/8 in the schematics of our CLIMB_OBC_EM2.

I would suggest that you remove both the pEnablePin and the pPpsPin (feature pins of my GPS hardware) from the init structure and replace it with your “pRs485DirPin” which should reference the currently used GPIO: P2[5]/(IC101-68) named PINIDX_RS485_TX_RX in the pinning_climbobc.h file.

Then you have to code that this pin is switched correctly for RX – TX. As you already succeeded in sending out bytes, I assume the default value currently set is for “TX”. You can manually switch this GPIO by using the “h 43 1” or “h 43 2” command. Here 43 is the real index number from the enum RS485_TX_RX and this crude hardware test command uses this as direct index into the pinmuxing2[] array.

[kodsurf]

I made recent code commit regarding that.

But where this wire has to be connected on RS485 converter ?

[RobertK66]

This has nothing to do with the Converter (side) of the communication!
If you use a 2 wire RS485 (which is what I think should be done in your case) then you only connect 2 wires A/B from OBC to adapter. On the OBC the RS485 Transeiver chip makes the conversion for incomming signal to RX (OBC view) and it generates the outgoing signal (on same A/B) for TX (OBC view). I gave you the reference to the schematics in my above comment. If you switch this GPIO per hand as I gave you the command, you should be able to see that you can control

• TX OBC -> connected terminal prog via converter works with one setting
• and when GPIO is reversed you will not see your output, but you should be able to get the input from the terminal program into OBC rx code.

And then finally your OBC code must manage that the pin is always in 'RX' only if TX is initated you should 'switch' the output driver to make this TX realy happen on A/B.

[RobertK66]

@kodsurf : For doku purpose I do repeat the Info here which I sent to you per DM (on 22.3.2022):

In EM2 we refactored the RS485 interface to use UART1!
The UART1 has a feature to drive the RS485 TX/RX line by itself. You have to configure this to happen. Pls. refer to Chapter 15 starting on page 328 of the UM10360 manual. Especially the Chapter 15.4.18 shows how to configure the ‘’Auto Direction Control’ for RS485 mode of operation! I strongly recommend that you debug this behaviour with connected Oscilloscope. Especially if we need a delay value configured in the RS485 DLY register (15.4.20) has to be investigated with the real (thruster) hardware!!!

[kodsurf]

In the code that I recently pushed into STP branch (regarding RS485 tx rx dirrection controll)

After switching PINIDX_RS485_TX_RX TRANSMIT to TX mode so that data bytes can be transmitted - delay has to be introduced ( see image). Otherwise bytes does not come through.

Please advice how to introduce this delay in a proper way.

3b5739f

[RobertK66]

1. Your comment in line 163 shows me that you did not grab the functionality of the TxBuffer yet ;-). Switching the Pin in Line 164 is much to early here!!!
   The transmission on the Tx line just starts here (with the first byte written in the buffer). The next byte(s) is/ are only sent to UART after the thrUartIRQ() routine in line 101 gets triggered ( ms later when the first byte finishes the shift out with set baudrate). So the original call to thrSendBytes() is long ago and in the meantime mainloop should continue its work as usual…..
   The correct place to switch the line back to RX is within the thrUartIRQ() function. At line 109/110 the IRQ routine detects that all bytes are sent now and disables ‘itself’ (by disabling own IRQ).
   But you are right that I told you: “we need a delay here”. This also holds for Line 109/110 because that moment when it is executed the last byte is still in the output shift register and not yet put on the line. (I somewhen had a crude workaround by always putting one byte more into buffer but this is no correct solution for final flight software!)

2. Putting a delay on the right places: Where you suggested your delays, they will only hamper main loop execution (when some other 'client' calls your thrSendBytes() API from main loop) and not help for the pinout timings. I think (I saw and measured) that the time between line 150 and first call of 157 until UART really putting out the first bits is good enough to get the Tx activated …. (still to be proofed and re-meassured …)
   Delaying the RX-enable switch to wait for the last byte to be finally sent was not an easy task (I tried in EM1 to achieve this, but it makes use of complicated timers itself…..). That’s the reason we refactored EM2 (as I already stated above)!

3. So fortunately, you do not have to implement a delay here. Instead you can use the functionality of UART1 described in the mentioned manual. (I have it not here now but pls. refer to the chapters I gave above). With this you should be able to initialize the GPIO pin and the UART hardware to make the switch like desired. There is still an issue to measure and proof a good and correct delay but there is a register to program that delay for this low level hardware solution.

[kodsurf]

This switching happens instantly ? I thought that delay is need so that there would be time to switch from LOW to HIGH

if so then delay on lines 151-154 not needed ? Can you confirm that time needed to switch (LOW-HIGH, HIGH-LOW) we can consider as "instant" for given problem ?

So I have to switch back to received

with

After line 110 on

?

---

OR according to UM10360 manual

We have to set UART1 DCTRL register to 1 in order to enable auto direction control.

Can you please give a hint on how to do it ?

When I try :

To access the registers of LPC_UART1 - I dont see DCTRL

Only RS485CRTL which is mentioned in UM10360 manual.

the type of variable is volatile uint32_t

To me looks confusing.

[kodsurf]

I also looked into tutorials for LPC1768

https://www.exploreembedded.com/wiki/LPC1768:_UART_Programming

Which explain pretty good on what are those UART registers

For example :
if we need to send byte - THR register of UART is filled with data byte.

In the same tutorial I see :

that in some "strange way" we set values at FCR and LCR registers

So I assume that FCR register uint32_t data contains all in :

and with line

all those is being filled.

Could you please explain what is going on here ( obviolsy I need to understad it in order to chage value in DCRTL register)

[kodsurf]

Am I understanding it correctly :

we need to set RS485CTRL register with 32bit data

for example : 100000000-----(32 zeroes) binary would stand for :

NMMEN is set to 1 (RS-485/EIA-485 Normal Multidrop Mode (NMM) is disabled. )

and the rest is disabled

So to supply an example configuratin described above - we need to set LPC_UART1-> RS485CRTL = hex(100000000000000000000000000000000)

to a hex value corresponding to binary of our desired configuration ?

[kodsurf]

Ok,

I think I have a solution for problem described above - but please check and confirm that it is correctly understood by me

On the right side I tested C code to change bit at a certain position (p) of data variable . Output looks like what I was expecting. So I want to use this method to change one bit at LPC_UART1->RS485CTRL register.

Does this looks correct ?

[RobertK66]

I think you already found out there are several "weired ways of setting bits in ANSI-C" ...

You simply could write:
LPC_UART1->FCR=0x0007; // or mybe ..FCR=0b0000000000000111; // (not sure our compiler does support 0b prefix )

But to give the humble source code reader a chance to glimpse what bits we want to set here, it is common to use some constant defines for it. Now how to write it, this depends on what could be found in chip.h - provided by NXP to reflect the available function bits......

I am not sure which version and library your example uart code used (but I never saw the SBIT_xxxx defines. What I would use in this context is:
LPC_UART1->FCR = (UART_FCR_FIFO_EN | UART_FCR_RX_RS | UART_FCR_TX_RS);

where the UART_xxx defines are from uart_17xx_40xx.h

/**
 * @brief Macro defines for UART FIFO Control Register
 */
#define UART_FCR_FIFO_EN        (1 << 0)	/*!< UART FIFO enable */
#define UART_FCR_RX_RS          (1 << 1)	/*!< UART RX FIFO reset */
#define UART_FCR_TX_RS          (1 << 2)	/*!< UART TX FIFO reset */
#define UART_FCR_DMAMODE_SEL    (1 << 3)	/*!< UART DMA mode selection - valid for 17xx/40xx, 18xx/43xx only */
#define UART_FCR_BITMASK        (0xCF)		/*!< UART FIFO control bit mask */`

The rest of the story is simply combining the ANSI-C bit operators to get the one constant you want to write to the register. As this all is done by the compiler it does not matter how you #calculate# the correct value to be used. Only some versions are 'better readable' and interpretable (without looking up bits in pages of the manual) as others.....

[RobertK66]

For your Rs485CTRL pls. use this defines from chip.h (->uart_17xx_40xx.h):

/**
 * @brief Macro defines for UART RS485 Control register
 */
#define UART_RS485CTRL_NMM_EN       (1 << 0)	/*!< RS-485/EIA-485 Normal Multi-drop Mode (NMM) is disabled */
#define UART_RS485CTRL_RX_DIS       (1 << 1)	/*!< The receiver is disabled */
#define UART_RS485CTRL_AADEN        (1 << 2)	/*!< Auto Address Detect (AAD) is enabled */
#define UART_RS485CTRL_SEL_DTR      (1 << 3)	/*!< If direction control is enabled (bit DCTRL = 1), pin DTR is
												        used for direction control */
#define UART_RS485CTRL_DCTRL_EN     (1 << 4)	/*!< Enable Auto Direction Control */
#define UART_RS485CTRL_OINV_1       (1 << 5)	/*!< This bit reverses the polarity of the direction
												       control signal on the RTS (or DTR) pin. The direction control pin
												       will be driven to logic "1" when the transmitter has data to be sent */
#define UART_RS485CTRL_BITMASK      (0x3F)		/*!< RS485 control bit-mask value */

with:
LPC_UART1->RS485CTRL |= UART_RS485CTRL_DCTRL_EN;
you should enable the auto direction control. (Without changing any other bits of the RS485CTRL register! Because of '|=' !)

But pls. make also sure to check setting of all other bits to correct value, because I think we need UART_RS485CTRL_SEL_DTR and UART_RS485CTRL_OINV_1 to be according to our hardware requirenments (connections).

To Set a single bit to 0 you could use:
`LPC_UART1->RS485CTRL &= (~UART_RS485CTRL_DCTRL_EN);' (... I think ;-) )

or any other Ansi-C bit operators ......

[kodsurf]

SEL value :
"If dirrection control is enabled (bit DCTRL =1) (which I intend to do ) ?!?!?!? then pin DTR is used for dirrectin control !?!?!?

So this means that even if I enable automatic direction control ? Why DTR pin would then be used for ????

I locate DTR pin on the schematics

But the strange thing is that I see that we have initialized p[2]5 with IOCON_FUNC0

But this DTR1 is at IOCON_FUNC1 ?

Something is still really confusing to me ....

[RobertK66]

Ok, "we have initialized p[2]5 with IOCON_FUNC0" was exactly what "we" have done when "we" didn't remember, that "we" changed to this pin exactly because here the Auto-DTR is available 😄 -> so just change it to FUNC2 and that should work as decribed in the manual.

[RobertK66]

... and don't forget to set UART_RS485CTRL_SEL_DTR bit to 1

[RobertK66]

and finally to your above question

"Can you confirm that time needed to switch (LOW-HIGH, HIGH-LOW) we can consider as "instant" for given problem ?"

No I can't. That's the reason you have to make it work and play around with it! -> Meassure with OSZI and analyze relliabillity of results......

Normally putting a GPIO to low works pretty 'instant'. So maybe none or only some instructions later everything should be ok. But if you have some outputs which are 'switched to high' by leaving the lines in 'high resistance'. Then the Pull Up resistor(s) used and the current it draws has influence on the time which has to be waited until this line is considered 'free'. On the RS485 bus you should see this times when the A-B lines drift to there 'idle' state after Tx (by OBC -> our 'leave lines high') or after RX (from Thruster -> thruster 'release lines'....) This all depends on R values (on A-B) and line length and, and, and ......

[kodsurf]

Another issue that I have discovered with current version of STP branch.

Last byte of request that are intended to be sent is replaced with FF. Which is wrong !

[RobertK66]

I think I gave you enough hints on this one already. Pls. use your own fantasy on that one now .....

[kodsurf]

With commit

baaf161

solves the problem. Last bit is not longer replaced with 0xFF. Dirrection controll works.

Once I get new thruster simulator hardware from EMPULSION (the one which is in FHWN right now is broken)- would be able to test "Version Request" and meassure "switching time" with osci.