Date   

Re: Help required on reading UART device and print on console

Erwan Gouriou
 

To answer your initial question, below example should work
 
   struct device *uartGPS;
   uartGPS = device_get_binding(CONFIG_UART_STM32_PORT_1_NAME);

    while (1) {
        unsigned char recvChar;
        while (uart_poll_in(uartGPS, &recvChar) < 0)
            ;
        printk("%c", recvChar);
    }

Besides, for the device tree issue, please see my answer in https://jira.zephyrproject.org/browse/ZEP-2125
Patch is provided, we'll see if we upstream it.

Erwan


On 9 May 2017 at 15:30, Erwan Gouriou <erwan.gouriou@...> wrote:
Hi Dhamu,

I saw the task you entered in Jira afterwards and now better understand your question.
Indeed, you might need additional settings to get these ports working:
One point is that you should activate them in dts files and nucleo_l476rg_defconfig.
Also, please check that GPIO ports are activated according to your pinmuxing.
I'll have a check and get back to you.

A sample test was present some time ago, but it has been moved to tests section and now is more adapted to extensive testing rather than simple (re-)use.
Re-instanciating a basic serial sample might indeed be a good idea.

Regards
Erwan


On 9 May 2017 at 15:12, Dhamodharan Krishnan <dhamukrish@...> wrote:
Thanks Erwan for your reply.

Basically, I was able to use UART2 without any issue. But I have GPS and GSM modules which are serial device and hence need UART1 and 3 apart from UART2 for fetching and processing the data.

Would be very helpful if any example or advise much appreciated.

Regards
Dhamu


On 09-May-2017, at 12:48 PM, Erwan Gouriou <erwan.gouriou@...> wrote:

Hi Digidhamu,


If you're trying to use default UART (through ST link USB port) on nucleo_l476rg, you should use UART_2.

Erwan






On 6 May 2017 at 09:53, Dhamodharan Krishnan <dhamukrish@...> wrote:
Hi,

I am a day old since I started in Zephyr and from Arduino background. Could you please help with an example how to read from UART ports which are from 

Here is the code I have tried but failed.

#include <zephyr.h>
#include <misc/printk.h>
#include <uart.h>

int main(void) {

struct device *uartGPS;
uartGPS = device_get_binding(UART_1);

while (1) {
unsigned char* msg;
uart_poll_in(uartGPS, msg);

printk("%s", msg);
}
}

Regards
digidhamu


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






Re: [RFC] Touchscreen driver API

Jon Medhurst (Tixy) <tixy@...>
 

On Tue, 2017-05-09 at 13:54 +0200, Tomasz Bursztyka wrote:
Hi Jon,

I don't know much about touchscreens myself but as a sensor, because it
basically is one,
is there any reason why you specifically did not make this with sensor API?
The main reason is that I hadn't thought of doing so ;-)

Just had a look at the sensor APIs and they could possibly work.
Two immediate questions spring to mind.

1. How to handle screen touched/not-touched state.
2. What units would a touchscreen use for it's values?

For 1, we could decide a special Z value meant screen-not-touched. Or
have a new trigger type for screen-not-touched events. With the latter,
the user would have two different trigger functions (for not-touched and
for data available), requiring the driver and user to be careful not to
get in a mess with any concurrent access by these two sources.

For 2, if we returned display pixel coordinates, then the complicated
translation function for converting the touchscreen values to display
coordinates would have to always be done, which could be an unnecessary
overhead for some users. Also, the application or user wouldn't be able
to get at the raw values in order to calibrate the system for that
coordinate translation. Possibly we'd need to support both raw and
screen values?

If the sensor driver did the coordinates translation, the sensor API
needs to gain a possibly messy new function for setting some touchscreen
calibration method (of which there could be many). So I'd favour just
returning raw touchscreen sample values the hardware produces and make
the user use other methods to convert that into more relevant
information. Though that doesn't seem to fit with current sensor types
which return well defined SI unit values.

--
Tixy


Re: Help required on reading UART device and print on console

Erwan Gouriou
 

Hi Dhamu,

I saw the task you entered in Jira afterwards and now better understand your question.
Indeed, you might need additional settings to get these ports working:
One point is that you should activate them in dts files and nucleo_l476rg_defconfig.
Also, please check that GPIO ports are activated according to your pinmuxing.
I'll have a check and get back to you.

A sample test was present some time ago, but it has been moved to tests section and now is more adapted to extensive testing rather than simple (re-)use.
Re-instanciating a basic serial sample might indeed be a good idea.

Regards
Erwan


On 9 May 2017 at 15:12, Dhamodharan Krishnan <dhamukrish@...> wrote:
Thanks Erwan for your reply.

