Pic Reg includes

[TimB]

Many years ago I worked with someone else to introduce a simple way to get at the reg info in the IDE

It enabled you to find the regs needed and paste them into your program see below

My question is, is there any simple way to just use one of Positrons includes to do the same.

Something like:-

Include "xxxx.xxx"


Thanks

Tim

Code Select Expand

    Symbol TMR1ON = T1CON.0     ; Timer1 On bit
    Symbol RD16 = T1CON.1       ; 16-Bit Read/Write Mode Enable bit
    Symbol NOT_T1SYNC = T1CON.2 ; Timer1 External Clock Input Synchronization Select bit
    Symbol SOSCEN = T1CON.3     ; SOSC Oscillator Enable bit
    Symbol T1CKPS0 = T1CON.4    ; Timer1 Input Clock Prescale Select bits
    Symbol T1CKPS1 = T1CON.5    ; Timer1 Input Clock Prescale Select bits
    Symbol TMR1CS0 = T1CON.6    ; Timer1 Clock Source Select bits
    Symbol TMR1CS1 = T1CON.7    ; Timer1 Clock Source Select bits


[top204]

Take a look in each device's .Def file and each SFR bit has a definition such as: STATUSbits_C, STATUSbits_Z, T1CONbits_T1CKPS0, T1CONbits_T1CKPS1 etc... That represent the SFR and bit name in full.

All of the defines are automatically loaded into a BASIC listing, so they are always ready to use. You will notice all of my code listings that use SFR bits use them.

So an interrupt example such as:

Code Select Expand

If INTCONbits_T0IF = 1 Then    ' Is it a Timer0 interrupt
' Yes. So code goes here
    INTCONbits_T0IF = 0        ' Reset the Timer0 interrupt flag
EndIf

Uses the SFRbits_Bitname defines.

Take a look at the code here, and you will see them used all over the place, because it makes the code a lot easier to write and understand: Low to Mid Frequency Measurement on a PIC12F683 device

[TimB]

Thanks Les

I had seen the your use of it but was not sure where and how to use them

Tim

[top204]

A very good point Tim. I had added a small section in the Proton24 manaul for them, in the preprocessor section, but not in the 8-bit compiler's manual. I have added a small section within both the new compiler manuals and made a bookmark reference to it, because they are actually a subtally important part of writing clearer code. This is the section's text:

SFR bit access using the preprocessor's built-in meta-macros
The SFR bit names are extremely useful within the BASIC program because they circumvent any differences in the device's makeup. For example, in order to access a device's Carry flag, use: STATUSbits_C

All the bit names follow the same rule, where the SFR name is first, followed by the text "bits_", followed by the bit name. Below are a few examples:

T1CONbits_TCS
T1CONbits_TSYNC
T1CONbits_TGATE
T1CONbits_TSIDL
T1CONbits_TON
T1CONbits_TCKPS0
T1CONbits_TCKPS1

To see all the SFR bit meta-macros available to a device, open the device's .def file and there is a compete list of them for all the SFRs and bit names attached to them. The .def files can be found within the compiler's folder, inside the Defs folder.

[TimB]

Thanks

I'm not sure if people are still writing plug-ins but a tool that looks at the device you're using then displays them in a way that collates or produces a display with the relevant info from them like No of ADC's and even the Pin numbers would be great

I opened then shut the file in fear of messing something up. So read only is important eg not into the editor.

[top204]

That's a good idea Tim, but the logistics of it are very high, especially with the constant, and rather unnecessary, changes made to new devices, and older devices data.

Even using the files that are installed with MPLABX, to extract relevant information, is not a good idea because Microchip keep changing them as well! They used to have .dev and .XML files and the very useful, .inc files, that were a standard format... But not anymore! So a program that reads them to create information cannot be relied upon because of the constant changes made to them, or they are removed etc... Even the XML files have changes to their section names, so an XML parser will fail, or create meaningless information, because it is looking for pre-determined name sections. It seems as though the programmers that Microchip employ to do a specific task make their own mind up as to how things work and how they are formatted etc, instead of sticking to set rules to make life easier for the end user. However, the "end user" simply does not matter to Microchip anymore. :-( Unfortunately, Microchip have taken the steps of all the other large companies and do as they please, and forget the end user because they will be back anyway, regardless of the mess made. :-(

"Quality" is now a thing of the past, and will continue to be so as long as "Money alone" is the dominant force of the people in charge, and their are no enforced rules for them to abide by. But we all know that is not going to happen. :-(

[tumbleweed]

So a program that reads them to create information cannot be relied upon because of the constant changes made to them, or they are removed etc

So true! This is probably why even Microchip's tools keep breaking as they change versions.

[TimB]

What I was thinking of was parsing the .def files. After all the hard works has already been done by you...

[Dompie]

Wasn't there a BNF utility for this on the old forum or am I completely wrong?

Johan

[TimB]

Yes there was a BNF tool. However it often produced symbols that clashed with key words like "TO"

I like Les's .def files as I would not have to reproduce them to use the bit names in my code.

[Stephen Moss]

Yes there was a BNF tool. However it often produced symbols that clashed with key words like "TO"

I believe that was Harms tool that extracted information for the datasheets, I wrote a program a couple of years ago that used the data from the MPLAB .Dev files instead but that changed any names that clashed with compiler keywords. Without checking my code IIRC it appended an underscore as suggested by JohnB.

I was going to upload the zip file and make it available again following the forum change as it covered many devices that do not have BNF files but it contains the bit names only (no description). However, as newer devices have been added to the compiler since then I will need to update the files which means changing the program I used to produce them to use the .PIC files of MPLABX as MPLAB 8 will not have .Dev file for them.

[top204]

I used the .pic files, along with other files, to create the compiler's .ppi and .def files, but they have started to reduce, and change, all of them as well. :-(

For the ultra new 18FxxQ84 devices, I am having to create the .ppi files by hand because of all the missing pieces of data from Microchip now for their devices, and it means a full re-write of the PPI creator software I wrote. I'll have to re-write it again some day, as I have had to do several times over the years when things are changed or removed for little reason.

I'm also having to re-write large parts of the compiler because the new GCC assembler they are using for the new 8-bit devices is "very" different to Mpasm, and very little of the original Mpasm assembler code is recognised by it.

It actually seems like Microchip want to keep the device architecture a secret so everyone "must" use their dreadful MPLABX IDE and C compilers. As you can tell, I have very little respect of them now, and "zero" trust. :-)

[TimB]

Considering the effort Les put in to generate the .def files a prog to expose them in a safe way would be great.