Date   
Re: Soft serial 9k6 for debugging on free GPIO?

Henrik Brix Andersen
 

Hi Martijn,

If you are using a Segger J-Link probe you can use the RAM-based RTT console by setting CONFIG_RTT_CONSOLE=y
See https://docs.zephyrproject.org/latest/guides/debugging/host-tools.html#jlink-debug-host-tools for more information.

./Brix
--
Henrik Brix Andersen

On 31 May 2019, at 15.53, martijn@... wrote:

Hi there,

We have a prototype utilising the nRF52840 BME340 SoC module. Since we use a LoRaWAN module and a MAX3485 we used the two 840 uarts for connecting to these subsystems. But I do have some free GPIOs on the prototype PCB which I'd like to use as a console when running the project in debug mode. So I'm looking for a way to have a low-speed soft-serial taking care of logging. Any pointers, or perhaps other ways to get logging output (we are using BLE)?

Looked at some discussions on the Nordic devzone, but not a lot going for it.

Thanks,
Martijn

Re: Soft serial 9k6 for debugging on free GPIO?

Jian Zhang
 

Hi Martijn,

Not sure about the exact situation you are facing, listed below please find some of the suggestions I can think of:

1. There are soft uart implementations on github, which you might be able to port to zephyr;
2. If you got SPI interface on your module, there are bridge modules available to convert i2c/spi to uart; // sc16is740 etc
3. If you only care about the application level log, probably you can use bluetooth to build a virtual serial port for logging purpose;

Best Regards,
Jian

Soft serial 9k6 for debugging on free GPIO?

Martijn Smit
 

Hi there,

We have a prototype utilising the nRF52840 BME340 SoC module. Since we use a LoRaWAN module and a MAX3485 we used the two 840 uarts for connecting to these subsystems. But I do have some free GPIOs on the prototype PCB which I'd like to use as a console when running the project in debug mode. So I'm looking for a way to have a low-speed soft-serial taking care of logging. Any pointers, or perhaps other ways to get logging output (we are using BLE)?

Looked at some discussions on the Nordic devzone, but not a lot going for it.

Thanks,
Martijn

"net arp" command displays "ARP cache is empty" even after a series of arpings from peer devices #nrf52840

giriprasad@...
 

Hi,

I have interfaced "ENC28J60" to "PCA10056"(NRF52840) through SPI. Made necessary configurations in order to reflect hardware changes in software. Flashed sample application, "dumb_http_server" to the board. Enabled "ARP" and "ICMP". I am able to ping the board from peer devices in network and vice versa. Also, I am able to "arping" the board from peer devices in network. After this, I have issued "net arp" command in the serial console of the board. By this, I am expecting a list of peer devices to be displayed on the console. But console throws a message saying "ARP cache is empty". Can I know the reason for this behavior? Please let me know, if I was wrong in the process. Also, let me know if more information is needed. Attached configuration file for reference.

Thanks & Regards,
Giri Prasad N.

Upcoming Event: Zephyr Project: Dev Meeting - Thu, 05/30/2019 8:00am-9:00am, Please RSVP #cal-reminder

devel@lists.zephyrproject.org Calendar <devel@...>
 

Reminder: Zephyr Project: Dev Meeting

When: Thursday, 30 May 2019, 8:00am to 9:00am, (GMT-07:00) America/Los Angeles

Where:https://zoom.us/j/993312203

An RSVP is requested. Click here to RSVP

Organizer: devel@...

Description: Join Zoom Meeting
https://zoom.us/j/993312203

One tap mobile
+16699006833,,993312203# US (San Jose)
+16465588656,,993312203# US (New York)

Dial by your location
        +1 669 900 6833 US (San Jose)
        +1 646 558 8656 US (New York)
        +1 877 369 0926 US Toll-free
        +1 855 880 1246 US Toll-free
Meeting ID: 993 312 203
Find your local number: https://zoom.us/u/ankEMRagf

Where is the proper place to update the RPL HBHO

