[Bug 1001428] New: Hal bits for Kinetis K40 SLCD controller

[Bug 1001428] New: Hal bits for Kinetis K40 SLCD controller

[bugzilla-daemon]

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

           Summary: Hal bits for Kinetis K40 SLCD controller
           Product: eCos
           Version: CVS
          Platform: All
        OS/Version: Cortex-M
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: low
         Component: Patches and contributions
        AssignedTo: unassigned@bugs.ecos.sourceware.org
        ReportedBy: tf+bugs.ecos@r-finger.com
                CC: ecos-patches@ecos.sourceware.org, ilijak@siva.com.mk
             Class: Advice Request


Created an attachment (id=1476)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1476)
Hal bits for K40 LCD controller

The attached patch adds register definitions and manipulation macros for the
SLCD controller on the K40 chips; I think the same controller is also on the
K30 and some of the K5? chips, but I have not verified this in detail, so the
definitions are only included for the K40 subfamily at the moment.

(As a side note, I am working on a driver the the LCD on the kwikstik board; I
will add that to bug 1001426 when it's ready.)

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

[Bug 1001428] Hal bits for Kinetis K40 SLCD controller

[bugzilla-daemon]

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

--- Comment #1 from Ilija Kocho <ilijak@siva.com.mk> 2011-12-21 11:03:02 GMT ---
Hi Tomas

(In reply to comment #0)
> Created an attachment (id=1476)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1476) [details]
> Hal bits for K40 LCD controller
> 
> The attached patch adds register definitions and manipulation macros for the
> SLCD controller on the K40 chips; I think the same controller is also on the
> K30 and some of the K5? chips, but I have not verified this in detail, so the
> definitions are only included for the K40 subfamily at the moment.
> 
> (As a side note, I am working on a driver the the LCD on the kwikstik board; I
> will add that to bug 1001426 when it's ready.)

Regarding your activity as a new (AFAIK) and productive eCos contributor
here are some general / introductory remarks (also applicable to Bug 1001397
which I hope to visit soon)  :

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. The idea is to re(use) drivers with different
architectures. In practice there are many exceptions but I would like to keep
at least Kinetis on this course. There are good reasons for this, one being the
fact that Freescale provides same or compatible peripherals on different
architectures.
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.


Regarding bits and shifts: Like it is in Bug 1001388, it would be good to use
BIT_() and VALUE_() macros for bits and shifts. Code looks cleaner and Cortex-M
eCos users are used to them. A minor (personal) note - I find "u" suffix on hex
constants unnecessary (though it might have been recommended by some coding
standards).


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.
Should you prefer to operate with register-like API, eCos has provision for
this by means of  HAL_WRITE_UINTxx() HAL_WRITE_READxx() macros - please look
ENET and UART drivers for sample usage. I would have to point that this API is
preferred choice by original eCos authors. In my eyes both ways are good, only
it would be bad idea to mix them on a same device.

Ilija

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

[Bug 1001428] Hal bits for Kinetis K40 SLCD controller

[bugzilla-daemon]

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.

[Bug 1001428] Hal bits for Kinetis K40 SLCD controller

[bugzilla-daemon]

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.

[Bug 1001428] Hal bits for Kinetis K40 SLCD controller

[bugzilla-daemon]

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

--- Comment #4 from Tomas Frydrych <tf+bugs.ecos@r-finger.com> 2011-12-21 18:33:30 GMT ---
(In reply to comment #3)
> 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.

OK. So in the case of the K40 SLCD controller, where would you suggest to place
this? Looking at the eth/uart drivers, perhaps along the lines of
/dev/slcd/freescale/<something>, but I am not sure what identifier to assign to
this actual device.

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

Makes sense.

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

[Bug 1001428] Hal bits for Kinetis K40 SLCD controller

[bugzilla-daemon]

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

--- Comment #5 from Ilija Kocho <ilijak@siva.com.mk> 2011-12-22 08:01:26 GMT ---
(In reply to comment #4)
> (In reply to comment #3)
> OK. So in the case of the K40 SLCD controller, where would you suggest to place
> this? Looking at the eth/uart drivers, perhaps along the lines of
> /dev/slcd/freescale/<something>, but I am not sure what identifier to assign to
> this actual device.
> 

Provided that it doesn't fit in any of existing directories, I would create
directory with general name such as lcd and for device name I would refer to
Freescale docs. That would probably give devs/lcd/freescale/slcd .

Note: I wonder if another tree level would be suitable/desirable such as:
devs/gui/lcd/... Would anybody comment pse?

Ilija

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

[Bug 1001428] Hal bits for Kinetis K40 SLCD controller

[bugzilla-daemon]

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

John Dallaway <john@dallaway.org.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |john@dallaway.org.uk

--- Comment #6 from John Dallaway <john@dallaway.org.uk> 2011-12-22 10:03:11 GMT ---
(In reply to comment #5)

> Provided that it doesn't fit in any of existing directories, I would create
> directory with general name such as lcd and for device name I would refer to
> Freescale docs. That would probably give devs/lcd/freescale/slcd .
> 
> Note: I wonder if another tree level would be suitable/desirable such as:
> devs/gui/lcd/... Would anybody comment pse?

Using an "lcd" hierarchy for LCD segment displays would imply a separate
hierarchy for LED segment displays with similar controllers. I think a more
generic name is desirable.

Historically, support for simple devices with no corresponding I/O
infrastructure package has tended to be bundled with the relevant HAL package.
However, I do appreciate the desire for portability across architectures.

A few possibilities for consideration:

1) Introduce a hal/devs/ hierarchy for HAL-level device definitions which may
be required across multiple architectures. Accessed directly as if part of a
platform HAL or variant HAL package.

2) Introduce a devs/misc/ hierarchy for miscellaneous simple eCos devices with
no corresponding I/O layer. Accessed via eCos device lookup.

3) Create an I/O infrastructure package for segment displays.

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

[Bug 1001428] Hal bits for Kinetis K40 SLCD controller

[bugzilla-daemon]

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

--- Comment #7 from Ilija Kocho <ilijak@siva.com.mk> 2011-12-23 08:07:51 GMT ---
Hi John
Thank you for your comments

(In reply to comment #6)
> (In reply to comment #5)
> 
> > Provided that it doesn't fit in any of existing directories, I would create
> > directory with general name such as lcd and for device name I would refer to
> > Freescale docs. That would probably give devs/lcd/freescale/slcd .
> > 
> > Note: I wonder if another tree level would be suitable/desirable such as:
> > devs/gui/lcd/... Would anybody comment pse?
> 
> Using an "lcd" hierarchy for LCD segment displays would imply a separate
> hierarchy for LED segment displays with similar controllers. I think a more
> generic name is desirable.
> 
> Historically, support for simple devices with no corresponding I/O
> infrastructure package has tended to be bundled with the relevant HAL package.
> However, I do appreciate the desire for portability across architectures.
> 
> A few possibilities for consideration:
> 
> 1) Introduce a hal/devs/ hierarchy for HAL-level device definitions which may
> be required across multiple architectures. Accessed directly as if part of a
> platform HAL or variant HAL package.

I would avoid putting directory named "devs" under "hal" since it may have
strong gravitational pull for any kind of device drivers (esp from new
developers).

But there are some devices that are close to the HAL but can be still shared
among different architectures such as: DMA, some RAM chips with configurability
features, etc. For this purpose I would propose hal/misc
This may be off-topic, but for me this is kind of actual question and I was
going to put it on devel list as I am near to submit a driver that employs DMA
and HAL support for external RAM chip(s) that have some registers for
configuration.

> 
> 2) Introduce a devs/misc/ hierarchy for miscellaneous simple eCos devices with
> no corresponding I/O layer. Accessed via eCos device lookup.
> 
> 3) Create an I/O infrastructure package for segment displays.

I would vote for this with little further generalization: may it be
devs/displays (eventually abbreviated)? Or could it be: /devs/hmi?
Note: This may raise question what to do with (existing) framebuffer, but I
think at present it shouldn't be a big issue to move it in because there's only
one entry within framebuffer.

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

[Bug 1001428] Hal bits for Kinetis K40 SLCD controller

[bugzilla-daemon]

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

--- Comment #8 from John Dallaway <john@dallaway.org.uk> 2011-12-23 08:30:57 GMT ---
(In reply to comment #7)

> > A few possibilities for consideration:
> > 
> > 1) Introduce a hal/devs/ hierarchy for HAL-level device definitions which
> > may be required across multiple architectures. Accessed directly as if part
> > of a platform HAL or variant HAL package.
> 
> I would avoid putting directory named "devs" under "hal" since it may have
> strong gravitational pull for any kind of device drivers (esp from new
> developers).

Yes. Perhaps hal/shared/ or hal/misc/ would be better.

> But there are some devices that are close to the HAL but can be still shared
> among different architectures such as: DMA, some RAM chips with
> configurability features, etc. For this purpose I would propose hal/misc
> This may be off-topic, but for me this is kind of actual question and I was
> going to put it on devel list as I am near to submit a driver that employs
> DMA and HAL support for external RAM chip(s) that have some registers for
> configuration.
> 
> > 2) Introduce a devs/misc/ hierarchy for miscellaneous simple eCos devices
> > with no corresponding I/O layer. Accessed via eCos device lookup.
> > 
> > 3) Create an I/O infrastructure package for segment displays.
> 
> I would vote for this with little further generalization: may it be
> devs/displays (eventually abbreviated)? Or could it be: /devs/hmi?
> Note: This may raise question what to do with (existing) framebuffer, but I
> think at present it shouldn't be a big issue to move it in because there's
> only one entry within framebuffer.

