* [ECOS] Fwd: New features required on Cortex-M platform @ 2014-06-13 15:15 Jerzy Dyrda 2014-06-13 15:33 ` AW: " Richard Rauch 2014-06-16 2:08 ` [ECOS] RE: New features required on Cortex-M platform Andrew Hannam 0 siblings, 2 replies; 11+ messages in thread From: Jerzy Dyrda @ 2014-06-13 15:15 UTC (permalink / raw) To: eCos Discussion Hello all, During developing some application on Cortex-M controller I realized that is missing some vital components in current version of eCos system (from my point of view) i.e : 1) HTTP server - AHTTPD doesn't support lwIP stack what causes that it's useless. I'm planing to modify it thus any kind of advises are welcome. 2) Small embedded GUI working directly on display. From my side I propose uGFX -> http://ugfx.org/ License seems to be compatible and due its nature porting on new platform shouldn't be complicated even for me :) I'm also planning to add support and again any kind of comments advices or warnings are expecting. 3) SD bus support. I know that I can use SD card in SPI mode but on some board like STM32F4DISCOVERY SD card i only available on SD bus. It's high time to add this miss part of system. Best regards, jerzy -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 11+ messages in thread
* AW: [ECOS] Fwd: New features required on Cortex-M platform 2014-06-13 15:15 [ECOS] Fwd: New features required on Cortex-M platform Jerzy Dyrda @ 2014-06-13 15:33 ` Richard Rauch 2014-06-13 15:53 ` Jerzy Dyrda 2014-06-16 2:08 ` [ECOS] RE: New features required on Cortex-M platform Andrew Hannam 1 sibling, 1 reply; 11+ messages in thread From: Richard Rauch @ 2014-06-13 15:33 UTC (permalink / raw) To: 'Jerzy Dyrda', 'eCos Discussion' > Von: ecos-discuss-owner@ecos.sourceware.org [mailto:ecos-discuss- > owner@ecos.sourceware.org] Im Auftrag von Jerzy Dyrda > Gesendet: Freitag, 13. Juni 2014 17:15 > An: eCos Discussion > Betreff: [ECOS] Fwd: New features required on Cortex-M platform > > Hello all, > > During developing some application on Cortex-M controller I realized that is > missing some vital components in current version of eCos system (from my > point of view) i.e : > > 1) HTTP server - AHTTPD doesn't support lwIP stack what causes that it's > useless. > I'm planing to modify it thus any kind of advises are welcome. > > 2) Small embedded GUI working directly on display. From my side I propose > uGFX -> http://ugfx.org/ License seems to be compatible and due its nature > porting on new platform shouldn't be complicated even for me :) I'm also > planning to add support and again any kind of comments advices or warnings > are expecting. > > 3) SD bus support. I know that I can use SD card in SPI mode but on some board > like STM32F4DISCOVERY SD card i only available on SD bus. > It's high time to add this miss part of system. > > Best regards, > jerzy > A few comments and questions from my side: - what is the advantage of uGFX? Are there applications available, which are based on uGFX? What do you think about support for QT ( http://qt-project.org/ )? - SD card interface. Unfortunately this is very processor specific. Each Microcontroller has its own IP for accessing SD card. We have made it e.g. for Xilinx Zynq (http://tiprom.itrgmbh.com/projects/ecos-on-zynq/wiki/ECosOnZynq-Wiki ), but I assume it is not re-usable for other platforms! Best Regards Richard -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: AW: [ECOS] Fwd: New features required on Cortex-M platform 2014-06-13 15:33 ` AW: " Richard Rauch @ 2014-06-13 15:53 ` Jerzy Dyrda 2014-06-13 18:55 ` [ECOS] SDHC support. [Was Re: AW: [ECOS] Fwd: New features required on Cortex-M platform] Ilija Kocho 0 siblings, 1 reply; 11+ messages in thread From: Jerzy Dyrda @ 2014-06-13 15:53 UTC (permalink / raw) To: ecos-discuss; +Cc: Richard Rauch Hello Richard, On Friday 13 of June 2014 17:33:39 Richard Rauch wrote: > > Von: ecos-discuss-owner@ecos.sourceware.org [mailto:ecos-discuss- > > owner@ecos.sourceware.org] Im Auftrag von Jerzy Dyrda > > Gesendet: Freitag, 13. Juni 2014 17:15 > > An: eCos Discussion > > Betreff: [ECOS] Fwd: New features required on Cortex-M platform > > > > During developing some application on Cortex-M controller I realized that > is > > missing some vital components in current version of eCos system (from my > > point of view) i.e : > > > > 1) HTTP server - AHTTPD doesn't support lwIP stack what causes that it's > > useless. > > I'm planing to modify it thus any kind of advises are welcome. > > > > 2) Small embedded GUI working directly on display. From my side I propose > > uGFX -> http://ugfx.org/ License seems to be compatible and due its nature > > porting on new platform shouldn't be complicated even for me :) I'm also > > planning to add support and again any kind of comments advices or warnings > > are expecting. > > > > 3) SD bus support. I know that I can use SD card in SPI mode but on some > board > > like STM32F4DISCOVERY SD card i only available on SD bus. > > It's high time to add this miss part of system. > > A few comments and questions from my side: > > - what is the advantage of uGFX? Are there applications available, which are > based on uGFX? What do you think about support for QT ( > http://qt-project.org/ )? Sorry but I feel confused. How can I use QT application on Cortex-M equipped with eCos? I use QT for Host side developing but I didn't expect that possible to run it on target. > - SD card interface. Unfortunately this is very processor specific. Each > Microcontroller has its own IP for accessing SD card. But only low level SD bus driver. Upper layer for MMC/SD card is common. > We have made it e.g. > for Xilinx Zynq > (http://tiprom.itrgmbh.com/projects/ecos-on-zynq/wiki/ECosOnZynq-Wiki ), but > I assume it is not re-usable for other platforms! Did you add any layer to access MMC/SD card via SD bus similar to mmc-spi.c from CYGPKG_DEVS_DISK_MMC package? Best regards, jerzy -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 11+ messages in thread
* [ECOS] SDHC support. [Was Re: AW: [ECOS] Fwd: New features required on Cortex-M platform] 2014-06-13 15:53 ` Jerzy Dyrda @ 2014-06-13 18:55 ` Ilija Kocho 2014-06-13 19:30 ` [ECOS] " Jerzy Dyrda 2014-06-14 22:47 ` Jerzy Dyrda 0 siblings, 2 replies; 11+ messages in thread From: Ilija Kocho @ 2014-06-13 18:55 UTC (permalink / raw) To: Jerzy Dyrda, ecos-discuss; +Cc: Richard Rauch Jerzy, Richard 3) SD bus support. I know that I can use SD card in SPI mode but on some >> board like STM32F4DISCOVERY SD card i only available on SD bus. >> It's high time to add this miss part of system. > - SD card interface. Unfortunately this is very processor specific. Each > Microcontroller has its own IP for accessing SD card. > But only low level SD bus driver. Upper layer for MMC/SD card is common. This is MMC/SD disk driver for Freescale Kinetis and iMX. https://sourceforge.net/projects/ecosfreescale/files/devs/SDHC/ Upper layer (based on SPI MMC driver) and HW dependent (Freescale) parts are placed in separate packages. Jerzy, can you see if STM support can be added? Note: The aim of this project is support for MMC/SD memory cards (I.E. disk drive) SDIO is out of scope. Comments are welcome. Ilija -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 11+ messages in thread
* [ECOS] Re: SDHC support. [Was Re: AW: [ECOS] Fwd: New features required on Cortex-M platform] 2014-06-13 18:55 ` [ECOS] SDHC support. [Was Re: AW: [ECOS] Fwd: New features required on Cortex-M platform] Ilija Kocho @ 2014-06-13 19:30 ` Jerzy Dyrda 2014-06-14 22:47 ` Jerzy Dyrda 1 sibling, 0 replies; 11+ messages in thread From: Jerzy Dyrda @ 2014-06-13 19:30 UTC (permalink / raw) To: Ilija Kocho; +Cc: ecos-discuss, Richard Rauch Hello Ilija, On Friday 13 of June 2014 20:54:47 Ilija Kocho wrote: > 3) SD bus support. I know that I can use SD card in SPI mode but on some > > >> board like STM32F4DISCOVERY SD card i only available on SD bus. > >> It's high time to add this miss part of system. > > - SD card interface. Unfortunately this is very processor specific. Each > > Microcontroller has its own IP for accessing SD card. > > But only low level SD bus driver. Upper layer for MMC/SD card is common. > > This is MMC/SD disk driver for Freescale Kinetis and iMX. > https://sourceforge.net/projects/ecosfreescale/files/devs/SDHC/ > Upper layer (based on SPI MMC driver) and HW dependent (Freescale) parts > are placed in separate packages. > > Jerzy, can you see if STM support can be added? With pleasure. > Note: The aim of this project is support for MMC/SD memory cards (I.E. > disk drive) SDIO is out of scope. OK. Best regards, jerzy -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 11+ messages in thread
* [ECOS] Re: SDHC support. [Was Re: AW: [ECOS] Fwd: New features required on Cortex-M platform] 2014-06-13 18:55 ` [ECOS] SDHC support. [Was Re: AW: [ECOS] Fwd: New features required on Cortex-M platform] Ilija Kocho 2014-06-13 19:30 ` [ECOS] " Jerzy Dyrda @ 2014-06-14 22:47 ` Jerzy Dyrda 2014-06-16 6:23 ` Ilija Kocho 1 sibling, 1 reply; 11+ messages in thread From: Jerzy Dyrda @ 2014-06-14 22:47 UTC (permalink / raw) To: Ilija Kocho; +Cc: eCos Discussion, Richard Rauch Hello Ilija, 2014-06-13 20:54 GMT+02:00 Ilija Kocho <ilijak@siva.com.mk>: > 3) SD bus support. I know that I can use SD card in SPI mode but on some >>> board like STM32F4DISCOVERY SD card i only available on SD bus. >>> It's high time to add this miss part of system. >> - SD card interface. Unfortunately this is very processor specific. Each >> Microcontroller has its own IP for accessing SD card. >> But only low level SD bus driver. Upper layer for MMC/SD card is common. > > This is MMC/SD disk driver for Freescale Kinetis and iMX. > https://sourceforge.net/projects/ecosfreescale/files/devs/SDHC/ > Upper layer (based on SPI MMC driver) and HW dependent (Freescale) parts > are placed in separate packages. > > Jerzy, can you see if STM support can be added? After first look I seems that yes. IMHO it's required some code re-factoring i.e. : 1) CYGPKG_DEVS_DISK_MMC_SDHC should be pushed into CYGPKG_DEVS_DISK_MMC package as a component similar to CYGPKG_DEVS_DISK_MMC_SPI component. 2) Using Freescale middle layer (sdhc.c) from platform specific package and pushing it to generic part. The aim of this layer is support for SDHC transaction what is generic. 3) And we should provide low level platform specific driver for SD bus not as Freescale in /devs/disk/mmc/sdhc/ but create new place /devs/sd/cortexm/stm similar to /devs/spi/cortexm/stm with simliar functionality i.e. xfer function supporting poling and DMA mode. 4) Regarding license most of code in platform specific part is a Freescale code. Can we use it? Best regards, jerzy -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [ECOS] Re: SDHC support. [Was Re: AW: [ECOS] Fwd: New features required on Cortex-M platform] 2014-06-14 22:47 ` Jerzy Dyrda @ 2014-06-16 6:23 ` Ilija Kocho 0 siblings, 0 replies; 11+ messages in thread From: Ilija Kocho @ 2014-06-16 6:23 UTC (permalink / raw) To: Jerzy Dyrda; +Cc: eCos Discussion, Richard Rauch, Michael Jones Jerzy Thank you for your analysis. I guess, that Mike follows the list, but anyway I'm adding him as an initiator of this SDHC port. On 15.06.2014 00:47, Jerzy Dyrda wrote: > Hello Ilija, > > 2014-06-13 20:54 GMT+02:00 Ilija Kocho <ilijak@siva.com.mk>: >> 3) SD bus support. I know that I can use SD card in SPI mode but on some >>>> board like STM32F4DISCOVERY SD card i only available on SD bus. >>>> It's high time to add this miss part of system. >>> - SD card interface. Unfortunately this is very processor specific. Each >>> Microcontroller has its own IP for accessing SD card. >>> But only low level SD bus driver. Upper layer for MMC/SD card is common. >> This is MMC/SD disk driver for Freescale Kinetis and iMX. >> https://sourceforge.net/projects/ecosfreescale/files/devs/SDHC/ >> Upper layer (based on SPI MMC driver) and HW dependent (Freescale) parts >> are placed in separate packages. >> >> Jerzy, can you see if STM support can be added? > After first look I seems that yes. > IMHO it's required some code re-factoring i.e. : > 1) CYGPKG_DEVS_DISK_MMC_SDHC should be pushed into CYGPKG_DEVS_DISK_MMC > package as a component similar to CYGPKG_DEVS_DISK_MMC_SPI component. > 2) Using Freescale middle layer (sdhc.c) from platform specific > package and pushing it to generic > part. The aim of this layer is support for SDHC transaction what is generic. It seems pretty generic indeed, only it has some references to usdhc_host.c. We could/should make some abstraction either simple (MACROS) or callback table (may require middle-level io driver). Can anybody comment on this? > 3) And we should provide low level platform specific driver for SD bus > not as Freescale in > /devs/disk/mmc/sdhc/ but create new place /devs/sd/cortexm/stm similar > to /devs/spi/cortexm/stm Once 2) is defined, this should be straight-forward. > with simliar functionality i.e. xfer function supporting poling and DMA mode. > 4) Regarding license most of code in platform specific part is a Freescale code. > Can we use it? IANAL, but IMO yes as long as we regard licence terms. The Freescale code is published under BSD licence that is one of eligible licences for third party products regarding eCos (Ref: http://ecos.sourceware.org/contrib.html). Any additional comments? Ilija -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 11+ messages in thread
* [ECOS] RE: New features required on Cortex-M platform 2014-06-13 15:15 [ECOS] Fwd: New features required on Cortex-M platform Jerzy Dyrda 2014-06-13 15:33 ` AW: " Richard Rauch @ 2014-06-16 2:08 ` Andrew Hannam 2014-06-16 11:02 ` Jerzy Dyrda 2014-06-16 18:46 ` Ilija Kocho 1 sibling, 2 replies; 11+ messages in thread From: Andrew Hannam @ 2014-06-16 2:08 UTC (permalink / raw) To: 'Jerzy Dyrda', 'eCos Discussion' As one of the primary developers of uGFX I have been watching the ecos mail-lists for a long time but have never implemented an ecos system yet (just due to being caught up on other projects such as uGFX). I would be happy to work with you to create a port of uGFX for ecos. As per one of your follow-up Emails relating to uGFX versus Qt: Some of the advantages of uGFX versus Qt: - uGFX is designed for small memory footprint systems (ie. embedded systems), Qt is not and therefore has a very large footprint. - uGFX works equally well on systems without a framebuffer. Qt requires a framebuffer (and the related RAM requirements) - uGFX is a full multi-threaded GUI, you can draw from any thread regardless on which thread the object was created. Qt has only limited support for multi-threaded applications. - uGFX has support for many LCD controllers and supports custom wiring connections to your micro. Qt assumes a full graphics/windows layer is already available (usually X). - uGFX includes other sub-systems like audio, toggle switch input devices, analogue dials, ROM based file system etc. Qt does not. Some disadvantages of uGFX versus Qt: - uGFX has a different API to Qt. More programmers are familiar with Qt. - uGFX has only restricted support for overlapping windows (container windows are however supported). uGFX is in short designed for embedded systems while Qt has a desktop based design. uGFX aims to provide a cross-platform way of writing embedded GUI applications. For example, most of the uGFX demos can be run on any uGFX supported operating system without changing a single line of code. This means you can prototype and debug your application on Windows or Linux and then very simply move it to your embedded board. Regards, Andrew (aka inmarket) -----Original Message----- From: Jerzy Dyrda [mailto:jerzdy@gmail.com] Sent: Saturday, 14 June 2014 1:15 AM To: eCos Discussion Subject: Fwd: New features required on Cortex-M platform Hello all, During developing some application on Cortex-M controller I realized that is missing some vital components in current version of eCos system (from my point of view) i.e : 1) HTTP server - AHTTPD doesn't support lwIP stack what causes that it's useless. I'm planing to modify it thus any kind of advises are welcome. 2) Small embedded GUI working directly on display. From my side I propose uGFX -> http://ugfx.org/ License seems to be compatible and due its nature porting on new platform shouldn't be complicated even for me :) I'm also planning to add support and again any kind of comments advices or warnings are expecting. 3) SD bus support. I know that I can use SD card in SPI mode but on some board like STM32F4DISCOVERY SD card i only available on SD bus. It's high time to add this miss part of system. Best regards, jerzy -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [ECOS] RE: New features required on Cortex-M platform 2014-06-16 2:08 ` [ECOS] RE: New features required on Cortex-M platform Andrew Hannam @ 2014-06-16 11:02 ` Jerzy Dyrda 2014-06-16 18:46 ` Ilija Kocho 1 sibling, 0 replies; 11+ messages in thread From: Jerzy Dyrda @ 2014-06-16 11:02 UTC (permalink / raw) To: Andrew Hannam Cc: ecos-discuss, Ilija Kocho [Илија Кочо] Hello Andrew, On Monday 16 of June 2014 12:08:24 Andrew Hannam wrote: > As one of the primary developers of uGFX I have been watching the ecos > mail-lists for a long time but have never implemented an ecos system yet > (just due to being caught up on other projects such as uGFX). > > > As per one of your follow-up Emails relating to uGFX versus Qt: > > Some of the advantages of uGFX versus Qt: > - uGFX is designed for small memory footprint systems (ie. embedded > systems), Qt is not and therefore has a very large footprint. > - uGFX works equally well on systems without a framebuffer. Qt requires a > framebuffer (and the related RAM requirements) > - uGFX is a full multi-threaded GUI, you can draw from any thread regardless > on which thread the object was created. Qt has only limited support for > multi-threaded applications. > - uGFX has support for many LCD controllers and supports custom wiring > connections to your micro. Qt assumes a full graphics/windows layer is > already available (usually X). > - uGFX includes other sub-systems like audio, toggle switch input devices, > analogue dials, ROM based file system etc. Qt does not. > > Some disadvantages of uGFX versus Qt: > - uGFX has a different API to Qt. More programmers are familiar with Qt. > - uGFX has only restricted support for overlapping windows (container > windows are however supported). > > uGFX is in short designed for embedded systems while Qt has a desktop based > design. Exactly. First time when I meet wit uGFX my thought was this is what I want to have in eCos - small deeply embedded GUI. > I would be happy to work with you to create a port of uGFX for ecos. It will be a honor for me but please look at topic regarding uGFX license: 1) https://sourceware.org/ml/ecos-devel/2014-06/msg00001.html > > License seems to be compatible and due its nature porting on new platform > > I'm afraid it's not compatible with eCos licence. IMO it doesn't even > comply with Open Source Definition http://opensource.org/definition 2) https://sourceware.org/ml/ecos-devel/2014-06/msg00002.html > The licence disallows commercial use. Most of eCos use is commercial, > eCos being a part of products that usually include some intellectual > property, often other than just software. > > You can link uGFX with eCos, but we can't let uGFX in main eCos tree. To be port to eCos could be accepted by eCos maintainers it have to be clarified licenses compatibility. Best regards, jerzy > -----Original Message----- > From: Jerzy Dyrda [mailto:jerzdy@gmail.com] > Sent: Saturday, 14 June 2014 1:15 AM > To: eCos Discussion > Subject: Fwd: New features required on Cortex-M platform > > Hello all, > > During developing some application on Cortex-M controller I realized that is > missing some vital components in current version of eCos system (from my > point of view) i.e : [snip] > 2) Small embedded GUI working directly on display. From my side I propose > uGFX -> http://ugfx.org/ License seems to be compatible and due its nature > porting on new platform shouldn't be complicated even for me :) I'm also > planning to add support and again any kind of comments advices or warnings > are expecting. [snip] -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [ECOS] RE: New features required on Cortex-M platform 2014-06-16 2:08 ` [ECOS] RE: New features required on Cortex-M platform Andrew Hannam 2014-06-16 11:02 ` Jerzy Dyrda @ 2014-06-16 18:46 ` Ilija Kocho 2014-06-17 0:31 ` Andrew Hannam 1 sibling, 1 reply; 11+ messages in thread From: Ilija Kocho @ 2014-06-16 18:46 UTC (permalink / raw) To: Andrew Hannam, 'Jerzy Dyrda', 'eCos Discussion' Hi Andrew We appreciate your interest in eCos and we will welcome uGFX as an added value to eCos. However due to uGFX licence terms, that disallow commercial use we can not allow it into main eCos repository. This is not an end of story, because eCos offers an elegant way for users that will want uGFX on eCos, to have it. It is eCos Package Distribution Ref: http://ecos.sourceware.org/docs-latest/cdl-guide/package.distrib.html . uGFX EPK (eCos package) is a simple way for distribution of eCos module sources. You sumply put uGFX EPK at your download page and users can import it in their private eCos repositories with few clicks. The package can also contain the licence that will be presented to the user for acceptance. Should you put uGFX package somewhere on the net we can point it by a link eCos site: http://ecos.sourceware.org/contrib.html . Some technical considerations: eCos has a well defined I/O layer and Framebuffer is a part of it. Therefore we strongly recommend Framebuffer support as an option. Of course if you have time and there's technical merit you can implement both options. Regards to both Andrew and Jerzy Ilija Kocho, eCos maintainer On 16.06.2014 04:08, Andrew Hannam wrote: > As one of the primary developers of uGFX I have been watching the ecos > mail-lists for a long time but have never implemented an ecos system yet > (just due to being caught up on other projects such as uGFX). > > I would be happy to work with you to create a port of uGFX for ecos. > > As per one of your follow-up Emails relating to uGFX versus Qt: > > Some of the advantages of uGFX versus Qt: > - uGFX is designed for small memory footprint systems (ie. embedded > systems), Qt is not and therefore has a very large footprint. > - uGFX works equally well on systems without a framebuffer. Qt requires a > framebuffer (and the related RAM requirements) > - uGFX is a full multi-threaded GUI, you can draw from any thread regardless > on which thread the object was created. Qt has only limited support for > multi-threaded applications. > - uGFX has support for many LCD controllers and supports custom wiring > connections to your micro. Qt assumes a full graphics/windows layer is > already available (usually X). > - uGFX includes other sub-systems like audio, toggle switch input devices, > analogue dials, ROM based file system etc. Qt does not. > > Some disadvantages of uGFX versus Qt: > - uGFX has a different API to Qt. More programmers are familiar with Qt. > - uGFX has only restricted support for overlapping windows (container > windows are however supported). > > uGFX is in short designed for embedded systems while Qt has a desktop based > design. > > uGFX aims to provide a cross-platform way of writing embedded GUI > applications. For example, most of the uGFX demos can be run on any uGFX > supported operating system without changing a single line of code. This > means you can prototype and debug your application on Windows or Linux and > then very simply move it to your embedded board. > > Regards, > Andrew (aka inmarket) > > -----Original Message----- > From: Jerzy Dyrda [mailto:jerzdy@gmail.com] > Sent: Saturday, 14 June 2014 1:15 AM > To: eCos Discussion > Subject: Fwd: New features required on Cortex-M platform > > Hello all, > > During developing some application on Cortex-M controller I realized that is > missing some vital components in current version of eCos system (from my > point of view) i.e : > > 1) HTTP server - AHTTPD doesn't support lwIP stack what causes that it's > useless. > I'm planing to modify it thus any kind of advises are welcome. > > 2) Small embedded GUI working directly on display. From my side I propose > uGFX -> http://ugfx.org/ License seems to be compatible and due its nature > porting on new platform shouldn't be complicated even for me :) I'm also > planning to add support and again any kind of comments advices or warnings > are expecting. > > 3) SD bus support. I know that I can use SD card in SPI mode but on some > board like STM32F4DISCOVERY SD card i only available on SD bus. > It's high time to add this miss part of system. > > Best regards, > jerzy > > -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 11+ messages in thread
* RE: [ECOS] RE: New features required on Cortex-M platform 2014-06-16 18:46 ` Ilija Kocho @ 2014-06-17 0:31 ` Andrew Hannam 0 siblings, 0 replies; 11+ messages in thread From: Andrew Hannam @ 2014-06-17 0:31 UTC (permalink / raw) To: 'Ilija Kocho', 'Jerzy Dyrda', 'eCos Discussion' Thank-you. I will start looking at the mechanics of making this happen over the next week or so. Use of the eCos framebuffer should be easy to add. Displays can then either be via the eCos framebuffer device or via any of our currently supported LCD controllers (either framebuffer or non-framebuffer based). Regards, Andrew. -----Original Message----- From: Ilija Kocho [mailto:ilijak@siva.com.mk] Sent: Tuesday, 17 June 2014 4:46 AM To: Andrew Hannam; 'Jerzy Dyrda'; 'eCos Discussion' Subject: Re: [ECOS] RE: New features required on Cortex-M platform Hi Andrew We appreciate your interest in eCos and we will welcome uGFX as an added value to eCos. However due to uGFX licence terms, that disallow commercial use we can not allow it into main eCos repository. This is not an end of story, because eCos offers an elegant way for users that will want uGFX on eCos, to have it. It is eCos Package Distribution Ref: http://ecos.sourceware.org/docs-latest/cdl-guide/package.distrib.html . uGFX EPK (eCos package) is a simple way for distribution of eCos module sources. You sumply put uGFX EPK at your download page and users can import it in their private eCos repositories with few clicks. The package can also contain the licence that will be presented to the user for acceptance. Should you put uGFX package somewhere on the net we can point it by a link eCos site: http://ecos.sourceware.org/contrib.html . Some technical considerations: eCos has a well defined I/O layer and Framebuffer is a part of it. Therefore we strongly recommend Framebuffer support as an option. Of course if you have time and there's technical merit you can implement both options. Regards to both Andrew and Jerzy Ilija Kocho, eCos maintainer On 16.06.2014 04:08, Andrew Hannam wrote: > As one of the primary developers of uGFX I have been watching the ecos > mail-lists for a long time but have never implemented an ecos system > yet (just due to being caught up on other projects such as uGFX). > > I would be happy to work with you to create a port of uGFX for ecos. > > As per one of your follow-up Emails relating to uGFX versus Qt: > > Some of the advantages of uGFX versus Qt: > - uGFX is designed for small memory footprint systems (ie. embedded > systems), Qt is not and therefore has a very large footprint. > - uGFX works equally well on systems without a framebuffer. Qt > requires a framebuffer (and the related RAM requirements) > - uGFX is a full multi-threaded GUI, you can draw from any thread > regardless on which thread the object was created. Qt has only limited > support for multi-threaded applications. > - uGFX has support for many LCD controllers and supports custom wiring > connections to your micro. Qt assumes a full graphics/windows layer is > already available (usually X). > - uGFX includes other sub-systems like audio, toggle switch input > devices, analogue dials, ROM based file system etc. Qt does not. > > Some disadvantages of uGFX versus Qt: > - uGFX has a different API to Qt. More programmers are familiar with Qt. > - uGFX has only restricted support for overlapping windows (container > windows are however supported). > > uGFX is in short designed for embedded systems while Qt has a desktop > based design. > > uGFX aims to provide a cross-platform way of writing embedded GUI > applications. For example, most of the uGFX demos can be run on any > uGFX supported operating system without changing a single line of > code. This means you can prototype and debug your application on > Windows or Linux and then very simply move it to your embedded board. > > Regards, > Andrew (aka inmarket) > > -----Original Message----- > From: Jerzy Dyrda [mailto:jerzdy@gmail.com] > Sent: Saturday, 14 June 2014 1:15 AM > To: eCos Discussion > Subject: Fwd: New features required on Cortex-M platform > > Hello all, > > During developing some application on Cortex-M controller I realized > that is missing some vital components in current version of eCos > system (from my point of view) i.e : > > 1) HTTP server - AHTTPD doesn't support lwIP stack what causes that > it's useless. > I'm planing to modify it thus any kind of advises are welcome. > > 2) Small embedded GUI working directly on display. From my side I > propose uGFX -> http://ugfx.org/ License seems to be compatible and > due its nature porting on new platform shouldn't be complicated even > for me :) I'm also planning to add support and again any kind of > comments advices or warnings are expecting. > > 3) SD bus support. I know that I can use SD card in SPI mode but on > some board like STM32F4DISCOVERY SD card i only available on SD bus. > It's high time to add this miss part of system. > > Best regards, > jerzy > > -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2014-06-17 0:31 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-06-13 15:15 [ECOS] Fwd: New features required on Cortex-M platform Jerzy Dyrda 2014-06-13 15:33 ` AW: " Richard Rauch 2014-06-13 15:53 ` Jerzy Dyrda 2014-06-13 18:55 ` [ECOS] SDHC support. [Was Re: AW: [ECOS] Fwd: New features required on Cortex-M platform] Ilija Kocho 2014-06-13 19:30 ` [ECOS] " Jerzy Dyrda 2014-06-14 22:47 ` Jerzy Dyrda 2014-06-16 6:23 ` Ilija Kocho 2014-06-16 2:08 ` [ECOS] RE: New features required on Cortex-M platform Andrew Hannam 2014-06-16 11:02 ` Jerzy Dyrda 2014-06-16 18:46 ` Ilija Kocho 2014-06-17 0:31 ` Andrew Hannam
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).