Jian Zhang
 

Hi all,

I am working on bring back RPL to Zephyr, which includes migrating RPL to use net_pkt API.

The old RPL implementation was using net_pkt_insert() to insert RPL HBHO header when finalizing the udp packet. However, I can see that the net_pkt_insert() was removed already.

I am not very familiar with the Zephyr network architecture. One way I can think about is to update the RPL HBHO in net_udp_create(), though not sure if this is the right way to go ahead. Please help.

Thanks and Best Regards,
Jian

Re: Logging with a string via %s

Chruściński, Krzysztof
 

Hi,

Logger is now able to detect lack of log_strdup() wrapping when %s is used with string coming from read write memory. Logger will assert if asserts are enabled or log error message if asserts are disabled. Feature is optional, enabled by default: https://github.com/zephyrproject-rtos/zephyr/pull/16310

Krzysztof

-----Original Message-----
From: devel@... <devel@...> On Behalf Of Chruscinski, Krzysztof via Lists.Zephyrproject.Org
Sent: Tuesday, May 21, 2019 7:37 AM
To: marc.herbert@...; Dunaj, Pawel <Pawel.Dunaj@...>
Cc: devel@...
Subject: Re: [Zephyr-devel] Logging with a string via %s

Hi,

Logger was redesigned to work in deferred mode (string processing and transport deferred to idle stage) to be capable of handling multiple backends and to be less intrusive than standard in-place approach. That is because Zephyr is targeting embedded systems where logger may be extensively used from interrupt context. This approach reduces logging time from hundreds of microseconds to just few, making it non-intrusive (compared to in-place logging). Additionally, deferred logging allows using multiple backends, including some which are slow (e.g. flashlog) or more complex (e.g. Bluetooth). In those cases in place logging wouldn't be possible at all. In order to achieve that, only arguments are stored when log message is created. %s is the victim of that but, as already mentioned, there are some countermeasures to take care of that: immediate mode (blocking) and log_strdup for duplicating transient string. For native_posix board immediate mode is the default one, maybe it should be the default for qemu boards as well but making it default for boards with SoC would soon lead to similar complaining email (like "I've enabled logging and my system crashed").

There are countermeasures that could be added that could help with that:
- detection of lack of log_strdup during log processing. Based on the string address it could be determined if it's in .rodata or log_strdup buffer pool and if not warning/assert could occur
- adding custom format specifiers for address (network, Bluetooth) since in many cases %s was used for locally rendered address.

Krzysztof

-----Original Message-----
From: devel@... <devel@...> On Behalf Of Marc Herbert via Lists.Zephyrproject.Org
Sent: Monday, May 20, 2019 7:00 PM
To: Dunaj, Pawel <Pawel.Dunaj@...>
Cc: devel@...
Subject: Re: [Zephyr-devel] Logging with a string via %s


On 20 May 2019, at 00:20, pawel.dunaj@... wrote:

I think %s capability should be dropped from the logger’s format string processing and a separate API added specifically to log a C string, which makes an immediate copy.

Here I totally agree. I think that formatting of strings is such a well known standard that nobody will read the fine print for a logger to see what magic may lie under its hood. I think we should either assert that %s is never used and use some other format instead (i.e. force people to check the doc at least once when they hit an error) or keep %s for in place rendering and add new format for people who want to go faster.
Another thing is that assert is disabled by default so many people may never notice the problem (especially for error paths).

There's a violation of the "Least Astonishment" principle but it's not with the '%s'. The '%s' traditionally refers to the type of the argument only, it says nothing about memory management. I don't think LOG_ASYNC('%s', ...) or LOG(O_NONBLOCK, '%s', ... ) would surprise anyone.

Confusing memory semantics with format specifiers would break not just user expectations but also tools like this:
https://gcc.gnu.org/onlinedocs/gcc-9.1.0/gcc/Common-Function-Attributes.html#index-format-function-attribute (I found an insane number of bugs with this attribute)
+ other static checkers trying to make C a bit more safe.


