Date   

Errors while using west flash

Pandey, Mithun
 

HI,

 

I am following the setup steps in given in https://docs.zephyrproject.org/latest/getting_started/index.html

Using a Python (3.6) Virtual environment.

I was able to build the Blinky example, trying to flash it in Nucleo F429zi board. West build Log file attached.

Tool chain used is “GNU_Arm_Embedded_Toolchain”

 

I have two Nucleo boards (One 429 and one F767), output of “pyocd list” command shows that

  #   Probe          Unique ID

-----------------------------------------------

  0   STM32 STLink   066CFF363336485043072710

  1   STM32 STLink   0674FF535155878281133844

 

Problem:

When doing the flashing using “west flash” command I am getting python related error, log file attached.

 

Kindly help in resolving this, is it happening because two probes are attached ?, I tried to find a way to specify the board number in the west command but didn’t find any.

 

Kindly help.

 

Thanks and Regards

Mithun

 

 

 

 

 


options for missing driver functions

Jeff Haynes <feedyurhed@...>
 


Relatively new Zephyr user here.  We have a custom board with a LIS2DS12 IMU on it.  I've been somewhat ignoring it up to now as it serves a secondary function and we sort of just threw it on there thinking we would get to it later.  Now that I'm ready to tackle it it looks like the built-in functionality in the driver is pretty limited and doesn't cover the wake-up scenarios we need.  What are our options at this point?  Should we add to the existing driver?  Attempt to do everything in the app or "side-load" a driver?  Attempt to include the ST HAL?

Thanks,

Jeff



--
If you want to build a ship, don't drum up people together to collect wood and don't assign them tasks and work, but rather teach them to long for the endless immensity of the sea.

Antoine de Saint-Exupery


Zephyr on Hexiwear and integrated Display Support

Marvin Beckmann <marvin@...>
 

Hi guys,

I am using Zephyr on the Hexiwear Board. I accomplished to use the hearrate sensor and some other sensors on the board.

But I am still having trouble with the integrated Display (SSD1351 OLED Display with SPI)

I didn't find drivers for this display. So i decided to use the SSD1306 Drivers.

It seems to work, because the functions for the display return zero, but display is not showing anything.

Is there any chance to support SPI on the Hexiwear Board and using the integrated display.

Here is the link for my code: https://gitlab.com/MarvB19/hexiwear_display <https://gitlab.com/MarvB19/hexiwear_display>

I hope you can help me :)

Have a nice day.


Kind regards

Marvin Beckmann


Re: Not understanding how to enable peripherals in devicetree

Jason Bens
 

Thanks Armand,

 

I think I‘ve got that working, now, and referenced properly in the CMakeList.  A devicetree binding somewhere requires a couple pin definitions, but I can handle that.

 

I did come across a bit more documentation at \zephyr\boards\arm\nrf5340dk_nrf5340\doc\index.rst , which lists the supported features for this SoC.  I2S is not on that list.  I’m not sure if that documentation is coming from the Zephyr community or Nordic, but should I interpret that to mean that any I2S driver functionality is accidental at best?

 

  • Jason

 

From: users@... <users@...> On Behalf Of Armand C.
Sent: June 29, 2021 2:22 PM
To: users@...
Subject: Re: [Zephyr-users] Not understanding how to enable peripherals in devicetree

 

External Email:

Hi Jason,

You have to enable the peripheral in the board devicetree overlay (see below).

&i2s0 {
    status = "okay";
};

Armand


Re: Not understanding how to enable peripherals in devicetree

Armand C. <rnx.lab@...>
 

Hi Jason,

You have to enable the peripheral in the board devicetree overlay (see below).

&i2s0 {
    status = "okay";
};

Armand


Not understanding how to enable peripherals in devicetree

Jason Bens
 

Hi,

 

I’m a complete newcomer to zephyr and devicetree, and I’m running into some trouble trying to enable the I2S peripheral on the nRF5340dk board.  I’ve enabled both the I2S driver (Modules->hal_nordic->nrfx_drivers) and the I2S bus drivers (Device Drivers) in menuconfig.  I’ve also added “CONFIG_I2S=y” to my top-level prj.conf.  Despite this, when I check zephyr.dts in my build directory, the i2s0 device is disabled.

 

