headers
Andrew Lunn | 1 Sep 2008 07:07
Picon

Re: Timeslicing on arm

On Sun, Aug 31, 2008 at 09:42:02PM +0200, Martin Hansen wrote:
> 2008/8/31 Andrew Lunn <andrew <at> lunn.ch>:
> > Thank about how mutex affect round robin scheduling....
> Does cyg_io_write implie an mutex on the thread?

I think so. 

Anyway, there are a couple possible explanations here. Use the bt and
threads commands in gdb to see where the threads are running/blocked.

Think about two threads:

thread1()
      for (;;) {
          mutex_lock(m);
          do_work()
          mutex_unlock(m);
      }

thread2()
      for (;;) {
          mutex_lock(m);
          do_other_work()
          mutex_unlock(m);
      }

thread1 starts first and will spend most of its time inside do_work(),
holding the mutex. If it runs without blocking until it has used its
timeslice, it will be descheduled. This is likely to happen inside
do_work, while still holding the mutex. thread 2 gets to run. It runs
(Continue reading)

Permalink | Reply | 1 comment |
headers
Marcos Del Puerto | 1 Sep 2008 11:13
Picon

Re: Looking in a future: VCS for eCos 3.0

Of course that eCos centric has to choose the VCS that best fits their
likes and requirements, but does eCos really need a distributed VCS? I
do not know how eCos is developed but I do not think there are eCos
development groups sparse around the globe who commit frecuently
changes? Has eCos centric outsourced parts of the development kernel
to other companies? Does eCos centric uses an Agile development
methodology where commits are performed several times a day by each
developer and they do not have access to Internet so they want to
commit locally and the merge all the changes we they get online? Do
they need perform diff operations with revisions other than the
checked out while working offline? Does eCos makes instensive use of
branching operations?

When Mark Shuttleworth talks about technical issues he must be simple
ignored or at least his post should have a advisory: developers don't
take this into account I really don't know what I'm talking about. At
the beginning you can find his posts funny even hilarious but they are
just that. For example using Ubuntu's 6 month release cycle for all
distros, or being optimistic about seeing KDE running on GTK, the bad
april month for ubuntu (you know, 150.000 bugs in ubuntu vs 5.000 in
debian) and now this a super ultra mega app killer whose main
advantage is that it renames files really fast.

Is that necessary for eCos? I mean how many files in the eCos kernel
have been renamed in the last years? And Bazaar is slow, very slow (I
need it quite often to fetch source code from launchpad among others).

One of the mayor Git problems is that it is still poor documented and
the tools for windows are still in early stages. Migrating for example
the Linux kernel from bitkeeper to Git when you have developed the VCS
(Continue reading)

Permalink | Reply | 5 comments |
headers
Robert Brusa | 1 Sep 2008 11:28
Picon

Re: Fwd: AT91SAM7X-EK with TC/IP - unresolved conflicts

On Fri, 29 Aug 2008 18:26:08 +0200, Andrew Lunn <andrew <at> lunn.ch> wrote:

...some old stuff removed...

> However, this is a pointless exercise. The AT91SAM7X only has 64K
> RAM. Getting the FreeBSD stack to work in that is probably impossible.
>
> Try the lwip_eth template. Then you will need to tune the lwip
> configuration.
>
>     Andrew

Not beeing able to use ethernet would be a serious blow to my planing. I  
intend to call a few routines on my target using RPC. This would allow me  
to implement a nice GUI on a PC and have the embedded software free of  
lengthy user I/F-code. Is RPC supported by ecos?

