* [ECOS] eCosCentric Cortex-M port contribution @ 2008-11-03 15:50 Nick Garnett 2008-11-04 18:30 ` simon.kallweit 0 siblings, 1 reply; 11+ messages in thread From: Nick Garnett @ 2008-11-03 15:50 UTC (permalink / raw) To: ecos-discuss The eCosCentric Cortex-M port has now been checked in to the repository. The following packages have been added: hal/cortexm/arch hal/cortexm/stm32/var hal/cortexm/stm32/stm3210e_eval devs/serial/cortexm/stm32 devs/flash/cortexm/stm32 ecos.db and NEWS have also been updated. See the various ChangeLogs for details. There are a few points about this port: - The internal flash driver is for the Version 2 driver architecture. To use it you will need to check out the flash_v2 branch and merge it with the trunk. A proper merge of V2 into the trunk is part of the eCos v3.0 work and is ongoing. - Support for the NOR flash on the STM3210E board is also V2 based. - There is currently no documentation for the HALs or drivers. - A new ARM toolchain that supports the Cortex-M is available. This toolchain contains a number of patches for code generation and GDB issues. These toolchains are available under ftp://ecos.sourceware.org/pub/ecos/gnutools/ Linux: i386linux/ecoscentric-gnutools-arm-eabi-20081022-sw.i386linux.tar.bz2 Cygwin: cygwin/ecoscentric-gnutools-arm-eabi-20081022-sw.cygwin.tar.bz2 These will also become available at the usual mirror sites, see: http://ecos.sourceware.org/mirror.html http://sourceware.org/mirrors.html These tools will also be used in eCos v3.0 for targets based on the ARM architecture HAL. eCosCentric already have patches to make the tools work with the ARM HAL and will be providing those soon for v3.0, so there is no need to do so separately. - Copyright and License headers currently use the original format, pending wholesale conversion to FSF copyright for v3.0. -- Nick Garnett eCos Kernel Architect eCosCentric Limited http://www.eCosCentric.com The eCos experts Barnwell House, Barnwell Drive, Cambridge, UK. Tel: +44 1223 245571 Registered in England and Wales: Reg No: 4422071 -- 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] eCosCentric Cortex-M port contribution 2008-11-03 15:50 [ECOS] eCosCentric Cortex-M port contribution Nick Garnett @ 2008-11-04 18:30 ` simon.kallweit 2008-11-04 19:28 ` Nick Garnett 0 siblings, 1 reply; 11+ messages in thread From: simon.kallweit @ 2008-11-04 18:30 UTC (permalink / raw) To: Nick Garnett; +Cc: ecos-discuss Nick Garnett wrote: > The eCosCentric Cortex-M port has now been checked in to the > repository. > > The following packages have been added: > > hal/cortexm/arch > hal/cortexm/stm32/var > hal/cortexm/stm32/stm3210e_eval > devs/serial/cortexm/stm32 > devs/flash/cortexm/stm32 > > ecos.db and NEWS have also been updated. > See the various ChangeLogs for details. > This is good news. Already checked out and tried on my evalboard. Seems to run, expect some small issues. I have had a look at you're approach to context switching and interrupt handling. It's quite nicely done, although you don't use NVIC exception handling for normal context switches during thread execution, which is something I absolutely tried to do (and had lots of trouble with :). Also, your port does not have a unified SavedRegisters structure, which mine had. But it's nice that so much is written in plain C, my port has rather more assembler code. Another difference is your GPIO framework for the STM32. As it seems your framework does not support "chanining" multiple pins on the same pin for configuration, which mine offered. In contrast your framework offers the possibility to store the configuration directly in the pin definition, which is a nice thing I guess. I might add support for chaining multiple pins, if there is nothing against it? My port also featured some more "helper macros". This included things like enable/disable/reset peripheral clocks, setup FSMC controllers etc. which obviously improve code readability. Is there interest to get such macros in the main repo? Also I had done some more register definitions which I can add. I also have a working wallclock driver for the STM32, which I will port to your port :) Will it be included or do you already have such a driver in the pipeline? Many thanks for the contribution! Simon -- 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] eCosCentric Cortex-M port contribution 2008-11-04 18:30 ` simon.kallweit @ 2008-11-04 19:28 ` Nick Garnett 2008-11-04 20:46 ` Simon Kallweit 0 siblings, 1 reply; 11+ messages in thread From: Nick Garnett @ 2008-11-04 19:28 UTC (permalink / raw) To: simon.kallweit; +Cc: ecos-discuss "simon.kallweit@intefo.ch" <simon.kallweit@intefo.ch> writes: > > This is good news. Already checked out and tried on my > evalboard. Seems to run, expect some small issues. I have had a look > at you're approach to context switching and interrupt handling. It's > quite nicely done, although you don't use NVIC exception handling for > normal context switches during thread execution, which is something I > absolutely tried to do (and had lots of trouble with :). I tried that approach originally and had trouble with it too. Keeping all thread context switching entirely in thread mode made a lot of stuff much simpler, particularly the use of the two stacks. > Also, your > port does not have a unified SavedRegisters structure, which mine > had. I also tried that originally, but decided that the extra code needed to save and restore compatible register sets, particularly during interrupts was an unnecessary burden. The only place that the different formats matter are in the debug code, where a little extra code probably doesn't matter. The result is that threads, exceptions and interrupts can use the most natural and efficient code to push and pop state. To be honest, I have never been entirely convinced that the use of a common saved state format for all contexts was the right approach, despite it being my idea. So this HAL was a small experiment to see how using different formats would work. I think it has worked very well. > But it's nice that so much is written in plain C, my port has > rather more assembler code. Given that one of the features of the Cortex-M was that it could be programmed in C throughout, I wanted to try and keep as close to that idea as possible. I didn't quite manage it since there are some things that eCos needs doing that can only be achieved in assembler. > Another difference is your GPIO framework for the STM32. As it seems > your framework does not support "chanining" multiple pins on the same > pin for configuration, which mine offered. In contrast your framework > offers the possibility to store the configuration directly in the pin > definition, which is a nice thing I guess. I might add support for > chaining multiple pins, if there is nothing against it? I'm not sure what you mean by chaining here. Could you explain. > My port also featured some more "helper macros". This included things > like enable/disable/reset peripheral clocks, setup FSMC controllers > etc. which obviously improve code readability. Is there interest to > get such macros in the main repo? My general approach to macros is that things that get done a lot (like configuring GPIO lines), or which are exported to more generic code (like the interrupt mask stuff) should go into macros. However, stuff that will only ever be called once (for example in a driver or in HAL init code) should usually just be written out in the code. This makes things easier for future maintenance since you don't have to go searching for a macro defined in some obscure header. So for things like peripheral clocks, which may be manipulated in different drivers, I suspect a macro may be useful. However, for the FSMC I suspect it is not very useful since this tends to be set up once, and having the code scattered in various macros makes it harder to read and maintain. > > Also I had done some more register definitions which I can add. Typing in register definitions is the most time consuming part of a new port, so any new definitions will be welcome. Just make sure they conform to the current naming and layout convention. > I also > have a working wallclock driver for the STM32, which I will port to > your port :) Will it be included or do you already have such a driver > in the pipeline? We don't currently have a wallclock driver, so please feel free to contribute yours. -- Nick Garnett eCos Kernel Architect eCosCentric Limited http://www.eCosCentric.com The eCos experts Barnwell House, Barnwell Drive, Cambridge, UK. Tel: +44 1223 245571 Registered in England and Wales: Reg No: 4422071 -- 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] eCosCentric Cortex-M port contribution 2008-11-04 19:28 ` Nick Garnett @ 2008-11-04 20:46 ` Simon Kallweit 2008-11-04 21:43 ` Nick Garnett 0 siblings, 1 reply; 11+ messages in thread From: Simon Kallweit @ 2008-11-04 20:46 UTC (permalink / raw) To: Nick Garnett; +Cc: ecos-discuss Nick Garnett schrieb: > "simon.kallweit@intefo.ch" <simon.kallweit@intefo.ch> writes: > > >> This is good news. Already checked out and tried on my >> evalboard. Seems to run, expect some small issues. I have had a look >> at you're approach to context switching and interrupt handling. It's >> quite nicely done, although you don't use NVIC exception handling for >> normal context switches during thread execution, which is something I >> absolutely tried to do (and had lots of trouble with :). >> > > I tried that approach originally and had trouble with it too. Keeping > all thread context switching entirely in thread mode made a lot of > stuff much simpler, particularly the use of the two stacks. > Yep, I can see. I think I was kind of blinded with the way the Cortex-M3 presumed you to do context switching. > >> Also, your >> port does not have a unified SavedRegisters structure, which mine >> had. >> > > I also tried that originally, but decided that the extra code needed > to save and restore compatible register sets, particularly during > interrupts was an unnecessary burden. The only place that the > different formats matter are in the debug code, where a little extra > code probably doesn't matter. The result is that threads, exceptions > and interrupts can use the most natural and efficient code to push and > pop state. > > To be honest, I have never been entirely convinced that the use of a > common saved state format for all contexts was the right approach, > despite it being my idea. So this HAL was a small experiment to see > how using different formats would work. I think it has worked very > well. > Ok sounds like a good idea then. Your code looks cleaner than mine did, so it probably is the right way. > >> But it's nice that so much is written in plain C, my port has >> rather more assembler code. >> > > Given that one of the features of the Cortex-M was that it could be > programmed in C throughout, I wanted to try and keep as close to that > idea as possible. I didn't quite manage it since there are some things > that eCos needs doing that can only be achieved in assembler. > True, but compared to the ARM port it's like nothing. I think the port is very readable. > >> Another difference is your GPIO framework for the STM32. As it seems >> your framework does not support "chanining" multiple pins on the same >> pin for configuration, which mine offered. In contrast your framework >> offers the possibility to store the configuration directly in the pin >> definition, which is a nice thing I guess. I might add support for >> chaining multiple pins, if there is nothing against it? >> > > I'm not sure what you mean by chaining here. Could you explain. > The idea is that you can OR multiple pins of the same port and configure/set them in one go. > > >> My port also featured some more "helper macros". This included things >> like enable/disable/reset peripheral clocks, setup FSMC controllers >> etc. which obviously improve code readability. Is there interest to >> get such macros in the main repo? >> > > My general approach to macros is that things that get done a lot > (like configuring GPIO lines), or which are exported to more generic > code (like the interrupt mask stuff) should go into macros. However, > stuff that will only ever be called once (for example in a driver or > in HAL init code) should usually just be written out in the code. This > makes things easier for future maintenance since you don't have to go > searching for a macro defined in some obscure header. > > So for things like peripheral clocks, which may be manipulated in > different drivers, I suspect a macro may be useful. However, for the > FSMC I suspect it is not very useful since this tends to be set up > once, and having the code scattered in various macros makes it harder > to read and maintain. > Understood. I'll try to cut it down and post a version. > >> Also I had done some more register definitions which I can add. >> > > Typing in register definitions is the most time consuming part of a > new port, so any new definitions will be welcome. Just make sure they > conform to the current naming and layout convention. > Yeah, I had a slightly different naming scheme, but adapting it should be simple. > >> I also >> have a working wallclock driver for the STM32, which I will port to >> your port :) Will it be included or do you already have such a driver >> in the pipeline? >> > > We don't currently have a wallclock driver, so please feel free to > contribute yours. > Ok, I'll port it soon and post it. Btw. I did not find any interface to set alarms for the Wallclock. Is there a common interface to set such an alarm-wakeup? Simon -- 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] eCosCentric Cortex-M port contribution 2008-11-04 20:46 ` Simon Kallweit @ 2008-11-04 21:43 ` Nick Garnett 0 siblings, 0 replies; 11+ messages in thread From: Nick Garnett @ 2008-11-04 21:43 UTC (permalink / raw) To: Simon Kallweit; +Cc: ecos-discuss Simon Kallweit <simon.kallweit@intefo.ch> writes: > Nick Garnett schrieb: > > "simon.kallweit@intefo.ch" <simon.kallweit@intefo.ch> writes: > > > > > >> This is good news. Already checked out and tried on my > >> evalboard. Seems to run, expect some small issues. I have had a look > >> at you're approach to context switching and interrupt handling. It's > >> quite nicely done, although you don't use NVIC exception handling for > >> normal context switches during thread execution, which is something I > >> absolutely tried to do (and had lots of trouble with :). > >> > > > > I tried that approach originally and had trouble with it too. Keeping > > all thread context switching entirely in thread mode made a lot of > > stuff much simpler, particularly the use of the two stacks. > > > > Yep, I can see. I think I was kind of blinded with the way the > Cortex-M3 presumed you to do context switching. The Cortex-M seems to be designed to a particular model that ARM decree is the right way to do things. Unfortunately that doesn't quite fit with the way eCos works, so some extra effort is needed to match them up. > > > >> But it's nice that so much is written in plain C, my port has > >> rather more assembler code. > >> > > > > Given that one of the features of the Cortex-M was that it could be > > programmed in C throughout, I wanted to try and keep as close to that > > idea as possible. I didn't quite manage it since there are some things > > that eCos needs doing that can only be achieved in assembler. > > > > True, but compared to the ARM port it's like nothing. I think the port > is very readable. While there are some bits and pieces copied over from the ARM HAL, particularly in the debug code, the HAL is structured more like the PowerPC and MIPS HALs. In some ways the ARM HAL is a bit of a maverick in the way it is structured. > > > > >> Another difference is your GPIO framework for the STM32. As it seems > >> your framework does not support "chanining" multiple pins on the same > >> pin for configuration, which mine offered. In contrast your framework > >> offers the possibility to store the configuration directly in the pin > >> definition, which is a nice thing I guess. I might add support for > >> chaining multiple pins, if there is nothing against it? > >> > > > > I'm not sure what you mean by chaining here. Could you explain. > > > > The idea is that you can OR multiple pins of the same port and > configure/set them in one go. I'm not really convinced that would be very useful. The pins for a particular device are the ones that need relating, but they often need configuring to different modes. See the UART pins for example. I think having a set of pins defined in one decriptor might be confusing. > >> I also > >> have a working wallclock driver for the STM32, which I will port to > >> your port :) Will it be included or do you already have such a driver > >> in the pipeline? > >> > > > > We don't currently have a wallclock driver, so please feel free to > > contribute yours. > > Ok, I'll port it soon and post it. Btw. I did not find any interface > to set alarms for the Wallclock. Is there a common interface to set > such an alarm-wakeup? There is no alarm support in the wallclock device. Wallclocks are very variable in the functionality they supply so the driver was designed to support just the absolute minimum: just read and set a seconds-since-epoch value. -- Nick Garnett eCos Kernel Architect eCosCentric Limited http://www.eCosCentric.com The eCos experts Barnwell House, Barnwell Drive, Cambridge, UK. Tel: +44 1223 245571 Registered in England and Wales: Reg No: 4422071 -- 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] eCosCentric Cortex-M port contribution @ 2008-10-07 17:03 Nick Garnett 2008-10-08 6:37 ` Simon Kallweit 0 siblings, 1 reply; 11+ messages in thread From: Nick Garnett @ 2008-10-07 17:03 UTC (permalink / raw) To: ecos-discuss As some of you may know, eCosCentric have been working on a Cortex-M port for eCos for a while. This has now reached a reasonably stable state and is currently running through tests in our test farm. We have decided to contribute the basic packages to anoncvs. This will provide a working Cortex-M base on which the community can further develop their own custom hardware ports. The packages I intend to contribute are as follows: Architecture HAL STM32 Variant HAL STM3210E-EVAL Platform HAL USART serial driver On-Chip FLASH driver (V2 flash interface) In addition there are a number of toolchain issues that need to be addressed. I discovered a potential problem the M3 implementation which needs a compiler modification (ARM are currently still evaluating the issue). GDB has some problems correctly supporting the different layout of the CPSR register in the M processors. There are also some GCC multilib issues that need sorting out. The result of this is that we will release a specially patched version of the ARM toolchain to go with the contribution. All of this is in hand but not quite yet ready for contribution: the toolchain work needs completing, and we want to get a few runs in on the test farm to ensure there are no obvious problems before contributing. I expect this to take a couple of weeks more. -- Nick Garnett eCos Kernel Architect eCosCentric Limited http://www.eCosCentric.com The eCos experts Barnwell House, Barnwell Drive, Cambridge, UK. Tel: +44 1223 245571 Registered in England and Wales: Reg No: 4422071 -- 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] eCosCentric Cortex-M port contribution 2008-10-07 17:03 Nick Garnett @ 2008-10-08 6:37 ` Simon Kallweit 2008-10-08 11:13 ` Nick Garnett 0 siblings, 1 reply; 11+ messages in thread From: Simon Kallweit @ 2008-10-08 6:37 UTC (permalink / raw) To: Nick Garnett; +Cc: ecos-discuss Nick Garnett schrieb: > As some of you may know, eCosCentric have been working on a Cortex-M > port for eCos for a while. This has now reached a reasonably stable > state and is currently running through tests in our test farm. > Can the test results be browsed by normal people, or is this still exclusive to ecos maintainers? > We have decided to contribute the basic packages to anoncvs. This > will provide a working Cortex-M base on which the community can > further develop their own custom hardware ports. > Sounds great! > The packages I intend to contribute are as follows: > > Architecture HAL > STM32 Variant HAL > STM3210E-EVAL Platform HAL > USART serial driver > On-Chip FLASH driver (V2 flash interface) > Are there plans to merge the flash V2 support into the trunk anytime soon? Or is this scheduled for the ecos 3 release? > In addition there are a number of toolchain issues that need to be > addressed. I discovered a potential problem the M3 implementation > which needs a compiler modification (ARM are currently still > evaluating the issue). GDB has some problems correctly supporting the > different layout of the CPSR register in the M processors. There are > also some GCC multilib issues that need sorting out. > > The result of this is that we will release a specially patched version > of the ARM toolchain to go with the contribution. > Could you give us some more information about the issues? Also, are there plans to get the patches into the mainline GCC? > All of this is in hand but not quite yet ready for contribution: the > toolchain work needs completing, and we want to get a few runs in on > the test farm to ensure there are no obvious problems before > contributing. > > I expect this to take a couple of weeks more. > Now, that puts me in quite an akward situation, as I've been working on a community cortex-m3 port for almost a month now. I wonder if it is best to stop my efforts and wait for your contribution. As we just got the first prototypes of our new STM32 based design a few days ago, we really look forward to get ecos working on the boards, so I cannot really just sit here and wait for your release. Is there a possibility to get the current snapshot upfront so I can continue with development based on your port, and see if there is anything worth to be contributed from the community port? I'd rather put further efforts into your port, if it is the better base for the future. Best regards, Simon -- 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] eCosCentric Cortex-M port contribution 2008-10-08 6:37 ` Simon Kallweit @ 2008-10-08 11:13 ` Nick Garnett 2008-10-08 12:07 ` simon.kallweit 0 siblings, 1 reply; 11+ messages in thread From: Nick Garnett @ 2008-10-08 11:13 UTC (permalink / raw) To: Simon Kallweit; +Cc: ecos-discuss Simon Kallweit <simon.kallweit@intefo.ch> writes: > Nick Garnett schrieb: > > As some of you may know, eCosCentric have been working on a Cortex-M > > port for eCos for a while. This has now reached a reasonably stable > > state and is currently running through tests in our test farm. > > > > Can the test results be browsed by normal people, or is this still > exclusive to ecos maintainers? These results are only available inside eCosCentric. > Are there plans to merge the flash V2 support into the trunk anytime > soon? Or is this scheduled for the ecos 3 release? Merging the V2 branch is part of the 3.0 release. In the meantime the V2 flash interface can still be used from its own branch. > Could you give us some more information about the issues? Also, are > there plans to get the patches into the mainline GCC? Unfortunately the details are covered by various NDAs between us, CodeSourcery and ARM. Once the problem is confirmed by ARM then I expect CodeSourcery will update their release, and this will find its way into the FSF sources at some point. In the meantime we are looking at making a temporary fix for the toolchain that will go out with 3.0. Although we will pre-release it when the Cortex-M contribution is made. > > All of this is in hand but not quite yet ready for contribution: the > > toolchain work needs completing, and we want to get a few runs in on > > the test farm to ensure there are no obvious problems before > > contributing. > > > > I expect this to take a couple of weeks more. > > > > Now, that puts me in quite an akward situation, as I've been working > on a community cortex-m3 port for almost a month now. I wonder if it > is best to stop my efforts and wait for your contribution. As we just > got the first prototypes of our new STM32 based design a few days ago, > we really look forward to get ecos working on the boards, so I cannot > really just sit here and wait for your release. Is there a possibility > to get the current snapshot upfront so I can continue with development > based on your port, and see if there is anything worth to be > contributed from the community port? I'd rather put further efforts > into your port, if it is the better base for the future. We don't want to give free public early access at present. There are still a number of thing that need completing before we are ready for the world to see it. You should probably wait. I know that you have just started looking at interrupts and context switching. My experience is that this is the hardest part of getting this architecture working. ARM's view of how operating systems should work is somewhat at odds with how eCos works and the harware rather strictly enforces ARM's world view. It is unlikely that you will get your port running before we make our contribution. -- Nick Garnett eCos Kernel Architect eCosCentric Limited http://www.eCosCentric.com The eCos experts Barnwell House, Barnwell Drive, Cambridge, UK. Tel: +44 1223 245571 Registered in England and Wales: Reg No: 4422071 -- 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] eCosCentric Cortex-M port contribution 2008-10-08 11:13 ` Nick Garnett @ 2008-10-08 12:07 ` simon.kallweit 2008-10-08 14:33 ` Nick Garnett 0 siblings, 1 reply; 11+ messages in thread From: simon.kallweit @ 2008-10-08 12:07 UTC (permalink / raw) To: Nick Garnett; +Cc: ecos-discuss Nick Garnett wrote: >> Could you give us some more information about the issues? Also, are >> there plans to get the patches into the mainline GCC? >> > > Unfortunately the details are covered by various NDAs between us, > CodeSourcery and ARM. Once the problem is confirmed by ARM then I > expect CodeSourcery will update their release, and this will find its > way into the FSF sources at some point. In the meantime we are looking > at making a temporary fix for the toolchain that will go out with > 3.0. Although we will pre-release it when the Cortex-M contribution is > made. > Ok, I guess the issues you're talking about are not related to the silicon errata just release by STMicroelectronics, concerning some compilers generating incompatible code with all but the latest revisions of the STM32 processors? >>> All of this is in hand but not quite yet ready for contribution: the >>> toolchain work needs completing, and we want to get a few runs in on >>> the test farm to ensure there are no obvious problems before >>> contributing. >>> >>> I expect this to take a couple of weeks more. >>> >>> >> Now, that puts me in quite an akward situation, as I've been working >> on a community cortex-m3 port for almost a month now. I wonder if it >> is best to stop my efforts and wait for your contribution. As we just >> got the first prototypes of our new STM32 based design a few days ago, >> we really look forward to get ecos working on the boards, so I cannot >> really just sit here and wait for your release. Is there a possibility >> to get the current snapshot upfront so I can continue with development >> based on your port, and see if there is anything worth to be >> contributed from the community port? I'd rather put further efforts >> into your port, if it is the better base for the future. >> > > We don't want to give free public early access at present. There are > still a number of thing that need completing before we are ready for > the world to see it. > > You should probably wait. I know that you have just started looking at > interrupts and context switching. My experience is that this is the > hardest part of getting this architecture working. ARM's view of how > operating systems should work is somewhat at odds with how eCos works > and the harware rather strictly enforces ARM's world view. It is > unlikely that you will get your port running before we make our > contribution. > It occurred to me, now that I have been digging into the subject more deeply, that there are some issues concerning the design of the Cortex-M3 to match with ecos. I think I do understand the design of how a kernel should work under the Cortex-M3 architecture, but admittedly I don't quite see yet how to do that efficiently with ecos. Does your solution come with changes in the generic ecos kernel code, or did you manage to solve it all in the Cortex-M3 HAL? Of course, it might make more sense to just wait for you to release the port, but this puts us on hold for an uncertain amount of time, as you don't make a clear statement of when the release will be. So I think it would be great to start working with your port, as I guess it's pretty sure that even if I continue developing and get a working solution myself, it will be your port that ends up in the official ecos community repository. So my past and future work will be quite obsolete, despite the learning I did :( Is there anything we can do about that? Otherwise, I think I'll continue with my development, risking to throw it all away a few weeks from now. Best regards, Simon -- 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] eCosCentric Cortex-M port contribution 2008-10-08 12:07 ` simon.kallweit @ 2008-10-08 14:33 ` Nick Garnett 2008-10-10 6:56 ` simon.kallweit 0 siblings, 1 reply; 11+ messages in thread From: Nick Garnett @ 2008-10-08 14:33 UTC (permalink / raw) To: simon.kallweit; +Cc: ecos-discuss "simon.kallweit@intefo.ch" <simon.kallweit@intefo.ch> writes: > > Ok, I guess the issues you're talking about are not related to the > silicon errata just release by STMicroelectronics, concerning some > compilers generating incompatible code with all but the latest > revisions of the STM32 processors? No they are not. ST is annoyingly vague about exactly what the problems are in that erratum, but the description bears no relation to the issue we have. In any case, that erratum refers to medium-density devices while the part on the eval board is high-density. Of course I don't know what density device or revision you are using for your own hardware, but it is probably worth ensuring you get parts that avoid this issue. > It occurred to me, now that I have been digging into the subject more > deeply, that there are some issues concerning the design of the > Cortex-M3 to match with ecos. I think I do understand the design of > how a kernel should work under the Cortex-M3 architecture, but > admittedly I don't quite see yet how to do that efficiently with > ecos. Does your solution come with changes in the generic ecos kernel > code, or did you manage to solve it all in the Cortex-M3 HAL? It is all solved entirely in the Cortex-M HAL. Like you I initially thought that eCos would fit quite nicely. However, the priority mechanism, the strict enforcement of exception nesting and some other things mean that the obvious approach didn't work. You either ended up throwing a hard fault exception, or ended up with all interrupts masked. I believe my eventual solution is quite elegant, but it was won at the expense of some false starts. > Of course, it might make more sense to just wait for you to release > the port, but this puts us on hold for an uncertain amount of time, as > you don't make a clear statement of when the release will be. So I > think it would be great to start working with your port, as I guess > it's pretty sure that even if I continue developing and get a working > solution myself, it will be your port that ends up in the official > ecos community repository. So my past and future work will be quite > obsolete, despite the learning I did :( The exact release date depends on whether any serious problems are thrown up in testing and how quickly we can deal with the remaining toolchain issues. Everything you have learned so far will still be useful, so nothing has been wasted :-) -- Nick Garnett eCos Kernel Architect eCosCentric Limited http://www.eCosCentric.com The eCos experts Barnwell House, Barnwell Drive, Cambridge, UK. Tel: +44 1223 245571 Registered in England and Wales: Reg No: 4422071 -- 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] eCosCentric Cortex-M port contribution 2008-10-08 14:33 ` Nick Garnett @ 2008-10-10 6:56 ` simon.kallweit 0 siblings, 0 replies; 11+ messages in thread From: simon.kallweit @ 2008-10-10 6:56 UTC (permalink / raw) To: Nick Garnett; +Cc: ecos-discuss Nick Garnett wrote: > "simon.kallweit@intefo.ch" <simon.kallweit@intefo.ch> writes: > > >> Ok, I guess the issues you're talking about are not related to the >> silicon errata just release by STMicroelectronics, concerning some >> compilers generating incompatible code with all but the latest >> revisions of the STM32 processors? >> > > No they are not. ST is annoyingly vague about exactly what the > problems are in that erratum, but the description bears no relation to > the issue we have. In any case, that erratum refers to medium-density > devices while the part on the eval board is high-density. Of course I > don't know what density device or revision you are using for your > own hardware, but it is probably worth ensuring you get parts that > avoid this issue. > Yeah, our current designs are only based on high-density parts, so there should be no problem. What about the just released toolchain of Codesourcery, does it already fix the issues you're talking about? >> It occurred to me, now that I have been digging into the subject more >> deeply, that there are some issues concerning the design of the >> Cortex-M3 to match with ecos. I think I do understand the design of >> how a kernel should work under the Cortex-M3 architecture, but >> admittedly I don't quite see yet how to do that efficiently with >> ecos. Does your solution come with changes in the generic ecos kernel >> code, or did you manage to solve it all in the Cortex-M3 HAL? >> > > It is all solved entirely in the Cortex-M HAL. Like you I initially > thought that eCos would fit quite nicely. However, the priority > mechanism, the strict enforcement of exception nesting and some other > things mean that the obvious approach didn't work. You either ended up > throwing a hard fault exception, or ended up with all interrupts > masked. I believe my eventual solution is quite elegant, but it was > won at the expense of some false starts. > Yeah, my current implementation suffers from hard faults too :) and I guess this has to do exactly with what you told, enforcement of exception nesting. Anyway, would you give me some advice into what direction I have to go to fix the problems? I would really like to get this working, even if it's just for learning purposes. >> Of course, it might make more sense to just wait for you to release >> the port, but this puts us on hold for an uncertain amount of time, as >> you don't make a clear statement of when the release will be. So I >> think it would be great to start working with your port, as I guess >> it's pretty sure that even if I continue developing and get a working >> solution myself, it will be your port that ends up in the official >> ecos community repository. So my past and future work will be quite >> obsolete, despite the learning I did :( >> > > The exact release date depends on whether any serious problems are > thrown up in testing and how quickly we can deal with the remaining > toolchain issues. > I see, this of course is a very vague statement. > Everything you have learned so far will still be useful, so nothing > has been wasted :-) > That of course is true, I have learned a lot already. Anyway, I would have rather spend my time collaborating with you, working on a common solution instead of doing my own. Simon -- 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:[~2008-11-04 19:28 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2008-11-03 15:50 [ECOS] eCosCentric Cortex-M port contribution Nick Garnett 2008-11-04 18:30 ` simon.kallweit 2008-11-04 19:28 ` Nick Garnett 2008-11-04 20:46 ` Simon Kallweit 2008-11-04 21:43 ` Nick Garnett -- strict thread matches above, loose matches on Subject: below -- 2008-10-07 17:03 Nick Garnett 2008-10-08 6:37 ` Simon Kallweit 2008-10-08 11:13 ` Nick Garnett 2008-10-08 12:07 ` simon.kallweit 2008-10-08 14:33 ` Nick Garnett 2008-10-10 6:56 ` simon.kallweit
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).