Zephyr.dts excerpt:

i2s0: i2s@28000 {

compatible = "nordic,nrf-i2s";

     #address-cells = < 0x1 >;

     #size-cells = < 0x0 >;

     reg = < 0x28000 0x1000 >;

     interrupts = < 0x28 0x1 >;

     status = "disabled";

     label = "I2S_0";

};

 

I’ve checked the i2s litex sample and read through the docs, but I’m not finding a solution.  Am I missing a step somewhere to enable this device? Do I need a devicetree overlay to explicitly enable i2s?  If it’s relevant, I’ve been using the Nordic edition of SEGGER Embedded studio to build the project, as per Nordic’s nRF Connect toolchain documentation.

 

Thanks,

 

  • Jason


nRF9160 custom board Re-running CMake #nrf9160

DKaplan@...
 
Edited

We have created a custom nRF9160 board which arrived in Las Vegas which I debug by Teams. The hardware engineer has the same version of Nordic nRF Connect SDK v1.51 (SES) as on my computer.
We both use Windows 10.

I update the following files
 1) c:\ncs\v1.5.1\zephyr\drivers\sensor\lsm6dsl\lsm6dsl.c
       Changes made in the sensor driver for retrieving the raw accelerometer X,Y,z int16 readings and for writing and reading raw chip byte setup registers.
 2) c:\ncs\v1.5.1\zephyr\include\drivers\sensor\lsm6dsl_drv.h
       Added a new raw channel and new raw register attributes defines
 3) c:\ncs\v1.5.1\zephyr\boards\arm\nrf9160axion_nrf9160
      Copied nrf9160dk_nrf9160 folder with a few adjustments for our custom board.
 4) D:\Projects\ami_axion
      Our project

For two days I sent updated files and the hardware engineer reran the nRF Connect SDK script from the SES File menu to rerun the scripts which act on the new files and then he performs a clean and a rebuild.
This morning, the rebuilt took such a long time and then returned with an error.
On my computer everything works. I resent the files and verified that he updated them in the correct places.
After several hours trying, I looked at the build window and saw that there was an endless loop of "Re-running CMake...".
In the log, it also showed one warning:
  warning: 'has-be32k' is marked as deprecated in 'properties:' in C:/Users/Omer_Z/ncs/v1.5.1/zephyr/dts/bindings\mtd\jedec,spi-nor.yaml for node /soc/peripheral@50000000/spi@b000/mx25r6435f@0.
This does not occur on my setup and when building the project for the original nrf9160dk_nrf9160(ns) board in Las Vegas, all compiled well.
Both the nrf9160dk_nrf9160ns.overlay and the nrf9160axion_nrf9160ns.overlay files have the has-be32k setting for the external memory.
I removed the has-be32k setting from the custom board's overlay but we just got to another problem.

I send the project folder compressed without the build_nrf9160axion_nrf9160ns or build_nrf9160dk_nrf9160ns directories since they are created with the nRF Connect SDK script from the SES File menu.

How I can I understand the exact reason for my problems?

Is there a different way to do things?

