From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13075 invoked by alias); 24 Jun 2005 00:04:06 -0000 Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Received: (qmail 13045 invoked by uid 22791); 24 Jun 2005 00:03:52 -0000 Received: from omr5.netsolmail.com (HELO omr5.netsolmail.com) (216.168.230.142) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Fri, 24 Jun 2005 00:03:52 +0000 Received: from ms5.netsolmail.com (IDENT:mirapoint@[216.168.230.178]) by omr5.netsolmail.com (8.12.10/8.12.10) with ESMTP id j5O03oqr018885 for ; Thu, 23 Jun 2005 20:03:51 -0400 (EDT) Received: from rivatek.dnsalias.net (rrcs-67-52-40-201.west.biz.rr.com [67.52.40.201]) by ms5.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id DQP21389; Thu, 23 Jun 2005 20:03:49 -0400 (EDT) Received: by rivatek.dnsalias.net (Postfix, from userid 501) id F2D2E49B78; Thu, 23 Jun 2005 19:03:48 -0500 (CDT) To: ecos-discuss@ecos.sourceware.org From: Grant Edwards In-Reply-To: References: <20050622182844.7476.qmail@web88210.mail.re2.yahoo.com> <200506231104.32693.sinany@beko.com.tr> <20050623090215.GF12265@lunn.ch> <200506231325.41733.sinany@beko.com.tr> Date: Fri, 24 Jun 2005 00:04:00 -0000 Message-Id: <20050624000348.F2D2E49B78@rivatek.dnsalias.net> Subject: [ECOS] Re: ECOS - MIPS X-SW-Source: 2005-06/txt/msg00228.txt.bz2 In gmane.os.ecos.general, you wrote: > My initial impressions were that the coding style in eCos was > rather old fashioned. Are you referring to the coding style (i.e. indentation, variable names, etc.) or the actual architecture and design? > We are probably both used to the amazing things that can be > done with STL, boost, template metaprogramming etc. However I > realise that many of these libraries and techniques are not > appropriate for embedded programming. Depends on the system. > On the other hand it is possible that some modern C++ > techniques could be useful in this context. Like what? Since eCos is the only RTOS kernel i know of written in C++, it would appear it's leading the pack in using "some modern C++ techniques. I'm no C++ expert, but the design and implimentation of the eCos kernel looked pretty nifty what with those objects and classes and whatnot. Most of the drivers, OTOH, are pretty much what drivers always are: nasty low-level C code. Embedded systems development is just plain hard compared to many other sorts of SW development. It requires a lot of knowlege about the platform hardware, the tools, and the problem domain. There is no silver bullet. > Currently I do not have enough experience of embedded > programming to give an opinion. > > Could you provide an example of how some part of eCos could be > improved using a specific design pattern. This could form the > basis of a more focused discussion of the benefits of what you > are proposing. If your ideas are practical and would genuinely > make eCos more easily configured then I am certain that the > eCos maintainers would be very happy to help you incorporate > them. I'm certain they would. -- Grant Edwards grante Yow! LOU GRANT froze at my ASSETS!! visi.com -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss