Author Topic: Microchip woes!  (Read 12548 times)

0 Members and 1 Guest are viewing this topic.

Online naliTopic starter

  • Frequent Contributor
  • **
  • Posts: 656
  • Country: gb
Microchip woes!
« on: January 25, 2016, 10:28:59 am »
 :wtf: is happening at Microchip?? I've occasionally used PICs with Mikropascal for years for trivial projects so I've decided to use PIC as the controller for my smart PSU (hobby) project and use C code.  So I download the latest MPLAB & XC8, here's how it goes:

From the zillions of devices I choose a 16F1779 from Farnell, partly because it's got an inbuilt 10-bit DAC onboard. It's not supported by XC8  :(

So use a 18F25K22 which I had in my parts box, and order a cheap SPI DAC to use with it. Start a new project, use the MPLAB  Code Configurator to set a GPIO pin and write a couple of lines of code to toggle it. OK, that was easy. Now I add a rotary encoder to RB0/RB1 so I can start playing with interrupts.

There's no gpio interrupts in MPCC. Or rather there is a blank column with no tickyboxes to select them. Now, I don't have a problem manually writing an interrupt handler but as this is a new environment to me I'd rather use the default tools while I climb the learning curve, and who knows if MPLAB will overwrite any of my code? From what I've seen so far I wouldn't be surprised.

I decide to look on Microchip's forums, try searching for IOC. Search just displays a "Searching...." dialog for a few seconds then sweet FA, it seems to be broken.

I decide to sign up to post a question. Enter my details and a password and I get "Invalid password" (there is no criteria mentioned on the sign in page!). My initial p/w was just letters so I add some digits and try again. Now the page just reloads, no error displayed. After trying a couple of times using Chrome I try the same using IE with the same result. No email received, so that appears to be broken.

 |O this project's going back on the shelf for now. Maybe I'll forget about digital control and use good old fashioned analogue pots and meters, I dunno, I'll decide later....

 

Offline hans

  • Super Contributor
  • ***
  • Posts: 1626
  • Country: nl
Re: Microchip woes!
« Reply #1 on: January 25, 2016, 10:36:01 am »
You also need to download the "extended part support" libraries for compilers in order to compile for them. Unfortunately the 16F1779 is not in pack 1.35B

Quote
Compiler Maintenance and Support

MPLAB XC PRO and Standard compilers both come with 12 months of High Priority Access (HPA), and a support and maintenance subscription. HPA access must be renewed at the end of twelve months. HPA includes:

    Priority technical support
    New part support
    New architecture support
    New compiler version and patch level updates
    Free shipping on Microchip Direct for all development tool orders

You probably have to wait a few months in order to get this part supported.
I rest my case.

As for the "code configurator", hmm how useful is it really? I always find it hard how you could "abstract" the concept of an interrupt in a code generator. I can understand it's useful to get basic init & clock stuff running, but interrupts.. it's not really doing much work.. just generating some framework code.
I don't use it. Just write the C code yourself. MPLAB X is not going to "override" code; it may include some C startup and a linker file in the background but that is happening in every compiler. You can replace it in the linker settings, so no woes there.

I would always search using google. You get results for Microchip forums, but as well others. It's faster & more content.
« Last Edit: January 25, 2016, 10:40:14 am by hans »
 

Offline Xenoamor

  • Regular Contributor
  • *
  • Posts: 83
  • Country: wales
Re: Microchip woes!
« Reply #2 on: January 25, 2016, 11:01:37 am »
I'd just start with an atmega168 which also has a 10bit ADC

There's a wealth of tutorials for the atmega168/328 and it has a strong community even if a bit fierce.

Personally I'm just a fan of the well documented datasheet
 

Offline Monkeh

  • Super Contributor
  • ***
  • Posts: 7990
  • Country: gb
Re: Microchip woes!
« Reply #3 on: January 25, 2016, 11:42:30 am »
http://www.microchip.com/forums/m908793.aspx

Quote
XC8 v1.36 release has support these parts and will be available shortly on the web site.
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8221
  • Country: 00
Re: Microchip woes!
« Reply #4 on: January 25, 2016, 12:04:38 pm »
Your experience is not unique, the microchip software teams just suck. There is no kinder way of putting it.

================================
https://dannyelectronics.wordpress.com/
 

Online naliTopic starter

  • Frequent Contributor
  • **
  • Posts: 656
  • Country: gb
Re: Microchip woes!
« Reply #5 on: January 25, 2016, 12:19:47 pm »
http://www.microchip.com/forums/m908793.aspx

Quote
XC8 v1.36 release has support these parts and will be available shortly on the web site.

Yeah I saw that - No mention of when though. Considering 1.35B was only released in September I'm not going to hold my breath  :popcorn:

I'll probably either forget the convenience "tools" & write all my code manually using the datasheet, or have a play with some Atmels which I need to have a look at anyway for a legacy project at work.

I was more frustrated at having wasted an evening reinstalling unfamiliar software because MPLAB wasn't seeing XC8 only to find I had picked an unsupported part - this being AFTER Googling & finding a whole load of posts saying I need to follow these instructions (outdated link), need to manually register MPLABXC8.dll  :blah:  :blah: Then trying to do something the documentation explicitly says I should be able to do. Then a broken forum. The overall impression is pretty cruddy IMHO.

Anyways, I feel better now I've had my whinge!  ^-^
 

Offline Xenoamor

  • Regular Contributor
  • *
  • Posts: 83
  • Country: wales
Re: Microchip woes!
« Reply #6 on: January 25, 2016, 01:20:38 pm »
My general consensus theses days is to use a text editor with a manufacturers header files and a custom makefile.

Means you can quite comfortably sit in your familiar environment and that your code can be compiled many years from now on any OS
 

Offline SteveyG

  • Supporter
  • ****
  • Posts: 987
  • Country: gb
  • Soldering Equipment Guru
Re: Microchip woes!
« Reply #7 on: January 25, 2016, 03:36:23 pm »
I'd just start with an atmega168 which also has a 10bit ADC

There's a wealth of tutorials for the atmega168/328 and it has a strong community even if a bit fierce.

Personally I'm just a fan of the well documented datasheet

IMO Microchip have some of the best datasheets, it's just the built in compiler support is not as up to date as the current product line. The device itself is great and has all the features if you are familiar with XC.
YouTube Channel: https://www.youtube.com/user/sdgelectronics/
Use code: “SDG5” to get 5% off JBC Equipment at Kaisertech
 

Offline bktemp

  • Super Contributor
  • ***
  • Posts: 1616
  • Country: de
Re: Microchip woes!
« Reply #8 on: January 25, 2016, 04:00:58 pm »
IMO Microchip have some of the best datasheets, it's just the built in compiler support is not as up to date as the current product line. The device itself is great and has all the features if you are familiar with XC.
Yes, but you have to wait about 5 years for a new device until the datasheet covers all the erratas and becomes really usable.
And never trust any microchip ADC oder DAC specification unless the datasheet has been updated several times. The specifications typically get worse over time.
 

Offline Monkeh

  • Super Contributor
  • ***
  • Posts: 7990
  • Country: gb
Re: Microchip woes!
« Reply #9 on: January 25, 2016, 04:15:49 pm »
The first revision of a datasheet contains the hopes and prayers of the silicon engineers. The final revision contains their tears.
 

Offline Daving

  • Contributor
  • Posts: 34
Re: Microchip woes!
« Reply #10 on: January 25, 2016, 06:43:14 pm »
http://www.microchip.com/forums/m908793.aspx

Quote
XC8 v1.36 release has support these parts and will be available shortly on the web site.

Yeah I saw that - No mention of when though. Considering 1.35B was only released in September I'm not going to hold my breath  :popcorn:

I'll probably either forget the convenience "tools" & write all my code manually using the datasheet, or have a play with some Atmels which I need to have a look at anyway for a legacy project at work.

I was more frustrated at having wasted an evening reinstalling unfamiliar software because MPLAB wasn't seeing XC8 only to find I had picked an unsupported part - this being AFTER Googling & finding a whole load of posts saying I need to follow these instructions (outdated link), need to manually register MPLABXC8.dll  :blah:  :blah: Then trying to do something the documentation explicitly says I should be able to do. Then a broken forum. The overall impression is pretty cruddy IMHO.

Anyways, I feel better now I've had my whinge!  ^-^

1.36 should be out soon(TM).  They tend to come out every 3 months or so to add support for new parts, and push bug fixes.  MCC3.0 should also be out soon(TM).
 

Offline Howardlong

  • Super Contributor
  • ***
  • Posts: 5315
  • Country: gb
Re: Microchip woes!
« Reply #11 on: January 25, 2016, 07:24:07 pm »
As for the "code configurator", hmm how useful is it really? I always find it hard how you could "abstract" the concept of an interrupt in a code generator. I can understand it's useful to get basic init & clock stuff running, but interrupts.. it's not really doing much work.. just generating some framework code.
I don't use it. Just write the C code yourself. MPLAB X is not going to "override" code; it may include some C startup and a linker file in the background but that is happening in every compiler. You can replace it in the linker settings, so no woes there.

As with any code generator or translator I've ever encountered in my career it's a mixed blessing.

O It's quite buggy
O You have to know and understand the peripherals anyway, there is no way around this
O It generates code as a full 8 bit register settings, not using bitfields, therefore it's not easily human-readable
O Far, far, far too much useless and unnecessary commentary, especially in the source file headers
O Does not generate the most efficient code
O It doesn't support the latest devices, or even some older ones properly
O Peripherals often not fully implemented in the UI
O Stupid merge nonsense means your bug fixes are overwritten and so is your application specific code far too easily: there is no clear way to define your own code sections distinct from machine generated nonsense.

Having said all that, I do use it sometimes though to generate boilerplate code in a dummy project, possibly even unit test it there, then copy and paste relevant bits into my own code and tidy it up to my own standards (using bitfields for example).

O Did I mention it's buggy?

Overall, it's a positive, but not by much. I consider it completely useless for maintaining code ongoing for example, it's just too likely it'll scrub your carefully hand coded sections away, and I strongly object to being forced to code up my own stuff in someone else's format. But it's OK for getting a few peripherals initialised, and copying and pasting that code into your own project.

O Oh, and it's a quite buggy.

Anyone who thinks this is the answer the Arduino crowd's been looking for has been misled. You simply can't ignore the fact that you still have to understand what each peripheral is capable of and its little intricacies.
 

Online naliTopic starter

  • Frequent Contributor
  • **
  • Posts: 656
  • Country: gb
Re: Microchip woes!
« Reply #12 on: January 25, 2016, 08:37:10 pm »

Having said all that, I do use it sometimes though to generate boilerplate code in a dummy project, possibly even unit test it there, then copy and paste relevant bits into my own code and tidy it up to my own standards (using bitfields for example).

That's pretty much what I set out to do. Trying to learn a new i) IDE ii) Language iii) Device at the same time, it's nice to get some sort of framework as a starting point. Not to worry, I'll plod on and find my own way; I've got a flashing LED and I've done a bit of stuff with PICs using MikroPascal including timer & ADC interrupts so it's not the end of the world.

 

Offline Howardlong

  • Super Contributor
  • ***
  • Posts: 5315
  • Country: gb
Re: Microchip woes!
« Reply #13 on: January 25, 2016, 09:16:34 pm »

Having said all that, I do use it sometimes though to generate boilerplate code in a dummy project, possibly even unit test it there, then copy and paste relevant bits into my own code and tidy it up to my own standards (using bitfields for example).

That's pretty much what I set out to do. Trying to learn a new i) IDE ii) Language iii) Device at the same time, it's nice to get some sort of framework as a starting point. Not to worry, I'll plod on and find my own way; I've got a flashing LED and I've done a bit of stuff with PICs using MikroPascal including timer & ADC interrupts so it's not the end of the world.

I did take one of their "Minute" videos which shows someone building a blinky with Code Configurator in about two minutes. So I thought I'd do the same without Code Configurator. I did it in 90 seconds.

There is actually little value in those videos other than someone showing how quickly they can use the app in a rehearsed manner. When I tried to repeat what the presenter did, I had to keep stopping the video to keep up, but it was one of the first times I'd used Code Configurator. In reality, making an unrehearsed blinky with Code Configurator would probably take a reasonably seasoned individual five minutes from beginning to end. I can certainly write a blinky without rehearsal or Code Configurator much quicker than that on any PIC form PIC10 to PIC32.
 

Offline Daving

  • Contributor
  • Posts: 34
Re: Microchip woes!
« Reply #14 on: January 26, 2016, 07:39:41 am »

O It's quite buggy
O You have to know and understand the peripherals anyway, there is no way around this
O It generates code as a full 8 bit register settings, not using bitfields, therefore it's not easily human-readable
O Far, far, far too much useless and unnecessary commentary, especially in the source file headers
O Does not generate the most efficient code
O It doesn't support the latest devices, or even some older ones properly
O Peripherals often not fully implemented in the UI
O Stupid merge nonsense means your bug fixes are overwritten and so is your application specific code far too easily: there is no clear way to define your own code sections distinct from machine generated nonsense.

There's a few bugs.  Mostly obvious ones, but a few subtle ones.

I think it's an okay learning tool.  It at least is quicker to learn a new peripheral with MCC + the datasheet than the datasheet by itself.  Also, the CLCs lend themselves to a graphical setup.

Agreed.  It'd be nice if it was a little more verbose.  The comments help with this, though.

I use code folding in the IDE to hide the comments until I need them.  I personally like the functions being documented in the header.  It's under tools->options->editor->folding (image attached)

True.  It favors readability in most cases over pure efficiency.  Although some of the code could use improvement in the readability department, too.  In general though, premature optimization should be avoided.
http://c2.com/cgi/wiki?PrematureOptimization
It’s harder to read code than to write it. http://www.joelonsoftware.com/articles/fog0000000069.html

That's one issue with microchip almost never EOLing parts.  The catalog endlessly expands, and there's a limit to what gets supported by new tools out the gate.

True.  In the 3.0 beta, there is a register view, so you can get full access to all of the peripheral's features, and not just the mainstream ones.

MCC could handle dependency injection (and bug fixes) better, so that you don't have to edit the MCC files.  Someday :)
 

Offline Howardlong

  • Super Contributor
  • ***
  • Posts: 5315
  • Country: gb
Re: Microchip woes!
« Reply #15 on: January 26, 2016, 08:14:21 am »
The proof of the pudding is in the eating.If I spend more time trying to adapt to a new way of doing things than plodding along as before, then it's a net negative, but you won't necessarily know that until you've had to try to adapt, by which time it's wasted effort.

An example of a bug is at it incorrectly sets the clock in the majority of cases for PIC16F183xx. As they don't use bit fields, you have to spend time reverse engineering the machine generated code and debug the OSCCON registers. As setting the clock is one of the most fundamental and tricky parts to even started on a device, one would have hoped they'd get this right, but no. So I had to know all the stuff about how the clock worked, how the various fields in the OSCCON registers worked, and debug their code, so definitely it's a time deficit as soon as it generates bad code.

As another example, the I2C interrupt code that's generated is not just a bit of register setting, it's a fairly significant state machine. So do I learn how to use a non-trivial state machine from a jack of all trades code generator, or do I code up my own API? Having seen what's generated, I'm fairly sure I'd rather code up my own and understand what's going on, and save the effort in trying to understand how to use and manipulate my use cases around a machine generated layer.

So I'm still on the fence. I think if they'd have used human readable bitfields I'd have been far more positive despite the bugs.

They've also fallen into the same traps as the Harmony developers did regarding code generation and merging too. Surely it isn't too difficult to have some tag injected around application specific code that tells the merge algorithm "no touchy" without having to prompt you. This alone makes the code unmaintainable ongoing: sure, generate your boilerplate, but after that no more "help" fiddling with my code thank you.
 

Offline hli

  • Frequent Contributor
  • **
  • Posts: 255
  • Country: de
Re: Microchip woes!
« Reply #16 on: January 26, 2016, 12:07:56 pm »
So use a 18F25K22 which I had in my parts box, and order a cheap SPI DAC to use with it. Start a new project, use the MPLAB  Code Configurator to set a GPIO pin and write a couple of lines of code to toggle it. OK, that was easy. Now I add a rotary encoder to RB0/RB1 so I can start playing with interrupts.

There's no gpio interrupts in MPCC. Or rather there is a blank column with no tickyboxes to select them.

Surely it is there. The 18F25K22 can do IOC only on port RB4-RB7. When you select them for the GPIO module, there are select boxes in the IOC column. (RB0-RB2 can be used for external interrupts too, but the EXTINT module is supported only in the new beta MCC I think.)

Make sure to get your facts right before ranting :)
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8221
  • Country: 00
