mplabx = xc32  header files with adress registers ? - Page 1
Forum section: electronics / general

author: snarkysparky
author_rank: Frequent Contributor
timestamp: August 28, 2025, 04:38:26 pm
content: I trying to setup mplabx for PIC32CM3204GV00048 because its cheap.For SAMD21 its apparent cousin you had in the Atmel studio header files things like thisREG_TC4_CTRLA (*(RwReg16*)0x42003000UL) /**< \brief (TC4) Control A */So.... I am stubborn and want to do bare metal startup. For that i need register addresses.But I cant find anything like this in either the "instance" or the "component" header files.How would you proceed.Thanks

author: ataradov
author_rank: Super Contributor
timestamp: August 28, 2025, 05:05:43 pm
content: Those things are in a device file in the device pack. For example, here is one from a generated projecthttps://github.com/Microchip-MPLAB-Harmony/csp_apps_pic32cm_jh00_jh01/blob/master/apps/tc/tc_timer_mode/firmware/src/packs/PIC32CM5164JH01100_DFP/pic32cm5164jh01100.hBut you can get device packs separately and extract the files you need.At the same time, I don't see why you would need the addresses. Something like this:Code:TC0_REGS->COUNT16.TC_CTRLA |= TC_CTRLA_ENABLE_Msk;is still baremetal, just using well defined structures.But to be fair, those defines are located in the same file.

author: JPortici
author_rank: Super Contributor
timestamp: August 28, 2025, 05:49:37 pm
content: wtf are instance and component?anyway, you just include <xc.h> (or xc.inc in assembly. Well, you do the latter for XC8/XC16, don't know about XC32)which will do some preprocessor magic, add some required defines then include the actual device header file (the one ataradov posted)and voila. All registers defined. You can forget that harmony or mcc even exists

author: ataradov
author_rank: Super Contributor
timestamp: August 28, 2025, 06:21:46 pm
content: Quote from: JPortici on August 28, 2025, 05:49:37 pmIt is a fairly logical way to separate definitions common to all instances of a peripheral and definitions specific to an instance.Quote from: JPortici on August 28, 2025, 05:49:37 pmThis would depend on header files shipped with a compiler, which may change with compiler versions. Some people might be fine with this, but I personally don't see how this is workable at all.

author: snarkysparky
author_rank: Frequent Contributor
timestamp: August 28, 2025, 06:37:48 pm
content: in hereC:\Program Files\Microchip\MPLABX\v6.25\packs\Microchip\PIC32CM-GV_DFP\1.0.7\PIC32CM-GV00\include\componentI find things like this. offset!#define PORT_DIR_REG_OFST _UINT32_(0x00) /* (PORT_DIR) Data Direction Offset */in hereC:\Program Files\Microchip\MPLABX\v6.25\packs\Microchip\PIC32CM-GV_DFP\1.0.7\PIC32CM-GV00\include\instanceI find this mostly useless info and nothing else/* ========== Instance Parameter definitions for PORT peripheral ========== */#define PORT_BITS (64) /* Number of PORT pins */#define PORT_DRVSTR (1) /* DRVSTR supported */#define PORT_GROUPS (2) /* Number of 32-bit PORT groups */#define PORT_INSTANCE_ID (35)#define PORT_ODRAIN (0) /* ODRAIN supported */#define PORT_SLEWLIM (0) /* SLEWLIM supported */#endif /* _PIC32CMGV00_PORT_INSTANCE_ */I see the base addresses listed in PIC32CM3204GV00048.hbut to access the individual registers i have to kludge together pointers with offsets ?The structures that point to registers would be fine like your exampleTC0_REGS->COUNT16.TC_CTRLA |= TC_CTRLA_ENABLE_Msk;But where do i find them ?Thanks

author: ataradov
author_rank: Super Contributor
timestamp: August 28, 2025, 06:45:33 pm
content: This is not useless if you write cross platform code. If you are relying on open drain output, then it is possible to check for the support in a specific device and may be compile alternative code or issue a warning.PORT is also bad example. More complex peripherals contain stuff like DMA and clock controller indexes.TC0_REGS should also be define in PIC32CM3204GV00048.h. It would be defined similar to this:Code:#define TC0_REGS ((tc_registers_t*)0x42003000)And tc_registers_t and corresponding defines are defined in the component file.But all you need to do is include "PIC32CM3204GV00048.h" and it will bring all those files automatically.

author: cv007
author_rank: Frequent Contributor
timestamp: August 28, 2025, 08:19:26 pm
content: QuoteThey have a generic pic32c.h header which is also in the dfp (device family pack), which is something like xc.h or sam.h where the ide defines the mcu chosen (via gui) and the generic device header ultimately chooses which mcu variation is in use (via an ide created device define and #if/else). If using the ide, a device has to be chosen anyway so you can include pic32c.h and you get the specific header included for you (and device pack chosen, linker script chosen, etc). Its probably a good idea to use the generic header if using the ide, so you and the ide are in sync about which mcu is in use- flash size, available pins, etc.

author: ataradov
author_rank: Super Contributor
timestamp: August 28, 2025, 08:44:22 pm
content: Well, yes, include whatever level is needed. Exact part number file is the lowest level that still makes sense to use.

author: westfw
author_rank: Super Contributor
timestamp: August 29, 2025, 02:55:25 am
content: The original PIC32 series (MIPS based) did a thing where peripheral base addresses where specified in linker files instead of as C #defines. I complained, and it was explained that this supposedly made it easier to move from one PIC32 chip to another.All I noticed was that the result was a lot of:Code:movhi r, high16bits(regaddr)movlo t, low16bits(regaddr+n);; do something.movhi r, high16bits(regaddr)movlo t, low16bits(regaddr+m)even though the high bits stayed the same, so the subsequent loads were unnecessary (but the compiler, which you might expect to optimize this, couldn't tell because the symbols didn't have values yet.)(using structures might have helped some, but you can fit multiple instances of a peripheral, or multiple peripherals, within 64k...)I haven't checked (yet) whether they've changed this since then, or done things differently for ARM than for the MIPS cores...

author: ataradov
author_rank: Super Contributor
timestamp: August 29, 2025, 02:59:09 am
content: ARM uses standard flow except for their hacked up linker.