button press AND hserout issues?!

[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?

[Giulio]

Thanks for taking time out to consider this, guys!

I tried the code example, and no go. Funny thing is, Henrik, I wrote some inline assembly, which didn't work UNLESS I included a 'dummy' call to hserout at the top of the program, just as you have, and then the assembly worked fine?!?!

The same happened if I tried to do anything else, though.

mister_e, you are correct about the 24h. It DOES work occasionally, but is 'happier' with a 20h - again, I don't know why there should be a 'high' and 'low' mode, or at what speed the selection should be made?

I'm now thinking that the baud rate of 31250 'drifts' if you try to do anything else in the main loop, but is fine if the main loop is nice and stable and executes precisely the same instructions every time, maybe???

Again, thanks for the input!


G

[mackrackit]

It may be advantageous to use the high baud rate
(BRGH = 1) even for slower baud clocks. This is
because the FOSC/(16(X + 1)) equation can reduce the
baud rate error in some cases.
Writing a new value to the SPBRG register causes the
BRG timer to be reset (or cleared) and ensures the
BRG does not wait for a timer overflow before
outputting the new baud rate.
The data on the RB1/RX/DT pin is sampled three times
by a majority detect circuit to determine if a high or a
low level is present at the RX pin.

I wonder....