Date   

Re: offsetof() in array sizes

Boie, Andrew P
 

Thanks for the reply, here's a patch below.
Hi Carles,

Can you submit your contribution to our Gerrit server?

https://nexus.zephyrproject.org/content/sites/site/org.zephyrproject.zephyr/latest/contribute/gerrit.html

Regards,
Andrew


Re: offsetof() in array sizes

Carles Cufi
 

Hi Andrew,

-----Original Message-----
From: Boie, Andrew P [mailto:andrew.p.boie(a)intel.com]
Sent: Tuesday, August 23, 2016 16:54
To: Cufi, Carles <Carles.Cufi(a)nordicsemi.no>;
devel(a)lists.zephyrproject.org
Subject: RE: offsetof() in array sizes



If one includes a offsetof() statement inside a macro that is then
used to size an array, the following warning is issued by GCC:

warning: variably modified <VAR_NAME> at file scope

The fix for this, at least for GCC, is to use:

#if defined(__GNUC__)
#define offsetof(s, m) __builtin_offsetof(s, m) #else #define
offsetof(s, m) ((size_t)(&(((s *)0)->m))) #endif

Any thoughts about this particular matter? We'd like to use offsetof()
when sizing arrays in the BLE Controller but we don't want to
duplicate the
offsetof() macro.
I don't see a problem with replacing the existing definition in the
minimal libc with the corrected version above.
Can you send a patch against lib/libc/minimal/include/stddef.h?

Andrew
Thanks for the reply, here's a patch below.

Thanks,

Carles

From ddd980e2418053ae346f25deb8ae029f50cb20b3 Mon Sep 17 00:00:00 2001
From: Carles Cufi <carles.cufi(a)nordicsemi.no>
Date:
Subject: [PATCH 1/1] lib: Use offsetof() builtin with GCC

The default offsetof() implementation generates a warning
(variably modified <variable> at file scope) when used in
to define the size of an array. By using this builtin with
GCC we avoid the warning and make sure no variable-size
arrays are used.

Change-Id: Iae215f777241f7daaa061067230086dffaa8311d
Signed-off-by: Carles Cufi <carles.cufi(a)nordicsemi.no>
---
lib/libc/minimal/include/stddef.h | 4 ++++
1 file changed, 4 insertions(+)

diff --git a/lib/libc/minimal/include/stddef.h b/lib/libc/minimal/include/stddef.h
index 2e1ef66..bcc0a6e 100644
--- a/lib/libc/minimal/include/stddef.h
+++ b/lib/libc/minimal/include/stddef.h
@@ -27,6 +27,10 @@
typedef int ptrdiff_t;
#endif

+#if defined(__GNUC__)
+#define offsetof(type, member) __builtin_offsetof(type, member)
+#else
#define offsetof(type, member) ((size_t) (&((type *) NULL)->member))
+#endif

#endif /* __INC_stddef_h__ */
--
1.9.1


Re: Porting to Cortex-M0+

Nashif, Anas
 

On 23 Aug 2016, at 10:39, Vinicius Costa Gomes <vinicius.gomes(a)intel.com> wrote:

Hi,

Euan Mutch <euan.mutch(a)gmail.com> writes:

I have started writing the drivers for peripherals on the M0+ now, but
I am getting the feeling that I should probably just add Atmel ASF to
the \ext\hal\ folder rather than basically rewriting them. I am just
wondering why this was not done already for the Arduino Due which also
has an Atmel SOC?
Licensing issues perhaps[1]?
Actually more because nobody did it until now, so you are welcome to do this.



"Disclaimer and Credits

...

4. This software may only be redistributed and used in connection with
an Atmel microcontroller product."

I do not think this will conflict with the intent of how to use it in Zephyr. After all the code will be used with Atmel MCUs only…

Anas


[1] http://www.atmel.com/Images/asf-releasenotes-3.32.0.pdf page 34


