Mplab X Ipe V5.30

[Adam Makin]

Ihave already installed MPLAB X IDE and MPLAB IPE, both v5.30, onto Kubuntu Linux 19.04 without any problems. The hope is that I can use the Velleman VM203 in this setup, using the IPE to download

software to the PIC.

Thank you for another swift reply. It would seem that I have got hold of the wrong end of the stick with regards to MPLAB IPE. So, I guess that I just need to know if the VM203 programmer would work with MPLAB X IDE v5.30.

Yes, seems to work in Windows version. You can check in the Linux version by opening or creating a project and then checking in the Project Properties if the PICkit2 exists there under Alternate Tools. (No programmer is needed to be connected to check.)

The device is programmable with PICkit 2 and VM203 if the two dots there are yellow or green.

The complete Device Support list can be found in the Windows version in the folder:

C:\Program Files (x86)\Microchip\MPLABX\v5.30\docs

BTW: PIC16F84 and PIC16F84A are not supported to program with the PICkit 2 using MPLAB X IDE v5.30.

However, I noticed at that time that both PICkit3 and PICkit 4 were both prepended by two colored circles, the first being red and the second being green. Do you happen to know what that color scheme indicates ?

If you have purchased a workstation compiler license, locate the activation key and have it ready for the install process. You may also wish to obtain a free C++ activation key if your purchased license includes only C/ASM language support. Visit for more information on free and paid compiler licenses for C and C++.

Smart-IO Improvements -- The existing Smart-IO feature of MPLAB XC32 reduces code size by analyzing your application code and providing a reduced-functionality variant of printf/scanf that meets your application requirements. The full versions of these functions are large because they support many format specifiers. This release further improves code-size reduction by providing additional reduced-functionality variants, increasing their granularity. This feature is enabled by default but can be disabled with the -mno-smart-io or -msmart-io=0 option. Also, see these notes on potential migration issues. (XC32-2282 & XC32-2270)

Memory-Usage Report by Module -- The linker-generated memory-usage report, enabled by passing --report-mem to the linker, now shows memory usage by object-file module (in addition to memory-usage by section/region). This information can be useful when you are trying to analyze which modules are consuming flash and/or RAM in your application. This report is generated in the map file as well as optionally to stdout when linking. You can enable this option for your MPLAB X project by opening the project properties and going to xc32-ld Option categories: "Diagnostics" Enable "Display memory usage". (XC32-1277)

Selection of Kahan or Newton sqrt() algorithm -- This release introduces a new mechanism to choose the sqrt() algorithm. When optimization level -Os is passed to xc32-gcc at link time, the Newton algorithm is selected. This results in smaller executable code. For all other optimization levels, the Kahan algorithm is selected. This results in bigger but faster executable code. The sqrt() results for some values might differ slightly based on the algorithm chosen, but in both cases, they will be within allowed tolerances. (XC32-2263)

Adaptive Calls for ARM Thumb/2 -- The MPLAB XC32 compiler defaults to using short, PC-relative function calls. In most cases, these short calls are sufficient to cover the entire Flash-memory space, since an Arm Thumb/2 PC-relative branch has a range of 16 MB. However, when calling a function allocated to RAM or ITCM from Flash (or vice versa), this 16 MB range may not be sufficient. Normally, you would add the long_call attribute to your function prototype to tell the compiler that the call's target address will be out of range of a short call. However, there may be some cases where you do not know in advance if the function being called will be within range. In such cases, the linker will now adapt the short call by adding a stub that can reach the target address. It will then iterate the best-fit allocation (BFA) process to account for this added stub. This adaptation happens automatically and does not require you to modify your code or your project.

Data-Initialization Improvements -- The MPLAB XC32 v4.20 release introduced improvements to the way that data is initialized. These improvements result in smaller flash usage for most projects. However, because there were some cases where these changes could increase flash usage rather than reduce it, this feature was disabled by default. Starting in the v4.30 release, the linker now automatically detects when section merging and/or compression will be profitable for your project. In addition, the dinit compression heuristic is now applied to the entire application's data rather than on each data section, resulting in further improvements to flash usage. This change may increase or decrease the startup time of your application. (XC32-2422 & XC32-2341 & XC32-2292 & XC32-2255 & XC32-2223)

