Date   

I2C or SPI Driver Example for ARC (Sensor subsystem) for Quark_se

Mahendravarman Rajarao (RBEI/EAA10) <Mahendravarman.Rajarao@...>
 

Hi Team

 

Do you have any sample/example of Using I2C or SPI driver of ARC ( sensor subsystem) in Quark_se ?

 

Thanks

 

 


★ Leia suas mensagens antes que sejam deletadas

Felipe Neves
 

Badoo
See this email in English, Deutsch, Français, Italiano, Español or 37 other languages
Felipe te enviou uma mensagem
Você ainda não leu a mensagem enviada por Felipe. Leia antes que seja deletada!
Outras pessoas perto de você:
App Store Google Play Windows Store


I2C or SPI Driver Example for ARC (Sensor subsystem) for Quark_se

Mahendravarman Rajarao (RBEI/EAA10) <Mahendravarman.Rajarao@...>
 

 

Hi Team

 

Do you have any sample/example of Using I2C or SPI driver of ARC ( sensor subsystem) in Quark_se ?

 

Thanks

 

 


Re: [Zephyr-devel] I2C or SPI Driver Example for ARC (Sensor subsystem) for Quark_se

Bogdan Davidoaia
 

Hello,

Although they are not specific to ARC, you can look over most of the
sensor drivers (in drivers/sensor/) for use of I2C and SPI.

Use of the I2C/SPI API is the same regardless of the platform, so it
should be an ok starting point.

Regards,
Bogdan



On 11 May 2017 at 08:12, Mahendravarman Rajarao (RBEI/EAA10)
<Mahendravarman.Rajarao@in.bosch.com> wrote:


Hi Team



Do you have any sample/example of Using I2C or SPI driver of ARC ( sensor
subsystem) in Quark_se ?



Thanks






_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


Re: [Zephyr-devel] I2C or SPI Driver Example for ARC (Sensor subsystem) for Quark_se

Dinh, Kien T <kien.t.dinh@...>
 

Hi Mahendravarman,

 

You might try to look at the samples folder in the repository. The below examples are using I2C and SPI on ARC:

https://github.com/zephyrproject-rtos/zephyr/tree/master/samples/drivers/current_sensing

https://github.com/zephyrproject-rtos/zephyr/tree/master/samples/environmental_sensing

https://github.com/zephyrproject-rtos/zephyr/tree/master/samples/sensor/bme280

 

Regards,

Kien

 

 

From: <zephyr-devel-bounces@...> on behalf of "Mahendravarman Rajarao (RBEI/EAA10)" <Mahendravarman.Rajarao@...>
Date: Thursday, May 11, 2017 14:12
To: "users@..." <users@...>, "devel@..." <devel@...>
Subject: [Zephyr-devel] I2C or SPI Driver Example for ARC (Sensor subsystem) for Quark_se

 

 

Hi Team

 

Do you have any sample/example of Using I2C or SPI driver of ARC ( sensor subsystem) in Quark_se ?

 

Thanks

 

 


Re: [Zephyr-devel] I2C or SPI Driver Example for ARC (Sensor subsystem) for Quark_se

Mahendravarman Rajarao (RBEI/EAA10) <Mahendravarman.Rajarao@...>
 

Hi

 

Iam using zephyr 1.6.0 downloaded from the site

 

If I need to toggle a simple GPIO on the Sensor subsystem, In the Kconfig file of the ARC

Config options given are GPIO_QMSI , GPIO_QMSI_SS & GPIO_QMSI_SS_0_NAME (default name is GPIO_SS_0)

 

So In device binding we need to give as device_get_binding(“GPIO_SS_0”);

If I give as device_get_binding(“GPIO_0”); then x86 gpio is toggling.

 

Can you confirm this ?

 

 

Do you have any example of gpio with sensor subsystem ?

 

 

 

Thanks

From: Dinh, Kien T [mailto:kien.t.dinh@...]
Sent: Thursday, May 11, 2017 2:41 PM
To: Mahendravarman Rajarao (RBEI/EAA10) <Mahendravarman.Rajarao@...>; users@...; devel@...
Subject: Re: [Zephyr-devel] I2C or SPI Driver Example for ARC (Sensor subsystem) for Quark_se

 

Hi Mahendravarman,

 

You might try to look at the samples folder in the repository. The below examples are using I2C and SPI on ARC:

https://github.com/zephyrproject-rtos/zephyr/tree/master/samples/drivers/current_sensing

https://github.com/zephyrproject-rtos/zephyr/tree/master/samples/environmental_sensing

https://github.com/zephyrproject-rtos/zephyr/tree/master/samples/sensor/bme280

 

Regards,

Kien

 

 

From: <zephyr-devel-bounces@...> on behalf of "Mahendravarman Rajarao (RBEI/EAA10)" <Mahendravarman.Rajarao@...>
Date: Thursday, May 11, 2017 14:12
To: "
users@..." <users@...>, "devel@..." <devel@...>
Subject: [Zephyr-devel] I2C or SPI Driver Example for ARC (Sensor subsystem) for Quark_se

 

 

Hi Team

 

Do you have any sample/example of Using I2C or SPI driver of ARC ( sensor subsystem) in Quark_se ?

 

Thanks

 

 


Re: [Zephyr-devel] I2C or SPI Driver Example for ARC (Sensor subsystem) for Quark_se

Dinh, Kien T <kien.t.dinh@...>
 

Have you looked at the gpio sample under samples/drivers/gpio?

 

It’s just “GPIO_0”, and it depends whether the app is built for ARC or x86.

For x86, it can be built with:

$ make BOARD=arduino_101

And for ARC, it can be built with

$ make BOARD=arduino_101_sss

 

Regards,

Kien

 

From: "Mahendravarman Rajarao (RBEI/EAA10)" <Mahendravarman.Rajarao@...>
Date: Thursday, May 11, 2017 18:35
To: Kien Dinh <kien.t.dinh@...>, "users@..." <users@...>, "devel@..." <devel@...>
Cc: Bogdan Davidoaia <bogdan.davidoaia@...>
Subject: RE: [Zephyr-devel] I2C or SPI Driver Example for ARC (Sensor subsystem) for Quark_se

 

Hi

 

Iam using zephyr 1.6.0 downloaded from the site

 

If I need to toggle a simple GPIO on the Sensor subsystem, In the Kconfig file of the ARC

Config options given are GPIO_QMSI , GPIO_QMSI_SS & GPIO_QMSI_SS_0_NAME (default name is GPIO_SS_0)

 

So In device binding we need to give as device_get_binding(“GPIO_SS_0”);

If I give as device_get_binding(“GPIO_0”); then x86 gpio is toggling.

 

Can you confirm this ?

 

 

Do you have any example of gpio with sensor subsystem ?

 

 

 

Thanks


From: Dinh, Kien T [mailto:kien.t.dinh@...]
Sent: Thursday, May 11, 2017 2:41 PM
To: Mahendravarman Rajarao (RBEI/EAA10) <Mahendravarman.Rajarao@...>; users@...; devel@...
Subject: Re: [Zephyr-devel] I2C or SPI Driver Example for ARC (Sensor subsystem) for Quark_se

 

Hi Mahendravarman,

 

You might try to look at the samples folder in the repository. The below examples are using I2C and SPI on ARC:

https://github.com/zephyrproject-rtos/zephyr/tree/master/samples/drivers/current_sensing

https://github.com/zephyrproject-rtos/zephyr/tree/master/samples/environmental_sensing

https://github.com/zephyrproject-rtos/zephyr/tree/master/samples/sensor/bme280

 

Regards,

Kien

 

 

From: <zephyr-devel-bounces@...> on behalf of "Mahendravarman Rajarao (RBEI/EAA10)" <Mahendravarman.Rajarao@...>
Date: Thursday, May 11, 2017 14:12
To: "
users@..." <users@...>, "devel@..." <devel@...>
Subject: [Zephyr-devel] I2C or SPI Driver Example for ARC (Sensor subsystem) for Quark_se

 

 

Hi Team

 

Do you have any sample/example of Using I2C or SPI driver of ARC ( sensor subsystem) in Quark_se ?

 

Thanks

 

 


Re: [Zephyr-devel] I2C or SPI Driver Example for ARC (Sensor subsystem) for Quark_se

Chuck Jordan <Chuck.Jordan@...>
 

Be sure to also get the data sheet for the device attached to SPI or I2C.
There are configurable options you must do correctly to communicate properly to the device on the other side.

