16f88 ausart & defines

[retepsnikrep]

The code I use at present for the 9600,8,E,1 reception is

DEFINE HSER_BAUD 9600		'Set Baud rate to 9600bps
DEFINE HSER_BITS 9		'Set to 9 bit mode
DEFINE HSER_EVEN 1		'Set Even Parity
DEFINE HSER_CLROERR 1 		'Clear overflow error automatically

HSERIN [WAIT($87), STR BCMDATA\11]	'Wait for packet start $87 then Rxd 11 bytes into BCMDATA

The code i use for the 9600,8,N,1 Transmission is

DEFINE HSER_BAUD 9600		'Set Baud rate to 9600bps

HSEROUT [254,192,"Cruise ",#Cruise," Duty ",#DutyCycle]	'Display

Both the above work fine in seperate programs, my program now needs to combine them into one and swap between one and the other
during execution.

So receive some data with parity, process it, then spit it out without parity and repeat.

Could you help with an example? Your subroutine? Or what registers to change?
I need to use hserin/out if i can as i can understand it and i'm working with arrays for the rxd data!!

[mackrackit]

If you have not been using mr. E's PicMulticalc grab it over here.
http://www.picbasic.co.uk/forum/cont....-PICMultiCalc

Quick example of not using DEFINES.
MultiCalc gives this for 9600 Baud at 20Mhz:

RCSTA = $90 ' Enable serial port & continuous receive
TXSTA = $24 ' Enable transmit, BRGH = 1
SPBRG = 129 ' 9600 Baud @ 20MHz, 0.16%

So the code would be something like this:

Send_Data: 'Sending Sub
RCSTA.4 = 0 : RCSTA.4 = 1
RCSTA=$90:TXSTA=$24:SPBRG=129:HSEROUT[254,192,"Cruise ",#Cruise," Duty ",#DutyCycle]
RETURN

Because DEFINES are not used you can change things around at will. Just do the changing in Sub-routines then GOSUB when ever needed.

[HenrikOlsson]

Hi,
I'm currently working on something similar and have been thinking about this for a while. I'm afraid (though I DO wish I'm wrong) that it's not as easy as just setting the registers manually.

Yes, you can control the way the (E)USART operates and enable it to send and/or receive 9 bits but the problem is that the DEFINE HSER_EVEN 1 and HSER_BITS 9 not only controls those registers, it also controls the way PBP generates the code.

When using parity PBP has to calculate the parity bit for each byte it sends and "load" that bit into the TX9 location of the TXSTA register. (And similar for the RX-part of course). If you don't DEFINE HSER_EVEN PBP doesn't calculate the parity bit so simply enabling 9 bit transmision and/or reception by setting up RXSTA and TXSTA properly isn't enough I'm afraid.

My personal project involves allowing the enduser to select between using parity or not which means it has to be done at runtime - not at buildtime.

Looking forward to a disussion and hopefully a solution!

/Henrik.

[mackrackit]

You might be correct, to be honest I do not use 9 bit that often so that may be the problem. I do use the register thing other wise. I had e a project a few years ago where the Baud needed to be changed on the fly.

I am looking at PBPPI18L.LIB. I think the 9 bit stuff is done in hardware. Looks to me changing the RCSTA or TXSTA values is all that is needed???

ifndef HSER_BITS
HSER_BITS = 8 ; Default to 8 bits
endif
ifndef HSER_RCSTA ; Receive register data
if (HSER_BITS != 9)
HSER_RCSTA EQU 90h ; Receiver enabled
else
HSER_RCSTA EQU 0d0h ; Receiver enabled for 9 bits
endif
endif
ifndef HSER_TXSTA ; Transmit register data
if (HSER_BITS != 9)
HSER_TXSTA EQU 20h ; Transmitter enabled
else
HSER_TXSTA EQU 60h ; Transmitter enabled for 9 bits
endif
endif

I guess someone will have to give it a try...

[HenrikOlsson]

Hi Dave,
The 9th bit is handled in hardware as far as physically sending and/or receiving it but the firmware has to actually put that 9th bit into TXSTA.0 pretty much like it has to put the "normal" 8 bits into TXREG.

Here's a quote from ESUART section of the datasheet for the 18F25K22:

Parity is not supported by the hardware, but can implemented is software and stored as the ninth data bit.

HSEROUT handles this nicely but only when tell it to do so by using the DEFINE HSER_EVEN and HSER_BITS 9, for example. So the DEFINE does not ONLY enable the 9th bit transmision/reception by setting bit6 in TXSTA/RCSTA but it also adds code to actually calculate the paritybit and load into TXSTA.0 when transmitting and get it out of RCSTA when receiving.

One way to see that this is the case, short of looking at the lst/asm files is to compare the filesize of the generated code with and without parity "defined".

I'd love to find a way to switch this at runtime but currently I have no idea how to do it except abandon HSEROUT/HSERIN completely.

/Henrik.

[cncmachineguy]

Can't you calc the parity yourself based on if you want it? I realize this is not as clean as lettine PBP do it, but it will solve you problem and still allow HSERIN/OUT. I think.

[retepsnikrep]

I tried to sidestep this issue by using HSERIN set up for 9 bits with even parity for my reception routine and debug at 9600,8,N,1 for my serial lcd driver routine.

But debug output stops working as soon as the hserin defines are enabled. The debug output is on the Asuart TX side as i was hoping to use HSEROUT so perhaps there is a conflict there?

Any more ideas?