Date   

Re: ELCE participation

Michael Turquette <mturquette@...>
 

Hi,

On Thu, Jun 15, 2017 at 7:57 AM, Kumar Gala <kumar.gala@...> wrote:
On 15 June 2017 at 09:08, Geoffrey LE GOURRIEREC
<geoffrey.legourrierec@...> wrote:

Hi all,

Not sure if this is the right mailing list for this, but does anybody plan
to participate at the Embedded Linux Conference Europe in Prague, this
October?

If so, what are the subject(s) about to be discussed?
For the last few years there has been an IOT track at ELCE. Not sure what
the plan is this year for that. I know a fair number of Zephyr developers
and maintainers have attended in the past.

- k
Some engineers from BayLibre will be there, as usual :-D

Best regards,
Mike


Cheers,

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


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


--
Michael Turquette
CEO
BayLibre - At the Heart of Embedded Linux
http://baylibre.com/


Re: Situation with net APIs testing

Paul Sokolovsky
 

Hello Jukka,

On Thu, 15 Jun 2017 10:46:29 +0300
Jukka Rissanen <jukka.rissanen@...> wrote:

[]

as part of sanitycheck testsuite! But, 8 tests of tests/net/ have
build_only=true, any wonder they're broken?
When we had gerrit and jenkins, some of the net tests run slightly
longer that what was desired, so they were marked as build only. Now
that situation is different with github and shippable, we can change
this. So I will prepare a patch that activates those tests that can be
activated.
That explains it, thanks.

[]

All other tests programs (24 pieces), that consists of quite many
individual tests, are run automatically by CI, so the situation is not
so bleak as you indicated here.
Great, thanks for clarifying this. Though I hope you'd agree that seeing
such tests as "context" or "tcp" fail does lead to concerns.

I will fix the relevant failing tests as they have bit rotted after
the tests were written.
Nice, thanks for finding time for this!

Converting two mqtt tests to not use real qemu
requires a bit more work.

[]

One would think that if we have 22 repetitive implementations of
test interfaces, whose main purpose is to be just loopback
interfaces,
No, the interface is not a loopback interface although it might look
like that. The purpose of the interface that is created in each of the
test is to simulate a real network so that we do not have to connect
to outside world but the test is self contained. So it kind of looks
like a loopback interface but in this case the source and destination
IP addresses are not the same (as would be the case with loopback
interface), as typically we want to test some real behavior of the
system so src/dest addresses should differ.
I see. I may imagine they offer more functionality than just a loopback
interface. I also may imagine that each of 22 test device
implementations are slightly different to cater for particular
testcases. Nothing of that help someone wanting to write a new test
unfortunately. How would one know that there's no standard device
implementation for dependency-free testing, and having figured that,
how one would choose which of 22 cases to use as a template?

The loopback support has limited use cases actually and we probably
need to make that optional (behind Kconfig option) in the code as
normally there should be no need to send anything back to itself in
the real world.
I absolutely agree that loopback device would be mostly useful for
development and testing, not for production. It also offers limited
testing indeed. But it has one big advantage: tests using it can be
easily run using existing sanitycheck framework. And if loopback
device existed in the main code, such tests would be also easy to write,
unlike now. Summing up, I'd like to give a try to implement one for the
mainline.


then
we'd have a loopback interface in the main codebase. But nope, as
confirmed by Jukka on IRC, we don't.

Summary:

1. Writing networking tests is hard, but it Zephyr, it takes
extraordinary, agonizing effort. The most annoying is that all
needed pieces are there, but instead of presenting a nice picture,
they form a mess which greets you with crashes if you try to change
anything.
I am not sure what kind of mess you mean here but patches are welcome
as always to rectify this.
Well, patches alone won't help here. Writing tests is always hard (for
various reasons, including "tests are code, so why not write 'real'
code instead?"). So, it would be nice to think how to facilitate that.
Specific proposal is to add a loopback netif, I assume it's ok, so will
go for a patch.

[]

there's
something wrong with my system, and yep, I'd be glad to know what
I'm still don't do right with Zephyr after working on it for a
year.)
Hmm, I missed the point of your last sentence.
Well, it's the same issue: various things in Zephyr are "harder than
necessary", so one can never know if something really broke or one
doesn't do all the needed things to run it successfully. It would be
nice to think of making the default config of Zephyr either run OOB, or
fail with clear error messages, not crash or lockup. That's again a big
meta-task, not something which can be "fixed with a patch", but would
be nice to see if different stakeholders of Zephyr agree that there's
an issue which needs attention.



Thanks for all the replies!

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

Kumar Gala
 

For the last few years there has been an IOT track at ELCE.  Not sure what the plan is this year for that.  I know a fair number of Zephyr developers and maintainers have attended in the past.

- k

On 15 June 2017 at 09:08, Geoffrey LE GOURRIEREC <geoffrey.legourrierec@...> wrote:
Hi all,

Not sure if this is the right mailing list for this, but does anybody plan
to participate at the Embedded Linux Conference Europe in Prague, this October?

If so, what are the subject(s) about to be discussed?

Cheers,

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


ELCE participation

Geoffrey LE GOURRIEREC <geoffrey.legourrierec@...>
 

Hi all,

Not sure if this is the right mailing list for this, but does anybody plan
to participate at the Embedded Linux Conference Europe in Prague, this October?

If so, what are the subject(s) about to be discussed?

Cheers,

--
Geoffrey


Re: Situation with net APIs testing

Jukka Rissanen
 

Hi Paul,

On Wed, 2017-06-14 at 18:10 +0300, Paul Sokolovsky wrote:
Hello,

As I'm approaching final steps in preparing BSD Sockets patchset for
submission, I'm looking into a way to add some tests for it. Testing
of
networking functionality is by default hard, because in general,
networking hardware would be required for that, even if "virtual",
like
tunslip6, etc. tools from net-tools repo running, to support QEMU
networking. During prototyping work, I learnt there're loopback
capabilities when binding and connecting to the same netif, but it
still requires net-tools running just to get QEMU start up with
networking support.

Well, I took a look at tests/net and saw the whole bunch of tests,
whoa! I gave a try to tests/net/tcp , some cases passed, some failed,
hmm. But then I killed net-tools/loop-slip-tab.sh script and the test
ran in the same manner. Whoa, so we have means to run networking
without any requirements on the host side, which means we can run
them
as part of sanitycheck testsuite! But, 8 tests of tests/net/ have
build_only=true, any wonder they're broken?
When we had gerrit and jenkins, some of the net tests run slightly
longer that what was desired, so they were marked as build only. Now
that situation is different with github and shippable, we can change
this. So I will prepare a patch that activates those tests that can be
activated.