-----Original Message-----
From: zephyr-devel-bounces@lists.zephyrproject.org [mailto:zephyr-devel-bounces@lists.zephyrproject.org] On Behalf Of Bogdan Davidoaia
Sent: Thursday, May 11, 2017 1:00 AM
To: Mahendravarman Rajarao (RBEI/EAA10) <Mahendravarman.Rajarao@in.bosch.com>
Cc: devel@lists.zephyrproject.org; users@lists.zephyrproject.org
Subject: Re: [Zephyr-devel] I2C or SPI Driver Example for ARC (Sensor subsystem) for Quark_se

Hello,

Although they are not specific to ARC, you can look over most of the sensor drivers (in drivers/sensor/) for use of I2C and SPI.

Use of the I2C/SPI API is the same regardless of the platform, so it should be an ok starting point.

Regards,
Bogdan



On 11 May 2017 at 08:12, Mahendravarman Rajarao (RBEI/EAA10) <Mahendravarman.Rajarao@in.bosch.com> wrote:


Hi Team



Do you have any sample/example of Using I2C or SPI driver of ARC (
sensor
subsystem) in Quark_se ?



Thanks






_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.zephyrproje
ct.org_mailman_listinfo_zephyr-2Ddevel&d=DwICAg&c=DPL6_X_6JkXFx7AXWqB0
tg&r=Ur8eT0ZY1DOjJtZ8biKXp_CyOvecmZtsphp7SXIsE1Y&m=nirrrHvTYPm_ezoRVKS
QRHEVyJyfsiT6yrNJC04V0C0&s=rW_84jfRfJ5BSA2GSTM_0-tJAVqNHs73iLJNKcJ0FtI
&e=
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.zephyrproject.org_mailman_listinfo_zephyr-2Ddevel&d=DwICAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=Ur8eT0ZY1DOjJtZ8biKXp_CyOvecmZtsphp7SXIsE1Y&m=nirrrHvTYPm_ezoRVKSQRHEVyJyfsiT6yrNJC04V0C0&s=rW_84jfRfJ5BSA2GSTM_0-tJAVqNHs73iLJNKcJ0FtI&e=


Zephyr in use with Arduino

Kevin Stöckl <k_stoeckl@...>
 

Hello,

I am trying to make a security camera with zephyr and Arduino and therefore I had some Questions.


1. Which Arduino will be the best for this Application? "Due" or "101"?

2. How can I turn on a USB Webcam when it is necessary?

3. Is it possible to get a Internet Connection with the Arduino Due?


Thanks in Advance

Kevin


Re: Zephyr in use with Arduino

Justin
 

The Arduino Due has USB host, but I don't think support will be added anytime soon for that. You will need USB host support to connect the webcam to the board. There is no easy connection to the internet for the Arduino Due board either. You could add an external WiFi chip or external BLE chip, which you would have to write the driver for. The BLE might work because Zephyr currently has a lot of BLE support. However, you won't be able to sent high resolution images because BLE is low bandwidth.

The Arduino 101 looks like it has USB, but I haven't been able to find the datasheet for the chip to see if it supports host. Even then you will need to write the host driver. The board does come with BLE on it, which may already work with Zephyr. I don't know for sure. I will check in the next few days or you can check.

Getting the data from the webcam is going to take a board with USB host though that's going to be the most difficult part because no board has USB host support right now.

As far as getting the data to the internet you really need a board with Ethernet or Wifi because video is high bandwidth.

On Thu, May 18, 2017 at 7:35 AM Kevin Stöckl <k_stoeckl@...> wrote:

Hello,

I am trying to make a security camera with zephyr and Arduino and therefore I had some Questions.


1. Which Arduino will be the best for this Application? "Due" or "101"?

2. How can I turn on a USB Webcam when it is necessary?

3. Is it possible to get a Internet Connection with the Arduino Due?


Thanks in Advance

Kevin

_______________________________________________
Zephyr-users mailing list
Zephyr-users@...
https://lists.zephyrproject.org/mailman/listinfo/zephyr-users


Re: Zephyr in use with Arduino

Kevin Stöckl <k_stoeckl@...>
 

Okay Thank you. 


so would it be better to take a Uart TTL Serial Camera? Is there a possibility to communicate with the camera without writing a driver?




Von: Justin Watson <jwatson5@...>
Gesendet: Donnerstag, 18. Mai 2017 18:44
An: Kevin Stöckl; zephyr-users@...
Betreff: Re: [Zephyr-users] Zephyr in use with Arduino
 
