colouring and case of some bit names

[See_Mos]

Only a minor thing.

I just noticed that there is no option to colour some bit names
and they are not case sensitive so that intCONBits_RBIF and IntConBits_rbif are accepted.

The old IDE colours the names but it also does not adjust the case of different formats within the same code.

[Giuseppe]

which ide do you mean?

[See_Mos]

The post is in the Proton Studio section so I am referring to Proton Studio

The original IDE refers to the Mecanique Proton IDE

[JohnB]

@See_Mos Currently I am taking the bit names from the .def file.  These are the bit names that Les uses internally.  The alternative is to use the PPI file. I'm at a quandary over which to use, maybe someone could enlighten me, it would be a very simple matter to change to the PPI file names but I don't want to make it an option under tools.  So would welcome users comments.

[top204]

John.

The compiler uses the SFRbits_Name  meta-macros from the .def file. The PPI file only has the bit numbers as assembler aliases, and these are not used by the user's BASIC program.

The .def files are created from the ppi files at development times, but any changes I make to the SFRbits_Name  macros are always made to the .def files only.

So any references to the SFRbits_Name  meta-macros in the IDE should always be read from the .def file. If it is not in the .def file, it does not exist, or it was not in the original data from Microchip, so it has not been enetered into the .def file.

[JohnB]

@top204
I assume you are saying that I am correctly using the .def files and should not be using the PPI bitnames.

[JohnB]

@See_Mos
If you look at the naming convention in the .def file you will see that the bit names take the form:
RegNameBits_BitName
where RegName and BitName are the names of the corresponding Registers and Bits.
BIts named in this format should be immediately recognised by the compiler without the need for aliasing. 
If you use the Bitname alone, you will have add a symbol definition for each bit.
e.g. Symbol UARTEN = U1Mode.15

[top204]

Yes John. You are correctly using the .def files for the meta-macro bit names in the IDE.

Because of things like: Symbol UARTEN = U1Mode.15 in a user's program, I had to remove the bit names from the assembler listing, and add the "PP_" texts to the bit names that the compiler uses itself.

Imagine when the assembler saw something like: Bcf U1Mode,U1Mode.15, instead of Bcf U1Mode,15. Because the UARTEN bit number had been given the alias of U1Mode.15, in the program. :-) Sometimes the assembler program would give an assembler error, but sometimes, on some bits, it would actually run with it and cause chaos in a program's operation because it seemed to default to a bit number of 0. :-O

[See_Mos]

I only noticed because my current keyboard, which was not a cheap one, has a horrible shit key action.

The following is an exaggeration of what I saw

IntConBits_RBIF = 0'Port B Interrupt-On-Change Interrupt Flag bit
'more code
intCONbits_rbif = 1

the upper - lower case are not corrected but both compile OK so it isn't a big problem, just an observation.

[JohnB]

@top204 - and anyone else interested.

I am thinking that I might change the Bit Name Viewer to use the Def files rather than the Bit Name Files.  I'll still present the bit names as they are defined in the Data Sheets but when the user double clicks on a bit in the SFR I will paste the full name as per .Def files in his code.  There will be no need to create aliases for that bit.

By dropping the use of the Bit name files we loose the description of each bit but as no one is prepared to maintain these files I don't think it is a huge loss and it still makes the Bit Name Viewer useful.

[top204]

Using the .def file is the best mechansim, because Microchip keep changing their minds about names, then the compiler gets the blame when something is different. With the device's .def file, if it is in there, it is used by the compiler, and if it is not in there, it is not used by the compiler and needs to be added in a program's listing by the user. :-)

[See_Mos]

looking back at some recent projects I find a mixture of conventions.

Using copy and paste from various sources the code can be a mix of old which used BNF, some where I have used information from the data sheets and some which Les has written so uses the DEF information.

I will have to change my methods and use just the DEF files.

[top204]

The Bit Name Viewer was a third party plugin to the IDE, but has not been maintained.

At the time, I thought it was not a good idea, because the logistics of constantly writing "custom" files for every new device was too great, and had to be constantly performed.

There are Microchip info files for the microcontrollers now, that use a form of XML script, and they could be used to give a form of Bit Name Viewer, but the work involved in parsing them, then constantly making sure Microchip have not made changes (which they always do), will, again, be a constant challenge. I never ever use Microchip files directly because they can never make their mind up what they are doing, and every new version of a software tool has unnecessary changes. Personally, I think it is because they are using a third party program (NetBeans), written in a constantly changing, very poor quality, language (Java) by third party programmers, and now they are also using some Python in it!!! Also, because the third party software tools are based upon very poorly written programs, they are constantly having to change things to make sure they work, and the writers of the programs are not given "rules", so they do the nerdy things that nerds do, because "they know better than the hundreds of thousands of users in the real world". :-)

[trastikata]

I am not savvy in IDE development so my question might be silly, but can't you use the MPLAB's files? I mean, does it not have similar structure i.e. some kind of includes for the various PICs?

[top204]

See my above statement.

Microchip constantly change for the sake of change, and their files can "never" be relied upon, because they change names and file formats whenever they like. I've come across this problem with them for the past 18 years!