Cheers,


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/4254 : Bluetooth: BR/EDR: Fix security check on legacy
- https://gerrit.zephyrproject.org/r/4246 : nano_work: Make use of ATOMIC_DEFINE for the flags
- https://gerrit.zephyrproject.org/r/4245 : Bluetooth: L2CAP: Disable fragmentation of rx pdu
- https://gerrit.zephyrproject.org/r/4250 : Bluetooth: RFCOMM: Fix cr bit of address in MSC response
- https://gerrit.zephyrproject.org/r/4227 : MAINTAINERS: Add BLUETOOTH CONTROLLER section
- https://gerrit.zephyrproject.org/r/4231 : net/yaip: Use the dummy L2 frame format for Qemu
- https://gerrit.zephyrproject.org/r/4241 : samples/quapi_client: use yaip
- https://gerrit.zephyrproject.org/r/4242 : samples/quapi_server: use yaip
- https://gerrit.zephyrproject.org/r/4248 : net: Fix net_send return value documentation
- https://gerrit.zephyrproject.org/r/4236 : samples/net: Add a sample for a CoAP client
- https://gerrit.zephyrproject.org/r/4229 : drivers/slip: Fix warnings when TAP support is disabled
- https://gerrit.zephyrproject.org/r/4239 : FIXME: use yaip
- https://gerrit.zephyrproject.org/r/4238 : FIXME: use yaip
- https://gerrit.zephyrproject.org/r/4243 : tests/quapi: use yaip
- https://gerrit.zephyrproject.org/r/4234 : tests: Add simple CoAP tests
- https://gerrit.zephyrproject.org/r/4232 : tests: Support computing the result of tests
- https://gerrit.zephyrproject.org/r/4233 : lib: Introduce the CoAP implementation for Zephyr
- https://gerrit.zephyrproject.org/r/4237 : MAINTAINERS: add Quapi section
- https://gerrit.zephyrproject.org/r/4230 : net/yaip: Fix listening on IPv6 ports
- https://gerrit.zephyrproject.org/r/4235 : samples/net: Add a sample for a CoAP server
- https://gerrit.zephyrproject.org/r/4244 : sampes/quapi_observer_server: Add observer sample
- https://gerrit.zephyrproject.org/r/4240 : iot/quapi: Add support for observing resources

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/3997 : Bluetooth: L2CAP: Implement connect command on BR/EDR
- https://gerrit.zephyrproject.org/r/4027 : Bluetooth: GATT: Add queuing support
- https://gerrit.zephyrproject.org/r/4028 : Bluetooth: ATT: Make it safe to access the request list
- https://gerrit.zephyrproject.org/r/4186 : x86: fix incorrect printk() usage
- https://gerrit.zephyrproject.org/r/4225 : net: raising MAX_TCP_RETRY_COUNT to account for slower response
- https://gerrit.zephyrproject.org/r/4111 : usb: Add USB sample build test to sanity check
- https://gerrit.zephyrproject.org/r/4218 : Bluetooth: A2DP: Basic Implementation of A2DP Sink.
- https://gerrit.zephyrproject.org/r/4214 : doc: Add more content for networking documentation
- https://gerrit.zephyrproject.org/r/4197 : Bluetooth: AVDTP: Module intialization
- https://gerrit.zephyrproject.org/r/3439 : spi_qmsi: Add suspend/resume
- https://gerrit.zephyrproject.org/r/4091 : board: nrf52_pca10040: Include BLE controller by default
- https://gerrit.zephyrproject.org/r/4090 : Bluetooth: Controller: Add BLE controller driver
- https://gerrit.zephyrproject.org/r/4089 : Bluetooth: Controller: A full, hardware-agnostic BLE Link Layer
- https://gerrit.zephyrproject.org/r/4226 : net: Do not fill in TCP option bytes for all packets
- https://gerrit.zephyrproject.org/r/4086 : Bluetooth: Controller: Hardware abstraction layer for nRF5x radio
- https://gerrit.zephyrproject.org/r/4169 : printk: "support" some modifier codes
- https://gerrit.zephyrproject.org/r/4171 : tests: test_printk: crude printk test case
- https://gerrit.zephyrproject.org/r/4206 : libc: minimal: add reduced inttypes.h
- https://gerrit.zephyrproject.org/r/4205 : recipes-devtools/gcc: newlib-stdint.h: Remove 32 bit longs
- https://gerrit.zephyrproject.org/r/4088 : Bluetooth: Controller: Add initial HCI implementation
- https://gerrit.zephyrproject.org/r/4087 : Bluetooth: Controller: Add a util folder with basic primitives
- https://gerrit.zephyrproject.org/r/3527 : console: shell: Shell enhancement - Support multiple modules

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/4249 : Bluetooth: tests/shell: Remove not needed RFCOMM option from config
- https://gerrit.zephyrproject.org/r/4228 : doc: remove 1.5 doc link until after release
- https://gerrit.zephyrproject.org/r/4247 : Bluetooth: tests/shell: Add dedicated BR/EDR config
- https://gerrit.zephyrproject.org/r/4210 : grub: Tweak build_grub.sh for proxy issues
- https://gerrit.zephyrproject.org/r/4202 : net: ip: Fix compiling with 15.4
- https://gerrit.zephyrproject.org/r/4221 : Bluetooth: L2CAP: Fix reset channel state context
- https://gerrit.zephyrproject.org/r/4220 : Bluetooth: L2CAP: Refactor connection security handler
- https://gerrit.zephyrproject.org/r/4219 : net: Add TODO items for L2 and 802.15.4