Re: Microchip woes!
« Reply #17 on: January 26, 2016, 12:40:46 pm »
"As they don't use bit fields, you have to spend time reverse engineering the machine generated code and debug the OSCCON registers. "

Wow, I'm surprised that someone as advanced and as experienced as you are got  stumbed by something this simple.
================================
https://dannyelectronics.wordpress.com/
 

Offline Howardlong

  • Super Contributor
  • ***
  • Posts: 5315
  • Country: gb
Re: Microchip woes!
« Reply #18 on: January 26, 2016, 01:58:21 pm »
"As they don't use bit fields, you have to spend time reverse engineering the machine generated code and debug the OSCCON registers. "

Wow, I'm surprised that someone as advanced and as experienced as you are got  stumbed by something this simple.

I don't think I ever said I was stumped, I just don't walk around with the bitfields in my "advanced and experienced" head, but thank you for the flattery.  ;)

Without using bitfields, the reader, even an advanced and experienced one, must frequently refer back to the DS, which IMHO is time consuming and unnecessary when it could've been written in the code. I assume that it's done that way to improve performance and reduce code size somewhat, but generally setting up peripheral registers is rarely at a pinchpoint in code. Of course, if it weren't so buggy there'd be much less need to do this. An option would be nice to select between bitfield notation and byte-banging.

