Hi,

I have the same problem. I would like to add support for Atmel SAM E70 chip (Cortex-M7) and was thinking that using the header files provided by Atmel as part of their ASF would make the job much, much easier.

Euan, did you already add files to ext/hal/ folder? Have you talked to Maureen Helm, the ARM architecture maintainer? Should we agree on folder structure so support for future Atmel chips can be easily added?

My thoughts:
I think we should only add header files that define register access and do not add any device drivers. While header files are valuable the Atmel implementation of device drivers looks low quality, at least the SAM E70 package. The way API is written is not directly useful for any serious development, neither it follows CMSIS standard. While some drivers look good, some are incomplete and some are buggy. We would need to fix them and cooperate with Atmel to push changes upstream. I reckon using third party source code which is not maintained in open source model is not a viable long term solution. Not mentioning the fact that device drivers will have to be tightly integrated with Zephyr kernel. I believe it's easier to write our own drivers from scratch. Anyway, that's only my opinion.

The text of SAM Software Package License included in the source code (and header files) looks actually very permissive but IANAL, also the ext/hal/ folder has already a selection of proprietary code with similar licenses. In any case we should probably get an official green light from someone.

Cheers,
Piotr

I just pushed the following to gerrit, for possible merge sometime in
the 1.6 timeframe. It will modify outdir to contain separate
subdirectories for each BOARD variant built, so they won't collide in
undetectable ways at build time when you swap targets or forget the
make variable:

https://gerrit.zephyrproject.org/r/#/c/4310/

It also will change the location of the output files for anyone
building without a custom O= variable, which will impact scripting.
(Though to be fair: if you're automating builds you probably want
to be setting O manually!)

Please be aware, and review the change if interested.

Andy

NEW JIRA items within last 24 hours: 3
[ZEP-734] Port AES-CMAC-PRF-128 [RFC 4615] encryption library for Thread support
https://jira.zephyrproject.org/browse/ZEP-734

[ZEP-733] Minimal libc shouldn't be providing stddef.h
https://jira.zephyrproject.org/browse/ZEP-733

[ZEP-735] Several Tests and Samples are broken for CONFIG_DEBUG
https://jira.zephyrproject.org/browse/ZEP-735


UPDATED JIRA items within last 24 hours: 5
[ZEP-648] New CoAP Implementation
https://jira.zephyrproject.org/browse/ZEP-648

[ZEP-711] I2c: fails to write with mode fast plus
https://jira.zephyrproject.org/browse/ZEP-711

[ZEP-199] Zephyr driver model is undocumented
https://jira.zephyrproject.org/browse/ZEP-199

[ZEP-642] Inconsistent interpretation of pwm_pin_set_values arguments among drivers
https://jira.zephyrproject.org/browse/ZEP-642

[ZEP-725] CI tag build is not sending emails
https://jira.zephyrproject.org/browse/ZEP-725


CLOSED JIRA items within last 24 hours: 22
[ZEP-210] (Duplicate) Zephyr TEE compatibility
https://jira.zephyrproject.org/browse/ZEP-210

[ZEP-327] (Fixed) Port available encryption libraries needed for Thread support
https://jira.zephyrproject.org/browse/ZEP-327

[ZEP-49] (Fixed) x86: unify separate SysV and IAMCU code
https://jira.zephyrproject.org/browse/ZEP-49

[ZEP-55] (Fixed) enable nanokernel test_context on ARC
https://jira.zephyrproject.org/browse/ZEP-55

[ZEP-350] (Fixed) Driver for HTS221 relative humidity and temperature sensor
https://jira.zephyrproject.org/browse/ZEP-350

[ZEP-348] (Fixed) Driver for LIS3MDL magnetometer
https://jira.zephyrproject.org/browse/ZEP-348

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

[ZEP-632] (Fixed) MQTT fail to re-connect to the broker.
https://jira.zephyrproject.org/browse/ZEP-632

[ZEP-669] (Fixed) MQTT fail to pingreq if broker deliver topic to client but client doesn't read it.
https://jira.zephyrproject.org/browse/ZEP-669

