OK.
Could you summarise which hardware and subroutines will be in the UART PIC, lets look into the sync problems.
E

 

OK.
Could you summarise which hardware and subroutines will be in the UART PIC, lets look into the sync problems.
E

Hi E, [ TRANSMITTER ]

18F4620
Hardware:modules:
5110 Screen
GPS
Barometer
Compass
Radio

5110 uses GOSUB with CALL for writing and clearing
GPS has a GOSUB Calculation
Barometer has a GOSUB calculation

Not forgetting the FONT INCLUDE

GPS and REMOTE use UART

The second PIC 18LF4431 has a QEI for the Encoder, and needs to pass the result back to the 18F4620 somehow..
C

 

Hi,
I think I've fond the BIT to watch! I added an [ If PIR1.RCIF = 1 Then ] instead of the WAIT, and I'm getting some results.

I'm getting every other digit, so some sort of numbering problem I think!
C.

 

hi,
OK, which peripheral/s is using an Interrupt.?
E

 

hi,
OK, which peripheral/s is using an Interrupt.?
E

Hi E, [ TRANSMITTER ]
In an effort to stop HSERIN blocking a TMR1 INTERRUPT was added.

An alternative was suggested HSERGET, which may work, and appears to in SIM.

Here is my latest test, using HSERGET and NO INTERRUPT. Will you have a Simulate please?

I find that if a corrupt STRING, (below) is entered, then the SENDSTRING box slows to 1x digit per LOOP.

$GNRMC,123519,A,4807.038,N,01131.000,E,022.4,084.4,230394,003.1,W*6A?1.000,E,022.4,084.4,230394,003.1,W*6A?$REMOTE,1234,4321,1111,1010,5555,6666,?$GNRMC,222222,A,3333.038,N,77777.000,E,022.4,084.4,230394,003.1,W*6A?$REMOTE,1010,4321,0101,101$REMOTE,0000,4321,1111,1010,5555,5432,?$GNRMC,123522,A,1111.038,N,01131.000,E,022.4,084.4,230394,003.1,W*6A?
$GNRMC,123533,A,4855.038,N,01131.000,E,022.4,084.4,230394,003.1,W*6A?$REMOTE,3333,4321,1111,1010,5555,5555,?$REMOTE,4444,4321,1111,1010,5555,9999,?

C.

 

hi,
As the GPS asynchronous message is incoming at a 1 second rate, why not use an Interrupt for the GPS.
The other peripherals, as I recall, are called by the program, ie: on demand.
E

 

hi,
As the GPS asynchronous message is incoming at a 1 second rate, why not use an Interrupt for the GPS.
The other peripherals, as I recall, are called by the program, ie: on demand.
E

Hi E,
See message #66, we skipped it.

Regarding GPS and REMOTE messages, there is a DATASWITCH chip on the PCB, which switches at each message. For cases as no signal, then perhaps an INTERRUPT TOGGLE may be added.
C.

 

What rate is the REMOTE serial coming in.? Is it on demand.?
IE: does the program request the REMOTE data or is it coming in at a fixed interval.?

 

What rate is the REMOTE serial coming in.? Is on demand.?
IE: does the program request the REMOTE data or is it coming in at a fixed interval.?

Hi E,
Not on demand, it will be sent as fast as possible from the REMOTE.
C.

 

hi,
Problem is, if you have two incoming serial sources, using the same HW UART and the two sources are not synchronised, you will most likely get message collisions and data will be lost or corrupted.
Is there any way you can control the REMOTE, to only send data when commanded.? [I know the GPS interval is fixed]
E

 

hi,
Problem is, if you have two incoming serial sources, using the same HW UART and the two sources are not synchronised, you will most likely get message collisions and data will be lost or corrupted.
Is there any way you can control the REMOTE, to only send data when commanded.? [I know the GPS interval is fixed]
E

Hi E,
Are you clear that only 1x message can arrive at the HW UART at a time, because of the DATASWITCH?
C

 

I know that, but what controls the dataswitch and how does it know when to allow in the REMOTE.????

 

I know that, but what controls the dataswitch and how does it know when to allow in the REMOTE.????