Re: offsetof() in array sizes

Boie, Andrew P
 


If one includes a offsetof() statement inside a macro that is then used to size
an array, the following warning is issued by GCC:

warning: variably modified <VAR_NAME> at file scope

The fix for this, at least for GCC, is to use:

#if defined(__GNUC__)
#define offsetof(s, m) __builtin_offsetof(s, m) #else #define offsetof(s, m)
((size_t)(&(((s *)0)->m))) #endif

Any thoughts about this particular matter? We'd like to use offsetof() when
sizing arrays in the BLE Controller but we don't want to duplicate the
offsetof() macro.
I don't see a problem with replacing the existing definition in the minimal libc with the corrected version above.
Can you send a patch against lib/libc/minimal/include/stddef.h?

Andrew


Naming both a top-level directory and a branch "net" is a bit unfortunate

Paul Sokolovsky
 

Hello,

Today I tried to figure why I got my Zephyr repository clone in an
inconsistent state, and here's what I found:

Git for quite a few years allow to checkout a remote's repository with:

git checkout <short-remote-name>

e.g.

git checkout net

is supposed to just checkout origin/net if didn't have it already, and
set it up a tracking remote branch.

Well, that doesn't work with Zephyr, because there's "net" top-level
directory. It's easy to overlook that "git checkout net" didn't produce
a notice of switching to another branch/setting up tracking, and wonder
why you didn't have the latest net's commits in git log. My next step
was to pull these branch changes explicitly: "git pull --rebase origin
net", and that's how I ended up with net's commit in my master branch.


I hope it's just me, but posting this in case someone else will have a
similar problem (or if maintainers get similar hard-to-explain reports
of "my local repo got messed up!").

The solution is to use explit --track option:

git checkout -b net --track origin/net

