This is the mail archive of the ecos-patches@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug 1001428] Hal bits for Kinetis K40 SLCD controller


Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001428

--- Comment #3 from Ilija Kocho <ilijak@siva.com.mk> 2011-12-21 17:54:52 GMT ---
(In reply to comment #2)
> (In reply to comment #1)
> Thanks Ilija,
> 
> > Regarding device drivers and HAL: In eCos terms, "HAL" refers to software
> > associated with CPU and hardware close to it. Therefore devices are not
> > considered part of HAL.
> 
> Sure, but I thought the patches I have submitted maintain that distinction. Are
> you saying the on-chip SLCD controller should be treated as a device rather
> than part of the MCU? (Which I can do, of course.)

Being on-chip doesn't change the relation, it's still a peripheral. The same
device may be present on MCUs with different CPU architecture (esp. at
Freescale). Also the division is reflected in eCos tree where we have hal and
devs subtrees.

> 
> > I am trying to make drivers as much as possible independent of Kinetis HAL and
> > one aspect is name space. Namely, for device naming I have used FREESCALE stem
> > rather than KINETIS, DEV or IO instead of HAL. Also instead of using
> > /devs/<xxx>/cortexm I have used/crated /devs/<xxx>/freescale directories.
> > I would invite you to keep this conventions with hope that in future someone
> > may (wish to) use the drivers on Coldfire+ or PX.
> 
> I did that for the MMA7660 patch (bug 1001419), for exactly the reasons you
> state; for the i2c driver I followed the conventions used by the driver I based
> it on.

It's true that under devs subtree you  can find "architectural" directories
such as arm and cortexm, etc. This is less problem for devices from
manufacturers that support single architecture but still may lead us to a
situation (there are examples) where some MCU has a choice between borrowing
devices from "other architecture" or cloning them. I am trying to avoid this
with Freescale for reasons stated earlier. I think it should not be difficult
for us as we are just at the beginning with Kinetis.

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]