I looked through tests/net what is current status of the tests:

ieee802154/crypto
* This cannot be run on qemu as it requires suitable hw

tcp
* Test does not pass, needs fixing

mld
* Test does not pass, needs fixing

ipv6
* Test does not pass, needs fixing

lib/mqtt_publisher
* Test requires real qemu to run. This needs to be converted 

lib/mqtt_subscriber
* Test requires real qemu to run. This needs to be converted 

buf
* This test runs ok so build_only=true can be removed.

all
* This is intentional compile test that activates all network config
options and tries to compile the binary. The result binary cannot be
run mostly because of memory requirements and no suitable test
environment. The only issue with this test is that we should remember
to add and enable new net config options into this test case.

All other tests programs (24 pieces), that consists of quite many
individual tests, are run automatically by CI, so the situation is not
so bleak as you indicated here.

I will fix the relevant failing tests as they have bit rotted after the
tests were written. Converting two mqtt tests to not use real qemu
requires a bit more work.



Anyway, I looked at what's involved in net-tools free running, and
figured it's CONFIG_NET_L2_DUMMY. Added it to my sockets test, and
got
only segfault in return. After debugging it, turned out it's the same
issue as already faced by me and other folks: if there're no netifs
defined, networking code is going to crash (instead of printing clear
error to the user): https://jira.zephyrproject.org/browse/ZEP-2105

But how the tests/net/ run then and don't crash? Here's the answer:

zephyr/tests/net$ grep NET_DEVICE -r * | wc
     22      42    1532

So, almost each and every test defines its own test interface.

One would think that if we have 22 repetitive implementations of test
interfaces, whose main purpose is to be just loopback interfaces,
No, the interface is not a loopback interface although it might look
like that. The purpose of the interface that is created in each of the
test is to simulate a real network so that we do not have to connect to
outside world but the test is self contained. So it kind of looks like
a loopback interface but in this case the source and destination IP
addresses are not the same (as would be the case with loopback
interface), as typically we want to test some real behavior of the
system so src/dest addresses should differ.

The loopback support has limited use cases actually and we probably
need to make that optional (behind Kconfig option) in the code as
normally there should be no need to send anything back to itself in the
real world.

then
we'd have a loopback interface in the main codebase. But nope, as
confirmed by Jukka on IRC, we don't.

Summary:

1. Writing networking tests is hard, but it Zephyr, it takes
extraordinary, agonizing effort. The most annoying is that all needed
pieces are there, but instead of presenting a nice picture, they form
a mess which greets you with crashes if you try to change anything.
I am not sure what kind of mess you mean here but patches are welcome
as always to rectify this.


2. There're existing big (~20K each) test which fail. Apparently,
because they aren't run, so bitrot. Why do we need these huge,
detailed
tests if we don't run them? (An alternative explanation is that
Some explanation given above.

there's
something wrong with my system, and yep, I'd be glad to know what I'm
still don't do right with Zephyr after working on it for a year.)
Hmm, I missed the point of your last sentence.



I'd be glad if more experienced developers could confirm if it's
really
like the above, or I miss something. And I'll be happy to work on the
above issues, but in the meantime, I'll need to submit BSD Sockets
with
rather bare and hard to run (not automated) tests due to the
situation
above.
Cheers,
Jukka


Situation with net APIs testing

Paul Sokolovsky
 

Hello,

As I'm approaching final steps in preparing BSD Sockets patchset for
submission, I'm looking into a way to add some tests for it. Testing of
networking functionality is by default hard, because in general,
networking hardware would be required for that, even if "virtual", like
tunslip6, etc. tools from net-tools repo running, to support QEMU
networking. During prototyping work, I learnt there're loopback
capabilities when binding and connecting to the same netif, but it
still requires net-tools running just to get QEMU start up with
networking support.

Well, I took a look at tests/net and saw the whole bunch of tests,
whoa! I gave a try to tests/net/tcp , some cases passed, some failed,
hmm. But then I killed net-tools/loop-slip-tab.sh script and the test
ran in the same manner. Whoa, so we have means to run networking
without any requirements on the host side, which means we can run them
as part of sanitycheck testsuite! But, 8 tests of tests/net/ have
build_only=true, any wonder they're broken?

Anyway, I looked at what's involved in net-tools free running, and
figured it's CONFIG_NET_L2_DUMMY. Added it to my sockets test, and got
only segfault in return. After debugging it, turned out it's the same
issue as already faced by me and other folks: if there're no netifs
defined, networking code is going to crash (instead of printing clear
error to the user): https://jira.zephyrproject.org/browse/ZEP-2105

But how the tests/net/ run then and don't crash? Here's the answer:

zephyr/tests/net$ grep NET_DEVICE -r * | wc
22 42 1532

So, almost each and every test defines its own test interface.

One would think that if we have 22 repetitive implementations of test
interfaces, whose main purpose is to be just loopback interfaces, then
we'd have a loopback interface in the main codebase. But nope, as
confirmed by Jukka on IRC, we don't.

Summary:

1. Writing networking tests is hard, but it Zephyr, it takes
extraordinary, agonizing effort. The most annoying is that all needed
pieces are there, but instead of presenting a nice picture, they form
a mess which greets you with crashes if you try to change anything.

2. There're existing big (~20K each) test which fail. Apparently,
because they aren't run, so bitrot. Why do we need these huge, detailed
tests if we don't run them? (An alternative explanation is that there's
something wrong with my system, and yep, I'd be glad to know what I'm
still don't do right with Zephyr after working on it for a year.)


I'd be glad if more experienced developers could confirm if it's really
like the above, or I miss something. And I'll be happy to work on the
above issues, but in the meantime, I'll need to submit BSD Sockets with
rather bare and hard to run (not automated) tests due to the situation
above.



Thanks,

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


Zephyr 1.8.0-rc4 tagged

Nashif, Anas
 

Hi,

I just noticed all my previous rc notifications were stuck and not sent out. Sorry about that.

 

We have just tagged rc4 which is is very close to the final release pending completion of the release notes. If all goes ok with that rc, we will release it as 1.8 in the next 1-2 days.

 

