Date   

Re: Suggestions for getting started

Abhinav Misra
 

Hi Kumar,

Waiting for your response !!

Thanks,
Abhinav

On Thu, Jan 19, 2017 at 11:33 PM, Abhinav Misra <abhitheextremeeng(a)gmail.com
wrote:
Hi Kumar,

I have STM32F407VG board.
Interest in developing the drivers.But can start with anything.
Worked on i2c and spi drivers.Developed code for userspace drivers for
both.
Currently working on bluetooth. Implemented few profiles using some vendor
stack.

Any kind of related stuff would be fine.

Regards,
Abhinav
.


On Thu, Jan 19, 2017 at 9:12 AM, Kumar Gala <kumar.gala(a)linaro.org> wrote:


On Jan 18, 2017, at 12:29 PM, Abhinav Misra <
abhitheextremeeng(a)gmail.com> wrote:

Hi All,

Hope everybody is doing well.

I recently joined the zephyr devel mailing list and going through the
documentation and other starters stuffs as being new to open source
development.

I want to contribute to the project.Please suggest me some ways how to
get started and on to which things to focus on.

I have following boards - :
1. Beagle bone black
2. STM32 discovery board
3. TI's MSP432

Any type of suggestion and help would be much appreciated.

Regards,
Abhinav
Which STM32 discovery board do you have, this is possibly the best
starting point to try and get zephyr up and running.

What kinda of work or code have you developed in the past? Any
particular area of interest?

- k


Re: uint32_t typedef differences causes issues

Marcus Shawcroft <marcus.shawcroft@...>
 

How easily can we feed different -W options to the /ext part of the
tree, or is that painful ?

Cheers
/Marcus


Re: uint32_t typedef differences causes issues

Boie, Andrew P
 

From the error printout, my first conclusion is that there is a bug in
newlib, not the other way around.


Cheers,

Patrik
We could also always turn off -Wformat.
I turned on -Wformat, and fixed a great deal of malfeasance across the codebase. I would be strongly opposed to disabling this warning.

It's a warning. The code still compiles for end users. We only force -Werror for sanitycheck runs. Surely we can keep our internal house in order...


Re: uint32_t typedef differences causes issues

Daniel Thompson <daniel.thompson@...>
 

On 20/01/17 13:37, Patrik Flykt wrote:
On Fri, 2017-01-20 at 06:21 -0500, Anas Nashif wrote:
the question is if we want to enforce usage of PRI macros.
The de facto standard is unfortunately that %d and %u print integers up
to and including an uint32_t. Enforcing these to be expressed as PRIu32
in Zephyr will be less portable for external and internal developers.

From the error printout, my first conclusion is that there is a bug in
newlib, not the other way around.
I don't think there's anything wrong with newlib. The only requirement
on the C library is that uint32_t is 32-bits wide (i.e. no padding) and
the newlib implementation meets this requirement.

Zephyr itself can use PRIu32 internally both to avoid warnings and to
be maximally portable (i.e. conforming to C99).

In order to support applications and libraries that do not wish to
become portable then I guess it needs to be possible to interfere with
compiler options for application code in a clean manner. I'm not
entirely clear if that is already the case or not.

Note that JerryScript needs to disable some of the warning options in
order to build. However it is compiled using the environment export code
rather than the application build system (making it easy for it to mess
about with the compiler options).


Daniel.


Re: [tsc] Re: why zephyer os did not support RR-Schedule policy between same priority task?

Nashif, Anas
 

Moving this to the devel@ mailing list.

The relevant jira: https://jira.zephyrproject.org/browse/ZEP-948

Anas

-----Original Message-----
From: Benjamin Walsh [mailto:benjamin.walsh(a)windriver.com]
Sent: Friday, January 20, 2017 11:31 AM
To: 曹子龙 <13824125580(a)163.com>
Cc: Nashif, Anas <anas.nashif(a)intel.com>; tsc(a)lists.zephyrproject.org
Subject: Re: [tsc] Re: why zephyer os did not support RR-Schedule policy between same priority task?

i review the zephyr os core code about the schedule policy, and i
am not sure if it is right about what i said next, i found that
zephyr not support the the Round-Robin schedule policy which many
rtos adopted between two or more identical prio tasks, so i
thinks this may bring some trouble for application user ,because
they must know when and where to yield the cpu to another task
with same priority because the scheduler cant do that, am i right ?

appreciate your kindly help for my puzzle. :)
Look at

https://www.zephyrproject.org/doc/introduction/introducing_zephyr.ht
ml

round robin is supported already with the following option:

config TIMESLICING
bool "Thread time slicing"
default y
depends on SYS_CLOCK_EXISTS && (NUM_PREEMPT_PRIORITIES != 0)
help
This option enables time slicing between preemptible threads of
equal priority.
but seems that the RR policy zephyr used, the time slice is
applied to the scheduler not each thread, is it? because i did
not see the time-slice member in the thread TCB block. and the
"_time_slice_duration" object is global but not thread private, am i
right?