(I didn't have to use --track explicitly for a couple of years).


--
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: Porting to Cortex-M0+

Vinicius Costa Gomes
 

Hi,

Euan Mutch <euan.mutch(a)gmail.com> writes:

I have started writing the drivers for peripherals on the M0+ now, but
I am getting the feeling that I should probably just add Atmel ASF to
the \ext\hal\ folder rather than basically rewriting them. I am just
wondering why this was not done already for the Arduino Due which also
has an Atmel SOC?
Licensing issues perhaps[1]?

"Disclaimer and Credits

...

4. This software may only be redistributed and used in connection with
an Atmel microcontroller product."


[1] http://www.atmel.com/Images/asf-releasenotes-3.32.0.pdf page 34


Cheers,
--
Vinicius


Reliability of Gerrit/Jira server

Paul Sokolovsky
 

Hello,

I more or less regularly (e.g., once a day) get following when pull
from the Zephyr repo:

$ git pull --rebase
fatal: unable to access 'https://gerrit.zephyrproject.org/r/zephyr/':
GnuTLS recv error (-9): A TLS packet with unexpected length was
received.

Also, sometimes, it takes quite a while to open a particular ticket in
Jira.

That's not too serious though, so I'm mostly posting to help
maintainers track (perceived) reliability of the project infrastructure
over time.

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


offsetof() in array sizes

Carles Cufi
 

Hi there,

If one includes a offsetof() statement inside a macro that is then used to size an array, the following warning is issued by GCC:

warning: variably modified <VAR_NAME> at file scope

The fix for this, at least for GCC, is to use:

#if defined(__GNUC__)
#define offsetof(s, m) __builtin_offsetof(s, m)
#else
#define offsetof(s, m) ((size_t)(&(((s *)0)->m)))
#endif

Any thoughts about this particular matter? We'd like to use offsetof() when sizing arrays in the BLE Controller but we don't want to duplicate the offsetof() macro.

Thanks,

Carles


Re: _Swap crash in attempt to add support for STM32F3 board

Maciek Borzecki <maciek.borzecki@...>
 

On Mon, Aug 22, 2016 at 4:46 PM, Mirza Krak <mirza.krak(a)gmail.com> wrote:
2016-08-19 4:25 GMT+02:00 Ricardo Salveti <ricardo.salveti(a)linaro.org>:
On Thu, Aug 18, 2016 at 4:43 PM, Mirza Krak <mirza.krak(a)gmail.com> wrote:
Hi.

My first post on this list so would like to say that this project
seems very promising and is something that I have been waiting for.

I wanted to get involved so I dusted of a STM32F3 discovery board and
started coding. It helped a lot that there was STM32F1 support all
ready.
Not related to your issue, but we also got a work-in-progress port for
STM32F4 last week, in case that is useful for you. Currently working
at https://github.com/rsalveti/zephyr/commits/stm32-dev, and expecting
to start the clean-up and upstreaming over the next couple of weeks.

Clock, uart, gpio, all working and tested with STM32F4 Nucleo.
Thank you for sharing your port, it was really helpful and my work is
heavily based on that.

FYI I now also have a STM32F3 Discovery board working (only clock and
gpio so far). Will also implement GPIO IRQ support. But then I plan to
start cleaning up and attempt to mainline. Will do the uart part later
since it is significantly different compared to F1 and F4.

I am not sure about your timeline, but we could end up clashing with
our ports. So I am unsure how it is best to proceed forward in
attempting to mainline.

I will happily move forward in a join effort.

My port is available on https://github.com/mirzak/zephyr-os/tree/stm32f3
Author of SM32F1 port here. I started working on STM32F3 back in March
and most of the changes I did at that time were pushed here:
https://github.com/bboozzoo/zephyr/commits/bboozzoo/stm32f3
The idea was to extract common pieces of STM32 functionality and have
individual STM32[FL]x ports provide chip specific overrides. That was
before external libraries were introduced, so I guess I would
reevaluate the approach if I were to start now.

Anyways, since then I have moved to other projects. However guys from
my team used the that tree as a base for their F3/F4 ports that AFAIK
are currently being shipped as part of a commercial project for one of
our customers (along with drivers for DAC and some sensors). Also, the
port was supposed to be posted for upstream review at some point.

I believe they should be subscribed to devel, but I will ping them to
check their status once I get back from vacation next week.

Cheers,
--
Maciek Borzecki


Re: Porting to Cortex-M0+

Euan Mutch <euan.mutch@...>
 

I have started writing the drivers for peripherals on the M0+ now, but I am getting the feeling that I should probably just add Atmel ASF to the \ext\hal\ folder rather than basically rewriting them. I am just wondering why this was not done already for the Arduino Due which also has an Atmel SOC?


Re: _Swap crash in attempt to add support for STM32F3 board

Mirza Krak
 

2016-08-22 18:38 GMT+02:00 Amit Kucheria <amit.kucheria(a)verdurent.com>:

Mirza,

I expect we'll start cleaning up our port in a week or two. I'm trying
to finish up the SPI driver before starting a cleanup.
Hi Amit.

Good to know that you are working on a SPI driver, I was planing on
doing that as well. Now I wont :).

I will wait for your clean-up then, I will be going on vacation next
week and I am probably not gonna finish anything until then.

Best Regards
Mirza


