Hi William,
I have already cast an eye over the include file and came to a similar conclusion.
I was hoping that someone may have already addressed this issue and come up with a mod to the .h file or maybe some separate code for the second port.
Peter.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
After looking at USART.H again, it might be simplest just to duplicate all the code, change Hser text to Hser2 and paste this modified code at the bottom of the file. You would then have to change all the register references in the new code section to those for the second port. Not that difficult to do.
The new routines would then be referenced as Hser2Print etc.
Probably the quickest fix, but not elegant or efficient.
Does anyone have any comments for or against this approach or suggestions for a better way to achieve hardware support for the 2nd USART port?
Peter.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You must take care with the register names and bits. I am not sure that they are consistent among the entire range of PICs that have 2 USASRTS/EUSARTS.
Consider also that there are a handful of PICS that have 4 USARTS. What do we do with these ?
I could be wrong, but I don't think that adding support for a second port will be as trivial as a copy and paste.
I may give it a try and see what I can come up with. But it will not be before next week sometime.
In the meantime can you use software serial for the second port?
Recent changes have significantly improved baud rate accuracy up to 19200 baud. However if you need bauds rates over 19200 you are limited to Hardware Serial
Last edit: William Roth 2015-04-30
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I really can not use the s/w serial in this application. I need both ports running at 9600bps. Both Rx channels also feed into 2 x circular lists (64bytes each) so that the CPU has plenty of time to do other things and I do not miss received characters on either port. Ideally, I would like to run 1 port at a much higher baud rate if I possibly can (maybe 156k).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
At least for the short term, I think I will focus on a quick modification that will work with the PIC 18F26K22. I have a project deadline to meet.
In the longer term, GCGB & GCB need updated HSer routines to add a second parameter that describes the port number. These new routines need the be backward compatible with the current arrangements. I haven't got the knowledge to tackle this approach.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Where do I find details for using the second USART port on some of the PIC chips?
I have a need to use both USART ports within GCGB.
Does GCGB support this or do I have to write my own code/modify the library files to do this?
Peter.
A quick look at USART.H indicates that currently there is only support for one USART port.
Hi William,
I have already cast an eye over the include file and came to a similar conclusion.
I was hoping that someone may have already addressed this issue and come up with a mod to the .h file or maybe some separate code for the second port.
Peter.
After looking at USART.H again, it might be simplest just to duplicate all the code, change Hser text to Hser2 and paste this modified code at the bottom of the file. You would then have to change all the register references in the new code section to those for the second port. Not that difficult to do.
The new routines would then be referenced as Hser2Print etc.
Probably the quickest fix, but not elegant or efficient.
Does anyone have any comments for or against this approach or suggestions for a better way to achieve hardware support for the 2nd USART port?
Peter.
You must take care with the register names and bits. I am not sure that they are consistent among the entire range of PICs that have 2 USASRTS/EUSARTS.
Consider also that there are a handful of PICS that have 4 USARTS. What do we do with these ?
I could be wrong, but I don't think that adding support for a second port will be as trivial as a copy and paste.
I may give it a try and see what I can come up with. But it will not be before next week sometime.
In the meantime can you use software serial for the second port?
Recent changes have significantly improved baud rate accuracy up to 19200 baud. However if you need bauds rates over 19200 you are limited to Hardware Serial
Last edit: William Roth 2015-04-30
I really can not use the s/w serial in this application. I need both ports running at 9600bps. Both Rx channels also feed into 2 x circular lists (64bytes each) so that the CPU has plenty of time to do other things and I do not miss received characters on either port. Ideally, I would like to run 1 port at a much higher baud rate if I possibly can (maybe 156k).
At least for the short term, I think I will focus on a quick modification that will work with the PIC 18F26K22. I have a project deadline to meet.
In the longer term, GCGB & GCB need updated HSer routines to add a second parameter that describes the port number. These new routines need the be backward compatible with the current arrangements. I haven't got the knowledge to tackle this approach.