Thanks David


  • Rebuilding ‘modules/nrf/samples/spm_subimage-prefix/src/spm_subimage-stamp/spm_subimage-mkdir’ from solution ‘build’ in configuration ‘Common’
  • 1> Combining ‘modules/nrf/samples/spm_subimage-prefix/src/spm_subimage-stamp/spm_subimage-mkdir’
  • Rebuilding ‘modules/nrf/samples/spm_subimage-prefix/src/spm_subimage-stamp/spm_subimage-download’ from solution ‘build’ in configuration ‘Common’
  • 1> Combining ‘modules/nrf/samples/spm_subimage-prefix/src/spm_subimage-stamp/spm_subimage-download’
  • Rebuilding ‘modules/nrf/samples/spm_subimage-prefix/src/spm_subimage-stamp/spm_subimage-update’ from solution ‘build’ in configuration ‘Common’
  • 1> Combining ‘modules/nrf/samples/spm_subimage-prefix/src/spm_subimage-stamp/spm_subimage-update’
  • Rebuilding ‘modules/nrf/samples/spm_subimage-prefix/src/spm_subimage-stamp/spm_subimage-patch’ from solution ‘build’ in configuration ‘Common’
  • 1> Combining ‘modules/nrf/samples/spm_subimage-prefix/src/spm_subimage-stamp/spm_subimage-patch’
  • Rebuilding ‘modules/nrf/samples/spm_subimage-prefix/src/spm_subimage-stamp/spm_subimage-configure’ from solution ‘build’ in configuration ‘Common’
  • 1> Combining ‘modules/nrf/samples/spm_subimage-prefix/src/spm_subimage-stamp/spm_subimage-configure’
  • Rebuilding ‘modules/nrf/samples/spm_subimage-prefix/src/spm_subimage-stamp/spm_subimage-build’ from solution ‘build’ in configuration ‘Common’
  • 1> Combining ‘modules/nrf/samples/spm_subimage-prefix/src/spm_subimage-stamp/spm_subimage-build’
  • 1> [0/1] Re-running CMake...
  • 1> Including boilerplate (Zephyr base (cached)): C:/Users/Omer_Z/ncs/v1.5.1/zephyr/cmake/app/boilerplate.cmake
  • 1> -- Application: C:/Users/Omer_Z/ncs/v1.5.1/nrf/samples/spm
  • 1> -- Using NCS Toolchain 1.5.1 for building. (C:/Users/Omer_Z/ncs/v1.5.1/toolchain/cmake)
  • 1> -- Zephyr version: 2.4.99 (C:/Users/Omer_Z/ncs/v1.5.1/zephyr)
  • 1> -- Found west (found suitable version "0.9.0", minimum required is "0.7.1")
  • 1> -- Board: nrf9160axion_nrf9160, Revision: 0.7.0
  • 1> -- Cache files will be written to: C:/Users/Omer_Z/ncs/v1.5.1/zephyr/.cache
  • 1> -- Found dtc: C:/Users/Omer_Z/ncs/v1.5.1/toolchain/opt/bin/dtc.exe (found suitable version "1.4.7", minimum required is "1.4.6")
  • 1> -- Found toolchain: gnuarmemb (C:/Users/Omer_Z/ncs/v1.5.1/toolchain/opt)
  • 1> -- Found BOARD.dts: C:/Users/Omer_Z/ncs/v1.5.1/zephyr/boards/arm/nrf9160axion_nrf9160/nrf9160axion_nrf9160.dts
  • 1> -- Found devicetree overlay: D:/Projects/ami_axion/nrf9160axion_nrf9160ns.overlay
  • 1> warning: 'has-be32k' is marked as deprecated in 'properties:' in C:/Users/Omer_Z/ncs/v1.5.1/zephyr/dts/bindings\mtd\jedec,spi-nor.yaml for node /soc/peripheral@50000000/spi@b000/mx25r6435f@0.
  • 1> -- Generated zephyr.dts: D:/Projects/ami_axion/build_nrf9160axion_nrf9160ns/spm/zephyr/zephyr.dts
  • 1> -- Generated devicetree_unfixed.h: D:/Projects/ami_axion/build_nrf9160axion_nrf9160ns/spm/zephyr/include/generated/devicetree_unfixed.h
  • 1> -- Generated device_extern.h: D:/Projects/ami_axion/build_nrf9160axion_nrf9160ns/spm/zephyr/include/generated/device_extern.h
  • 1> Parsing C:/Users/Omer_Z/ncs/v1.5.1/zephyr/Kconfig
  • 1> Loaded configuration 'D:/Projects/ami_axion/build_nrf9160axion_nrf9160ns/spm/zephyr/.config'
  • 1> No change to configuration in 'D:/Projects/ami_axion/build_nrf9160axion_nrf9160ns/spm/zephyr/.config'
  • 1> No change to Kconfig header in 'D:/Projects/ami_axion/build_nrf9160axion_nrf9160ns/spm/zephyr/include/generated/autoconf.h'
  • 1> -- Configuring done
  • 1> -- Generating done
  • 1> -- Build files have been written to: D:/Projects/ami_axion/build_nrf9160axion_nrf9160ns/spm
  • 1> [0/1] Re-running CMake...
  • 1> Including boilerplate (Zephyr base (cached)): C:/Users/Omer_Z/ncs/v1.5.1/zephyr/cmake/app/boilerplate.cmake
  • 1> -- Application: C:/Users/Omer_Z/ncs/v1.5.1/nrf/samples/spm
  • 1> -- Using NCS Toolchain 1.5.1 for building. (C:/Users/Omer_Z/ncs/v1.5.1/toolchain/cmake)
  • 1> -- Zephyr version: 2.4.99 (C:/Users/Omer_Z/ncs/v1.5.1/zephyr)
  • 1> -- Found west (found suitable version "0.9.0", minimum required is "0.7.1")
  • 1> -- Board: nrf9160axion_nrf9160, Revision: 0.7.0
  • 1> -- Cache files will be written to: C:/Users/Omer_Z/ncs/v1.5.1/zephyr/.cache
  • 1> -- Found dtc: C:/Users/Omer_Z/ncs/v1.5.1/toolchain/opt/bin/dtc.exe (found suitable version "1.4.7", minimum required is "1.4.6")
  • 1> -- Found toolchain: gnuarmemb (C:/Users/Omer_Z/ncs/v1.5.1/toolchain/opt)
  • 1> -- Found BOARD.dts: C:/Users/Omer_Z/ncs/v1.5.1/zephyr/boards/arm/nrf9160axion_nrf9160/nrf9160axion_nrf9160.dts
  • 1> -- Found devicetree overlay: D:/Projects/ami_axion/nrf9160axion_nrf9160ns.overlay
  • 1> warning: 'has-be32k' is marked as deprecated in 'properties:' in C:/Users/Omer_Z/ncs/v1.5.1/zephyr/dts/bindings\mtd\jedec,spi-nor.yaml for node /soc/peripheral@50000000/spi@b000/mx25r6435f@0.
  • 1> -- Generated zephyr.dts: D:/Projects/ami_axion/build_nrf9160axion_nrf9160ns/spm/zephyr/zephyr.dts
  • 1> -- Generated devicetree_unfixed.h: D:/Projects/ami_axion/build_nrf9160axion_nrf9160ns/spm/zephyr/include/generated/devicetree_unfixed.h
  • 1> -- Generated device_extern.h: D:/Projects/ami_axion/build_nrf9160axion_nrf9160ns/spm/zephyr/include/generated/device_extern.h
  • 1> Parsing C:/Users/Omer_Z/ncs/v1.5.1/zephyr/Kconfig
  • 1> Loaded configuration 'D:/Projects/ami_axion/build_nrf9160axion_nrf9160ns/spm/zephyr/.config'
  • 1> No change to configuration in 'D:/Projects/ami_axion/build_nrf9160axion_nrf9160ns/spm/zephyr/.config'
  • 1> No change to Kconfig header in 'D:/Projects/ami_axion/build_nrf9160axion_nrf9160ns/spm/zephyr/include/generated/autoconf.h'
  • 1> -- Configuring done
  • 1> -- Generating done
  • 1> -- Build files have been written to: D:/Projects/ami_axion/build_nrf9160axion_nrf9160ns/spm
  • 1> [0/1] Re-running CMake...
  • 1> Including boilerplate (Zephyr base (cached)): C:/Users/Omer_Z/ncs/v1.5.1/zephyr/cmake/app/boilerplate.cmake
  • 1> -- Application: C:/Users/Omer_Z/ncs/v1.5.1/nrf/samples/spm
  • 1> -- Using NCS Toolchain 1.5.1 for building. (C:/Users/Omer_Z/ncs/v1.5.1/toolchain/cmake)
  • 1> -- Zephyr version: 2.4.99 (C:/Users/Omer_Z/ncs/v1.5.1/zephyr)
  • 1> -- Found west (found suitable version "0.9.0", minimum required is "0.7.1")
  • 1> -- Board: nrf9160axion_nrf9160, Revision: 0.7.0
  • 1> -- Cache files will be written to: C:/Users/Omer_Z/ncs/v1.5.1/zephyr/.cache
  • 1> -- Found dtc: C:/Users/Omer_Z/ncs/v1.5.1/toolchain/opt/bin/dtc.exe (found suitable version "1.4.7", minimum required is "1.4.6")
  • 1> -- Found toolchain: gnuarmemb (C:/Users/Omer_Z/ncs/v1.5.1/toolchain/opt)
  • 1> -- Found BOARD.dts: C:/Users/Omer_Z/ncs/v1.5.1/zephyr/boards/arm/nrf9160axion_nrf9160/nrf9160axion_nrf9160.dts
  • 1> -- Found devicetree overlay: D:/Projects/ami_axion/nrf9160axion_nrf9160ns.overlay
  • 1> warning: 'has-be32k' is marked as deprecated in 'properties:' in C:/Users/Omer_Z/ncs/v1.5.1/zephyr/dts/bindings\mtd\jedec,spi-nor.yaml for node /soc/peripheral@50000000/spi@b000/mx25r6435f@0.
  • 1> -- Generated zephyr.dts: D:/Projects/ami_axion/build_nrf9160axion_nrf9160ns/spm/zephyr/zephyr.dts
  • 1> -- Generated devicetree_unfixed.h: D:/Projects/ami_axion/build_nrf9160axion_nrf9160ns/spm/zephyr/include/generated/devicetree_unfixed.h
  • 1> -- Generated device_extern.h: D:/Projects/ami_axion/build_nrf9160axion_nrf9160ns/spm/zephyr/include/generated/device_extern.h
  • 1> Parsing C:/Users/Omer_Z/ncs/v1.5.1/zephyr/Kconfig
  • 1> Loaded configuration 'D:/Projects/ami_axion/build_nrf9160axion_nrf9160ns/spm/zephyr/.config'
  • 1> No change to configuration in 'D:/Projects/ami_axion/build_nrf9160axion_nrf9160ns/spm/zephyr/.config'
  • 1> No change to Kconfig header in 'D:/Projects/ami_axion/build_nrf9160axion_nrf9160ns/spm/zephyr/include/generated/autoconf.h'
  • 1> -- Configuring done
  • 1> -- Generating done
  • 1> -- Build files have been written to: D:/Projects/ami_axion/build_nrf9160axion_nrf9160ns/spm
  • 1> [0/1] Re-running CMake...


