Date   

Re: [RFCv2 1/2] misc: Add timer API

Tomasz Bursztyka
 

Hi Benjamin,

2. I am not sure about the naming. This is yet another timer library,
when we already have nano timers and micro timers. What makes it special
is its callback functionality. Can we try to get that into the name ?
Sure we can add a timeout or callback to the name, but IMO this would
be much more useful than nano_timer thus why I would like to promote
it over it.
Since nobody is suggesting anything here are some alternatives:

sys_timer_callback*: quite long imo
sys_callback: doesn't say much
sys_timeout: I would favor this one
Me too.

I would prefer sys_callback I think: you add a callback with a timeout
shows that there is a timeout/timer IMHO.
A timeout says all without people to read parameters. At a timeout
usually, it means
you want to do something, thus the callback. It's not suprizing timeout
keyword is usually
preferred in some user-land libraries on Linux or else.

Tomasz


Re: [RFC PATCH 3/6] i2c: add device config helpers

Tomasz Bursztyka
 

Hi Vlad,

The configuration tool needs to generate config structures (see
devices.c in patch 6/6). These structures are device specific, but the
tool should be as generic as possible. Hard coding the struct member
name to "i2c_client" helps achieve that.

Thus, assuming the macros are correctly used, the config tool needs only
information such as "this device is connected to master I2C0, address
0x76", to generate "I2C_CLIENT(I2C0, 0x76)". Allowing the name to
change would be an extra variable.
Ok, so it would be really great know a lot more about this tool.

Tomasz


Architecture Porting Guide now available

Nashif, Anas
 

Hi,

Thanks to Ben, we now have a porting guide for new architectures, please find it at:

https://www.zephyrproject.org/doc/dev/porting/arch.html


Thanks,
Anas


Re: [RFC PATCH 3/6] i2c: add device config helpers

Vlad Dogaru <vlad.dogaru@...>
 

On Mon, Apr 25, 2016 at 01:10:49PM +0200, Tomasz Bursztyka wrote:
Hi Vlad,

Add some macros that drivers and applications can use in describing I2C
clients.

Change-Id: Ic7af97804e88ed3b9d4f68f9ac358a425f4cc17c
Signed-off-by: Vlad Dogaru <vlad.dogaru(a)intel.com>
---
include/i2c.h | 17 +++++++++++++++++
1 file changed, 17 insertions(+)

diff --git a/include/i2c.h b/include/i2c.h
index d1c699c..87cb071 100644
--- a/include/i2c.h
+++ b/include/i2c.h
@@ -266,6 +266,23 @@ static inline int i2c_resume(struct device *dev)
return api->resume(dev);
}
+struct i2c_client_config {
+ //struct device *i2c_master;
+ char *i2c_master;
+ uint16_t i2c_addr;
+};
+
+#define DECLARE_I2C_CLIENT_CONFIG struct i2c_client_config i2c_client
+
+#define I2C_CLIENT(master, addr) \
I don't know if their is a rule for macro's parameter naming.
My personal - and thus subjective - opinion is to separate those to
actual C code, and
I tend to enclose these with '_', so it would be _master_, _addr_
Or prefixing with '__' works as well.
Sure thing.


+ .i2c_client = { \
So it means we cannot use anything else but "i2c_client" as a name
in our device's configuration structure?
Would be easier that way:
{ \
.i2c_master = (master), \
.i2c_addr = (addr) \
}

Thus usage would be:

my_dev_config.i2c_info = I2C_CLIENT(foo, bar)
The configuration tool needs to generate config structures (see
devices.c in patch 6/6). These structures are device specific, but the
tool should be as generic as possible. Hard coding the struct member
name to "i2c_client" helps achieve that.

Thus, assuming the macros are correctly used, the config tool needs only
information such as "this device is connected to master I2C0, address
0x76", to generate "I2C_CLIENT(I2C0, 0x76)". Allowing the name to
change would be an extra variable.


+ .i2c_master = (master), \
+ .i2c_addr = (addr), \
+ }
+
+#define GET_I2C_MASTER(conf) ((conf)->i2c_client.i2c_master)
+#define GET_I2C_ADDR(conf) ((conf)->i2c_client.i2c_addr)
I2C_ prefixed
Yes.


And names are not relevant enough. What's the form of master's
information? What address?
So:
I2C_GET_MASTER_NAME()
I2C_GET_CLIENT_ADDR() (or _ADDRESS() actually)
Hopefully these will be better once I add some comments. There is an
example in patch 6/6, I hope that will clear these up.

And finally, document the struct and the macros.
Yep.


Re: [RFC PATCH 4/6] gpio: add device config helpers

