Date   

Re: Reg: Command handling Via USB driver

Marti Bolivar <marti.bolivar@...>
 

On 15 March 2017 at 04:52, Andrei Emeltchenko
<andrei.emeltchenko.news@gmail.com> wrote:
Hi,

On Tue, Mar 14, 2017 at 09:02:55AM +0000, Mahendravarman Rajarao (RBEI/EAA10) wrote:
Hi

Thanks for the reply But as of now with the available zephyr, the USB
can work either as DFU flashing or as UART over USB (CDC) and not both
functionalities together.

We have a requirement at End of Line, we need to pass commands from a
PC to test each interfaces. And finally we need to flash the
functional software to the device via DFU flashing.

So only I have a doubt that can we use USB DFU class and expand the
driver to handle some more custom commands other than DFU commands to
satisfy my requirement.

Please suggest !!
You can combine those descriptors together to have multifunction device.
http://www.beyondlogic.org/usbnutshell/usb5.shtml
(I have not tried it myself)
IIRC, last time I tried this (5 or so years ago), composite devices
required custom drivers on Windows. That may not work for a factory
line test environment; these tend to involve very locked down PCs that
don't even allow custom unprivileged executables, much less device
drivers. The situation may have gotten better since then.

Marti


Best regards
Andrei Emeltchenko


Thanks
Mahendra

-----Original Message-----
From: Andrei Emeltchenko [mailto:andrei.emeltchenko.news@gmail.com]
Sent: Thursday, March 09, 2017 1:47 PM
To: Mahendravarman Rajarao (RBEI/EAA10) <Mahendravarman.Rajarao@in.bosch.com>
Cc: devel@lists.zephyrproject.org
Subject: Re: [Zephyr-devel] Reg: Command handling Via USB driver

Hi Mahendra,

On Thu, Mar 09, 2017 at 04:54:23AM +0000, Mahendravarman Rajarao (RBEI/EAA10) wrote:
Hi

We are using Quark_C1000 controller in our project along with zephyr 1.6.
I could see zephyr 1.6 has support for USB.

I have a query.

We are currently having a requirement of send some commands via USB (from
a PC) and based on the commands received (in the device ) we will execute
certain applications.

For this requirement I need clarifications regarding the USB driver.

I could see that the USB DFU handles command which is sent from a PC.

Do I need to expand this driver itself for my requirement or Should I use
the USB UART driver for my requirement ?
It is easier to use cdc_acm sample in samples/usb/cdc_acm, then your PC already has the driver for it and it appears on your PC as ttyACM or ttyUSB, then you can communicate over serial.

If you want to implement certain USB class like Bluetooth in hci_usb sample you should look here: samples/bluetooth/hci_usb/

For other samples you need AFAIK to have certain driver, like btusb for hci_usb, etc.

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


Re: Odp.: Graphics and Zephyr

Daniel Thompson <daniel.thompson@...>
 

On 15/03/17 09:53, Bober, Wojciech wrote:
Hi Bill,


I'm not sure if ugfx has been ported to Zephyr but you can check it
anyway. I've heard good things about it.

https://ugfx.io/
Interesting product indeed but beware of the "100% open" on the front page. ugfx is not open source... merely "open".


Daniel.



------------------------------------------------------------------------
*Od:* zephyr-devel-bounces@lists.zephyrproject.org
<zephyr-devel-bounces@lists.zephyrproject.org> w imieniu użytkownika
Bill Rees <bill@zglue.com>
*Wysłane:* 14 marca 2017 00:15:35
*Do:* zephyr-devel@lists.zephyrproject.org
*Temat:* [Zephyr-devel] Graphics and Zephyr


I'm looking around for RTOSs that support graphics and while I don't
see any references to graphics support in Jira or schedules I'm hoping
someone knows of a 3rd party library that would work?

Thanks,
Bill Rees

--
___________________________________________
: +1 (650) 533-4054 <tel:(650)%20533-4054>
: zGlue Inc., Mountain View, CA
___________________________________________


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