Re: Questions regarding Zephyr's testing framework

Kumar Gala
 

On Jun 25, 2021, at 4:16 AM, Harald Böhm <harald.boehm@fau.de> wrote:

Hello,

I am trying to get a better understanding of Zephyr's testing framework.
I have read the documentation, but I still have two questions:

1. Is there a meaniningful difference between the terms "board" and
"platform" or are these used interchangeably?
They are used interchangeably. Its unfortunate we haven’t cleaned up platform to be board.


2. Do there exist fixture names that are deduced from the board's
configuration or are only those considered that are defined in
the hardware map / provided via command line?

As an example, if the respective YAML file in /boards defines:

...
supported:
- gpio
...

does this already fulfil some of the fixtures mentioned in the
documentation with the prefix gpio_?
Fixtures are different from what is listed in ’supported’ in the board YAML. The board YAML is meant to convey what features a board supports between hardware on the board & software in zephyr. A fixture is describing some test hardware requirement.

- k


Questions regarding Zephyr's testing framework

Harald Böhm
 

Hello,

I am trying to get a better understanding of Zephyr's testing framework.
I have read the documentation, but I still have two questions:

1. Is there a meaniningful difference between the terms "board" and
"platform" or are these used interchangeably?

2. Do there exist fixture names that are deduced from the board's
configuration or are only those considered that are defined in
the hardware map / provided via command line?

