Support of PICs with more than one USARTs

[GoogleCodeExporter]

It is desirable that the serial libs support at least
one USART of PICs with multiple USARTs.  
The serial libraries support currently only PICs
with a single USART. PICs with more than one USART
are not supported for several reasons:
1. their register names have a number suffix
   (e.g. for the 18F6310 RCSTA1 in stead of RCSTA, etc.)
2. the interrupt bits for the second and further
   USARTs have no direct relatioship with this suffix
   (e.g. for the 18F6310 the TX2IF bit is in PIR3).

Original issue reported on code.google.com by robhamerling on 24 Jan 2010 at 8:47

[GoogleCodeExporter]

The support for _one_ USART can relatively easy be provided
by supplying an alias for each of the USART registers.  
There were several suggestions for the place of these aliases.
The preferred place seems to be the existing serial libraries.
An alternative place is the device files of the concerned PICs,
similarly as provided by MPLAB for MPASM. For example the 
include file p18f6310.inc contains: 

RCSTA     EQU  H'0FAB'
RCSTA1    EQU  H'0FAB'

In MPLAB this is done for the first USART only.

For consistency reasons the Jallib device files could
adopt this method by providing aliases for the
registers and their subfields of the first USART.

Original comment by robhamerling on 24 Jan 2010 at 9:19

[GoogleCodeExporter]

Regardless which files will get the required aliases the device files require 
some
additional declarations (or changes) because of differences in the naming 
conventions
of interrupt bits.  Some device files of PICs with multiple USARTs use for 
example
for the receive interrupt enable bit the name PIR1_RCIE, others the name 
PIR1_RC1IE,
and there are similar naming differences for other bits. These naming 
differences
have to be straightened out.

In the past there was a similar issue with PICs with multiple [E]CCP modules. 

Original comment by robhamerling on 24 Jan 2010 at 3:57

[GoogleCodeExporter]

I've done some analysis of the naming of [E]USART registers in the device files.
These are my observations:
- Extended USARTs have an accompanying BAUDCON register (with a.o. BRG16 bit)
  ordinary USARTs have no BAUDCON register
- PICs with a single EUSART have no number suffix (RCSTA, TXSTA), but 
  some (18F2450) have BAUDCON1 in stead of BAUDCON). 
  A rename to BAUDCON somes appropriate, or at least a BAUDCON alias.
- No midrange PIC has more than 1 [E]USART
- No PIC has more than 2 [E]USARTs, 
- Of PICs with 2 USARTs zero, one or both can be extended
- PICs with 2 USARTs have number suffixes (RCSTA1, RCSTA2) and similarly
  for TXSTA, BAUDCON. 
- Some PICs with 1 [E]USART have also a number suffix (eg. 18F67J60)
  Correction or an unnubered alias seems appropriate.

Original comment by robhamerling on 30 Jan 2010 at 7:41

[GoogleCodeExporter]

{continuation of Comment 3}
- correction: some future midrange PICs (16[L]F1946/47) have 2 USARTs
- interrupt bits of only USART have no number-suffix and are in PIR1,PIE1
- interrupt bits of first USART have most of the times suffix '1',
  but sometimes (a.o. 18f6310) no suffix, and are in PIR1,PIE1
- interrupt bits of second USART have suffix '2' and are mostly in PIR3,PIE3, 
  but sometimes in PIR4,PIE4 (16[L]F1946/47)

Note: The MPLAB device files contain error and omissions, and these 'rules' may 
have
to be adjusted later.....

I suggest the following naming normalisation (consistent with CCP modules)
- for PICs with 1 USART:
  * no number suffix for registers and interrupt bits
- for PICS with 2 USARTs: 
  * first USART: suffix '1' for all USART registers and interrupt bits
    and an alias without suffix 
  * second USART: suffix '2' for all USART registers and interrupt bits
Distinction between 'extended' and 'legacy' USART is the presence of 
BAUDCON[x], to be determined in the serial libraries: defined(BAUDCON[x]). 

Original comment by robhamerling on 31 Jan 2010 at 9:28

[GoogleCodeExporter]

One question I often have when you normalize device files like that: don't you 
want
to keep the normalization "layer" distinct from raw information coming from 
MPLAB ?
For instance, there are lots of registers not well suffixed here, and you're 
going to
make them more "logical" (normalization). Will you keep original bad suffixed
register, and create aliases ? Or just replace them ?

Anyway, I can see you log these normalizations in your device files 
documentation.

Original comment by sebastie...@gmail.com on 31 Jan 2010 at 9:40

[GoogleCodeExporter]

Is this about the dev2jal script, or about having device files in different 
flavours
(raw, normalised, mixed)?

The generation of the device files for JalV2 is indeed a combination of format
conversion of MPLAB files and smoothing out the many anomalies and errors in 
MPLAB.
The dev2jal script has both aspects integrated. It has developed itself that 
way over
time and I think it will be quite some work to split these. The dev2jal script
contains comments where normalisation or error correction is performed to help
maintanability.

The normalisation is broadly outlined in devicefiles.html and in most cases per 
PIC
component documented in quite some detail.  

When I would have had from the beginning the knowledge which I collected during 
the
development of the dev2jal script in the last two years I might have done it
differently.  Spliting may be an improvement for maintenanability, although I 
think
it is reasonably maintainable today (pretty well structured and documented). 

About having two flavours of the device files: I don't see the benefit.  The raw
files (inclusive MPLAB errors!) are hardly useful for any purpose, certainly 
not for
libraries. And of a mixed format only the normalised part would be useful. So 
why
keeping the raw format?

Original comment by robhamerling on 31 Jan 2010 at 10:52

[GoogleCodeExporter]

It's not about having two flavours of device files, indeed I don't see the 
benefit
either. It's about being able to view the different layers: raw / normalized, to
understand how it is done (and promote this important point). But you answer my
question: your dev2jal script holds the normalization step with documentation.

Original comment by sebastie...@gmail.com on 31 Jan 2010 at 11:34

[GoogleCodeExporter]

New device files have been committed (revision 16. For PICs with 2 UARTs these
contain aliases as suggested above (names without suffixes) for USART 1. Where 
the
MPLAB .dev files an contain unqualified name (and no name with suffix) an alias 
with
'1' suffix is added (applies mainly to interrupt bits).  When in the future 
libraries
will be developed which support more than 1 USART these libraries can (should) 
make
use of qualified names.  

Some samples have been added which show the use of a serial library for the 
first
USART of PICs with 2 USARTs (ic. for 18F6310, 18F6520).    

Original comment by robhamerling on 2 Feb 2010 at 6:45

• Changed state: Fixed