Odp.: Graphics and Zephyr

Bober, Wojciech <Wojciech.Bober@...>
 

Hi Bill,


I'm not sure if ugfx has been ported to Zephyr but you can check it anyway. I've heard good things about it.


https://ugfx.io/


Od: zephyr-devel-bounces@... <zephyr-devel-bounces@...> w imieniu użytkownika Bill Rees <bill@...>
Wysłane: 14 marca 2017 00:15:35
Do: zephyr-devel@...
Temat: [Zephyr-devel] Graphics and Zephyr
 

    I'm looking around for RTOSs that support graphics and while I don't see any references to graphics support in Jira or schedules I'm hoping someone knows of a 3rd party library that would work?

Thanks,
Bill Rees

--

___________________________________________
 : zGlue Inc., Mountain View, CA
___________________________________________



Re: Reg: Command handling Via USB driver

Andrei
 

Hi,

On Tue, Mar 14, 2017 at 09:02:55AM +0000, Mahendravarman Rajarao (RBEI/EAA10) wrote:
Hi

Thanks for the reply But as of now with the available zephyr, the USB
can work either as DFU flashing or as UART over USB (CDC) and not both
functionalities together.

We have a requirement at End of Line, we need to pass commands from a
PC to test each interfaces. And finally we need to flash the
functional software to the device via DFU flashing.

So only I have a doubt that can we use USB DFU class and expand the
driver to handle some more custom commands other than DFU commands to
satisfy my requirement.

Please suggest !!
You can combine those descriptors together to have multifunction device.
http://www.beyondlogic.org/usbnutshell/usb5.shtml
(I have not tried it myself)

Best regards
Andrei Emeltchenko


Thanks
Mahendra

-----Original Message-----
From: Andrei Emeltchenko [mailto:andrei.emeltchenko.news@gmail.com]
Sent: Thursday, March 09, 2017 1:47 PM
To: Mahendravarman Rajarao (RBEI/EAA10) <Mahendravarman.Rajarao@in.bosch.com>
Cc: devel@lists.zephyrproject.org
Subject: Re: [Zephyr-devel] Reg: Command handling Via USB driver

Hi Mahendra,

On Thu, Mar 09, 2017 at 04:54:23AM +0000, Mahendravarman Rajarao (RBEI/EAA10) wrote:
Hi

We are using Quark_C1000 controller in our project along with zephyr 1.6.
I could see zephyr 1.6 has support for USB.

I have a query.

We are currently having a requirement of send some commands via USB (from
a PC)  and based on the commands received (in the device ) we will execute
certain applications.

For this requirement I need clarifications regarding the USB driver.

I could see that the USB DFU handles command which is sent from a PC.

Do I need to expand this driver itself for my requirement or Should I use
the USB UART driver for my requirement ?
It is easier to use cdc_acm sample in samples/usb/cdc_acm, then your PC already has the driver for it and it appears on your PC as ttyACM or ttyUSB, then you can communicate over serial.

If you want to implement certain USB class like Bluetooth in hci_usb sample you should look here: samples/bluetooth/hci_usb/

For other samples you need AFAIK to have certain driver, like btusb for hci_usb, etc.

Best regards
Andrei Emeltchenko


Re: [RFC] MPU support for debugging

Boie, Andrew P
 

On Tue, 2017-03-14 at 17:29 +0100, Piotr Mienkowski wrote:
I would like to add one more point to the discussion. It is maybe not directly
related to the topic but should likely be considered when designing MPU
support.

Occasionally, mainly in case of device drivers, on MCUs that have cache it is
required to use the so called non-cacheable RAM regions. A memory region for
which caching has been turned off. This task is typically done by MPU/MMU and
Zephyr MPU architecture should also support it. I.e. as a developer I would
like to have a possibility to place a specific variable / set of variables in
a non-cacheable RAM region.
This is a great topic to bring up. In addition to an MPU policy to protect
threads for debugging, we do need to specify a system-level policy that get
applied at boot, even if we are not protecting individual threads.