so the scheduler would be not thread evenly but force to schedule
without thought that whether it is the "current" thread cost up all
the time slice? because two thread with equal priority may release
cpu by volute yield operation, am i right?
That is correct: the time slicing is very coarse, and can be very unfair, depending when in the time slice the highest priority ready in the system changes. A thread can be preempted before it can execute a full time slice.

I personally don't like this policy. Changing it is one of the improvements that could be made to the kernel.

and ,by the way, did the zephyr has the plan to add the MMU support in
the future?
There have been some talks about this, and is something that will probably happen at some point. No plans yet though.

Cheers,
Ben

--
Benjamin Walsh, SMTS
WR VxWorks Virtualization Profile
www.windriver.com
Zephyr kernel maintainer
www.zephyrproject.org


Re: uint32_t typedef differences causes issues

Anas Nashif
 

On Fri, Jan 20, 2017 at 11:12 AM, Kumar Gala <kumar.gala(a)linaro.org> wrote:


On Jan 20, 2017, at 7:37 AM, Patrik Flykt <Patrik.Flykt(a)linux.intel.com>
wrote:

On Fri, 2017-01-20 at 06:21 -0500, Anas Nashif wrote:
the question is if we want to enforce usage of PRI macros.
The de facto standard is unfortunately that %d and %u print integers up
to and including an uint32_t. Enforcing these to be expressed as PRIu32
in Zephyr will be less portable for external and internal developers.

From the error printout, my first conclusion is that there is a bug in
newlib, not the other way around.


Cheers,

Patrik
We could also always turn off -Wformat.
Any secure coding guideline will tell you to enable this in addition to
other options (-Wformat -Wformat-security -Werror=format-security), we are
working on such a guideline right now, so my assumption it will be there as
well.

Anas



- k


Re: uint32_t typedef differences causes issues

Maciek Borzecki <maciek.borzecki@...>
 

On Fri, Jan 20, 2017 at 5:16 PM, David Brown <david.brown(a)linaro.org> wrote:
On Fri, Jan 20, 2017 at 10:12:36AM -0600, Kumar Gala wrote:

We could also always turn off -Wformat.

I think it'd be better to fix things like this. Although it sometimes
has problems, -Wformat also catches a lot of things that are indeed
wrong.
If i recall correctly -Wformat also affects scanf() checks. It would
be bad to leave these calls unchecked.

It isn't always going to be possible to make it right, since
gcc is expecting a full printf rather than our limited printk, but it
should still catch gross size mismatches.


--
Maciek Borzecki


Re: uint32_t typedef differences causes issues

David Brown
 

On Fri, Jan 20, 2017 at 10:12:36AM -0600, Kumar Gala wrote:

We could also always turn off -Wformat.
I think it'd be better to fix things like this. Although it sometimes
has problems, -Wformat also catches a lot of things that are indeed
wrong. It isn't always going to be possible to make it right, since
gcc is expecting a full printf rather than our limited printk, but it
should still catch gross size mismatches.

David


Re: uint32_t typedef differences causes issues

Kumar Gala
 

On Jan 20, 2017, at 7:37 AM, Patrik Flykt <Patrik.Flykt(a)linux.intel.com> wrote:

On Fri, 2017-01-20 at 06:21 -0500, Anas Nashif wrote:
the question is if we want to enforce usage of PRI macros.
The de facto standard is unfortunately that %d and %u print integers up
to and including an uint32_t. Enforcing these to be expressed as PRIu32
in Zephyr will be less portable for external and internal developers.

From the error printout, my first conclusion is that there is a bug in
newlib, not the other way around.


Cheers,

Patrik
We could also always turn off -Wformat.

- k


Daily JIRA Digest

donotreply@...
 

NEW JIRA items within last 24 hours: 2
[ZEP-1599] printk() support for the '-' indicator in format string (left justifier)
https://jira.zephyrproject.org/browse/ZEP-1599

[ZEP-1600] Quark Se doesn't come out of deep sleep
https://jira.zephyrproject.org/browse/ZEP-1600


UPDATED JIRA items within last 24 hours: 49
[ZEP-807] Neighbor Discovery for IPv6
https://jira.zephyrproject.org/browse/ZEP-807

[ZEP-1457] Add SPDX Tags to Zephyr licence boilerplate
https://jira.zephyrproject.org/browse/ZEP-1457

[ZEP-826] Get IPv6 Ready approval
https://jira.zephyrproject.org/browse/ZEP-826

[ZEP-540] add APIs for asynchronous transfer callbacks
https://jira.zephyrproject.org/browse/ZEP-540

[ZEP-820] HTTP v1.1 Server Sample
https://jira.zephyrproject.org/browse/ZEP-820

[ZEP-1038] Hard real-time interrupt support
https://jira.zephyrproject.org/browse/ZEP-1038

[ZEP-1550] CI: replace zephyr-verify with run_phases from https://gerrit.zephyrproject.org/r/#/c/9762/
https://jira.zephyrproject.org/browse/ZEP-1550

[ZEP-321] Zephyr Build Management
https://jira.zephyrproject.org/browse/ZEP-321

[ZEP-1307] Plumbing the DTS configuration
https://jira.zephyrproject.org/browse/ZEP-1307