BTW the current API is neither "asynchronous" nor "non-blocking" in the usual API meanings.

It's not asynchronous in the usual sense because there's no callback or any other second step to know when the memory can be freed or re-used.

It's not non-blocking because it always succeeds, never asks to retry with EAGAIN/EWOULDBLOCK etc.

It's a "globals-only", "UFO" API like nothing else.

Upcoming Event: Zephyr Project: APIs - Tue, 05/28/2019 9:00am-10:00am, Please RSVP #cal-reminder

devel@lists.zephyrproject.org Calendar <devel@...>
 

Reminder: Zephyr Project: APIs

When: Tuesday, 28 May 2019, 9:00am to 10:00am, (GMT-07:00) America/Los Angeles

Where:https://zoom.us/j/177647878

An RSVP is requested. Click here to RSVP

Organizer: devel@...

Description: Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/177647878

Or iPhone one-tap :
    US: +16465588656,,177647878# or +16699006833,,177647878# 
Or Telephone:
    Dial(for higher quality, dial a number based on your current location): 
        US: +1 646 558 8656 or +1 669 900 6833 or +1 855 880 1246 (Toll Free) or +1 877 369 0926 (Toll Free)
    Meeting ID: 177 647 878
    International numbers available: https://zoom.us/zoomconference?m=ioAR9GK1OE5LkN1ojt-heTCl7yPcJrhY


 Live meeting minutes: https://docs.google.com/document/d/1lv-8B5QE2m4FjBcvfqAXFIgQfW5oz6306zJ7GIZIWCk/edit?usp=sharing

API meeting and agenda

Carles Cufi
 

Hi all,

As you know, the Zephyr API meeting takes place on Tuesdays 9AM-10AM (PDT) (18h-19h (CEST)).

Until now the way to include an item (issue or Pull Request) added to the meeting agenda was to add the API label to it.
In order to simplify the management of issues, we now ask everybody to instead mark the item as belonging to the API review/cleanup/rework GitHub Project (use the Projects selector in the issue or Pull Request):
https://github.com/zephyrproject-rtos/zephyr/projects/18

During the API meeting we will go through the Triage column in that project.

Additional information about the meeting can be found here:
https://github.com/zephyrproject-rtos/zephyr/wiki/Zephyr-Committee-and-Working-Group-Meetings#zephyr-api-discussion

Thanks,

Carles

CANopen support?

Henrik Brix Andersen
 

Hi all,

I am working on a project where we will need to use CANopen on top of the SocketCAN driver layer in Zephyr.

I have found two references to CANopen on Zephyr so far:
- https://github.com/zephyrproject-rtos/zephyr/issues/15278
- https://github.com/zephyrproject-rtos/zephyr/pull/13206

Have anybody already tried porting an existing CANopen stack to run on Zephyr? Are there any plans for including “official” support for CANopen in Zephyr?
Currently, we are looking at proprietary, 3rd party CANopen stacks (haven’t found any that supports Zephyr out of the box), but I’d much rather go with an open source solution in the long run.

Regards,
Brix
--
Henrik Brix Andersen

Re: Checking compiler support for userspace C, C++ libs (ZeroMQ)

Stanislav Pobořil
 

Hi Ivan,

I have successfully tried Zephyr with C++ library (eRPC) some time ago.
The version of Zephyr was based on master branch as of March 19th.

However:

    I haven't used zephyr-sdk, I used arm-gcc toolchain instead - standard C++ headers in zephyr-sdk were not complete and build failed in zephyr-sdk.
    I got some compilation warnings as the build system tried to put C only compiler flags to C++ sources. This could be ignored.
    I had the following in project configuration:
        CONFIG_NEWLIB_LIBC=y
        CONFIG_CPLUSPLUS=n     (the demo application and Zerphyr were compiled as C, only eRPC C++ files were compiled as C++)


