hserout and serial 7 segment display

[queenidog]

This should NOT be that hard, since I have been using other serial commands like Shiftout, and have echoed typed characters on this computer keyboard using hserin and hserout. Having said this...

I'm using a LabX1 with 16F887 MCU, pin 25 which is port C.6 (TX) using the internal EUSART. Interfaced to this is the one line to the Rx of a Sparkfun serial 7-segment display. I've been all over this thing with Serout, HSerout, even Shiftout but cannot make a change. Here's my code. I am making it as simple as possible by doing one thing: dimming the display. Sparkfun says to send a control character ($7A) followed by the value for brightness. I do this. The display does not change brightness. Even now, with no other characters being set, the display is toggling weird characters and the display is at its Dimmest. I set the baud rate too, on principle though the default for the display is 9600 baud.

include "modedefs.bas"
trisc.6=0
LED var portc.6
dEFINE OSC 4
DEFINE HSER_TXSTA 24h ' Enable transmit, BRGH = 1 (b.3=1 means high speed)
'define HSER_BAUD 9600
DEFINE HSER_SPBRG 25 ' 25=9600 Baud @ 4MHz, 0.16%
DEFINE HSER_CLROERR 1 ' Clear overflow automatically

bright con $7A
baud con $7F 'followed by 2=9600 baud, 4=19200 baud

hserout [baud, 2]
Main: HSEROUT [bright, 0] ' 0 is max brightness, $FE is dimmest
pause 100
goto main

I haven't scoped portc.6 yet. That should tell me if there is data and the speed, but is the above all kosher?

[mackrackit]

Does the device require inverted or true mode?

[Megahertz]

hserout [baud, 2]
Main: HSEROUT [bright, 0] ' 0 is max brightness, $FE is dimmest

How about trying this


hserout [HEX baud, 2]
Main: HSEROUT [HEX bright, 0] ' 0 is max brightness, $FE is dimmest

[queenidog]

It doesn't say if it should be inverted or true mode.
I did try [hex bright,0] and other permutations, like sending the Ascii value "z" instead.

I finally put a scope on it and tried to relate the command to the scope trace. This is what I got for $7A (brightness control, Ascii "z")

6566

When I write the binary version out, it is indeed $7A or %0111 1010, except it's back to front. What I would have expected to be the msb at the front end of the trace, is at the back end. In other words, what is being sent is not $7A, but %0101 1110. (At least when I used to demonstrate RS-232 signals, they used to follow that convention). Tell me if I'm wrong.

So, what do you guys figure is happening? Maybe the inverted/true mode business? How do I choose either mode? I was looking at the REV command to reverse all the bits, but that seems rather "kludgy".

The latest code:


DEFINE OSC 4
DEFINE HSER_RCSTA 80h ' Enable serial port (b7=1 to enable TX as serial port pins
DEFINE HSER_TXSTA 24h ' Enable transmit, BRGH = 1
define HSER_BAUD 9600
'DEFINE HSER_SPBRG 25 ' 9600 Baud @ 4MHz, 0.16%
DEFINE HSER_CLROERR 1 ' Clear overflow automatically
trisc.6=0
LED var portc.6
'****The following are the control codes for the Sparkfun serial 7-segment display
decpts con $77 ' "w"
bright con $7A ' "z"
setbaud con $7F '2=9600, 4=19200
reset con $76 ' "v"
lsb con $7B ' "{"
dig2 con $7C ' "|"
dig3 con $7D ' "}"
msb con $7E ' "~"


'hserout [setbaud,2]
Main:
HSEROUT [bright, $ff]
pause 50
goto main

[Dave]

I don't know where you ever thought that IEEE RS232 sent msb... They have been designing hardware USARTS with lsb for about 40+ years. You should Google RS232 protocol.... It's the LAW.....

[queenidog]

You're right, I'm an idiot. Of course it's lsb first. For some STUPID reason I was thinking the first bit was a STOP bit, not a START bit and got the whole thing wonky. It's been awhile since I've had to troubleshoot serial stuff.

Okay, now I've got it and it's even more perplexing that this doesn't work since the display is getting the right code. When I send out [$7A, $55], that's indeed what I see on the scope.

I think it's a timing issue and tried using DEFINE CHARACTER_PACING but that doesn't work either for values 1000 to 20000.

[Charlie]

Silly question, but have you tied the unused inputs appropriately? You may be getting noise resetting things or sending garbage on the SPI port...

[queenidog]

Unused inputs? You mean Rx? Are there more? The 16F887 is in the LabX1, all jumpers are in except the Tx, which I am using as an output.

[queenidog]

I figured what Charlie meant was unused SPI inputs on the display (which can use SPI or serial in). I tied the 3 inputs to ground, no change, then out of frustration (I had already thrown the display in the garbage...)I started hitting each pin with ground. After touching the RST (which I assume is reset), the display started working. No changes in code, and when I took off extraneous wires to the display (ie the 3 SPI inputs) and hooked it up in very basic mode with only SI, Vcc, and ground, it continued to work, even through power cycling and numerous downloads to the host chip (16F887). I can now display anything I want, anywhere I want.