[ZEP-1304] Define device tree bindings for NXP Kinetis K64F
https://jira.zephyrproject.org/browse/ZEP-1304

[ZEP-1305] Add DTS/DTB targets to build infrastructure
https://jira.zephyrproject.org/browse/ZEP-1305

[ZEP-1306] Create DTS/DTB parser
https://jira.zephyrproject.org/browse/ZEP-1306

[ZEP-1338] Update external fs with new FATFS revision 0.12b
https://jira.zephyrproject.org/browse/ZEP-1338

[ZEP-749] TinyCrypt uses an old, unoptimized version of micro-ecc
https://jira.zephyrproject.org/browse/ZEP-749

[ZEP-1156] Document CI infrastructure and all jobs we run within the project on wiki
https://jira.zephyrproject.org/browse/ZEP-1156

[ZEP-1134] CI: record data about failed sanitycheck TCs which are rerun
https://jira.zephyrproject.org/browse/ZEP-1134

[ZEP-1167] wiki/doc: change search box to use google search
https://jira.zephyrproject.org/browse/ZEP-1167

[ZEP-1568] Replace arm cortex_m scs and scb functionality with direct CMSIS-core calls
https://jira.zephyrproject.org/browse/ZEP-1568

[ZEP-1061] Create a tool for finding out stack sizes automatically.
https://jira.zephyrproject.org/browse/ZEP-1061

[ZEP-343] uWeave
https://jira.zephyrproject.org/browse/ZEP-343

[ZEP-345] XMPP
https://jira.zephyrproject.org/browse/ZEP-345

[ZEP-1396] Add ksdk adc shim driver
https://jira.zephyrproject.org/browse/ZEP-1396

[ZEP-150] Support out-of-tree board definitions
https://jira.zephyrproject.org/browse/ZEP-150

[ZEP-1170] Thread notification kernel APIs
https://jira.zephyrproject.org/browse/ZEP-1170

[ZEP-89] Provide more generic UART APIs for read and write
https://jira.zephyrproject.org/browse/ZEP-89

[ZEP-720] Add MAX30101 heart rate sensor driver
https://jira.zephyrproject.org/browse/ZEP-720

[ZEP-1392] Add FXAS21002 gyroscope sensor driver
https://jira.zephyrproject.org/browse/ZEP-1392

[ZEP-965] Supervisory and Monitoring Task
https://jira.zephyrproject.org/browse/ZEP-965

[ZEP-1334] Add "make debug" support for QEMU-based boards
https://jira.zephyrproject.org/browse/ZEP-1334

[ZEP-1472] Support for the KW22D512 Kinetis MCU based USB Dongle
https://jira.zephyrproject.org/browse/ZEP-1472

[ZEP-1528] Provide template for multi-core applications
https://jira.zephyrproject.org/browse/ZEP-1528

[ZEP-1037] Add standard APIs for Battery Charging and Fuel Gauge Handling (Energy Management)
https://jira.zephyrproject.org/browse/ZEP-1037

[ZEP-339] Tickless Kernel
https://jira.zephyrproject.org/browse/ZEP-339

[ZEP-945] Add framework for provisioning-style device configuration
https://jira.zephyrproject.org/browse/ZEP-945

[ZEP-1492] Add Atmel SAM family GMAC Ethernet driver
https://jira.zephyrproject.org/browse/ZEP-1492

[ZEP-1171] Event group kernel APIs
https://jira.zephyrproject.org/browse/ZEP-1171

[ZEP-1500] net/mqtt: Test case for the MQTT high-level API
https://jira.zephyrproject.org/browse/ZEP-1500

[ZEP-1499] net/dns: Test case for DNS API
https://jira.zephyrproject.org/browse/ZEP-1499

[ZEP-1589] Define yaml descriptions for UART devices
https://jira.zephyrproject.org/browse/ZEP-1589

[ZEP-896] nRF5x Series: Add support for power and clock peripheral
https://jira.zephyrproject.org/browse/ZEP-896

[ZEP-772] CI uses guess_tags to run the ideal restricted set of test cases
https://jira.zephyrproject.org/browse/ZEP-772

[ZEP-569] SDP server implementation for Bluetooth
https://jira.zephyrproject.org/browse/ZEP-569

[ZEP-771] guess_tags: based on the diff of a change, guess test tags to run
https://jira.zephyrproject.org/browse/ZEP-771

[ZEP-1588] I2C doesn't work on Arduino 101
https://jira.zephyrproject.org/browse/ZEP-1588

[ZEP-1598] "samples/philosophers" build failed unexpectedly @quark_d2000 "section `noinit' will not fit in region `RAM'"
https://jira.zephyrproject.org/browse/ZEP-1598

[ZEP-1592] echo-server does not build with newlib
https://jira.zephyrproject.org/browse/ZEP-1592

[ZEP-1593] /scripts/sysgen should create output using SPDX licensing tag
https://jira.zephyrproject.org/browse/ZEP-1593

[ZEP-1434] menuconfig screen shots show nanokernel options
https://jira.zephyrproject.org/browse/ZEP-1434

[ZEP-1086] yaip: Cryptic debug messages
https://jira.zephyrproject.org/browse/ZEP-1086


CLOSED JIRA items within last 24 hours: 8
[ZEP-793] (Fixed) DNS Resolver
https://jira.zephyrproject.org/browse/ZEP-793

[ZEP-801] (Fixed) DNS Extensions to support IPv6
https://jira.zephyrproject.org/browse/ZEP-801

[ZEP-796] (Fixed) DHCPv4
https://jira.zephyrproject.org/browse/ZEP-796

[ZEP-519] (Duplicate) ARM float should support lazy context saves
https://jira.zephyrproject.org/browse/ZEP-519

[ZEP-1352] (Won't Do) FDRM k64f SPI code needs cleanup
https://jira.zephyrproject.org/browse/ZEP-1352

[ZEP-1590] (Fixed) echo_server run on FRDM-K64F displays BUS FAULT
https://jira.zephyrproject.org/browse/ZEP-1590

[ZEP-1579] (Fixed) external links to zephyr technical docs are broken
https://jira.zephyrproject.org/browse/ZEP-1579

[ZEP-1573] (Fixed) net/tcp: User provided data in net_context_recv is not passed to callback
https://jira.zephyrproject.org/browse/ZEP-1573


RESOLVED JIRA items within last 24 hours: 0


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/10273 : Bluetooth: L2CAP: Only set state for dynamic channels
- https://gerrit.zephyrproject.org/r/10272 : Merge net branch into master
- https://gerrit.zephyrproject.org/r/10271 : gpio: serial: Fix NXP copyright
- https://gerrit.zephyrproject.org/r/10270 : wpan_serial: Queue only full packet to RX queue
- https://gerrit.zephyrproject.org/r/10266 : Bluetooth: Move Bluetooth docs to rst
- https://gerrit.zephyrproject.org/r/10249 : samples/coaps_server CoAP over DTLS server example app using mbedTLS
- https://gerrit.zephyrproject.org/r/10261 : Disable automatic system updates on Ubuntu
- https://gerrit.zephyrproject.org/r/10260 : samples/net/http: Update README file
- https://gerrit.zephyrproject.org/r/10259 : samples/net/http: Add HTTP 4xx class of status code
- https://gerrit.zephyrproject.org/r/10258 : samples/net/http: Add support for multiple URLs
- https://gerrit.zephyrproject.org/r/10244 : doc: update MAINTAINERS for .rst files
- https://gerrit.zephyrproject.org/r/10257 : samples: grove: use correct i2c device driver name
- https://gerrit.zephyrproject.org/r/10242 : Add jq to baseline
- https://gerrit.zephyrproject.org/r/10243 : Add git-review to base system
- https://gerrit.zephyrproject.org/r/10239 : added preliminary version of winc1500 driver and Arrow Panther support

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/9987 : tests: Update spi driver test for mcux
- https://gerrit.zephyrproject.org/r/9989 : spi: k64: Remove the k64 spi driver
- https://gerrit.zephyrproject.org/r/9988 : samples: net: Increase spi log level
- https://gerrit.zephyrproject.org/r/9985 : spi: Introduce new mcux shim driver
- https://gerrit.zephyrproject.org/r/9986 : k64: Change the default spi driver to the mcux shim
- https://gerrit.zephyrproject.org/r/10106 : samples: net: Add DHCPv4 sample application README file
- https://gerrit.zephyrproject.org/r/9984 : spi: Add shared default configs
- https://gerrit.zephyrproject.org/r/7492 : Bluetooth: A2DP: Added Preset Structure
- https://gerrit.zephyrproject.org/r/6720 : Bluetooth: A2DP: Stream End Point Registration
- https://gerrit.zephyrproject.org/r/6719 : Bluetooth: A2DP: Stream End Point Structure
- https://gerrit.zephyrproject.org/r/10141 : tests: fix invoke k_timer_stop issue inside timeout expiry_fn
- https://gerrit.zephyrproject.org/r/10189 : Xtensa port: Added kernel arch dependent structs and functions.
- https://gerrit.zephyrproject.org/r/10188 : Xtensa port: Added Xtensa header generic files.
- https://gerrit.zephyrproject.org/r/10183 : irq: introduce 'direct' interrupt API definition
- https://gerrit.zephyrproject.org/r/7104 : drivers: spi: Add nRF5 SPI slave driver
- https://gerrit.zephyrproject.org/r/10084 : net: buf: Introduce net_buf_save/restore APIs
- https://gerrit.zephyrproject.org/r/10093 : samples/net/http: Add the server sample application
- https://gerrit.zephyrproject.org/r/10132 : samples/zoap_server: Also listen on the unicast address
- https://gerrit.zephyrproject.org/r/10212 : net/ip: Do not modify the address for failure cases
- https://gerrit.zephyrproject.org/r/9711 : Bluetooth: SDP: Get ProtocolDescriptorList attrbute internals
- https://gerrit.zephyrproject.org/r/10190 : samples/net/http: Move http write functionality to its own files
- https://gerrit.zephyrproject.org/r/10220 : samples/net/http: Modify data pool size
- https://gerrit.zephyrproject.org/r/10178 : samples/net/http: Introduce routines to handle multiple contexts
- https://gerrit.zephyrproject.org/r/10218 : samples/net/http: Increase the max number of network contexts
- https://gerrit.zephyrproject.org/r/10224 : arm: cortex-m: Implement CONFIG_TEXT_SECTION_OFFSET
- https://gerrit.zephyrproject.org/r/9710 : Bluetooth: shell: Add SDP client support
- https://gerrit.zephyrproject.org/r/9712 : Bluetooth: shell: Add getting ProtocolDescriptorList attribute
- https://gerrit.zephyrproject.org/r/9709 : Bluetooth: SDP: Add API to extract Attribute Value
- https://gerrit.zephyrproject.org/r/9356 : quark_se: PM: Add multicore support
- https://gerrit.zephyrproject.org/r/9981 : samples: spi_flash: remove an unnecessary config symbol
- https://gerrit.zephyrproject.org/r/10194 : sanity: switch sdk depending on branch
- https://gerrit.zephyrproject.org/r/5504 : dma: Introduce STM32F4x DMA driver
- https://gerrit.zephyrproject.org/r/9883 : i2c: Adds a functions set that supports 16 bit addressing.
- https://gerrit.zephyrproject.org/r/9001 : counter: cmsdk: Add Timer 0 and 1 as Timers
- https://gerrit.zephyrproject.org/r/9031 : counter: cmsdk: Add DualTimer as Counter
- https://gerrit.zephyrproject.org/r/9036 : counter: cmsdk: Add Dualtimer as a Timer
- https://gerrit.zephyrproject.org/r/9002 : board: v2m_beetle: Update defconfig
- https://gerrit.zephyrproject.org/r/9976 : net: tcp: Issue connection callback on RST
- https://gerrit.zephyrproject.org/r/8759 : samples/drivers: Add Counters example
- https://gerrit.zephyrproject.org/r/9030 : counter: cmsdk: Add clock control to TMR Counters.
- https://gerrit.zephyrproject.org/r/9000 : soc: arm: beetle: Add Timers IRQ map

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/10268 : net: echo-server: Use net_buf_frag_del() return parameter
- https://gerrit.zephyrproject.org/r/10269 : net: echo-server: Handle 0 byte received packets
- https://gerrit.zephyrproject.org/r/10267 : wpan_serial: Fix possible NULL pointer dereference
- https://gerrit.zephyrproject.org/r/10265 : net: tcp: Fix TCP states swap when accepted an incoming connection
- https://gerrit.zephyrproject.org/r/10246 : net: net_context: correct description of recv_data_wait in net_context
- https://gerrit.zephyrproject.org/r/10253 : net: tcp: move accept_cb from net_context to net_tcp
- https://gerrit.zephyrproject.org/r/10263 : Bluetooth: RFCOMM: Implement MSC Flow Control
- https://gerrit.zephyrproject.org/r/10262 : Bluetooth: RFCOMM: Fix v24_signal in MSC response
- https://gerrit.zephyrproject.org/r/10254 : drivers: gpio: stm32: fix CONFIG_SOC_SERIES_STM32F4X build break
- https://gerrit.zephyrproject.org/r/10240 : boards: arduino_101: set correct LED pin
- https://gerrit.zephyrproject.org/r/10250 : drivers: QMSI GPIO: simplify driver reentrancy code using IS_ENABLED macro
- https://gerrit.zephyrproject.org/r/10255 : drivers: QMSI WDT: simplify driver reentrancy code using IS_ENABLED macro
- https://gerrit.zephyrproject.org/r/10245 : xtensa: support 'make qemu' target
- https://gerrit.zephyrproject.org/r/10237 : license: Replace Apache boilerplate with SPDX tag
- https://gerrit.zephyrproject.org/r/10238 : doc: update MAINTAINERS for *.rst reviewers
- https://gerrit.zephyrproject.org/r/10231 : samples: sensor: fxos8700: use floating point for printing sensor values
- https://gerrit.zephyrproject.org/r/10232 : sensor: fxos8700: fix missing dependency in Kconfig
- https://gerrit.zephyrproject.org/r/9448 : tests: add threads customdata api test case with unified kernel
- https://gerrit.zephyrproject.org/r/7182 : tests: add pipe test cases which use unified kernel
- https://gerrit.zephyrproject.org/r/7034 : tests: add fifo/lifo test cases with unified kernel
- https://gerrit.zephyrproject.org/r/10236 : net: context: Add status to connect callback
- https://gerrit.zephyrproject.org/r/9461 : tests: kernel: added memory pool api test
- https://gerrit.zephyrproject.org/r/9462 : tests: kernel: added memory pool concept test
- https://gerrit.zephyrproject.org/r/9463 : tests: kernel: added memory pool configuration options test
- https://gerrit.zephyrproject.org/r/9464 : tests: kernel: added memory pool threadsafe test
- https://gerrit.zephyrproject.org/r/9331 : Bluetooth: A2DP: Adds accept state callback handlers
- https://gerrit.zephyrproject.org/r/9505 : tests: kernel: re-path mslab test
- https://gerrit.zephyrproject.org/r/9506 : tests: kernel: added memory slab api test
- https://gerrit.zephyrproject.org/r/9507 : tests: kernel: added memory slab concept test
- https://gerrit.zephyrproject.org/r/9508 : tests: kernel: added memory slab threadsafe test
- https://gerrit.zephyrproject.org/r/10225 : net: samples: Add ENC28J60 pin numbers to documentation
- https://gerrit.zephyrproject.org/r/10226 : net: samples: Print assigned address from DHCPv4 server
- https://gerrit.zephyrproject.org/r/10235 : net: nbuf: Fix debug prints in memory pool init and unref
- https://gerrit.zephyrproject.org/r/10234 : net: zperf: Add bluetooth support
- https://gerrit.zephyrproject.org/r/10233 : net: zoap-client: Add bluetooth support
- https://gerrit.zephyrproject.org/r/10142 : net: tcp: fix buffer leak in tcp_synack_received
- https://gerrit.zephyrproject.org/r/9948 : net: tcp: in tcp_establish save TCP flags for post-processing use
- https://gerrit.zephyrproject.org/r/9950 : net: tcp: handle TCP_FIN after processing any data in the buffer
- https://gerrit.zephyrproject.org/r/9951 : net: tcp: don't assume TCP_FIN buffers are NET_DROP
- https://gerrit.zephyrproject.org/r/9952 : net: tcp: if buffer is TCP_FIN increment send_ack by 1
- https://gerrit.zephyrproject.org/r/10144 : net: tcp: add timeout wait in net_context_connect
- https://gerrit.zephyrproject.org/r/10223 : build: have sysgen create SPDX license identifiers
- https://gerrit.zephyrproject.org/r/10215 : scripts: quick script to determine candidates to own Coverity issues
- https://gerrit.zephyrproject.org/r/10182 : kernel_event_logger: add additional function prototypes
- https://gerrit.zephyrproject.org/r/10181 : kernel.h: add prototype for private idle exit function
- https://gerrit.zephyrproject.org/r/10184 : gen_idt: show vector assignments in debug output
- https://gerrit.zephyrproject.org/r/9974 : Xtensa port: Added support for XCC, the Cadence Systems Inc compiler
- https://gerrit.zephyrproject.org/r/9889 : serial: k64: Remove the uart_k20 driver
- https://gerrit.zephyrproject.org/r/9886 : frdm_k64f: hexiwear_k64: Add defaults for the mcux serial driver
- https://gerrit.zephyrproject.org/r/9888 : frdm_k64f: hexiwear_k64: Remove defaults for the uart_k20 driver
- https://gerrit.zephyrproject.org/r/9887 : k64: Change the default serial driver to the mcux one
- https://gerrit.zephyrproject.org/r/9885 : serial: Introduce new mcux shim driver
- https://gerrit.zephyrproject.org/r/9701 : pinmux/stm32: default pin assignment for STM32373C-EVAL board
- https://gerrit.zephyrproject.org/r/9700 : pinmux/stm32: default pin assignment for NUCLEO-F334R8 board
- https://gerrit.zephyrproject.org/r/9896 : cc3200: Added board documentation in RST format.
- https://gerrit.zephyrproject.org/r/9699 : pinmux/stm32: default pin assignment for STM3210C-EVAL board
- https://gerrit.zephyrproject.org/r/9868 : uart/stm32: add STM32F3X support for uart
- https://gerrit.zephyrproject.org/r/9693 : pinmux/stm32: extend pinmux driver functionality to support STM32F3X series MCUs
- https://gerrit.zephyrproject.org/r/9325 : gpio/stm32: provide GPIO driver implementation for STM32F3X family
- https://gerrit.zephyrproject.org/r/7626 : flash/stm32: flash driver for STM32F3x series microcontrollers
- https://gerrit.zephyrproject.org/r/7625 : exti/stm32: add support for F334 & F373 MCUs
- https://gerrit.zephyrproject.org/r/7614 : boards: add initial support for Nucleo-64 with Soc STM32F334
- https://gerrit.zephyrproject.org/r/7623 : clock/stm32: add STM32F3X reset and clock control
- https://gerrit.zephyrproject.org/r/7613 : soc/stm32: add initial support for STM32F3X series
- https://gerrit.zephyrproject.org/r/7615 : boards: add initial support for STM32373C-EVAL with SoC STM32F373VC
- https://gerrit.zephyrproject.org/r/10172 : board: add nucleo_401re board documentation


Re: Networking-with-Qemu wiki page updated

Anas Nashif
 

Paul,

Thank you for the update.

Maybe it makes sense to move this to the source tree and have it as part of
the documentation alongside the samples. This way the information for older
versions will always be available. There will always be users of released
versions.

Anas

On Fri, Jan 20, 2017 at 8:46 AM, Paul Sokolovsky <paul.sokolovsky(a)linaro.org
wrote:
Hello,

This is just a background notice that the page
https://wiki.zephyrproject.org/view/Networking-with-Qemu , which
previously contained information for 1.6 and earlier, was updated for
the master branch status (i.e. 1.7-pre). This page is also linked from
the official docs at
https://www.zephyrproject.org/doc/samples/net/qemu_setup.html , so is
a kind of motion towards updating the docs for 1.7.

The page itself tries to provide a bit more detailed walkthru on
setting up IP networking test environment using QEMU, than the
reference Zephyr docs, and provide more hints/caveats, to make the
process easy even for Zephyr newcomers.

I also post about it at this time with the outlook that Zephyr moves
towards 1.7 freeze, and it would be really great if in 1.7 we finally
had the robustly working native IP stack. So, everyone interested is
welcome to test it using the instructions above and update
status/submit new issues at:
https://jira.zephyrproject.org/issues/?jql=project+%3D+
ZEP+AND+component+%3D+%22Networking+%2F+IP+Stack%22

--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog


Networking-with-Qemu wiki page updated

Paul Sokolovsky
 

Hello,

This is just a background notice that the page
https://wiki.zephyrproject.org/view/Networking-with-Qemu , which
previously contained information for 1.6 and earlier, was updated for
the master branch status (i.e. 1.7-pre). This page is also linked from
the official docs at
https://www.zephyrproject.org/doc/samples/net/qemu_setup.html , so is
a kind of motion towards updating the docs for 1.7.

The page itself tries to provide a bit more detailed walkthru on
setting up IP networking test environment using QEMU, than the
reference Zephyr docs, and provide more hints/caveats, to make the
process easy even for Zephyr newcomers.

I also post about it at this time with the outlook that Zephyr moves
towards 1.7 freeze, and it would be really great if in 1.7 we finally
had the robustly working native IP stack. So, everyone interested is
welcome to test it using the instructions above and update
status/submit new issues at:
https://jira.zephyrproject.org/issues/?jql=project+%3D+ZEP+AND+component+%3D+%22Networking+%2F+IP+Stack%22

--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog


Re: uint32_t typedef differences causes issues

Patrik Flykt <Patrik.Flykt@...>
 

On Fri, 2017-01-20 at 06:21 -0500, Anas Nashif wrote:
the question is if we want to enforce usage of PRI macros.
The de facto standard is unfortunately that %d and %u print integers up
to and including an uint32_t. Enforcing these to be expressed as PRIu32
in Zephyr will be less portable for external and internal developers.

From the error printout, my first conclusion is that there is a bug in
newlib, not the other way around.


Cheers,

Patrik


Re: [USB] composite device

Alexey Belyaev <BeliaevAV@...>
 

Thank you, Joseph.


Re: uint32_t typedef differences causes issues

Szymon Janc <ext.szymon.janc@...>
 

Hi,

On Fri, Jan 20, 2017 at 12:21 PM, Anas Nashif <nashif(a)gmail.com> wrote:



On Fri, Jan 20, 2017 at 5:26 AM, Marcus Shawcroft <marcus.shawcroft(a)gmail.com> wrote:

On 20 January 2017 at 04:06, Kumar Gala <kumar.gala(a)linaro.org> wrote:

As Anas said, I don’t think we can expect 3rd party software to utilize PRIu32. The fact that newlib and minimal libc different in the way the typedef (u)int32_t seems like a pointless difference for us to maintain and have to deal with a lot of pain if one switches between them.
This is not a choice between alternatives. There are two separate
decisions here:

1) Do we align minimal C with newlib in order to have consistent
breakage in /ext irrespective of the users choice between newlib and
minimal lib.

2) Do we write portable conforming code in our own tree outside of
/ext using the standards defined PRI macros.


We can do both, they are not alternatives:
- Number 2 is valuable because writing portable code leaves our
options open in the future.
- Number 1 is valuable because it will ensure consistent breakage under /ext.

Ironically, that said, not doing 1) helps with 2) because it flushes
out broken code.

But either way, whether or not we do 1) I strongly advocate that for
our own code we adopt 2).

That sounds reasonable to me. Change minimal libc to align with newlib and apply 2, the question is if we want to enforce usage of PRI macros.
A bit off topic, but could someone shed some light on why Zephyr has
support for two libc implementations?
ie Why not just always use newlib ?


--
BR
Szymon Janc


Re: uint32_t typedef differences causes issues

Anas Nashif
 

On Fri, Jan 20, 2017 at 5:26 AM, Marcus Shawcroft <
marcus.shawcroft(a)gmail.com> wrote:

On 20 January 2017 at 04:06, Kumar Gala <kumar.gala(a)linaro.org> wrote:

As Anas said, I don’t think we can expect 3rd party software to utilize
PRIu32. The fact that newlib and minimal libc different in the way the
typedef (u)int32_t seems like a pointless difference for us to maintain and
have to deal with a lot of pain if one switches between them.

This is not a choice between alternatives. There are two separate
decisions here:

1) Do we align minimal C with newlib in order to have consistent
breakage in /ext irrespective of the users choice between newlib and
minimal lib.

2) Do we write portable conforming code in our own tree outside of
/ext using the standards defined PRI macros.


We can do both, they are not alternatives:
- Number 2 is valuable because writing portable code leaves our
options open in the future.
- Number 1 is valuable because it will ensure consistent breakage under
/ext.

Ironically, that said, not doing 1) helps with 2) because it flushes
out broken code.

But either way, whether or not we do 1) I strongly advocate that for
our own code we adopt 2).
That sounds reasonable to me. Change minimal libc to align with newlib and
apply 2, the question is if we want to enforce usage of PRI macros.

Anas




Cheers
/Marcus


Re: uint32_t typedef differences causes issues

Tomasz Bursztyka
 

Hi Marcus,

On 20 January 2017 at 04:06, Kumar Gala <kumar.gala(a)linaro.org> wrote:

As Anas said, I don’t think we can expect 3rd party software to utilize PRIu32. The fact that newlib and minimal libc different in the way the typedef (u)int32_t seems like a pointless difference for us to maintain and have to deal with a lot of pain if one switches between them.
This is not a choice between alternatives. There are two separate
decisions here:

1) Do we align minimal C with newlib in order to have consistent
breakage in /ext irrespective of the users choice between newlib and
minimal lib.