In general, device drivers under devs/$TYPE/ are accessed via the I/O layer at
io/$TYPE/ and I see no reason to change this. For example devs/framebuf/ is
accessed via the Framebuffer I/O  layer at io/framebuf/.

Also, in general, drivers under devs/ present themselves via the eCos device
driver API.

If the Freescale SLCD package will simply provide some HAL definitions and
HAL-level API then perhaps hal/misc/freescale/slcd/ is indeed the better place.

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

[Bug 1001428] Hal bits for Kinetis K40 SLCD controller

[bugzilla-daemon]

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

--- Comment #9 from Ilija Kocho <ilijak@siva.com.mk> 2011-12-23 09:23:33 GMT ---
(In reply to comment #8)
> (In reply to comment #7)
> 
> > > A few possibilities for consideration:
> > > 
> > > 1) Introduce a hal/devs/ hierarchy for HAL-level device definitions which
> > > may be required across multiple architectures. Accessed directly as if part
> > > of a platform HAL or variant HAL package.
> > 
> > I would avoid putting directory named "devs" under "hal" since it may have
> > strong gravitational pull for any kind of device drivers (esp from new
> > developers).
> 
> Yes. Perhaps hal/shared/ or hal/misc/ would be better.

Both sound good to me with slight preference to hal/misc.

> 
> > But there are some devices that are close to the HAL but can be still shared
> > among different architectures such as: DMA, some RAM chips with
> > configurability features, etc. For this purpose I would propose hal/misc
> > This may be off-topic, but for me this is kind of actual question and I was
> > going to put it on devel list as I am near to submit a driver that employs
> > DMA and HAL support for external RAM chip(s) that have some registers for
> > configuration.
> > 
> > > 2) Introduce a devs/misc/ hierarchy for miscellaneous simple eCos devices
> > > with no corresponding I/O layer. Accessed via eCos device lookup.
> > > 
> > > 3) Create an I/O infrastructure package for segment displays.
> > 
> > I would vote for this with little further generalization: may it be
> > devs/displays (eventually abbreviated)? Or could it be: /devs/hmi?
> > Note: This may raise question what to do with (existing) framebuffer, but I
> > think at present it shouldn't be a big issue to move it in because there's
> > only one entry within framebuffer.
> 
> In general, device drivers under devs/$TYPE/ are accessed via the I/O layer at
> io/$TYPE/ and I see no reason to change this. For example devs/framebuf/ is
> accessed via the Framebuffer I/O  layer at io/framebuf/.
> 
> Also, in general, drivers under devs/ present themselves via the eCos device
> driver API.
> 
> If the Freescale SLCD package will simply provide some HAL definitions and
> HAL-level API then perhaps hal/misc/freescale/slcd/ is indeed the better place.