Tomasz Bursztyka
 

Hi Vlad,


+struct gpio_pin_config {
+ /* In the future, devices will be selected by their handle, not
+ * name.
+ */
+ /* struct device *gpio_controller; */
+ char *gpio_controller;
+ uint32_t gpio_pin;
+};
I see a problem with that: it will fit only device that need to
configure 1 pin.
On cc2520 it requires many ones, and many complex devices will need
more than 1.
This structure does declare only one pin. But you can call the _IDX
macros multiple times:

struct mydev_config {
DECLARE_GPIO_PIN_CONFIG_IDX(0);
DECLARE_GPIO_PIN_CONFIG_IDX(1);
/* ... */
};

/* And when declaring the device: */
struct mydev_config mydev_0_config = {
GPIO_PIN_IDX(0, "GPIO_0", 12);
GPIO_PIN_IDX(1, "GPIO_0", 14);
/* ... */
};
This will bloat things up by repeating controller's name pointer
(which is most likely be the same).
Maybe a variable array of pins would be better then.

I don't have an obvious solution for that.
I'll take a stab at that in the next version, assuming we're comfortable
with the assumption that a device will never have GPIO pins tied to
different controllers.
It might and it's not going to be a rare case.
Again, about cc2520 it uses 2 GPIO controller on quark_se_devboard (it's
board specific obviously)
Actually, take a look at how we addressed this issue in
boards/quark_se_dev_board/board.<h/c>
It's far from being perfect and it's not generic, but it may help.

Tomasz


Re: [RFC PATCH 4/6] gpio: add device config helpers

Tomasz Bursztyka
 

Hi Vlad,
+struct gpio_pin_config {
+ /* In the future, devices will be selected by their handle, not
+ * name.
+ */
+ /* struct device *gpio_controller; */
+ char *gpio_controller;
+ uint32_t gpio_pin;
+};
I see a problem with that: it will fit only device that need to
configure 1 pin.
On cc2520 it requires many ones, and many complex devices will need
more than 1.
This structure does declare only one pin. But you can call the _IDX
macros multiple times:

struct mydev_config {
DECLARE_GPIO_PIN_CONFIG_IDX(0);
DECLARE_GPIO_PIN_CONFIG_IDX(1);
/* ... */
};

/* And when declaring the device: */
struct mydev_config mydev_0_config = {
GPIO_PIN_IDX(0, "GPIO_0", 12);
GPIO_PIN_IDX(1, "GPIO_0", 14);
/* ... */
};
This will bloat things up by repeating controller's name pointer (which
is most likely be the same).
Maybe a variable array of pins would be better then.

I don't have an obvious solution for that.

Tomasz


Re: [RFC PATCH 4/6] gpio: add device config helpers

Vlad Dogaru <vlad.dogaru@...>
 

On Mon, Apr 25, 2016 at 01:33:33PM +0200, Tomasz Bursztyka wrote:
Hi Vlad,
+struct gpio_pin_config {
+ /* In the future, devices will be selected by their handle, not
+ * name.
+ */
+ /* struct device *gpio_controller; */
+ char *gpio_controller;
+ uint32_t gpio_pin;
+};
I see a problem with that: it will fit only device that need to
configure 1 pin.
On cc2520 it requires many ones, and many complex devices will need
more than 1.
This structure does declare only one pin. But you can call the _IDX
macros multiple times:

struct mydev_config {
DECLARE_GPIO_PIN_CONFIG_IDX(0);
DECLARE_GPIO_PIN_CONFIG_IDX(1);
/* ... */
};

/* And when declaring the device: */
struct mydev_config mydev_0_config = {
GPIO_PIN_IDX(0, "GPIO_0", 12);
GPIO_PIN_IDX(1, "GPIO_0", 14);
/* ... */
};
This will bloat things up by repeating controller's name pointer
(which is most likely be the same).
Maybe a variable array of pins would be better then.

I don't have an obvious solution for that.
I'll take a stab at that in the next version, assuming we're comfortable
with the assumption that a device will never have GPIO pins tied to
different controllers.


Re: [RFC PATCH 0/6] Refactor device configuration

Tomasz Bursztyka
 

Hi Vlad,
Hi everyone,

I'd like to propose we revisit the way that devices are configured in
Zephyr. This is very RFC, please poke holes wherever you see fit.

Currently, most drivers define one or more device instances which can be
activated and configured from Kconfig. This has several drawbacks:

- It limits the number of devices which can be defined. If you have 3
DW I2C controllers, you need to add one more set of config variables
and structures.