2) Do we write portable conforming code in our own tree outside of
/ext using the standards defined PRI macros.


We can do both, they are not alternatives:
- Number 2 is valuable because writing portable code leaves our
options open in the future.
- Number 1 is valuable because it will ensure consistent breakage under /ext.

Ironically, that said, not doing 1) helps with 2) because it flushes
out broken code.

But either way, whether or not we do 1) I strongly advocate that for
our own code we adopt 2).
I'd rather stick with 1). User PRI for all uint32_t is going to be ugly.
I align with Johan here.

newlib has a reason to use long unsigned int as uint32_t. It ensures
that uint32_t is always 32 bits whatever the
arch newlib is ported on. unsigned int on 16bits arch, is 16 bits arch
for instance.

Tomasz


Re: uint32_t typedef differences causes issues

Marcus Shawcroft <marcus.shawcroft@...>
 

On 20 January 2017 at 04:06, Kumar Gala <kumar.gala(a)linaro.org> wrote:

As Anas said, I don’t think we can expect 3rd party software to utilize PRIu32. The fact that newlib and minimal libc different in the way the typedef (u)int32_t seems like a pointless difference for us to maintain and have to deal with a lot of pain if one switches between them.
This is not a choice between alternatives. There are two separate
decisions here:

1) Do we align minimal C with newlib in order to have consistent
breakage in /ext irrespective of the users choice between newlib and
minimal lib.