Changes since rc1 are below…

 

Adithya Baglody (2):

      tests: benchmark: app_kernel: Return values from kernel APIs are read.

      tests: benchmark: Fixed build error from icx toolchain.

 

Anas Nashif (17):

      boards: microbit: enable flashing with pyocd

      Revert "xtools: get rid of warnings about wrong path"

      doc: remove links to wiki

      xtools: add new configurations for xtools 1.23

      doc: update macOS getting started documentation

      doc: also require dtc to be installed for linux

      doc: emphasize usage of MSYS2 MSYS Shell

      dts: make extract script take options

      dts: generate definitions for build system

      release: Zephyr 1.8.0-rc2

      Revert "x86: call gen_idt with $ZEPHYR_BASE too"

      quark_d2000_crb: increase default stack size

      gitlint: Ignore signed-off-by line

      release: Tag 1.8.0-rc3

      license: add missing licenses and copyright

      tests: remove obsolete usage of defrag

      release: Tag 1.8.0-rc4

 

Andrew Boie (22):

      bbc_microbit: fix 'make debugserver'

      arm: implement __svc on Cortex M0

      arm: fix k_oops on armv6 with interrupts locked

      Makefile.toolchain.zephyr: fix C++ on Xtensa

      samples: restore cpp_synchronization test

      doc: add interrupt implementation details

      printk: fix printing of long long types

      gccarmemb: don't assume 'dtc' is in /usr/bin

      kernel: fix short time-slice reset

      schedule_api: don't exclude Nios II

      nios2: reset timeslice on interrupt-induced swap

      riscv32: update time slice before swap

      tests: context: make some failures less ambiguous

      tests: context: allow 2 ticks of slop

      sam3x: report correct number of IRQ priority bits

      frdm_k64f: default to pyocd.sh for flashing/debug

      stack_sentinel: change cooperative check

      arches: declare _SysFatalErrorHandler __weak

      k_oops: force unlock IRQs on ARMv7M

      tests: fatal: increase coverage

      stack_sentinel: hang system on failure

      tests: context: move idle test to the end

 

Andy Gross (4):

      Makefile: Add dts config include file

      doc: Add Device Tree documentation

      dts: yaml: Add YAML template file

      scripts: Makefile.lib: Add dependency for DTS overlay

 

Carles Cufi (6):

      Bluetooth: controller: Increase RX prio stack size

      Bluetooth: controller: Conditionally include conn-related options

      Bluetooth: Consolidate all role configuration

      build: Fix DTC overlay file paths on MSYS2

      doc: getting_started: Add WSL instructions

      doc: Fill the Bluetooth section in the 1.8 release notes

 

David B. Kinder (4):

      doc: fix linenum references in api example

      doc: starting draft for 1.8 release notes

      doc: fix misspellings in docs

      doc: fix board/sample broken links

 

David Brown (1):

      dts: Allow override of dts overlay directory

 

Harry Jiang (2):

      sensor: lps22hb: fix the pressure sensor fractional value

      dts: 96b_carbon: Fix the model name and compatible

 

Inaky Perez-Gonzalez (1):

      scripts: look for files with no licensing info

 

Jaganath Kanakkassery (1):

      Bluetooth: SDP: Fix possible out of bound memory access

 

Johan Hedberg (4):

      Bluetooth: AVDTP: Remove dead code

      Bluetooth: Fix missing test for BLUETOOTH_CONN with DLE

      Bluetooth: ATT: Fix canceling ATT timeout upon response

      Bluetooth: L2CAP: Remove redundant checks for chan->ops

 

John Andersen (1):

      samples: net: mqtt_publisher: fixed formatting

 

Jukka Rissanen (31):

      net: zoap: Fix NULL pointer access

      tests: net: zoap: Add path uri matching tests

      net: zoap: Remove extra null checks

      net: http: Add timeout to HTTP server response

      sample: net: http: Add Basic auth support to server sample

      net: Print characters in hexdump

      net: pkt: Handle out-of-mem case properly

      net: ipv6: Skip unknown options in NS message

      net: http: Handle HTTPS connection closing gracefully

      samples: net: mbedtls_dtlsclient: Fix compile issues

      samples: net: mbedtls_dtlsclient: Fix testcase.ini

      samples: net: coaps_client: Fix compile issues

      samples: net: coaps_client: Fix testcase.ini

      net: ipv6: Default reassembly timeout set to 5 sec

      net: ipv6: Memory leak during fragment reassembly

      net: ipv6: Fix the IPv6 packet fragmentation sending

      net: ipv6: Fix fragmentation cancellation

      net: ipv6: Make max number of fragmented pkt configurable

      tests: net: ipv6: Test IPv6 fragmentation sending

      net: shell: Enhance IPv6 fragmentation debugging prints

      net: http: Parsing state was not cleared

      samples: net: zperf: Fix llvm compiler warnings

      samples: net: dtls_client: Fix Coverity warning

      samples: net: http_client: Increase the number of buffers

      net: http: Use random source port when connecting

      net: http: Avoid unnecessary net_pkt error print

      net: tcp: Timeout memory allocations

      net: https: Allow mbedtls debugging for https-server

      samples: net: Fix README.rst file documentation

      net: tcp: Check pkt before sending RESET

      doc: Add networking changes to 1.8 release note

 

Justin Watson (3):

      arch: arm: Fix SoC issues with Atmel SAM4S series.

      boards: arm: Added doc. image for the SAM E70 Xplained.

      boards: arm: arduino_due: Added doc. image for the Arduino Due.

 

Kumar Gala (1):

      toolchain.gccarmemb: Fix support for where to find newlib

 

Leandro Pereira (6):

      drivers: spi_mcux_dspi: Fix unlikely but possible division by zero

      tests: clock: Initialize d64 value

      ieee802154_shell: Only accept channels within expected range

      samples: mqtt_publisher: Try connecting a few times before giving up

      net: tcp: Limit number of segment retransmissions

      samples: dns_resolve: Clarify documentation about DNS configuration

 

Luiz Augusto von Dentz (3):

      net: shell: Move SHELL_REGISTER out of net_shell_init

      net: shell: Remove extra help command

      Bluetooth: GATT: Fix not queuing writes to CCC

 

Marti Bolivar (5):

      stack.h: add missing include guard

      lib: json: fix JSON_OBJ_DESCR_ARRAY Doxygen example

      tests: json: fix sense of test result string

      lib: json: add JSON_OBJ_DESCR_*_NAMED variants

      tests: json: test JSON_OBJ_DESCR_*_NAMED

 

Maureen Helm (1):

      arm: nxp: mpu: Return constant number of mpu regions

 

Michael Scott (3):

      arm: soc: nordic nRF52: Add MPU support

      arm: soc: nxp k6x: mpu: clarify magic numbers for UM/SM defines

      arm: soc: nxp k6x: mpu: add Bus Master 3 User Mode access bits

 

Patrik Flykt (1):

      zoap: Include net/net_ip.h when sockaddr is used

 

Paul Sokolovsky (6):

      subsys: console: Fix signed vs unsigned char issues.

      drivers/ethernet/eth_mcux: Fix extra PHY debug Kconfig name.

      tests: net: ipv6: Fix possible NULL pointer dereference behind a macro

      drivers/ethernet/eth_mcux: Fix selection of promisc mode IPv6 workaround

      drivers: serial: Clarification for uart_fifo_fill()/read() calls

      net: context: Operations on unused context should lead to EBADF.

 

Piotr Mienkowski (1):

      watchdog: atmel_sam: enable build for all SAM family

 

Ravi kumar Veeramally (2):

      net: rpl: Update RPL header

      net: 6lo: Fix source address uncompression

 

Sharron LIU (4):

      tests: kernel: added tests for timeslice reset

      tests: kernel: added tests for k_mem_pool_alloc from isr

      samples: fixed typo in README.rst

      samples: static_lib: conditional assign BOARD (?=)

 

Tomasz Bursztyka (1):

      api/spi: Change transceive functions signature

 

Vinayak Kariappa Chettimada (7):

      Bluetooth: controller: Fix DLE crossover assert

      Bluetooth: controller: Handle Rej Ext Ind for Length Req PDU

      Bluetooth: Auto-update LE data length to max. supported

      Bluetooth: controller: Fix CSA#2 assert

      Bluetooth: controller: Fix failing fast encryption setup feature

      drivers: timer: Fix nRF RTC timer _timer_cycle_get_32

      arch: arm: Fix compile error on ARMv6-M SoCs with TICKLESS_KERNEL

 

Vincenzo Frascino (1):

      arm: core: mpu: Add core support to NXP MPU

 

chunlin (1):

      arm: core: mpu: Prevent updating unexpected region

 

ruuddw (1):

      Create release-notes-1.8.rst

 

 

Thanks,

Anas


Re: sdk-ng

Nashif, Anas
 

Erwin,
The experience should be the same as with the current SDK. I did not say anything about downloading IDEs and from various vendors. There are well-established, standalone toolchains available that are better supported than what we have in the current SDK. Membership in the yocto project is really not a factor here. We are trying to keep things simple and remove the burden of having to maintain toolchains as part of the project. Believe it or not, the Zephyr SDK is also a one man show, yocto being a tool here that has nothing to do with the content of the SDK itself. And no, yocto does not give us an SDK on no Linux platforms and I am not sure what you mean with ptxdist... For the Zephyr developer just like with the current SDK it will be a downloadable file that installs some toolchains, in other cases it will download toolchains maintained by vendors like ARM, Intel and Synopsys etc.

Anas

-----Original Message-----
From: Erwin Rol [mailto:mailinglists@...]
Sent: Tuesday, June 13, 2017 9:44 PM
To: Nashif, Anas <anas.nashif@...>; zephyr-devel <zephyr-devel@...>
Subject: Re: [Zephyr-devel] sdk-ng

Hey Anas,

thanks for the explanation, I just wondered because Intel, Linaro, the Linux Foundation, etc. all seem Yocto members, where crosstools-ng seems to be pretty much a one-man-show (looking at the github commits).

On 14-6-2017 2:11, Nashif, Anas wrote:
The current SDK is very difficult to maintain, requires lots of
resources to build
And crosstools-ng is easier? Looking at ptxdist (which I already use for
years) there is still a lot of tuning needed. Same with RTEMS, they also seem to put a lot of effort in toolchain maintenance and tuning, especially integration with newlib.

And what about tools like openocd, they aren't part of crosstools-ng, are they?

and is not compatible with how crosstool compilers from vendors are
being distributed.
In what way "not compatible"? Aren't most vendors distributing some huge (eclipse)IDE with some GCC deep inside? (I am thinking about things like AC6, Atmel-Studio, etc.) Is there any "general" way to distribute a toolchain?

There are a few other issues, for
example it is only available on Linux, crosstools-ng gives us support
for the Mac as well.
Isn't Yocto capable to build SDK/toolchains that can run on Windows, Mac and Linux?

Another things is portability, try moving binaries around, this fails
with the current SDK.
That sounds a bit like a non-issue to me. Most big software packages can not be moved around. Of course others might have usecases where being able to move around the binaries is useful.