Are you thinking that this would be something declared at the SOC level? I think
because of the size and alignment constraints of MPU regions, we may want to
configure these reasons in a central area. You may be interested to look at
Vincenzo's patches, which define MPU regions for a few ARM SOCs at boot:

https://gerrit.zephyrproject.org/r/#/q/topic:zephyr_mpu

This brings up another thing we need to consider: for thread-level debugging,
what is the minimum number of free MPU regions necessary to make it work?

For example, on an ARM Cortex-M, AFAIK you can only configure 8 MPU regions
total, each of which must be aligned to a multiple of their size. If 5 or 6 of
them are already used for system-wide MPU policy, it may be not be feasible to
introduce all the thread-level protection ideas that have been discussed so far.

Looking at this another way, maybe we need to consider different levels of
memory protection support, each building on top of the previous level. What
level any given board target supports will be determined by the available memory
protection hardware and its capabilities, as well as how much extra RAM we can
waste to accommodate the alignment constraints of the MPU hardware:

1) No memory protection

2) System-wide memory protection policy, set at boot by board or SOC code.

3) Per-thread stack overflow protection. We configure the MPU, on a per-thread
basis, to trigger an exception if the thread tries to write past its available
stack space. I think this should only require 1 extra region, just a sentinel
area immediately before the thread's stack to catch writes, with the struct
k_thread stored elsewhere. I think this is something simple we can do which will
make a lot of people happy given how painful stack overflows can be to debug if
you don't know they are happening.

4) Per-thread memory protection. User threads can only write to their own stack
+ additional runtime-configurable memory regions. System calls to interact with
the kernel, whose memory is otherwise untouchable. Basically what we have been
talking about so far.

5) Virtualized memory (MMU). Application and kernel run in different virtualized
memory spaces. Introduce the possibility of different isolated zephyr processes.

We may never need or want to get as far as #5, although I think whatever design
we come up with ought to leave the door open for it.

Andrew


Re: [RFC] MPU support for debugging

Benjamin Walsh <benjamin.walsh@...>
 

On Tue, Mar 14, 2017 at 05:29:57PM +0100, Piotr Mienkowski wrote:
I would like to add one more point to the discussion. It is maybe not
directly related to the topic but should likely be considered when
designing MPU support.

Occasionally, mainly in case of device drivers, on MCUs that have cache
it is required to use the so called non-cacheable RAM regions. A memory
region for which caching has been turned off. This task is typically
done by MPU/MMU and Zephyr MPU architecture should also support it. I.e.
as a developer I would like to have a possibility to place a specific
variable / set of variables in a non-cacheable RAM region.

Following is one real life example when using non-cacheable RAM region
is necessary (for the interested):
Atmel SAM Ethernet module, like most other Ethernet modules, is using
scatter-gather technique to exchange data with the Ethernet driver. To
communicate the location of the data buffers the driver sets-up a so
called descriptor list. This is effectively a place in RAM containing a
sequence of 32-bit words representing buffer location and its status. If
cache is enabled every time the device driver updates data in the
descriptor list it should theoretically also call cache clean operation.
This would ensure that the data is written to RAM where it can be read
by the hardware module. Unfortunately, at the same time the device
driver is modifying one location in the descriptor list the hardware
module can be modifying one next to it. Since cache clean operation
works on a full cache line - 8 bytes in case of Atmel device - it would
overwrite any such modifications done by the hardware module. As such,
ensuring cache coherency using standard techniques is not possible here.
One workaround would be to force write-through cache policy but this is
really just a workaround.
Yet another example that shows the importance of laying out early what
the different MPU regions will be used for, as stated in the top comment
in my original reply to the RFC.


Re: [RFC] MPU support for debugging

Boie, Andrew P
 

