button press AND hserout issues?!

[Giulio]

Yes, I didn't want to waste space by showing my initialisation code, but:

CMCON = 7

and to isolate the one switch for testing:

TRISA = %00000010



G

[mackrackit]

if not porta.1 then
hserout [144,90,90]
endif

FAIL! Whereas the analyser was consistent before, now it fails every so often, showing error messages/system reset errors, etc., which leads me to believe there are timing issues with the USART that the if...then and porta.0

You may want to post your whole code...

[Giulio]

The porta.0 was a typo in my message - the code was exact. This works, every time, and doesn't skip a beat:


define OSC 20

DEFINE HSER_TXSTA 24H
DEFINE HSER_BAUD 31250

main:

CMCON = 7
TRISA = %00000010
TRISB = 0


loop:

hserout [144,90,90]

goto loop

;---------------------------------------

This also works some of the time, but midi analyser shows 'error' periodically, and results are spurious:


define OSC 20

DEFINE HSER_TXSTA 24H
DEFINE HSER_BAUD 31250

main:

CMCON = 7
TRISA = %00000010
TRISB = 0


loop:

if not porta.1 then
hserout [144,90,90]
endif

goto loop

;-------------------------------------

As I said, the if...then, and the test for button is most certainly doing something to the hserout command. I've tried putting a PAUSE [x] before and after and both before and after the hserout command, and it just slows things up, and still produces errors at the midi analyser... ???


G

[cncmachineguy]

Just for kicks, change the loop label to something other then loop. That is a keyword in later releases and maybe it is playing up on the IF?

And maybe put a check after the HSEROUT to check if the transmission is done. Maybe the transmission is colliding with the next time through loop since there is nothing else to do? Of course that doesn't explain why the first one works.

[Giulio]

Did this:

define OSC 20

DEFINE HSER_TXSTA 24H
DEFINE HSER_BAUD 31250

main:

CMCON = 7
TRISA = %00000010


lp1:

hserout [147,100,100]

pause 1000

goto lp1

;---------------------------------------

changed the label to lp1 [I usually get some kind of warning for reserved words], and added a long pause, and everything is fine. This corresponds to a note on message on channel 4 and, sure enough, the analyser shows exactly that, then the leds on the analyser go off according to the pause time [I've tried longer and shorter], and never misses a beat or gives an error.

Tried this, by way of a debug/test:


define OSC 20

DEFINE HSER_TXSTA 24H
DEFINE HSER_BAUD 31250

main:

CMCON = 7
TRISA = %00000010
TRISB = %00000000
OPTION_REG.7 = 0

lp1:

portb.3 = 0
if not porta.1 then
portb.3 = 1
endif

goto lp1

;----------------------------------

Sure enough, the led on pin 9, [portb.3] comes on when I press the switch connected to pin 18 [porta.1] and goes off when I release it, perfectly. The switch is pulled up to 5v via a 10k resistor, with the connection to the pin on the switch side of the resistor. Multimeter shows 5.18v on no press, and .082v on press, so well beyond the logic transition levels. Besides, I'm content with the switches, and have done a lot of playing with them, so I'm sure there's no issue with the hardware.

However, if I put the hserout command in, after the led on command, thus:


portb.3 = 0
if not porta.1 then
portb.3 = 1
hserout [144,100,100]
endif

then the note on message NEVER works, even with a suitable pause after. The analyser shows 'error', 'system reset', and the odd spurious code, like 'song select', which tells me that the timing for the hserout is failing badly.

I've wasted hours on this, and it's extremely frustrating. I've never coded the USART in assembler, but think my time might be best used doing so, instead of trying to work around the obvious problems inherent with this compiled language.

This reminds me of the problems I had with a serial LCD display. If I tried to use any interrupts, the display would go off, or show random characters, so the hserout command, or at least the assembly language behind it, must be using one or more of the timers, and other resources. Can I be bothered to pore over the disassembly? Probably not...

G

[HenrikOlsson]

Hi,
In your latest post, first example you're sending 144,100,100 and in the second example you're sending 147,100,100. I know nothing about MIDI and I suspect this has nothing to do with the problem but I mention it anyway.

OK, try this, just as a test:

HSEROUT [147, 100, 100]  '  Dummy output, try removing this if "everything" works.
 
Pause 500
 
LP1:
  If PortA.1 = 0 THEN
    TXREG = 147 : GOSUB WaitForIt
    TXREG = 100 : GOSUB WaitForIt
    TXREG = 100 : GOSUB WaitForIt
    While PortA.1 : WEND  ' Wait for button to be released.
  ENDIF
Goto LP1
 
WaitForIt:
  While PIR1.4 : WEND   ' Wait for TXREG to clear.
RETURN

Personally I don't think there's a problem with HSEROUT per se, I've never had any problem/bug with that but that's no guarantee. Unfortunately I don't have another suggestion on what might be the problem... You don't happen to have a logic analyzer that you can monitor the serial line with?

[mister_e]

The logic analyser may help, but for MIDI I would suggest you to install MIDI-OX and monitor it directly on your PC. It's like a Hyperterminal but for MIDI... assuming you have a USB to MIDI or else MIDI interface attached to your PC.

OR some Terminal may read 31250 BAUDs.

Still the issue make no sense, which version of PBP are you using? What if you use 3 HSEROUT?
what if you add

DEFINE HSER_RCSTA 90h

Last thing, are you really sure TXSTA need to be 24?