Basically, I was able to use UART2 without any issue. But I have GPS and GSM modules which are serial device and hence need UART1 and 3 apart from UART2 for fetching and processing the data.

Would be very helpful if any example or advise much appreciated.

Regards
Dhamu


On 09-May-2017, at 12:48 PM, Erwan Gouriou <erwan.gouriou@...> wrote:

Hi Digidhamu,


If you're trying to use default UART (through ST link USB port) on nucleo_l476rg, you should use UART_2.

Erwan






On 6 May 2017 at 09:53, Dhamodharan Krishnan <dhamukrish@...> wrote:
Hi,

I am a day old since I started in Zephyr and from Arduino background. Could you please help with an example how to read from UART ports which are from 

Here is the code I have tried but failed.

#include <zephyr.h>
#include <misc/printk.h>
#include <uart.h>

int main(void) {

struct device *uartGPS;
uartGPS = device_get_binding(UART_1);

while (1) {
unsigned char* msg;
uart_poll_in(uartGPS, msg);

printk("%s", msg);
}
}

Regards
digidhamu


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





Re: Help required on reading UART device and print on console

Dhamodharan Krishnan <dhamukrish@...>
 

Thanks Erwan for your reply.

Basically, I was able to use UART2 without any issue. But I have GPS and GSM modules which are serial device and hence need UART1 and 3 apart from UART2 for fetching and processing the data.

Would be very helpful if any example or advise much appreciated.

Regards
Dhamu

On 09-May-2017, at 12:48 PM, Erwan Gouriou <erwan.gouriou@...> wrote:

Hi Digidhamu,


If you're trying to use default UART (through ST link USB port) on nucleo_l476rg, you should use UART_2.

Erwan






On 6 May 2017 at 09:53, Dhamodharan Krishnan <dhamukrish@...> wrote:
Hi,

I am a day old since I started in Zephyr and from Arduino background. Could you please help with an example how to read from UART ports which are from 

Here is the code I have tried but failed.

#include <zephyr.h>
#include <misc/printk.h>
#include <uart.h>

int main(void) {

struct device *uartGPS;
uartGPS = device_get_binding(UART_1);

while (1) {
unsigned char* msg;
uart_poll_in(uartGPS, msg);

printk("%s", msg);
}
}

Regards
digidhamu


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




Re: [RFC] Touchscreen driver API

Tomasz Bursztyka
 

Hi Jon,

I don't know much about touchscreens myself but as a sensor, because it basically is one,
is there any reason why you specifically did not make this with sensor API?

Some of the existing attributes and functions there seem really meant for such usage.

If things are missing in sensor API, wouldn't it be worth improving that API then?

Br,

Tomasz


[RFC] Touchscreen driver API

Jon Medhurst (Tixy) <tixy@...>
 

Hello all

Zephyr doesn't have any API defined for touchscreen devices so when
writing a driver for one I needed to design an API. Below is what I came
up with and I wanted to request comments about it, with the intent of it
becoming a generic API others could use.

The driver interface is basically 2 functions:
- touchscreen_set_callback() to register a callback for notification

when samples are available.
- touchscreen_get_sample() to get a sample
(X,Y,Z value).

I also wrote some helper functions to translate touchscreen coordinates
to display coordinates:
- touchscreen_set_calibration() initialise coordinate translation params
- touchscreen_translate() translate an X,Y point

The actual header file with the API...


/** A single sample of the touchscreen's state */
struct touchscreen_sample {
/** Sampled value for touchscreen X position */
u16_t x;
/** Sampled value for touchscreen Y position */
u16_t y;
/** Sampled value for touchscreen Z (pressure) position */
u16_t z;
/** Flags associated with this sample */
u16_t flags;
};

/* Following #defines are for flags in struct touchscreen_sample */

/** Touchscreen is being touched */
#define TOUCHSCREEN_TOUCHED (1 << 0)

/* API to be implemented by touchscreen drivers */
struct touchscreen_api {
/* Get the next sample of the touchscreen state */
int (*get_sample)(struct device *dev,
struct touchscreen_sample *sample);
/* Set the callback function to be called when a sample is available */
void (*set_callback)(struct device *dev,
void (*callback)(struct device *));
};

/**
* @brief Get a sample from the touchscreen.
*
* @param dev Pointer to the device structure for the driver instance.
* @param sample Pointer to the sample to update.
*
* @return 0 on success, -EAGAIN if no more samples available,
* otherwise negative error value.
*/
static inline int touchscreen_get_sample(struct device *dev,
struct touchscreen_sample *sample)
{
const struct touchscreen_api *api = dev->driver_api;

return api->get_sample(dev, sample);
}

