|
Main / Micros
Microchip PICGlossary
Chip Families8-bit PICs: Baseline Architecture PIC10 PIC12 PIC16 Mid-Range Architecture PIC12 PIC16 Enhanced Mid-Range Architecture PIC12F1xx PIC16F1xx PIC18F PIC18 "J" Series PIC18 "K" Series 16-bit PICs: PIC24F - Lowest Power PIC24H - Higher Performance PIC24E - Highest Performance dsPIC30F - 5V & EEPROM DSC dsPIC33F - High Performance DSC dsPIC33E - Highest Performance DSC dsPIC33EV - 5V dsPIC33 "EV" Family DSC dsPIC33CH - Dual Core DSC 32-bit PICs: PIC32MK PIC32MM - eXtreme Low Power (XLP) PIC32MM GPL PIC32MM GPM PIC32MX PIC32MX1/2 - eXtreme Low Power (XLP) PIC32MX3/4 PIC32MX5/6/7 - Integrated Ethernet MAC PIC32MZ - Embedded Connectivity (EC) Family PIC32MZ1024 - 1 MB Flash PIC32MZ2048 - 2 MB Flash PIC32MZ EF - Highest performance PIC32MZ DA - Integrated Graphics Acceleration & DRAM For PIC32MZ, you have flash memory size, then family (EF is for Embedded Connectivity with FPU), followed by key feature set.
After that is pin count. PIC32MX Instruction Set Reference: https://johnloomis.org/microchip/pic32/cpu/instructions.html ADCA lot of things are tweaked with the PIC32MZ ADC, here's a rundown: DelaysThere is no built-in delay function in XC32. You should use the core timer as a system tick. One idea:
#define TICK_PER_MS (_XTAL_FREQ/2/1000)
void __delay_ms(uint32_t ms)
{
uint32_t Start=_CP0_GET_COUNT();
uint32_t Duration=TICK_PER_MS*ms;
while((_CP0_GET_COUNT()-Start)<Duration);
}
Good PIC32MZ write-up: For the 16-bit chips, you can get delay functions and other handy tools with the libpic30.h mini-library. Working with MPLABProject CopyMPLAB v5.45 has a bug that manifests when trying to copy or rename an existing project or a board configuration, in that it doesn't change all the config management files it needs to. These links gave some good hints on working around the problem: Here is the process for copying to a new project:
Still trying to get the creation of a new configuration to work. For this case, it looks like you can live with a separate .X configuration folder inside the existing project firmware folder and share the same src files, but haven't perfected the process yet. Harmony Migration StepsIf you want to keep source code from an older project, but move on to use that code with a new version of MPLAB and Harmony, here are your steps.
Moving Git RepoCan follow a similar process to project copy but don't need quite as many steps. After cloning from the new location, do the cache deletion and nbproject folder deletions per above. Shouldn't need to change anything inside the .xml files. Make sure the ownership and permissions are correct on the .xml files. Then open MPLAB X and open the project at the new repo location and clean/rebuild. Java libusb Launch Fail Problem/mnt/newHHD/microchip/mplabx/v6.15/sys/java/zulu8.64.0.19-ca-fx-jre8.0.345-linux_x64/bin/java: symbol lookup error: /tmp/mplab_ide/mplabcomm1839511973792384871/mplabcomm2530709051246829272libUSBAccessLink_3_38.so: undefined symbol: libusb_handle_events_timeout_completed https://www.medo64.com/2023/10/mplabx-and-the-symbol-lookup-error/ Since there were a few links to the old MPLAB directory, I cleaned up /usr/lib a bit, but that didn't help. What did help was removing the older libusb altogether. sudo rm /usr/local/lib/libusb-1.0.so.0 How can that be? ll /usr/local/lib/libusb-1.0.so.0 lrwxrwxrwx 1 root root 17 Mar 21 2021 /usr/local/lib/libusb-1.0.so.0 -> libmchpusb-1.0.so Nothing else comes up in a search for libusb except libusb-1.0.so.0 on my system in /usr/local, but what about /usr/lib? ll /usr/lib/libusb* -rw-r--r-- 1 tyler tyler 302234 Sep 18 2014 /usr/lib/libusb-1.0.a -rw-r--r-- 1 tyler tyler 955 Sep 18 2014 /usr/lib/libusb-1.0.la lrwxrwxrwx 1 root root 19 Mar 21 2021 /usr/lib/libusb-1.0.so.0 -> libusb-1.0.so.0.0.0 -rw-r--r-- 1 tyler tyler 189956 Sep 18 2014 /usr/lib/libusb-1.0.so.0.0.0 Is it possible the /usr/local/ symlink was created by the MPLAB installer? The old one? Based on microchip forum: The installer created symbolic links to an older version of libusb. So this is a big error on Microchip's part. Removing the symlink does work, but need to keep an eye out for other problems this may cause with other SW. Even when removing that symlink, it respawns, unclear what triggers that. Its presence does cause interference with other programs, and it must be removed again. Git SCM for MPLAB
HarmonyInstalling HarmonyHarmony or Microchip Code Configurator is an added plug-in, but it doesn't seem to be available in the plug-in manager list in v5.45. I had to clone the repo and then point MPLABX to the .nbm file. https://forum.microchip.com/s/topic/a5C3l000000MdjGEAS/t382773 Low Level TerminologyThe PLIBS peripheral libraries are the lowest level of the MHC configurator generated code blocks, and are device-specific. Drivers and system services build on top of those. A driver is capable of handling multiple instances of a peripheral without duplicating the driver code to handle the individual instance of a peripheral. The OSAL OS abstraction layer sits between the common system services and the RTOS. Driver ModesGood high level summary of how Harmony v3 drivers are architected: http://ww1.microchip.com/downloads/en/DeviceDoc/The-Difference-Between-MPLAB-Harmonyv3-Synchronous-and-Asynchronous-Drivers-and-When-to-Use-DS90003269A.pdf Note they use synchronous and asynchronous to be analogous to blocking and non-blocking. They don't recommend the former for bare metal, only for RTOS, with the latter being suitable for either. This is because the RTOS scheduler can allow other tasks to run despite one being blocked. It's worth noting that the asynchronous implementations do take more memory space because there is more code to handle it. A state machine model is recommended for bare metal applications. Drivers vs PLIB APIsIn general, all PLIBs are interrupt driven, but few PLIBs have blocking implementation in addition to interrupt driven implementation. The APIs are quite simple with only a handful of functions. But what about the higher layer functions like DRV_SPI_BufferAddWriteRead()? Turns out these are the Driver API rather than PLIB API. The MPLAB Harmony v3 drivers are a highly abstracted interface to control, access, manage peripherals, and other resources on the 32-bit SAM and PIC microcontrollers. The driver interface allows applications and other client modules (drivers, Middleware libraries and system services) to interact with the peripheral. The following are MPLAB Harmony v3 driver features:
Direct comparison:
Heap SizeThe TCP/IP module needs a good size heap. The Harmony manual states In general, for a TCP/IP project running on a PIC32MX device with an embedded Ethernet controller, at least 8 KB of heap space is needed by the stack. However, the following is implied:• 100 Mbps traffic is not sustained• No SSL• Relatively few socketsA typical value for comfortably handling 100 Mbps Ethernet traffic would be 40 KB of TCP/IP heap space. But I found for my PIC32MZ project I needed to set it to more than 40KB. 32768 wasn't big enough to prevent the "Heap creation failed" error. XC32 and Debugger TroubleshootingIf your debugger dives into an exception handler on init when interrupts are enabled, one work around is to add a software breakpoint right there. MPLAB X IDE will pass -D__DEBUG to any compiler when it's kicking off a debug session, so it will leave that line out of a deployment build. Handy because that would freeze your execution otherwise. No idea why this works and makes the debugger behave.
#ifdef __DEBUG
__builtin_software_breakpoint();
#endif
Apparently the case where the EPC (read into excep_addr) is 0 or cannot be used to determine the instruction causing the exception, is called an imprecise exception: In this section, the terms precise and imprecise are used to describe exceptions. A precise exception is one in which the EPC (CP0, Register 14, Select 0) can be used to identify the instruction that caused the exception. For imprecise exceptions, the instruction that caused the exception cannot be identified. Most exceptions are precise. Bus error exceptions may be imprecise. By default, the size of the stack is 1024 bytes. Note that it appears if you switch compilers, this is reset. Slow build, hanging on project property changes, debugger failures, PIC crashesTurns out MPLAB is affected mightily if you have mounted drive points on your Linux system with no attached filesystem underneath. For example, a flash drive that's been removed or a network share that is lost on a VPN disconnect but wasn't unmounted. This can cause the intensely slow application launch, build, and even seems to relate to bad debugger comms that can make your PIC jump off into the weeds on execution during debug. Has to do probably with some kind of drive scanning procedure that is delayed by slow folder listing commands. Running ls on suspect folders seems to correlate, when it takes forever to complete. TCP/IP Stack WolfSSL Compile FailFor some reason, compilers past v2.50 don't make their min/max functions available so the compilation of the Wolfcrypt library fails. You must crack open the WOLFSSL_HAVE_MIN option to comment it out by defining NO_INLINE used in the Wolf misc.h file. In the project properties, for the XC32 gcc option you can add to the command line the text -D NO_INLINE. Then go to the MHC configuration.h file and look in the Wolf section for the #define WOLFSSL_HAVE_MIN line and comment that out so that Wolf knows that we do NOT have a min function. Silly, but this works. Broken breakpoints "unresolvable" to addressThis can happen when you have a bunch of different configurations for the same project, and there's all this code living under the firmware/src/config/<cfgnames>/ folders. You can delete everything you don't want in firmware/src/ and all the config folders except the active one and then re-generate everything you need from the MHC control menu. Communication fail with debuggerA problem can occur after closing MPLAB when the debugger hangs and won't pause/stop execution, but processes remain running that prevent re-use of the debugger with a new instance of MPLAB. Look for something still running in your processes like chpsegusbmonitor and kill all MPLAB related processes so you don't have to reboot your machine to bring it back. |