RS232 Component and RX Value 255

[Ron]

Hi,

Is there a way to change the RS232 component so that 255 is available? Perhaps add another variable (whose value can be tested) that is dedicated to "RX Buffer Empty". RX Buffer Empty = 1, RX Buffer Not Empty = 2?

I want to try to setup an RS485 network and I will be receiving a VAR that could be 255. All the data will be sent as bytes, not characters to keep the packet sizes small.

Thank you,

Ron

[Dan81]

Hello Ron

It's very easy with Flowcode4 : choose integer for the "char receive type" in the RS232 properties.
With Flowcode3, If you know C language, you can try to customize the C code (think to make a back up before)

Daniel

[Ron]

Hello Daniel,

I have V3 so change the component is what I will have to do. Has anyone ever done this? I have limited experience with "C".

Is this change to the component a huge undertaking?

Thanks,

Ron

[Spanish_dude]

Hasn't Benj changed the C file for the RS232 component to allow that ?

Have you searched on the forum for that modified RS232 component ?

[Benj]

Hello,

You need to open the RS232 component C file and do the following.

Near the top of the file find this...

Code: Select all

[MacroNames]
Count=3
1=GetDefines
2=SendRS232Char
3=ReceiveRS232Char

[MacroReturns]
1=void
2=void
3=char

change to this...

Code: Select all

[MacroNames]
Count=3
1=GetDefines
2=SendRS232Char
3=ReceiveRS232Char

[MacroReturns]
1=void
2=void
3=short

Then scroll down and find this...

Code: Select all

