The issue is I set an output (RA4) in main after initializing the pic and then enter the while(1) loop where the rtcount_callNextCallback() is called. I am using MPLabX and XC8, both up-to-date versions and I am trying the example on a pic18F47k40 xpress board. I have run into a strange (for me) issue with the rtcounter module as provided by MCC and shown by the example program in the blog area of this site.
#Mplab xc8 2.00 update
The first version of the libraries with the update is v1.75
#Mplab xc8 2.00 code
We have released a new version of the MCC 8-bit libraries which will addresses these issues by converting the code to CCI compatible syntax which will make it work on all modes and versions of the XC8 compiler.
There is a change in the Vectored Interrupt vector names which we are still looking into, contact me if you run into this one and I can help. The int24_t type define in stdint.h is not present for C99 mode, it will be there soon. There are also a couple of small issues which should be resolved in the next compiler release. "_interrupt()" instead of just " interrupt" - yes the brackets are required. The correct syntax is (the underscores are all double-underscores btw.): You can get these projects to work easily by either fixing the code to use the standards-compliant CCI syntax - or changing the define to C90 and leave the code unchanged (leaving the problem for later so to speak) When you make a new project it will default to "= C99 " which means the deprecated syntax will cause compilation errors where the above syntax was used. If you use MCC with this project you should experience no problems.
This will tell the compiler to use the pre-XC8v2.0 front-end to compile your code which should give you the same behavior you got before with XC8 v1.45 and earlier. To minimize problems the IDE will default any "old project" you open (and change the compiler to XC8 2.0) to pass in "C Standard = C90" which can be set under " XC8 Global Options". Unfortunately MCC has been using too many of this pre- XC8 2.0 syntax and this can now cause some compatibility issues. XC8 has for a while allowed the corrected syntax but with 2.0, due to the improved front-end implementation, these non-standard keywords are no longer available. Together with the wonders we get with the new front-end we have also lost support for the "old" way of doing these things which was not strictly standards compliant. Using "int i to hard locate a variable at a ram location Using " interrupt" to mark interrupt functions Unfortunately pre- XC8 2.0 we had some keywords in the compiler which were not strictly conforming to the C standard. With XC8 2.0 we are very excited that we get an improved compiler front-end, which brings things like C99 features to us which we are very happy to have.
I also posted about this on the Microchip forum on this thread. There are a couple of other CCI keywords which are described in the compiler user's guide such as _interrupt which you can also get to work by switching back to the pre 2.0 syntax by choosing "C90" as shown above. This defines the TMR0 register - volatile is important to tell the compiler that this is a volatile register, // read more about volatile in the XC8 Users Guide #define TMR0 (*( volatile uint8_t *) 0x0001u ) // You can now access it like normal, something like this. If you want to use something which does not use a compiler specific extension such as or _at() you can always do it like this:
The setting looks like this, it is under "XC8 Global Options" and is called "C standard". With XC8 2.0 it is possible to compile your old code using the syntax if you set the compiler settings to use "C90" format. Since this has a double underscore and the brackets it is more compliant to the C standards. Volatile unsigned char TMR0 _at ( 0x01 ) In XC8 v2.0 the syntax was switched to what Microchip calls the CCI (Common Compiler Interface) syntax, which uses the following syntax to hard locate a variable. In the past it was possible to hard locate a variable using XC8 like this : volatile unsigned char TMR0 0x01 Īlthough this was convenient it was also not strictly acceptable C syntax, so if you were using a linter on your code to check if you have anything untoward in there it could flag this as being incorrect C syntax. I came across this and thought I would post it here in case others hit the same snag.
0 kommentar(er)