- It makes interaction with external tools difficult. We are working
on a hardware configuration tool that will enable the user to choose
components from a catalog and generate a Zephyr config based on that.
I think you will need to clarify that before anything. I guess we are
all curious to see what it
will look like and how much it's affecting Zephyr. You are, afaik in
your patches, moving away
from Kconfig as we used to do. I am not saying it's good or bad, I just
lack the final goal: this tool
your are talking about. Would be great to see what it is all about.

We can generate Kconfig, but it's not a very robust approach. Given
an I2C device, its master may be called CONFIG_MYDEV_I2C_BUS,
CONFIG_MYDEV_0_I2C_MASTER or anything else.

Patches 1-4 introduce the needed wrappers and some fixes.
Fixes can go already to gerrit I think.

Tomasz


Re: [RFC PATCH 4/6] gpio: add device config helpers

Tomasz Bursztyka
 

Hi Vlad,

Change-Id: I8af573484934a02893a395bb0d19551b5c9d0291
Signed-off-by: Vlad Dogaru <vlad.dogaru(a)intel.com>
---
include/gpio.h | 30 ++++++++++++++++++++++++++++++
1 file changed, 30 insertions(+)

diff --git a/include/gpio.h b/include/gpio.h
index 57b3e22..cb1c4db 100644
--- a/include/gpio.h
+++ b/include/gpio.h
@@ -432,6 +432,36 @@ static inline int gpio_port_disable_callback(struct device *port)
return api->disable_callback(port, GPIO_ACCESS_BY_PORT, 0);
}

+struct gpio_pin_config {
+ /* In the future, devices will be selected by their handle, not
+ * name.
+ */
+ /* struct device *gpio_controller; */
+ char *gpio_controller;
+ uint32_t gpio_pin;
+};
I see a problem with that: it will fit only device that need to
configure 1 pin.
On cc2520 it requires many ones, and many complex devices will need more
than 1.

+
+#define DECLARE_GPIO_PIN_CONFIG_IDX(idx) \
+ struct gpio_pin_config gpio_pin_ ##idx
+#define DECLARE_GPIO_PIN_CONFIG \
+ DECLARE_GPIO_PIN_CONFIG_IDX()
+
+#define GPIO_PIN_IDX(idx, controller, pin) \
+ .gpio_pin_ ##idx = { \
+ .gpio_controller = (controller),\
+ .gpio_pin = (pin), \
+ }
+#define GPIO_PIN(controller, pin) \
+ GPIO_PIN_IDX(, controller, pin)
+
+#define GET_GPIO_CONTROLLER_IDX(idx, conf) \
+ (conf)->gpio_pin_ ##idx.gpio_controller
+#define GET_GPIO_PIN_IDX(idx, conf) \
+ (conf)->gpio_pin_ ##idx.gpio_pin
+
+#define GET_GPIO_CONTROLLER(conf) GET_GPIO_CONTROLLER_IDX(, conf)
+#define GET_GPIO_PIN(conf) GET_GPIO_PIN_IDX(, conf)
And GPIO_ prefixed.

and documentation


Tomasz


Re: [RFC PATCH 3/6] i2c: add device config helpers

Tomasz Bursztyka
 

Hi Vlad,

Add some macros that drivers and applications can use in describing I2C
clients.

Change-Id: Ic7af97804e88ed3b9d4f68f9ac358a425f4cc17c
Signed-off-by: Vlad Dogaru <vlad.dogaru(a)intel.com>
---
include/i2c.h | 17 +++++++++++++++++
1 file changed, 17 insertions(+)

diff --git a/include/i2c.h b/include/i2c.h
index d1c699c..87cb071 100644
--- a/include/i2c.h
+++ b/include/i2c.h
@@ -266,6 +266,23 @@ static inline int i2c_resume(struct device *dev)
return api->resume(dev);
}

+struct i2c_client_config {
+ //struct device *i2c_master;
+ char *i2c_master;
+ uint16_t i2c_addr;
+};
+
+#define DECLARE_I2C_CLIENT_CONFIG struct i2c_client_config i2c_client
+
+#define I2C_CLIENT(master, addr) \
I don't know if their is a rule for macro's parameter naming.
My personal - and thus subjective - opinion is to separate those to
actual C code, and
I tend to enclose these with '_', so it would be _master_, _addr_
Or prefixing with '__' works as well.

+ .i2c_client = { \
So it means we cannot use anything else but "i2c_client" as a name in
our device's configuration structure?
Would be easier that way:
{ \
.i2c_master = (master), \
.i2c_addr = (addr) \
}

Thus usage would be:

my_dev_config.i2c_info = I2C_CLIENT(foo, bar)

+ .i2c_master = (master), \
+ .i2c_addr = (addr), \
+ }
+
+#define GET_I2C_MASTER(conf) ((conf)->i2c_client.i2c_master)
+#define GET_I2C_ADDR(conf) ((conf)->i2c_client.i2c_addr)
I2C_ prefixed

