button press AND hserout issues?!

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

[HenrikOlsson]

Hi,
The dummy HSEROUT just forces a "proper" setup of the USART, it can just as well be done manually. When your inline assembly didn't work it was missing something in USART setup. (Been there...)

Using Steves excellent tool (PICMultiCalc (thanks again Steve!)) suggests the following for 31250baud @ 20MHz:

DEFINE HSER_RCSTA 90h ' Enable serial port & continuous receive
DEFINE HSER_TXSTA 20h ' Enable transmit, BRGH = 0
DEFINE HSER_CLROERR 1 ' Clear overflow automatically
DEFINE HSER_SPBRG 39  ' 31250 Baud @ 20MHz, 0,0%
SPBRGH = 0
BAUDCON.3 = 1         ' Enable 16 bit baudrate generator

Try that and remove the DEFINE HSERBAUD 31250 and see what happends. The weird thing is that since you say it works perfectly when you send continously the baudrate "must" be correct and adding the button check really shouldn't matter.

[mister_e]

Writing to the SPBRG register ought to solve the problem if it's a baudrate error thingy. IF so, my guess is the math done at compile time are so so. Hence the PîcMultiCalc.

PS: you'll need to remove those 2 line for the PIC16F628
SPBRGH = 0 BAUDCON.3 = 1 ' Enable 16 bit baudrate generator

Still the issue is weird, I would like to see the whole code....

[Giulio]

The whole code is above! It was just a few lines before things started going awry...

For everybody's info (and thanking you all again for your input), I transferred over to a 18F4550, which is total overkill for the MIDI project, but I had a couple lying around with future projects in mind.

Result: Works perfectly every time! Button press on a porta pin calls hserout, and the MIDI analyser never shows an error, just the expected leds lighting up according to note on, control change, etc...

So I'm now sticking with a sledgehammer to crack a nut - at least the sledgehammer works! I have no idea why the 16F628A is failing in this respect, and I shall avoid this particular chip for MIDI, but at least I now have a working prototype. Thanks again.

G

[mister_e]

I would bet it is not a 20Mhz rated one... or badly rated

Hammer time!