Re: having trouble getting the echo client to work using TCP/uIP on K64F

Morgaine
 

This state of play with FRDM-K64F is really quite unexpected. Freescale
and their new owners NXP are after all *founding members* of the Zephyr
Project, and FRDM-K64F is not only their leading FRDM-series board but it
is also the only NXP board which is explicitly listed as Supported.

Given the above, it would be very reasonable for any reader to assume that
at least this one board would be excellently supported by Zephyr (as a
result of NXP's support), especially in regard to its key features like
built-in networking. Evidently that would be a false assumption.

Do founding members of the project not offer to provide manpower support or
running code, at least for their own boards?

I think it would be useful to understand the relationship between
sponsoring corporations and the project better. Despite operating under
the umbrella of the Linux Foundation, code contributions in Zephyr may
differ from the Linux model, for which companies commonly contribute kernel
code for their hardware.

If this is written down somewhere already, a link would be awesome.
Thanks! :-)

Morgaine.


Re: _Swap crash in attempt to add support for STM32F3 board

Amit Kucheria
 

On Mon, Aug 22, 2016 at 8:16 PM, Mirza Krak <mirza.krak(a)gmail.com> wrote:
2016-08-19 4:25 GMT+02:00 Ricardo Salveti <ricardo.salveti(a)linaro.org>:
On Thu, Aug 18, 2016 at 4:43 PM, Mirza Krak <mirza.krak(a)gmail.com> wrote:
Hi.

My first post on this list so would like to say that this project
seems very promising and is something that I have been waiting for.

I wanted to get involved so I dusted of a STM32F3 discovery board and
started coding. It helped a lot that there was STM32F1 support all
ready.
Not related to your issue, but we also got a work-in-progress port for
STM32F4 last week, in case that is useful for you. Currently working
at https://github.com/rsalveti/zephyr/commits/stm32-dev, and expecting
to start the clean-up and upstreaming over the next couple of weeks.

Clock, uart, gpio, all working and tested with STM32F4 Nucleo.
Thank you for sharing your port, it was really helpful and my work is
heavily based on that.

FYI I now also have a STM32F3 Discovery board working (only clock and
gpio so far). Will also implement GPIO IRQ support. But then I plan to
start cleaning up and attempt to mainline. Will do the uart part later
since it is significantly different compared to F1 and F4.

I am not sure about your timeline, but we could end up clashing with
our ports. So I am unsure how it is best to proceed forward in
attempting to mainline.

I will happily move forward in a join effort.

My port is available on https://github.com/mirzak/zephyr-os/tree/stm32f3
Mirza,

I expect we'll start cleaning up our port in a week or two. I'm trying
to finish up the SPI driver before starting a cleanup.

Cheers,
Amit


Re: Implementation for QMSI SPI driver - burst mode

Tomasz Bursztyka
 

Hi Mahendravarman,

Please help me on the following

We have connected a BMA255 accelerometer in the SPI of Atlas peak.
BMA255 has a FIFO data readout register (0x3F). This register should be read as a BURST mode ( the address is 0x3F , but we need to initiate burst mode)
Expected data to be read from the register (0x3F) is 192 bytes

1. Will the SPI_transceive function will support burst mode ??
Sure, I don't see why it would not.


2. For the above use case of BMA255 , should I need to issue function as below for SPI burst read

cnt = 192 ;
iError = spi_transceive(dev_addr, array, cnt+1,array, cnt+1);
Yes, make sure the array provides the dummy bytes (0s).

Have a look at drivers/sensors/sensor_bma* , I believe some do have such
reading.

Br,

