This thread is dedicated to gathering suggestions related to what features could be improved or added in the next release of MCC. Please try to provide some arguments for your suggestions as they will help when proposing the idea to the team. Providing arguments will also help the team in better estimating what your needs are.
 
Please help us to improve MCC!
 
Regards,
The MCC Team

Add the PIC32 family to the configurator

I second the above! Please support PIC32, and the rest perhaps!

1. Ability users to define its own code snippets that be merged into IC2 generated code.
2. Ability users to define its own modules (perhaps software modules).

Example for (1):
RTClock. This is a module, that relies on one of the PIC timers (TIMER1, TIMER2,4,6). The selected base timer is configured to make interrupts at intervals, say, 2.5ms. This can be done in IC2. RTClock module defines software timers that have periods multiples of 2.5ms. Every timer has code associated with it. This code should be embedded into the base timer interrupt -- and if defined as user code snippet, it would be easy to embed it.
 
Example for (2):
The same RTClock module. It needs not only code snippets in the timer interrupt; it needs variable definitions, procedures (or macros) for setting, stopping, checking elapsed interval etc. So, an user defined module with possibility to be integrated to "system" IC2 modules would be great.
 
Ivan
 

Plugin system, so as users can add features to IC2.

Thanks everyone for the great suggestions. They`re all noted down and taken into account. Support for more peripherals and more devices will be added in the following months.

I noticed that for the PIC16F1828/1823 there is no reference to the CPS Capacitive Sense module.
Is the CodeConfigurator providing code generation for EVERY module and peripheral in the PIC12 & PIC16 series?

Hi rcardenas,
 
The v1.0 release has support for select peripherals. More peripherals and more devices will be added in the following months. I can't say neither when nor what devices/peripherals exactly. I can tell you that we want to release them as soon as possible. In what concerns peripherals and devices probably priorities may shift based on user requests and needs.

Thanks for the feedback, I realize that we all live in a priority driven world, and unfourtunately the Real World interrupts are more arbitrary than the predictable world of MCUs.  ;-)
 
Keep up the great work your teeam is doing.  The more your facilitate the start-up process is a day faster to our project delivery
Thanks

Try to include the support for serial EEPROM device in I2C framework. Currently the I2C framework generated has following functions:
 
uint8_t I2C_ReadFrame(uint8_t i2cSlaveAddress, uint8_t *i2cReadPointer, uint8_t i2cFrameLength);
uint8_t I2C_WriteFrame(uint8_t i2cSlaveAddress, uint8_t *i2cWritePointer, uint8_t i2cFrameLength);
uint8_t I2C_WriteByte(uint8_t i2cSlaveAddress, uint8_t i2cData);
 
It is not possible to read the serial EEPROM device using this code. When we want to read the serial EEPROM, we need to first give write packet (containing start address) and then without giving stop condition we need to restart the read sequence.