On Tue, Mar 14, 2017 at 09:01:53AM +0000, Jon Medhurst (Tixy) wrote:
On Mon, 2017-03-13 at 23:08 +0000, Boie, Andrew P wrote:
Thanks for your feedback, I'm going to spend some more time thinking
about this, but now I'm leaning towards a full userspace solution
(with MPU as a special case with physical=virtual addresses) with a
supplemental API for userspace applications that handles descriptor
management and kernel object allocation.
And validation of all the arguments passed into each function call. No
point going to all this trouble if userspace code can pass in dodgy
pointers or lengths etc. to the kernel.
Agreed, but I think this can be made optional if the application is trusted and
user-space is used more as a debugging aid. Although, that's Yet Another
Kconfig configuration to verify.
I had planned on checking user pointers unconditionally, I think it's a common programming mistake. When running in supervisor mode on behalf of a user thread, we should make sure any buffers passed in are actually owned and writable by the caller.

Andrew


Re: [RFC] MPU support for debugging

Piotr Mienkowski
 

I would like to add one more point to the discussion. It is maybe not directly related to the topic but should likely be considered when designing MPU support.

Occasionally, mainly in case of device drivers, on MCUs that have cache it is required to use the so called non-cacheable RAM regions. A memory region for which caching has been turned off. This task is typically done by MPU/MMU and Zephyr MPU architecture should also support it. I.e. as a developer I would like to have a possibility to place a specific variable / set of variables in a non-cacheable RAM region.

Following is one real life example when using non-cacheable RAM region is necessary (for the interested):
Atmel SAM Ethernet module, like most other Ethernet modules, is using scatter-gather technique to exchange data with the Ethernet driver. To communicate the location of the data buffers the driver sets-up a so called descriptor list. This is effectively a place in RAM containing a sequence of 32-bit words representing buffer location and its status. If cache is enabled every time the device driver updates data in the descriptor list it should theoretically also call cache clean operation. This would ensure that the data is written to RAM where it can be read by the hardware module. Unfortunately, at the same time the device driver is modifying one location in the descriptor list the hardware module can be modifying one next to it. Since cache clean operation works on a full cache line - 8 bytes in case of Atmel device - it would overwrite any such modifications done by the hardware module. As such, ensuring cache coherency using standard techniques is not possible here. One workaround would be to force write-through cache policy but this is really just a workaround.

Piotr


Re: how to user KTimer?

Li, Jun R
 

Ben,
Thanks for the explanation! It is very clear now.

Regards,
Jun

On Mar 14, 2017, at 06:30, Benjamin Walsh <benjamin.walsh@windriver.com> wrote:

Hi Jun,

I’m trying to use the “k_timer” in my project, and get confused by the
parameters in the function “k_timer_start(struct k_timer *timer,
int32_t duration, int32_t period)”. How are the parameters “duration”
and “period” defined for this one? How can I use them? Thank you!
<duration> is the time before the first timer expiry, and <period> is
the period at which it will expiry subsenquently. If you specify a
<period> of 0, the timer only fire once.

e.g.

If the current uptime is 1000ms, and you specify duration = 100 and
period = 50, the timer will expire at uptime = 1100 and then at every
subsequent multiple of 50 (1150, 1200, 1250, etc) until cancelled.

HTH,
Ben

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


Re: [RFC] MPU support for debugging

Benjamin Walsh <benjamin.walsh@...>
 

On Tue, Mar 14, 2017 at 09:01:53AM +0000, Jon Medhurst (Tixy) wrote:
On Mon, 2017-03-13 at 23:08 +0000, Boie, Andrew P wrote:
Thanks for your feedback, I'm going to spend some more time thinking
about this, but now I'm leaning towards a full userspace solution (with
MPU as a special case with physical=virtual addresses) with a
supplemental API for userspace applications that handles descriptor
management and kernel object allocation.
And validation of all the arguments passed into each function call. No
point going to all this trouble if userspace code can pass in dodgy
pointers or lengths etc. to the kernel.
Agreed, but I think this can be made optional if the application is
trusted and user-space is used more as a debugging aid. Although, that's
Yet Another Kconfig configuration to verify.


