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, <mkristian(a)outlook.com> wrote: 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

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

Hi Vinicius, 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,

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

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"

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

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

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 /"

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

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

Hi Anders, According to arch/arm/soc/fsl_frdm_k64f/Kconfig GPIO and GPIO_K64 are set by default. Verify you get these in your output/.config The name you should use is GPIO_K64_<X>_DEV_NAME (where

Hi, I am trying to use GPIO on my Freescale FRDM-K64 board. However, I cannot seem to find the driver name. It from this page that the driver name should be something like

Hi, I have a Freescale FRDM-K64 board. I cannot get the samples/hello_world/microkernel to work. Compiling with this: # make O=out-arm BOARD=frdm_k64f It compiles fine and the out-arm/zephyr.bin can

That was my first thought but I don't think we have the liberty of changing our 1.0 APIs. Andrew

Sounds good. We can use the SYS_INIT_NAMED() macro for devices that need a name for PM purpose. Do you think we should replace SYS_INIT() with the new one? i.e. just modify SYS_INIT(). I am ok

Hi all, Quoting Andre Guedes (2016-03-03 16:43:24) Do we have a consensus about this? After the "errno-drivers" patchset, DEV_* codes will be used only at 'board' and 'arch' layers. Actually, all