1.) The wizzard asks for driver inclusion. Why aren't the chosen drivers not automatically included, e.g. #include "fsl_gpio.h" in main.c when I chose the GPIO driver in the wizzard?
2.) Why do I have to call e.g. GPIO_PortInit(GPIO, port) manually, although I chose a specific GPIO in the Pins tool? I would suggest this to be done automatically by the Pins tool in clock_config.c (or pinmux.c). I think to read
somewhere
*************************
EDIT: Tutorial: Blinky with the NXP LPC845-BRK Board | MCU on Eclipse
*************************
that on Kinetis version this is the standard (but haven't checked this).
*************************
EDIT: More bad on function WKT_Init(). DPDCTRL->LPOSCEN isn't set to "1" by this function when low power oscillator is chosen as clock source. Power has to be enabled manually in this case. This code doesn't work:
wkt_config_t wkt_config;
WKT_GetDefaultConfig(&wkt_config);
wkt_config.clockSource = kWKT_LowPowerClockSource;
WKT_Init(WKT, &wkt_config);
Changing the clock source and then init the peripheral doesn't work.
*************************
3.) LPC845-BRK example blinky: Why is GPIO configured twice? First in Pins tool (Direction: Output, GPIO initial state: 0, Mode: PullUp??? why this???) and then in main.c with "gpio_pin_config_t led_config" ?
Hello,
Regards,
Sebastian
1.) Sorry, but I can't believe that the wizzard doesn't know which .h and .c files belong to a driver. When I remove the WKT from the project via "Manage SDK components" (untick "wkt") this dialog appears:
So the belonging files are well known. And even if not: The files are named like the driver, added by .h. or.c.
I haven't find out yet where the changes are made in the background.
2.) I use the LPC845-BRK (MCUXPresso 10.3.1 and SDK 2.5.0 for LPC845) and created a new project with the wizzard. During the dialog I added the gpio driver.
I started pins tool and chose config below.
My estimation was: I chose a specific pin (PIO1_0, port and pin number are known), a direction of that pin, an initial value (0) and the pull-up (no pull-up). So the tool translates this into code, including the #include "fsl_gpio.h, enables the relevant clocks and I can start to use use functions like GPIO_PortToggle() in main.
That the LPO isn't powered automatically (like I stated as a mistake above) is correct, I think, because it's not the default clock source for the WKT.
3.) I have to reread the Config-tool docu carefully, I think.
Hello,
Thank you for your feedback.
Since not every code implementation is the same, the wizard does not automatically add the #include statements to your main file; this is done with the purpose of manually deciding which source files will use each library file.
Regards,
Sebastian
Question:
LPC845-BRK example blinky: Why is GPIO configured twice? First in Pins tool (Direction: Output, GPIO initial state: 0, Mode: PullUp??? why this???) and then in main.c with "gpio_pin_config_t led_config" ?
Answer:
It's not really being initialized twice. Could you please check the led_blinky.c file, there you will find it's just being set as an output, while in the pin_mux.c file we are setting other configurations, such as the pullup resistor.
Reply:
I followed your advise and checked the code: BOARD_InitPins() is the first function called in main. This function is created by mex-file, residing in pin_mux.c:
void BOARD_InitPins(void)
{
GPIO->DIR[1] = ((GPIO->DIR[1] &
/* Mask bits to zero which are setting */
(~(GPIO_DIR_DIRP_MASK)))
/* Selects pin direction for pin PIOm_n (bit 0 = PIOn_0, bit 1 = PIOn_1, etc.). Supported pins
* depends on the specific device and package. 0 = input. 1 = output.: 0x02u */
| GPIO_DIR_DIRP(0x02u));
}
The upper part is completely useless, because "everything" & 0x0000 0000 results in 0x0000 0000. This result (0) is ORed with "2". So simply writing GPIO_DIR_DIRP(0x02u) would be enough here.
So here the pin is set to output.
GPIO_PinInit(GPIO, BOARD_LED_PORT, BOARD_LED_PIN, &led_config); does the same. In struct led_config the setting for pin to output is done.
Hello,
Sorry for any inconvenience caused by this.
Thank you for your comments and feedback, we will take them into account for our next release.
Best regards,
Sebastian