The Arduino Due has USB host, but I don't think support will be added anytime soon for that. You will need USB host support to connect the webcam to the board. There is no easy connection to the internet for the Arduino Due board either. You could add an external WiFi chip or external BLE chip, which you would have to write the driver for. The BLE might work because Zephyr currently has a lot of BLE support. However, you won't be able to sent high resolution images because BLE is low bandwidth.

The Arduino 101 looks like it has USB, but I haven't been able to find the datasheet for the chip to see if it supports host. Even then you will need to write the host driver. The board does come with BLE on it, which may already work with Zephyr. I don't know for sure. I will check in the next few days or you can check.

Getting the data from the webcam is going to take a board with USB host though that's going to be the most difficult part because no board has USB host support right now.

As far as getting the data to the internet you really need a board with Ethernet or Wifi because video is high bandwidth.

On Thu, May 18, 2017 at 7:35 AM Kevin Stöckl <k_stoeckl@...> wrote:

Hello,

I am trying to make a security camera with zephyr and Arduino and therefore I had some Questions.


1. Which Arduino will be the best for this Application? "Due" or "101"?

2. How can I turn on a USB Webcam when it is necessary?

3. Is it possible to get a Internet Connection with the Arduino Due?


Thanks in Advance

Kevin

_______________________________________________
Zephyr-users mailing list
Zephyr-users@...
https://lists.zephyrproject.org/mailman/listinfo/zephyr-users


Re: Zephyr in use with Arduino

Justin
 

Of course you can do that without writing a driver. You can't send your code to Zephyr though and expect it to be added if it's not part of a driver. You can do whatever you want in your own project.


On Thu, May 18, 2017 at 10:08 AM Kevin Stöckl <k_stoeckl@...> wrote:

Okay Thank you. 


so would it be better to take a Uart TTL Serial Camera? Is there a possibility to communicate with the camera without writing a driver?




Von: Justin Watson <jwatson5@...>
Gesendet: Donnerstag, 18. Mai 2017 18:44
An: Kevin Stöckl; zephyr-users@...
Betreff: Re: [Zephyr-users] Zephyr in use with Arduino
 
The Arduino Due has USB host, but I don't think support will be added anytime soon for that. You will need USB host support to connect the webcam to the board. There is no easy connection to the internet for the Arduino Due board either. You could add an external WiFi chip or external BLE chip, which you would have to write the driver for. The BLE might work because Zephyr currently has a lot of BLE support. However, you won't be able to sent high resolution images because BLE is low bandwidth.

The Arduino 101 looks like it has USB, but I haven't been able to find the datasheet for the chip to see if it supports host. Even then you will need to write the host driver. The board does come with BLE on it, which may already work with Zephyr. I don't know for sure. I will check in the next few days or you can check.

Getting the data from the webcam is going to take a board with USB host though that's going to be the most difficult part because no board has USB host support right now.

As far as getting the data to the internet you really need a board with Ethernet or Wifi because video is high bandwidth.

On Thu, May 18, 2017 at 7:35 AM Kevin Stöckl <k_stoeckl@...> wrote:

Hello,

I am trying to make a security camera with zephyr and Arduino and therefore I had some Questions.


1. Which Arduino will be the best for this Application? "Due" or "101"?

2. How can I turn on a USB Webcam when it is necessary?

3. Is it possible to get a Internet Connection with the Arduino Due?


Thanks in Advance

Kevin

_______________________________________________
Zephyr-users mailing list
Zephyr-users@...
https://lists.zephyrproject.org/mailman/listinfo/zephyr-users


Using printk on an STM32F103C8 board

Scott Nelson <scott@...>
 

I’m trying to get Zephyr running on an STM32F103C8 "blue pill" board by using the similar nucleo_f103rb board config (with which I can successfully get an LED to blink). I’m trying to setup printk by enabling CONFIG_UART_STM32_PORT_1=y (TX=PA9, RX=PA10) but I get the following compile errors: https://pastebin.com/raaww0a8

Am I missing additional config?

I was also planning on setting CONFIG_UART_CONSOLE_ON_DEV_NAME="UART_1" and CONFIG_PRINTK=y in hopes of being able to read printk messages via a USB-to-serial adapter.

-Scott