/**
* @brief Set the callback function.
*
* The callback function will be called when one or more samples becomes
* available. It may be executed in any any context, e.g. ISR or thread context,
* or may be called during the execution of touchscreen_get_sample(). Therefore
* the function mustn't itself use touchscreen_get_sample() or make use of
* kernel services that aren't safe from interrupt context.
*
* A typical action for the callback is to simply signal a semaphore or trigger
* some work on a workqueue.
*
* The callback function won't be called again until all samples have been
* retrieved, i.e. until the call to touchscreen_get_sample() which returned
* -EAGAIN.
*
* @param dev Pointer to the device structure for the driver instance.
* @param callback Pointer to the callback function.
*/
static inline void touchscreen_set_callback(struct device *dev,
void (*callback)(struct device *))
{
const struct touchscreen_api *api = dev->driver_api;

api->set_callback(dev, callback);
}


#ifdef CONFIG_TOUCHSCREEN_HELPERS

/** X,Y coordinates for a point on the touchscreen or display. */
struct touchscreen_point {
u16_t x;
u16_t y;
};

/**
* @brief Touchscreen coordinate translation parameters
*
* These are initialised by calling touchscreen_set_calibration().
* Members should be considered private and not accessed directly.
*/
struct touchscreen_xlat {
s64_t A;
s64_t B;
s64_t C;
s64_t D;
s64_t E;
s64_t F;
};

/**
* @brief Initialise touchscreen coordinate translation parameters.
*
* This requires that three different and valid display/touchscreen coordinate
* pairs are known.
*
* @param xlat Translation parameters to be initialised.
* @param touchscreen Three touchscreen coordinates that correspond to the
* given display coordinates.
* @param display Three display coordinates that correspond to the given
* touchscreen coordinates.
*/
void touchscreen_set_calibration(struct touchscreen_xlat *xlat,
const struct touchscreen_point touchscreen[3],
const struct touchscreen_point display[3]);

/**
* @brief Translate touchscreen coordinates into screen coordinates.
*
* Convert a touchscreen X,Y sample into the corresponding display X,Y
* coordinates by using the previously initialised translation parameters.
*
* @param xlat Translation parameters.
* @param touch_x Touchscreen X sample
* @param touch_y Touchscreen Y sample
* @param dislpay_x Display X coordinate
* @param dislpay_x Display Y coordinate
*/
void touchscreen_translate(struct touchscreen_xlat *xlat,
int touch_x, int touch_y,
int *display_x, int *display_y);

#endif /* CONFIG_TOUCHSCREEN_HELPERS */


Re: Help required on reading UART device and print on console

Erwan Gouriou
 

Hi Digidhamu,


If you're trying to use default UART (through ST link USB port) on nucleo_l476rg, you should use UART_2.

Erwan






On 6 May 2017 at 09:53, Dhamodharan Krishnan <dhamukrish@...> wrote:
Hi,

I am a day old since I started in Zephyr and from Arduino background. Could you please help with an example how to read from UART ports which are from 

Here is the code I have tried but failed.

#include <zephyr.h>
#include <misc/printk.h>
#include <uart.h>

int main(void) {

struct device *uartGPS;
uartGPS = device_get_binding(UART_1);

while (1) {
unsigned char* msg;
uart_poll_in(uartGPS, msg);

printk("%s", msg);
}
}

Regards
digidhamu


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



Re: RFC: Clarifying UART API

Paul Sokolovsky
 

Hello Daniel,

On Mon, 8 May 2017 14:32:56 +0100
Daniel Thompson <daniel.thompson@...> wrote:

[]

Interpretation 1:
"ready" means "ready to accept more chars to transmit", "empty"
means "transmission complete".

Interpretation 2:
"empty" means "there's empty room in TX FIFO (so more chars can be
written to it)", "ready" means "transmission complete".
Perhaps we should note that interpretation 1 is the "right" one in
the sense that this is what the current implementations of the API
currently approximate to.
Yes, I kinda implied that, and that's why I sent this RFC ahead of full
analysis of each and every existing drivers/serial/ case, but just
confirming on my side your previous suggestion to use uart_ns16550.c
driver as the reference.

I also view interpretation #2 is only possible when the reasoner
neglects the FIFO since when there is a FIFO we have to redefine the
normal meaning of empty[1] to mean not-full.
I don't agree here. It's very easy to get to that interpretation by
reading almost any hardware datasheet, even 16550 itself have things
called "Transmitter Holding Register Empty" and "Transmitter Empty",
the first meaning it can slurp more, while latter meaning it's done.
And yep, FIFO is always optional, so reasoning should start without it,
and then FIFO should be consistently integrated into it.

[]

I'm proposing to make the following changes to deconfuse it:

1. Given that there's a (sole) uart_irq_rx_ready() with the meaning
"there's a char ready to be received", it's natural to leave
uart_irq_tx_ready() as it is, and explicitly describe as "TX block
is ready to accept a char for a transmission".
Agree. Perhaps phrase as "accept at least one char for a
transmission".
Sure, there would be a patch review where the exact formulation cab be
polished.


Note a couple of existing drivers check their interrupt mask and only
admit to being ready if their interrupt is enabled. These drivers are
anomalous and should be fixed to meet the above anyway.
I kind of agree that it would be almost unrealistic to enforce behavior
like "if irq_rx_disable() was called, then irq_rx_ready() should always
return false". Then, any driver which so far does that in software can
be made few bytes shorter and few cycles faster by removing the ANDing
stuff.

[]

Similarly I agree that uart_irq_tx_complete() is a useful addition to
the API.

Sorry to make you read to far just to find out that this RFC gets a
+1 from me...
I definitely appreciate detailed multi-faceted discussion of the matter,
though with all discussion we already had in previous mails, in
tickets, on IRC, I wonder if sometimes we lose track that the top-level
goal of this effort is improving Zephyr's console subsystem, not just
speculative research in UART "zoology" ;-).

Thanks!


Daniel.


--
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: RFC: Clarifying UART API

Daniel Thompson <daniel.thompson@...>
 

On 08/05/17 11:45, Paul Sokolovsky wrote:
Hello,
We have a problem in the UART (and UART driver) API very akin to the
proverbial half-empty vs half-full glass problem. So, there're 2
interrupt testing predicates:
* uart_irq_tx_ready()
* uart_irq_tx_empty()
What would each of them mean? Reading docstrings won't get you very
far, e.g. description of uart_irq_tx_ready() is "Check if Tx IRQ has
been raised", which is absolutely correct and absolutely useless, as
uart_irq_tx_empty() also means that Tx IRQ was raised, albeit a
different kind of IRQ.
Then thinking what they would mean, it becomes clear that they may mean
two *opposite* things:
Interpretation 1:
"ready" means "ready to accept more chars to transmit", "empty" means
"transmission complete".
Interpretation 2:
"empty" means "there's empty room in TX FIFO (so more chars can be
written to it)", "ready" means "transmission complete".
Perhaps we should note that interpretation 1 is the "right" one in the sense that this is what the current implementations of the API currently approximate to.

I also view interpretation #2 is only possible when the reasoner neglects the FIFO since when there is a FIFO we have to redefine the normal meaning of empty[1] to mean not-full.

Having said that, an API definition that relies on the reader intuiting the existence of FIFOs that may not event exist on their favorite test platform solely in order to comprehend an API is *seriously* user hostile!

[1] empty (adj.), Devoid of content; containing nothing or nobody;
vacant [this is the definition from wiktionary ;-) ].


The possibility of such U-turn'ish interpretation is alone a problem
for the good API design, and coupled with vagueness of the docs, it
becomes a real hazard, and we already saw signs of these completely
different interpretation being used in drivers/serial (specifically,
STM32 driver looked like trying to use interpretation 2).
I'm proposing to make the following changes to deconfuse it:
1. Given that there's a (sole) uart_irq_rx_ready() with the meaning
"there's a char ready to be received", it's natural to leave
uart_irq_tx_ready() as it is, and explicitly describe as "TX block is
ready to accept a char for a transmission".
Agree. Perhaps phrase as "accept at least one char for a transmission".

Note a couple of existing drivers check their interrupt mask and only admit to being ready if their interrupt is enabled. These drivers are anomalous and should be fixed to meet the above anyway.


2. Naming of uart_irq_tx_empty() is however strictly confusing, so
the proposal is to rename it to uart_irq_tx_complete(), and
explicitly describe that usecase behind it is knowing when the UART (or
the whole system) can be powered off, and not for the buffer control
during normal RX/TX UART operations.
Agree entirely on the proposal although with an alternative reasoning.

For me the real problem with uart_irq_tx_empty() is that I struggle to find any use case for it!

It is broken for power management because having an empty FIFO does not imply that it is safe to turn off the cell because it may still be shifting out the final character (in most designs the TX shift register is not part of the FIFO).

It is also pointless for implementing half duplex protocols for pretty much the same reason.

So what is this uart_irq_tx_empty() *for*? If we don't have a good answer then we should discard or depreciate it.

Similarly I agree that uart_irq_tx_complete() is a useful addition to the API.

Sorry to make you read to far just to find out that this RFC gets a +1 from me...


Daniel.


RFC: Clarifying UART API

Paul Sokolovsky
 

Hello,

We have a problem in the UART (and UART driver) API very akin to the
proverbial half-empty vs half-full glass problem. So, there're 2
interrupt testing predicates:

* uart_irq_tx_ready()
* uart_irq_tx_empty()

What would each of them mean? Reading docstrings won't get you very
far, e.g. description of uart_irq_tx_ready() is "Check if Tx IRQ has
been raised", which is absolutely correct and absolutely useless, as
uart_irq_tx_empty() also means that Tx IRQ was raised, albeit a
different kind of IRQ.

Then thinking what they would mean, it becomes clear that they may mean
two *opposite* things:

Interpretation 1:
"ready" means "ready to accept more chars to transmit", "empty" means
"transmission complete".

Interpretation 2:
"empty" means "there's empty room in TX FIFO (so more chars can be
written to it)", "ready" means "transmission complete".


The possibility of such U-turn'ish interpretation is alone a problem
for the good API design, and coupled with vagueness of the docs, it
becomes a real hazard, and we already saw signs of these completely
different interpretation being used in drivers/serial (specifically,
STM32 driver looked like trying to use interpretation 2).


I'm proposing to make the following changes to deconfuse it:

1. Given that there's a (sole) uart_irq_rx_ready() with the meaning
"there's a char ready to be received", it's natural to leave
uart_irq_tx_ready() as it is, and explicitly describe as "TX block is
ready to accept a char for a transmission".

2. Naming of uart_irq_tx_empty() is however strictly confusing, so
the proposal is to rename it to uart_irq_tx_complete(), and
explicitly describe that usecase behind it is knowing when the UART (or
the whole system) can be powered off, and not for the buffer control
during normal RX/TX UART operations.



--
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: BSD Sockets like API: prototyping report #3

Paul Sokolovsky
 

Hello,

On Thu, 4 May 2017 17:47:17 +0300
Paul Sokolovsky <Paul.Sokolovsky@...> wrote:

[]

b) My "ultimate" test was supposed to be downloading large files (tens
of MBs) from http://archive.ubuntu.com/, checking their hash (I'm
using that site as it readily offers hash values for different
algorithms), then repeating to collect enough traffic (ultimately
mentioned gigabyte). Unfortunately, I didn't have much luck with this
"ambitious" goal. Overall, I got 100% TCP hang on byte counts ranging
from 100Kbs to ~10MB.
I figured out this issue - it's because Zephyr IP stack doesn't
anticipate the possibility that its ACK may be lost. Then peer will
resend a packet Zephyr already saw, and it doesn't like that. This is
ticketed as https://jira.zephyrproject.org/browse/ZEP-2121 .

With workaround for that applied, I didn't have problems with prolonged
downloads from the real Internet:

========
...
Received already seen pkt - ACKing
Received already seen pkt - ACKing
Received already seen pkt - ACKing
Making sure FIN goes with ACK; adjusting seq by 2; now fire up Wireshark and check that all's ok
Size : 7015896
Hash : 337c37d7ec00348414224baa6bdb2d43f2a34ef5676bafcdcad916f148b5b317
Total downloaded so far: 160M
========


Summing up, basic testing with a convenient to use API (BSD Sockets)
and easy to use environment to exercise that API (MicroPython) quickly
uncovered 3 critical issues in Zephyr IP stack, and few more less
serious, which shows the potential ;-).


[]

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


Help required on reading UART device and print on console

Dhamodharan Krishnan <dhamukrish@...>
 

Hi,

I am a day old since I started in Zephyr and from Arduino background. Could you please help with an example how to read from UART ports which are from 

Here is the code I have tried but failed.

#include <zephyr.h>
#include <misc/printk.h>
#include <uart.h>

int main(void) {

struct device *uartGPS;
uartGPS = device_get_binding(UART_1);

while (1) {
unsigned char* msg;
uart_poll_in(uartGPS, msg);

printk("%s", msg);
}
}

Regards
digidhamu


RFC: Fault injection framework for Zephyr

Paul Sokolovsky
 

Hello,

It's fair to say that we're seeing the need to better test various
error handling paths in Zephyr, for example, in networking code.

This is commonly handled with fault injection. I grepped thru Jira, and
didn't find anything related, so decided to open a story on that:
https://jira.zephyrproject.org/browse/ZEP-2118 .

I don't think it's anyhow a priority for 1.8, so I'm posting this
mostly FYI and to avoid possible duplication. If you have any ideas,
it's probably best to add the comments to the ticket above.


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


BSD Sockets like API: prototyping report #3

Paul Sokolovsky
 

Hello,

This report is quite overdue, and I hoped to have sent it weeks ago, as
the initial implementation of all the basic functions were done long
ago. But I wanted to back it with automated easily reproducible
testing, as well as test against real-world sites or well-known
networking servers with real data sizes (like an odd gigabyte) - and
both aims turned out to be elusive, requiring excursions in unrelated
areas (like UART handling in Zephyr, still ongoing) and many more
investigation and fixes.

