Re: 16f88 ausart & defines
You do not need to set the DEFINES at the beginning of your code. You can set the registers as you go. I would setup a couple of sub routines for this.
Re: 16f88 ausart & defines
The code I use at present for the 9600,8,E,1 reception is
Code:
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
Code:
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!!
Re: 16f88 ausart & defines
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:
Quote:
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:
Code:
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.
Re: 16f88 ausart & defines
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.
Re: 16f88 ausart & defines
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???
Quote:
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...
Re: 16f88 ausart & defines
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:
Quote:
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.
Re: 16f88 ausart & defines
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.
Re: 16f88 ausart & defines
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?
Re: 16f88 ausart & defines
What about this:
Do the defines and set it up for pairity. This will make PBP do the math for it.
Then set the registers to 8 bit before HSEROUT and set them back when done.
Re: 16f88 ausart & defines
Now THAT is a good idea! I'll have to play with that in particular application and see how it works.
Thanks!
/Henrik.
Re: 16f88 ausart & defines
Agreed that is a good idea. can you post your code example when tested.
I'll do the same If i get round to it first
OK so assuming i set up HSERIN/OUT for 9 bit even parity
I do my 9 bit recieve then just before I want to do my 8bit transmit i clear the TXSTA TX9 flag
Just a thought though if we clear the TXSTA TX9 flag just before we do the HSEROUt won't it just overwrite it immediately?
Is the TXSTA only loaded once during program execution when the define is executed? I appreciate the parity bit is changed to suit.
Or am I confused.
Re: 16f88 ausart & defines
Hmmm, good point. I was/am assuming PBP sets and forgets it. setting it on each transmission seems like wasted code.
Re: 16f88 ausart & defines
I'm going to try
Code:
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
TXSTA.6 = 0 'Clear 9 Bit Txd Mode
See if that works as clearing the 9 bit mode bit for the txd should hopefully
leave the rxd unaffected and in 9 bit mode.
Perhaps we can ask the pbpro author to support seperate defines for rxd and txd ausart.
Re: 16f88 ausart & defines
This seem to work OK!
So I am receiving my 9600,8,E,1 data on Usart RXD Hserin
and
I am driving my lcd display using Usart TXD at 9600,8,N,1 Hserout
Defines as above in my previous post for parity
I just cleared the 9 bit register TXSTA.6 once at start of program after defines and seems to work fine!! :)
Thanks for all the ideas.
Re: 16f88 ausart & defines
Hi,
I've just tried this at my end and it seems to work fine. The DEFINE sets the RCSTA and TXSTA (once) as well as "tells" the compiler to insert code to calculate the parity bit for each byte it send and receives. If we then "override" and disables the transmision of the 9th bit PBP will still calculate and load that bit into the 9th databit "slot" but it will never get sent out.
In my particular case I'm swiching between using and not using parity for both RX and TX, at runtime, so I had to add dual HSERIN commands in my receive ISR, like:
Code:
If RCSTA.6 = 1 THEN 'If 9th bit reception is enabled we're using parity.
HSERIN ParityError, [RxChar]
ELSE
HSERIN [RxChar]
ENDIF
Goto OverParityError
ParityError:
'Handle it here
OverParityError:
'Continue here....
Thanks again for pointing this, now pretty obvious, way out!
/Henrik.
Re: 16f88 ausart & defines
Ha, talk about coincidence, posting pretty much the same thing at the same time like that. I didn't see your post before writing mine. It's great that you got it working at your end as well!
/Henrik.