Tomasz


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: 3
[ZEP-433] (Won't Do) Unclear how to obtain Arduino 101 "original bootloader" for dfu-util operation
https://jira.zephyrproject.org/browse/ZEP-433

[ZEP-478] (Fixed) Linux setup docs missing step to install curses development package for Fedora
https://jira.zephyrproject.org/browse/ZEP-478

[ZEP-516] (Fixed) Ubuntu setup instructions missing 'upgrade' step
https://jira.zephyrproject.org/browse/ZEP-516


RESOLVED JIRA items within last 24 hours: 9
[ZEP-650] (Fixed) Quark SE: Implement PM reference application
https://jira.zephyrproject.org/browse/ZEP-650

[ZEP-662] (Fixed) QMSI shim driver: Pinmux: Implement suspend and resume callbacks
https://jira.zephyrproject.org/browse/ZEP-662

[ZEP-658] (Fixed) QMSI shim driver: GPIO: Implement suspend and resume callbacks
https://jira.zephyrproject.org/browse/ZEP-658

[ZEP-659] (Fixed) QMSI shim driver: UART: Implement suspend and resume callbacks
https://jira.zephyrproject.org/browse/ZEP-659

[ZEP-655] (Fixed) QMSI shim driver: PWM: Implement suspend and resume callbacks
https://jira.zephyrproject.org/browse/ZEP-655

[ZEP-652] (Fixed) QMSI shim driver: RTC: Implement suspend and resume callbacks
https://jira.zephyrproject.org/browse/ZEP-652

[ZEP-616] (Fixed) OS X setup instructions not working on El Capitan
https://jira.zephyrproject.org/browse/ZEP-616

[ZEP-583] (Cannot Reproduce) "make debugserver" get "lakemont_halt" @quark_se_devboard
https://jira.zephyrproject.org/browse/ZEP-583

[ZEP-708] (Fixed) tests/kernel/test_ipm fails on Arduino 101
https://jira.zephyrproject.org/browse/ZEP-708


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/4225 : net: raising MAX_TCP_RETRY_COUNT to account for slower response
- https://gerrit.zephyrproject.org/r/4226 : uIP: don't fill in TCP option bytes (in header) for all packets
- https://gerrit.zephyrproject.org/r/4219 : net: Add TODO items for L2 and 802.15.4
- https://gerrit.zephyrproject.org/r/4221 : Bluetooth: L2CAP: Fix reset channel state context
- https://gerrit.zephyrproject.org/r/4220 : Bluetooth: L2CAP: Refactor connection security handler
- https://gerrit.zephyrproject.org/r/4214 : doc: Add more content for networking documentation

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/4028 : Bluetooth: ATT: Make it safe to access the request list
- https://gerrit.zephyrproject.org/r/4027 : Bluetooth: GATT: Add queuing support
- https://gerrit.zephyrproject.org/r/4081 : power_mgmt: Updated Power Management device driver API
- https://gerrit.zephyrproject.org/r/3997 : Bluetooth: L2CAP: Implement connect command on BR/EDR
- https://gerrit.zephyrproject.org/r/4090 : Bluetooth: Controller: Add driver that glues Link Layer with the BLE stack
- https://gerrit.zephyrproject.org/r/4086 : Bluetooth: Controller: Hardware abstraction layer for nRF5x radio
- https://gerrit.zephyrproject.org/r/4168 : net: samples: Add a simple Qemu sample for testing off-line 802.15.4
- https://gerrit.zephyrproject.org/r/4165 : net: drivers: Add a fake ieee802154 radio driver for qemu
- https://gerrit.zephyrproject.org/r/4167 : samples: net: Qemu make utilities update
- https://gerrit.zephyrproject.org/r/4166 : samples: net: Moving the current ieee802154 sample
- https://gerrit.zephyrproject.org/r/4202 : net: ip: Fix compiling with 15.4
- https://gerrit.zephyrproject.org/r/4091 : board: nrf52_pca10040: Include Controller by default in board nrf52_pca10040
- https://gerrit.zephyrproject.org/r/4089 : Bluetooth: Controller: A full, hardware-agnostic Link Layer implementation
- https://gerrit.zephyrproject.org/r/4087 : Bluetooth: Controller: Add a util folder with basic primitives
- https://gerrit.zephyrproject.org/r/4088 : Bluetooth: Controller: Initial impl. of a HCI controller-side interface

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/4215 : Bluetooth: RFCOMM: Handle data and credit from peer
- https://gerrit.zephyrproject.org/r/4212 : Bluetooth: RFCOMM: Perform MSC transaction after dlc
- https://gerrit.zephyrproject.org/r/4213 : Bluetooth: RFCOMM: Move rfcomm_make_uih_msg() up
- https://gerrit.zephyrproject.org/r/4211 : Merge remote-tracking branch 'origin/master' into net
- https://gerrit.zephyrproject.org/r/4200 : net: samples: Fix slip config for echo-server and echo-client
- https://gerrit.zephyrproject.org/r/4201 : net: samples: Fix the echo-server IPv6 address
- https://gerrit.zephyrproject.org/r/4196 : net: TODO file for networking
- https://gerrit.zephyrproject.org/r/4144 : net: tests: Enable unit tests for the new IP stack
- https://gerrit.zephyrproject.org/r/4199 : net: Clarify the CONFIG_NET_TESTING setting
- https://gerrit.zephyrproject.org/r/4203 : net: samples: Fix the location of net-tools project files


Implementation for QMSI SPI driver - burst mode

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

Hi Tomasz

Please help me on the following

We have connected a BMA255 accelerometer in the SPI of Atlas peak.
BMA255 has a FIFO data readout register (0x3F). This register should be read as a BURST mode ( the address is 0x3F , but we need to initiate burst mode)
Expected data to be read from the register (0x3F) is 192 bytes

1. Will the SPI_transceive function will support burst mode ??

2. For the above use case of BMA255 , should I need to issue function as below for SPI burst read

cnt = 192 ;
iError = spi_transceive(dev_addr, array, cnt+1,array, cnt+1);






Best regards

Mahendravarman Rajarao

-----Original Message-----
From: Tomasz Bursztyka [mailto:tomasz.bursztyka(a)linux.intel.com]
Sent: Wednesday, July 06, 2016 11:16 PM
To: Mahendravarman Rajarao (RBEI/EAA3) <Mahendravarman.Rajarao(a)in.bosch.com>
Subject: Re: [devel] Re: Re: Re: Re: Re: Need Callback Implementation for QMSI SPI driver

Hi Mahendravarman,

Please help me on the following

I have a query.
In the qmsi SPI driver under the spi_qmsi_transceive function its
stated as

/* FIXME: QMSI expects rx_buf_len and tx_buf_len to
* have the same size. */

So, the current driver has dependency that rx_buf_len and tx_buf_len has to be same size.
Yes it's a regression in QMSI side: it does not support asymmetric buffer though zephyr's spi api (include/spi.h) does.

SPI API was designed to let the driver handling dummy bytes. You send 2 bytes, waiting to read 10 bytes in return would mean the driver would have to send 8 dummy bytes after the 2 first command bytes.
Dummy bytes are just zeros.

With QMSI, you cannot let the driver do that for you so you have to think about these "dummy bytes" yourself.


In our BLE module, we have a requirement that, When we pass 4 bytes of SPI write command, BLE module sends 8 bytes of data ..
Is that possible to handle the above situation using SPI_read and SPI _write calls in the present driver ??
You still have to use spi_transceive. Basically, it's up to your BLE module to handle the SPI dummy bytes.
So you have to provide symmetric rx/tx buffers. In your case you could do:

uint8_t buf[8] = {};

buf[0] = your_1st_byte;
buf[1] = your_2nd_byte;

spi_transceive(spi_dev, buf, 8, buf, 8);

SPI is serialized, always. So 1 byte sent will mean 1 byte read. That's why, in this example, I use the same buffer in rx/tx. (It will never ever happen that your receive more than what you wrote. Or then it's a serious bug in the spi driver.)