Hi E,
At the moment in each GET_VAL section is a switch.
-----------------------------------------------------------------------------------------------------------------------
get_valr: '$REMOTE,1234,4321,1111,1010,5555,6666,?
dataswitch = 1 '0=REMOTE 1=GPS<<<<<<<<<<<<<<<<<<<<<<<<<<<
rled = 1
yled = 0
Select Case csv 'COMMA POSITION VALUES
Case 2
strtx1 = LeftStr(msg1, 4) 'SEND DATA TO REMOTE
Case 3
strtx2 = LeftStr(msg1, 4)
Case 4
strtx3 = LeftStr(msg1, 4)
Case 5
strtx4 = LeftStr(msg1, 4)
Case 6
strtx5 = LeftStr(msg1, 4)
Case 7
strtx6 = LeftStr(msg1, 4)
Case Else
EndSelect
msg1 = ""
Return
--------------------------------------

get_valg: 'GPS $GNRMC,123519,A,4807.038,N,01131.000,E,022.4,084.4,230394,003.1,W*6A?
dataswitch = 0 '0=REMOTE 1=GPS<<<<<<<<<<<<<<<<<<<<<<<<<<<<
yled = 1
rled = 0
Select Case csv 'COMMA POSITION VALUES
Case 2
strtim = LeftStr(msg1, 2) + ":" + MidStr(msg1, 3, 2) + ":" + MidStr(msg1, 5, 2)
Case 4
strlat = LeftStr(msg1, 10) 'Number of digits in the STRING
sinlat = StrValS(strlat)
Case 6
strlong = RightStr(msg1, 11)
sinlong = StrValS(strlong)
Case 12
Case Else
EndSelect
msg1 = ""
Return
-------------------------------------------------------------------------------------------------------

 

Hi S,
...
II'll keep searching searching the DATA SHEET, for the UART RECEIVE REGISTER FLAG/STATUS.
Thanks.
C.

You check PIR1.RCIF if there is a character in RCREG. Even though it is an "interrupt flag", it does not mean you have to use it for interrupts, you can simple loop and check it with a simple read. That flag is set regardless of interrupt settings. Once set, you go read RCREG.
See page 116 of the datasheet. Then read section 18.2.2 (page 215) for how the Receive section of the UART works. Step 7 is important, if you had an overflow, that is where you catch it.

Hserget gives you the option of not "hanging", waiting for a character. It simply reads the register and returns the character or a zero if there is none (Oshonsoft must check the RCIF flag and return zero if not set). Hserin will block until a character arrives, you cannot unblock it.

EDIT: When you read a valid character from RCREG, you MUST read RCREG again for a second character if PIR1.RCIF is still set. That is, RCIF is set as long as there are any characters in the RCREG FIFO (2 characters). In other words, keep reading RCREG until PIR1.RCIF is = 0

Figure 18-7 in the datasheet shows typical data receive of 3 words (to show overflow). However, you see RCREG being read twice (third line down), then PIR1.RCIF being cleared after the second read (4th line down). Since there was a 3rd character after, they show the overflow error in that example.

 

hi C,
With respect that is not answering the question.
What and when decides to select the GPS or REMOTE by using the DataSwitch.???

If the two input serial messages ie: GPS and REM are not synchronised for the intervals which they transmit data.
The two messages could be arriving at the same time or slightly offset at the DataSw input, so which one has priority.

eg1: assume DataSw has selected GPS and its getting msg OK, what if the REM starts sending serial data half way through the GPS, part of REM message will be lost and the trailing bytes will be unread and will raise a OERR.
Likewise if the REM is being received first and then halway thru the GPS starts.

E

 

hi C,
With respect that is not answering the question.
What and when decides to select the GPS or REMOTE by using the DataSwitch.???

If the two input serial messages ie: GPS and REM are not synchronised for the intervals which they transmit data.
The two messages could be arriving at the same time or slightly offset at the DataSw input, so which one has priority.

eg1: assume DataSw has selected GPS and its getting msg OK, what if the REM starts sending serial data half way through the GPS, part of REM message will be lost and the trailing bytes will be unread and will raise a OERR.
Likewise if the REM is being received first and then halway thru the GPS starts.

E

Hi E,
Assuming both GPS and REMOTE are sending clear messages.

Before the LOOP, the DATASWITCH is set one way, 'say' GPS