So your desired ZeroMQ library can have problems in zephyr-sdk, but could be probably build with third party toolchains specific to each architecture.
You may need to create definitions of some C++ operators like operator new, delete if the library does not define it. eRPC library defines it like this: https://github.com/EmbeddedRPC/erpc/blob/master/erpc_c/port/erpc_port_zephyr.cpp
I am not sure about the version of zephyr-sdk I have used. Probably 0.9.4 or 0.9.5. The situation in the actual Zephyr and zephyr-sdk versions may be different now. Search for LIB_CPLUSPLUS in the Zephyr source, this for example includes the C++ operator definitions into a build.

It is also worth noting that eRPC is created with embedded C interoperability in mind. If your ZeroMQ library for example uses C++ exceptions, you would have to work around it somehow.

Best regards,
Staňa

Re: Checking compiler support for userspace C, C++ libs (ZeroMQ)

Rodrigo Peixoto
 

Ivan,
I would suggest you to not use C++. I am facing a lot of compatibility issues and some drivers (like Bluetooth) will not work in C++. 

C is the only truly viable option. Go for it. Zephyr in C rules! Try some lib option in C if possible. 

Best regards,
Rodrigo 

On Sat, 25 May 2019 at 17:23 Ivan Serdyuk <local.tourist.kiev@...> wrote:
Hello.

I was wondering how to investigate the state of things around incompatibility of the level of C++ support, required to compile these bindings for ZeroMQ:

.

But that is rather is an aside target - I was assuming that it would make sense to develop aside binding, suitable for the limitations. The main target would be a compilation of a userspace lib in pure C - the previously mentioned binding and another binding:

. And again - I wonder how to perform auto-check for the compiler.

Ivan 

--
Rodrigo Peixoto
Co-founder and Technical advisor

+55 (82) 98144-8585
http://ayna.tech | Skype: rodrigopex


Checking compiler support for userspace C, C++ libs (ZeroMQ)

Ivan Serdyuk
 

Hello.

I was wondering how to investigate the state of things around incompatibility of the level of C++ support, required to compile these bindings for ZeroMQ:

.

But that is rather is an aside target - I was assuming that it would make sense to develop aside binding, suitable for the limitations. The main target would be a compilation of a userspace lib in pure C - the previously mentioned binding and another binding:

. And again - I wonder how to perform auto-check for the compiler.

Ivan 

Upcoming Event: Zephyr Project: Dev Meeting - Thu, 05/23/2019 8:00am-9:00am, Please RSVP #cal-reminder

devel@lists.zephyrproject.org Calendar <devel@...>
 

Reminder: Zephyr Project: Dev Meeting

When: Thursday, 23 May 2019, 8:00am to 9:00am, (GMT-07:00) America/Los Angeles

Where:https://zoom.us/j/993312203

An RSVP is requested. Click here to RSVP

Organizer: devel@...

Description: Join Zoom Meeting
https://zoom.us/j/993312203

One tap mobile
+16699006833,,993312203# US (San Jose)
+16465588656,,993312203# US (New York)

Dial by your location
        +1 669 900 6833 US (San Jose)
        +1 646 558 8656 US (New York)
        +1 877 369 0926 US Toll-free
        +1 855 880 1246 US Toll-free
Meeting ID: 993 312 203
Find your local number: https://zoom.us/u/ankEMRagf

Re: Moving external components out of the main tree

Nashif, Anas
 

Hi,

The first HAL (QMSI) was removed from the tree and the west manifest has been updated. Please make sure you run `west update` to update your trees.

 

 

Anas

 

 

 

From: devel@... [mailto:devel@...] On Behalf Of Nashif, Anas
Sent: Tuesday, May 21, 2019 10:27 PM
To: devel <devel@...>
Subject: [Zephyr-devel] Moving external components out of the main tree

 

Hi,

 