As an example, if the respective YAML file in /boards defines:

...
supported:
- gpio
...

does this already fulfil some of the fixtures mentioned in the
documentation with the prefix gpio_?


Best regards,
Harald


how to turn off echo on USB serial port

Holger Schurig
 

Hi,

I use a CDC_ACM serial port with Zephyr (from git), and using IRQ driven. Here is my ISR:

static void usb_serial_irq(const struct device *usb_dev, void *user_data)
{
    while (uart_irq_update(usb_dev) && uart_irq_is_pending(usb_dev)) {
        if (uart_irq_rx_ready(usb_dev)) {
            usb_rx_buf_len = uart_fifo_read(usb_dev, usb_rx_buf, sizeof(usb_rx_buf));
            // we disable the interrupt here and send an event
            // main.c will receive the event, parses what we received, and turn
            // on the receive interrupts again.
            uart_irq_rx_disable(usb_dev);
            LOG_HEXDUMP_ERR(&usb_rx_buf, usb_rx_buf_len, "USB RX");
            event_send(USB_INCOMING_DATA);
        }

        if (uart_irq_tx_ready(usb_dev)) {
            uint8_t buffer[64];
            int rb_len;
            int send_len;

            rb_len = ring_buf_get(&usb_tx_ring, buffer, sizeof(buffer));
            if (!rb_len) {
                uart_irq_tx_disable(usb_dev);
                continue;
            }

            send_len = uart_fifo_fill(usb_dev, buffer, rb_len);
            if (send_len < rb_len) {
                LOG_ERR("dropped tx %d byte", rb_len - send_len);
            }
        }
    }
}

