public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
From: "Andrew Hannam" <andrewh@inmarket.com.au>
To: "'Jerzy Dyrda'" <jerzdy@gmail.com>,
	"'eCos Discussion'" <ecos-discuss@ecos.sourceware.org>
Subject: [ECOS] RE: New features required on Cortex-M platform
Date: Mon, 16 Jun 2014 02:08:00 -0000	[thread overview]
Message-ID: <001001cf8907$e21e32c0$a65a9840$@inmarket.com.au> (raw)
In-Reply-To: <5752197.rmWza1iyYx@inteldesktop.site>

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

  parent reply	other threads:[~2014-06-16  2:08 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-13 15:15 [ECOS] Fwd: " 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 ` Andrew Hannam [this message]
2014-06-16 11:02   ` [ECOS] RE: New features required on Cortex-M platform Jerzy Dyrda
2014-06-16 18:46   ` Ilija Kocho
2014-06-17  0:31     ` Andrew Hannam

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='001001cf8907$e21e32c0$a65a9840$@inmarket.com.au' \
    --to=andrewh@inmarket.com.au \
    --cc=ecos-discuss@ecos.sourceware.org \
    --cc=jerzdy@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).