OK. Thank you for clarification.

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

[Bug 1001428] Hal bits for Kinetis K40 SLCD controller

[bugzilla-daemon]

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

--- Comment #10 from Tomas Frydrych <tf+bugs.ecos@r-finger.com> 2011-12-23 10:18:58 GMT ---
Thank you both; I shall update the patch so it lives under
hal/misc/freescale/slcd.

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

[Bug 1001428] Hal bits for Kinetis K40 SLCD controller

[bugzilla-daemon]

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

Tomas Frydrych <tf+bugs.ecos@r-finger.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #1476|0                           |1
        is obsolete|                            |

--- Comment #11 from Tomas Frydrych <tf+bugs.ecos@r-finger.com> 2012-01-11 11:24:55 GMT ---
Created an attachment (id=1511)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1511)
Freescale SLCD HAL package

This patch adds a package that provide a header with memory map for the
Freescale SLCD controller.

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

[Bug 1001428] Hal bits for Kinetis K40 SLCD controller

[bugzilla-daemon]

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

--- Comment #12 from Tomas Frydrych <tf+bugs.ecos@r-finger.com> 2012-01-11 11:28:03 GMT ---
Created an attachment (id=1512)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1512)
Kinetis-specific bits for Freescale SLCD controller

This patch provides a definition of the SLCD controller base pointer and allows
for the _SCGC*_ALL_M masks to be overridden from platform definitions.

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

