* Re: [ECOS] ECOS - MIPS [not found] <W646741726646371119364845@webmail3> @ 2005-06-22 7:09 ` K. Sinan YILDIRIM 2005-06-22 10:21 ` Fabian Scheler 2005-06-22 18:28 ` L D 0 siblings, 2 replies; 21+ messages in thread From: K. Sinan YILDIRIM @ 2005-06-22 7:09 UTC (permalink / raw) To: ecos-discuss i dont understand why ecos restricts its users with a configtool and templates. i want a clean makefile and module structure. not structuring with a config tool or hardware environment. it is really diffucult to add or remove a new file. also many files are coupled each other. i have a board that implements mips core and different to atlas board. there must be a clean version of ecos that includes pure mips dependencies. atlas dependencies makes people to change their OS choice... does anyone think that it is really configurable ? i dont think so... OS must fit the environment, environment must not. Salı 21 Haziran 2005 05:40 ös tarihinde, rramesh@connextechnology.com şunları yazmıştı: > I attempted the same a couple of months ago and gave up. Looks like we need > to have extensive changes to eCos before we can attempt that. The possible > route to go is to use a Simulator. If you look in the source directories, > there is a simulator which fakes the board related initializations, drivers > etc. Attempt that. If I recall right, I could not attempt to compile it > successfully. I posted a few messages here, did not get any response and I > had to change the course of RTOS selection for my project. Hope this helps. > If you find any help in this regard - in private- would you be kind enough > to inform me as well? Thanks and regards > Ramesh > > > -----Original Message----- > > From: K. Sinan YILDIRIM [mailto:sinany@beko.com.tr] > > Sent: Tuesday, June 21, 2005 01:38 PM > > To: ecos-discuss@sources.redhat.com > > Subject: [ECOS] ECOS - MIPS > > > > hi! > > > > I examined the MIPS platform ports for Ecos. I have some problems and i > > am a little bit confused. > > > > As far as i see, we cannot configure or compile ecos without selecting a > > target platform. One of the Mips targets i examined was Atlas board. when > > i configure ecos with configtool, it generates a buildtree with the atlas > > board spesific headers. > > > > Is there a possible way to configure ecos without using a target platform > > ? or jusy empty macros or platform specific functions? I want to have a > > clean and a MIPS ported code and then fill these functions according to > > my board. Is there a way to do this ? I dont want to inspect atlas board > > specific codes or compile atlas platform files. > > > > please help me... i really need help! > > > > > > -- > > Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos > > and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss -- 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] 21+ messages in thread
* Re: [ECOS] ECOS - MIPS 2005-06-22 7:09 ` [ECOS] ECOS - MIPS K. Sinan YILDIRIM @ 2005-06-22 10:21 ` Fabian Scheler 2005-06-22 18:28 ` L D 1 sibling, 0 replies; 21+ messages in thread From: Fabian Scheler @ 2005-06-22 10:21 UTC (permalink / raw) To: K. Sinan YILDIRIM; +Cc: ecos-discuss Hi, > i dont understand why ecos restricts its users with a configtool and > templates. i want a clean makefile and module structure. not structuring with > a config tool or hardware environment. it is really diffucult to add or > remove a new file. also many files are coupled each other. eCos is, compared to other embedded OS, a really highly configurable OS, the configtool and templates are provided to support the user when selecting an appropriate set of options that fulfill his needs. I don't believe you want to manage the selction of the numerous features on your own. In my opinion eCos is not really useable without the configtool > i have a board that implements mips core and different to atlas board. there > must be a clean version of ecos that includes pure mips dependencies. atlas > dependencies makes people to change their OS choice... well, eCos does (and you can find them in packages/hal/mips/arch I think), the other directories you can see are containing board-specific stuff). Well, and if eCos is not available for the special board you use, you have to adopt an existing board package, and that's the case with every embedded OS, because different boards have different features and thus they need a (at least partly) specific HAL. Ciao, Fabian -- 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] 21+ messages in thread
* Re: [ECOS] ECOS - MIPS 2005-06-22 7:09 ` [ECOS] ECOS - MIPS K. Sinan YILDIRIM 2005-06-22 10:21 ` Fabian Scheler @ 2005-06-22 18:28 ` L D 2005-06-23 6:29 ` K. Sinan YILDIRIM 1 sibling, 1 reply; 21+ messages in thread From: L D @ 2005-06-22 18:28 UTC (permalink / raw) To: ecos-discuss --- "K. Sinan YILDIRIM" <sinany@beko.com.tr> wrote: > i dont understand why ecos restricts its users with > a configtool and Have you actually used it the way it was meant to be used? You have to learn the _ecos_ way of doing things, there is no shortcuts (unless you pay someone [not me] to do the work) !. > templates. i want a clean makefile and module > structure. What is so unclean about eCos? eCos is more than a collection of .cxx files held together by makefiles. It is a collection of reconfigurable reusable components and this is where the cdl (component definition language) comes in. Take a look at his link http://www.embedded.com/story/OEG20011220S0059 its few years old but it is also nice and _short_. > not structuring with > a config tool or hardware environment. it is really > diffucult to add or > remove a new file. also many files are coupled each > other. You add and remove files by adding the filename to the a cdl file. That is not harder than editing a makefile. > > i have a board that implements mips core and > different to atlas board. there > must be a clean version of ecos that includes pure > mips dependencies. atlas There is no such thing as "pure" mips. Why don't you just give us more details about your board. It is much more productive than making negative inaccurate comments about eCos. This is how it normally works around here. You ask a question, give the relevant details and hope that someone can help. > dependencies makes people to change their OS > choice... > > does anyone think that it is really configurable ? Hello! Its called configurable for a good reason! -- 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] 21+ messages in thread
* Re: [ECOS] ECOS - MIPS 2005-06-22 18:28 ` L D @ 2005-06-23 6:29 ` K. Sinan YILDIRIM 2005-06-23 7:03 ` Andrew Lunn 0 siblings, 1 reply; 21+ messages in thread From: K. Sinan YILDIRIM @ 2005-06-23 6:29 UTC (permalink / raw) To: ecos-discuss People may have positive and negative comments about a SW product. Does this group for only positive ones ? Or only positive questions ? I have been writing SW for about 10 years. I have just examined eCOS and found that it is configurable on some way and unconfigurable ( hard to reconfigure ) on some way. May be it is much more configurable than the existing ones but not a super really configurable OS. I am the user. This is a user point of view . Having a seperate HAL layer or a structured file tree doesnt make an operating system really configurable. Configurability means to change the operating system according to your needs in a quick way : not being able to change it in a month... configurable modern SW is done with SW patterns. Architectural and Design patterns makes SW configurable, easy to change, etc... Embedded SW needs good architectural design with really reusable architectural and design patterns. What makes JAVA popular is these points. It is a programming framework that fullfills these points. eCOS is not a really framework. When you read the documentation, it seems to be an OS framework but indeed it doesn't. What i try to mean is we must make it better in order to make it usable in the future. Çarşamba 22 Haziran 2005 09:28 ös tarihinde, L D şunları yazmıştı: > --- "K. Sinan YILDIRIM" <sinany@beko.com.tr> wrote: > > i dont understand why ecos restricts its users with > > a configtool and > > Have you actually used it the way it was meant to be > used? You have to learn the _ecos_ way of doing > things, there is no shortcuts (unless you pay someone > [not me] to do the work) !. > > > templates. i want a clean makefile and module > > structure. > > What is so unclean about eCos? eCos is more than a > collection of .cxx files held together by makefiles. > It is a collection of reconfigurable reusable > components and this is where the cdl (component > definition language) comes in. Take a look at his link > http://www.embedded.com/story/OEG20011220S0059 > its few years old but it is also nice and _short_. > > > not structuring with > > a config tool or hardware environment. it is really > > diffucult to add or > > remove a new file. also many files are coupled each > > other. > > You add and remove files by adding the filename to > the a cdl file. That is not harder than editing a > makefile. > > > i have a board that implements mips core and > > different to atlas board. there > > must be a clean version of ecos that includes pure > > mips dependencies. atlas > > There is no such thing as "pure" mips. Why don't you > just give us more details about your board. It is > much more productive than making negative inaccurate > comments about eCos. This is how it normally works > around here. You ask a question, give the relevant > details and hope that someone can help. > > > dependencies makes people to change their OS > > choice... > > > > does anyone think that it is really configurable ? > > Hello! Its called configurable for a good reason! -- 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] 21+ messages in thread
* Re: [ECOS] ECOS - MIPS 2005-06-23 6:29 ` K. Sinan YILDIRIM @ 2005-06-23 7:03 ` Andrew Lunn [not found] ` <200506231102.17394.sinany@beko.com.tr> 0 siblings, 1 reply; 21+ messages in thread From: Andrew Lunn @ 2005-06-23 7:03 UTC (permalink / raw) To: K. Sinan YILDIRIM; +Cc: ecos-discuss On Thu, Jun 23, 2005 at 09:27:32AM +0300, K. Sinan YILDIRIM wrote: > People may have positive and negative comments about a SW product. Does this > group for only positive ones ? Or only positive questions ? > > I have been writing SW for about 10 years. I have just examined eCOS and found > that it is configurable on some way and unconfigurable ( hard to reconfigure > ) on some way. May be it is much more configurable than the existing ones but > not a super really configurable OS. > > I am the user. This is a user point of view . Having a seperate HAL layer or a > structured file tree doesnt make an operating system really configurable. > Configurability means to change the operating system according to your needs > in a quick way : not being able to change it in a month... > > configurable modern SW is done with SW patterns. Architectural and Design > patterns makes SW configurable, easy to change, etc... Embedded SW needs good > architectural design with really reusable architectural and design patterns. > What makes JAVA popular is these points. It is a programming framework that > fullfills these points. > > eCOS is not a really framework. When you read the documentation, it seems to > be an OS framework but indeed it doesn't. > > What i try to mean is we must make it better in order to make it usable in the > future. Could you give some examples of what you would change? Thanks Andrew -- 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] 21+ messages in thread
[parent not found: <200506231102.17394.sinany@beko.com.tr>]
* Re: [ECOS] ECOS - MIPS [not found] ` <200506231102.17394.sinany@beko.com.tr> @ 2005-06-23 8:07 ` K. Sinan YILDIRIM 2005-06-23 8:34 ` Jerome Souquieres ` (2 more replies) 0 siblings, 3 replies; 21+ messages in thread From: K. Sinan YILDIRIM @ 2005-06-23 8:07 UTC (permalink / raw) To: Andrew Lunn; +Cc: ecos-discuss i wont make it configurable with make files. i would use object oriented configurabilitiy. just inspect Java. you register classes, you program for interfaces, you use abstract classes. just inspect bridge or adapter pattern. you will understand me. > Perşembe 23 Haziran 2005 10:02 öö tarihinde, Andrew Lunn şunları yazmıştı: > > On Thu, Jun 23, 2005 at 09:27:32AM +0300, K. Sinan YILDIRIM wrote: > > > People may have positive and negative comments about a SW product. Does > > > this group for only positive ones ? Or only positive questions ? > > > > > > I have been writing SW for about 10 years. I have just examined eCOS > > > and found that it is configurable on some way and unconfigurable ( hard > > > to reconfigure ) on some way. May be it is much more configurable than > > > the existing ones but not a super really configurable OS. > > > > > > I am the user. This is a user point of view . Having a seperate HAL > > > layer or a structured file tree doesnt make an operating system really > > > configurable. Configurability means to change the operating system > > > according to your needs in a quick way : not being able to change it in > > > a month... > > > > > > configurable modern SW is done with SW patterns. Architectural and > > > Design patterns makes SW configurable, easy to change, etc... Embedded > > > SW needs good architectural design with really reusable architectural > > > and design patterns. What makes JAVA popular is these points. It is a > > > programming framework that fullfills these points. > > > > > > eCOS is not a really framework. When you read the documentation, it > > > seems to be an OS framework but indeed it doesn't. > > > > > > What i try to mean is we must make it better in order to make it usable > > > in the future. > > > > Could you give some examples of what you would change? > > > > Thanks > > Andrew -- 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] 21+ messages in thread
* Re: [ECOS] ECOS - MIPS 2005-06-23 8:07 ` K. Sinan YILDIRIM @ 2005-06-23 8:34 ` Jerome Souquieres 2005-06-23 9:02 ` Andrew Lunn 2005-06-23 15:17 ` Grant Edwards 2 siblings, 0 replies; 21+ messages in thread From: Jerome Souquieres @ 2005-06-23 8:34 UTC (permalink / raw) To: K. Sinan YILDIRIM; +Cc: ecos-discuss K. Sinan YILDIRIM wrote: > i wont make it configurable with make files. i would use object oriented > configurabilitiy. just inspect Java. > > you register classes, you program for interfaces, you use abstract > classes. > > just inspect bridge or adapter pattern. you will understand me. > > > Well, I'm afraid eCos is by philosophy and design NOT the right OS for this kind of run-time configurability. eCos is designed for embedded systems where the hardware is well known (you don't keep adding expansion boards from no-name taiwanese manufacturers), where run-time resources (memory, cpu) are scarce. In this context, compile-time configurabibity through #ifdefs and makefiles is a must. I'm using eCos myself on a MIPS target (IDT32334) and have been through the following steps: - find an existing HAL which was close to my actual hardware (here: idt79s334a) and modify it to match my hardware exactly. - build redboot with this HAL to start my system - carefully select packages and build an eCos tailored for my needs. Most OS for embedded systems I know use this philosophy (create a BSP/HAL, build the OS from selected packages using some kind of configurator). eCos "just" pushes one step further the configurability. Maybe you should look for an OS not dedicated to embedded systems if this is not the way you intend to work and you have plenty of RAM. Maybe some flavor of Linux ? -- 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] 21+ messages in thread
* Re: [ECOS] ECOS - MIPS 2005-06-23 8:07 ` K. Sinan YILDIRIM 2005-06-23 8:34 ` Jerome Souquieres @ 2005-06-23 9:02 ` Andrew Lunn 2005-06-23 10:27 ` K. Sinan YILDIRIM 2005-06-23 15:17 ` Grant Edwards 2 siblings, 1 reply; 21+ messages in thread From: Andrew Lunn @ 2005-06-23 9:02 UTC (permalink / raw) To: K. Sinan YILDIRIM; +Cc: Andrew Lunn, ecos-discuss On Thu, Jun 23, 2005 at 11:04:32AM +0300, K. Sinan YILDIRIM wrote: > i wont make it configurable with make files. i would use object oriented > configurabilitiy. just inspect Java. So you are talking about using run time configurability? Does this mean that every application must contain all of eCos? Java works this way as far as i know. You must have all of Java available because you never know what parts of it the application may use. Does such a system make sense with a deeply embedded system where i have limited memory and no secondary storage? > you register classes, you program for interfaces, you use abstract classes. > > just inspect bridge or adapter pattern. you will understand me. Actually, i don't. I've never used patterns as such. Its a relatively new name to what i suspect are old ideas. So please could you explain these patterns and how they are appropriate to extreamly small memory systems? Thanks Andrew -- 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] 21+ messages in thread
* Re: [ECOS] ECOS - MIPS 2005-06-23 9:02 ` Andrew Lunn @ 2005-06-23 10:27 ` K. Sinan YILDIRIM 2005-06-23 15:28 ` [ECOS] " Grant Edwards 2005-06-23 16:19 ` [ECOS] " Richard Forrest 0 siblings, 2 replies; 21+ messages in thread From: K. Sinan YILDIRIM @ 2005-06-23 10:27 UTC (permalink / raw) To: Andrew Lunn; +Cc: ecos-discuss there are patterns for limited memory systems and real time systems. there are papers, books... you can find them and read them. patterns doesnt always mean run-time configurability. what u can do with compile time can also be done with patterns. patterns means reusability of the design and architecture. if u want your opearting system to fullfill future requests, i must strongly suggest to use them.the things that eCos uses is traditional C programming way of doing reusability and maintainability.modern operating systems must modern software ideas and architecture. Pattern oriented architecture is not a new idea but none of the embedded operating systems uses them. Java classes are dynamically loaded. Java will be a future for embedded systems. Many companies started to use java. it has many benefits. If performance problems are solved, Java will be a revolution for embedded systems. i am going to write an operating system with patterns and reusable architecture. i will share it with you in the future when i finish. Perşembe 23 Haziran 2005 12:02 ös tarihinde, Andrew Lunn şunları yazmıştı: > On Thu, Jun 23, 2005 at 11:04:32AM +0300, K. Sinan YILDIRIM wrote: > > i wont make it configurable with make files. i would use object oriented > > configurabilitiy. just inspect Java. > > So you are talking about using run time configurability? > > Does this mean that every application must contain all of eCos? Java > works this way as far as i know. You must have all of Java available > because you never know what parts of it the application may use. Does > such a system make sense with a deeply embedded system where i have > limited memory and no secondary storage? > > > you register classes, you program for interfaces, you use abstract > > classes. > > > > just inspect bridge or adapter pattern. you will understand me. > > Actually, i don't. I've never used patterns as such. Its a relatively > new name to what i suspect are old ideas. So please could you explain > these patterns and how they are appropriate to extreamly small memory > systems? > > Thanks > Andrew -- 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] 21+ messages in thread
* [ECOS] Re: ECOS - MIPS 2005-06-23 10:27 ` K. Sinan YILDIRIM @ 2005-06-23 15:28 ` Grant Edwards 2005-06-24 6:14 ` K. Sinan YILDIRIM 2005-06-23 16:19 ` [ECOS] " Richard Forrest 1 sibling, 1 reply; 21+ messages in thread From: Grant Edwards @ 2005-06-23 15:28 UTC (permalink / raw) To: ecos-discuss In gmane.os.ecos.general, you wrote: > patterns means reusability of the design and architecture. if > u want your opearting system to fullfill future requests, i > must strongly suggest to use them.the things that eCos uses is > traditional C programming way of doing reusability and > maintainability. Right. > modern operating systems must modern software ideas and > architecture. You're free to write your own. eCos suits my needs quite nicely. > Pattern oriented architecture is not a new idea > but none of the embedded operating systems uses them. Firstly, there might be a reason for that. We're not stupid, you know. Secondly, I have no idea what you mean by "pattern oriented architecture" can you point to a description? The things that Google found were either describing ways to fail: Pattern oriented architecture - A trend that's found in systems created by architects who've recently read and digested books on architectural patterns and come to the conclusion that implementing patterns (such as front-controller, etc) is the key to a successful architecture. Rather than determining if common patterns are appropriate, and picking the most suitable one, all patterns that can be applied are done so, on top of one another, creating an entangled, schizophrenic system. or were marketing buzword-bullshit: A standards-based, pattern-oriented architecture that follows industry best-practices assures that the NEFS will fit right into your development environment. > Java classes are dynamically loaded. Java will be a future for > embedded systems. Many companies started to use java. it has > many benefits. If performance problems are solved, Java will > be a revolution for embedded systems. People have been saying that for 10 years. I stopped paying much attention 5 years ago. Java requires MASSIVE amounts of storage compared to eCos. > i am going to write an operating system with patterns and > reusable architecture. i will share it with you in the future > when i finish. OK. -- Grant Edwards grante Yow! I own seven-eighths at of all the artists in visi.com downtown Burbank! -- 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] 21+ messages in thread
* Re: [ECOS] Re: ECOS - MIPS 2005-06-23 15:28 ` [ECOS] " Grant Edwards @ 2005-06-24 6:14 ` K. Sinan YILDIRIM 2005-06-24 9:07 ` Nick Garnett 2005-06-24 14:08 ` Grant Edwards 0 siblings, 2 replies; 21+ messages in thread From: K. Sinan YILDIRIM @ 2005-06-24 6:14 UTC (permalink / raw) To: Grant Edwards, ecos-discuss SW is a different concept. You make code really faster but after 2 months you cannot improve it. Also you write it in a really maintanainable way, but it may consume too much space... vice versa...Modern SW is done with reusing the architecture, not only reusing components or codes. There are plenty of documents, you may read and learn. Embedded SW is behind the general PC software. PC SW evolved so much, many problems are solved but embedded systems are just popular and there are many problems to be solved. These discussions are the result of this situation. I just mention that eCOS didnt fullfill my needs. The only thing eCOS provides is using reusable components like the ones in visual programming languages. If u substract components, uCOS is much more usable than it if I compare it with eCOS. uCOs is small, deterministic etc... For example i may write components to uCOS and then it becomes eCOS :P (just a joke...) Just examine the books : + Real Time Design Patterns + Patterns for Small Memory Systems + Pattern Oriented SW Architecture .. they are the experiences of embedded SW developers. There are the things that they know much better... I think Operating systems are the products that must live longer. If you want your SW to live longer, you must learn new SW concepts, you must apply them... For example having an HAL layer as an architecture is not a new concept. Unix, Linux and also Windows have HAL layers. Also HAL layer is a must for embedded systems. eCOS is written in C++ . You may use Bridge or Adapter pattern to build an HAL layer. ("Program for interfaces, not for the implementation" is the main concept of modern SW. ) There are many operating systems that are done with C++. Have u ever examined them ? For example Chorus, L4, Amobea... etc. They have new ideas,they try to use new SW techniques. Perşembe 23 Haziran 2005 06:28 ös tarihinde, Grant Edwards şunları yazmıştı: > In gmane.os.ecos.general, you wrote: > > patterns means reusability of the design and architecture. if > > u want your opearting system to fullfill future requests, i > > must strongly suggest to use them.the things that eCos uses is > > traditional C programming way of doing reusability and > > maintainability. > > Right. > > > modern operating systems must modern software ideas and > > architecture. > > You're free to write your own. eCos suits my needs quite > nicely. > > > Pattern oriented architecture is not a new idea > > but none of the embedded operating systems uses them. > > Firstly, there might be a reason for that. We're not stupid, > you know. > > Secondly, I have no idea what you mean by "pattern oriented > architecture" can you point to a description? The things that > Google found were either describing ways to fail: > > Pattern oriented architecture - A trend that's found in > systems created by architects who've recently read and > digested books on architectural patterns and come to the > conclusion that implementing patterns (such as > front-controller, etc) is the key to a successful > architecture. Rather than determining if common patterns are > appropriate, and picking the most suitable one, all patterns > that can be applied are done so, on top of one another, > creating an entangled, schizophrenic system. > > or were marketing buzword-bullshit: > > A standards-based, pattern-oriented architecture that follows > industry best-practices assures that the NEFS will fit right > into your development environment. > > > Java classes are dynamically loaded. Java will be a future for > > embedded systems. Many companies started to use java. it has > > many benefits. If performance problems are solved, Java will > > be a revolution for embedded systems. > > People have been saying that for 10 years. I stopped paying > much attention 5 years ago. Java requires MASSIVE amounts of > storage compared to eCos. > > > i am going to write an operating system with patterns and > > reusable architecture. i will share it with you in the future > > when i finish. > > OK. > > -- > Grant Edwards grante Yow! I own > seven-eighths at of all the artists in visi.com > downtown Burbank! -- 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] 21+ messages in thread
* Re: [ECOS] Re: ECOS - MIPS 2005-06-24 6:14 ` K. Sinan YILDIRIM @ 2005-06-24 9:07 ` Nick Garnett 2005-06-24 14:08 ` Grant Edwards 1 sibling, 0 replies; 21+ messages in thread From: Nick Garnett @ 2005-06-24 9:07 UTC (permalink / raw) To: K. Sinan YILDIRIM; +Cc: Grant Edwards, ecos-discuss "K. Sinan YILDIRIM" <sinany@beko.com.tr> writes: > > Just examine the books : > > + Real Time Design Patterns > + Patterns for Small Memory Systems > + Pattern Oriented SW Architecture .. > > they are the experiences of embedded SW developers. There are the things that > they know much better... eCos was designed and written by experienced embedded software engineers. We don't need books to tell us how to suck those eggs. > I think Operating systems are the products that must > live longer. If you want your SW to live longer, you must learn new SW > concepts, you must apply them... Long lived software must be based on well understood, tried, tested and trusted techniques. It should not adopt the latest flavour-of-the-month fad just for the sake of appearing modern. > > For example having an HAL layer as an architecture is not a new concept. Unix, > Linux and also Windows have HAL layers. Also HAL layer is a must for embedded > systems. We have never claimed that any of the techniques in eCos are original or novel. Quite the opposite, for the reasons I give above. > eCOS is written in C++ . You may use Bridge or Adapter pattern to > build an HAL layer. The Bridge and Adapter patterns seem to be no more than techniques for separating interface from implementation. They can only be directly applied in object oriented languages and require a rather complex class hierarchy to be created. The HAL for an embedded system must be small and efficient. Embedding it in layers of C++ class hierarchies would defeat the object. Much of the HAL needs to access hardware resources, some of which must be done in assembler, and for efficiency needs to be done inline. Assembly linkage to C++ is hard, and we want the HAL code to be callable from both C++ and C code. If you want to see something similar to the Bridge/Adapter patterns being applied in eCos, see the way in which thread objects and thread queues are constructed from a mixture of interface and implementation classes. It may not match the patterns exactly, but its goal is the same. I expect you will find many examples of software patterns throughout eCos, they are mostly common implementation techniques that any experienced software engineer applies as a matter of course. > ("Program for interfaces, not for the implementation" is > the main concept of modern SW. ) > That is hardly a new concept, it is probably one of the oldest system structuring techniques around. You will find well defined and enforced interfaces throughout eCos. It is the only way for an OS that runs on a wide range of platforms, supports a wide range of devices, and is highly configurable to manage the complexity. > There are many operating systems that are done with C++. Have u ever examined > them ? For example Chorus, L4, Amobea... etc. They have new ideas,they try to > use new SW techniques. Chorus is 20+ years old. So is Amobea. Hardly new. L4 is interesting mainly for the very low level techniques used in the kernel to achieve very fast context switch times. Of course I have examined them, read the papers, downloaded the sources, talked to the authors. In the case of Chorus and Amobea, probably long before you had ever heard of them. Those parts that were useful were noted and used. Most of the more exotic techniques were marvelled over and then firmly set aside. As far as software patterns are concerned, I think you have things the wrong way round. Software Patterns are a descriptive technique used to codify the insights, knowledge and experience of expert programmers. It is not a prescription for building all code. Any pattern needs to be adapted and changed to match the specific situation. As a teaching mechanism I don't doubt that it is useful, but it is just a more formal version of learning by example, which we all went through. For real software design, it doesn't seem to be any kind of substitute for genuine knowledge and experience. -- Nick Garnett eCos Kernel Architect http://www.ecoscentric.com The eCos and RedBoot experts -- 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] 21+ messages in thread
* [ECOS] Re: ECOS - MIPS 2005-06-24 6:14 ` K. Sinan YILDIRIM 2005-06-24 9:07 ` Nick Garnett @ 2005-06-24 14:08 ` Grant Edwards 2005-06-24 14:52 ` K. Sinan YILDIRIM 1 sibling, 1 reply; 21+ messages in thread From: Grant Edwards @ 2005-06-24 14:08 UTC (permalink / raw) To: ecos-discuss In gmane.os.ecos.general, you wrote: > I just mention that eCOS didnt fullfill my needs. The only > thing eCOS provides is using reusable components like the ones > in visual programming languages. Huh? I've no idea what you mean. What are "visual" programming languages? Things like LabVIEW and IBM Data Explorer? > If u substract components, uCOS is much more usable than it if I can't take it any more. The word is _you_! > I compare it with eCOS. That statement puzzles me as well. I've used both uCOS and eCos (and I mean shipped products containing both -- not just played with them for an afternoon). They're intended for much different markets. You're comparing apples and oranges. > uCOs is small, deterministic etc... You probably find it "more usable" simply because it has so many fewer available features. It includes driver models for no peripherals, no networking, no filesystem, and only one scheduler. You should be comparing uCOS to just the eCos kernel with about half of it's available features removed. > For example i may write components to uCOS and then it becomes > eCOS :P (just a joke...) OK > Just examine the books : > > + Real Time Design Patterns > + Patterns for Small Memory Systems > + Pattern Oriented SW Architecture .. > > they are the experiences of embedded SW developers. There are > the things that they know much better... I think Operating > systems are the products that must live longer. If you want > your SW to live longer, you must learn new SW concepts, you > must apply them... So tell us, how many embedded OSes have you written? How many different emebdded SW projects have you shipped? Did you use all those "patterns"? > For example having an HAL layer as an architecture is not a > new concept. Nobody said it was. New doesn't not always mean better, and old does not always mean worse. > Unix, Linux and also Windows have HAL layers. Also HAL layer > is a must for embedded systems. eCOS is written in C++ . You > may use Bridge or Adapter pattern to build an HAL layer. > ("Program for interfaces, not for the implementation" is the > main concept of modern SW. ) I simply don't see how you think eCos violates that statement. The interfaces between eCos and various hardware drivers is well defined. > There are many operating systems that are done with C++. Have > u ever examined them ? For example Chorus, L4, Amobea... etc. > They have new ideas,they try to use new SW techniques. And how many products in the field contain those OSes? -- Grant Edwards grante Yow! LOOK!!! I'm WALKING at in my SLEEP again!! 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [ECOS] Re: ECOS - MIPS 2005-06-24 14:08 ` Grant Edwards @ 2005-06-24 14:52 ` K. Sinan YILDIRIM 2005-06-24 16:39 ` Grant Edwards 0 siblings, 1 reply; 21+ messages in thread From: K. Sinan YILDIRIM @ 2005-06-24 14:52 UTC (permalink / raw) To: Grant Edwards, ecos-discuss Cuma 24 Haziran 2005 05:08 ös tarihinde, Grant Edwards şunları yazmıştı: > In gmane.os.ecos.general, you wrote: > > I just mention that eCOS didnt fullfill my needs. The only > > thing eCOS provides is using reusable components like the ones > > in visual programming languages. > > Huh? I've no idea what you mean. What are "visual" programming > languages? Things like LabVIEW and IBM Data Explorer? > - I said visual programming languages. Not tools! If you say "tools" that means you have an idea. This is a contradiction, isn't it ? :P Some visual programming environments have component based SW development, like VB. You drag and drop components, use them, change them. I just wanted to mean that eCOS components are ,in mentality, like that. I didn't want to say that "eCOS" is bad. An advantage of eCOS is its components. It includes many components. Having components is not a bad idea.It is not new also... Isnt it ? Why do you misunderstand me ? May be your english is not so good... Go and take courses. I advice you... > > If u substract components, uCOS is much more usable than it if > > I can't take it any more. The word is _you_! > > > I compare it with eCOS. > > That statement puzzles me as well. I've used both uCOS and > eCos (and I mean shipped products containing both -- not just > played with them for an afternoon). They're intended for much > different markets. You're comparing apples and oranges. > > > uCOs is small, deterministic etc... > > You probably find it "more usable" simply because it has so > many fewer available features. It includes driver models for > no peripherals, no networking, no filesystem, and only one > scheduler. You should be comparing uCOS to just the eCos > kernel with about half of it's available features removed. > - eCOS is much more bigger, it is still groving. There may be many commercial products that uses it. But there are OS'es that do the same on the embedded world ( May be you will misunderstand me again. Let me explain. I mean kernel, not components... ). I just wanted to give an example. uCOS is not apple and eCOs is not orange. I am not a child that plays operating systems on the afternoons. I am not a uCOS fan or an anti-eCOS man. I just tried eCOS and saw that it is not really configurable. This is my idea. I wish it changes in the future... > > For example i may write components to uCOS and then it becomes > > eCOS :P (just a joke...) > > OK > > > Just examine the books : > > > > + Real Time Design Patterns > > + Patterns for Small Memory Systems > > + Pattern Oriented SW Architecture .. > > > > they are the experiences of embedded SW developers. There are > > the things that they know much better... I think Operating > > systems are the products that must live longer. If you want > > your SW to live longer, you must learn new SW concepts, you > > must apply them... > > So tell us, how many embedded OSes have you written? How many > different emebdded SW projects have you shipped? Did you use > all those "patterns"? > + I have shipped 1 million embedded products and i have written 1 million embedded operating systems. I have been using patterns for a million of years. Patterns doesnt solve everything but it increases reusability. If an operating system says "I am configurable" or " I may be used with many projects." it must , at least in the future , use some new SW techniques. > > For example having an HAL layer as an architecture is not a > > new concept. > > Nobody said it was. New doesn't not always mean better, and > old does not always mean worse. + Yes. You are really right at that point. > > > Unix, Linux and also Windows have HAL layers. Also HAL layer > > is a must for embedded systems. eCOS is written in C++ . You > > may use Bridge or Adapter pattern to build an HAL layer. > > ("Program for interfaces, not for the implementation" is the > > main concept of modern SW. ) > > I simply don't see how you think eCos violates that statement. > The interfaces between eCos and various hardware drivers is > well defined. > + Yes. You are right too. I just mean that, i think in modern object oriented manner and the code and design of eCOS has some design based lacks. > > There are many operating systems that are done with C++. Have > > u ever examined them ? For example Chorus, L4, Amobea... etc. > > They have new ideas,they try to use new SW techniques. > > And how many products in the field contain those OSes? > > -- > Grant Edwards grante Yow! LOOK!!! I'm > WALKING at in my SLEEP again!! visi.com + You must learn that many contain these OS'es. I know the internals of embedded products. I know what sort of bugs they have... Commercially used operating systems doesnt meand that they are the best. If eCOS wasnt open source or free, how many users will choose eCOS instead of Nucleus, uCOS, QNX etc... ? -- 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] 21+ messages in thread
* [ECOS] Re: ECOS - MIPS 2005-06-24 14:52 ` K. Sinan YILDIRIM @ 2005-06-24 16:39 ` Grant Edwards 0 siblings, 0 replies; 21+ messages in thread From: Grant Edwards @ 2005-06-24 16:39 UTC (permalink / raw) To: ecos-discuss In gmane.os.ecos.general, you wrote: > Cuma 24 Haziran 2005 05:08 ös tarihinde, Grant Edwards ?unlar? yazm??t?: >> In gmane.os.ecos.general, you wrote: >> > I just mention that eCOS didnt fullfill my needs. The only >> > thing eCOS provides is using reusable components like the ones >> > in visual programming languages. >> >> Huh? I've no idea what you mean. What are "visual" programming >> languages? Things like LabVIEW and IBM Data Explorer? > > - I said visual programming languages. Not tools! If you say > "tools" that means you have an idea. This is a contradiction, > isn't it ? :P Sorry, I have no idea what that means. > Some visual programming environments have component based SW > development, like VB. The VB with which I am most familiar is Victoria Bitter. After googling for "VB" I'm guessing you're talking about Visual Basic? > You drag and drop components, use them, change them. I just > wanted to mean that eCOS components are, in mentality, like > that. I didn't want to say that "eCOS" is bad. This is all about the configuration tool's UI design? You want to drag and drop stuff instead of using the tree widget? > An advantage of eCOS is its components. It includes many > components. Having components is not a bad idea.It is not new > also... Isnt it ? Why do you misunderstand me ? May be your > english is not so good... Go and take courses. I advice you... Yea, that's it. My English isn't good enough. >> You probably find it "more usable" simply because it has so >> many fewer available features. It includes driver models for >> no peripherals, no networking, no filesystem, and only one >> scheduler. You should be comparing uCOS to just the eCos >> kernel with about half of it's available features removed. > > - eCOS is much more bigger, it is still groving. There may be > many commercial products that uses it. But there are OS'es > that do the same on the embedded world ( May be you will > misunderstand me again. Let me explain. I mean kernel, not > components... ). I just wanted to give an example. uCOS is not > apple and eCOs is not orange. I am not a child that plays > operating systems on the afternoons. I am not a uCOS fan or an > anti-eCOS man. I just tried eCOS and saw that it is not really > configurable. This is my idea. I wish it changes in the > future... You're right. My English must not be up to snuff. I'll bow out of the discussion and let those with better English handle it. -- Grant Edwards grante Yow! This is my WILLIAM at BENDIX memorial CORNER visi.com where I worship William Bendix like a GOD!! -- 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] 21+ messages in thread
* [ECOS] ECOS - MIPS 2005-06-23 10:27 ` K. Sinan YILDIRIM 2005-06-23 15:28 ` [ECOS] " Grant Edwards @ 2005-06-23 16:19 ` Richard Forrest 2005-06-24 0:04 ` [ECOS] " Grant Edwards 1 sibling, 1 reply; 21+ messages in thread From: Richard Forrest @ 2005-06-23 16:19 UTC (permalink / raw) To: K. Sinan YILDIRIM; +Cc: ecos-discuss K. Sinan YILDIRIM I am new to eCos and embedded programming and still have lots to learn about both. Probably like yourself I am experienced in *nix and Windows programming with boundless resources. My initial impressions were that the coding style in eCos was rather old fashioned. 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. On the other hand it is possible that some modern C++ techniques could be useful in this context. 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. Richard Forrest On Thu, 23 Jun 2005 13:25:41 +0300, K. Sinan YILDIRIM <sinany@beko.com.tr> wrote: > there are patterns for limited memory systems and real time systems. > there are > papers, books... you can find them and read them. > > patterns doesnt always mean run-time configurability. what u can do with > compile time can also be done with patterns. > > patterns means reusability of the design and architecture. if u want your > opearting system to fullfill future requests, i must strongly suggest to > use > them.the things that eCos uses is traditional C programming way of doing > reusability and maintainability.modern operating systems must modern > software > ideas and architecture. Pattern oriented architecture is not a new idea > but > none of the embedded operating systems uses them. > > Java classes are dynamically loaded. Java will be a future for embedded > systems. Many companies started to use java. it has many benefits. If > performance problems are solved, Java will be a revolution for embedded > systems. > > i am going to write an operating system with patterns and reusable > architecture. i will share it with you in the future when i finish. -- Using Opera's revolutionary e-mail client: http://www.opera.com/m2/ -- 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] 21+ messages in thread
* [ECOS] Re: ECOS - MIPS 2005-06-23 16:19 ` [ECOS] " Richard Forrest @ 2005-06-24 0:04 ` Grant Edwards 2005-06-24 7:48 ` Richard Forrest 0 siblings, 1 reply; 21+ messages in thread From: Grant Edwards @ 2005-06-24 0:04 UTC (permalink / raw) To: ecos-discuss 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* [ECOS] Re: ECOS - MIPS 2005-06-24 0:04 ` [ECOS] " Grant Edwards @ 2005-06-24 7:48 ` Richard Forrest 0 siblings, 0 replies; 21+ messages in thread From: Richard Forrest @ 2005-06-24 7:48 UTC (permalink / raw) To: ecos-discuss I may have given the impression that I was unhappy with eCos. That could not be further from the truth. I love its compile-time configuration system. It is a really clever concept, beautifully and cleanly implemented. Altogether it is a fantastic piece of software and I would not be wasting my time learning to use it if I thought otherwise. I am genuinely incredibly grateful to all who have contributed and released it under the GPL for us all to enjoy. You probably get fed up with newbies telling you what is wrong with eCos without putting in the effort of understanding it first. And I would agree with you there. I am not going to make any criticisms (if at all) until I am a lot more experienced with eCos than I am today. My point is that criticisms should not be discouraged. Sometimes people with different software backgrounds might see something that the eCos community might miss. Encouraging people to put forward concrete proposals for discussion (not necessarily just patches) might be a good way to sort the good ideas from those that are misguided. By submitting a concrete proposal a critic can show they understand eCos, the issue they are criticising and that they have a carefully considered and practical solution. Richard Forrest On Thu, 23 Jun 2005 19:03:48 -0500, Grant Edwards <grante@visi.com> wrote: > 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. > -- Using Opera's revolutionary e-mail client: http://www.opera.com/m2/ -- 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] 21+ messages in thread
* [ECOS] Re: ECOS - MIPS 2005-06-23 8:07 ` K. Sinan YILDIRIM 2005-06-23 8:34 ` Jerome Souquieres 2005-06-23 9:02 ` Andrew Lunn @ 2005-06-23 15:17 ` Grant Edwards 2 siblings, 0 replies; 21+ messages in thread From: Grant Edwards @ 2005-06-23 15:17 UTC (permalink / raw) To: ecos-discuss In gmane.os.ecos.general, you wrote: > i wont make it configurable with make files. i would use object oriented > configurabilitiy. just inspect Java. > > you register classes, you program for interfaces, you use abstract classes. > > just inspect bridge or adapter pattern. you will understand me. That sort of run-time configurability is completely unusable for the dedicated, embedded systems for which eCos is intended. You approach would require huge amounts of storage and probably some sort of filesystem. If you want a JVM, run a JVM. -- Grant Edwards grante Yow! My uncle Murray at conquered Egypt in 53 visi.com B.C. And I can prove it too!! -- 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] 21+ messages in thread
* [ECOS] ECOS - MIPS @ 2005-06-21 13:40 K. Sinan YILDIRIM 2005-06-21 13:53 ` Andrew Lunn 0 siblings, 1 reply; 21+ messages in thread From: K. Sinan YILDIRIM @ 2005-06-21 13:40 UTC (permalink / raw) To: ecos-discuss hi! I examined the MIPS platform ports for Ecos. I have some problems and i am a little bit confused. As far as i see, we cannot configure or compile ecos without selecting a target platform. One of the Mips targets i examined was Atlas board. when i configure ecos with configtool, it generates a buildtree with the atlas board spesific headers. Is there a possible way to configure ecos without using a target platform ? or jusy empty macros or platform specific functions? I want to have a clean and a MIPS ported code and then fill these functions according to my board. Is there a way to do this ? I dont want to inspect atlas board specific codes or compile atlas platform files. please help me... i really need help! -- 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] 21+ messages in thread
* Re: [ECOS] ECOS - MIPS 2005-06-21 13:40 [ECOS] " K. Sinan YILDIRIM @ 2005-06-21 13:53 ` Andrew Lunn 0 siblings, 0 replies; 21+ messages in thread From: Andrew Lunn @ 2005-06-21 13:53 UTC (permalink / raw) To: K. Sinan YILDIRIM; +Cc: ecos-discuss On Tue, Jun 21, 2005 at 04:38:23PM +0300, K. Sinan YILDIRIM wrote: > hi! > > I examined the MIPS platform ports for Ecos. I have some problems and i am a > little bit confused. > > As far as i see, we cannot configure or compile ecos without > selecting a target platform. One of the Mips targets i examined was > Atlas board. when i configure ecos with configtool, it generates a > buildtree with the atlas board spesific headers. > > Is there a possible way to configure ecos without using a target > platform ? or jusy empty macros or platform specific functions? I > want to have a clean and a MIPS ported code and then fill these > functions according to my board. Is there a way to do this ? I dont > want to inspect atlas board specific codes or compile atlas platform > files. The normal way of doing a port is to take an existing port which is the most similar and modify it to work for your target. So if you board is like the atlas, then use the atlas for a starting point. If its more like a tx49 then use the tx49 as a starting point. In the repository you need to copy the HAL files from you choosen starting target to a directory for your target. You then need to start making the modifications, and add the necassary entries in the packages/ecos.db file. There is a documentation about doing a port. See http://ecos.sourceware.org/docs-latest/ref/hal-porting-guide.html Andrew -- 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] 21+ messages in thread
end of thread, other threads:[~2005-06-24 16:39 UTC | newest] Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <W646741726646371119364845@webmail3> 2005-06-22 7:09 ` [ECOS] ECOS - MIPS K. Sinan YILDIRIM 2005-06-22 10:21 ` Fabian Scheler 2005-06-22 18:28 ` L D 2005-06-23 6:29 ` K. Sinan YILDIRIM 2005-06-23 7:03 ` Andrew Lunn [not found] ` <200506231102.17394.sinany@beko.com.tr> 2005-06-23 8:07 ` K. Sinan YILDIRIM 2005-06-23 8:34 ` Jerome Souquieres 2005-06-23 9:02 ` Andrew Lunn 2005-06-23 10:27 ` K. Sinan YILDIRIM 2005-06-23 15:28 ` [ECOS] " Grant Edwards 2005-06-24 6:14 ` K. Sinan YILDIRIM 2005-06-24 9:07 ` Nick Garnett 2005-06-24 14:08 ` Grant Edwards 2005-06-24 14:52 ` K. Sinan YILDIRIM 2005-06-24 16:39 ` Grant Edwards 2005-06-23 16:19 ` [ECOS] " Richard Forrest 2005-06-24 0:04 ` [ECOS] " Grant Edwards 2005-06-24 7:48 ` Richard Forrest 2005-06-23 15:17 ` Grant Edwards 2005-06-21 13:40 [ECOS] " K. Sinan YILDIRIM 2005-06-21 13:53 ` Andrew Lunn
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).