All in all, we are trying to
make it simpler and easier to maintain and we want to rely on vendor
toolchains rather than build everything ourselves in one giant blob
and then have to support it. We are not in the toolchain business, we
want to leave this to the experts and rely on recipes that are simple
that the way it is right now.
My experience is that those vendors are in the business of selling chips, and most software that comes from them is terrible. Look at the
AVR32 support from Atmel, they proudly present a GCC 4.4.X
(http://distribute.atmel.no/tools/opensource/Atmel-AVR32-GNU-Toolchain/3.4.3/)
in the form of patches that apparently no GCC developer wants to touch.

And from a user point of view, I thought it was very easy to download and install the Zephyr toolchains, and get to work with them. I would hate to have some readme.txt explaining to me I have to install 1 toolchain from Atmel, 1 from ST, 1 from Intel, all with different GUI installers (of course we want point-and-click) and all with their own huge (eclipse) IDE.

- Erwin


Re: sdk-ng

Erwin Rol
 

Hey Anas,

thanks for the explanation, I just wondered because Intel, Linaro, the
Linux Foundation, etc. all seem Yocto members, where crosstools-ng seems
to be pretty much a one-man-show (looking at the github commits).

On 14-6-2017 2:11, Nashif, Anas wrote:
The current SDK is very difficult to maintain, requires lots of
resources to build
And crosstools-ng is easier? Looking at ptxdist (which I already use for
years) there is still a lot of tuning needed. Same with RTEMS, they also
seem to put a lot of effort in toolchain maintenance and tuning,
especially integration with newlib.

And what about tools like openocd, they aren't part of crosstools-ng,
are they?

and is not compatible with how crosstool compilers
from vendors are being distributed.
In what way "not compatible"? Aren't most vendors distributing some huge
(eclipse)IDE with some GCC deep inside? (I am thinking about things like
AC6, Atmel-Studio, etc.) Is there any "general" way to distribute a
toolchain?

There are a few other issues, for
example it is only available on Linux, crosstools-ng gives us support
for the Mac as well.
Isn't Yocto capable to build SDK/toolchains that can run on Windows, Mac
and Linux?

Another things is portability, try moving binaries
around, this fails with the current SDK.
That sounds a bit like a non-issue to me. Most big software packages can
not be moved around. Of course others might have usecases where being
able to move around the binaries is useful.

All in all, we are trying to
make it simpler and easier to maintain and we want to rely on vendor
toolchains rather than build everything ourselves in one giant blob and
then have to support it. We are not in the toolchain business, we want
to leave this to the experts and rely on recipes that are simple that
the way it is right now.
My experience is that those vendors are in the business of selling
chips, and most software that comes from them is terrible. Look at the
AVR32 support from Atmel, they proudly present a GCC 4.4.X
(http://distribute.atmel.no/tools/opensource/Atmel-AVR32-GNU-Toolchain/3.4.3/)
in the form of patches that apparently no GCC developer wants to touch.

And from a user point of view, I thought it was very easy to download
and install the Zephyr toolchains, and get to work with them. I would
hate to have some readme.txt explaining to me I have to install 1
toolchain from Atmel, 1 from ST, 1 from Intel, all with different GUI
installers (of course we want point-and-click) and all with their own
huge (eclipse) IDE.

- Erwin


Re: sdk-ng

Nashif, Anas
 

The current SDK is very difficult to maintain, requires lots of resources to build and is not compatible with how crosstool compilers from vendors are being distributed. There are a few other issues, for example it is only available on Linux, crosstools-ng gives us support for the Mac as well. Another things is portability, try moving binaries around, this fails with the current SDK. All in all, we are trying to make it simpler and easier to maintain and we want to rely on vendor toolchains rather than build everything ourselves in one giant blob and then have to support it. We are not in the toolchain business, we want to leave this to the experts and rely on recipes that are simple that the way it is right now.

Anas

-----Original Message-----
From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of Erwin Rol
Sent: Tuesday, June 13, 2017 7:21 PM
To: zephyr-devel <zephyr-devel@...>
Subject: [Zephyr-devel] sdk-ng

Hey All,

when going over the 1.9 plans I noticed "sdk-ng".

When looking into the "sdk-ng" repo I noticed switching from yocto to crosstools-ng.

One question; why ?

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


sdk-ng

Erwin Rol
 

Hey All,

when going over the 1.9 plans I noticed "sdk-ng".

When looking into the "sdk-ng" repo I noticed switching from yocto to
crosstools-ng.

One question; why ?

- Erwin


Re: DMA driver API, source_burst_length, dest_burst_length

Liu, Baohong
 

-----Original Message-----
From: Johann Fischer [mailto:johann_fischer@...]
Sent: Friday, June 9, 2017 5:13 AM
To: Liu, Baohong <baohong.liu@...>; zephyr-
devel@...
Subject: Re: [Zephyr-devel] DMA driver API, source_burst_length,
dest_burst_length

Hi Baohong,

What are the data units? octets?
This is HW related. It can't specified here in the generic API.

Burst length should be used together with transfer width. Let me give an
example.

For a single DMA data transfer, the source can only send data out at 2
bytes each transfer and the destination can only accept data at one
byte each transfer (this is HW related.). The DMA engine will get 2
bytes from the source and sends the data to the destination one byte
each time (do this twice). For this case, the DMA burst length will be
2 bytes long, since this is the minimum data unit the source side can
deal with. So, source_burst_length = 1 source_transfer_width = 2
dest_burst_length = 2 dest_transfer_width = 1
thanks for the clarification. I suppose:
source_transfer_width should be source_data_size ?
dest_transfer_width should be dest_data_size ?

It is a little redundant, what is the reason for two burst length variables? You can
also pass the number of bytes per request and then calculate the burst length in
the driver, if necessary.
Make sense.



Note: 1 or 2 in the above is absolute value. Since in the API, the enum starts
from 0, 1 or 2 should be changed to 0 or 1.

Do you mean "enum dma_burst_length"? No driver seems to use it.
If a dma driver implementation follows the generic dma API, it should use this enum.


I would be glad if you would find time to review PR[1] and the fix for
test_chan_blen_transfer (15757e1).
I do not work on Zephyr any more. If time allows, I will be happy to review it.


[1] https://github.com/zephyrproject-rtos/zephyr/pull/393

--
Best Regards,
Johann Fischer


Re: C-lib status

Erwin Rol
 

Hey Anas,

On 12-6-2017 19:45, Nashif, Anas wrote:
Not following how this is related to Posix and feature of 1.9.
AFAIK, What is missing is a hook for gettimeofday in
lib/libc/newlib/libc-hooks.c which can then get the needed information
from the underlying hardware. We could provide a dummy and a way to
connect this to RTC drivers or the kenel timers for example...
Yeah newlib offers hooks for a lot of things, but that not just means
changing Zephyr, but also the toolchains (if I understood correctly).

And here is where the 1.9 features come in, if 1.9 will have big changes
to both API's and toolchain building I'll rather wait until that is done
(or at least started) before trying to apply patches now.

For now I rather focus on stuff like missing drivers, I got a prototype
eth_stm32_hal driver for Ethernet. I will need something to do LIN-like
RS485 (BREAK as sync on a half duplex bus) and I need CAN.

Those things I could use under other OSes (like FreeRTOS or RTEMS) too,
which gives me a possibility to contribute to Zephyr and have a backup
plan for my work.

Even though I am complaining (we Dutch always have something to
complain), Zephyr really surprised me in a positive way. It was real
easy to add the olimex_stm32_e407 bsp, and the Ethernet drivers wasn't
that difficult apart from understanding the alternate function setup of
the GPIO's.

- Erwin


Re: C-lib status

Nashif, Anas
 

Not following how this is related to Posix and feature of 1.9.

AFAIK, What is missing is a hook for gettimeofday in lib/libc/newlib/libc-hooks.c which can then get the needed information from the underlying hardware. We could provide a dummy and a way to connect this to RTC drivers or the kenel timers for example...

Anas

-----Original Message-----
From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of Paul Sokolovsky
Sent: Monday, June 12, 2017 9:42 AM
To: Erwin Rol <mailinglists@...>
Cc: zephyr-devel@...
Subject: Re: [Zephyr-devel] C-lib status

Hello Erwin,

On Sun, 11 Jun 2017 16:34:21 +0200
Erwin Rol <mailinglists@...> wrote:

Hey Paul,

time() was just the first thing I tried to see how well newlib works,
and the results was it doesn't. And that it compiles without warning
and than hangs in an endless loop sounds like a bug to me, no matter
how useful/useless a time() call would be.
I'm sure everyone would agree, so it's worth considering how to "fix"
it (even it will be a workaround or incomplete fix) and do that.

But your point about version 1.9 is interesting, "POSIX API Layer",
"BSD Socket Support", "Build and Configuration System", and "Zephyr
SDK NG" sound like very big changes to how Zephyr can/should be used.
Well, it's true that Zephyr currently undergoes extensive (vs
intensive) growth, with a lot of functionality being both added and planned. But there may be omissions, gaps, and plain bugs in that functionality. While all that's not ideal, I (even though I'm just an
engineer) personally think that, given the competitive RTOS landscape, it's the best approach so far - try to offer more functionality and support than other RTOSes and by that, attract wide community so "any bug becomes shallow".

