Date   

[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


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


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


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: 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


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
 

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


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-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=


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

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@...>
 

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

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


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

 

 


★ Zephyr Users, Felipe te mandou uma mensagem

Felipe Neves
 


using Intel ISSM tolos to compile arduino_101_sss

Carles Perello
 

Hi

While having no issues using Intel ISSM toolkit on arduino_101, when I try to compile using arduino_101_sss as target, it complains that

arc-elf32-gcc.exe: error: unrecognized argument in option '-mcpu=quarkse_em'

what would be the apropiate cpu to use on ISSM tools?


cheers


[net]Why not respond RS message

guiwu.guo <hfggw@...>
 

Hi all,

I am development a Ipv6 project now, I have enable the CONFIG_NET_IPV6_ND.
But when the connection establish between two note, the note doesn't processing the RS message.
the log is like this:
[net/core] [DBG] net_recv_data: (0x200092b8): fifo 0x20003620 iface 0x20000e60 pkt 0x20008fa4 len 28
[net/core] [INF] net_analyze_stack: net (0x200081a4): RX thread stack real size 1596 unused 796 usage 704/1500 (43 %)
[net/core] [DBG] net_rx_thread: (0x200081a4): Received pkt 0x20008fa4 len 28
[net/ipv6] [DBG] net_ipv6_process_pkt: (0x200081a4): IPv6 packet len 56 received from fe80::d2af:d0ff:fe36:f04d to ff02::1
[net/ipv6] [DBG] process_icmpv6_pkt: (0x200081a4): ICMPv6 Router Solicitation received type 133 code 0
[net/core] [DBG] processing_data: (0x200081a4): Dropping pkt 0x20008fa4
In the code of icmpv6 that only register the request handler of echo_request:
static struct net_icmpv6_handler echo_request_handler = {
.type = NET_ICMPV6_ECHO_REQUEST,
.code = 0,
.handler = handle_echo_request,
};
Does it loss RS request processing in icmpv6?

Thanks,
Guiwu.guo


Re: Reg: Enable arc to access the spi controller on I/O fabric on C1000

Michael Rosen
 

1. I have declared CONFIG_SPI in the prj.conf for the ARC project and SPI access is working.
Can I declare the CONFIG_ SPI on the prj.conf on the X86 also ?
My query is simultaneous SPI access is possible via ARC and X86 ? or should we declare CONFIG_SPI in any one of the cores only.
You can, just be aware that there isn't any builtin mutual exclusion between the x86 and ARC cores in the OS, so if both cores are trying to access the same SPI controller, there will likely be concurrency issues. But it should be perfectly fine to use SPI0 from x86 and SPI1 from ARC (just be aware there still might be issues if you attempt to clock gate the controllers from both cores). Just be sure to disable the SPI controller you aren't using on the core that isn't using it or the interrupt routing will break things (wrong core responding to the interrupt).

x86.conf:

CONFIG_SPI=y
CONFIG_SPI_QMSI=y
CONFIG_SPI_0=y
CONFIG_SPI_1=n

arc.conf:

CONFIG_SPI=y
CONFIG_SPI_QMSI=y
CONFIG_SPI_0=n
CONFIG_SPI_1=y

2. After reset of C1000, the code in the ARC is getting executed first, Followed by x86 .
By default can I make some settings to delay the execution of ARC code  other than task_sleep ?
You can make sure ARC starts later if you modify the following file (unfortunately, the option isn't Kconfig'able):
arch/x86/soc/intel_quark/quark_se/soc.c

And modify the priority under SYS_INIT to be later. However, if you want it to happen AFTER the x86 application starts, youll need to still modify that file to remove the SYS_INIT and add this to your application:

extern int _arc_init(struct dev* arg);

// use in app like so
// if (_arc_init(NULL)) {
// printk("ARC initialization failed!\n");
// }

Its pretty ugly, but functional. You will still need CONFIG_ARC_INIT=y to build the _arc_init function.

Mike

2521 - 2540 of 2576