Hope it answers your question. Don't hesitate to ask if you have more unclear stuff.

Br,

Tomasz


Thanks


-----Original Message-----
From: Mahendravarman Rajarao (RBEI/EAA3)
Sent: Thursday, June 30, 2016 12:22 PM
To: 'Tomasz Bursztyka' <tomasz.bursztyka(a)linux.intel.com>
Subject: RE: [devel] Re: Re: Re: Re: Re: Need Callback Implementation
for QMSI SPI driver


Hi

Sorry typo error
We plan to use AON GPIO call back itself in case of any BLE Activity.



-----Original Message-----
From: Tomasz Bursztyka [mailto:tomasz.bursztyka(a)linux.intel.com]
Sent: Thursday, June 30, 2016 12:22 PM
To: devel(a)lists.zephyrproject.org
Subject: [devel] Re: Re: Re: Re: Re: Need Callback Implementation for
QMSI SPI driver

Hi,

Indeed, not using AON would have been surprising. :)

Tomasz

Hi

We are using MCU x86 Core
We have connected a GPIO line from BLE module to the MCU x86's AON GPIO.
Based on your discussion below I think we can use GPIO call back itself in case of any BLE Activity.

Thanks


-----Original Message-----
From: Tomasz Bursztyka [mailto:tomasz.bursztyka(a)linux.intel.com]
Sent: Tuesday, June 28, 2016 3:03 PM
To: devel(a)lists.zephyrproject.org
Subject: [devel] Re: Re: Re: Need Callback Implementation for QMSI
SPI driver