Well, now things more or less got together:

1. There's implementation of the following function (with Python
interface, which would still require some refactoring to turn them into
C ones): socket(), bind(), connect(), listen(), accept(), recv(),
send(), close(), getaddrinfo(). Only blocking sockets are supported so
far.

2. These are implemented in "usocket" module of MicroPython, in
"zephyr-socket2" branch:
https://github.com/pfalcon/micropython/blob/zephyr-socket2/zephyr/modusocket.c
To work as expected, this requires master with some additional patches
applied: https://github.com/pfalcon/zephyr/tree/master-micropython .

3. It was tested in following ways:

a) There few (4) automated tests, for basic UDP functionality.
Unfortunately, TCP tests don't work in this manner,
https://jira.zephyrproject.org/browse/ZEP-2001.

b) My "ultimate" test was supposed to be downloading large files (tens
of MBs) from http://archive.ubuntu.com/, checking their hash (I'm using
that site as it readily offers hash values for different algorithms),
then repeating to collect enough traffic (ultimately mentioned
gigabyte). Unfortunately, I didn't have much luck with this "ambitious"
goal. Overall, I got 100% TCP hang on byte counts ranging from
100Kbs to ~10MB. A raw TCP connection hanging is an expected situation
in general (in real-world apps, that's countered by having connection
timeout), but hitting that in 100% of cases would mean that something
not yet fully right with Zephyr stack handling of non-successful
conditions (like retransmits, backoffs, etc.).

c) So, I had to scale down to use my local Apache server. There
everything went much better, and I was able to download ~300MB at the
first try (sorry, keep forgetting to leave it overnight for the
proverbial gigibyte). So, overall, "success" flow is ok both on Zephyr
side and on BSD prototype side, there're no buffer leaks, etc. (Again,
"non-success" cases where there's need for some recovery and retries
is a different story). This concludes (initial) client-side testing.

