HSerin background receive handling question

[Markw996]

Hi,

I'm starting to get the hang of serial coms using my 14m2 chip, but now I'm trying to grasp the concept of background receive on a 20x2.

Before I go ahead and spend weeks writing a program, does my code below look like a good starting point, or am I asking for trouble with data loss at 9600 baud?

I intend to expand the code to use the ptr to locate a string, possibly by using the last byte in the string to step back and read out the whole string from the buffer.

symbol RAD_LED = B.0
symbol BMBO_LED = B.1
symbol MFL_LED = B.2

#picaxe 20x2 'suitable chip with a large background Rx buffer

Init:
	'listen on pin B.6 (leg 11)
	hsersetup B9600_8, %110
	setintflags %00100000,%00100000

Main:
	Do
		pause 100
	Loop

Interrupt:
	let b0 = hSerPtr - 1 'read the last received byte into b0
	
	If b0 = $3B Then 'check if the last byte received is for RAD
		'$3B received
		high RAD_LED
	End If
	
	If b0 = $F0 Then 'check if the last byte received is for BMBO
		'$F0 received
		high BMBO_LED
	End If
	
	If b0 = $50 Then 'check if the last byte received is for MFL
		'$50 received
		high MFL_LED
	End If
	
	'prepare for next byte
	hserinflag = 0
	
	Return

I have spent hours reading posts and Picaxe manuals so I apologise in advance if none of it sunk in and I haven't understood the concept

 

[hippy]

let b0 = hSerPtr - 1 'read the last received byte into b0

That won't get the last byte received, but the last address written into, and that might not always work because it doesn't cater for buffer overflow and wrapround.

The easiest technique is probably to chase 'hserptr' with 'ptr' ...

Interrupt:
Do While ptr <> hseptr
b0 = @ptrinc
Loop
If b0 = $3B then ...

 

[Markw996]

Thanks hippy, I guess I still don't understand pointers

I get the concept of bptr (at least I think I do) referring to the number on the end of each byte, like a label on a box so you can look it up and check inside.
Do ptr & hserptr work in a similar way but referencing the scratchpad?

If hserptr is a counter that stores the position of the last byte of data in the scratchpad, then what does ptr do?

Am I using ptr to catch up with hserptr i.e. hserptr jumps up 5 places (5 bytes received), so my loop runs 5 times until it has caught up?

I don't really understand the loop part either (what a surprise!)
If I don't want to miss any data then shouldn't my IF..THEN.. tests be inside the loop like this:

Interrupt:
	Do While ptr [COLOR="#FF0000"]<[/COLOR] hserptr 
		b0 = [COLOR="#FF0000"]@ptr[/COLOR]
	
		If b0 = $3B Then 'check if the last byte received is for RAD
			'$3B received
			high RAD_LED
		End If
	
		If b0 = $F0 Then 'check if the last byte received is for BMBO
			'$F0 received
			high BMBO_LED
		End If
	
		If b0 = $50 Then 'check if the last byte received is for MFL
			'$50 received
			high MFL_LED
		End If
		[COLOR="#FF0000"]inc ptr[/COLOR]
	Loop
	
	hserinflag = 0 'prepare for next byte
	setintflags %00100000,%00100000 'interrupt every time data is received in the background
	Return

 

[nick12ab]

Do ptr & hserptr work in a similar way but referencing the scratchpad?

Both ptr and hserptr reference the scratchpad. Use @ptr or @hserptr to access the data stored at the location in the scratchpad set by ptr or hserptr.

If hserptr is a counter that stores the position of the last byte of data in the scratchpad, then what does ptr do?

ptr is independent of hserptr. It is ideal for reading data from the scratchpad when there is a chance that more serial data could be received in the background which would overwrite the data you're trying to read if you use hserptr to read the data.

There is also the hserflag which is set once serial data is received in the background. You have to manually clear this afterwards.

 

[Technical]

Both ptr and hserptr reference the scratchpad. Use @ptr or @hserptr to access the data stored at the location in the scratchpad set by ptr or hserptr.

No, that is not correct. You can only use @ptr to access the data. You can use the hserptr value to calculate the last byte received, but it is not used with @

So to get the last byte received you can use
ptr = hserptr - 1
b1 = @ptr

 

[Markw996]

Is there a way to run this in the simulator?

By replacing 'hserin' and 'hserptr' with something that is simulator compatible and typing the serial bytes in manually?

 

[Technical]

The latest PE6 already supports background hserin simulation. No need to replace anything like hserptr, they all work in simulation.

 

[hippy]

Is there a way to run this in the simulator?

The latest version of PE6 (6.0.5.9) simulates hardware background receive.

 

[Markw996]

Thanks, I'm just upgrading now.

I'll be back with more daft questions after I've played around with the simulation for a while

 

[nick12ab]

No, that is not correct. You can only use @ptr to access the data. You can use the hserptr value to calculate the last byte received, but it is not used with @

How silly of me to wrongly assume that PICAXE has something as simple as this [@hserptr] and not bother look it up to check that it actually has it!

 

[lbenson]

How silly of me to wrongly assume that PICAXE has something as simple as this [@hserptr] and not bother look it up to check that it actually has it!

We need more pointers so we can move data within a space

@ptrinc = @ptr2inc

or

@bptr2inc = @bptrinc

 

[JSDL]

how does this loop work when comparing ptr to hserptr? I have seen it in numerous posts but don't quite get the difference yet between the two.

 

[techElder]

From the manual ...

When a byte is received it is saved to this scratchpad
address, the hserptr variable is incremented and the hserinflag flag is set (must be
cleared by user software). Therefore the value &#8216;hserptr -1&#8217; indicates the last byte
written, and &#8216;hserinflag = 1&#8217; indicates a byte has been received

PTR is pointing to a location within SCRATCHPAD. You set that location for changing or reading SCRATCHPAD.

 

[danners430]

Thanks, I'm just upgrading now.

I'll be back with more daft questions after I've played around with the simulation for a while

As long as it's in context, there's no such thing as a silly or stupid question - we've all got to learn somehow, and that's what the forum is for. Just look at some of my posts, and you'll see what I mean