Giter Site home page Giter Site logo

microchip-mplab-harmony / csp Goto Github PK

View Code? Open in Web Editor NEW
33.0 18.0 21.0 446.35 MB

Harmony 3 Chip Support Package

Home Page: https://microchip-mplab-harmony.github.io/csp/

License: Other

C 2.74% Python 51.61% FreeMarker 42.53% Fluent 0.05% HTML 0.10% TypeScript 2.66% JavaScript 0.22% CSS 0.09%
mplab-harmony microchip-mplab

csp's Introduction

Microchip logo Harmony logo small

MPLAB® Harmony 3 Chip Support Package

MPLAB® Harmony 3 is an extension of the MPLAB® ecosystem for creating embedded firmware solutions for Microchip 32-bit SAM and PIC® microcontroller and microprocessor devices. Refer to the following links for more information.

This repository contains the MPLAB® Harmony 3 Chip Support Package (CSP). The CSP supports initialization of Microchip 32-bit SAM and PIC® microcontroller and microprocessor devices and development of simple applications that directly control peripheral hardware with minimal external dependencies. Refer to the following links for release notes, training materials, and interface reference information.

Contents Summary

Folder Description
apps Example applications for CSP library components
arch Initialization and starter code templates and data
docs CSP library help documentation
peripheral Peripheral library templates and configuration data
plugins UI configurator plugins for different peripherals

License Latest release Latest release date Commit activity Contributors


Follow us on Youtube Follow us on LinkedIn Follow us on Facebook Follow us on Twitter

csp's People

Contributors

aditya-shankar avatar aethaniel avatar amitraddi avatar arpananand1 avatar azbullseye avatar budcaldwell avatar cristianguemes avatar dineshvedium avatar djsaz avatar dsettu avatar jeevithkumar avatar jigneshmoradiya1 avatar joffreycoffineau avatar kkathirvel avatar manjunathshiremath avatar mchp-mcu32dc0 avatar mhgc avatar microchip-gfx avatar mohan-kumar-rp avatar mratre avatar nagarjunaguttikonda avatar padmarajjain avatar prachiap avatar sandeepm1 avatar sumanthsuraneni avatar syamknair avatar syedthaseemuddin avatar tom-crosley avatar vishalnxt avatar zzelevl avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

csp's Issues

UART Polling process problem

Device: PIC32MK MCJ Curiosity Pro EVB
IDE: MPLAB X IDE v5.40, XC32 v2.50
BootLoader: Harmony3 UART_Bootloader (https://github.com/Microchip-MPLAB-Harmony/bootloader_apps_uart/tree/master/apps/uart_bootloader)

I have other questions.
I am writing UART transmission/reception by polling method.
Transmission seems to be fine in PIC.
However, there is a problem in receiving processing.
It appears to be a phenomenon caused by RX FIFO on the UART module of PIC32MK.
RX FIFO is 8-Level and up to 8 bytes can be received without problem.
However, if 9 bytes are transmitted, reception processing is performed at the first time, but reception processing is not performed at all after that.

I try to receive 8 bytes 3 times, and finally, after receiving 9 bytes, I cannot receive it.
image

What causes this phenomenon?
No matter how simple you modify the code, it is the same.
The code I received and processed is as follows.
image

printf processing issue

Device: PIC32MK MCJ Curiosity Pro EVB
IDE: MPLAB X IDE v5.40, XC32 v2.50
BootLoader: Harmony3 UART_Bootloader (https://github.com/Microchip-MPLAB-Harmony/bootloader_apps_uart/tree/master/apps/uart_bootloader)

I am doing UART transmission by connecting printf.
Most of the communication is performed normally.
However, the data of certain characters is a problem.
I am sending a string.
It contains a mixture of ASCII and hexadecimal characters.
I sent the data "5B 0A 43 58 45 4E 41 42 4C 45 8F 5D".
printf("[%cCXENABLE%c]",0x0A10,0x8F);
image

I wrote it with the code above.
When the code is executed, data is transmitted,
Data on the receiving side is received as "5B 0D 0A 43 58 45 4E 41 42 4C 45 8F 5D".
image

If 0A (ASCII-Line Feed) is always sent, 0D (ASCII-Carriage Return) is attached in front of 0A and received in the form of 0D 0A.
It seems to change that way in printf processing.
I am curious about the cause of this phenomenon and how to improve it.

SPI Library Documentation

I've noticed 2 minor documentation issues for the SPI Peripheral Library. I am using a PIC32MZ.

In the SPIx_WriteRead documentation it is stated that It returns False if either of the size parameters are 0 and corresponding data pointer is NULL. which is not accurate. The function will return false if both size parameters are 0.

In the SPIx_TransferSetup there is no mention of the fact that for the spiSourceClock a value of 0 will default to Use Master Clock Frequency set in GUI. If this is something that will become obsolete in the future ignore it.

How to send and receive CAN FD Frames with more than 8 Bytes of data.

Title states the problem. We can only send and receive data using

bool CAN0_MessageTransmitFifo(uint8_t numberOfMessage, CAN_TX_BUFFER *txBuffer);
or
bool CAN0_MessageReceiveFifo(CAN_RX_FIFO_NUM rxFifoNum, uint8_t numberOfMessage, CAN_RX_BUFFER *rxBuffer);

respectively. However in https://github.com/Microchip-MPLAB-Harmony/csp/blob/f6814f5b3f60f7743dad711b866c929169dc0037/peripheral/can_u2003/templates/plib_can_common.h.ftl#L370C3-L370C3 it is hardcoded that both rx and tx buffer objects only contain a maximum of 8 data bytes.

More drastically in https://github.com/Microchip-MPLAB-Harmony/csp/blob/f6814f5b3f60f7743dad711b866c929169dc0037/peripheral/can_u2003/templates/plib_can.c.ftl#L238C14-L238C14 we copy data from register buffer to rx buffer object. Let's assume in MCC we configured FiFo size to hold the maximum of 64 Data Bytes (there is a dropdown for that for Rx and Tx Fifos in MCC). In that case MCC declares macro #define CAN0_RX_FIFO0_ELEMENT_SIZE 72U (which sounds reasonable for 4 Byte Id + 4 Bytes Misc + 64 Bytes Data; too lazy to check with datasheet, as this is not the point I am making) which means we copy 72 Bytes of data in a struct that is only 16 Bytes of size, causing overflow and therefore undefined behaviour.

Possible ways forward:

  • Increase data length to constant 64 Bytes --> wastes memory for all of us that only want to use 8 Byte maximum, but easily implemented
  • Configure data length according to user selection in MCC --> probably most elegant solution

Keep in mind I might have overlook some consequences.

PIC32MX340F512H.atdf not found

Hi,
I can't find the pic32mx340f512h.atdf in /dev_packs/Microchip/PIC32MX_DFP/1.1.215/atdf/
Harmony V3 crash with error : Unable to locate ATDF file for processor ID "PIC32MX340F512H"
Can you help me ?
Thanks

SAMV7x - Image Sensor Interface peripheral support?

Hi all,

I just noticed that the CSP for SAMV7x does not have ISI.

New Project > SAMV71Q21B > Harmony 3 Configurator > Peripherals Drop Down but could not find ISI in the peripheral list.

Is the support for ISI planned?

Regards,
Shashank

Vector Table incorrectly defined

For the ATSAMC20 and ATSAMC21 (Cortex M0+) there are 32 interrupts, after PTC_Handler there should be reserved vector. The header file "device_vectors.h" should have pfn_handler_t pfnReserved31; after pfn_handler_t pfnPTC_Handler; so that it falls on a page boundary.

[EVIC] interrupts_vector_table.h.ftl error

PIC32MX795F512L

Error on generating files:

<FreeMarker>[Error]: An exception was thrown while attempting to markup a template file: C:\microchip\harmony\v3\csp\peripheral\evic_01166\templates\system\interrupts_vector_table.h.ftl
<FreeMarker>[Error]: freemarker.core.InvalidReferenceException: The following has evaluated to null or missing:
==> .vars["EVIC_PRIORITY_" + .vars[INT_PRIORITY] + "ATTRIBUTE"]  [in template "interrupts_vector_table.h.ftl" at line 81, column 82]

----
Tip: It's the final [] step that caused this error, not those before it.
----
Tip: If the failing expression is known to be legally refer to something that's sometimes null or missing, either specify a default value like myOptionalVar!myDefault, or use <#if myOptionalVar??>when-present<#else>when-missing</#if>. (These only cover the last step of the expression; to cover the whole expression, use parenthesis: (myOptionalVar.foo)!myDefault, (myOptionalVar.foo)??
----

----
FTL stack trace ("~" means nesting-related):
	- Failed at: ${.vars["EVIC_PRIORITY_" + .vars[INT_...  [in template "interrupts_vector_table.h.ftl" at line 81, column 80]
----
<FreeMarker>[Error]: 	- Failed at: ${.vars["EVIC_PRIORITY_" + .vars[INT_...  [in template "interrupts_vector_table.h.ftl" at line 81, column 80]
<Generate>[Info]: An exception occured during file preprocessing.
<Log>[Error]: Exception cause: java.lang.Exception: Error during file preprocessing.
<Log>[Error]: Stack trace:
<Log>[Error]: com.microchip.mh3.generate.GenerateCommon.preprocessFileToString(GenerateCommon.java:93)
<Log>[Error]: com.microchip.mh3.generate.engine.mplabx.GenerateEngineMPLABX.generate(GenerateEngineMPLABX.java:128)
<Log>[Error]: com.microchip.mh3.generate.Generate$2.run(Generate.java:361)
<Log>[Error]: java.lang.Thread.run(Thread.java:748)
<Generate>[Error]: Aborting project generation.  Your project has not been modified.

if all changes made in 2020 which effects [EVIC] are revered, the file generation is successful.

<#lt>void __ISR(${.vars[INT_VECTOR]}, ipl${.vars[INT_PRIORITY]}${.vars["EVIC_PRIORITY_" + .vars[INT_PRIORITY] + "ATTRIBUTE"]}) ${.vars[INT_HANDLER]} (void)

2 CANFD on PIC32MK1024MCM100

Hi,

I work on PIC32MK1024MCM100 an CANFD in a custum board.
All CAN channel work correctly alone.
But when I tried to use 2, 3 or 4 CAN in same time PIC CRASH.
I think that the PIC don't start.

Could you help me

RAF6410

CANFD_Setup

SAM D5x/E5x Family 16-bit Timer data structure issue

Hello,
Generated tc.h file conatain tc_count16_registers_t structure
This structure has 16-bit long fields "tc_cc".
According to datasheet these fields have 16-bit width.
But in fact it is 32-bit width fields(MPlab IO View and hardware tests with PWM mode).
So we have mistakes in datasheet: addresses and sizes of CC0,CC11,CCBUF0,CCBUF1 for 16-bit TC mode.
I didn't find any information about this problem in Errata sheet.
Also we have mistakes in Harmony generated code according to datasheet.
Best regards,
Nikolay
1
2
3
4

Unable to update package using content manager

After trying to update the package this error occured:

"csp" has local changes. To checkout, please clean it using settings.

After trying to clean the next error occured:

"csp" package failed to clean.

By manualy deleting the package, updating the package is possible by simply installing the latest release.

Wrong variable usage in SPI slave tempates

Hi,

In SPI slave templates when it is configured to active low busy pin there is a missing "$" character at the beginning of the lines:

{PLIB_NAME}_PinWrite((${PLIB_NAME}_PIN)${SPI_INSTANCE_NAME}_BUSY_PIN, 1);

{PLIB_NAME}_PinWrite((${PLIB_NAME}_PIN)${SPI_BUSY_PIN}, 1);

{PLIB_NAME}_PinWrite((${PLIB_NAME}_PIN)${SPI_INSTANCE_NAME}_BUSY_PIN, 1);

Imre

PIC32MX460F512L support

Looking for support to be added for the MX460 please?

Any ETA?
Is there a guide of how i can help add this support my self? files to copy edit and add? happy to PR if its easy

UARTx_SerialSetup

after calling DRV_USART_SerialSetup the serial doesn't work anymore because UARTx_SerialSetup turns off the peripheral before change the parameters but when it turns on again, UTXEN and URXEN remain off

Harmony Configurator's Pin Configuration and Peripherals availability for SAMD10C14A differs from datasheet

Hi,
I'm trying to use SERCOM2 with SAMD10C14's pins 4 and 5 (PA14 and PA15), since the datasheet says they are available as SERCOM-ALT:
pin mux
However, I have two problems when using the MPLAB Harmony Configurator:

  • SERCOM2 isn't available as a Peripheral
  • SERCOM2 isn't available as an alternative for these pins
    image
    Maybe I'm getting something wrong from the docs or there is a reason why it's not available, I'm sorry if that's the case, but I couldn't find any of these in the documentation.

The RTCC_TimeGet() function of plib_rtcc.c does not use a standard tm struct.

In the function:
void RTCC_TimeGet( struct tm Time )
from the harmony library (plib_rtcc.c)
The tm_year field according to the standard is:
int tm_year; /the years since 1900/
However, in this function this variable is set to an exact value of year 0.
So if the standard is followed with this function we get errors.
It would only be necessary to change line 175:
....
//tmp += 2000U; /
This RTC is designed for a range of 0 to 99 years. You have to add 2000 to that. */
tmp += 100U; //To adjust the structure to standard time it is necessary to add 2000 and subtract 1900 from this field. That is, add 100.
Time->tm_year = (int)tmp;
....

Configuration for ATSAME70N20 failes for PIO and CLK

The Harmony configurator doesn't correctly configure the register UTMI_REGS->UTMI_CKTRIM in file "plib_clk.c". In fact, either configuring for a 12 MHz or a 16 MHz crystal in the harmony configurator, the register is always set to UTMI_CKTRIM_FREQ_XTAL12 and never to UTMI_CKTRIM_FREQ_XTAL16. This is maybe a problem in the configurator and not in the template files.
Second problem is for PIO. The device doesn't have a PORTC but has a PORTD. The configurator fails first to execute. The fix for this is to change the line 657 of the file "plib_pio.c.ftl" from <#if PIO_C_INTERRUPT_USED??> to <#if PIO_D_INTERRUPT_USED??>.
Then, the generated plib_pio.c file has a configuration for PORTC but not for PORTD, so the compilation fails. You need to manually delete all PORTC related registers and configure PORTD, but all PORTD related configuration from the visual pin manager is lost.

Infinite loop in SDHC driver.

I ran into an issue due to following line:

while ((${SDHC_INSTANCE_NAME}_REGS->SDHC_PSR & (SDHC_PSR_CMDINHC_Msk | SDHC_PSR_CMDINHD_Msk)) != 0U)

https://github.com/Microchip-MPLAB-Harmony/csp/blob/90adeccd9213d7d66be8a14a17220638f25ef9fd/peripheral/sdhc_u2011/templates/plib_sdhc.c.ftl#L386C25-L386C25

With some specific hardware issues, those bits may never be cleared, which causes an infinite loop. There should probably be some kind of max iteration count, in order to return false if the bits are not eventually cleared.

PIC32MX460F512L

Support for this chip seems to be missing.
Would be nice to have that added.
From the looks of it all the 460 chips are missing.

PIC32MZW WTD reset clock initialisation

The following change causes the device to lockup after a WDT reset occurs as the clocks are no longer initialised:
38e536e

Adding a test for the "RCONbits.WDTO" bit as with the "RCONbits.SWR" bit works around the issue.

PIC32MX440F256H is missing.

Hello.

I've installed latest updates, but cannot start Harmony v3 with my PIC32MX440F256H.
Error: Unable to locate ATDF file...

What should I do?

Thanks.

Support for SAM cortex-m3 MCUs

Hello, I'd want to ask - is it planned to add support for SAM Cortex-M3 MCUs like SAM3U or SAM3X series? They're great small MCUs with tons of capabilities but they can be seen now like little out of support.

PIC32MX interrupt error for UART1-3

Attempts to use UART1, UART2, UART3 cause an error when generating the configuration, but only if the interrupts are enabled.

<FreeMarker>[Error]: An exception was thrown while attempting to markup a template file: D:\HarmonyFramework\csp\peripheral\evic_01166\templates\system\interrupts_vector_asm.h.ftl
<FreeMarker>[Error]: freemarker.core.InvalidReferenceException: The following has evaluated to null or missing:
==> .vars[INT_NUMBER]  [in template "interrupts_vector_asm.h.ftl" at line 34, column 56]

The underlying cause appears to be the way the interrupts are configured in the 01166 EVIC module.
In a few cases, interrupts are shared between peripherals, and the evic.py code understands this. It generates symbols like EVIC_4_NUMBER, EVIC_5_NUMBER for interrupts that are not shared, but for interrupts that are shared, it uses names like EVIC_24_0_NUMBER, EVIC_24_1_NUMBER, EVIC_24_2_NUMBER. See code around lines 332 and 392 in csp\peripheral\evic_01166\config\evic.py

The problem comes when this information is used by the template in csp\peripheral\evic_01166\templates\system\interrupts_vector_asm.h.ftl

The template assigns a local variable called INT_NUMBER with a format like EVIC_4_NUMBER. This works fine where interrupts are not shared, but where interrupts are shared, this fails. For example, there is no such variable as EVIC_24_NUMBER, because there are three variables for this interrupt EVIC_24_0_NUMBER etc.
This causes the lookup to fail, since the expression .vars[INT_NUMBER] fails when INT_NUMBER is EVIC_24_NUMBER

As a temporary workaround, I have used UART4, which does not use a shared interrupt.

PIC32MZ2048ECM100

Hello there,
our product uses the PIC32MZ2048ECM100 which doesn't seem to be supported by Harmony3 (i see EF is supported).

What do you recommend?
Using Harmony3 configured for the PIC32MZ2048EFM100 and then changing the drivers (like 8740 to 8720) or use Harmony2?

Reading the changelogs Harmony3 seems to be the best choice due to all the improvements.

Thanks

AD1CSSL Value gets overwritten

Hello,

sometimes when regenerating all harmony files, the value of the AD1CSSL Register will be overwritten with another Value.

I'm using the following configuration for the adc.
grafik

It seems that the configurator doesnt recognize the choosen Input Scan Pins.

PIC32MX450F256H
CSP 3.8.1

Cannot Launch MHC 3

I am unable to open MHC 3 on Linux for the SAMS70 processor. I get the following error:

MHC.log

I verified all my components are up to date

Bug in UART driver

A recent update has introduced a bug in the UART driver.
See commit 7823048

The problem was experienced on a PIC32MX device, using UART6 without a ring buffer,

This commit moved the point where the TX interrupt flag was cleared. Previously it was cleared after new data had been pushed into the TX FIFO, but this commit changed it to be cleared before new data had been pushed to the TX FIFO. Crucially, this means that the TX interrupt flag was cleared while the interrupt condition still existed (i.e. the TX buffer was still empty).

See the following note from the PIC32MX Technical Reference manual Section 21.5.2

For UART modules with an 8-level-deep FIFO, an interrupt is generated and asserted when the
interrupt condition specified by the UTXISEL control bits is true. This means, to clear an interrupt
for these modules, before clearing the corresponding UxTXIF flag bit, the user application must
ensure that the interrupt condition specified by the UTXISEL control bits is no longer true.

The result is that a second TX interrupt occurs immediately after the first one. It looks like the original code tolerates this by the use of the uart6Obj.txBusyStatus flag however there are some weird edge cases where this doesn't work as expected.

The point is that clearing the TX Interrupt flag at that point is clearly incorrect according to the PIC32MX manual (and also, has broken my serial comms code!! ).

I don't know whether there is a similar issue with the RX Interrupt.

I would be interested to know the rationale behind this change - was it to fix an RX problem?

dfp path is not valid in ubuntu14.04

how do i fix this , when i just open a sama5d2-demo followed by Get Started with Harmony 3 on the SAMA5D2 pages, i confirmed my DFP and CMSIS path placed in win-form "configuration database setup ", i confirmed read-write-exec priority of the path and files, but not worked , and the Launch button is always gray !!

Extended CAN template issue

txMessage->msgEID = ((id & 0x3FFFF) << 10) | CAN_MSG_IDE_MASK;

should read:
txMessage->msgEID = ((id & 0x3FFFF) << 10) | CAN_MSG_IDE_MASK | CAN_MSG_SRR_MASK;

this causes many issues in Extended CAN applications.

As per Microchip documentation:
SRR: Substitute Remote Request bit
In case of a standard message format (IDE = 0), this bit is don’t care.
In case of an extended message format (IDE = 1), this bit should always be set.

C++ compatibility of gpio functions

peripheral/gpio/plib_gpio.h is missing some cast to be c++ compatible.

With this casts it can compile with xc32-g++

static inline void GPIO_PinWrite(GPIO_PIN pin, bool value)
{
    GPIO_PortWrite((GPIO_PORT)(pin >> 4), (uint32_t)(0x1) << (pin & 0xF),
                   (uint32_t)(value) << (pin & 0xF));
}

static inline bool GPIO_PinRead(GPIO_PIN pin)
{
    return (bool)(((GPIO_PortRead((GPIO_PORT)(pin >> 4))) >> (pin & 0xF)) & 0x1);
}

static inline bool GPIO_PinLatchRead(GPIO_PIN pin)
{
    return (bool)((GPIO_PortLatchRead((GPIO_PORT)(pin >> 4)) >> (pin & 0xF)) & 0x1);
}

static inline void GPIO_PinToggle(GPIO_PIN pin)
{
    GPIO_PortToggle((GPIO_PORT)(pin >> 4), 0x1 << (pin & 0xF));
}

static inline void GPIO_PinSet(GPIO_PIN pin)
{
    GPIO_PortSet((GPIO_PORT)(pin >> 4), 0x1 << (pin & 0xF));
}

static inline void GPIO_PinClear(GPIO_PIN pin)
{
    GPIO_PortClear((GPIO_PORT)(pin >> 4), 0x1 << (pin & 0xF));
}

static inline void GPIO_PinInputEnable(GPIO_PIN pin)
{
    GPIO_PortInputEnable((GPIO_PORT)(pin >> 4), 0x1 << (pin & 0xF));
}

static inline void GPIO_PinOutputEnable(GPIO_PIN pin)
{
    GPIO_PortOutputEnable((GPIO_PORT)(pin >> 4), 0x1 << (pin & 0xF));
}

PWM0_CH3 not listed in configuration for ATSAME70N19B

For an ATSAME70N19B (LQFP100 package), the PWM0 module configuration in Harmony 3 shows only channels 0..2, but not channel 3. For the PWM1 module, all four channels 0..3 are shown as expected.

Analysis
The ATDF file .\dev_packs\Microchip\SAME70_DFP\4.6.98\same70b\atdf\ATSAME70N19B.atdf lists the following signals for PWM0 with group "PWMH"

<module name="PWM" id="6343" version="Y">
 <instance name="PWM0">
  <signals>
   <signal pad="PA7" function="B" group="PWMH" index="3"/>
   <signal pad="PA14" function="B" group="PWMH" index="3"/>
   <signal pad="PA17" function="C" group="PWMH" index="3"/>
   <signal pad="PD23" function="A" group="PWMH" index="3"/>
 </signals>
[...]

The pinouts section for the LQFP100 package lists PA7, PA14, and PA17, but not PD23. This seems in line with the data sheet.

Considering the following code, where it is checked if the output pins for the individual PWM channels are available:

#Find available channels and available external clock pins
pwm_signals = []
pwm = ATDF.getNode("/avr-tools-device-file/devices/device/peripherals/module@[name=\"PWM\"]/instance@[name=\""+pwmInstanceName.getValue()+"\"]/signals")
pwm_signals = pwm.getChildren()
for pad in range(0, len(pwm_signals)):
if "PWMH" in pwm_signals[pad].getAttribute("group"):
padSignal = pwm_signals[pad].getAttribute("pad")
if padSignal in availablePins:
channel[int(pwm_signals[pad].getAttribute("index"))] = True
else:
channel[int(pwm_signals[pad].getAttribute("index"))] = False

Here, the last padSignal encountered is PD23, which is not available on the LQFP100 package. However, this should not matter as three other pins are available for the PWM channel 3 signal.

It seems, the code silently assumes that each PWMH signal may be assigned to at most one output pin. However, with the situation as described herein, the logic to my understanding should be "display channel configuration if there is at least one output pin available". As the channel array is initialized to False in line 481, it should suffice to remove lines 506-507:

   for pad in range(0, len(pwm_signals)):
        if "PWMH" in pwm_signals[pad].getAttribute("group"):
            padSignal = pwm_signals[pad].getAttribute("pad")
            if padSignal in availablePins:
                channel[int(pwm_signals[pad].getAttribute("index"))] = True
            #else:
            #    channel[int(pwm_signals[pad].getAttribute("index"))] = False

This fixed the issue on my project.

exceptionsHandler.s.ftl

IAR EWARM version 9.10.2.
Bad instruction in lines 48, 49, 50, 52, 54, 77, and 83.

These instruction used in GCC assembler, not in IAR as implemented.

NVM Driver Documentation missing function

The Library interface documentation for the NVM driver is missing the NVM_QuadWordWrite entry.
Quad Word write is available on PIC32MZ devices and is it already implemented in the harmony driver but not listed in the documentation.

TMR documentation does not match function

In the:
Harmony3\csp\peripheral\tmr_00745\templates\plib_tmr_common.h

The event callback function requires two arguments.
// *****************************************************************************
/* TMR_CALLBACK

Summary:
Use to register a callback with the TMR.

Description:
When a match is asserted, a callback can be activated.
Use TMR_CALLBACK as the function pointer to register the callback
with the match.

Remarks:
The callback should look like:
void callback(handle, context);
Make sure the return value and parameters of the callback are correct.
*/

typedef void (*TMR_CALLBACK)(uint32_t status, uintptr_t context);

// *****************************************************************************

However in the Harmony3/csp/docs/ it incorrectly only says one argument is required.

  • This function is called after period expires /
    void TIMER2_EventHandler(uintptr_t context)
    {
    /
    Toggle LED */
    LED_Toggle();
    }

int main(void)
{
/* Register callback function Timer interrupt */
TMR2_CallbackRegister(TIMER2_EventHandler,(uintptr_t)NULL);

/* Start the timer channel 0*/
TMR2_Start();

}

Could the documentation be changed to match the actual usage?

Best regards,
Robert

Clock Configurator for e51 not working

Latest commit of clock configurator (clk_sam_e5x.jar) does not work, at least not with SAME51J19A.
Trying to start it from Harmony configurator does nothing.

Changed clk_sam_e5x.jar to previous version (from 26 July 2019) and it starts fine.
Using Harmony Configurator v3.4.1

SMBus features request for PIC32MZ series devices.

I am trying to implement SMBus logic with the I2C driver for a PIC32MZ2048EFM100.
My application uses the above mention PIC MCU but this feature request is probably mostly the same for other MCUs in the PIC32MZ EF series.

The MCU should be an SMBus Master & Slave .

  • Current harmony only allows me to select either a I2C Master or I2C Slave implementation not both.

SMBus BlockRead & BlockWrite-BlockRead not supported.

  • The BlockRead & BlockWrite-BlockRead Protocols specify that the first byte read specifies the number of bytes that follow and the current driver doesn't support this dynamical reading capability.
  • All other SMBus BUS Protocols I can make with the available driver functions.

I checked "PIC32 Family Reference Manual, Sect. 24 Inter-Integrated Circuit" manual and in the overview it gives an example that this is possible as the I2C Master & I2C Slave work independently form each other in the I2C Module.

As I am not to familiar with the internal workings of the Harmony project I didn't manage to implement this myself yet, hence my request to look if this can be integrated in the driver for the devices that support is.

SAMD21 I2S

unable use samd21 i2s without "i2s_u2224" sub directory folder in "csp\peripheral" directory

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.