d) Trying server-side handling, I immediately hit an issue with
(case-dependent) FIN handling:
https://jira.zephyrproject.org/browse/ZEP-2104. Working that around
(proper fix yet needs investigation), I'm happy to report that a simple
HTTP server sample sustains 1000 requests from ApacheBench (ab -n 1000
http://192.0.2.1:8080/).



Further plans:

1. There are some optimizations to do yet on the current code, before
separating socket functions from MicroPython boilerplate.

2. It's clear that in-tree patches won't be ready before 1.8 release
freeze, so instead I plan to concentrate on trying to flush any
smaller changes which may be useful for mainline already, and on
investigating identified issues.




--
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: RFC: TCP receive/send window handling in Zephyr IP stack

Paul Sokolovsky
 

Hello Jukka,

On Tue, 02 May 2017 17:32:30 +0300
Jukka Rissanen <jukka.rissanen@...> wrote:

[]

https://jira.zephyrproject.org/browse/ZEP-1999 .

So, as the issue is confirmed, I would like to proceed with
resolving it, and this RFC is about ways to do it.
Thanks for pushing this, we definitely have an issue with the rcv wnd
handling.
Thanks for supporting it. Given that I won't have time to prepare BSD
Sockets API patches for 1.8, I'm switching instead on trying to resolve
as many issues as was spotted during its prototyping work for 1.8
timeframe.

lwIP offers a very simple and easy to understand model of that: IP
stack only decreases the available receive window, never increases
it,
it's a task of application code. When an application really
processes received data (vs just buffering it), it calls a special
function (called tcp_recved()) to advance the window.
[]

way to do that would be to change recv callback signature from:

typedef void (*net_context_recv_cb_t)(struct net_context *context,
                                      struct net_pkt *pkt,
                                      int status,
                                      void *user_data);

to one returning u32_t, the size by which to advance the receive
window. For each existing recv callback, that would be
net_pkt_appdatalen(pkt), so we can try to optimize that one step
further by defining some constant and allowing to return it:

return NET_ADVANCE_WHOLE_PKT;
I like this better than an application manually calling a special
function to do the trick like what was found in the gerrit patch.
I see. And I on my side was pondering these days about the comment you
gave in Gerrit review: "Why cannot we call this directly inside the
stack when we receive data?"

Is it likely that the application would not move the window for full
packet? I mean what would happen if we always move the window the
received data amount automatically by the core stack after we return
from recv cb?
So, that would be almost the same as it is now, except that currently
receive window moved (i.e. ack value updated) before calling recv cb.
It's definitely more correct to move it after, but the difference in
behavior probably will be negligible in practice, and it won't help
applications which *buffer* incoming packets, like what BSD Sockets API
does.

The net_buf's should be released anyway by the
application asap, otherwise we have possible memory leak.
Not memory leak, but buffering ;-). So, returning to your idea of doing
it completely automatically, like a grown-up IP stack. The whole idea
is that receive window should be moved not when packet *received* (and
that's the event which recv_cb signals), but when data in packet is
*processed* (which may be much later due to buffering).

How can we know that application finished processing? Again, simple
stacks like lwIP require explicit notification of that. But how to do
it otherwise? Well, we know that data processing was 100% finished when
a network buffer holding it is freed. Hopefully, that gives enough of
insight on the idea, and you can comment - how do you like that
net_buf_frag_del() and friends will now update TCP structures related
to a fragment - at the minimum, at the maximum they may trigger an
outgoing packet to be sent (to notify peer of the window update).

Unfortunately, that's inevitable - TCP for efficient implementation
requires close enough coupling with IP and buffer management. Again,
apparently to simplify that lwIP put window update step in the user app
instead. I'll submit a patch for MTU handling for outgoing packets
soon, which already exposes this problem of the need to intermingle
different "layers" of API (so, we would need to stop thinking about
them as different layers, just as one).

Is it likely that the application would not move the window for full
packet?
Fairly speaking, we should move window as soon as we're able to
receive new data chunk. As we allocate data chunks in fragment buffers,
freeing one would be already a good ground to update recv window. But:
recv window is measured in terms of data bytes, but we receive data in
terms of packets, which have protocol headers overhead. So, if we got 1
fragment buffer freed (128 bytes), if we announce that to peer, we'll
get 128 + 40 (IPv4) bytes back. If we had only one fragment buffer,
this packet will be dropped, and everything will be as bad as it is now
(exponential backoff triggering, etc.)

So, it's not that easy, but I'm excited about the idea to try to do it
fully automatic, and as I said, I was pondering about it all these days,
and hope to proceed to experimenting a bit later. Overall, recv/send
window handling will require various rules, majority of which would be
heuristic. lwIP for one, even if receives window updates from an app,
does quite a lot of magic with them before they go into real packets.

[]

--
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: Move to Github completed and some issue

Leandro Pereira
 

Andrew,

On 05/03/2017 08:30 AM, Boie, Andrew P wrote:

I would like to leverage this so that I can have Zephyr notifications sent to my Intel email address and not my personal Gmail. I can’t figure out how to do this however. I have both email accounts verified in the Github system. Any pointers?
This is only possible if you're a member of the organization. Right now, as far as I can tell, people are mostly contributors to the "zephyr" repository there. This is in the pipeline to be fixed.

Leandro


Re: Zephyr JSON API can't find missing fields in sub-objects

Leandro Pereira
 

Marti,

On 05/02/2017 10:07 PM, Marti Bolivar wrote:

However, when I parse this, I can tell whether "config" or "_links" is
present in the top-level JSON object using the return value from
json_obj_parse(), but I can't tell if its subobjects (the
"deploymentBase", "cancelAction" etc. in "_links") are present or not.
That's indeed a known limitation.


One way to do this would be to introduce a u32_t in each structure
(hawkbit_ctl_res_sleep, hawkbit_ctl_res_polling, hawkbit_ctl_res_href,
hawkbit_ctl_res_links) recording whether or not each of the "real"
fields is present, and have the JSON API fill this value recursively
as it parses. This would let me decide what fields are present at all
levels in the parsed hierarchy.

Does this seem reasonable? Does anyone else have other suggestions?
In this case, it might be sufficient to zero out the struct hawkbit_ctl_res struct, and then just NULL-check _links.cancelAction.href or _links.deploymentBase.href. It's not the ideal generic solution but will work for strings at least.

For the general case, it might be worth doing something like you mentioned, but making the added integer member optional. One way to do this is to consider cases like this as union cases:

struct links {
union {
struct href deploymentBase;
struct href cancelAction;
};
struct href configData;
u32 fields;
};

The `fields` member would have 1<<0 set if deploymentBase was decoded, 1<<1 if cancelAction was decoded, and 1<<2 if configData was decoded. The href struct wouldn't need a `fields` member of its own since it's not a union case.

Now, using a union wouldn't work if deploymentBase and cancelAction could be set at the same time. In this case, one just removes the union declaration, and things should work. The only confusing bit is that this would still be a union case, but without the declaration of a union properly.

Cheers,
Leandro


Re: Move to Github completed and some issue

Boie, Andrew P
 

Github appears to have a feature where you can have notification emails to sent to different email addresses depending on the ‘organization’ that owns a particular project. Under Personal Settings -> Notifications -> Custom Routing: “You can send notifications to different verified email addresses depending on the organization that owns the repository.”

 

