- Porting to Cortex-M0+
Re: Porting to Cortex-M0+
toggle quoted messageShow quoted text
From: Piotr Mienkowski [mailto:Piotr.Mienkowski(a)schmid-telecom.ch]
Sent: Thursday, August 25, 2016 4:22 AM
Subject: [devel] Re: Re: Re: Re: Porting to Cortex-M0+
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?
I agree it would make sense to add the device header files from Atmel to ext/hal. We already have the CMSIS Core header files from ARM in ext/hal/cmsis, which are being used by the NXP ksdk and Nordic mdk. As far as folder structure goes, I think anything under ext/hal/asf (or whatever we end up calling it) has some freedom to do what makes sense. For ext/hal/cmsis and ext/hal/ksdk, I tried to preserve the structure from the original source as much as possible. The folder structure under arch/arm/soc is intended to be more standardized, though you may have noticed that some SoCs have a family/series hierarchy (nxp_kinetis) and some don't (atmel_sam3). To add SAM E70, we'll need to first convert the existing atmel_sam3 to the family/series hierarchy. Something like this:
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.
I can't comment on the state of the Atmel drivers, but at least for NXP we do a lot of testing on the ksdk drivers and they are actively maintained. Intel is doing a similar thing with their qmsi drivers.
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.
IANAL either, but will check with someone at LF on this.
Join email@example.com to automatically receive all group messages.