I can receive nicely with this.

However, when I sent characters this way:

int usb_serial_putc(char c)
{
    if (!usb_dev)
        return 0;
    int count = 0;
    while (ring_buf_space_get(&usb_tx_ring) < 1) {
        if (++count > 500)
            return -1;
        k_sleep(K_MSEC(2));
    }
    ring_buf_put(&usb_tx_ring, &c, 1);
    uart_irq_tx_enable(usb_dev);
    return 0;
}

I will *ALSO* receive them, as the LOG_HEXDUMP_ERR in the ISR showed me.

My applicaton is currently compiled for POSIX native (real hardware isn't ready yet). In Linux, I use "usbip attach -r localhost -b 1-1". And even a "cat </dev/ttyACM0" makes my ISR receive sent data ... despite the fact that cat cannot send at all. This also doesn't happen with normal USB dongles, so it must be some behavior of Zephyr.

How can I prevent the reception of the data that I sent by myself?


Re: porting cyclictest to zephyr

João Costa
 

No one ?
:/

João Costa <joaocostalapin@...> escreveu no dia quarta, 16/06/2021 à(s) 17:21:

Hello,

In [1], and not only, it is mentioned that cyclictest was used with zephyr. However, I cannot find any specific documentation regarding this combination (zephyr + cyclictest).

Could anyone explain me, or point me in the right direction, how to port cyclictest into zypher?

Thanks




stm32 quadrature decoder general purpose timer functionality

Matias N.
 

Hi,
I need to access STM32's general purpose timer's quadrature decoding functionality. I'm trying to understand what exactly is needed to expose this, either write a custom driver accessing arch-dependant interface directly or if there's at least some support exposed via counter API for example. I see there's specific driver for STM32 PWM functionality so I would guess a similar driver is needed. There's also STM32 counter driver but this would be a different kind of counter (requires special setup of timer). I also see bindings for other platforms which have dedicated QDEC peripherals, so I'm guessing that a similar DTS binding should also be added.

What would be the proper way to do this?

Best,
Matias


porting cyclictest to zephyr

João Costa
 

Hello,

In [1], and not only, it is mentioned that cyclictest was used with zephyr. However, I cannot find any specific documentation regarding this combination (zephyr + cyclictest).

Could anyone explain me, or point me in the right direction, how to port cyclictest into zypher?

Thanks




Re: Zephyr 2.6.0 and st_ble_sensor sample on the nucleo_wb55rg board. #ble #bluetooth #stm32

Erwan Gouriou
 

Hi Kevin,

Thanks for reporting this.
Would you mind creating a github issue ?
We'll investigate the point

BR
Erwan


On Wed, 16 Jun 2021 at 00:09, <kevin@...> wrote:

I would like to move a BLE project from Zephyr 2.5.0 to 2.6.0. The st_ble_sensor sample included in the Zephyr 2.5.0 tree compiles and runs successfully with the nucleo_wb55rg eval board, but does not work when I attempt the same from the Zephyr 2.6.0 tree. In this case the board advertises correctly, and is seen by ST BLE Sensor iPhone app, but an attempt to connect results in a forever-spinning Connecting icon. With our own project code we get a connection notification from the bluetooth subsystem and then the client times out while trying to enumerate the GATT.

Has anybody made the st_ble_sensor sample to work with the nucleo_wb55rg eval board? Wouldn't this be part of the Zephyr release testing?

Thanks,

Kevin


Zephyr 2.6.0 and st_ble_sensor sample on the nucleo_wb55rg board. #ble #bluetooth #stm32

kevin@...
 

I would like to move a BLE project from Zephyr 2.5.0 to 2.6.0. The st_ble_sensor sample included in the Zephyr 2.5.0 tree compiles and runs successfully with the nucleo_wb55rg eval board, but does not work when I attempt the same from the Zephyr 2.6.0 tree. In this case the board advertises correctly, and is seen by ST BLE Sensor iPhone app, but an attempt to connect results in a forever-spinning Connecting icon. With our own project code we get a connection notification from the bluetooth subsystem and then the client times out while trying to enumerate the GATT.

Has anybody made the st_ble_sensor sample to work with the nucleo_wb55rg eval board? Wouldn't this be part of the Zephyr release testing?

Thanks,

Kevin


Re: Activate shell over uart

Ruud Derwig
 

Hi Jacob,

 

> I'm trying to enable the shell subsystem over the uart console on my board with no luck.

 

It seems to be a problem in the board/test config for the ARC hsdk board. Watson is looking into it:

https://github.com/zephyrproject-rtos/zephyr/issues/36254

 

Feel free to subscribe to the issue to be notified of updates.

 

Ruud.


Re: RFC: Developer Experience WG kick off - we want your input!

Kumar Gala
 

On Jun 14, 2021, at 10:21 AM, Jonathan Beri <jberi@golioth.io> wrote:

Hi all,

During a BoF session at this year's Developer Summit, several of us felt the need to kick off a temporary working group focused on the Developer Experience of Zephyr. Topics that spurred the discussion included Editor and IDE configuration, (ex. what's the VS Code experience?) & CI/CD performance with Github Action.

