Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

Reading Packets?

Status
Not open for further replies.
The string function in Oshonsoft is non existent.. You need to use a circular buffer..

Create an input buffer that is longer than the incoming string...
Also create two variables to monitor the input

Code:
dim inpbuffer(40) as byte
dim inptr as word
dim outptr as word

Set an interrupt with the hardware serial port

Code:
On Interrupt
	Save System
	If RCSTA.OERR = True Then
			RCSTA.CREN = 0
			RCSTA.CREN = 1
			Goto fin
	Endif
	inpbuffer(inptr) = RCREG
	inptr = inptr + 1
	If inptr = 39 Then inptr = 0
	If inbuff(inptr) = 0x2e Then outptr = inptr    ; set the Character recognition here
fin:
Resume

Once you have received the character you waited for... You can then parse the string...
 
Hi Lanquer.

I realised that was the problem but have now switched to NMEA protocal. I have started a new thread on this and could really use some help.

Regards - Paul

hi Paul,
This is a simple way to extract parts of a string, if you have the maths option with Oshonsoft use PROC /FUNCTION.

At the end of a NEMA string there is a CRLF string 0x0d , 0x10.
Use the CRLF terminator to end the Array loading.

I used copy and paste to enter the $ string into the Oshonsoft hardware UART window,

The UART transmit mode is just to verify the string in testing.
Eric
 

Attachments

  • AAesp01.gif
    AAesp01.gif
    25.5 KB · Views: 402
  • AAesp02.gif
    AAesp02.gif
    25 KB · Views: 393
  • paul1.bas
    1.9 KB · Views: 418
hi Paul,

This option is tidier, I use the UART as an output display.

Copy and paste the GPS string located at the top of the Basic listing, into the Oshonsoft UART for testing.

Eric
 

Attachments

  • AAesp03.gif
    AAesp03.gif
    11.1 KB · Views: 387
  • paul3.bas
    1.3 KB · Views: 427
Hi Eric.

Thanks for this. I have 'adapted' the code to use a while end looking for 0x0d (cr). I think that will work.

I have started a new thread with the GPS code embedded into the earlier RTTY code. - Still having a few problems but I'm sure it's either timing or im doing something really wrong.
 
Hello Ian.

Having researched things a bit further it appears that my code is crashing because the hserin bufer gets overloaded.

I have looked at your code but i'm not quite sure what it does.

I have never used interupts before as to be honest I could never get my head around what was going on.

It appears the only way I am going to fix my code is to do something about how the buffer works. Your code may well fix this.

More research found this from microchip

Solution
The most common cause USART reception stops is a result of overflowing the received buffer. A receive buffer overflow can occur when interrupt or polling response, relative to the incoming data rate causes the overflow and disabling of the receiver.

Methods of testing in code:
once entering the RCIF interrupt handler, test for framing (RCSTA<FERR>) or overrun (RCSTA<OERR>) error. If RCSTA<OERR> is set, the error condition can be reset by cycling the RCSTA<CREN>, low then high for one instruction cycle each. After removing the error condition, read the RCREG register until PIR1<RCIF> is clear.

USART overrun error prevention:
1. quaruntee by design, no single interrupt handler or software routine lasts longer than 1/10 * (usart data byte reception period)
2. test for (RCSTA<OERR> and (RCSTA<FERR>
if RCSTA<OERR> is set, cycle RCSTA<CREN> and empty out REREG
3. when an interrupt handler is entered because PIR1<RCIF> =1, read all waiting byte from RCREG unitl PIR1<RCIF> is clear.

Things are begining to become a little clearer.
I'm still unsure as how the interupt is triggered and I assume that you don't use HSERIN with this as the contents of the UART RX are placed in the array inpbuffer.
 
The idea is.. If you let an interrupt take care of fast incoming data.. The interrupt places all the input into a large buffer so you don't miss anything... Only when you see a character in the buffer do you need to do something about it... I use flags to indicate when the array needs my attention..


Interrupts in oshonsoft are very easy to work with... All registers are available to you so you don't need to use ANY inbuilt functions.. Just initialise the HSEROPEN.... and then manually set the interrupts then every time a character arrives in the RXREG the interrupt places it in a queue...

Using interrupts isn't daunting in fact when you get one up and running you will wonder why you never used them before.... Remeber that all the NMEA sentences end with the characters " 0x0A 0x0C " so when they arrive set the outptr to the same as the inptr.. Then your main loop can see its here.... Look at the first five characters if its the NMEA sentence you want work on it.. If not clear the buffer and wait again..
 
Status
Not open for further replies.

Latest threads

New Articles From Microcontroller Tips

Back
Top