Date   

Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/1332 : Bluetooth: Export helpers for defining buffer pools
- https://gerrit.zephyrproject.org/r/1330 : Bluetooth: Refactor buffer handling for non-host managed buffers
- https://gerrit.zephyrproject.org/r/1325 : power_mgmt: Provide APIs for devices to signal busy to PM policy mgr
- https://gerrit.zephyrproject.org/r/1329 : openocd: make openocd variables overridable from env
- https://gerrit.zephyrproject.org/r/1313 : samples: A test app for spi flash
- https://gerrit.zephyrproject.org/r/1322 : doc: Fixed structure in collab guide
- https://gerrit.zephyrproject.org/r/1321 : doc: create subsystem section
- https://gerrit.zephyrproject.org/r/1320 : doc: move device driver to a new section
- https://gerrit.zephyrproject.org/r/1327 : doc: fix wording in device documentation
- https://gerrit.zephyrproject.org/r/1323 : docs: remove notes from bluetooth document
- https://gerrit.zephyrproject.org/r/1328 : doc: make naming conventions apply to none kernel functions
- https://gerrit.zephyrproject.org/r/1326 : power_mgmt: Sample usage of device_xxx__busy() APIs
- https://gerrit.zephyrproject.org/r/1316 : nano_fifo: Fix problem with nano_fifo and timeouts

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/1135 : boards: nucleo: Adding flash support
- https://gerrit.zephyrproject.org/r/1303 : sensors: add driver for TMP007 infrared thermopile sensor
- https://gerrit.zephyrproject.org/r/1251 : sensor: make runtime configurable attrs continuous
- https://gerrit.zephyrproject.org/r/1281 : Bluetooth: BR/EDR: Make available L2CAP signal channel
- https://gerrit.zephyrproject.org/r/1280 : Bluetooth: BR/EDR: Get proper L2CAP CID limits
- https://gerrit.zephyrproject.org/r/1219 : soc: introduce SoC families and series
- https://gerrit.zephyrproject.org/r/1221 : new SoC naming convention
- https://gerrit.zephyrproject.org/r/1308 : Bluetooth: Rename bt_l2cap_fixed_chan_register()
- https://gerrit.zephyrproject.org/r/1216 : kinetis: reorganise soc directory using soc family
- https://gerrit.zephyrproject.org/r/1217 : stm32: reorganise soc directory and use family/series
- https://gerrit.zephyrproject.org/r/1309 : Bluetooth: BR/EDR: Add register routine for L2CAP fixed channel
- https://gerrit.zephyrproject.org/r/1214 : stm32: rename CONFIG_SOC_STM32 -> CONFIG_SOC_FAMILY_STM32
- https://gerrit.zephyrproject.org/r/1215 : stm32: rename SOC_STM32F1X -> SOC_SERIES_STM32F1X

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/1324 : Makefile: Fix linking order of libraries
- https://gerrit.zephyrproject.org/r/1331 : benchmark: Remove trailing whitespaces.
- https://gerrit.zephyrproject.org/r/1315 : x86.ini: increase arduino_101 priority
- https://gerrit.zephyrproject.org/r/1319 : sanitycheck: fix test names to be same as before
- https://gerrit.zephyrproject.org/r/1318 : sanitycheck: be smarter about scanning for test cases
- https://gerrit.zephyrproject.org/r/1317 : sanitycheck: add ability to use arbitrary report for comparison
- https://gerrit.zephyrproject.org/r/1314 : arduino_101: defconfig: Limit UART defaults for Bluetooth H:4 driver
- https://gerrit.zephyrproject.org/r/1312 : script: jira query: add URL in message
- https://gerrit.zephyrproject.org/r/1162 : doc: Add sensor section to kernel primer
- https://gerrit.zephyrproject.org/r/1161 : doc: Add sensor section in API documentation
- https://gerrit.zephyrproject.org/r/1311 : gpio: dw: add support for D2000 board
- https://gerrit.zephyrproject.org/r/1250 : samples: revert to default CFLAGS
- https://gerrit.zephyrproject.org/r/1170 : galileo: Enable PCI enumeration
- https://gerrit.zephyrproject.org/r/1232 : kernel: Make idle task sleep
- https://gerrit.zephyrproject.org/r/1283 : script: query jira: removed issue type and priority from report.
- https://gerrit.zephyrproject.org/r/1193 : tests: test_early_sleep: Let's test at all initialization level
- https://gerrit.zephyrproject.org/r/1282 : sanitycheck: parallelize binary size calculations


Re: RFC: Timer/Timeout API

Kalowsky, Daniel <daniel.kalowsky@...>
 

+ Marcel, as he mentioned some changes to both areas (I think) at OpenIoT.

-----Original Message-----
From: Luiz Augusto von Dentz [mailto:luiz.dentz(a)gmail.com]
Sent: Friday, April 8, 2016 4:38 AM
To: devel(a)lists.zephyrproject.org
Subject: [devel] RFC: Timer/Timeout API

Hi,

For the network protocols is quite common to have timers/timeouts for
retrying, etc, and these cold be many in parallel depending on how
many protocols and connections are involved, for that reason the IP
stack actually contains a Timer Fiber to keep track of every timer, it
does basically something like this:

net/ip/net_core.c:666:
while (1) {
/* Run various timers */
next_wakeup = etimer_request_poll();
if (next_wakeup == 0) {
/* There was no timers, wait for fiber_wakeup */
next_wakeup = TICKS_UNLIMITED;
} else {
if (next_wakeup > MAX_TIMER_WAKEUP) {
next_wakeup = MAX_TIMER_WAKEUP;
}
...
fiber_sleep(next_wakeup);
}

This actually uses contiki etimer infra but that in the end is using
nano_timer as a backend.

In the other hand in the Bluetooth stack we actually use delayed
fibers, but that requires each and every timeout to create its own
stack to be run separately which adds more footprint to the stack, so
we would like to use the same approach of IP stack and share the same
fiber/stack but without having to resort to any contiki API.

With this in mind Id like to get some opinions regarding the design of
a Timer/Timeout API:

- Shall this be global/system wide or net specific? I think it could
be global enabled with a Kconfig option and perhaps make _nano_timeout
API public.
- Perhaps have the API flexible enough so private fiber could be used
instead in case one don't want to use the global one?
- Where would be the best location in the source tree?

--
Luiz Augusto von Dentz


Daily JIRA Digest

donotreply@...
 

NEW JIRA items within last 24 hours: 1
[ZEP-185] Nanokernel FIFO does not handle timeouts correctly

UPDATED JIRA items within last 24 hours: 1

CLOSED JIRA items within last 24 hours: 0

RESOLVED JIRA items within last 24 hours: 0


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/1311 : gpio: dw: add support for D2000 board
- https://gerrit.zephyrproject.org/r/1310 : Bluetooth: BR/EDR: Refactor bt_l2cap_connected handler
- https://gerrit.zephyrproject.org/r/1307 : net: contiki: Enable 802.15.4 auto-ack for null RDC
- https://gerrit.zephyrproject.org/r/1306 : cc2520: Make HW filtering and AUTOACK working
- https://gerrit.zephyrproject.org/r/1305 : cc2520: Set short address and ieee address from the driver
- https://gerrit.zephyrproject.org/r/1309 : Bluetooth: BR/EDR: Add register routine for L2CAP fixed channel
- https://gerrit.zephyrproject.org/r/1308 : Bluetooth: Rename bt_l2cap_fixed_chan_register()
- https://gerrit.zephyrproject.org/r/1304 : net: Test random is necessary to use CC2520 as radio driver
- https://gerrit.zephyrproject.org/r/1303 : sensors: add driver for TMP007 infrared thermopile sensor
- https://gerrit.zephyrproject.org/r/1283 : script: query jira: removed issue type and priority from report.

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/1217 : stm32: reorganise soc directory and use family/series
- https://gerrit.zephyrproject.org/r/1221 : new SoC naming convention
- https://gerrit.zephyrproject.org/r/1170 : galileo: Enable PCI enumeration
- https://gerrit.zephyrproject.org/r/1216 : kinetis: reorganise soc directory using soc family
- https://gerrit.zephyrproject.org/r/1280 : Bluetooth: BR/EDR: Get proper L2CA CID limits
- https://gerrit.zephyrproject.org/r/1215 : stm32: rename SOC_STM32F1X -> SOC_SERIES_STM32F1X
- https://gerrit.zephyrproject.org/r/1214 : stm32: rename CONFIG_SOC_STM32 -> CONFIG_SOC_FAMILY_STM32
- https://gerrit.zephyrproject.org/r/1219 : soc: introduce SoC families and series
- https://gerrit.zephyrproject.org/r/1281 : Bluetooth: BR/EDR: Make available L2CAP signal channel
- https://gerrit.zephyrproject.org/r/1201 : Bluetooth: tester: Add support for seqence gatt database
- https://gerrit.zephyrproject.org/r/1278 : sensor: fix coding style (bmc150 and lsm9ds0)
- https://gerrit.zephyrproject.org/r/1251 : sensor: make runtime configurable attrs continuous
- https://gerrit.zephyrproject.org/r/1005 : build: Fix not allowing the host tools to be crosscompiled
- https://gerrit.zephyrproject.org/r/1256 : pwm/pca_9685: move driver_api assignment later
- https://gerrit.zephyrproject.org/r/1078 : test_tickless: improve testcase.ini filter
- https://gerrit.zephyrproject.org/r/1258 : gpio/pcal_9535a: move driver_api assignment later
- https://gerrit.zephyrproject.org/r/1259 : uart/nsim: fixed missing driver_api assignment
- https://gerrit.zephyrproject.org/r/1262 : serial/uart.h: no need to check driver_api being NULL
- https://gerrit.zephyrproject.org/r/1250 : samples: revert to default CFLAGS
- https://gerrit.zephyrproject.org/r/914 : gpio: Improve the public API to handle multi callbacks

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/1282 : sanitycheck: parallelize binary size calculations
- https://gerrit.zephyrproject.org/r/1295 : Bluetooth: Kconfig: don't hardcode "UART_0"
- https://gerrit.zephyrproject.org/r/1296 : Bluetooth: drivers/nble: Add Kconfig option for conn.c
- https://gerrit.zephyrproject.org/r/1300 : net: Fix ip_buf_len after removing extra header
- https://gerrit.zephyrproject.org/r/1302 : net: coap: Create buffer while generating observe notification
- https://gerrit.zephyrproject.org/r/1299 : net: Add Kconfig debug option for coap observe and well-known
- https://gerrit.zephyrproject.org/r/1298 : net: Add Kconfig debug option for simple udp and udp packet
- https://gerrit.zephyrproject.org/r/1301 : net: coap: Use correct network buffer in serialization
- https://gerrit.zephyrproject.org/r/1294 : Bluetooth: Refactor nRF51 API
- https://gerrit.zephyrproject.org/r/1297 : arduino_101: Add default Bluetooth UART configurations
- https://gerrit.zephyrproject.org/r/1293 : boards/arduino_101: defconfig: Enable nRF51 PM if NBLE is selected
- https://gerrit.zephyrproject.org/r/1286 : net: coap: Add debug activation support to Kconfig
- https://gerrit.zephyrproject.org/r/1291 : net: Add Kconfig debug option for REST API
- https://gerrit.zephyrproject.org/r/1290 : net: coap: Make sure that local endpoint IP address is set
- https://gerrit.zephyrproject.org/r/1287 : net: contiki: Enhance the IPv6 prefix calculation routine
- https://gerrit.zephyrproject.org/r/1289 : net: coap: Delete network context when CoAP context is deleted
- https://gerrit.zephyrproject.org/r/1288 : net: coap: Add debugging support for CoAP internals
- https://gerrit.zephyrproject.org/r/1292 : net: contiki: Fix the timer expiration check
- https://gerrit.zephyrproject.org/r/1285 : net: Use TICKS_UNLIMITED if there are no timers
- https://gerrit.zephyrproject.org/r/1232 : kernel: Make idle task sleep
- https://gerrit.zephyrproject.org/r/1193 : tests: test_early_sleep: Let's test at all initialization level
- https://gerrit.zephyrproject.org/r/804 : ieee802154: Replace the CC2520 driver with a new implementation
- https://gerrit.zephyrproject.org/r/1190 : drivers: Renaming directory "802.15.4" into "ieee802154"
- https://gerrit.zephyrproject.org/r/1228 : sensor: lsm9ds0-gyro: fix FULL_SCALE attribute
- https://gerrit.zephyrproject.org/r/1194 : samples: add environmental sensing sample for Arduino 101
- https://gerrit.zephyrproject.org/r/1226 : sys_clock: Add a helper to compute micro seconds


RFC: Timer/Timeout API

Luiz Augusto von Dentz
 

Hi,

For the network protocols is quite common to have timers/timeouts for
retrying, etc, and these cold be many in parallel depending on how
many protocols and connections are involved, for that reason the IP
stack actually contains a Timer Fiber to keep track of every timer, it
does basically something like this:

net/ip/net_core.c:666:
while (1) {
/* Run various timers */
next_wakeup = etimer_request_poll();
if (next_wakeup == 0) {
/* There was no timers, wait for fiber_wakeup */
next_wakeup = TICKS_UNLIMITED;
} else {
if (next_wakeup > MAX_TIMER_WAKEUP) {
next_wakeup = MAX_TIMER_WAKEUP;
}
...
fiber_sleep(next_wakeup);
}

This actually uses contiki etimer infra but that in the end is using
nano_timer as a backend.

In the other hand in the Bluetooth stack we actually use delayed
fibers, but that requires each and every timeout to create its own
stack to be run separately which adds more footprint to the stack, so
we would like to use the same approach of IP stack and share the same
fiber/stack but without having to resort to any contiki API.

With this in mind Id like to get some opinions regarding the design of
a Timer/Timeout API:

- Shall this be global/system wide or net specific? I think it could
be global enabled with a Kconfig option and perhaps make _nano_timeout
API public.
- Perhaps have the API flexible enough so private fiber could be used
instead in case one don't want to use the global one?
- Where would be the best location in the source tree?

--
Luiz Augusto von Dentz


Re: Daily JIRA Digest

Kalowsky, Daniel <daniel.kalowsky@...>
 

-----Original Message-----
From: Perez Hernandez, Javier B
Sent: Thursday, April 7, 2016 8:35 AM
To: Kalowsky, Daniel <daniel.kalowsky(a)intel.com>;
devel(a)lists.zephyrproject.org
Subject: Re: [devel] Re: Daily JIRA Digest

Dan,

On Thu, 2016-04-07 at 00:34 +0000, Kalowsky, Daniel wrote:

-----Original Message-----
From: donotreply(a)jenkins.zephyrproject.org
[mailto:donotreply(a)jenkins.zephyrproject.org]
Sent: Wednesday, April 6, 2016 9:47 AM
To: devel(a)lists.zephyrproject.org
Subject: [devel] Daily JIRA Digest

NEW JIRA items within last 24 hours: 2
  B [ZEP-184] (P 2) QMSI 'CONFIG_RTC_IRQ_PRI' undeclared.
  B [ZEP-183] (P 3) [regression]PINMUX_NUM_PINS is missing in
arch/x86/soc/quark_se/soc.h
The fact that I'm needing a decoder key/ring for these emails is not
useful.

What does the B before each line mean?

Not convinced the priority is needed in these emails.  It really does
nothing to add to the title except create some bizarre string
encryption.
It is the first letter of the issue type (Bug, Requirement, Story).

I will probably changed to something like:
Bug:
  [ZEP-] ...
Story
Please don't. Again, you're just creating an extremely difficult line of text to read. Anyone who wants that data can find it in the JIRA entry itself. The point of this email to make people aware of issues being filed that they really might not have been on the notification list for so that they may add themselves to the watch list.

The point is NOT to reproduce all of a JIRA entry in email.


  ..




UPDATED JIRA items within last 24 hours: 2
  B [ZEP-75]  (P 1) REOPENED Zephyr compiler fails with error about
executing
cc1
  B [ZEP-7]   (P 3) REOPENED Arduino 101 GPIO_INT_LEVEL not working
as
expected

CLOSED JIRA items within last 24 hours: 3
  B [ZEP-174] (Fixed) Hello_world app build fail with  error:
'PINMUX_BASE_ADDR' undeclared when
PINMUX_DEV,PINMUX_DEV_QUARK_MCU were enabled
  B [ZEP-161] (Won't Do) Nothing output when run hello_world app
with x86
SDK for quark platforms
  B [ZEP-151] (Fixed) QMSI AON_TIMER_IRQ and AON_TIMER_IRQ_PRI
have
not been configured in quark_se_devboard
Why is the closed status being inserted here?   Anyone interested in
that can and should go look at the JIRA.



RESOLVED JIRA items within last 24 hours: 0


Daily JIRA Digest

donotreply@...
 

NEW JIRA items within last 24 hours: 0

UPDATED JIRA items within last 24 hours: 0
B [ZEP-184] (P 2) ACCEPTED QMSI 'CONFIG_RTC_IRQ_PRI' undeclared.

CLOSED JIRA items within last 24 hours: 1
B [ZEP-183] (Won't Do) [regression]PINMUX_NUM_PINS is missing in arch/x86/soc/quark_se/soc.h

RESOLVED JIRA items within last 24 hours: 0


Re: Daily JIRA Digest

Perez Hernandez, Javier B <javier.b.perez.hernandez@...>
 

Dan,

On Thu, 2016-04-07 at 00:34 +0000, Kalowsky, Daniel wrote:

-----Original Message-----
From: donotreply(a)jenkins.zephyrproject.org
[mailto:donotreply(a)jenkins.zephyrproject.org]
Sent: Wednesday, April 6, 2016 9:47 AM
To: devel(a)lists.zephyrproject.org
Subject: [devel] Daily JIRA Digest

NEW JIRA items within last 24 hours: 2
  B [ZEP-184] (P 2) QMSI 'CONFIG_RTC_IRQ_PRI' undeclared.
  B [ZEP-183] (P 3) [regression]PINMUX_NUM_PINS is missing in
arch/x86/soc/quark_se/soc.h
The fact that I'm needing a decoder key/ring for these emails is not
useful.  

What does the B before each line mean?

Not convinced the priority is needed in these emails.  It really does
nothing to add to the title except create some bizarre string
encryption.
It is the first letter of the issue type (Bug, Requirement, Story).

I will probably changed to something like:
Bug:
  [ZEP-] ...
Story
  ..




UPDATED JIRA items within last 24 hours: 2
  B [ZEP-75]  (P 1) REOPENED Zephyr compiler fails with error about
executing
cc1
  B [ZEP-7]   (P 3) REOPENED Arduino 101 GPIO_INT_LEVEL not working
as
expected

CLOSED JIRA items within last 24 hours: 3
  B [ZEP-174] (Fixed) Hello_world app build fail with  error:
'PINMUX_BASE_ADDR' undeclared when
PINMUX_DEV,PINMUX_DEV_QUARK_MCU were enabled
  B [ZEP-161] (Won't Do) Nothing output when run hello_world app
with x86
SDK for quark platforms
  B [ZEP-151] (Fixed) QMSI AON_TIMER_IRQ and AON_TIMER_IRQ_PRI have
not been configured in quark_se_devboard
Why is the closed status being inserted here?   Anyone interested in
that can and should go look at the JIRA.



RESOLVED JIRA items within last 24 hours: 0


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/1278 : sensor: fix coding style (bmc150 and lsm9ds0)
- https://gerrit.zephyrproject.org/r/1280 : Bluetooth: BR/EDR: Get proper L2CAP CID limits
- https://gerrit.zephyrproject.org/r/1279 : Bluetooth: BR/EDR: Increase L2CAP signal channel pool
- https://gerrit.zephyrproject.org/r/1281 : Bluetooth: BR/EDR: Make available L2CAP signal channel
- https://gerrit.zephyrproject.org/r/1273 : spi: intel: fix port 1 pin setup

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/1232 : kernel: Make idle task sleep
- https://gerrit.zephyrproject.org/r/1271 : sensors: Using new GPIO API callbacks
- https://gerrit.zephyrproject.org/r/914 : gpio: Improve the public API to handle multi callbacks
- https://gerrit.zephyrproject.org/r/1190 : drivers: Renaming directory "802.15.4" into "ieee802154"
- https://gerrit.zephyrproject.org/r/804 : ieee802154: Replace the CC2520 driver with a new implementation
- https://gerrit.zephyrproject.org/r/1226 : sys_clock: Add a helper to compute micro seconds
- https://gerrit.zephyrproject.org/r/1217 : stm32: reorganise soc directory and use family/series
- https://gerrit.zephyrproject.org/r/1135 : boards: nucleo: Adding flash support
- https://gerrit.zephyrproject.org/r/1215 : stm32: rename SOC_STM32F1X -> SOC_SERIES_STM32F1X
- https://gerrit.zephyrproject.org/r/1214 : stm32: rename CONFIG_SOC_STM32 -> CONFIG_SOC_FAMILY_STM32
- https://gerrit.zephyrproject.org/r/1216 : kinetis: reorganise soc directory using soc family
- https://gerrit.zephyrproject.org/r/1219 : soc: introduce SoC families and series
- https://gerrit.zephyrproject.org/r/1221 : new SoC naming convention
- https://gerrit.zephyrproject.org/r/1255 : relocate_sdk.patch: Fix file sections overwrites

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/1277 : Bluetooth: Fix not using endianess helper in LE L2CAP conn req
- https://gerrit.zephyrproject.org/r/1276 : Bluetooth: Fix BLUETOOTH_NRF51_PM Kconfig definition
- https://gerrit.zephyrproject.org/r/1275 : sanitycheck: fix initlevel section being mentioned twice
- https://gerrit.zephyrproject.org/r/1274 : rtc/qmsi: Fix the IRQ priority setting according to the SoC specific option
- https://gerrit.zephyrproject.org/r/1272 : sensors: fix coding style regarding max line length
- https://gerrit.zephyrproject.org/r/1254 : ethernet/dw: remove kconfigs that are SoC specific
- https://gerrit.zephyrproject.org/r/1270 : Bluetooth: tester: Use bt enable cb to indicate cmd rsp success
- https://gerrit.zephyrproject.org/r/1253 : job: jira: change recipient email


Re: nRF52 port for Zephyr

Xue Liu
 

Hello Johan Hedberg,

Thank you for your info.


2016-04-07 12:47 GMT+02:00 Johan Hedberg <johan.hedberg(a)intel.com>:

Hi Xue Liu,

On Wed, Apr 06, 2016, Xue Liu wrote:
Now I am working on the port of nRF52 DK board for Zephyr project. I have
several questions about the procedures of port.

1. I use nRF5x SDK v11.0 as a start point. This SDK dependence on CMSIS.
Since currently there is no CMSIS in the Zephyr, should I rewrite the
register and bitfields definitions or just copy these files from nRF52
SDK
to the Zephyr ?
2. From the technical review
https://www.zephyrproject.org/sites/local-zephyr/files/zephyr_project_technical_overview.pdf
.
The Zephyr project will support CMSIS. But until now there is no source
code or support of CMSIS. Is it right ?
3. Could someone gives me some suggestions or guide to port a new SOC to
the Zephyr.
Have you taken a look at how MyNewt has implemented support for the
nRF52? It's one of their supported platforms. IIRC they have copies of
the nRF5x SDK header files in their source tree.
Yes. I have seen the soc source code of nr52. But nRF5x SDK depends on
header files from CMSIS.
Maybe I should go on porting with CMSIS in the "lib" like MyNewt done, and
wait for the official CMSIS support in Zephyr.


Johan
Regards,

Xue Liu



--


Re: nRF52 port for Zephyr

Xue Liu
 

Hello Daniel,

Thank you for your feedback

2016-04-07 2:30 GMT+02:00 Kalowsky, Daniel <daniel.kalowsky(a)intel.com>:

Xue,

-----Original Message-----
From: Xue Liu [mailto:liuxuenetmail(a)gmail.com]
Sent: Wednesday, April 6, 2016 2:27 PM
To: devel(a)lists.zephyrproject.org
Subject: [devel] nRF52 port for Zephyr

Hello,

Now I am working on the port of nRF52 DK board for Zephyr project. I have
several questions about the procedures of port.

1. I use nRF5x SDK v11.0 as a start point. This SDK dependence on CMSIS.
Since currently there is no CMSIS in the Zephyr, should I rewrite the
register
and bitfields definitions or just copy these files from nRF52 SDK to the
Zephyr
?
Can you provide a bit more detail about the options you're trying?
Now I chose the way of copying header files from nrf52 SDK and some macros
of CMSIS, such as __I, __O and __IO.


2. From the technical review https://www.zephyrproject.org/sites/local-
zephyr/files/zephyr_project_technical_overview.pdf. The Zephyr project
will support CMSIS. But until now there is no source code or support of
CMSIS. Is it right ?
There is work being done for this. It's one of the many pieces currently
being executed.
I am really looking forwarding the merge to the master. That will be much
easier for me to port nrf52.


3. Could someone gives me some suggestions or guide to port a new SOC to
the Zephyr.
I'd encourage you to look at the arch/ directory for samples of how to
model the SOC.
Yes. I have seen the soc of FRDM-K64F and stm32. They use unique
definitions of register and bit field.

Regards,

Xue Liu

--


Re: nRF52 port for Zephyr

Johan Hedberg
 

Hi Xue Liu,

On Wed, Apr 06, 2016, Xue Liu wrote:
Now I am working on the port of nRF52 DK board for Zephyr project. I have
several questions about the procedures of port.

1. I use nRF5x SDK v11.0 as a start point. This SDK dependence on CMSIS.
Since currently there is no CMSIS in the Zephyr, should I rewrite the
register and bitfields definitions or just copy these files from nRF52 SDK
to the Zephyr ?
2. From the technical review
https://www.zephyrproject.org/sites/local-zephyr/files/zephyr_project_technical_overview.pdf.
The Zephyr project will support CMSIS. But until now there is no source
code or support of CMSIS. Is it right ?
3. Could someone gives me some suggestions or guide to port a new SOC to
the Zephyr.
Have you taken a look at how MyNewt has implemented support for the
nRF52? It's one of their supported platforms. IIRC they have copies of
the nRF5x SDK header files in their source tree.

Johan


Re: Daily JIRA Digest

Kalowsky, Daniel <daniel.kalowsky@...>
 

-----Original Message-----
From: donotreply(a)jenkins.zephyrproject.org
[mailto:donotreply(a)jenkins.zephyrproject.org]
Sent: Wednesday, April 6, 2016 9:47 AM
To: devel(a)lists.zephyrproject.org
Subject: [devel] Daily JIRA Digest

NEW JIRA items within last 24 hours: 2
B [ZEP-184] (P 2) QMSI 'CONFIG_RTC_IRQ_PRI' undeclared.
B [ZEP-183] (P 3) [regression]PINMUX_NUM_PINS is missing in
arch/x86/soc/quark_se/soc.h
The fact that I'm needing a decoder key/ring for these emails is not useful.

What does the B before each line mean?

Not convinced the priority is needed in these emails. It really does nothing to add to the title except create some bizarre string encryption.


UPDATED JIRA items within last 24 hours: 2
B [ZEP-75] (P 1) REOPENED Zephyr compiler fails with error about executing
cc1
B [ZEP-7] (P 3) REOPENED Arduino 101 GPIO_INT_LEVEL not working as
expected

CLOSED JIRA items within last 24 hours: 3
B [ZEP-174] (Fixed) Hello_world app build fail with error:
'PINMUX_BASE_ADDR' undeclared when
PINMUX_DEV,PINMUX_DEV_QUARK_MCU were enabled
B [ZEP-161] (Won't Do) Nothing output when run hello_world app with x86
SDK for quark platforms
B [ZEP-151] (Fixed) QMSI AON_TIMER_IRQ and AON_TIMER_IRQ_PRI have
not been configured in quark_se_devboard
Why is the closed status being inserted here? Anyone interested in that can and should go look at the JIRA.


RESOLVED JIRA items within last 24 hours: 0


Re: nRF52 port for Zephyr

Kalowsky, Daniel <daniel.kalowsky@...>
 

Xue,

-----Original Message-----
From: Xue Liu [mailto:liuxuenetmail(a)gmail.com]
Sent: Wednesday, April 6, 2016 2:27 PM
To: devel(a)lists.zephyrproject.org
Subject: [devel] nRF52 port for Zephyr

Hello,

Now I am working on the port of nRF52 DK board for Zephyr project. I have
several questions about the procedures of port.

1. I use nRF5x SDK v11.0 as a start point. This SDK dependence on CMSIS.
Since currently there is no CMSIS in the Zephyr, should I rewrite the register
and bitfields definitions or just copy these files from nRF52 SDK to the Zephyr
?
Can you provide a bit more detail about the options you're trying?

2. From the technical review https://www.zephyrproject.org/sites/local-
zephyr/files/zephyr_project_technical_overview.pdf. The Zephyr project
will support CMSIS. But until now there is no source code or support of
CMSIS. Is it right ?
There is work being done for this. It's one of the many pieces currently being executed.

3. Could someone gives me some suggestions or guide to port a new SOC to
the Zephyr.
I'd encourage you to look at the arch/ directory for samples of how to model the SOC.


Re: state of development and participation

Kalowsky, Daniel <daniel.kalowsky@...>
 

-----Original Message-----
From: Idupsle [mailto:idupsle(a)gmail.com]
Sent: Wednesday, April 6, 2016 8:50 AM
To: devel(a)lists.zephyrproject.org
Subject: [devel] state of development and participation

Hello,

I'm still wondering about this project. Is it right, that most work is
from intel? I was hoping, that NXP is continuing it's work on it - or
was it only for the early- support?
Having just spent the last few days with NXP at Open IoT / Embedded Linux Conference, I can say that they are still active on the project. I will let the member of NXP on the mailing list share their own thoughts about this.

Otherwise I'd like start to develop a little more for my K64, but
looking at those amount of daily changes, especially at the core api -
is it wiser to wait a few months? I really would like to contribute a
litte bit in my sparse spare time to get this board a little bit more
usable :)
I'd encourage you to submit such patches. The APIs should no longer be bouncing around. If they are, please call us out on when it is happening.


nRF52 port for Zephyr

Xue Liu
 

Hello,

Now I am working on the port of nRF52 DK board for Zephyr project. I have
several questions about the procedures of port.

1. I use nRF5x SDK v11.0 as a start point. This SDK dependence on CMSIS.
Since currently there is no CMSIS in the Zephyr, should I rewrite the
register and bitfields definitions or just copy these files from nRF52 SDK
to the Zephyr ?
2. From the technical review
https://www.zephyrproject.org/sites/local-zephyr/files/zephyr_project_technical_overview.pdf.
The Zephyr project will support CMSIS. But until now there is no source
code or support of CMSIS. Is it right ?
3. Could someone gives me some suggestions or guide to port a new SOC to
the Zephyr.

Thank you for your help.

Regards,

Xue Liu

--


Re: [RFC] Device: device_get_binding() returns NULL if device fails initialization

Daniel Leung <daniel.leung@...>
 

On Wed, Apr 06, 2016 at 02:02:17PM +0000, Kalowsky, Daniel wrote:
-----Original Message-----
From: Tomasz Bursztyka [mailto:tomasz.bursztyka(a)linux.intel.com]
Sent: Wednesday, April 6, 2016 12:00 AM
To: devel(a)lists.zephyrproject.org
Subject: [devel] Re: [RFC] Device: device_get_binding() returns NULL if
device fails initialization

Hi Daniel,

That's actually a good point.

And that reminds me, that most of our drivers do not set driver API to
NULL if they fail.
But they do return an explicit code which no one care about:
see _sys_device_do_config_level() in kernel/nanokernel/device.c

I think there you can add also a tiny test:

if (device->init(info) < 0) {
info->driver_api = NULL;
}
Good point Tomasz. Might need to be part of the RFC patch that Daniel posted.
The original discussion was actually started about getting rid of returns of
initialization functions. The idea was that the kernel could not really do
anything when a driver failed initialization, so why not getting rid of returns
to save a few bytes. The burden of determining whether it is a critical error
during init is up to the driver. If there is a critical error, the driver
should assert (and setting driver_api to NULL).

There are situations where there are non-critical erros during initialization.
For example, the I2C driver, failure to set default configuration is not
critical. As long as the developer sets it later, the driver can still function.
However, with the above code, this non-critical error will cause driver_api
to be NULL, which prevents its usage at all. The driver writer should know
whether an error prevents the device from functioning at all. So it should be
up to driver writer to set driver_api to NULL. One can argue that a non-critical
error should not return anything other than 0. But then it is not passing on
the information that there is a non-critical error (though the kernel does not
really care).

(actually, naming in this function should be reversed: struct device
should be "device" and
struct device_config should be "info" or "config", even better. But I am
diverging from subject)

It's better to let device.c doing it, instead of making sure all driver
behaves well on that aspect.
As long as they return a relevant status, it will be fine.
Correct. If the OS is going to depend upon a feature/function being set to
indicate a specific status, the OS should be doing this not the device driver.
Although it doesn't hurt if the device driver does it as well :-)
(see above.)


Tomasz

Problem Statement:
Currently, there is no way to know if a driver fails initialization.

Problem Description:
Zephyr currently does not provide a way to check programmatically
whether a device can be used. The device_get_binding() always
returns a valid device struct (if such device driver instance
exists). This causes a bit of headache when debugging apps as
the developer assumes the devices are ready to be used.

Solution:
The solution was actually proposed in [1] a while ago. The idea
is to piggy-back onto driver_api pointer. If the pointer is NULL,
the device driver has failed in its own initialization function.
The driver_api is set to NULL (or in other words, never set to
the actual API struct). When device_get_binding() sess that
the driver_api is NULL for a particular device struct, it returns
NULL to the caller, and thus preventing its use in the app.
Since this is a binary state, instead of creating another variable
inside device struct, this uses driver_api to avoid unnecessarily
enlarging the ROM size. Since this is a simple change, a patch
has been created in [2].

[1]
https://lists.zephyrproject.org/archives/list/devel(a)lists.zephyrproject.org/
message/MZB5PYBSRHV3NIEHJYXYQVLTPFIIHPB3/
[2] https://gerrit.zephyrproject.org/r/1261


----------
Daniel Leung


Daily JIRA Digest

donotreply@...
 

NEW JIRA items within last 24 hours: 2
B [ZEP-184] (P 2) QMSI 'CONFIG_RTC_IRQ_PRI' undeclared.
B [ZEP-183] (P 3) [regression]PINMUX_NUM_PINS is missing in arch/x86/soc/quark_se/soc.h

UPDATED JIRA items within last 24 hours: 2
B [ZEP-75] (P 1) REOPENED Zephyr compiler fails with error about executing cc1
B [ZEP-7] (P 3) REOPENED Arduino 101 GPIO_INT_LEVEL not working as expected

CLOSED JIRA items within last 24 hours: 3
B [ZEP-174] (Fixed) Hello_world app build fail with error: 'PINMUX_BASE_ADDR' undeclared when PINMUX_DEV,PINMUX_DEV_QUARK_MCU were enabled
B [ZEP-161] (Won't Do) Nothing output when run hello_world app with x86 SDK for quark platforms
B [ZEP-151] (Fixed) QMSI AON_TIMER_IRQ and AON_TIMER_IRQ_PRI have not been configured in quark_se_devboard

RESOLVED JIRA items within last 24 hours: 0


Re: Daily Gerrit Digest

Perez Hernandez, Javier B <javier.b.perez.hernandez@...>
 

Dan,


On Wed, 2016-04-06 at 06:44 +0000, Kalowsky, Daniel wrote:
While I like getting these emails, any reason why I've received 3
different copies today, and at that they all seem to have different
data in them?
You should only see 1 everyday.
The scripts runs everyday at around 8am PST.

Regards

Javier B. Perez



-----Original Message-----
From: donotreply(a)jenkins.zephyrproject.org
[mailto:donotreply(a)jenkins.zephyrproject.org]
Sent: Tuesday, April 5, 2016 8:12 AM
To: devel(a)lists.zephyrproject.org
Subject: [devel] Daily Gerrit Digest

NEW within last 24 hours:
 - https://gerrit.zephyrproject.org/r/1230  : test:
kernel/test_timer/nanokernel increase timeout.
 - https://gerrit.zephyrproject.org/r/1251  : sensor: make runtime
configurable attrs continuous
 - https://gerrit.zephyrproject.org/r/1250  : samples: revert to
default
CFLAGS
 - https://gerrit.zephyrproject.org/r/1247  : Bluetooth: Enable
Nordic BLE chip
with compatible firmware
 - https://gerrit.zephyrproject.org/r/1246  : quark_se_devboard:
Move UART
default name from soc to board
 - https://gerrit.zephyrproject.org/r/1248  : Bluetooth/shell: Add
configuration for Nordic BLE with HCI
 - https://gerrit.zephyrproject.org/r/1245  : Bluetooth: Add option
for Nordic
BLE with HCI firmware
 - https://gerrit.zephyrproject.org/r/1235  : hosttools-tarball.bb:
Integrate
Python 3 into SDK
 - https://gerrit.zephyrproject.org/r/1231  : test
 - https://gerrit.zephyrproject.org/r/1232  : kernel: Make idle
task sleep

UPDATED within last 24 hours:
 - https://gerrit.zephyrproject.org/r/1199  : drivers/nble: Add
support for attr
iteration functions
 - https://gerrit.zephyrproject.org/r/1201  : Bluetooth: tester:
Add support
for seqence gatt database
 - https://gerrit.zephyrproject.org/r/1202  : Bluetooth: tester:
Return pre
defined db offset on start server
 - https://gerrit.zephyrproject.org/r/1200  : Bluetooth: tester:
Update server
commands with sequence params
 - https://gerrit.zephyrproject.org/r/804   : ieee802154: Replace
the CC2520
driver with a new implementation
 - https://gerrit.zephyrproject.org/r/1226  : sys_clock: Add a
helper to
compute micro seconds
 - https://gerrit.zephyrproject.org/r/1190  : drivers: Renaming
directory
"802.15.4" into "ieee802154"
 - https://gerrit.zephyrproject.org/r/1161  : doc: Add sensor
section in API
documentation
 - https://gerrit.zephyrproject.org/r/1228  : sensor: lsm9ds0-gyro:
fix
FULL_SCALE attribute
 - https://gerrit.zephyrproject.org/r/1162  : doc: Add sensor
section to kernel
primer
 - https://gerrit.zephyrproject.org/r/1217  : stm32: reorganise soc
directory
and use family/series
 - https://gerrit.zephyrproject.org/r/1219  : soc: introduce SoC
families and
series
 - https://gerrit.zephyrproject.org/r/1215  : stm32: rename
SOC_STM32F1X -

SOC_SERIES_STM32F1X
 - https://gerrit.zephyrproject.org/r/1214  : stm32: rename
CONFIG_SOC_STM32 -> CONFIG_SOC_FAMILY_STM32
 - https://gerrit.zephyrproject.org/r/1227  : doc: Editing notices
page to be
more concise and relevant to Zephyr
 - https://gerrit.zephyrproject.org/r/1193  : tests:
test_early_sleep: Let's test
at all initialization level
 - https://gerrit.zephyrproject.org/r/1093  : doc: index config
variable only
once
 - https://gerrit.zephyrproject.org/r/992   : Bluetooth: BR/EDR:
Refactor
internals of 'Cancel' authentication API
 - https://gerrit.zephyrproject.org/r/1123  : Bluetooth: BR/EDR:
Rename pair
method field
 - https://gerrit.zephyrproject.org/r/1055  : Bluetooth: shell: Use
same config
for arm and x86 build
 - https://gerrit.zephyrproject.org/r/1205  : gcc-4.sc.iamcu.inc:
Enable LTO
 - https://gerrit.zephyrproject.org/r/1194  : samples: add
environmental
sensing sample for Arduino 101

MERGED within last 24 hours:
 - https://gerrit.zephyrproject.org/r/1234  : gerrit digest: rename
subject of
email for gerrit changes.
 - https://gerrit.zephyrproject.org/r/1233  : step: doc: use
website template
only on daily and tag build
 - https://gerrit.zephyrproject.org/r/1249  : drivers/nble: Move
Nordic
Bluetooth LE driver inside drivers/bluetooth
 - https://gerrit.zephyrproject.org/r/1244  : Bluetooth: Add stub
for
bt_storage_clear()
 - https://gerrit.zephyrproject.org/r/1240  : Bluetooth: Don't
update random
address unnecessarily
 - https://gerrit.zephyrproject.org/r/1238  : Bluetooth: Add
Privacy Feature
support
 - https://gerrit.zephyrproject.org/r/1242  : Bluetooth: Export
bt_storage
inside the stack
 - https://gerrit.zephyrproject.org/r/1239  : Bluetooth: Use
bt_addr_t inside
bt_addr_le_t
 - https://gerrit.zephyrproject.org/r/1243  : Bluetooth: Rename
bt_register_storage to bt_storage_register
 - https://gerrit.zephyrproject.org/r/1237  : Bluetooth: Introduce
SMP helper
to generate RPAs
 - https://gerrit.zephyrproject.org/r/1236  : Bluetooth: Export
is_bonded
through hci_core.c
 - https://gerrit.zephyrproject.org/r/1178  : ia32: Allow to
connect Nordic chip
to qemu
 - https://gerrit.zephyrproject.org/r/1224  : drivers/nble: Update
RPC to
Nordic firmware 0404 version
 - https://gerrit.zephyrproject.org/r/996   : quark_se_devboard:
Configure
UART0 for quark_se_devboard
 - https://gerrit.zephyrproject.org/r/1177  : drivers/nble:
Refactor Nordic BLE
chip enable functions
 - https://gerrit.zephyrproject.org/r/1225  : drivers/nble: Fix
typo in
compatible_firmware name
 - https://gerrit.zephyrproject.org/r/995   : quark_se_devboard:
Enable NBLE
for quark_se_devboard in Kconfig
 - https://gerrit.zephyrproject.org/r/1130  : drivers/nble:
Implement GATT
read Characteristic Presentation Format
 - https://gerrit.zephyrproject.org/r/1129  : samples/nble: Remove
default
driver debug for samples
 - https://gerrit.zephyrproject.org/r/1210  : Bluetooth: Add
support for
reading local address from storage
 - https://gerrit.zephyrproject.org/r/1209  : Bluetooth: Add
skeleton for
persistent storage API


state of development and participation

Idupsle <idupsle@...>
 

Hello,

I'm still wondering about this project. Is it right, that most work is
from intel? I was hoping, that NXP is continuing it's work on it - or
was it only for the early- support?
Otherwise I'd like start to develop a little more for my K64, but
looking at those amount of daily changes, especially at the core api -
is it wiser to wait a few months? I really would like to contribute a
litte bit in my sparse spare time to get this board a little bit more
usable :)

Idups

7741 - 7760 of 8194