Hi,
We have connected MCU SPI to a BLE module.
BLE module will wakeup MCU from sleep state through SPI interrupt
During that time we need a callback implementation in SPI driver
Are you talking about the MCU's ARC core or x86 core?
This makes quite a difference.

I would be surprised you hook up the BLE only to SPI, don't you have
a GPIO line to tell about BLE activity? In case of ARC core, any GPIO
interrupt actually wakes up the core, if I am not mixing up. (input
ones are wake capable, on level trigger)

Is you BLE lined up as an SPI slave or as an master? (only x86 core's SPI supports being wired as a slave against an external master if I remember well).
BLE as a slave, it would not be able to generate any interrupt through SPI.
On x86, only AON GPIO can be used to wake up, from external activity.

Please detail. In both case, there is no need of ISR context SPI user callback.
But there are implementations implications though.

Tomasz


having trouble getting the echo client to work using TCP/uIP on K64F

Rohit Grover
 

Hello Community,

I've still not been able to get a TCP stream going over uIP using the echo-client sample.
I've unearthed problems along the way (including data-integrity issues in Zephyr's port of uIP; refer to https://gerrit.zephyrproject.org/r/#/c/4226/ ) which suggest that this kind of thing isn't actively tested. With my recent changes, I manage to get the first packet bounce back successfully to the echo-client. Successive packets aren't getting processed on their way out from the client.

I find that uip_process() isn't getting called on successive packets. It gets called for the first packet due to some retransmission timer. The recently made change to eventhandler() in tcpip.c (https://gerrit.zephyrproject.org/r/#/c/4050/) makes things worse because the code meant to refresh certain periodic timers gets skipped.

These issues seem to arise from uIP. I would appreciate some help from people who ported uIP to zephyr. I believe the problems will surface if someone tries a TCP/IPV4 stream.

rohit
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.


Re: _Swap crash in attempt to add support for STM32F3 board

Mirza Krak
 

2016-08-19 4:25 GMT+02:00 Ricardo Salveti <ricardo.salveti(a)linaro.org>:
On Thu, Aug 18, 2016 at 4:43 PM, Mirza Krak <mirza.krak(a)gmail.com> wrote:
Hi.

My first post on this list so would like to say that this project
seems very promising and is something that I have been waiting for.

I wanted to get involved so I dusted of a STM32F3 discovery board and
started coding. It helped a lot that there was STM32F1 support all
ready.
Not related to your issue, but we also got a work-in-progress port for
STM32F4 last week, in case that is useful for you. Currently working
at https://github.com/rsalveti/zephyr/commits/stm32-dev, and expecting
to start the clean-up and upstreaming over the next couple of weeks.

Clock, uart, gpio, all working and tested with STM32F4 Nucleo.
Thank you for sharing your port, it was really helpful and my work is
heavily based on that.

FYI I now also have a STM32F3 Discovery board working (only clock and
gpio so far). Will also implement GPIO IRQ support. But then I plan to
start cleaning up and attempt to mainline. Will do the uart part later
since it is significantly different compared to F1 and F4.

I am not sure about your timeline, but we could end up clashing with
our ports. So I am unsure how it is best to proceed forward in
attempting to mainline.

I will happily move forward in a join effort.

My port is available on https://github.com/mirzak/zephyr-os/tree/stm32f3

Best Regards,
Mirza Krak

6761 - 6780 of 8041