Re: how to user KTimer?

Benjamin Walsh <benjamin.walsh@...>
 

Hi Jun,

I’m trying to use the “k_timer” in my project, and get confused by the
parameters in the function “k_timer_start(struct k_timer *timer,
int32_t duration, int32_t period)”. How are the parameters “duration”
and “period” defined for this one? How can I use them? Thank you!
<duration> is the time before the first timer expiry, and <period> is
the period at which it will expiry subsenquently. If you specify a
<period> of 0, the timer only fire once.

e.g.

If the current uptime is 1000ms, and you specify duration = 100 and
period = 50, the timer will expire at uptime = 1100 and then at every
subsequent multiple of 50 (1150, 1200, 1250, etc) until cancelled.

HTH,
Ben

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


Re: Reg: Command handling Via USB driver

Mahendravarman Rajarao (RBEI/EAA10) <Mahendravarman.Rajarao@...>
 

Hi

Thanks for the reply
But as of now with the available zephyr, the USB can work either as DFU flashing or as UART over USB (CDC) and not both functionalities together.

We have a requirement at End of Line, we need to pass commands from a PC to test each interfaces. And finally we need to flash the functional software to the device via DFU flashing.

So only I have a doubt that can we use USB DFU class and expand the driver to handle some more custom commands other than DFU commands to satisfy my requirement.

Please suggest !!

Thanks
Mahendra

-----Original Message-----
From: Andrei Emeltchenko [mailto:andrei.emeltchenko.news@gmail.com]
Sent: Thursday, March 09, 2017 1:47 PM
To: Mahendravarman Rajarao (RBEI/EAA10) <Mahendravarman.Rajarao@in.bosch.com>
Cc: devel@lists.zephyrproject.org
Subject: Re: [Zephyr-devel] Reg: Command handling Via USB driver

Hi Mahendra,

On Thu, Mar 09, 2017 at 04:54:23AM +0000, Mahendravarman Rajarao (RBEI/EAA10) wrote:
Hi

We are using Quark_C1000 controller in our project along with zephyr 1.6.
I could see zephyr 1.6 has support for USB.

I have a query.

We are currently having a requirement of send some commands via USB (from
a PC)  and based on the commands received (in the device ) we will execute
certain applications.

For this requirement I need clarifications regarding the USB driver.

I could see that the USB DFU handles command which is sent from a PC.

Do I need to expand this driver itself for my requirement or Should I use
the USB UART driver for my requirement ?
It is easier to use cdc_acm sample in samples/usb/cdc_acm, then your PC already has the driver for it and it appears on your PC as ttyACM or ttyUSB, then you can communicate over serial.

If you want to implement certain USB class like Bluetooth in hci_usb sample you should look here: samples/bluetooth/hci_usb/

For other samples you need AFAIK to have certain driver, like btusb for hci_usb, etc.

Best regards
Andrei Emeltchenko


Re: [RFC] MPU support for debugging

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

On Mon, 2017-03-13 at 23:08 +0000, Boie, Andrew P wrote:
Thanks for your feedback, I'm going to spend some more time thinking
about this, but now I'm leaning towards a full userspace solution (with
MPU as a special case with physical=virtual addresses) with a
supplemental API for userspace applications that handles descriptor
management and kernel object allocation.
And validation of all the arguments passed into each function call. No
point going to all this trouble if userspace code can pass in dodgy
pointers or lengths etc. to the kernel.

--
Tixy


Re: Reg: GPIO callbacks on galileo Gen 2

Dinh, Kien T
 

Hi Vishal,

 

The button example was originally created for the nucleo_f103rb board, and then expanded for others. However, looking at the latest README.rst, galileo is not in the supported list.

 

Regards,

Kien

 