I think I'll wait for that release (when it really comes in August) to
reevaluate if Zephyr is usable for me or if it would be better to put
energy and effort in for example RTEMS.
Sounds good, but unfortunately we aren't yet have enough eyes (and
hands) to proverbially make any bug shallow, so if you consider that
time() would be really useful for Zephyr applications, or its current behavior very problematic, I'd encourage you to do something about it - at the very least, submit a bug for it at http://jira.zephyrproject.org/


- Erwin

On 10-6-2017 14:12, Paul Sokolovsky wrote:
Hello Erwin,

On Sat, 10 Jun 2017 13:38:33 +0200
Erwin Rol <mailinglists@...> wrote:

Hey all (yeah there he is again),

I was wondering what the status and planning is for the C-library?
I tried a simple example and I guess I directly hit a problem. The
"buildin" mini C-lib doesn't offer much (I wanted the time(NULL)
When you want time(NULL), what are your expectations? Because as you
know, what it's supposed to do is to return number of seconds since
1970-01-01. Does your board even have an idea how long ago 1970 was?
I own ~ couple of dozens of MCU boards, and none of them has
battery-backed RTC as required to know when 1970-01-01 was. The
remaining alternative is to pray that a board has MCU-internal RTC
which doesn't reset with MCU reset, and set it up (usually manually)
on each power up, which is hardly practical.

function), so I selected newlibc. That compiles but doesn't work,
it ends up in an endless loop where gettimeofday calls
_gettimeofday_r and that calls gettimeofday again (see stack trace
below).

Am I doing something wrong here (Zephyr configuration or something
like that) or is newlib support just not yet ready to use ?
I guess a fair answer is that Zephyr will never work like Linux.
Otherwise, functions which make sense for MCU boards get tried in
one by one manner, issues found and fixed (e.g. errno didn't work
for newlib few weeks ago:
https://github.com/zephyrproject-rtos/zephyr/commit/8cc6f6ddd6e0ff882ec5bd10700058df345cea19).

Otherwise, if you read TSC planning notes for 1.9, they include
"POSIX API". It's not very clear what that means, but making time()
work somehow would fit that line, but as usual would require
stakeholders interested to RFC and implement it.

Otherwise, Zephyr has native time API which you can use to measure
duration between events, etc.


- Erwin
[]

--
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 _______________________________________________
Zephyr-devel mailing list
Zephyr-devel@...
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


Re: C-lib status

Paul Sokolovsky
 

Hello Erwin,

On Sun, 11 Jun 2017 16:34:21 +0200
Erwin Rol <mailinglists@...> wrote:

Hey Paul,

time() was just the first thing I tried to see how well newlib works,
and the results was it doesn't. And that it compiles without warning
and than hangs in an endless loop sounds like a bug to me, no matter
how useful/useless a time() call would be.
I'm sure everyone would agree, so it's worth considering how to "fix"
it (even it will be a workaround or incomplete fix) and do that.

But your point about version 1.9 is interesting, "POSIX API Layer",
"BSD Socket Support", "Build and Configuration System", and "Zephyr
SDK NG" sound like very big changes to how Zephyr can/should be used.
Well, it's true that Zephyr currently undergoes extensive (vs
intensive) growth, with a lot of functionality being both added and
planned. But there may be omissions, gaps, and plain bugs in that
functionality. While all that's not ideal, I (even though I'm just an
engineer) personally think that, given the competitive RTOS landscape,
it's the best approach so far - try to offer more functionality and
support than other RTOSes and by that, attract wide community so "any
bug becomes shallow".

I think I'll wait for that release (when it really comes in August) to
reevaluate if Zephyr is usable for me or if it would be better to put
energy and effort in for example RTEMS.
Sounds good, but unfortunately we aren't yet have enough eyes (and
hands) to proverbially make any bug shallow, so if you consider that
time() would be really useful for Zephyr applications, or its current
behavior very problematic, I'd encourage you to do something about it -
at the very least, submit a bug for it at
http://jira.zephyrproject.org/


- Erwin

On 10-6-2017 14:12, Paul Sokolovsky wrote:
Hello Erwin,

On Sat, 10 Jun 2017 13:38:33 +0200
Erwin Rol <mailinglists@...> wrote:

Hey all (yeah there he is again),

I was wondering what the status and planning is for the C-library?
I tried a simple example and I guess I directly hit a problem. The
"buildin" mini C-lib doesn't offer much (I wanted the time(NULL)
When you want time(NULL), what are your expectations? Because as you
know, what it's supposed to do is to return number of seconds since
1970-01-01. Does your board even have an idea how long ago 1970
was? I own ~ couple of dozens of MCU boards, and none of them has
battery-backed RTC as required to know when 1970-01-01 was. The
remaining alternative is to pray that a board has MCU-internal RTC
which doesn't reset with MCU reset, and set it up (usually manually)
on each power up, which is hardly practical.