And names are not relevant enough. What's the form of master's
information? What address?
So:
I2C_GET_MASTER_NAME()
I2C_GET_CLIENT_ADDR() (or _ADDRESS() actually)


And finally, document the struct and the macros.

Tomasz


Re: [RFC PATCH 4/6] gpio: add device config helpers

Vlad Dogaru <vlad.dogaru@...>
 

On Mon, Apr 25, 2016 at 01:13:51PM +0200, Tomasz Bursztyka wrote:
Hi Vlad,

Change-Id: I8af573484934a02893a395bb0d19551b5c9d0291
Signed-off-by: Vlad Dogaru <vlad.dogaru(a)intel.com>
---
include/gpio.h | 30 ++++++++++++++++++++++++++++++
1 file changed, 30 insertions(+)

diff --git a/include/gpio.h b/include/gpio.h
index 57b3e22..cb1c4db 100644
--- a/include/gpio.h
+++ b/include/gpio.h
@@ -432,6 +432,36 @@ static inline int gpio_port_disable_callback(struct device *port)
return api->disable_callback(port, GPIO_ACCESS_BY_PORT, 0);
}
+struct gpio_pin_config {
+ /* In the future, devices will be selected by their handle, not
+ * name.
+ */
+ /* struct device *gpio_controller; */
+ char *gpio_controller;
+ uint32_t gpio_pin;
+};
I see a problem with that: it will fit only device that need to
configure 1 pin.
On cc2520 it requires many ones, and many complex devices will need
more than 1.
This structure does declare only one pin. But you can call the _IDX
macros multiple times:

struct mydev_config {
DECLARE_GPIO_PIN_CONFIG_IDX(0);
DECLARE_GPIO_PIN_CONFIG_IDX(1);
/* ... */
};

/* And when declaring the device: */
struct mydev_config mydev_0_config = {
GPIO_PIN_IDX(0, "GPIO_0", 12);
GPIO_PIN_IDX(1, "GPIO_0", 14);
/* ... */
};

+
+#define DECLARE_GPIO_PIN_CONFIG_IDX(idx) \
+ struct gpio_pin_config gpio_pin_ ##idx
+#define DECLARE_GPIO_PIN_CONFIG \
+ DECLARE_GPIO_PIN_CONFIG_IDX()
+
+#define GPIO_PIN_IDX(idx, controller, pin) \
+ .gpio_pin_ ##idx = { \
+ .gpio_controller = (controller),\
+ .gpio_pin = (pin), \
+ }
+#define GPIO_PIN(controller, pin) \
+ GPIO_PIN_IDX(, controller, pin)
+
+#define GET_GPIO_CONTROLLER_IDX(idx, conf) \
+ (conf)->gpio_pin_ ##idx.gpio_controller
+#define GET_GPIO_PIN_IDX(idx, conf) \
+ (conf)->gpio_pin_ ##idx.gpio_pin
+
+#define GET_GPIO_CONTROLLER(conf) GET_GPIO_CONTROLLER_IDX(, conf)
+#define GET_GPIO_PIN(conf) GET_GPIO_PIN_IDX(, conf)
And GPIO_ prefixed.

and documentation
Noted.


Re: [RFC PATCH 2/6] sensor: add device config helpers

Tomasz Bursztyka
 

Hi Vlad,

Define some configuration structures and macros that can be used in
device configuration. These usage scenarios are as follows:

* device drivers will use DECLARE_* macros in their device
configuration structures and GET_* macros in the init functions;

* application code will use SENSOR_TRIG_* to fill in the device
configuration structures.

We also define a convenient wrapper for starting a new fiber based on a
given configuration.

Change-Id: I3a897999175b14a4cd1111da4c26434741294e52
Signed-off-by: Vlad Dogaru <vlad.dogaru(a)intel.com>
---
include/sensor.h | 44 ++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 44 insertions(+)

diff --git a/include/sensor.h b/include/sensor.h
index 918326a..8312b5a 100644
--- a/include/sensor.h
+++ b/include/sensor.h
@@ -190,6 +190,18 @@ enum sensor_attribute {
SENSOR_ATTR_CALIB_TARGET,
};

