Note that in sagor’s reply, if A[ ] has a dimension of 10, it’s last element is A[9]. This can be confusing. Remember that when an array is used, it’s indices always start at 0. Thus, for n (eg 10) elements, the last element will always be n-1 (eg 9). Also remember that the first element will always be A[0].

 

The variable "A" is the name of the array of bytes, addressable as A(0) to A(9) (10 bytes)

Hi S and D,
Ok, thanks. it makes sense.

I got a 'realisation' !!
The first thing I'm trying to do is send 0 to 359 Degrees from and incremental encoder on an 18F4431. In my 1st post, I ask about adding zeros in front of some data so that there are always 3x digits, keeping the DATA the same length, for parsing, e,g, 001 020, 359.
This is because I use an 18F4431 QEI to output 0 to 359 (after calculation) to the MAIN PIC for use.

Remembering that the QEI outputs 2x BYTEs. I now think, why not send the 2x BYTEs to the MAIN PIC and then do the 0-359 calculation. e,g, DIM QEIDEG(2) as BYTE.

Does this sound good?
C

 

Hi,
Moved back to here: https://forum.allaboutcircuits.com/...location-pic-in-oshonsoft.148795/post-1698621
C

 

hi C,
From what I recall about your project, I would say using a ring buffer is pointless, it will increase the complexity of the program and gobble up memory, which is already tight.
E

Hi E,
I've been playing with 'ring buffers' with interest on ETO, and now understand how they work, and how to PARSE them.

We are at the stage of getting all 4x PICs talking to each other in 'the project', but nearly all of them stall periodically, so 'ring buffer' was a suggestion to cure this, as the UART would not be switched off between sentences.
What do you think?
C.

 

Hi C,
How did the person who suggested using a ring buffer for the 4 UARTs, suggest how it would solve the problem.?

IIRC, your problems are caused by using asynchronous timing of the UARTs when trying to read the data.
Which would still apply to saving data from these sources into a ring buffer.

E

 

Hi C,
How did the person who suggested using a ring buffer for the 4 UARTs, suggest how it would solve the problem.?

IIRC, your problems are caused by using asynchronous timing of the UARTs when trying to read the data.
Which would still apply to saving data from these sources into a ring buffer.

E

Hi E,
True I have 4x PIC talking to each other, but they are pairs. Each BASE and REMOTE pair talk between PICs on each PCB via SPI, and BASE and REMOTE talk to each other via UART/radio link.

The SPIs are called for in turn, and the UARTS toggle between them, so they don't both talk at once.
C.

 

I wonder if part of your problem is that you are shutting off (disabling) the UARTS and then re-enabling them. That may cause some issues if it happens at a high rate. You should leave the UART on and read ALL traffic, and filter it in the receive interrupt routine, either directly or while filling the storage buffer.
I have no proof of this on/off idea, but leaving the UART on and just filtering the data as received is probably the most stable method of using them. Turning things off and on several times a second may cause some unexpected behavior.

 

I wonder if part of your problem is that you are shutting off (disabling) the UARTS and then re-enabling them. That may cause some issues if it happens at a high rate. You should leave the UART on and read ALL traffic, and filter it in the receive interrupt routine, either directly or while filling the storage buffer.
I have no proof of this on/off idea, but leaving the UART on and just filtering the data as received is probably the most stable method of using them. Turning things off and on several times a second may cause some unexpected behavior.

Hi S,
I'm waiting for a reply from another forum, on exctly this. I'm sure I recall, that this is the reason hat I was advised to use 'ring buffers'
I can test the existing 4x programs, by using 'ring buffers', and report back.
This is quite complicated, so it may be a while.
C.

 

Hi C,
Do you have an example of the UART data stream for the 4 UARTs and their transmit period intervals, to post ?
Also are the 4 UARTs transmit intervals synchronised in some way?

E

 

Hi C,
Do you have an example of the UART data stream for the 4 UARTs and their transmit period intervals, to post ?
Also are the 4 UARTs transmit intervals synchronised in some way?

E

Hi E,
(BaseOutRemoteIn RemoteOutBaseIn)

The BASE SLAVE receives GPS NMEA sentences GNRMC, and doesn't transmit.

The BASE MASTER transmits the BORI DATA which is control information for the REMOTE, receive switched off for 10 times, then receives ROBI.
The BASE MASTER transmits [ Hserout "$BORI", ",", strud, ",", strrot, ",", strfr, ",", strlr, ",", strcmd, ",", strbastp, ",", strbaspr, ",", strqeideg, ",", strtofro, ",", "W", " ", CrLf ] '$ to W. Message from BASE to REMOTE.

The REMOTE SLAVE receives GPS NMEA sentences GNRMC, and doesn't transmit.

The REMOTE MASTER transmits [ Hserout "$ROBI,111,1,11,W", CrLf ] This is information from the REMOTE 'say' battery voltage etc.

(I hope this is correct, it was quite difficult to write it)
C.



The REMOTE MASTER receives 10 BORIs then transmits its ROBI
C

 

I wonder if part of your problem is that you are shutting off (disabling) the UARTS and then re-enabling them. That may cause some issues if it happens at a high rate. You should leave the UART on and read ALL traffic, and filter it in the receive interrupt routine, either directly or while filling the storage buffer.
I have no proof of this on/off idea, but leaving the UART on and just filtering the data as received is probably the most stable method of using them. Turning things off and on several times a second may cause some unexpected behavior.

Hi S,
I received this answer from ETO, that may answer what's wrong?
EDIT: If I don't switch the UART OFF, but don't add CHARS into the buffer, will this work, and is it more efficient than saving the 'ring buffer' all of the time?
C
For my working method, the Buffer ring is better. A simple linear buffer may be sufficient for your working method. If you use a linear buffer and it does not work well for you, it may be that the buffer you use is not well defined or structured and has a problem. Buffers in general are used to not stop data entry, data enters the buffer automatically while other processes are running. A GPS that delivers the data frame every 100mSeg leaves a dead time of 100mSeg and this time is very long for a microcontroller, it should give it time to process the input frame and perform many more tasks. The important thing is not to get ahead of the data frame, once the data frame is entered it is processed, in this case the microcontroller goes with a delay frame, in most cases this delay time is not a problem.