From: <zephyr-devel-bounces@...> on behalf of Vishal Varun Tipparaju <vlnu1@...>
Date: Sunday, March 12, 2017 9:49
To: "zephyr-devel@..." <zephyr-devel@...>
Subject: [Zephyr-devel] Reg: GPIO callbacks on galileo Gen 2

 

Hello,

 

I have been working on gpio callbacks for galileo gen2 board. I have referred to zephyr/samples/basic/button/ example and tried the callbacks on DW4 gpio pin. But the callbacks are never fired. Kindly suggest appropriate changes for galileo gen 2 to use the button sample project.

 

Kindly redirect me to the appropriate mailing list if this is not the list for this issue

 

Thank you

Vishal T


how to user KTimer?

Li, Jun R
 

Hi there,

 

I’m trying to use the “k_timer” in my project, and get confused by the parameters in the function “k_timer_start(struct k_timer *timer, int32_t duration, int32_t period)”. How are the parameters “duration” and “period” defined for this one? How can I use them? Thank you!

 

Regards,

Jun

 

 


Graphics and Zephyr

Bill Rees
 


    I'm looking around for RTOSs that support graphics and while I don't see any references to graphics support in Jira or schedules I'm hoping someone knows of a 3rd party library that would work?

Thanks,
Bill Rees

--

___________________________________________
 : zGlue Inc., Mountain View, CA
___________________________________________



Re: [RFC] MPU support for debugging

Boie, Andrew P
 

On Sat, 2017-03-11 at 17:21 -0500, Benjamin Walsh wrote:
Some random thoughts on this, do with them as you wish. :)

To get more detailed feedback, I think you need to document how
exactly
you intend on using the MPU.

- Introduce the notion of User/Supervisor threads. User threads
would
only have write access to their own stack, plus some additional
memory
                            ^^^^^^^^^^^^^^^
And whatever other stacks are in the same protection region: stack
overflow will only corrupt the current region, but they can still
happen
and wreck havoc within the protection area. Or are you thinking of
rewriting the memory protection area boundaries on every context
switch
to with bounds around the current thread's stack ? I don't mean only
changing the permissions, but the boundaries themselves ?
Yes, that's the intention. Every context switch _Swap() would involve
reprogramming the MPU (or MMU page tables) to appropriate values for
the incoming thread.

THIS IS NOT A SECURITY FEATURE
This bothers me a bit. If you ever want to turn this into a more
fleshed-out user-space model, would you introduce a third API/model
or
modify them again ?

My gut feeling would be to design for the full "user-space" model,
and
then have the reduced-capability MPU-model be a special case of it.

Then again, depends on the timeframe and how future-proof you want to
design this.
My expectation was that we can implement this proposal without changing
our existing kernel APIs. Kernel APIs would be supplemented with a few
extra calls to drop a thread down to User mode and set up its memory
regions. I don't see much else changing.

To go to a full userspace model, my thought process was that we have to
re-do all the kernel APIs to work with descriptors instead of pointers,
introduce an allocator on the kernel side, etc. My thinking was that it
will fundamentally change the class of devices that we are targeting
with this OS, and I was loath to introduce such a sweeping change to
all the kernel APIs.

However, I think you may have convinced me, read on..


I think this needs more of a "split" between kernel and "user-space"
APIs than a redesign. But then, kernel applications could not be
rebuilt
as user-space applications. Applications using the user-space API
could
probably be rebuilt as kernel applications, if we provided the
user-space API as a very thin layer around the current kernel APIs in
the kernel. Nothing would prevent removing the user-space layer and
run
kernel-only.
I like this idea. Supplement all the k_* APIs with z_* APIs (or
whatever naming convention people agree on) which are intended to be
run from userspace context. They will handle allocation and descriptor
management and call into the kernel APIs. Let people working on
severely RAM-constrained devices like Quark D2000 keep using kernel
APIs like they are now. Everybody wins.