Most of you already use the west tool for various things already, including building, flashing, signing and other common operations. One of the main reasons west was introduced was to support building Zephyr with external modules hosted in external repositories. The first module that was split out of the tree was tinycbor and it seems to be working well. It is time now to start moving many of the external components out of the tree and keep the main zephyr code base as lean and as self-contained as possible and we have a few pull requests already lined up. The ultimate goal is to remove all HALs and external libraries to repositories maintained under the zephyr project org on github and yet maintain the main zephyr tree in a state that allows building a representative amount of configuration for testing purposes.

 

With the changes coming over the next few weeks you need to remember to update the environment with `west update` and pull the latest changes per the manifest from all configured modules. Failing to do so will result in inconsistent build results. So instead of just pulling zephyr (with zephyr pull or zephyr fetch) please make sure you use `west update` to get the latest state of the code in modules whenever the manifest changes.

 

For more information about module and how to submit changes to modules or how to submit a new module, visit:

 

https://docs.zephyrproject.org/latest/guides/modules.html

 

First batch of changes to move ext/ components into modules will start going into the tree starting tomorrow (Wed.)

 

Thanks,

Anas

 

 

 

Moving external components out of the main tree

Nashif, Anas
 

Hi,

 

Most of you already use the west tool for various things already, including building, flashing, signing and other common operations. One of the main reasons west was introduced was to support building Zephyr with external modules hosted in external repositories. The first module that was split out of the tree was tinycbor and it seems to be working well. It is time now to start moving many of the external components out of the tree and keep the main zephyr code base as lean and as self-contained as possible and we have a few pull requests already lined up. The ultimate goal is to remove all HALs and external libraries to repositories maintained under the zephyr project org on github and yet maintain the main zephyr tree in a state that allows building a representative amount of configuration for testing purposes.

 

With the changes coming over the next few weeks you need to remember to update the environment with `west update` and pull the latest changes per the manifest from all configured modules. Failing to do so will result in inconsistent build results. So instead of just pulling zephyr (with zephyr pull or zephyr fetch) please make sure you use `west update` to get the latest state of the code in modules whenever the manifest changes.

 

For more information about module and how to submit changes to modules or how to submit a new module, visit:

 

https://docs.zephyrproject.org/latest/guides/modules.html

 

First batch of changes to move ext/ components into modules will start going into the tree starting tomorrow (Wed.)

 

Thanks,

Anas

 

 

 

Re: submitting contributions to Zephyr

Nicolas Pitre
 

On Tue, 21 May 2019, Nathaniel Graff wrote:

I for one am definitely excited about a 64-bit RISC-V port of Zephyr!
That's coming! But that's the easy part. Making core Zephyr 64-bit clean
is the bulk of the work.

You might be interested in this tool from GitHub called ‘hub’: https://hub.github.com/ <https://hub.github.com/> It provides a command-line interface to GitHub’s web UI.
That's wonderful! Go figure why I didn't find it when looking exactly
for such a thing. Thanks!


Nicolas

Re: submitting contributions to Zephyr

Nathaniel Graff
 

Hi Nicholas!

I for one am definitely excited about a 64-bit RISC-V port of Zephyr!

You might be interested in this tool from GitHub called ‘hub’: https://hub.github.com/ It provides a command-line interface to GitHub’s web UI.

Nate

On May 21, 2019, at 2:22 PM, Nicolas Pitre <npitre@...> wrote:

Hello,

This is my first post here, however it probably won't be the last.

For a while I've been working on making Zephyr to compile for and run on
64-bit targets. That currently works with the native-posix target,
and 64-bit RISC-V is my next target.

I would like to submit my work for inclusion into the mainline Zephyr
repository. The documented submit and review procedures imply Github
forks and pull requests which involve going through hoops such as a
Javascript-capable web browser and that is not exactly like a walk in
the park for me (my background and credentials are available online if
you want to know why). That would make my life easier if there could
be some alternative way similar to how it is done with the Linux kernel.
Please let me know if that is possible.

I'm therefore posting my first patch here mainly to initiate a
conversation on this issue. Obviously I have many more of them.