But then I'm sure someone of your calibre already knew that.  ;)
 

Offline Daving

  • Contributor
  • Posts: 34
Re: Microchip woes!
« Reply #19 on: January 26, 2016, 04:06:06 pm »
Since most of what we're talking about is in the initialization code, it's not terribly important that it have the fastest execution.  Expanding the statement to a few lines with enums for the assignment options would be nice.

So something like this in the header:
Code: [Select]
typedef enum {
    ADC_ADFM_LEFT,
    ADC_ADFM_RIGHT,
    ADC_ADFM_COUNT
} adc_adcon1_adfm_t;

typedef enum {
    ADC_ADCS_FOSC_2,
    ADC_ADCS_FOSC_8,
    ADC_ADCS_FOSC_32,
    ADC_ADCS_FRC1,
    ADC_ADCS_FOSC_4,
    ADC_ADCS_FOSC_16,
    ADC_ADCS_FOSC_64,
    ADC_ADCS_FRC2,
    ADC_ADCS_COUNT
} adc_adcon1_adcs_t;

typedef enum {
    ADC_ADPREF_VDD,
    ADC_ADPREF_RESERVED,
    ADC_ADPREF_VREF,
    ADC_ADPREF_FVR,
    ADC_ADPREF_COUNT
}adc_adcon1_adpref_t;