The real trick of course is in the scenario where the protection is
only being used during the debug phase of development, how to make the
userspace layer thin enough with memory protection disabled that it
would be roughly comparable in footprint and performance to an app that
just used kernel APIs directly.

- No need for system calls for privilege elevation. Through macro
magic, if memory protection is turned on we can wrap kernel/driver
What do you mean by "macro magic" ? There has to be a mechanism to
trigger the privilege elevation. On ARM, you have to use the SVC
instruction, handle the exception, write the CONTROL register, and
come
back to the next instruction after SVC. That's basically one system
call, which purpose is to elevate the privilege of the current
thread.
I am waving my arms here, but I was thinking this would be a relatively
small amount of code to do a generic privilege escalation to run
whatever kernel code is desired by the caller, rather than a carefully
controlled table of valid system call entry points.

But this is moot, I like the idea of supplementing the kernel APIs with
a set of parallel userspace APIs much better.

Thanks for your feedback, I'm going to spend some more time thinking
about this, but now I'm leaning towards a full userspace solution (with
MPU as a special case with physical=virtual addresses) with a
supplemental API for userspace applications that handles descriptor
management and kernel object allocation. I'll send another proposal
with this taken into account.

Andrew


Testing random number generators

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

Hi all,

I realized recently that no random number generation API
test framework was available in Zephyr (apart from a very simple test
in tests/kernel/common/src/rand32.c).
I realize hardware number generators differ in expected "quality"
and that such a framework should allow tuning expected results,
like the generators' guaranteed period, for instance.

I took a look recently at the ENT program (http://www.fourmilab.ch/random/),
which performs a battery of tests on streams of bytes, and
provides global metrics at the end of the tests (correlation, mean value...).

This is only a suggestion, but we could write a simple generic framework using
the UART serial line to run the test with ENT running on the host computer.
I find ENT to be simple to use, and besides, its byte-level granulatity matches
the API exposed by random.h. I don't have extensive experience with hardware
number generators and therefore am probably unaware of potential issues
regarding the efforts to make generic test metrics (lack of hardware documentation
comes to my mind).

Any ideas or critics are welcome.

Regards,

--
Geoffrey


Zephyr 1.7.0 tagged

Nashif, Anas
 

Hi,

 

We are pleased to announce the release of Zephyr kernel version 1.7.0. This

release continues refinement of the unified kernel introduced with the 1.6.0

kernel release, simplifying the overall Zephyr architecture and programming

interfaces. This is the last release that will support the deprecated legacy

nano- and micro-kernel APIs found in the 1.5.0 release and earlier.

 

This release introduces a new native IP stack, replacing the legacy uIP stack,

maintaining the legacy functionality, adding additional capabilities, and allowing

future improvements.

 

We have introduced support for the RISC V and Xtensa architectures and now

support 6 architectures in total.

 

Device tree support for ARM based boards added. The initial

device tree support includes flash/sram base address and UART devices.  Board

support includes NXP Kinetis based SoCs, ARM Beetle, TI CC3200 LaunchXL, and

STML32L476 based SoCs. Plan is to add support for other architectures and

expand device support in upcoming Zephyr releases.

 

More details can be found in the release notes at:

 

https://www.zephyrproject.org/doc/1.7.0/release-notes.html

 

 

Many thanks to all who contributed to this release and continue to make Zephyr

better every day.

 

Master branch is now open for feature development. The Zephyr 1.8 release is

planned for end of May 2017.

 

Regards,

Anas


Reg: GPIO callbacks on galileo Gen 2

Vishal Varun Tipparaju <vlnu1@...>
 

Hello,

I have been working on gpio callbacks for galileo gen2 board. I have referred to zephyr/samples/basic/button/ example and tried the callbacks on DW4 gpio pin. But the callbacks are never fired. Kindly suggest appropriate changes for galileo gen 2 to use the button sample project.

Kindly redirect me to the appropriate mailing list if this is not the list for this issue

Thank you
Vishal T

5441 - 5460 of 8033