char ReceiveRS232Char(char nTimeout)
{
/*Macro_ReceiveRS232Char_Start*/
  #ifndef MX_UART
	#pragma error "Chip does not have UART capability"
  #endif

	char delay1 = 0;
	char delay2 = 0;
	char dummy = 0;
	char retVal = 255;

Change to this...

Code: Select all

char ReceiveRS232Char(char nTimeout)
{
/*Macro_ReceiveRS232Char_Start*/
  #ifndef MX_UART
	#pragma error "Chip does not have UART capability"
  #endif

	char delay1 = 0;
	char delay2 = 0;
	char dummy = 0;
	short retVal = 256;

And that's it your done. Restart Flowcode to load your changes.

[Ron]

Hi Benj,

Thank you, DAN81 also helped me get this going.

There should be a library that can only have posts done by Moderators, read only to users. Things like this could be documented without all the extra replies to make it easier for us "inexperienced" users to find.


Just an idea............

I am saving up my money to get the PIC AND dsPIC V4 version .

The support everyone offers is why I have made this decision.

Thanks again,

Ron

[Steve]

Hi Ron,

You probably know this, but just in case you don't here's the cheapest way to get both the PIC and dsPIC versions:

First, upgrade your V3 PIC to V4 - this saves you half price.

Then, "crossgrade" your PIC V4 to the dsPIC/PIC24 V4 - again with a saving of 50%.

[Spanish_dude]

...
Change to this...

Code: Select all

char ReceiveRS232Char(char nTimeout)
{
/*Macro_ReceiveRS232Char_Start*/
  #ifndef MX_UART
	#pragma error "Chip does not have UART capability"
  #endif

	char delay1 = 0;
	char delay2 = 0;
	char dummy = 0;
	short retVal = 256;

I think you forgot to change the type of the function. That needs to be changed to "short" too.

[Benj]

Hello Spanish Dude,

The change was made up in the Flowcode section. Just a peculiarity with the way Flowcode imports its macros.

[MacroNames]
Count=3
1=GetDefines
2=SendRS232Char
3=ReceiveRS232Char

[MacroReturns]
1=void
2=void
3=short

[Ron]

Hi,

I changed my standard rs232 macro so that I can receive 255 as Ben shows above (my returned value is -1 so I test for RS232_INT_VAR > -1). When I receive RS232_INT_VAR now, if I want to move it into a BYTE can I just do this (since the value will never be higher than 255)?

MY_BYTE_VAR = RS232_INT_VAR

or must I break the RS232_INT_VAR into 2 bytes then move

MY_BYTE_VAR = RS232_INT_VAR_LO



Thanks,

Ron

[Benj]

Hi Ron,

This should work well to mask off just the data, I don't foresee any problems with doing this.

MY_BYTE_VAR = RS232_INT_VAR

[Ron]

Hi,

I have MODBUS RTU working with several slaves I have built. One of the specifications for MODBUS is that when receiving a packet you wait for 3.5 characters of silence (time). Then analyze the received packet.

Right now I am using 10us delays and counting them between receiving a character. If I receive a packet I clear the counter, if no packet received then I INC my counter. This works ok but I am sure I am waiting much longer as I am counting the 10us delays and also have all the time the receive macro uses to solve.

How much time does the receive macro (rs232) take to solve?

18F4620
19.6608MHz
0 set for timeout.

Example:

You tell me, Ron that code takes 2us to solve. I would get rid of my 10us delay counting loop and just loop 500 times to get the 3.5 char silence delay. This would be much more accurate than how I am doing it now.

EDIT......

I found this in the datasheet......

All single-word instructions are executed in a single
instruction cycle, unless a conditional test is true or the
program counter is changed as a result of the instruction.
In these cases, the execution takes two instruction
cycles, with the additional instruction cycle(s) executed
as a NOP.
The double-word instructions execute in two instruction
cycles.
One instruction cycle consists of four oscillator periods.
Thus, for an oscillator frequency of 4 MHz, the normal
instruction execution time is 1 μs. If a conditional test is
true, or the program counter is changed as a result of
an instruction, the instruction execution time is 2 μs.
Two-word branch instructions (if true) would take 3 μs.

Here is the bulk of what I think is the ASM file. I want to get rid of my 10us counter loop. The code below takes time so I want to determine how much time each loop takes, and then simply count the loops that I do not receive any response for the 3.5 char delay.

FCD_RS2320_00015
; { FCD_RS2320_ReceiveRS232Char ; function begin
CLRF FCD_RS2320_00015_1_delay1
CLRF FCD_RS2320_00015_1_delay2
CLRF FCD_RS2320_00015_1_dummy
SETF FCD_RS2320_00015_1_retVal
CLRF FCD_RS2320_00015_1_retVal+D'1'
DECF FCD_RS2320_00015_1_retVal+D'1', F
CLRF FCD_RS2320_00015_1_bWaitForever
CLRF FCD_RS2320_00015_1_rxStatus
INCF FCD_RS2320_00015_arg_nTimeout, W
BNZ label268439299
MOVLW 0x01
MOVWF FCD_RS2320_00015_1_bWaitForever
label268439299
BSF gbl_rcsta,4
label268439304
MOVF FCD_RS2320_00015_1_rxStatus, F
BNZ label268439305
BTFSS gbl_pir1,5
BRA label268439308
MOVLW 0x02
MOVWF FCD_RS2320_00015_1_rxStatus
BRA label268439304
label268439308
MOVF FCD_RS2320_00015_1_bWaitForever, F
BNZ label268439304
MOVF FCD_RS2320_00015_arg_nTimeout, F
BNZ label268439317
MOVLW 0x01
MOVWF FCD_RS2320_00015_1_rxStatus
BRA label268439304
label268439317
DECF FCD_RS2320_00015_1_delay1, F
MOVF FCD_RS2320_00015_1_delay1, F
BTFSC STATUS,Z
DECF FCD_RS2320_00015_arg_nTimeout, F
BRA label268439304
label268439305
MOVLW 0x02
CPFSEQ FCD_RS2320_00015_1_rxStatus
BRA label268439342
BTFSS gbl_rcsta,2
BRA label268439331
MOVF gbl_rcreg, W
MOVWF FCD_RS2320_00015_1_dummy
BRA label268439342
label268439331
BTFSS gbl_rcsta,1
BRA label268439337
BCF gbl_rcsta,4
BSF gbl_rcsta,4
BRA label268439342
label268439337
MOVF gbl_rcreg, W
MOVWF FCD_RS2320_00015_1_retVal
CLRF FCD_RS2320_00015_1_retVal+D'1'
label268439342
MOVF FCD_RS2320_00015_1_retVal, W
MOVWF CompTempVarRet607
MOVF FCD_RS2320_00015_1_retVal+D'1', W
MOVWF CompTempVarRet607+D'1'
RETURN
; } FCD_RS2320_ReceiveRS232Char function end

ORG 0x00000076
main
; { main ; function begin
MOVLW 0x0F
MOVWF gbl_adcon1
MOVLW 0x04
MOVWF gbl_txsta
MOVLW 0x1F
MOVWF gbl_spbrg
CLRF gbl_rcsta
BSF gbl_rcsta,7
label268439356
CLRF FCD_RS2320_00015_arg_nTimeout
CALL FCD_RS2320_00015
MOVF CompTempVarRet607, W
MOVWF gbl_FCV_RX_BUFFER
MOVF CompTempVarRet607+D'1', W
MOVWF gbl_FCV_RX_BUFFER+D'1'
XORLW 0x80
MOVWF CompTempVar608
MOVLW 0x7F
SUBWF CompTempVar608, W
BNZ label268439364
MOVLW 0xFF
CPFSGT gbl_FCV_RX_BUFFER
label268439364
BZ label268439367
BC label268439356
label268439367
BRA label268439367
; } main function end

ORG 0x000000A8
_startup
GOTO main
ORG 0x000000AC
interrupt
; { interrupt ; function begin
MOVFF FSR0H, Int1Context
MOVFF FSR0L, Int1Context+D'1'
MOVFF PRODH, Int1Context+D'2'
MOVFF PRODL, Int1Context+D'3'
MOVFF Int1Context+D'3', PRODL
MOVFF Int1Context+D'2', PRODH
MOVFF Int1Context+D'1', FSR0L
MOVFF Int1Context, FSR0H
RETFIE 1
; } interrupt function end


Thank you....

Ron

[Benj]

Hi Ron,

A quick way of working out how long code takes to execute is to start a counter running using a fairly high prescaler. Set the code running in a loop and count how many times you managed to execute it before the interrupt kicked in. Then display the count on the LCD. You then know how many time the code ran within a single interrupt time frame.

eg

Timer interrupt macro

testing = 0

Main Macro

testing = 1
count = 0
while (testing == 1)
{
code block
count = count + 1
}

[Ron]

Hi,

If I get a buffer overflow when using the RS232 RX macro, how do I clear it?

The 18F4620 has a 2 byte RX buffer.

Thank you....

[Benj]

Hi Ron,

The overrun error is cleared by calling the RS232 receive function. If you call it twice before you do anything then the error should be cleared and any data already in the receive buffer will be flushed.

if you keep receiving the overrun error then you could maybe fix this by performing the receive function more often or resort to using the receive interrupt RXINT.

[Ron]

Hi,

I am doing RS485 using a max485 chip and the rs232 macro/component.

I have a slave I/O board that has both inputs and outputs on it. I do comm every scan to this board. On my master I have 8 LEDs that I turn on and off.

EX.

turn on led 1
wait 100ms
turn on led 2
wait 100ms
turn on led 3
wait 100ms
turn on led 4
wait 100ms
turn on led 5
wait 100ms
turn on led 6
wait 100ms
turn on led 7
wait 100ms
turn on led 8
wait 100ms
then turn them off in reverse order with 100ms delay in between.
go to top

When I do rs485 comm on each scan I can see that my timing (100ms) for the above code on master it way off. I am using MODBUS RTU.

Is TMR0 disabled while in the RS232 "send" component?
Is TMR0 disabled while in the RS232 "receive" component?

If yes to either can you tell me how to modify the rs232 component to keep TMR0 running. I am currently running at 38400 baud but will try to get it working at 115200 in the future.

18F4620 is on Master

Thank you,

Ron