[Bug 1001428] Hal bits for Kinetis K40 SLCD controller

[bugzilla-daemon]

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

Tomas Frydrych <tf+bugs.ecos@r-finger.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Blocks|                            |1001426

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

[Bug 1001428] Hal bits for Kinetis K40 SLCD controller

[bugzilla-daemon]

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

Tomas Frydrych <tf+bugs.ecos@r-finger.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #1511|0                           |1
        is obsolete|                            |

--- Comment #13 from Tomas Frydrych <tf+bugs.ecos@r-finger.com> 2012-01-11 11:43:27 GMT ---
Created an attachment (id=1513)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1513)
Freescale SLCD HAL package

Sorry, the previous patch was made against wrong local branch.

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

[Bug 1001428] Hal bits for Kinetis K40 SLCD controller

[bugzilla-daemon]

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

Tomas Frydrych <tf+bugs.ecos@r-finger.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #1513|0                           |1
        is obsolete|                            |

--- Comment #14 from Tomas Frydrych <tf+bugs.ecos@r-finger.com> 2012-01-11 11:43:59 GMT ---
Created an attachment (id=1514)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1514)
Kinetis-specific bits for Freescale SLCD controller

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

[Bug 1001428] Hal bits for Kinetis K40 SLCD controller

[bugzilla-daemon]

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

Tomas Frydrych <tf+bugs.ecos@r-finger.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #1512|0                           |1
        is obsolete|                            |

--- Comment #15 from Tomas Frydrych <tf+bugs.ecos@r-finger.com> 2012-01-11 11:44:47 GMT ---
Created an attachment (id=1515)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1515)
Freescale SLCD HAL package

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

[Bug 1001428] Hal bits for Kinetis K40 SLCD controller

[bugzilla-daemon]

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

John Dallaway <john@dallaway.org.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Platform|All                         |Other (please specify)

--- Comment #16 from John Dallaway <john@dallaway.org.uk> 2012-03-26 17:09:41 BST ---
(In reply to comment #0)

> (As a side note, I am working on a driver the the LCD on the kwikstik board; I
> will add that to bug 1001426 when it's ready.)

Tomas, do you have any sort of schedule for the LCD driver? I'm wondering
whether it makes sense to check the HAL definitions and driver code in
together.

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

[Bug 1001428] Hal bits for Kinetis K40 SLCD controller

[bugzilla-daemon]

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

--- Comment #17 from Tomas Frydrych <tf+bugs.ecos@r-finger.com> 2012-03-26 17:22:13 BST ---
(In reply to comment #16)
> (In reply to comment #0)
> 
> > (As a side note, I am working on a driver the the LCD on the kwikstik board; I
> > will add that to bug 1001426 when it's ready.)
> 
> Tomas, do you have any sort of schedule for the LCD driver? I'm wondering
> whether it makes sense to check the HAL definitions and driver code in
> together.

I got a prototype that can output text and scroll, but it's not ready for
inclusion -- I was thinking of pushing what I have to github to make the WIP
available. (I should have bit more time for ecos come April.)

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

[Bug 1001428] Hal bits for Kinetis K40 SLCD controller

[bugzilla-daemon]

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

John Dallaway <john@dallaway.org.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Blocks|1001426                     |

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