2) Do we write portable conforming code in our own tree outside of
/ext using the standards defined PRI macros.


We can do both, they are not alternatives:
- Number 2 is valuable because writing portable code leaves our
options open in the future.
- Number 1 is valuable because it will ensure consistent breakage under /ext.

Ironically, that said, not doing 1) helps with 2) because it flushes
out broken code.

But either way, whether or not we do 1) I strongly advocate that for
our own code we adopt 2).

Cheers
/Marcus


Re: [RFC]DMA API Update

Tomasz Bursztyka
 

Hi Baohong,

Very little comment on struct attributes.

Hi everyone,

Based on the feedbacks, I updated the RFC.

Data Structure Definitions
-------

/**
* @brief DMA block configuration structure.
*
* config is a bit field with the following parts:
* source_gather_en [ 0 ] --enable/disable source gather
* dest_scatter_en [ 1 ] --enable/disable destination scatter
* source_inc_en [ 2 ] --enable/disable source address increment
* dest_inc_en [ 3 ] --enable/disable destination address increment
* source_reload_en [ 4 ] --reload source address at the end of block transfer
* dest_reload_en [ 5 ] --reload destination address at the end of block transfer
* fifo_mode_control [ 6 : 9 ] --How full of the fifo before transfer start. HW specific.
* flow_control_mode [ 10 ] --source request is served when data available or
* wait until destination request happens.
* RESERVED [ 11 : 31 ]
Is there a need of that much reserved space? I am asking this because
maybe we could shrink some attributes to 16bits
like config (it would still give 5 bits left for reserved usage)

* source_address is block starting address at source
* source_gather_count is the continuous transfer count between gather boundaries
* source_gather_interval is the address adjustment at gather boundary
These 2 ones above for instance, is this necessary to put them on 32 bits?

* dest_address is block starting address at destination
* dest_scatter_count is the continuous transfer count between scatter boundaries
* dest_scatter_interval is the address adjustment at scatter boundary
Same here.

* block_size is the number of bytes to be transferred for this block.
*/
struct dma_block_config {
uint32_t config;
uint32_t source_address;
uint32_t source_gather_count;
uint32_t source_gather_interval;
uint32_t dest_address;
uint32_t dest_scatter_count;
uint32_t dest_scatter_interval;
uint32_t block_size;
struct dma_block_config *next_block;
}
I am also wondering how will we be able to use DMA efficiently in device
drivers.
They can't really use direct dma features. We will need something nicely
made, generic as possible, for
sg dma buffers, etc...

Tomasz

5501 - 5520 of 7817