function), so I selected newlibc. That compiles but doesn't work,
it ends up in an endless loop where gettimeofday calls
_gettimeofday_r and that calls gettimeofday again (see stack trace
below).

Am I doing something wrong here (Zephyr configuration or something
like that) or is newlib support just not yet ready to use ?
I guess a fair answer is that Zephyr will never work like Linux.
Otherwise, functions which make sense for MCU boards get tried in
one by one manner, issues found and fixed (e.g. errno didn't work
for newlib few weeks ago:
https://github.com/zephyrproject-rtos/zephyr/commit/8cc6f6ddd6e0ff882ec5bd10700058df345cea19).

Otherwise, if you read TSC planning notes for 1.9, they include
"POSIX API". It's not very clear what that means, but making time()
work somehow would fit that line, but as usual would require
stakeholders interested to RFC and implement it.

Otherwise, Zephyr has native time API which you can use to measure
duration between events, etc.


- Erwin
[]

--
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: STM32F4 I2C driver

Jorge Ramirez <jorge.ramirez-ortiz@...>
 

On 06/12/2017 10:01 AM, Yannis Damigos wrote:
Hi Erwan,

I actually my plan is to finally create a generic i2c_ll_stm32 driver
but I started small with the stm32f4 finally because it is my first
attempt to code a driver and I only have stm32f1 and stm32f4
development boards.
Running just a diff on the i2c_ll_stm32fxxx header files, I could say
that there are two groups of stm32 soc families for the I2C LL API.
The first group contains the families F1, F4 and the second the
families F3, F7, L4.
So my i2c driver should work also for the F1 family with few
modifications, which I planned to test after the testing of i2c read
operation.

I will contact Jorge to coordinate our efforts on the st i2c ll driver.
hi Yannis,

This is great timing.

I have a working stm32f4x driver based on HAL (did a little bit of rework on one of Neil's Armstrong prototypes but nothing major just, enough to get it working).
I was only able to test the protocol on a logic analyzer though since my Grove-LCD seems dead.
And yes I also noticed two very different type of controllers.

I believe that now you have done the LL, adding some abstractions and adapting i2c_stm32lx.c shouldn't be too bad/
are you in IRC? my id is ldts . if you have some time later in the morning (I am in CEST time zone) we could discuss.

TIA
jorge


STM32F4 I2C driver

Yannis Damigos
 

Hi Erwan,

I actually my plan is to finally create a generic i2c_ll_stm32 driver
but I started small with the stm32f4 finally because it is my first
attempt to code a driver and I only have stm32f1 and stm32f4
development boards.
Running just a diff on the i2c_ll_stm32fxxx header files, I could say
that there are two groups of stm32 soc families for the I2C LL API.
The first group contains the families F1, F4 and the second the
families F3, F7, L4.
So my i2c driver should work also for the F1 family with few
modifications, which I planned to test after the testing of i2c read
operation.

I will contact Jorge to coordinate our efforts on the st i2c ll driver.

Yannis

On Mon, Jun 12, 2017 at 10:32 AM, Erwan Gouriou
<erwan.gouriou@...> wrote:
Hi Yannis,


Thanks for this proposition. We are indeed missing I2C driver for STM32F4
family.
What would be really nice is to get a generic STM32 I2C driver, working on
all series
(based on LL STM32Cube API as you've done is a good start for this purpose).
Jorge (cc) is working on the "generic side" of the driver, can you get in
touch with him,
and see how to achieve and upstream i2c_ll_stm32.c/h ?

Erwan

On 11 June 2017 at 16:33, Yannis Damigos <giannis.damigos@...> wrote:

Hello,

I am developing an I2C driver based on the stm32cube LL API.
The driver can be found here:
https://github.com/ydamigos/zephyr/tree/i2c_ll_stm32f4

The driver supports both polling and interrupt for master mode.

The status of the I2C driver today is the following:
The master write operation for 7bit addressing was tested on Carbon from
96Boards.
The master read operation was not tested (at the moment I only have a I2C
OLED display which supports only write operations)
The 10bit address support was not tested.
Slave mode is not implemented.

Should I open a PR for the driver or wait until all the operations are
tested?

Please feel free to test the driver and provide me with any input.

Yannis



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


Re: STM32F4 I2C driver

Erwan Gouriou
 

Hi Yannis,


Thanks for this proposition. We are indeed missing I2C driver for STM32F4 family.
What would be really nice is to get a generic STM32 I2C driver, working on all series
(based on LL STM32Cube API as you've done is a good start for this purpose).
Jorge (cc) is working on the "generic side" of the driver, can you get in touch with him,
and see how to achieve and upstream i2c_ll_stm32.c/h ?

Erwan

On 11 June 2017 at 16:33, Yannis Damigos <giannis.damigos@...> wrote:
Hello,

I am developing an I2C driver based on the stm32cube LL API.
The driver can be found here: https://github.com/ydamigos/zephyr/tree/i2c_ll_stm32f4

The driver supports both polling and interrupt for master mode.

The status of the I2C driver today is the following:
The master write operation for 7bit addressing was tested on Carbon from 96Boards.
The master read operation was not tested (at the moment I only have a I2C OLED display which supports only write operations)
The 10bit address support was not tested.
Slave mode is not implemented.

Should I open a PR for the driver or wait until all the operations are tested?

Please feel free to test the driver and provide me with any input.

Yannis



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



Re: C-lib status

Erwin Rol
 

Hey Paul,

time() was just the first thing I tried to see how well newlib works,
and the results was it doesn't. And that it compiles without warning and
than hangs in an endless loop sounds like a bug to me, no matter how
useful/useless a time() call would be.

But your point about version 1.9 is interesting, "POSIX API Layer", "BSD
Socket Support", "Build and Configuration System", and "Zephyr SDK NG"
sound like very big changes to how Zephyr can/should be used.

I think I'll wait for that release (when it really comes in August) to
reevaluate if Zephyr is usable for me or if it would be better to put
energy and effort in for example RTEMS.

- Erwin

On 10-6-2017 14:12, Paul Sokolovsky wrote:
Hello Erwin,

On Sat, 10 Jun 2017 13:38:33 +0200
Erwin Rol <mailinglists@...> wrote:

Hey all (yeah there he is again),

I was wondering what the status and planning is for the C-library? I
tried a simple example and I guess I directly hit a problem. The
"buildin" mini C-lib doesn't offer much (I wanted the time(NULL)
When you want time(NULL), what are your expectations? Because as you
know, what it's supposed to do is to return number of seconds since
1970-01-01. Does your board even have an idea how long ago 1970 was? I
own ~ couple of dozens of MCU boards, and none of them has
battery-backed RTC as required to know when 1970-01-01 was. The
remaining alternative is to pray that a board has MCU-internal RTC
which doesn't reset with MCU reset, and set it up (usually manually)
on each power up, which is hardly practical.

function), so I selected newlibc. That compiles but doesn't work, it
ends up in an endless loop where gettimeofday calls _gettimeofday_r
and that calls gettimeofday again (see stack trace below).

Am I doing something wrong here (Zephyr configuration or something
like that) or is newlib support just not yet ready to use ?
I guess a fair answer is that Zephyr will never work like Linux.
Otherwise, functions which make sense for MCU boards get tried in one by
one manner, issues found and fixed (e.g. errno didn't work for newlib
few weeks ago:
https://github.com/zephyrproject-rtos/zephyr/commit/8cc6f6ddd6e0ff882ec5bd10700058df345cea19).

Otherwise, if you read TSC planning notes for 1.9, they include
"POSIX API". It's not very clear what that means, but making time()
work somehow would fit that line, but as usual would require
stakeholders interested to RFC and implement it.

Otherwise, Zephyr has native time API which you can use to measure
duration between events, etc.


- Erwin

#0 gettimeofday (ptimeval=ptimeval@entry=0x20001720
<_main_stack+4052>, ptimezone=ptimezone@entry=0x0)
at /usr/src/debug/newlib/2.4.0-r0/newlib-2.4.0/newlib/libc/syscalls/sysgettod.c:12
#1 0x0800091c in _gettimeofday_r (ptr=0x20000008 <impure_data>,
ptimeval=ptimeval@entry=0x20001720 <_main_stack+4052>,
ptimezone=ptimezone@entry=0x0)
at /usr/src/debug/newlib/2.4.0-r0/newlib-2.4.0/newlib/libc/reent/gettimeofdayr.c:71
#2 0x0800093c in gettimeofday (ptimeval=ptimeval@entry=0x20001720
<_main_stack+4052>, ptimezone=ptimezone@entry=0x0)
at /usr/src/debug/newlib/2.4.0-r0/newlib-2.4.0/newlib/libc/syscalls/sysgettod.c:12
#3 0x0800091c in _gettimeofday_r (ptr=0x20000008 <impure_data>,
ptimeval=ptimeval@entry=0x20001720 <_main_stack+4052>,
ptimezone=ptimezone@entry=0x0)
at /usr/src/debug/newlib/2.4.0-r0/newlib-2.4.0/newlib/libc/reent/gettimeofdayr.c:71
#4 0x0800093c in gettimeofday (ptimeval=ptimeval@entry=0x20001720
<_main_stack+4052>, ptimezone=ptimezone@entry=0x0)
at /usr/src/debug/newlib/2.4.0-r0/newlib-2.4.0/newlib/libc/syscalls/sysgettod.c:12
#5 0x0800091c in _gettimeofday_r (ptr=0x20000008 <impure_data>,
ptimeval=ptimeval@entry=0x20001720 <_main_stack+4052>,
ptimezone=ptimezone@entry=0x0)
at /usr/src/debug/newlib/2.4.0-r0/newlib-2.4.0/newlib/libc/reent/gettimeofdayr.c:71
#6 0x0800093c in gettimeofday (ptimeval=ptimeval@entry=0x20001720
<_main_stack+4052>, ptimezone=ptimezone@entry=0x0)
at /usr/src/debug/newlib/2.4.0-r0/newlib-2.4.0/newlib/libc/syscalls/sysgettod.c:12
#7 0x0800091c in _gettimeofday_r (ptr=0x20000008 <impure_data>,
ptimeval=ptimeval@entry=0x20001720 <_main_stack+4052>,
ptimezone=ptimezone@entry=0x0)
at /usr/src/debug/newlib/2.4.0-r0/newlib-2.4.0/newlib/libc/reent/gettimeofdayr.c:71
#8 0x0800093c in gettimeofday (ptimeval=ptimeval@entry=0x20001720
<_main_stack+4052>, ptimezone=ptimezone@entry=0x0)
at /usr/src/debug/newlib/2.4.0-r0/newlib-2.4.0/newlib/libc/syscalls/sysgettod.c:12
#9 0x0800091c in _gettimeofday_r (ptr=0x20000008 <impure_data>,
ptimeval=ptimeval@entry=0x20001720 <_main_stack+4052>,
ptimezone=ptimezone@entry=0x0)
at /usr/src/debug/newlib/2.4.0-r0/newlib-2.4.0/newlib/libc/reent/gettimeofdayr.c:71
#10 0x0800093c in gettimeofday (ptimeval=ptimeval@entry=0x20001720
<_main_stack+4052>, ptimezone=ptimezone@entry=0x0)
at /usr/src/debug/newlib/2.4.0-r0/newlib-2.4.0/newlib/libc/syscalls/sysgettod.c:12
#11 0x0800091c in _gettimeofday_r (ptr=0x20000008 <impure_data>,
ptimeval=ptimeval@entry=0x20001720 <_main_stack+4052>,
ptimezone=ptimezone@entry=0x0)
at /usr/src/debug/newlib/2.4.0-r0/newlib-2.4.0/newlib/libc/reent/gettimeofdayr.c:71
#12 0x080008ee in time (t=t@entry=0x0)
at /usr/src/debug/newlib/2.4.0-r0/newlib-2.4.0/newlib/libc/time/time.c:46
#13 0x0800094a in main ()
at /home/erwin/zephyr/samples/hello_world/src/main.c:43
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@...
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


STM32F4 I2C driver

Yannis Damigos
 

Hello,

I am developing an I2C driver based on the stm32cube LL API.
The driver can be found here: https://github.com/ydamigos/zephyr/tree/i2c_ll_stm32f4

The driver supports both polling and interrupt for master mode.

The status of the I2C driver today is the following:
The master write operation for 7bit addressing was tested on Carbon from 96Boards.
The master read operation was not tested (at the moment I only have a I2C OLED display which supports only write operations)
The 10bit address support was not tested.
Slave mode is not implemented.

Should I open a PR for the driver or wait until all the operations are tested?

Please feel free to test the driver and provide me with any input.

Yannis

5761 - 5780 of 8790