We'd like to collect comments at this Github Discussion: https://github.com/zephyrproject-rtos/zephyr/discussions/36194. But feel free to reply here and I'll make sure your feedback is included.

Looking forward to creating the best-possible developer experience for Zephyr, together!

One topic I think would be good to take on is:

https://github.com/zephyrproject-rtos/crosstool-ng-old/issues/25

- k


RFC: Developer Experience WG kick off - we want your input!

Jonathan Beri
 

Hi all,

During a BoF session at this year's Developer Summit, several of us felt the need to kick off a temporary working group focused on the Developer Experience of Zephyr. Topics that spurred the discussion included Editor and IDE configuration, (ex. what's the VS Code experience?) & CI/CD performance with Github Action.

We'd like to collect comments at this Github Discussion: https://github.com/zephyrproject-rtos/zephyr/discussions/36194. But feel free to reply here and I'll make sure your feedback is included.

Looking forward to creating the best-possible developer experience for Zephyr, together!

--


how to support new touch screen sensor with integration to LVGL

Matias N.
 

Hi,
I'm considering adding support for a touchscreen sensor (CST816, used in PineTime) and I would like
to use LVGL as well. Right now LVGL expects touchscreen sensor to be exposed via KSCAN API,
however this impedes supporting the touchpad's gesture detection. I found some old messages
in the list proposing a touch API but it was then recommended to use the sensor API. This is indeed
possible but it would require extending LVGL integration layer (besides adding some standard
channel types for gestures and taps, etc).

What is preferable at this point?

Best,
Matias


Activate shell over uart

Jacob Avraham
 

Hi,
I'm trying to enable the shell subsystem over the uart console on my board with no luck.
I built the samples/subsys/shell/shell_module/ application and added some printk() to it just to see that the console is working, and indeed the printk works.
I don't get any prompt, or any other interaction with the console.
Any idea what am I doing wrong?In general, I'm trying to understand how the shell works. Is it running as a separate thread along side with my application thread?
Is it running in kernel mode, or userspace?
Your insight is appreciated.
-Jacob

41 - 60 of 2659