Hi Anders,
I took a quick look and ran your code, and it appears that the pinmux for PTB22 is not configured correctly. The register field PORTB_PCR[MUX] is set to 0 when it should be set to 1. You should be able to fix this by pulling in the pinmux driver and changing the pin to function 1.
Maureen

Hi,
I don't know what's happening with your UART but regarding the GPIO, I think
the problem is K64 gpio driver doesn't configure the pin as GPIO when you
call the gpio_pin_configure function.
I got the same problem and applying the next patch solve it to me:

diff --git a/drivers/gpio/gpio_k64.c b/drivers/gpio/gpio_k64.c
index 2d6a355..011eb52 100644
--- a/drivers/gpio/gpio_k64.c
+++ b/drivers/gpio/gpio_k64.c
@@ -111,6 +111,9 @@ static int gpio_k64_config(struct device *dev, int
access_op,
}
}

+ /* Ensure pin is configured as GPIO */
+ setting |= K64_PINMUX_FUNC_GPIO;
+
/* write pull-up/-down and, if set, interrupt configuration settings */

if (access_op == GPIO_ACCESS_BY_PIN) {

Regards,
Carlos Carrizosa

2016-03-15 20:43 GMT+01:00 idups idups <idupsle(a)gmail.com>:

I did copy it to the MBED Mount Point (Actual Firmware)...
Besides, I forgot that I played a little bit with the kernel-config, which
isn't present in my prj.conf... but I'm sorry to say that I'm away from
home until saturday. But I think if you look at the other examples in
the Zephyr Project you'll get it to run. (Thats the way i fiddled it out)
Does the orange led on the usb-connection blink, if you type something in
the tty-session?

Hi,
I have tried your settings above and also with the following - but it still does not work:
CONFIG_STDOUT_CONSOLE=y
CONFIG_PRINTK=y

I am using the latest firmware 226 and programming the board using the "copy" method. Programming seems to work fine judging from the way it usually reacts.

How are you programming the board?

Hi Anas,
Yes, that is correct. I was installing it on OSX. Cannot really give more details about what happened except that I pressed ctrl-C during the installation. It was the only shell I had open at that moment, so I am pretty sure it was caused by the SDK.
Best regards, Mads

I have installed gcc,g++,and sdk , the environment shows that :
ZEPHYR_SDK_INSTALL_DIR=/opt/zephyr-sdkOLDPWD=/shrd/microkernelZEPHYR_BASE=/shrd/zephyrPATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/shrd/zephyr/scriptsPWD=/shrd/microkernelSHLVL=2HOME=/rootZEPHYR_GCC_VARIANT=zephyrLESSOPEN=| /usr/bin/lesspipe %sLESSCLOSE=/usr/bin/lesspipe %s %s_=/usr/bin/envLOGNAME=rootARCH=x86

When I build a application (do as https://www.zephyrproject.org/doc/application/application.html ), it failed and shows these :
make[1]: Entering directory `/shrd/zephyr'make[2]: /opt/zephyr-sdk/sysroots/i686-pokysdk-linux/usr/bin/i586-poky-elf/i586-poky-elf-gcc: Command not foundmake[2]: Entering directory `/shrd/microkernel/outdir'make[2]: /opt/zephyr-sdk/sysroots/i686-pokysdk-linux/usr/bin/i586-poky-elf/i586-poky-elf-gcc: Command not found Using /shrd/zephyr as source for kernel /shrd/zephyr is not clean, please run 'make mrproper' in the '/shrd/zephyr' directory.make[2]: *** [prepare3] Error 1make[2]: Leaving directory `/shrd/microkernel/outdir'make[1]: *** [sub-make] Error 2make[1]: Leaving directory `/shrd/zephyr'make: *** [all] Error 2
How to solve this error ?

Mads,

Were you trying to install the SDK on Mac OS?
If yes, this issue will be addressed in the latest SDK drop which will be released today.


Anas

Hi,
The issue has been reported and being addressed. Still not known what the issue is exactly :(

Anas

Hi Mads,

On Mon, Mar 14, 2016 at 10:15 PM, Mads Kristiansen
<mkristian(a)outlook.com> wrote:

I downloaded the Zephyr SDK v0.7.2 last night and tried to install it this
morning on my MacBook.

During the installation, I cancelled with ctrl-C and somehow it seems to
have executed a "rm -rf /" (as root).

I was curious on how this could happen. So I unpacked the installer
script (using "--noexec --target somedir --keep options") and looked
at setup.sh. This seems the most relevant snippet:

...
if [ -d $target_sdk_dir ]; then
# If the directory exists, test for write permission
if [ ! -w $target_sdk_dir ] ; then
echo "No permission, please run as 'sudo'"
exit 1
else
# wipe the directory first
read_confirm
if [ "$confirm" = "y" -o "$confirm" = "Y" ]; then
rm -rf $target_sdk_dir/*
else
# Abort the installation
echo "SDK installation aborted!"
exit 1
fi
fi
else
...

The "read_confirm" function should have warned you that the directory
you provided (which I assume was some important directory such as /usr
or even /) was about to be removed:

...
# Read the input "y"
read_confirm () {
echo "The existing directory $target_sdk_dir will be removed! "
if [ "$confirm" != "y" ]; then
echo "Do you want to continue (y/n)? "
while read confirm; do
[ "$confirm" = "Y" -o "$confirm" = "y" -o "$confirm" = "n" \
-o "$confirm" = "N" ] && break
echo "Invalid input \"$confirm\", please input 'y' or 'n': "
done
else
echo
fi
}
...

My opinion is that given the installation script requires wiping the
existing target directory, it would be wise to either blacklist
important directories (/ /usr etc.) or simply exit with failure if the
target directory exists (safest option in my opinion, due to the point
below).

There is the possibility that the read bash function captures buffered
input data prior to the prompt (e.g. if the user unknowingly typed "y"
while the script was unpacking), which is very dangerous in this case.

Obviously my system wont boot now, so I cannot examine this further until I
have it up and running again. Just a heads up and maybe someone should have
a glance at the SDK to make sure noone else gets into the same situation.

Best Regards,
--
Anderson Lizardo

Hi everyone,

is it just me or everyone does not receive some emails to their inbox
from the devel mailing list?

For example I did not receive any email for the threads:
[RFC] GPIO API changes
FRDM-K64 GPIO driver name
Zephyr SDK v0.7.2 - "rm -rf /"

If someone posts something to the devel mailing list using the web
GUI, do you receive an email?

Best regards,
Yannis

Hi Vinicius,

Another issue of the current API is the confusion caused by
'gpio_port_enable_callback()' and 'gpio_pin_enable_callback()'.

With the changes proposed later in this thread, you could have a
unified call:
'gpio_enable_callback(struct device *port, uint32_t pinmask)' (or something like it)

gpio_port_callback() make the callback called, whatever pins is
triggering the interrupt and enabled or not (callback wise).
So they are different (documentation could be better though)

I am just wondering that in the "old" API '_port_enable_callback()' was
a way to have the callback called with the pins expressed in a bitmask,
now the same behaviour can be achieved by running
'_pin_enable_callback(port, 0xffffffff)'. Just saying that, with the new
API, '_port_enable_callback()' adds little value.

Rethinking about that, while doing the proper patch-set. You've got good
point.
I am making it useless if the user has not set a callback through
gpio_set_callback()
(old way of doing, for a unique callback on the whole port)

Thanks,

Tomasz

Hi, Reffering to my post in users, I wasn't successfully activating the
LEDs, but I got the debug output. See below

--- prj.conf ---
CONFIG_STDOUT_CONSOLE=y
CONFIG_PRINTK=y
CONFIG_NANO_TIMERS=y
CONFIG_NANO_TIMEOUTS=y
CONFIG_GPIO=y

I've following settings:
CONFIG_ARM=y
CONFIG_SOC_FSL_FRDM_K64F=y
CONFIG_BOARD_FRDM_K64F=y
CONFIG_CONSOLE=y
CONFIG_UART_CONSOLE=y
CONFIG_SERIAL=y
CONFIG_CORTEX_M_SYSTICK=y
CONFIG_UART_K20=y

Now the printk/f should be to uart.


Nevertheless, I tried NXP's MQX. There I found, that activating
the LED was done by setting the output of the Pin to one and then to zero.
Maybe thats the way it is done since the cathode is, reffering to the manual,
on the processor side.

Hi Thomasz,

Yesterday I tried with the following source code - but nothing happens :(
Nothing blinks. I programming it by copying the outdir/zephyr.bin onto the MBED folder. The board seems to "eat" it as it should but nothing happens - even after a reset.

GPIO out pin is Port B pin 22. Input is port B pin 9.
What puzzels me the most is that I do not get ANY debug output on the console (screen /dev/ttyACM0 in Linux). I'd really like it to just show a sign of life...

--- prj.conf ---
CONFIG_STDOUT_CONSOLE=y
CONFIG_PRINTK=y
CONFIG_NANO_TIMERS=y
CONFIG_NANO_TIMEOUTS=y
CONFIG_GPIO=y

---------------
--- main.c ---
#include <zephyr.h>
#include <device.h>
#include <gpio.h>
#include <sys_clock.h>


#if defined(CONFIG_STDOUT_CONSOLE)
#include <stdio.h>
#define PRINT printf
#else
#include <misc/printk.h>
#define PRINT printk
#endif

#define SLEEPTICKS SECONDS(1)

#define GPIO_OUT_PIN 22
#define GPIO_INT_PIN 9
#define GPIO_NAME "GPIO_"
#define GPIO_DRV_NAME CONFIG_GPIO_K64_B_DEV_NAME

void gpio_callback(struct device *port, uint32_t pin)
{
PRINT(GPIO_NAME "%d triggered\n", pin);
}


void main(void)
{
PRINT("Hello World!\n");
printf("Hello World!\n");

struct nano_timer timer;
void *timer_data[1];
struct device *gpio_dev;
int ret;
int toggle = 0;

nano_timer_init(&timer, timer_data);

gpio_dev = device_get_binding(GPIO_DRV_NAME);
if (!gpio_dev) {
PRINT("Cannot find %s!\n", GPIO_DRV_NAME);
}

/* Setup GPIO output */
ret = gpio_pin_configure(gpio_dev, GPIO_OUT_PIN, (GPIO_DIR_OUT));
if (ret) {
PRINT("Error configuring " GPIO_NAME "%d!\n", GPIO_OUT_PIN);
}

/* Setup GPIO input, and triggers on rising edge. */
ret = gpio_pin_configure(gpio_dev, GPIO_INT_PIN,
(GPIO_DIR_IN | GPIO_INT | GPIO_INT_EDGE
| GPIO_INT_ACTIVE_HIGH | GPIO_INT_DEBOUNCE));
if (ret) {
PRINT("Error configuring " GPIO_NAME "%d!\n", GPIO_INT_PIN);
}

ret = gpio_set_callback(gpio_dev, gpio_callback);
if (ret) {
PRINT("Cannot setup callback!\n");
}

ret = gpio_pin_enable_callback(gpio_dev, GPIO_INT_PIN);
if (ret) {
PRINT("Error enabling callback!\n");
}

while (1) {
PRINT("Toggling " GPIO_NAME "%d\n", GPIO_OUT_PIN);

ret = gpio_pin_write(gpio_dev, GPIO_OUT_PIN, toggle);
if (ret) {
PRINT("Error set " GPIO_NAME "%d!\n", GPIO_OUT_PIN);
}

if (toggle) {
toggle = 0;
} else {
toggle = 1;
}

nano_timer_start(&timer, SLEEPTICKS);
nano_timer_test(&timer, TICKS_UNLIMITED);
}


}

On Tue, Mar 15, 2016 at 3:50 AM, Nashif, Anas <anas.nashif(a)intel.com> wrote:

On 14/03/2016, 22:46, "Kalowsky, Daniel" <daniel.kalowsky(a)intel.com> wrote:

-----Original Message-----
From: Maciek Borzecki [mailto:maciek.borzecki(a)gmail.com]
Sent: Monday, March 14, 2016 5:19 AM
To: Nashif, Anas <anas.nashif(a)intel.com>; Kalowsky, Daniel
<daniel.kalowsky(a)intel.com>; Walsh, Benjamin (Wind River)
<benjamin.walsh(a)windriver.com>
Cc: Boie, Andrew P <andrew.p.boie(a)intel.com>;
users(a)lists.zephyrproject.org; devel(a)lists.zephyrproject.org
Subject: Re: [devel] [users] Re: Re: Re: Re: Re: STM32F103x port

<..snip..>

Do we have a consensus on this matter then? Did you get a chance to
discuss this internally?

Sorry I was out of the office today, and most likely delayed Anas's hope of delivering a solution by EOD. That said, he reviewed the patch online, and for some reason Gerrit won't take my response.

Anas correctly highlights that your initial patch should not advertise the support for the STM32F{ 2 | 3 | 4} MCUs, those should be added when that support comes in. I completely overlooked this, sorry about that.

I am working right now on defining a new layer in Kconfig and reorganising Kconfig for this purpose and will take the STM32 changes and propose better structure for all architectures and existing SoCs.

Cool, I'll wait for your changes then.

I have a couple of updates lined up already, namely support for
interrupts on UART and GPIO input (might suquash that with the GPIO
patch anyway). There's also some initial support for EXTI and GPIO
interrupts, though this might require a number of iterations as the
STM32's way of handling this does not map that well to the GPIO driver
API.

Cheers,
--
Maciek Borzecki

On 14/03/2016, 22:46, "Kalowsky, Daniel" <daniel.kalowsky(a)intel.com> wrote:

-----Original Message-----
From: Maciek Borzecki [mailto:maciek.borzecki(a)gmail.com]
Sent: Monday, March 14, 2016 5:19 AM
To: Nashif, Anas <anas.nashif(a)intel.com>; Kalowsky, Daniel
<daniel.kalowsky(a)intel.com>; Walsh, Benjamin (Wind River)
<benjamin.walsh(a)windriver.com>
Cc: Boie, Andrew P <andrew.p.boie(a)intel.com>;
users(a)lists.zephyrproject.org; devel(a)lists.zephyrproject.org
Subject: Re: [devel] [users] Re: Re: Re: Re: Re: STM32F103x port

<..snip..>

Do we have a consensus on this matter then? Did you get a chance to
discuss this internally?

Sorry I was out of the office today, and most likely delayed Anas's hope of delivering a solution by EOD. That said, he reviewed the patch online, and for some reason Gerrit won't take my response.

Anas correctly highlights that your initial patch should not advertise the support for the STM32F{ 2 | 3 | 4} MCUs, those should be added when that support comes in. I completely overlooked this, sorry about that.

I am working right now on defining a new layer in Kconfig and reorganising Kconfig for this purpose and will take the STM32 changes and propose better structure for all architectures and existing SoCs.

Anas

I downloaded the Zephyr SDK v0.7.2 last night and tried to install it this morning on my MacBook.
During the installation, I cancelled with ctrl-C and somehow it seems to have executed a "rm -rf /" (as root).
Obviously my system wont boot now, so I cannot examine this further until I have it up and running again. Just a heads up and maybe someone should have a glance at the SDK to make sure noone else gets into the same situation.
/ Mads

On 14 Mar 2016, at 08:18, Maciek Borzecki <maciek.borzecki(a)gmail.com> wrote:

On Fri, Mar 11, 2016 at 3:34 PM, Nashif, Anas <anas.nashif(a)intel.com> wrote:

On 10 Mar 2016, at 13:28, Kalowsky, Daniel <daniel.kalowsky(a)intel.com> wrote:

-----Original Message-----
From: Nashif, Anas
Sent: Wednesday, March 9, 2016 5:49 PM
To: Boie, Andrew P <andrew.p.boie(a)intel.com>; Kalowsky, Daniel
<daniel.kalowsky(a)intel.com>
Cc: users(a)lists.zephyrproject.org; maciek.borzecki(a)gmail.com;
devel(a)lists.zephyrproject.org; Walsh, Benjamin (Wind River)
<benjamin.walsh(a)windriver.com>
Subject: Re: [devel] Re: [users] Re: Re: Re: Re: Re: STM32F103x port

On 09/03/2016, 19:51, "Boie, Andrew P" <andrew.p.boie(a)intel.com> wrote:

On Wed, 2016-03-09 at 21:35 +0000, Kalowsky, Daniel wrote:

-----Original Message-----

Summing up, what you're basically suggesting is having a structure
like this (assumig that we keep vendor prefix for the time being):

arch/
arm/
soc/
st_stm32f1/
Kconfig.soc
Kconfig
...
soc.c
st_stm32f2/
...
st_stm32l0/

If we're on the same page then i"ll post some patches tomorrow.

Seems

like an easy fix.

Yes, the only different from what you have right now is having 1 level

less. I

think everything else should stay the same.

I not convinced that is any good. You're essentially going to create a larger

mess of MCUs in the arch/arm/soc directory.

The goal of keeping everything in a common directory (st_stm32) is to

enforce maximum sharing between MCUs where possible. For example, the
stm32f1_init is really the same for the STM32F{1 | 2 | 3 | 4 }x MCUs. Moving
this into an upper level "common" area, not only makes it difficult to find, it
just creates confusion as we add in future platforms.

Do we need another layer of abstraction in the build for SoC variants?

Where did you see a new layer in what I said? The current patch and adding
st_stm32 is adding a new layer. st_stm32 is not an SoC, its an architecture
(just like there is STM8) that has different variants (M0+, M3, M4, …) that
have additional SoCs. st_stm32 is something comparable to Quark from x86.
So with this patch and looking at the Kconfig variables we have

arch / doc family or architecture / soc variant / soc / board

You're confusing me now. Please state your objection to the proposed method clearly here.

I am not in favour of adding the stm32 layer. I am all for adding the "SoC series" or "family layer”.

What this means:

instead of


arch/
arm/
soc/
stm32/
st_stm32f1/
st_stm32f2/


we will just have:

arch/
arm/
soc/
st_stm32f1/ (this would include multiple SoCs from the same series and the same architecture)
st_stm32f2/


The above model is already used for the atmel_sam3, where SAM3 is the series or family and ATMEL_SAM3X8E is the actual SoC. Actually, looking at

http://www.atmel.com/products/microcontrollers/arm/sam3x.aspx we should rename sam3 to sam3x to be more consistent.

If we decide to add one more level, i.e. ATMEL SAM or ST STM32, then we need to revisit and redesign the hierarchy and mark those being families or series in Kconfig and stop the mis-use of CONFIG_SOC_XX for three different levels in the hierarchy.

I
share Dan's concerns, I think it may be better to have st_stm32/ SoC and
then subdirectories with variants thereof, with common code at the
toplevel.

This would mean we have inheritance as follows: arch / soc /
soc_variant / board. This would be something fully supported by the
build system, like it knows about arches / boards / socs now.

Not keen on collapsing all this to just soc/.

This the design as we have now (and it was proposed and discussed). Under
soc/ we have frdm-k64f, atmel_sam3 which are SoCs and not sub-
architectures. If you think we need another layer, then we need to change
this across the board and not only for STM32.

Correct. That would be step #2.

No, We make first make it fit in the current structure then take our time and do it right after some discussion and after getting to an agreement.

Do we have a consensus on this matter then? Did you get a chance to
discuss this internally?

We are looking into this and will send a proposal to address this by EOD.

Anas

Cheers,

On Fri, Mar 11, 2016 at 3:34 PM, Nashif, Anas <anas.nashif(a)intel.com> wrote:

On 10 Mar 2016, at 13:28, Kalowsky, Daniel <daniel.kalowsky(a)intel.com> wrote:

-----Original Message-----
From: Nashif, Anas
Sent: Wednesday, March 9, 2016 5:49 PM
To: Boie, Andrew P <andrew.p.boie(a)intel.com>; Kalowsky, Daniel
<daniel.kalowsky(a)intel.com>
Cc: users(a)lists.zephyrproject.org; maciek.borzecki(a)gmail.com;
devel(a)lists.zephyrproject.org; Walsh, Benjamin (Wind River)
<benjamin.walsh(a)windriver.com>
Subject: Re: [devel] Re: [users] Re: Re: Re: Re: Re: STM32F103x port

On 09/03/2016, 19:51, "Boie, Andrew P" <andrew.p.boie(a)intel.com> wrote:

On Wed, 2016-03-09 at 21:35 +0000, Kalowsky, Daniel wrote:

-----Original Message-----

Summing up, what you're basically suggesting is having a structure
like this (assumig that we keep vendor prefix for the time being):

arch/
arm/
soc/
st_stm32f1/
Kconfig.soc
Kconfig
...
soc.c
st_stm32f2/
...
st_stm32l0/

If we're on the same page then i"ll post some patches tomorrow.

Seems

like an easy fix.

Yes, the only different from what you have right now is having 1 level

less. I

think everything else should stay the same.

I not convinced that is any good. You're essentially going to create a larger

mess of MCUs in the arch/arm/soc directory.

The goal of keeping everything in a common directory (st_stm32) is to

enforce maximum sharing between MCUs where possible. For example, the
stm32f1_init is really the same for the STM32F{1 | 2 | 3 | 4 }x MCUs. Moving
this into an upper level "common" area, not only makes it difficult to find, it
just creates confusion as we add in future platforms.

Do we need another layer of abstraction in the build for SoC variants?

Where did you see a new layer in what I said? The current patch and adding
st_stm32 is adding a new layer. st_stm32 is not an SoC, its an architecture
(just like there is STM8) that has different variants (M0+, M3, M4, …) that
have additional SoCs. st_stm32 is something comparable to Quark from x86.
So with this patch and looking at the Kconfig variables we have

arch / doc family or architecture / soc variant / soc / board

You're confusing me now. Please state your objection to the proposed method clearly here.

I am not in favour of adding the stm32 layer. I am all for adding the "SoC series" or "family layer”.

What this means:

instead of


arch/
arm/
soc/
stm32/
st_stm32f1/
st_stm32f2/


we will just have:

arch/
arm/
soc/
st_stm32f1/ (this would include multiple SoCs from the same series and the same architecture)
st_stm32f2/


The above model is already used for the atmel_sam3, where SAM3 is the series or family and ATMEL_SAM3X8E is the actual SoC. Actually, looking at

http://www.atmel.com/products/microcontrollers/arm/sam3x.aspx we should rename sam3 to sam3x to be more consistent.

If we decide to add one more level, i.e. ATMEL SAM or ST STM32, then we need to revisit and redesign the hierarchy and mark those being families or series in Kconfig and stop the mis-use of CONFIG_SOC_XX for three different levels in the hierarchy.

I
share Dan's concerns, I think it may be better to have st_stm32/ SoC and
then subdirectories with variants thereof, with common code at the
toplevel.

This would mean we have inheritance as follows: arch / soc /
soc_variant / board. This would be something fully supported by the
build system, like it knows about arches / boards / socs now.

Not keen on collapsing all this to just soc/.

This the design as we have now (and it was proposed and discussed). Under
soc/ we have frdm-k64f, atmel_sam3 which are SoCs and not sub-
architectures. If you think we need another layer, then we need to change
this across the board and not only for STM32.

Correct. That would be step #2.

No, We make first make it fit in the current structure then take our time and do it right after some discussion and after getting to an agreement.

Do we have a consensus on this matter then? Did you get a chance to
discuss this internally?

Cheers,
--
Maciek Borzecki

Thanks Tomasz,
It compiles :)

I will try lator today with a real GPIO test.

Thanks again.
/Anders