[sdcc-devel] [ sdcc-Patches-3571327 ] Regenerate the DEVICE.[ch] files with the cinc2h.pl program.

[SourceForge.net <no...@so...>]

Patches item #3571327, was opened at 2012-09-24 13:48
Message generated for change (Comment added) made by borutr
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=300599&aid=3571327&group_id=599

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Molnár Károly (molnarkaroly)
>Assigned to: Borut Ražem (borutr)
Summary: Regenerate the DEVICE.[ch] files with the cinc2h.pl program.

Initial Comment:
In the pic14 and pic16 and branches, uniform the appearance of everything DEVICE.c and DEVICE.h files. Support of bit fields. New pseudo registers:

extern __at(0x0FC3) __sfr ADRES;
extern __at(0x0FC3) volatile unsigned short wADRES;  <------ pseudo register
extern __at(0x0FC3) __sfr ADRESL;
extern __at(0x0FC4) __sfr ADRESH;

-------------------------------------------------

Update the device/lib/pic16/libio/usart/uopen.c file.
No necessary the \"PIR1bits.TXIF_PIR1 = 0;\" line. Instead, it is enough the \"PIR1bits.TXIF = 0;\" line.
No necessary the \"PIE1bits.TXIE_PIE1 = 0;\" line. Instead, it is enough the \"PIE1bits.TXIE = 0;\" line.

----------------------------------------------------------------------

>Comment By: Borut Ražem (borutr)
Date: 2012-10-01 06:00

Message:
Patch applied in svn revision #8127.

Borut

----------------------------------------------------------------------

Comment By: Molnár Károly (molnarkaroly)
Date: 2012-09-28 00:38

Message:
> - in the new device .c files the sfr definitions are:
> __at(<addr>) __sfr <register>;
> old definitions are:
> __sfr __at(<addr>) <register>;
> Is the new syntax correct?

Yes, the sdcc compiles correctly.

> - in the old .h device files (at least some) there were definitions of
sfr
> addresses but they are missing in the new ones. This means broken
backward
> compatibility if somebody is using sfr address symbols in his source
code

In the pic14 series returns that opportunity.

> Karoly, please comment my concerns if you feel I'm wrong or prepare a
new
> set of patches. Please prepare several smaller patches, i.e. first for
> pic14 headers, second for pic14 c files, third for pic16 headers and
fourth
> for pic16 c files, instead of a big one which have to be sliced and then
> merged.

Really better this way.

> I also noticed that 2 extra empty lines are generated at the end of .c
> files. Can this be corrected?

This too I will fix.

----------------------------------------------------------------------

Comment By: Borut Ražem (borutr)
Date: 2012-09-27 12:56

Message:
I also noticed that 2 extra empty lines are generated at the end of .c
files. Can this be corrected?

Borut

----------------------------------------------------------------------

Comment By: Borut Ražem (borutr)
Date: 2012-09-27 12:45

Message:
I took a look to changed device files and I have some concerns:
- in the new device .c files the sfr definitions are:
__at(<addr>) __sfr <register>;
old definitions are:
__sfr __at(<addr>) <register>;
Is the new syntax correct?

- in the old .h device files (at least some) there were definitions of sfr
addresses but they are missing in the new ones. This means broken backward
compatibility if somebody is using sfr address symbols in his source code

- in the copyright notice Karoly's first and second name is written using
non ASCII characters. This characters are utf-8 encoded. Since utf-8 is
(still) not the default encoding on many platforms and is not supported by
many editors I propose to keep the source files in plain ASCII encoding.

- I already fixed a typo in all (c)inc2h*.pl scripts so the device files
have to be regenerated.

Karoly, please comment my concerns if you feel I'm wrong or prepare a new
set of patches. Please prepare several smaller patches, i.e. first for
pic14 headers, second for pic14 c files, third for pic16 headers and fourth
for pic16 c files, instead of a big one which have to be sliced and then
merged.

Borut


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=300599&aid=3571327&group_id=599