A GPS message arrives at the UART, is READ and put into [ rxi ] until [ ? or LF ]

[ rxi ] is checked, for either [ If str1(1) = "R" or If str1(5) = "C" ] which GOSUBS to either [ GET_VALR or GET_VALG ] where DATASWITCH is switched to the opposite message, which in this case is REMOTE.

The program then ignores the tail end of the last REMOTE message, and waits for the next $ in the REMOTE message and so on.

In other words one message sets the DATASWITCH to the other MESSAGE, so both messages can never meet.

Is this ok or am I misunderstanding?
C

 

You check PIR1.RCIF if there is a character in RCREG. Even though it is an "interrupt flag", it does not mean you have to use it for interrupts, you can simple loop and check it with a simple read. That flag is set regardless of interrupt settings. Once set, you go read RCREG.
See page 116 of the datasheet. Then read section 18.2.2 (page 215) for how the Receive section of the UART works. Step 7 is important, if you had an overflow, that is where you catch it.

Hserget gives you the option of not "hanging", waiting for a character. It simply reads the register and returns the character or a zero if there is none (Oshonsoft must check the RCIF flag and return zero if not set). Hserin will block until a character arrives, you cannot unblock it.

EDIT: When you read a valid character from RCREG, you MUST read RCREG again for a second character if PIR1.RCIF is still set. That is, RCIF is set as long as there are any characters in the RCREG FIFO (2 characters). In other words, keep reading RCREG until PIR1.RCIF is = 0

Figure 18-7 in the datasheet shows typical data receive of 3 words (to show overflow). However, you see RCREG being read twice (third line down), then PIR1.RCIF being cleared after the second read (4th line down). Since there was a 3rd character after, they show the overflow error in that example.

Hi S,
I'll re-read this and reply again
Thanks
C

 

hi,
For explanation only, assume that GPS data = 80 bytes in length and REM is also 80 bytes.
Say that the GPS data occurs every 1 second and so does the REM data, but the REM data start arrives 20mSec after the GPS start.
With your program you will get the GPS, ID first every time and when the DataSw toggles over then the partial data of the REM will set the OERR, as the buffer will not have been read.

Also if the GPS and REM intervals are running at slightly different occurrence rates which ever is detected first will take priority and the other message will be lost.

Do you follow.?
Is there anyway that you can prevent the REM message being sent until the GPS msg has been Read.?


E

 

hi,
For explanation only, assume that GPS data = 80 bytes in length and REM is also 80 bytes.
Say that the GPS data occurs every 1 second and so does the REM data, but the REM data start arrives 20mSec after the GPS start.
With your program you will get the GPS, ID first every time and when the DataSw toggles over then the partial data of the REM will set the OERR, as the buffer will not have been read.

Also if the GPS and REM intervals are running at slightly different occurrence rates which ever is detected first will take priority and the other message will be lost.

Do you follow.?
Is there anyway that you can prevent the REM message being sent until the GPS msg has been Read.?


E

Hi E,
Yes, I follow.

The DATASWITCH only switches after a full message has been READ and saved, whatever it's length, or it waits till the next '$ of the same type' message. Once saved, the message can be checked for [ RXI (1) and RXI(5) ]

Once completely in, it then switches DATASWITCH to the other type of message, and again does not switch until a full message has been READ and saved, starting with [ $ ] and ending with [ ? or LF ]

I'm pretty sure this is the case! (although you're giving me doubts) This is the intention of how it should be programmed.

C.

 

Stopping a device from sending, depends on the device. There were several different protocols for controlling a serial data stream. But both sides must agree to the protocol.

In early RS232, special signals separate from the data stream were used. Look up RTS/CTS if you’re curious. This technique is rarely used today.

Then there was XON/XOFF, where a reserved character was sent to start/stop transmission. The remote device would have to support these protocols.

Do your devices support flow control? Then whatever they use, you code for.

Software serial libraries do support multiple data streams, but usually restrict communications to one virtual port at a time.

Can any of your devices support a retransmit request? You can code collision detection and request retransmission in case of a collision (garbled reception = collision)

It comes down to what your remote devices support. If they don’t support flow control or retransmission requests, there may be no solution.

You may be able to compensate by extrapolating or interpolating the missed data. If that satisfies your requirements.

Otherwise, I don’t have an answer.