And this in the intialize function:
Code: [Select]

    ADCON1bits.ADFM = ADC_ADFM_RIGHT;
    ADCON1bits.ADCS = ADC_ADCS_FOSC_32;
    ADCON1bits.ADPREF = ADC_ADPREF_VDD;
   
Instead of:
Code: [Select]
    // ADFM left; ADPREF VDD; ADCS FOSC/32;
    ADCON1 = 0x20;

At any rate, the compiler should compile repeated assignments to the same register to one assignment.  I'll have to check and see if it does, now that I think about it.

Edit: And now that I think about it further, optimizing writes to SFRs could be tricky, since SFRs are written to specifically for their side effects.  (Writing 1 to LATB1 stores the 1, but it also sets the pin high).
Oring a bunch of values together gets pretty ugly, especially with a 32-bit SFR.
« Last Edit: January 26, 2016, 04:15:02 pm by Daving »
 

Online naliTopic starter

  • Frequent Contributor
  • **
  • Posts: 656
  • Country: gb
Re: Microchip woes!
« Reply #20 on: January 26, 2016, 06:11:58 pm »
So use a 18F25K22 which I had in my parts box, and order a cheap SPI DAC to use with it. Start a new project, use the MPLAB  Code Configurator to set a GPIO pin and write a couple of lines of code to toggle it. OK, that was easy. Now I add a rotary encoder to RB0/RB1 so I can start playing with interrupts.