Back to the above exercise: When using ecosconfig, it seems to work, but  
when I call ecosconfig check, I get the following:
================ calling ecosconfig --verbose check
ecos.db, package CYGPKG_HAL_FR30_MB91360: warning
     This package is not present in the component repository.
     There is no directory `/opt/ecos/ecos-2.x/packages/hal/fr30/mb91360'.
ecos.db, package CYGPKG_HAL_FR30_MB91360_PHYTEC91F364G: warning
     This package is not present in the component repository.
     There is no directory  
`/opt/ecos/ecos-2.x/packages/hal/fr30/phytec91f364g'.
ecos.db, target phytec91f364g: warning
     This target refers to an unknown package `CYGPKG_HAL_FR30_MB91360'.
ecos.db, target phytec91f364g: warning
(Continue reading)

Permalink | Reply | 4 comments |
headers
Andrew Lunn | 1 Sep 2008 11:36
Picon

Re: Fwd: AT91SAM7X-EK with TC/IP - unresolved conflicts

On Mon, Sep 01, 2008 at 11:28:58AM +0200, Robert Brusa wrote:
> On Fri, 29 Aug 2008 18:26:08 +0200, Andrew Lunn <andrew <at> lunn.ch> wrote:
>
> ...some old stuff removed...
>
>> However, this is a pointless exercise. The AT91SAM7X only has 64K
>> RAM. Getting the FreeBSD stack to work in that is probably impossible.
>>
>> Try the lwip_eth template. Then you will need to tune the lwip
>> configuration.
>>
>>     Andrew
>
> Not beeing able to use ethernet would be a serious blow to my planing.

I never said that. I just said the FreeBSD stack will not work. The
lwip stack has been shown to work on the AT91SAM7X. Go google lwip.

> Is RPC supported by ecos?

RPC is too generic a word. Do you mean Suns RPC used by NFS, RFC 1057?
Do you mean XML-RPC like http://www.xmlrpc.com/. Do you mean COBRA?

Out of the box eCos supports none of these. However you could port
something or write your own RPC code.

> Back to the above exercise: When using ecosconfig, it seems to work, but  
> when I call ecosconfig check, I get the following:
> ================ calling ecosconfig --verbose check
> ecos.db, package CYGPKG_HAL_FR30_MB91360: warning
(Continue reading)

Permalink | Reply | 3 comments |
headers
Tim Hatton | 1 Sep 2008 11:40
Picon

Assert in at91rm9200_i2c.c


Hi all,
We've been developing an application on our own board which is based on the
AT91RM9200. The eCos config is closely based on that for the AT91RM9200-EK
and uses the I2C driver from that board to connect to an ADC (for monitoring
voltage, current, temp etc).

This basically appears to work fine but when I have eCos Asserts turned on I
very occasionally get the
following assertion:

ASSERT FAIL: <5>at91rm9200_i2c.c[101]at91rm9200_i2c_isr() I2C driver error:
OVRE without RXRDY

Could anybody give me some advice about what, from an application point of
view, could cause this sort of behaviour, or what sort of things I should be
thinking about?

Any assistance would be greatly appreciated,
regards,
Tim

PS: I am using version 2.0.43 of eCos.
-- 
View this message in context: http://www.nabble.com/Assert-in-at91rm9200_i2c.c-tp19251714p19251714.html
Sent from the Sourceware - ecos-discuss mailing list archive at Nabble.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
(Continue reading)

Permalink | Reply | 2 comments |
headers
Andrew Lunn | 1 Sep 2008 12:11
Picon

Re: Assert in at91rm9200_i2c.c

On Mon, Sep 01, 2008 at 02:40:20AM -0700, Tim Hatton wrote:
> 
> Hi all,
> We've been developing an application on our own board which is based on the
> AT91RM9200. The eCos config is closely based on that for the AT91RM9200-EK
> and uses the I2C driver from that board to connect to an ADC (for monitoring
> voltage, current, temp etc).
> 
> This basically appears to work fine but when I have eCos Asserts turned on I
> very occasionally get the
> following assertion:
> 
> ASSERT FAIL: <5>at91rm9200_i2c.c[101]at91rm9200_i2c_isr() I2C driver error:
> OVRE without RXRDY
> 
> Could anybody give me some advice about what, from an application point of
> view, could cause this sort of behaviour, or what sort of things I should be
> thinking about?
> 
> Any assistance would be greatly appreciated,
> regards,
> Tim

There is no i2c driver in the open source version of eCos, at least
none that i know of. I suspect you have the closed source code from
eCosCentric? That probably also means you have a support contract?  So
i would suggest making use of your support contract, you have payed
for it, and ask them....

    Andrew
(Continue reading)

Permalink | Reply | 1 comment |
headers
Tom Deconinck | 1 Sep 2008 13:12
Picon

Re: Assert in at91rm9200_i2c.c

On Mon, Sep 1, 2008 at 12:11 PM, Andrew Lunn <andrew <at> lunn.ch> wrote:
> On Mon, Sep 01, 2008 at 02:40:20AM -0700, Tim Hatton wrote:
>>
>> Hi all,
>> We've been developing an application on our own board which is based on the
>> AT91RM9200. The eCos config is closely based on that for the AT91RM9200-EK
>> and uses the I2C driver from that board to connect to an ADC (for monitoring
>> voltage, current, temp etc).
>>
>> This basically appears to work fine but when I have eCos Asserts turned on I
>> very occasionally get the
>> following assertion:
>>
>> ASSERT FAIL: <5>at91rm9200_i2c.c[101]at91rm9200_i2c_isr() I2C driver error:
>> OVRE without RXRDY
>>
>> Could anybody give me some advice about what, from an application point of
>> view, could cause this sort of behaviour, or what sort of things I should be
>> thinking about?
>>
>> Any assistance would be greatly appreciated,
>> regards,
>> Tim
>
> There is no i2c driver in the open source version of eCos, at least
> none that i know of. I suspect you have the closed source code from
> eCosCentric? That probably also means you have a support contract?  So
> i would suggest making use of your support contract, you have payed
> for it, and ask them....
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
simon.kallweit@intefo.ch | 1 Sep 2008 15:18
Picon

Cortex M3 architecture

Hello everyone

I'm planning on starting an initial effort to port eCos to the Cortex M3 
architecture, using the STM3210E-EVAL board as the initial target. After 
studying the current ARM architecture code, as well as some of it's 
variants and platforms, I wonder if the Cortex M3 should be implemented 
as a variant of the ARM architecture, or as a complete new architecture 
of it's own. I think I'd prefer to start a new architecture, as the M3 
differs quite a bit from the normal ARM architecture in terms of context 
switching as well as interrupt and exception handing. Also the M3 
exclusively runs Thumb2 instructions, so all the current assembler code 
using normal ARM instructions cannot be used. I think writing a new 
architecture saves us from introducing quite a mess in the current ARM 
architecture code. What do you think?

I wonder if the other Cortex variants (A8, A9, R4, M1) should be 
considered for porting from the beginning. My focus is clearly on the 
M3, but if anyone is willing to work on the other variants this should 
be considered now.

Also if anyone is interested to help, please inform me.

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
(Continue reading)

Permalink | Reply | 15 comments |
headers
Andrew Lunn | 1 Sep 2008 15:37
Picon

Re: Cortex M3 architecture

> I wonder if the other Cortex variants (A8, A9, R4, M1) should be  
> considered for porting from the beginning. My focus is clearly on the  
> M3, but if anyone is willing to work on the other variants this should  
> be considered now.

Have you seen any documents which compares/contrasts the different
Cortex variants. Before answering your question it is necessary to
know how similar/different the different variants are.

     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 | Reply | 14 comments |
headers
simon.kallweit@intefo.ch | 1 Sep 2008 15:47
Picon

Re: Cortex M3 architecture

Andrew Lunn wrote:
>> I wonder if the other Cortex variants (A8, A9, R4, M1) should be  
>> considered for porting from the beginning. My focus is clearly on the  
>> M3, but if anyone is willing to work on the other variants this should  
>> be considered now.
>>     
>
> Have you seen any documents which compares/contrasts the different
> Cortex variants. Before answering your question it is necessary to
> know how similar/different the different variants are.
>   

No I haven't really. All I know is that the variants all have very 
different application profiles. A series being mostly for complex OS and 
applications, R series for more complex embedded applications and the M 
series for deeply embedded applications. A & R also support normal Thumb 
and ARM instructions. Perhaps someone else can give some insight?

--

-- 
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 | Reply | 13 comments |

Gmane