----- >8
Subject: [PATCH] fix PTP clock test case

The various ptp_clock_driver_api methods receive a struct ptp_context
not a struct eth_context, and the later must be obtained from a reference
stored in the former. Failing to do so by directly interpreting
driver_data as a struct eth_context instance does end up corrupting
memory past the actual struct ptp_context storage. The test may still
pass as ptp_clock_get() reads from the same out-of-bounds memory as the
previous ptp_clock_set() and therefore the content matches, and with luck
the corrupted memory is not essential to the completion of the test.
But that wasn't my case which allowed me to find this issue.

Fix this by properly obtaining a reference to the struct eth_context
instance via the actual struct ptp_context, and adding one validation
test in my_ptp_clock_set() like the one found in eth_tx() to make sure
we got the right memory.

Signed-off-by: Nicolas Pitre <npitre@...>

diff --git a/tests/net/ptp/clock/src/main.c b/tests/net/ptp/clock/src/main.c
index 1625f6ec18..5d69164694 100644
--- a/tests/net/ptp/clock/src/main.c
+++ b/tests/net/ptp/clock/src/main.c
@@ -175,29 +175,40 @@ static u64_t timestamp_to_nsec(struct net_ptp_time *ts)
return (ts->second * NSEC_PER_SEC) + ts->nanosecond;
}

+struct ptp_context {
+ struct eth_context *eth_context;
+};
+
static int my_ptp_clock_set(struct device *dev, struct net_ptp_time *tm)
{
- struct eth_context *ctx = dev->driver_data;
+ struct ptp_context *ptp_ctx = dev->driver_data;
+ struct eth_context *eth_ctx = ptp_ctx->eth_context;

- memcpy(&ctx->time, tm, sizeof(struct net_ptp_time));
+ if (&eth_context_1 != eth_ctx && &eth_context_2 != eth_ctx) {
+ zassert_true(false, "Context pointers do not match\n");
+ }
+
+ memcpy(&eth_ctx->time, tm, sizeof(struct net_ptp_time));

return 0;
}

static int my_ptp_clock_get(struct device *dev, struct net_ptp_time *tm)
{
- struct eth_context *ctx = dev->driver_data;
+ struct ptp_context *ptp_ctx = dev->driver_data;
+ struct eth_context *eth_ctx = ptp_ctx->eth_context;

- memcpy(tm, &ctx->time, sizeof(struct net_ptp_time));
+ memcpy(tm, &eth_ctx->time, sizeof(struct net_ptp_time));

return 0;
}

static int my_ptp_clock_adjust(struct device *dev, int increment)
{
- struct eth_context *ctx = dev->driver_data;
+ struct ptp_context *ptp_ctx = dev->driver_data;
+ struct eth_context *eth_ctx = ptp_ctx->eth_context;

- ctx->time.nanosecond += increment;
+ eth_ctx->time.nanosecond += increment;

return 0;
}
@@ -207,10 +218,6 @@ static int my_ptp_clock_rate_adjust(struct device *dev, float ratio)
return 0;
}

-struct ptp_context {
- struct eth_context *eth_context;
-};
-
static struct ptp_context ptp_test_1_context;
static struct ptp_context ptp_test_2_context;










submitting contributions to Zephyr

Nicolas Pitre
 

Hello,

This is my first post here, however it probably won't be the last.

For a while I've been working on making Zephyr to compile for and run on
64-bit targets. That currently works with the native-posix target,
and 64-bit RISC-V is my next target.

I would like to submit my work for inclusion into the mainline Zephyr
repository. The documented submit and review procedures imply Github
forks and pull requests which involve going through hoops such as a
Javascript-capable web browser and that is not exactly like a walk in
the park for me (my background and credentials are available online if
you want to know why). That would make my life easier if there could
be some alternative way similar to how it is done with the Linux kernel.
Please let me know if that is possible.

I'm therefore posting my first patch here mainly to initiate a
conversation on this issue. Obviously I have many more of them.