I would like to leverage this so that I can have Zephyr notifications sent to my Intel email address and not my personal Gmail. I can’t figure out how to do this however. I have both email accounts verified in the Github system. Any pointers?

 

 

 

From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of Nashif, Anas
Sent: Wednesday, May 3, 2017 2:19 AM
To: Zephyr Devel <devel@...>
Subject: [Zephyr-devel] Move to Github completed and some issue

 

Hi,

We are now on github and PRs are flowing in, CI is operational as expected and we are getting used to the new flow.

 

Thank you for all who helped make this happen.

 

Now, we have been on gerrit for a while and we have been used to doing things in a certain way and a change in mindset is needed. Github has its own way of doing things and we need to adapt, one thing we immediately noticed is the fact that no everyone can add reviewers… This can only be done by users with write access to a specific repo. We are trying a few things to deal with that. In gerrit we used to add many reviewers using a script and we want to continue doing this using github APIs. In Github we have the concept of Assignee and Reviewers, we want to make use of that.

 

The other issue we are noticing is with subsystem branches, i.e. Bluetooth, net and ARM. Force push will not be possible if we decide to protect those branches and apply some rules on them and working around this through merges is not clean as well (leaves duplicate, phantom commits in the branch). We have tried to enable force push on the branches and removed protection, this results in PRs getting lots of unrelated commits when branches are rebased by maintainers.

This raises the question if in the github world we still need the subsystem branches on the main tree and if we should request all PRs to be submitted to master and have subsystem owners manage incoming changes to their subsystem on master, given that we have to go via  a fork anyways. To make it easier on maintainers of the various subsystem we can use the ‘project’ concept in Github and apply it to filter and triage pull requests and later issues if we decide to move to github issues in the future.

 

Moving all development to master has a few other advantages IMO. First, it is easy on new comers and occasional contributors, you do not need to figure out where to submit. There is only one entry point for all patches and changes. The other thing is the fact that when working on branches, those turn into isolated Silos of development with own policies and rules and end up in master as one large change. Finally, when developing against master and submitting changes to master we will keep master up to date all the time and there is no lag  in introducing features to master.

 

We had a lengthy discussion on IRC today about this but not everyone is on IRC, so posting this to get more views on the topic.

 

Regards,

Anas

 

 


Re: Zephyr JSON API can't find missing fields in sub-objects

Marti Bolivar <marti.bolivar@...>
 

Hit send too soon.

On 3 May 2017 at 00:55, Marti Bolivar <marti.bolivar@...> wrote:

Hi,

I am trying to convert an application to use the Zephyr JSON library in lib/json from jsmn [1], and have run into an issue that I think will req

...uire changes to the Zephyr API.

Here is the reference on the JSON I am trying to parse, for the
hawkBit device management system:

http://www.eclipse.org/hawkbit/documentation/interfaces/ddi-api.html

In particular, I need to parse responses that sometimes look like this:

{
"config": {
"polling": {
"sleep": "00:00:30"
}
},
"_links": {
"deploymentBase": {
"href": "https://some_url"
},
"configData": {
"href": "https://some_url"
}
}
}

And sometimes look like this:

{
"config": {
"polling": {
"sleep": "00:00:30"
}
},
"_links": {
"cancelAction": {
"href": "https://some_url"
},
"configData": {
"href": "https://some_url"
}
}
}

I've done that with something like what I've attached in foo.c.

However, when I parse this, I can tell whether "config" or "_links" is
present in the top-level JSON object using the return value from
json_obj_parse(), but I can't tell if its subobjects (the
"deploymentBase", "cancelAction" etc. in "_links") are present or not.

This leaves me unable to tell which kind of response I got -- one
containing a deploymentBase, or one containing a cancelAction.

I think there's no way around this without changing the Zephyr JSON API.

One way to do this would be to introduce a u32_t in each structure
(hawkbit_ctl_res_sleep, hawkbit_ctl_res_polling, hawkbit_ctl_res_href,
hawkbit_ctl_res_links) recording whether or not each of the "real"
fields is present, and have the JSON API fill this value recursively
as it parses. This would let me decide what fields are present at all
levels in the parsed hierarchy.

Does this seem reasonable? Does anyone else have other suggestions?

Thanks,
Marti



[1] https://github.com/zserge/jsmn


Zephyr JSON API can't find missing fields in sub-objects

Marti Bolivar <marti.bolivar@...>
 

Hi,

I am trying to convert an application to use the Zephyr JSON library in lib/json from jsmn [1], and have run into an issue that I think will req

[1] https://github.com/zserge/jsmn

5801 - 5820 of 8700