hserin with Interrupt Question

[fcd72]

Ladies and Gentleman,

I'm trying to route a Stream of MIDI Data thru a 20x2 (probably upgrade to 28x2@64MHz) using this code:

init:
hsersetup B31250_16, %001             '31500baud, background receive
hserptr = 0                                    'SET POINTER TO BUFFER START (NECESSARY??)
setintflags %00100000, %00100000    'SET INTERRUPT FOR BREAKING AT BACKGROUND RECEIVE

main:
'doing some pot scanning, processing and sending MIDI data vie hserout

interrupt: 
	midicounter = 0				        'SET COUNTER TO 0
	DO UNTIL midicounter = hserptr	        'DO UNTIL BUFFER END
		GET midicounter, midibyte	        'READ A BYTE FROM THE BUFFER
		HSEROUT 0, (midibyte)  	        'WRITE THIS TO PORT
		midicounter = midicounter +1	'INCREASE COUNTER
	LOOP	

	hserptr = 0                                         'RESET BUFFER POINTER
	hserinflag = 0                                     'RESET FLAG
	SETINTFLAGS %00100000, %00100000    'REENABLE INTERRUPT

RETURN

While it runs fine if there is nothing to forward and/or nothing much going on in the main part of the Program it seems to drop a bit of Data under load.
I implemented Code in the Interrupt Routine that stops execution if there is a Buffer overrun but as it never occurred i removed this so i am pretty shure that this is not the case.

So sorry if I bother you with questions as i am on tour and have a bit of time to think about it while being on the train, heres what i think i could change to make it work better:

• Maybe it jumps into the Interrupt while the hserout Command is cranking out some bytes with "hserout 0,(b0, b1, pot value)", thus disabling the interrupt while sending Data would help

• Same thoughts as above for sending Data to the Display with "serout display, N2400_16, (b1, b2, b3)". Maybe integrate the Display into the 28X2s code and saving the 2nd PicAxe and save sending Data serially (which is a bit glacieresque...)

• Main Concern: should i better read the buffer circular (with overflow) rather than resetting the serial Pointer?

• Or is it just the 20X2 being to slow at 16MHz?

Any thoughts highly welcome - and please apologize my bad english!

Thanks in advance,

Frank

 

[Technical]

hserout won't cause loss of data, but serout could definately do so. See the interrupts section in the conflicting commands appendix of the manual part 2. Basically the PICAXE can't fire its own internal (silicon) interrupts whilst doing timing sensitive things like serout. If you get three hserin bytes received during a long serout one of those three may get dropped (hserin silicon buffer is only two bytes deep)

 

[fcd72]

Thanks a lot, thats exactly the answer i needed. So ill integrate the Display Driver Code into a 28X2 and everything should work fine since there is no more SerOut commands.

Ill try and report back.

Thanks again,
Frank

 

[hippy]

There's also a potential issue with resetting hserptr=0 as anything which arrives between you thinking you have everything and it being reset will be lost; a free-running circular buffer would be easier and arguably best.

I'd be tempted to do polling rather than interrupts and that could be better anyway as you may have to do some state analysis of the MIDI stream because you could otherwise put your pot data out at a time which causes subsequent data to be lost or corrupt -

If you play a note you could have : Note-On key velocity | pause | key 0

Inserting something into the pause, such as sending a pot as a controller change, will alter the Running Status of the stream such that the 'key 0' is no longer a note off but another controller change command.

You also have to be very careful with interrupts because the way you have it if a byte arrives between resetting hserptr=0 and hserinflag=0 then you won't see an interrupt until a second byte arrives. In some cases you won't notice that, but occasionally you might.

Finally, you might not have realised it, but the 20X2 will run at 64MHz, simply use SETFREQ M64. No need to upgrade to a 28X2 though doing so will give you a much larger background buffer, though with it being emptied fairly quickly that may not be much of a benefit.

 

[Goeytex]

I would first try bumping the 20x2 up to either 32MHz or 64MHz and see what happens. Then try the circular method.