[ZEP-612] (Won't Do) Need to send a dummy packet to establish connection using the TCP/IP stack
https://jira.zephyrproject.org/browse/ZEP-612

[ZEP-704] (Fixed) test_atomic does not complete on ARC
https://jira.zephyrproject.org/browse/ZEP-704

[ZEP-703] (Fixed) USB sample apps are broken after QMSI update
https://jira.zephyrproject.org/browse/ZEP-703

[ZEP-693] (Fixed) tests/kernel/test_lifo: execution fails on ARC
https://jira.zephyrproject.org/browse/ZEP-693

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

[ZEP-369] (Fixed) When building out of the tree, application object files are not placed into outdir
https://jira.zephyrproject.org/browse/ZEP-369

[ZEP-455] (Won't Do) Sensor DHT11/DHT22 Fails to perform repetitive sampling with Zephyr
https://jira.zephyrproject.org/browse/ZEP-455

[ZEP-534] (Fixed) Scan for consistent use of "platform/board/SoC" in documentation
https://jira.zephyrproject.org/browse/ZEP-534

[ZEP-187] (Fixed) BLE APIs are not documented
https://jira.zephyrproject.org/browse/ZEP-187

[ZEP-695] (Fixed) FatFs doesn't compile using Newlib
https://jira.zephyrproject.org/browse/ZEP-695

[ZEP-188] (Duplicate) IPStack/6LoWPAN/15.4 APIs are not documented
https://jira.zephyrproject.org/browse/ZEP-188

[ZEP-598] (Fixed) CoAP Link format filtering is not supported
https://jira.zephyrproject.org/browse/ZEP-598

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


RESOLVED JIRA items within last 24 hours: 2
[ZEP-697] (Fixed) samples/net/test_15_4 cannot be built by sanitycheck
https://jira.zephyrproject.org/browse/ZEP-697

[ZEP-384] (Fixed) D2000 hangs after I2C communication with BMC150 sensor
https://jira.zephyrproject.org/browse/ZEP-384

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/4308 : win-build: Explicity call phyton
- https://gerrit.zephyrproject.org/r/4307 : win-build: Fixes Makefile target names including char ":"
- https://gerrit.zephyrproject.org/r/4306 : win-build: Fixes an issue supporting quotes
- https://gerrit.zephyrproject.org/r/4305 : net: drivers: ieee802154: sys_log is needed on legacy driver
- https://gerrit.zephyrproject.org/r/4304 : net: Legacy IP stack Kconfig has nothing to do with new stack
- https://gerrit.zephyrproject.org/r/4294 : net: drivers: Normalize ieee802154 Kconfig
- https://gerrit.zephyrproject.org/r/4293 : net: drivers: cc2520 ieee802154 drivers select relevant options
- https://gerrit.zephyrproject.org/r/4292 : net: Split debug Kconfig options from legacy to new stack
- https://gerrit.zephyrproject.org/r/4291 : net: yaip: Normalize Kconfig and fix it
- https://gerrit.zephyrproject.org/r/4290 : net: yaip: Move IPv4 related Kconfig options to its own file
- https://gerrit.zephyrproject.org/r/4289 : net: yaip: Move IPv6 related Kconfig options to its own file
- https://gerrit.zephyrproject.org/r/4302 : net: samples: Fix the echo-server IPv4 address
- https://gerrit.zephyrproject.org/r/4301 : net: Do not try to use net_if.h in legacy uIP stack
- https://gerrit.zephyrproject.org/r/4303 : loop-slip4.sh: Wrapper script to run tunslip for IPv4 connection to QEMU
- https://gerrit.zephyrproject.org/r/4297 : Bluetooth: Set simultaneous LE and BR/EDR to same device capable
- https://gerrit.zephyrproject.org/r/4298 : Bluetooth: Refactor Link Key notification event handling
- https://gerrit.zephyrproject.org/r/4300 : Bluetooth: Enable Secure Connections if supported
- https://gerrit.zephyrproject.org/r/4295 : Bluetooth: Enable and disable BLE chip sleep mode dynamically
- https://gerrit.zephyrproject.org/r/4299 : Bluetooth: Add support for P256 Link Keys
- https://gerrit.zephyrproject.org/r/4282 : net: fetch valid conn. to determine MSS in data_is_sent_and_acked()
- https://gerrit.zephyrproject.org/r/4260 : Bluetooth: tests: Add BLE controller init tests
- https://gerrit.zephyrproject.org/r/4257 : lib: Use offsetof() builtin with GCC
- https://gerrit.zephyrproject.org/r/4277 : drivers: pwm_shim: correct api argument inconsistency
- https://gerrit.zephyrproject.org/r/4256 : toolchain: Remove vestigial COFF assembler symbol mangling support

UPDATED within last 24 hours:
- 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/4251 : net: yaip: ieee802154: Normalize Kconfig
- https://gerrit.zephyrproject.org/r/4252 : net: yaip: Centralize generic IEEE 802.15.4 radio utility functions
- https://gerrit.zephyrproject.org/r/4253 : net: yaip: ieee802154: Add CSMA-CA non slotted radio protocol support
- 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/4165 : net: drivers: Add a fake ieee802154 radio driver for qemu
- https://gerrit.zephyrproject.org/r/4164 : net: ieee802154: Add basic support for IEEE 802.15.4e on FCF
- https://gerrit.zephyrproject.org/r/4081 : power_mgmt: Updated Power Management device driver API
- 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/4231 : net/yaip: Use the dummy L2 frame format for Qemu
- https://gerrit.zephyrproject.org/r/3997 : Bluetooth: L2CAP: Implement connect command on BR/EDR
- https://gerrit.zephyrproject.org/r/4225 : net: raising MAX_TCP_RETRY_COUNT to account for slower response
- https://gerrit.zephyrproject.org/r/4226 : net: Do not fill in TCP option bytes for all packets
- https://gerrit.zephyrproject.org/r/4248 : net: Fix net_send return value documentation
- https://gerrit.zephyrproject.org/r/4090 : Bluetooth: Controller: Add BLE controller driver
- https://gerrit.zephyrproject.org/r/4091 : board: nrf52_pca10040: Include BLE controller by default
- https://gerrit.zephyrproject.org/r/4089 : Bluetooth: Controller: A full, hardware-agnostic BLE Link Layer
- https://gerrit.zephyrproject.org/r/4245 : Bluetooth: L2CAP: Disable fragmentation of rx pdu
- https://gerrit.zephyrproject.org/r/4086 : Bluetooth: Controller: Hardware abstraction layer for nRF5x radio
- 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/4227 : MAINTAINERS: Add BLUETOOTH CONTROLLER section
- https://gerrit.zephyrproject.org/r/4105 : sanity: enable sanity multiple configuration
- https://gerrit.zephyrproject.org/r/3439 : spi_qmsi: Add suspend/resume
- https://gerrit.zephyrproject.org/r/4197 : Bluetooth: AVDTP: Module intialization

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/4296 : Bluetooth: Fix typo in code comment
- https://gerrit.zephyrproject.org/r/4287 : net: yaip: Fix documentation errors in net_if header file
- https://gerrit.zephyrproject.org/r/4275 : Revert "sys_log: replace old debug macros at DMA sample"
- https://gerrit.zephyrproject.org/r/4263 : Revert "misc: Remove generic PRINT macros from net samples"
- https://gerrit.zephyrproject.org/r/4276 : Revert "sys_log: replace old debug macros at USB DFU sample"
- https://gerrit.zephyrproject.org/r/4271 : Revert "misc: Remove generic PRINT macros from pci samples"
- https://gerrit.zephyrproject.org/r/4264 : Revert "misc: Remove generic PRINT macros from sensor samples"
- https://gerrit.zephyrproject.org/r/4288 : net: Add more items to TODO
- https://gerrit.zephyrproject.org/r/4268 : Revert "misc: Remove generic PRINT macros from power samples"
- https://gerrit.zephyrproject.org/r/4273 : Revert "misc: Remove generic PRINT macros from button samples"
- https://gerrit.zephyrproject.org/r/4269 : Revert "misc: Remove generic PRINT macros from spi samples"
- https://gerrit.zephyrproject.org/r/4270 : Revert "misc: Remove generic PRINT macros from flash samples"
- https://gerrit.zephyrproject.org/r/4266 : Revert "misc: Remove generic PRINT macros from synch samples"
- https://gerrit.zephyrproject.org/r/4267 : Revert "misc: Remove generic PRINT macros from hello world samples"
- https://gerrit.zephyrproject.org/r/4265 : Revert "misc: Remove generic PRINT macros from usb samples"
- https://gerrit.zephyrproject.org/r/4274 : Revert "sys_log: replace old debug macro on ADC driver sample."
- https://gerrit.zephyrproject.org/r/4272 : Revert "misc: Remove generic PRINT macros from aio samples"
- https://gerrit.zephyrproject.org/r/4284 : net: Add TODO items for 6LoWPAN
- https://gerrit.zephyrproject.org/r/4281 : net: tests: Extented 6lo unit tests
- https://gerrit.zephyrproject.org/r/4285 : Merge remote-tracking branch 'origin/master' into net
- https://gerrit.zephyrproject.org/r/4262 : Merge master branch into bluetooth
- https://gerrit.zephyrproject.org/r/4202 : net: ip: Fix compiling with 15.4
- https://gerrit.zephyrproject.org/r/4214 : doc: Add more content for networking documentation
- https://gerrit.zephyrproject.org/r/4162 : sanitycheck: Add support for section net_l2_data
- https://gerrit.zephyrproject.org/r/4250 : Bluetooth: RFCOMM: Fix cr bit of address in MSC response
- https://gerrit.zephyrproject.org/r/4200 : net: samples: Fix slip config for echo-server and echo-client

Hello Community,

In my attempts to get a TCP stream to flow in and out of a K64F, I've had to make a few changes to core of the uIP port: https://gerrit.zephyrproject.org/r/#/q/rohit+grover+status:open.
I now have some success in getting data to flow continuously, nevertheless I haven't fixed all issues and I'm not sure my changes take all possible cases into account.
These changes have had to do with errors in how uIP handles outbound packets.
I'm not an expert in IP stacks, and in one particular case, https://gerrit.zephyrproject.org/r/#/c/4225/, I've not been able to provide a fix--my patch simply raises a certain retry-limit and results in the expected behaviour.

I would appreciate assistance from people who may have authored the port of uIP to Zephyr. It seems to me that these issues should have surfaced for any application attempting to setup a TCP/IPv4 stream over uIP; it is a surprise that these have gone undetected so far.

Rohit.

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

Hi Andrew,

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,

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

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

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

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

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

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

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

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?

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

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.

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

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