There's no gpio interrupts in MPCC. Or rather there is a blank column with no tickyboxes to select them.

Surely it is there. The 18F25K22 can do IOC only on port RB4-RB7. When you select them for the GPIO module, there are select boxes in the IOC column. (RB0-RB2 can be used for external interrupts too, but the EXTINT module is supported only in the new beta MCC I think.)

Make sure to get your facts right before ranting :)

You're right. I tried RB7 and the IOC options magically appear, although I was initially looking for the external interrupts not IOC.  A bit of selective reading on my part not helped by me getting a bit annoyed!

 

Offline bktemp

  • Super Contributor
  • ***
  • Posts: 1616
  • Country: de
Re: Microchip woes!
« Reply #21 on: January 27, 2016, 03:38:54 pm »
At any rate, the compiler should compile repeated assignments to the same register to one assignment.  I'll have to check and see if it does, now that I think about it.

Edit: And now that I think about it further, optimizing writes to SFRs could be tricky, since SFRs are written to specifically for their side effects.  (Writing 1 to LATB1 stores the 1, but it also sets the pin high).
Oring a bunch of values together gets pretty ugly, especially with a 32-bit SFR.
That is exactly the problem. The SFRs are volatile, so prohibiting almost any optimization.
Microchip did all the SFR bits using bitfields. It is easily readable, but generates a large code, because the compiler needs to read-modify-write every changed bit. So instead of writing a single 8/16/32bit register at once it may read-modify-write 8/16/32bits individually. That may generate 10s of bytes of code instead of a single word.
AVR-gcc does not have any bitfields, instead defines for the bitvalue of each setting. So you have to assemble the value yourself:
ADCSRA=(1<<ADEN)|(1<<ADSC)|(1<<ADIE)|(1<<ADFR)|6;
It is not as nice to read, but is will be compiled to a single instruction word.
It is hard to decide. For registers I prefer the AVR solution, for IO pins or other settings where I only want to change a single bit the microchip way is much nicer because you can write _LATB1=1; instead of PORTB|=(1<<PB1);
 