Re: Using printk on an STM32F103C8 board

Adam Podogrocki
 

Hi Scott,

if you are using board configuration file purposed for Nucleo F103RB, then the default UART configuration refers to UART2, pins TX=A2, RX=PA3. Pins configuration can be found in drivers/pinmux/stm32/pinmux_board_nucleo_f103rb.c.

If you would like to use UART1, then in menuconfig you have to modify settings for Serial drivers & Console drivers to match the desired UART port and baud rate.

Compile errors point out that the UART1 configuration is missing.

Please also take a look at e.g "dts/arm/nucleo_l476rg.fixup" file and do appropriate amendments in nucleo f103rb corresponding file.

Cheers,
Adam

On 21 May 2017 at 23:54, Scott Nelson <scott@...> wrote:
I’m trying to get Zephyr running on an STM32F103C8 "blue pill" board by using the similar nucleo_f103rb board config (with which I can successfully get an LED to blink).  I’m trying to setup printk by enabling CONFIG_UART_STM32_PORT_1=y (TX=PA9, RX=PA10) but I get the following compile errors: https://pastebin.com/raaww0a8

Am I missing additional config?

I was also planning on setting CONFIG_UART_CONSOLE_ON_DEV_NAME="UART_1" and CONFIG_PRINTK=y in hopes of being able to read printk messages via a USB-to-serial adapter.

-Scott
_______________________________________________
Zephyr-users mailing list
Zephyr-users@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-users


Re: Using printk on an STM32F103C8 board

Scott Nelson <scott@...>
 

Hi Adam,

