[Bug 1001428] Hal bits for Kinetis K40 SLCD controller

[bugzilla-daemon@bugs.ecos.sourceware.org]

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

--- Comment #2 from Tomas Frydrych <tf+bugs.ecos@r-finger.com> 2011-12-21 12:05:36 GMT ---
(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.)

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

> Regarding register macros such as:
> #define CYG_HAL_KINETIS_LCD_GCR \
>   ((cyghwr_hal_kinetis_lcd_t*)CYG_HAL_KINETIS_LCD_B)->gcr
> 
> IMO such macros tend to produce sub-optimal code and I wouldn't accept them.
> Commonly, you need same pointer more than once within a function (to access
> same or different structure member(s)) and it is more effective to declare a
> pointer and (re)use it.

OK, I can remove these.

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