+enum sensor_trigger_mode {
+ SENSOR_TRIG_MODE_NONE,
+ SENSOR_TRIG_MODE_OWN,
+ SENSOR_TRIG_MODE_GLOBAL,
+};
+
+struct fiber_config {
Since it's part of public sensor API, rename it to: struct
sensor_fiber_config

+ void *fiber_stack;
+ unsigned int fiber_stack_size;
+ unsigned int fiber_priority;
+};
+
typedef void (*sensor_trigger_handler_t)(struct device *dev,
struct sensor_trigger *trigger);

@@ -334,6 +346,15 @@ static inline int sensor_channel_get(struct device *dev,
return api->channel_get(dev, chan, val);
}

+static inline nano_thread_id_t
+sensor_fiber_start(const struct fiber_config *cfg,
+ nano_fiber_entry_t entry, int arg1, int arg2,
+ unsigned options)
+{
+ return fiber_start(cfg->fiber_stack, cfg->fiber_stack_size,
+ entry, arg1, arg2, cfg->fiber_priority,
+ options);
+}

#ifdef CONFIG_SENSOR_DELAYED_WORK
/**
@@ -425,6 +446,29 @@ static inline void sensor_degrees_to_rad(int32_t d, struct sensor_value *rad)
rad->val2 = ((int64_t)d * SENSOR_PI / 180LL) % 1000000LL;
}

+#define DECLARE_SENSOR_TRIG_CONFIG \
+ enum sensor_trigger_mode trig_mode; \
+ struct fiber_config fiber_config
+
+#define SENSOR_TRIG_OWN_FIBER(stack, prio) \
+ .trig_mode = SENSOR_TRIG_MODE_OWN, \
+ .fiber_config = { \
+ .fiber_stack = (stack), \
+ .fiber_stack_size = sizeof(stack), \
+ .fiber_priority = (prio), \
+ }
+
+#define SENSOR_TRIG_GLOBAL_FIBER \
+ .trig_mode = SENSOR_TRIG_MODE_GLOBAL, \
+ .fiber_config = { \
+ .fiber_stack = NULL, \
+ .fiber_stack_size = 0, \
+ .fiber_priority = 0, \
+ }
+
+#define GET_SENSOR_TRIG_MODE(conf) ((conf)->trig_mode)
+#define GET_SENSOR_FIBER_CONFIG(conf) ((conf)->fiber_config)
SENSOR_ prefixed

+
#ifdef __cplusplus
}
#endif


Re: [RFC PATCH 2/6] sensor: add device config helpers

Vlad Dogaru <vlad.dogaru@...>
 

On Mon, Apr 25, 2016 at 12:59:57PM +0200, Tomasz Bursztyka wrote:
Hi Vlad,

Define some configuration structures and macros that can be used in
device configuration. These usage scenarios are as follows:

* device drivers will use DECLARE_* macros in their device
configuration structures and GET_* macros in the init functions;

* application code will use SENSOR_TRIG_* to fill in the device
configuration structures.

We also define a convenient wrapper for starting a new fiber based on a
given configuration.

Change-Id: I3a897999175b14a4cd1111da4c26434741294e52
Signed-off-by: Vlad Dogaru <vlad.dogaru(a)intel.com>
---
include/sensor.h | 44 ++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 44 insertions(+)

diff --git a/include/sensor.h b/include/sensor.h
index 918326a..8312b5a 100644
--- a/include/sensor.h
+++ b/include/sensor.h
@@ -190,6 +190,18 @@ enum sensor_attribute {
SENSOR_ATTR_CALIB_TARGET,
};
+enum sensor_trigger_mode {
+ SENSOR_TRIG_MODE_NONE,
+ SENSOR_TRIG_MODE_OWN,
+ SENSOR_TRIG_MODE_GLOBAL,
+};
+
+struct fiber_config {
Since it's part of public sensor API, rename it to: struct
sensor_fiber_config
If it stays here, then yeah, it makes sense to prefix it with "sensor_".

The question is if other subsystems would benefit from such a structure.
As it's defined now, there is nothing sensor specific about it or the
helper function that starts a fiber. Should I move them to a system
header so others can use them?


+ void *fiber_stack;
+ unsigned int fiber_stack_size;
+ unsigned int fiber_priority;
+};
+
typedef void (*sensor_trigger_handler_t)(struct device *dev,
struct sensor_trigger *trigger);
@@ -334,6 +346,15 @@ static inline int sensor_channel_get(struct device *dev,
return api->channel_get(dev, chan, val);
}
+static inline nano_thread_id_t
+sensor_fiber_start(const struct fiber_config *cfg,
+ nano_fiber_entry_t entry, int arg1, int arg2,
+ unsigned options)
+{
+ return fiber_start(cfg->fiber_stack, cfg->fiber_stack_size,
+ entry, arg1, arg2, cfg->fiber_priority,
+ options);
+}
#ifdef CONFIG_SENSOR_DELAYED_WORK
/**
@@ -425,6 +446,29 @@ static inline void sensor_degrees_to_rad(int32_t d, struct sensor_value *rad)
rad->val2 = ((int64_t)d * SENSOR_PI / 180LL) % 1000000LL;
}
+#define DECLARE_SENSOR_TRIG_CONFIG \
+ enum sensor_trigger_mode trig_mode; \
+ struct fiber_config fiber_config
+
+#define SENSOR_TRIG_OWN_FIBER(stack, prio) \
+ .trig_mode = SENSOR_TRIG_MODE_OWN, \
+ .fiber_config = { \
+ .fiber_stack = (stack), \
+ .fiber_stack_size = sizeof(stack), \
+ .fiber_priority = (prio), \
+ }
+
+#define SENSOR_TRIG_GLOBAL_FIBER \
+ .trig_mode = SENSOR_TRIG_MODE_GLOBAL, \
+ .fiber_config = { \
+ .fiber_stack = NULL, \
+ .fiber_stack_size = 0, \
+ .fiber_priority = 0, \
+ }
+
+#define GET_SENSOR_TRIG_MODE(conf) ((conf)->trig_mode)
+#define GET_SENSOR_FIBER_CONFIG(conf) ((conf)->fiber_config)
SENSOR_ prefixed
Will do.


+
#ifdef __cplusplus
}
#endif
Thanks,
Vlad


Daily JIRA Digest

donotreply@...
 

NEW JIRA items within last 24 hours: 0

UPDATED JIRA items within last 24 hours: 0

CLOSED JIRA items within last 24 hours: 0

RESOLVED JIRA items within last 24 hours: 0


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/1630 : arc: make SRAM/DCCM values configurable
- https://gerrit.zephyrproject.org/r/1629 : grove: use default i2c device set in Kconfig

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/1135 : boards: nucleo: Adding flash support
- https://gerrit.zephyrproject.org/r/1445 : gpio: Deprecate API 1.0 callback function
- https://gerrit.zephyrproject.org/r/1628 : i2c: use I2C_X nameing instead of I2CX

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/1565 : newlib_2.2.%.bbappend: Upgrade ARC newlib
- https://gerrit.zephyrproject.org/r/1564 : gcc-4.8arc.inc: Upgrade gcc
- https://gerrit.zephyrproject.org/r/1563 : binutils-2.23arc.inc:Upgrade version
- https://gerrit.zephyrproject.org/r/1562 : libgcc_4.8arc.bb: Cleanup
- https://gerrit.zephyrproject.org/r/1561 : make_zephyr_sdk.sh: Fix script compatibility with "dash"
- https://gerrit.zephyrproject.org/r/1560 : binutils: Rename append file


Re: Zephyr Project Application Development

Flavio Santes <flavio.santes@...>
 

Hello Rechna,

In order to get access to Galileo's TTL UART you must the converter
cable.

BTW, this is the Developers Mailing List for the Zephyr Project. 
Perhaps you can get more help here:

https://communities.intel.com/community/tech/galileo 


Cheers,
Flavio

On Sat, 2016-04-23 at 19:11 -0400, Rachna Desai wrote:
Hi Flavio,
             So according to what I understood from your answer, I
have to connect my laptop to board using 6-pin header USB cable and
not just our normal USB cable that is used to charge our cell phones?
Thank you.

Regards,
Rachna Naik


On Sat, Apr 23, 2016 at 5:17 PM, Santes, Flavio <flavio.santes(a)intel.c
om> wrote:
Hello Rechna,

The Galileo Gen2 Development Board is briefly described here:

http://www.intel.com/content/www/us/en/embedded/products/galileo/gal
ileo
-g2-datasheet.html

The USB cable connected to the 6-pin header is a USB to TTL UART
serial
converter.

Hope this helps you.
Flavio


On Fri, 2016-04-22 at 17:53 -0400, Rachna Desai wrote:
Hello all,
            I am trying to use Zephyr application to boot it on
Intel
galileo board gen2. In the steps provided on the Zephyr website,
it is
mentioned that we have use 6-pin serial cable to connect board to
laptop. But can we use USB cable for the same purpose?
Looking forward to hear from you.
Thanking you.

Regards,
Rachna Naik


Regarding zephyr application development

Keya Shah <keyashah24@...>
 

Hi there,

I would like to boot the image of a zephyr application on the galileo board
gen 2. For this purpose I am have followed the instructions to create the
bootable image and copied it to the usb drive.
Also I have connected the usb to the board, and used a usb to microusb
cable to connect my laptop to the board. However, when I power on the
board, the terminal on putty does not show anything.
Could you please help me with this? How can I successfully load the image
on the board.

Regards,
Keya Shah


Re: Zephyr Project Application Development

Flavio Santes <flavio.santes@...>
 

Hello Rechna,

The Galileo Gen2 Development Board is briefly described here:

http://www.intel.com/content/www/us/en/embedded/products/galileo/galileo
-g2-datasheet.html

The USB cable connected to the 6-pin header is a USB to TTL UART serial
converter.

Hope this helps you.
Flavio

On Fri, 2016-04-22 at 17:53 -0400, Rachna Desai wrote:
Hello all,
            I am trying to use Zephyr application to boot it on Intel
galileo board gen2. In the steps provided on the Zephyr website, it is
mentioned that we have use 6-pin serial cable to connect board to
laptop. But can we use USB cable for the same purpose?
Looking forward to hear from you.
Thanking you.

Regards,
Rachna Naik


Daily JIRA Digest

donotreply@...
 

NEW JIRA items within last 24 hours: 1
[ZEP-213] net_set_mac() didn't deal wtih NULL
https://jira.zephyrproject.org/browse/ZEP-213


UPDATED JIRA items within last 24 hours: 1
[ZEP-177] Windows build with MinGW
https://jira.zephyrproject.org/browse/ZEP-177


CLOSED JIRA items within last 24 hours: 0

RESOLVED JIRA items within last 24 hours: 0


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/1629 : grove: use default i2c device set in Kconfig
- https://gerrit.zephyrproject.org/r/1628 : i2c: use I2C_X nameing instead of I2CX
- https://gerrit.zephyrproject.org/r/1627 : aio: build only when driver is configured in
- https://gerrit.zephyrproject.org/r/1626 : toolchain: move iamcu output format/arch to SoC
- https://gerrit.zephyrproject.org/r/1623 : device: simplify synchronization

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/1376 : kernel: Init back pointer to microkernel task
- https://gerrit.zephyrproject.org/r/1611 : sensor: make delayed work visible in menuconfig
- https://gerrit.zephyrproject.org/r/1616 : samples: mcp9808: support two devices
- https://gerrit.zephyrproject.org/r/1613 : i2c: add device config helpers
- https://gerrit.zephyrproject.org/r/1601 : doc: power_mgmt: Added Power Management documentation
- https://gerrit.zephyrproject.org/r/1278 : sensor: refactor bmc150 and lsm9ds0
- https://gerrit.zephyrproject.org/r/1593 : nanokernel: Add callout API
- https://gerrit.zephyrproject.org/r/1381 : tests: Pend microkernel tasks on nanokernel objects
- https://gerrit.zephyrproject.org/r/1378 : kernel: Add thread parameter to _nano_wait_q_put()
- https://gerrit.zephyrproject.org/r/1377 : nanokernel: Add thread parameter to _NANO_TIMEOUT_ADD()
- https://gerrit.zephyrproject.org/r/1379 : microkernel: [un]block tasks on nanokernel objects infrastructure
- https://gerrit.zephyrproject.org/r/1380 : nanokernel: [un]block tasks on nanokernel objects infrastructure
- https://gerrit.zephyrproject.org/r/1550 : Bluetooth: L2CAP: Refactor l2cap_chan_del
- https://gerrit.zephyrproject.org/r/1553 : Bluetooth: L2CAP: Validate conn type in l2cap_chan_recv
- https://gerrit.zephyrproject.org/r/1552 : Bluetooth: L2CAP: Make common l2cap_disconn_req
- https://gerrit.zephyrproject.org/r/1606 : Bluetooth: L2CAP: Enable L2CAP public API for BREDR
- https://gerrit.zephyrproject.org/r/1554 : Bluetooth: L2CAP: Make common l2cap_disconn_rsp
- https://gerrit.zephyrproject.org/r/1555 : Bluetooth: L2CAP: Rename LE PSM server list variable
- https://gerrit.zephyrproject.org/r/1556 : Bluetooth: L2CAP: Add BREDR PSM server API interface
- https://gerrit.zephyrproject.org/r/1579 : Add capability to output binary data over console UART
- https://gerrit.zephyrproject.org/r/1580 : Add support of event logger put/get without sync
- https://gerrit.zephyrproject.org/r/1581 : Task monitor: move to "no_sync" API to feed kernel event logger
- https://gerrit.zephyrproject.org/r/1444 : Bluetooth: drivers/nble: Fix calling cmd from discov callback
- https://gerrit.zephyrproject.org/r/1594 : Bluetooth: SMP: Make use of sys_callout API
- https://gerrit.zephyrproject.org/r/1573 : sensor: rename SENSOR_TYPE_* to SENSOR_VALUE_TYPE_*
- https://gerrit.zephyrproject.org/r/1575 : sensor: split lsm9ds0_gyro driver
- https://gerrit.zephyrproject.org/r/1360 : sensor: fix init driver_api

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/1625 : Bluetooth: add drivers to include path
- https://gerrit.zephyrproject.org/r/1622 : soc: arm: add Makefiles one level up
- https://gerrit.zephyrproject.org/r/1621 : Bluetooth: Add recently added SPI & I2C HCI bus defines
- https://gerrit.zephyrproject.org/r/914 : gpio: Improve the public API to handle multi callbacks
- https://gerrit.zephyrproject.org/r/1271 : sensors: Using new GPIO API callbacks
- https://gerrit.zephyrproject.org/r/1518 : build: fixes issue in windows Kconfig support
- https://gerrit.zephyrproject.org/r/1354 : cc2520: Using new GPIO API callbacks
- https://gerrit.zephyrproject.org/r/1353 : samples: Using new GPIO API callbacks
- https://gerrit.zephyrproject.org/r/1598 : quark_d2000: remove unused code
- https://gerrit.zephyrproject.org/r/1500 : qmsi: uart: use built-in qmsi driver
- https://gerrit.zephyrproject.org/r/1493 : qmsi: aio: use built-in qmsi driver
- https://gerrit.zephyrproject.org/r/1098 : drivers: add qmsi files for Quark MCUs
- https://gerrit.zephyrproject.org/r/1495 : qmsi: aon_counters: use built-in qmsi driver
- https://gerrit.zephyrproject.org/r/1488 : qmsi: i2c: use built-in qmsi driver
- https://gerrit.zephyrproject.org/r/1494 : aio: rename sample name and make it generic
- https://gerrit.zephyrproject.org/r/1326 : power_mgmt: Sample usage of device_xxx__busy() APIs
- https://gerrit.zephyrproject.org/r/1325 : power_mgmt: APIs for devices to signal busy
- https://gerrit.zephyrproject.org/r/1491 : spi: use global init priority
- https://gerrit.zephyrproject.org/r/1497 : samples: power: use string for driver name
- https://gerrit.zephyrproject.org/r/1482 : qmsi: rtc: use built-in qmsi driver
- https://gerrit.zephyrproject.org/r/1093 : doc: index config variable only once
- https://gerrit.zephyrproject.org/r/1521 : qmsi: use QMSI_LIBRARY instead of QMSI_DRIVERS
- https://gerrit.zephyrproject.org/r/1544 : qmsi: pinmux: use built-in qmsi driver
- https://gerrit.zephyrproject.org/r/1492 : qmsi: spi: use built-in qmsi driver
- https://gerrit.zephyrproject.org/r/1597 : quark_se: quark_d2000: remove all defines that now come from qmsi
- https://gerrit.zephyrproject.org/r/1498 : nble: Use string name for GPIO driver
- https://gerrit.zephyrproject.org/r/1609 : qmsi: spi: fixed warning due to const paramter in API call
- https://gerrit.zephyrproject.org/r/1490 : qmsi: pwm: use built-in qmsi driver
- https://gerrit.zephyrproject.org/r/1483 : qmsi: watchdog: use built-in qmsi driver
- https://gerrit.zephyrproject.org/r/1489 : pwm: unify driver names
- https://gerrit.zephyrproject.org/r/1506 : qmsi: flash: use built-in qmsi driver
- https://gerrit.zephyrproject.org/r/1499 : qmsi: adc: use built-in qmsi driver
- https://gerrit.zephyrproject.org/r/1496 : qmsi: gpio: use built-in qmsi driver
- https://gerrit.zephyrproject.org/r/1569 : i2c: add register access API
- https://gerrit.zephyrproject.org/r/1522 : doc: add architecture porting guide
- https://gerrit.zephyrproject.org/r/1608 : Bluetooth: tests: Add automated tests for new monitor code
- https://gerrit.zephyrproject.org/r/1618 : Bluetooth: Add name member to HCI driver struct
- https://gerrit.zephyrproject.org/r/1617 : Bluetooth: Move HCI device bus information to the driver
- https://gerrit.zephyrproject.org/r/1607 : Bluetooth: Add custom "monitor" protocol logging over UART
- https://gerrit.zephyrproject.org/r/1610 : Bluetooth: Remove RX priority fiber
- https://gerrit.zephyrproject.org/r/1620 : quark_se_devboard: Configure default UART for UART_PIPE

7921 - 7940 of 8530