----- >8
Subject: [PATCH] fix PTP clock test case

The various ptp_clock_driver_api methods receive a struct ptp_context
not a struct eth_context, and the later must be obtained from a reference
stored in the former. Failing to do so by directly interpreting
driver_data as a struct eth_context instance does end up corrupting
memory past the actual struct ptp_context storage. The test may still
pass as ptp_clock_get() reads from the same out-of-bounds memory as the
previous ptp_clock_set() and therefore the content matches, and with luck
the corrupted memory is not essential to the completion of the test.
But that wasn't my case which allowed me to find this issue.

Fix this by properly obtaining a reference to the struct eth_context
instance via the actual struct ptp_context, and adding one validation
test in my_ptp_clock_set() like the one found in eth_tx() to make sure
we got the right memory.

Signed-off-by: Nicolas Pitre <npitre@...>

diff --git a/tests/net/ptp/clock/src/main.c b/tests/net/ptp/clock/src/main.c
index 1625f6ec18..5d69164694 100644
--- a/tests/net/ptp/clock/src/main.c
+++ b/tests/net/ptp/clock/src/main.c
@@ -175,29 +175,40 @@ static u64_t timestamp_to_nsec(struct net_ptp_time *ts)
return (ts->second * NSEC_PER_SEC) + ts->nanosecond;
}

+struct ptp_context {
+ struct eth_context *eth_context;
+};
+
static int my_ptp_clock_set(struct device *dev, struct net_ptp_time *tm)
{
- struct eth_context *ctx = dev->driver_data;
+ struct ptp_context *ptp_ctx = dev->driver_data;
+ struct eth_context *eth_ctx = ptp_ctx->eth_context;

- memcpy(&ctx->time, tm, sizeof(struct net_ptp_time));
+ if (&eth_context_1 != eth_ctx && &eth_context_2 != eth_ctx) {
+ zassert_true(false, "Context pointers do not match\n");
+ }
+
+ memcpy(&eth_ctx->time, tm, sizeof(struct net_ptp_time));

return 0;
}

static int my_ptp_clock_get(struct device *dev, struct net_ptp_time *tm)
{
- struct eth_context *ctx = dev->driver_data;
+ struct ptp_context *ptp_ctx = dev->driver_data;
+ struct eth_context *eth_ctx = ptp_ctx->eth_context;

- memcpy(tm, &ctx->time, sizeof(struct net_ptp_time));
+ memcpy(tm, &eth_ctx->time, sizeof(struct net_ptp_time));

return 0;
}

static int my_ptp_clock_adjust(struct device *dev, int increment)
{
- struct eth_context *ctx = dev->driver_data;
+ struct ptp_context *ptp_ctx = dev->driver_data;
+ struct eth_context *eth_ctx = ptp_ctx->eth_context;

- ctx->time.nanosecond += increment;
+ eth_ctx->time.nanosecond += increment;

return 0;
}
@@ -207,10 +218,6 @@ static int my_ptp_clock_rate_adjust(struct device *dev, float ratio)
return 0;
}

-struct ptp_context {
- struct eth_context *eth_context;
-};
-
static struct ptp_context ptp_test_1_context;
static struct ptp_context ptp_test_2_context;

Re: [Zephyr-builds] zephyr build env for external module

Nashif, Anas
 

Qipeng,

You should be posting to the devel@ mailing list instead.

To answer your question, this is not supported in zephyr.

 

Anas

 

From: <builds@...> on behalf of "Zha, Qipeng" <qipeng.zha@...>
Date: Tuesday, 21 May 2019 at 06:33
To: "Zephyr-builds@..." <Zephyr-builds@...>
Subject: [Zephyr-builds] zephyr build env for external module

 

Hi

 

In Linux, there will be some driver modules are external, can be put outside in linux kernel tree and build with a simple Makefile.

For zephyr, is there similar usage can work as this ?   thx.

 

 

 

Best wishes

Qipeng