Code-Size Optimization - Reduced Register pressure for Loop Invariant Motion -- Previously, the loop-invariant motion optimization extracted many instructions out of a loop. This can sometimes lead to more operands being live at the same time and if so, more registers are required. This could lead to additional code size because an operation that uses a high-numbered register requires a larger instruction encoding. MPLAB XC32 v4.30 now more accurately estimates the registers to be used in a loop so that the compiler can more accurately optimize for code size. This change may affect the timing of a loop in your application. (XC32-2230)

region pragma in multiple files with LTO enabled [MIPS] -- Previously, using #pragma region for a new application-specific memory region was not usable when compiling with Link-Time Optimizations. This combination is now allowed. (XC32-2232)

Added multilib for the Cortex-A7 core -- For the SAMA7G5 MPU, we now provide a precompiled library variant that can take advantage of the more features of this core. Specifically, integer division on this device is now faster. (XC32-2268)

New pragmas for default section names -- This release introduces two new pragmas that can be used to specify the default section names for variables and functions in your C source unit. While these new pragmas, default_variable_attributes and default_function_attributes, change the default for variables and functions, they do not replace the section attribute, which should be used to specify the section name for specific variables and functions. This mechanism is intended primarily to assist in porting code from other toolchains that use this pragma mechanism. We recommend that new code use the existing section attribute. (XC32-2027)

Note that using the default_variable_attributes pragma may cause uninitialized and initialized variables to be placed into the same section. This typically results in less efficient data-initialization code, which can waste some flash space and also increase data-initalization time at application startup. (XC32-2492)

Bug fix for xc32-bin2hex when generating a large C source file [Arm] -- The XC32 v4.20 release introduced a new feature to generate a C source file from an ELF file. For larger ELF files, the v4.20 release would have generated an incomplete C file. The XC32 v4.21 release fixes this issue. (XC32-2319)

Data-Initialization Template Flash-Usage Improvements -- As described in the XC32 User's Guides, XC32 uses a linker-generated data-initialization template to copy initialization values from flash to RAM for initialized variables. This same mechanism clears uninitialized variables. This data-init template is generated in an output section named .dinit (XC32-1948).

Since the .dinit section contains an initialization template for every .data or .bss input section, it can grow large when your application has many of these sections. If your application has many modules or uses the -fdata-sections option, this can result in many templates.

This release of XC32 introduces a new mechanism, --dinit-compression=1, that will attempt to merge .data sections together into a single .data section. The sections initialized with the same value will be compressed. This typically results in a smaller .dinit section and therefore reduced Flash memory usage. It can do the same for .bss sections. This feature can be disabled by passing the --dinit-compression=0 or enabled by passing the --dinit-compression=1 to xc32-gcc at link time.

In our testing on various example applications that use a lot of initialized data, we have seen savings of several KB of flash. However, in applications that do not utilize initialized data, this option can increase code size by approximately 140 bytes due to added code required to decompress the section. We recommend experimenting with --dinit-compression=0 and --dinit-compression=1 to see which option works best for your particular application.

Immediate-Offset addressing optimization [Arm] -- Added a new optimization to reduce the immediate-offset value for load / store instructions that use the [areg, #imm_offset] addressing mode. This option is disabled by default. Use the compiler's -mopt-imm-offset option to enable it for your application.(XC32-1841)

Avoid negative immediate offsets [Arm] -- The induction variable optimizations have been improved to avoid negative offsets as a negative offset requires a 32-bit instruction encoding, while a positive offset can typically use a 16-bit encoding. In addition, the instruction scheduler has also been improved to avoid instructions using a negative immediate offset. (XC32-2046, XC32-2084, XC32-2187)

3a8082e126