Offline Daving

  • Contributor
  • Posts: 34
Re: Microchip woes!
« Reply #22 on: January 27, 2016, 08:39:30 pm »
http://www.microchip.com/forums/m908793.aspx

Quote
XC8 v1.36 release has support these parts and will be available shortly on the web site.

Yeah I saw that - No mention of when though. Considering 1.35B was only released in September I'm not going to hold my breath  :popcorn:

I'll probably either forget the convenience "tools" & write all my code manually using the datasheet, or have a play with some Atmels which I need to have a look at anyway for a legacy project at work.

I was more frustrated at having wasted an evening reinstalling unfamiliar software because MPLAB wasn't seeing XC8 only to find I had picked an unsupported part - this being AFTER Googling & finding a whole load of posts saying I need to follow these instructions (outdated link), need to manually register MPLABXC8.dll  :blah:  :blah: Then trying to do something the documentation explicitly says I should be able to do. Then a broken forum. The overall impression is pretty cruddy IMHO.

Anyways, I feel better now I've had my whinge!  ^-^

1.36 should be out soon(TM).  They tend to come out every 3 months or so to add support for new parts, and push bug fixes.  MCC3.0 should also be out soon(TM).

1.36 is out, now.
 

Offline Daving

  • Contributor
  • Posts: 34
