search

zephyrproject-rtos / zephyr

Primary Git Repository for the Zephyr Project. Zephyr is a new generation, scalable, optimized, secure RTOS for multiple hardware architectures.
https://docs.zephyrproject.org
Apache License 2.0
10.51k stars 6.44k forks source link

Add preliminary support for Atmel SAM E70 (Cortex-M7) chipset family and SAM E70 Xplained board #2272

Closed zephyrbot closed 7 years ago

zephyrbot commented 8 years ago

Reported by Piotr Mienkowski:

Add preliminary support for [Atmel SAM E70 | http://www.atmel.com/products/microcontrollers/arm/sam-e.aspx] (Cortex-M7) chipset family and SAM E70 Xplained board.

At minimum following items should be added:

(Imported from Jira ZEP-759)

zephyrbot commented 7 years ago

by Mark Linkmeyer:

Piotr Mienkowski , is this on track to be implemented and merged before the 1.6 merge window closes on Nov 9th?

zephyrbot commented 7 years ago

by Piotr Mienkowski:

The implementation is dependent on the header files from Atmel. We are waiting for Atmel to provide header files with Zephyr compatible license, alternatively we would need to decide if the current license is acceptable.

There are also a few open points related to my commits: https://gerrit.zephyrproject.org/r/5026 https://gerrit.zephyrproject.org/r/5027

I'm ready to provide updated commits as soon as the license issue is solved / I get the feedback on the open points.

zephyrbot commented 7 years ago

by Piotr Mienkowski:

Zephyr's devel list discussion related to this issue: https://lists.zephyrproject.org/archives/list/devel@lists.zephyrproject.org/thread/2VG27JUW5MBIWFCJZ2H4WJ5A56C7VBKM/

zephyrbot commented 7 years ago

by Mark Linkmeyer:

Niheer Patel , I see in the discussion thread which Piotr references above that you are helping with the Atmel license issue. What's the latest status? What do we need to do get this story progressing so it gets done in time for the 1.6 release? Thx.

zephyrbot commented 7 years ago

by Mark Linkmeyer:

Per email from Niheer, Kumar Gala and Matt Locke have agreed to cover the licensing issue for Niheer. Currently, we're waiting to hear back from Henrik at Atmel.

zephyrbot commented 7 years ago

by Mark Linkmeyer:

Kumar Gala , based on the current status of this one (we're still waiting to hear from Henrik at Atmel and the merge window for 1.6 is closing tomorrow), it seems this story ought to be pushed out to 1.7 instead of leaving it in the list for 1.6. You agree?

zephyrbot commented 7 years ago

by Piotr Mienkowski:

Hi Mark Linkmeyer , You've changed recently the "Fix Version/s" field to None. Do you have any feedback from Atmel. Are they not going to provide us with a Zephyr compatible license for the register access header files? I was hoping we will get them before merge window for 1.7 is closed.

zephyrbot commented 7 years ago

by Kumar Gala:

Atmel, is we just dont know when they will make it in a releasable means. So we are saying that we just dont know what release this will get into at this point.

zephyrbot commented 7 years ago

by Piotr Mienkowski:

Thanks Kumar Gala for the feedback. However, that starts looking pretty bad. It has been several months already since Atmel was asked to provide header files compatible with Zephyr's license. How do you estimate chances that we will get them for 1.7 release? Is there anything that can be done to convince Atmel to work faster?

zephyrbot commented 7 years ago

by Thibaut VIARD:

Hi Piotr Mienkowski , it is highly understandable you didn't receive any feedback from Atmel but your request has been approved and new headers published under Apache 2.0 license since some months now : http://packs.download.atmel.com/#collapse-Atmel-SAME70-DFP-pdsc

The C headers format may have changed a bit since last time you extracted them.

I did know about your request from mynewt team, which I was supporting on the same matter, and expected Zephyr team to obtain feedbacks from Sterling as I didn't have any contact in Zephyr. Sorry for inconvenience.

Thibaut

zephyrbot commented 7 years ago

by Piotr Mienkowski:

Hi Thibaut VIARD , that's very good news! Thanks a lot!

zephyrbot commented 7 years ago

by Thibaut VIARD:

You are welcome! By the way, to oversee the global picture around Cortex-M devices, if the meaning is to obtain Apache 2 compatible device headers for every product you want to support, I would suggest to investigate into CMSIS SVDConv tool which can generate headers from SVD files. Following some study I did, a good solution can be obtained either by using 'macro' output mode or by mixing both 'struct' and 'macro' output modes (by hand). SVD files are usually easy to find here and there.

At least, you won't have to chase every silicon vendor in order to publish and use consistent product definitions following your own format. ;-)

my 2 cents...

zephyrbot commented 7 years ago

by Piotr Mienkowski:

Hi Thibaut VIARD , thanks for the advice. I probably won't need to generate header files but others may do.

I've finally tried to replace header files we are currently using with the new ones. They look very good but there are some minor inconsistencies and a few things are missing, e.g. the definitions for TC Channel Mode Register: Waveform Mode and also alternate pin functions like former PIO_PB13X1_DAC0.

I assume the packs are supported by Atmel like any other software library, should I open a ticket at Atmel support?

zephyrbot commented 7 years ago

by Thibaut VIARD:

Piotr Mienkowski , these issues are known and currently in progress. If you need the missing definitions urgently, I may suggest you to update by hand the 18 impacted banked registers (USART SPI/LIN/LON modes and TC Mode Register).

You did a good catch regarding the missing PIO_PB13X1_DAC0: I didn't notice it yet among others. I'm waiting for feedback on this point.

zephyrbot commented 7 years ago

by Piotr Mienkowski:

Thanks Thibaut VIARD for a hint. I've already created a patch that adds the missing symbols which I'm using in my code.

There are a few more minor inconsistencies in header files. Maybe I can report it here?

Thanks for your help!

zephyrbot commented 7 years ago

by Thibaut VIARD:

Hi Piotr Mienkowski ,

These issues are known and in progress too. Unfortunately, this won't be solved soon, AFAIK. I don't see either a fix for newline harmonization coming.

For my own open source projects, I maintain my own header files in an harmonized environment, cf https://github.com/aethaniel/ExperimentalCore-sam or https://github.com/arduino/ArduinoModule-CMSIS-Atmel.

zephyrbot commented 7 years ago

by Piotr Mienkowski:

Hi Thibaut VIARD , there is one more issue with the new header files we've just found. Chip header files like same70q21.h define _U, _L, _UL macros in the following manner {code}

if !defined(_UL)

define _U(x) x ## U

define _L(x) x ## L

define _UL(x) x ## UL

endif / !defined(UL) /

{code} However, some toolchains define _U but not _UL. That leads to a double definition of _U, _L macros. It looks like these macros are not used by the header files themselves so maybe it would be best to remove them?

There are two more macros which are defined but unused: CAST, REG_ACCESS. Some projects may define them differently. That could also cause some problems.

zephyrbot commented 7 years ago

by Thibaut VIARD:

Interesting feedbacks, do you have precise examples of those toolchains so that I can reproduce the potential issue here, please?

These macros are now used by some headers (internally at the moment), but you can delete these lines without problem, AFAIK.

zephyrbot commented 7 years ago

by Piotr Mienkowski:

We've noticed the problem in Zephyr when trying to compile with newlib. The standard minimal lib must have been defining _UL symbol. The issue can be observed with the standard GCC ARM Embedded toolchain. The conflicting definitions are located in ctype.h. They usage is quite different than in Atmel header files.