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
    25.5 KB · Views: 403
  • 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
    11.1 KB · Views: 387
  • paul3.bas
    1.3 KB · Views: 428
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


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.
Cookies are required to use this site. You must accept them to continue using the site. Learn more…