Not applicable
Apr 22, 2014
05:08 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Apr 22, 2014
05:08 AM
3 Replies
Apr 24, 2014
01:35 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Apr 24, 2014
01:35 AM
Hi Dough,
I guess that with "linked" you mean hardware connected.Correct me if I am wrong ?
I don't understand "This linkage is not reflected well in generated code forcing the programmer to always reference DAVE" Could you write an example ?
Best Regards
Oreste
I guess that with "linked" you mean hardware connected.Correct me if I am wrong ?
I don't understand "This linkage is not reflected well in generated code forcing the programmer to always reference DAVE" Could you write an example ?
Best Regards
Oreste
Not applicable
Apr 25, 2014
07:05 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Apr 25, 2014
07:05 AM
Oreste,
I have many different apps linked to NVIC002 apps, DMA003, PWMSP001, PWMMP001. UART001, I2C001.
The NVIC002 initialization and configuration sets the node priority and initializes the interrupt as appropriate, but creates no connectivity.
To find the connectivity the user must find the hardware unit say, CCU80_CC80 for PWMMP001 in PWMMP001_Conf.c, and then go to multiplexer.c and find which interrupt line is used.
Next the NVIC002_Conf.c is used to find which instance is used to.
The reference manual is used to thoughout this process to find which interrupt connect to the specific output of CCU80, and which register(s) the CCU80 use for connecting to interrupts.
If an NVIC002 is used to connect a UART001 or I2C001 and DMA003 app then another connection in code must be made between the NVIC and DLR.
Referencing the DAVE project is by far easier than the generated code when it comes to hardware connectivity.
It is valuable to have the connectivity represented in DAVE translate to an easily traceable code.
Regards,
Doug
I have many different apps linked to NVIC002 apps, DMA003, PWMSP001, PWMMP001. UART001, I2C001.
The NVIC002 initialization and configuration sets the node priority and initializes the interrupt as appropriate, but creates no connectivity.
To find the connectivity the user must find the hardware unit say, CCU80_CC80 for PWMMP001 in PWMMP001_Conf.c, and then go to multiplexer.c and find which interrupt line is used.
Next the NVIC002_Conf.c is used to find which instance is used to.
The reference manual is used to thoughout this process to find which interrupt connect to the specific output of CCU80, and which register(s) the CCU80 use for connecting to interrupts.
If an NVIC002 is used to connect a UART001 or I2C001 and DMA003 app then another connection in code must be made between the NVIC and DLR.
Referencing the DAVE project is by far easier than the generated code when it comes to hardware connectivity.
It is valuable to have the connectivity represented in DAVE translate to an easily traceable code.
Regards,
Doug
Apr 30, 2014
01:17 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Apr 30, 2014
01:17 AM
Hi Doug,
If I understand correctly you would like to understand from the code the connectivity.
We have already planned to improve this in the next major release of Dave.
Multiplexer.c will disappear. Each app will be in charge of configuring the multiplexer register of the used HW resources.
E.g.
For NVIC002 there will be no change (there is no mux in NVIC peripheral)
But for the other app you will find the code that configure the muxex in the other apps DMA003, PWMSP001, PWMMP001. UART001, I2C001.
However the code will not so clear because the intermediate signals (signals between peripherals) names are not present in the solver and so they can be used easily used in the app template. (Technical rationale: solver is designed to be as fast as possible and all interconnection is 'precompiled' in special compact and efficient representation )
A hw connectivity explorer is under evaluation to help the user to understand the mux registers configuration.
Best Regards
Oreste
If I understand correctly you would like to understand from the code the connectivity.
We have already planned to improve this in the next major release of Dave.
Multiplexer.c will disappear. Each app will be in charge of configuring the multiplexer register of the used HW resources.
E.g.
For NVIC002 there will be no change (there is no mux in NVIC peripheral)
But for the other app you will find the code that configure the muxex in the other apps DMA003, PWMSP001, PWMMP001. UART001, I2C001.
However the code will not so clear because the intermediate signals (signals between peripherals) names are not present in the solver and so they can be used easily used in the app template. (Technical rationale: solver is designed to be as fast as possible and all interconnection is 'precompiled' in special compact and efficient representation )
A hw connectivity explorer is under evaluation to help the user to understand the mux registers configuration.
Best Regards
Oreste