I opened up the menuconfig and verified that “Device Drivers > Serial Drivers -> STM32 MCU serial driver > Enable STM32 USART1 Port” was selected (presumably because I set CONFIG_UART_STM32_PORT_1=y in my project-specific config file). What other config options do I need to set? When browsing through the menuconfig I did not see a place to set the baudrate (also did not see a relevant baudrate config option here: https://www.zephyrproject.org/doc/reference/kconfig/index.html).

Thanks!

-Scott

On May 22, 2017, at 1:33 AM, Adam Podogrocki <a.podogrocki@gmail.com> wrote:

Hi Scott,

if you are using board configuration file purposed for Nucleo F103RB, then the default UART configuration refers to UART2, pins TX=A2, RX=PA3. Pins configuration can be found in drivers/pinmux/stm32/pinmux_board_nucleo_f103rb.c.

If you would like to use UART1, then in menuconfig you have to modify settings for Serial drivers & Console drivers to match the desired UART port and baud rate.

Compile errors point out that the UART1 configuration is missing.

Please also take a look at e.g "dts/arm/nucleo_l476rg.fixup" file and do appropriate amendments in nucleo f103rb corresponding file.

Cheers,
Adam

On 21 May 2017 at 23:54, Scott Nelson <scott@scottnelson.co> wrote:
I’m trying to get Zephyr running on an STM32F103C8 "blue pill" board by using the similar nucleo_f103rb board config (with which I can successfully get an LED to blink). I’m trying to setup printk by enabling CONFIG_UART_STM32_PORT_1=y (TX=PA9, RX=PA10) but I get the following compile errors: https://pastebin.com/raaww0a8

Am I missing additional config?

I was also planning on setting CONFIG_UART_CONSOLE_ON_DEV_NAME="UART_1" and CONFIG_PRINTK=y in hopes of being able to read printk messages via a USB-to-serial adapter.

-Scott
_______________________________________________
Zephyr-users mailing list
Zephyr-users@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-users


[CFP] Elsevier FGCS Journal [IF=2.43] -- SI on "Internet of Things (IoT): Operating System, Applications and Protocols Design, and Validation Techniques"

Yousaf Bin Zikria <yousaf.bin.zikria@...>
 

Dear All, 

Please find below a call for papers for Special Issue in Elsevier Future Generation Computer Systems Journal.

Please accept our apologies if you receive multiple copies of this announcement.


---------------------------
CALL FOR PAPERS

Special Issue in Elsevier Future Generation Computer Systems Journal.
" Internet of Things (IoT): Operating System, Applications and Protocols Design, and Validation Techniques"

Submission Deadline: June 30, 2017

THE THEME
------------------

Internet of Things (IoT) connects durable goods, cars and trucks, industrial and utility components, and sensors to Internet with data analytics capabilities. IoT is flourishing due to technology advancements. The key features of IoT Operating Systems (OSs) are modularity, energy-efficient scheduler, hardware support, architecture, network stacks, reliability, interoperability, unified APIs, generic interfaces, and real-time capabilities. The applications for IoT service scenarios are diverse and challenging. These range from smart energy, transportation, etc. to big data analysis. The integration of all these applications is essential to eventually make everything smart. The memory and energy efficient IoT protocols are desirable. The validation of IoT protocols and applications is a key to success. Therefore, an IoT OS requires to support not only a huge variety of  heterogeneous hardware, but also simulators and emulators as well as testbed facilities Further, it should provide the capability to perform small scale to large scale testing with heterogeneous physical devices and communication technologies. The availability of variety of IoT OSs, low-cost IoT devices, heterogeneous telecommunications technologies, big data technologies and standardization is a key of success for IoT deployment. To fully exploit these technological advancements, there exists many issues related to applications, protocols, testing, interoperability; time bounded big data processing and analysis, heterogeneous communication technologies and platform support.

This Special Issue focuses on the most recent advancement in interdisciplinary research areas encompassing IoT OSs, applications and protocols design, development, and validation domain. This Special Issue will bring together researchers from diverse fields such as communication engineering, computer engineering, computer science, electrical and electronics engineering, bio-informatics and mathematics. Through this Special Issue, we invite researchers from industry, academia and government organizations to discuss innovative ideas and contributions, demonstrate results and share standardization efforts on the IoT OSs and related areas.

Topics of interest include, but not limited to the following:

                      ·         IoT Operating Systems (OSs)

o    Energy and memory efficient approaches

o    Sensors, IoT platform support and limitations in IoT OSs

o    Interoperability of IoT OSs protocols and devices

o    Simulation, emulation and testbed support, limitations and Solutions

o    Resource management for IoT OSs

o    Memory management for resource constrained IoT devices

o    Security issues and solutions for privacy in IoT OSs

o    Co-existence of technologies, limitation and solutions

o    Standard API specifications for IoT OSs

 

                   ·          Applications for IoT Service Scenario

o    Smart energy

o    Smart transportation

o    Smart waste management

o    Smart buildings

o    Smart physical safety and security

o    Smart health care

o    Smart education

o    Smart Personal Network (SPN)

o    Edge Computing

o    Cooperative and smart sensing approaches

o    Sensor data collection and management

o    Efficient big data techniques, processing, and analysis

 

               ·         Protocol overview, issues and solutions

o    IoT physical layer protocols 

o    IoT MAC layer protocols

o    IoT network layer protocols

o    IoT transport layer protocols

o    IoT applications

o    Radio Duty Cycling (RDC)

o    Cross layer protocol design

 

              ·         Modeling of IoT heterogeneous wireless technologies, protocols and applications

              ·         Simulator/Emulator issues and  improvements

             ·         Testbed deployment and testing

Submission Guidelines:
---------------------------------


All submissions have to be prepared according to the Guide for Authors as published in the Journal website at 
http://ees.elsevier.com/fgcs/. Authors should select “IoT:OS,App,Proto,Valid”, from the “Choose Article Type” pull-down menu during the submission process at EVISE. All contributions must not have been previously published or be under consideration for publication elsewhere. A submission based on one or more papers that appeared elsewhere has to comprise major value-added extensions over what appeared previously (at least 30% new material). Authors are requested to attach to the submitted paper their relevant, previously published articles and a summary document explaining the enhancements made in the journal version.



Important Dates:
-----------------------

Submission Deadline (Full Paper): 30 June 2017

Notification of Acceptance/Revisions: 30 Oct 2017

Final paper production deadline: 30 Dec 2017

Expected publication of Special IssueFeb 2018

GUEST EDITORS OF THE SPECIAL SECTION
------------------------------------------------------------

Yousaf Bin Zikria, Lead Guest Editor

Yeungnam University, South Korea.

Email:yousafbinzikria@...m

 

Heejung Yu

Yeungnam University, South Korea.

Email: heejung@...

 

Muhammad Khalil Afzal

COMSATS Institute of Information Technology, Pakistan

Email: khalilafzal@....pk

Mubashir Husain Rehmani

COMSATS Institute of Information Technology, Pakistan.

Email: mshrehmani@...

 

Oliver Hahm

Inria, France,

                Email : oliver.hahm@... 


--
Warm Regards
Yousaf Bin Zikria, Ph.D.
Managing Guest Editor
Future Generation Computer Systems
Information and Communication Engineering
College of Engineering, Yeungnam University


Patch for zephyr 1.6 which includes deep sleep for quark_se

Mahendravarman Rajarao (RBEI/EAA10) <Mahendravarman.Rajarao@...>
 

Hi

 

In Zephyr 1.7 , the implementation for deep sleep for quark_se is done

 

We have finalized our application based on zephyr 1.6. In this version deep sleep implementation for quark_se is NOT available

 

 

Is there any patch I can apply on zephyr 1.6, to get the deep sleep support for quark_se ??

 

Thanks

Mahendra


Error flasing Nucleo F401RE

Lucas Tanure <tanure@...>
 

Hi,

I got this error trying to use the board Nucleo F401RE.

Where is the definition for the flash start address used by openocd ?

tanure@archTanure hello_world $ make BOARD=nucleo_f401re flash
make[1]: Entering directory '/home/tanure/workspace/zephyr'
make[2]: Entering directory
'/home/tanure/workspace/zephyr/samples/hello_world/outdir/nucleo_f401re'
Using /home/tanure/workspace/zephyr as source for kernel
GEN ./Makefile
CHK include/generated/version.h
CHK include/generated/generated_dts_board.h
CHK misc/generated/configs.c
CHK include/generated/offsets.h
make[3]: 'isr_tables.o' is up to date.
Flashing nucleo_f401re
Flashing Target Device
Open On-Chip Debugger 0.9.0-dirty (2017-05-16-18:46)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : The selected transport took over low-level target control. The
results might differ compared to plain JTAG/SWD
adapter speed: 2000 kHz
adapter_nsrst_delay: 100
none separate
srst_only separate srst_nogate srst_open_drain connect_deassert_srst
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : clock speed 1800 kHz
Info : STLINK v2 JTAG v27 API v2 SWIM v15 VID 0x0483 PID 0x374B
Info : using stlink api v2
Info : Target voltage: 3.257255
Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints
TargetName Type Endian TapName State
-- ------------------ ---------- ------ ------------------ ------------
0* stm32f4x.cpu hla_target little stm32f4x.cpu halted
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x08000358 msp: 0x20018000
auto erase enabled
Info : device id = 0x10016433
Info : flash size = 512kbytes
Warn : no flash bank found for address 0
wrote 0 bytes from file
/home/tanure/workspace/zephyr/samples/hello_world/outdir/nucleo_f401re/zephyr.bin
in 0.000737s (0.000 KiB/s)
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x08000358 msp: 0x20018000
diff 0 address 0x00000000. Was 0x00 instead of 0x68
diff 1 address 0x00000001. Was 0x80 instead of 0x08
diff 2 address 0x00000002. Was 0x01 instead of 0x00
diff 3 address 0x00000004. Was 0x59 instead of 0x1d
diff 4 address 0x00000005. Was 0x03 instead of 0x21
diff 5 address 0x00000008. Was 0xa1 instead of 0x6d
diff 6 address 0x00000009. Was 0x03 instead of 0x21
diff 7 address 0x0000000c. Was 0xa1 instead of 0xc5
More than 8 errors, the rest are not printed.

make[2]: *** [/home/tanure/workspace/zephyr/Makefile:1299: flash] Error 1
make[2]: Leaving directory
'/home/tanure/workspace/zephyr/samples/hello_world/outdir/nucleo_f401re'
make[1]: *** [Makefile:176: sub-make] Error 2
make[1]: Leaving directory '/home/tanure/workspace/zephyr'
make: *** [/home/tanure/workspace/zephyr/Makefile.inc:88: flash] Error 2

Thanks

--
Lucas Tanure
Embedded Developer


NXP FRDM-K64F networking

Kevin Stöckl <k_stoeckl@...>
 

Hi

How is it possible to get my data into the cloud with the frdm-k64f board?


Problems with Zephyr JS

Kevin Stöckl <k_stoeckl@...>
 

Hello,

when i try to run following code in the zephyr js ide, then the application did not start. What could be the problem? In the console it just writes "echo o" and than it stops.


var aio = require("aio");
//var ble = require("ble");
var pins = require("arduino101_pins");

// heart rate calculation
var IBI = 600;               // value holds the time interval between beats! Must be seeded!
var pulse = false;           // "True" when User's live heartbeat is detected. "False" when not a "live beat".
var rate = [10];               // array to hold last ten IBI values
var sampleCounter = 0;       // used to determine pulse timing
var lastBeatTime = 0;        // used to find IBI
var P = 2048;                // used to find peak in pulse wave, seeded
var T = 2048;                // used to find trough in pulse wave, seeded
var thresh = 2100;           // used to find instant moment of heart beat, seeded
var amp = 400;               // used to hold amplitude of pulse waveform, seeded
var firstBeat = true;        // used to seed rate array so we startup with reasonable BPM
var secondBeat = false;      // used to seed rate array so we startup with reasonable BPM

// pins
var pin = aio.open({device:0, pin: pins.A1 });

function measureHeartRate(signal) {
    var HR = 0;

    sampleCounter += 2;                        // keep track of the time in mS with this variable
    var N = sampleCounter - lastBeatTime;       // monitor the time since the last beat to avoid noise

    // find the peak and trough of the pulse wave
    if (signal < thresh && (N > ((IBI / 5) * 3))) { // avoid dichrotic noise by waiting 3/5 of last IBI
        if (signal < T) {                       // T is the trough
            T = signal;                         // keep track of lowest point in pulse wave
        }
    }

    if (signal > thresh && signal > P) {        // thresh condition helps avoid noise
        P = signal;                             // P is the peak
    }                                           // keep track of highest point in pulse wave

    // NOW IT'S TIME TO LOOK FOR THE HEART BEAT
    // signal surges up in value every time there is a pulse
    if (N > 250 && N < 2000) {                  // avoid noise. 30 bpm < possible human heart beat < 240
        if ((signal > thresh) && (pulse == false) && (N > ((IBI / 5) * 3))) {
            pulse = true;                       // set the pulse flag when we think there is a pulse
            IBI = sampleCounter - lastBeatTime; // measure time between beats in mS
            lastBeatTime = sampleCounter;       // keep track of time for next pulse

            if (secondBeat) {                   // if this is the second beat, if secondBeat == TRUE
                console.log("Measured 2nd beat");
                secondBeat = false;             // clear secondBeat flag
                for(var i = 0; i <= 9; i++) {   // seed the running total to get a realisitic BPM at startup
                    rate[i] = IBI;
                }
            }

            if (firstBeat) {                    // if it's the first time we found a beat, if firstBeat == TRUE
                console.log("Measured 1st beat");
                firstBeat = false;              // clear firstBeat flag
                secondBeat = true;              // set the second beat flag
                return 0;                       // IBI value is unreliable so discard it
            }

            // keep a running total of the last 10 IBI values
            var runningTotal = 0;               // clear the runningTotal variable

            for (var i = 0; i <= 8; i++) {      // shift data in the rate array
                rate[i] = rate[i + 1];          // and drop the oldest IBI value
                runningTotal += rate[i];        // add up the 9 oldest IBI values
            }

            rate[9] = IBI;                      // add the latest IBI to the rate array
            runningTotal += rate[9];            // add the latest IBI to runningTotal
            runningTotal /= 10;                 // average the last 10 IBI values
            HR = 60000 / runningTotal;          // how many beats can fit into a minute? that's BPM!
        }
    }

    if (signal < thresh && pulse == true) {     // when the values are going down, the beat is over
        pulse = false;                          // reset the pulse flag so we can do it again
        amp = P - T;                            // get amplitude of the pulse wave
        thresh = (amp * 2 / 3) + T;             // set thresh at 67% of the amplitude
        P = thresh;                             // reset these for next time
        T = thresh;
    }

    if (N > 2500) {                             // if 2.5 seconds go by without a beat
        thresh = 2048;                          // set thresh default
        P = 2048;                               // set P default
        T = 2048;                               // set T default
        lastBeatTime = sampleCounter;           // bring the lastBeatTime up to date
        firstBeat = true;                       // set these to avoid noise
        secondBeat = false;                     // when we get the heartbeat back
   }

    return HR;                              // return integer instead of float
}

setInterval(function() {
    var rawSignal = pin.read();
    var signal = measureHeartRate(rawSignal);
    // send notification
    console.log("HR=" + signal);
}, 0);

41 - 60 of 2555