Re: Microchip woes!
« Reply #23 on: January 28, 2016, 07:04:31 am »
At any rate, the compiler should compile repeated assignments to the same register to one assignment.  I'll have to check and see if it does, now that I think about it.

Edit: And now that I think about it further, optimizing writes to SFRs could be tricky, since SFRs are written to specifically for their side effects.  (Writing 1 to LATB1 stores the 1, but it also sets the pin high).
Oring a bunch of values together gets pretty ugly, especially with a 32-bit SFR.
That is exactly the problem. The SFRs are volatile, so prohibiting almost any optimization.
Microchip did all the SFR bits using bitfields. It is easily readable, but generates a large code, because the compiler needs to read-modify-write every changed bit. So instead of writing a single 8/16/32bit register at once it may read-modify-write 8/16/32bits individually. That may generate 10s of bytes of code instead of a single word.
AVR-gcc does not have any bitfields, instead defines for the bitvalue of each setting. So you have to assemble the value yourself:
ADCSRA=(1<<ADEN)|(1<<ADSC)|(1<<ADIE)|(1<<ADFR)|6;
It is not as nice to read, but is will be compiled to a single instruction word.
It is hard to decide. For registers I prefer the AVR solution, for IO pins or other settings where I only want to change a single bit the microchip way is much nicer because you can write _LATB1=1; instead of PORTB|=(1<<PB1);

The same type of definitions are defined in the xc.h headers.  Not many use them, though.

What I've done in the past is something like this:

// In some utility header, included in ADC c file.
#define UTIL_Mask(bits) ((1 << ((bits)+1)) - 1)

// In ADC c file.  Not needed by USER API.
#define ADC_ADFM_POS (3)
#define ADC_ADFM_BITS (1)
#define ADC_Adfm(a) ((UTIL_Mask(ADC_ADFM_BITS) & (a)) << ADC_ADFM_POS)

#define ADC_ADFM_LEFT (ADC_Adfm(0))
#define ADC_ADFM_RIGHT (ADC_Adfm(1))

Then I can OR ( | ) the settings together.

ADC1CON = (ADC_ADFM_RIGHT | ADC_ADCS_FOSC_32 | ADC_ADPREF_VDD)

For 32 bit registers, this could get unweildy, so if the compiler optimizes right, you should be able to do this.

uint32_t config = ADC_ADFM_RIGHT;
config |= ADC_ADCS_FOSC_32;
config |= ADC_ADPREF_VDD;
ADC1CON = config;

...
config = blah;
config |= foo;
config |= bar;
ADC2CON = config;

The compiler could realize it's a local variable that only gets copied to the SFR once and never takes inputs from anything but literals.  Depends on the compiler and options, I suppose.
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4196
  • Country: us
Re: Microchip woes!
« Reply #24 on: January 28, 2016, 08:31:39 am »
Quote
ADCSRA=(1<<ADEN)|(1<<ADSC)|(1<<ADIE)|(1<<ADFR)|6;
It is not as nice to read, but is will be compiled to a single instruction word.

Given reasonably sensible typedefs (eg CMSIS) you can also define local/register variables of the same type as the peripheral register, manipulate the bits "elegantly" and then assign them to the actual peripheral register "in bulk."   Here's an actual example, from Atmel ASF code for SAMD:
Code: [Select]
SYSCTRL_OSC8M_Type temp = SYSCTRL->OSC8M;

/* Use temporary struct to reduce register access */
temp.bit.PRESC    = config->prescaler;
temp.bit.ONDEMAND = config->on_demand;
temp.bit.RUNSTDBY = config->run_in_standby;

SYSCTRL->OSC8M = temp;
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf