headers
Evgeniy Dushistov | 5 Feb 2009 14:39
Picon

at91sam9263ek support ver. beta 2

Hi,

here is updated version of series of patches to support at91sam9263ek.
I recieved and signed papers from fsf and I hope in near future they recive them.

High level changes:
- as discussed earlier, there is now arm7 package, and all variants of at91 use it,
and at91sam9 uses arm9
- there is now romram startup, so it is possible to program nor flash, press reset and you see
redboot message during next power on

Here is link to patches with description.

This patch introduces arm7 package, now all at91 variants are based on arm7 package.
So it is now possible to introduce another at91 variant based on arm9.
And hal_cache.h and so on stuff will be used from these package:

http://sites.google.com/site/duhistov/Home/0001-introduce-arm7-package-now-at91-variants-based-on-a.patch?attredirects=0

Change default delay in getting character via serial line method,
to correctly handle 115200 baudrate case:

http://sites.google.com/site/duhistov/Home/0002-change-default-delay-in-method-for-getting-character.patch?attredirects=0

This patch separate board's pio layout.
Extract each variant of pio's layout to separate header file:
http://sites.google.com/site/duhistov/Home/0003-This-patch-separate-board-s-pio-layout.patch?attredirects=0

Move common for arm9 code for work with mmu into common header (var_mmu.h):
http://sites.google.com/site/duhistov/Home/0004-move-common-for-arm9-code-for-work-with-mmu-into-com.patch?attredirects=0
(Continue reading)

Permalink | Reply | 0 comments |
headers
joseph biswal | 5 Feb 2009 17:33
Picon

Redboot based on Freescale PDK1.4

Is anyone working on the latest Redboot from (the Freescale PDK1.4
code) on the MX31 platform?
Please ping back if you are as i have a set of questions.

Thanks,
Munro.
Permalink | Reply | 0 comments |
headers
sd109 | 9 Feb 2009 20:47
Picon
Favicon

Changing tick interval - MIPS

I have a MIPS platform running ECOS v2.0. Default tick interval is 10ms. There are a few tasks at equal
priority, and time slicing is enabled (5 ticks). At 10ms tick interval, everything works fine. All equal
priority tasks get a chance to run.

I tried changing tick intervals by modifying CYGNUM_HAL_RTC_DENOMINATOR value.

First, i lowered the tick interval to 1ms. After this, i see only one task is running. None of the other tasks
are getting a chance to run. Then i changed tick interval to 5ms. Same result. It seems like context switch
is not happening.

Secondly, i increased the tick interval to 50ms and 100ms. And, the system hangs on boot up. Nothing runs.

As soon as i change the CYGNUM_HAL_RTC_DENOMINATOR value to 10ms (default), things get back to normal. I am
not sure why changing the tick interval has such a big impact on scheduling. The RTC interrupt on MIPS is
derived from count and compare register, which i would assume can handle 1ms or 5ms or 50ms durations. In
other words, i am not suspecting the RTC interrupt itself.

Any clues on why this is happening? The only value that i change is CYGNUM_HAL_RTC_DENOMINATOR. I do see
that CYGNUM_HAL_RTC_PERIOD changes based on the denominator value.

Are there any other dependencies to change tick interval? I wonder what is so special about the default 10ms
tick interval?

Thanks in advance.
Santosh
Permalink | Reply | 0 comments |
headers
Martin Laabs | 15 Feb 2009 19:13
Picon

How to handle very fast repeating interrupts?

Hi,

i'm using a lpx2214 board which is running with 60MHz.
Now I have an interrupt every 12us (so 80k per second.)
The Interrupt handler is very short. It has to read one
word from the external memeory interface and store it into a
buffer. This has to happen until the next interrupt will occure
because otherwise data would be lost.
Because it has to do so little but so often I'd like to
avoid the whole interrupt management/routing eCos implements.
I'd like to configure this interrupt as a FIQ and just want
to jump to my ISR routine. What do I have to pay attention
on when doing so?
I'd write the routine in ASM and store the register I use
to the stack. (Which stack will I use. The one of the current
process?)

When disabeling the "Use seperate stacks for interrupt ..." I
get the following trap. Do you have any idea?

0x00002810 in ?? ()
Loading section .sram, size 0x54 lma 0x40000540
Loading section .rom_vectors, size 0x40 lma 0x81010000
Loading section .text, size 0x14948 lma 0x81010040
Loading section .rodata, size 0x4544 lma 0x81024988
Loading section .data, size 0x718 lma 0x81028ecc
Start address 0x81010040, load size 103992
Transfer rate: 62066 bits/sec, 370 bytes/write.
(gdb) cont
Continuing.
(Continue reading)

Permalink | Reply | 6 comments |
headers
Chris Zimman | 15 Feb 2009 23:33
Favicon

RE: How to handle very fast repeating interrupts?

>  i'm using a lpx2214 board which is running with 60MHz.
> Now I have an interrupt every 12us (so 80k per second.)
> The Interrupt handler is very short. It has to read one
> word from the external memeory interface and store it into a
> buffer. This has to happen until the next interrupt will occure
> because otherwise data would be lost.
> Because it has to do so little but so often I'd like to
> avoid the whole interrupt management/routing eCos implements.
> I'd like to configure this interrupt as a FIQ and just want
> to jump to my ISR routine. What do I have to pay attention
> on when doing so?
> I'd write the routine in ASM and store the register I use
> to the stack. (Which stack will I use. The one of the current
> process?)

Not to get of topic, but are you running eCos w/o the scheduler?  Because if
you're not, I don't see how you are going to be able to keep up with the time
interval that you need.

Figuring 1.1 DMIPS/MHz, you have 0.015151515 us/instruction, giving you about
792 instructions per 12us interrupt period, without including any bus wait
states etc. or other losses in time.  Even one context switch from eCos for
whatever reason may cause you to lose data if you really do need to service
it every 12uS.

That said, I would suggest just pointing the FIQ vector directly, and
managing your own stack.  You could just carve out a piece of memory for
yourself (many ways to do this, depending on your application) and use that.

--Chris
(Continue reading)

Permalink | Reply | 5 comments |
headers
Martin Laabs | 16 Feb 2009 11:29
Picon

Re: How to handle very fast repeating interrupts?

Hello,

On Sun, 15 Feb 2009 23:33:55 +0100, Chris Zimman <czimman <at> bloomberg.com> wrote:

[Interrupt every 12us]

> Not to get of topic, but are you running eCos w/o the scheduler?  Because if
> you're not, I don't see how you are going to be able to keep up with the time
> interval that you need.

I use the scheduler...

> That said, I would suggest just pointing the FIQ vector directly, and
> managing your own stack.  You could just carve out a piece of memory for
> yourself (many ways to do this, depending on your application) and use that.

Yes - this was my idea too. Just beginnig a pice of assembler code at the
FIQ adress. (Even without a jump because it is at the end of the vector table)
Since the FIQ has 8 banked registers I fortunately do not even need a stack.

I'd like to place the ring-buffer into the fast onchip sram.
Can I just define some symbols in the linker script for that purpose? Or
can I tell the assembler to generate some symbols in a special section
like

.section ".sram_data"
_adc_buffer:
	.rept 64
	.long 0
	.endr
(Continue reading)

Permalink | Reply | 4 comments |
headers
Chris Zimman | 16 Feb 2009 13:08
Favicon

RE: How to handle very fast repeating interrupts?

> I use the scheduler...

Then I'm surprised you're able to maintain the RT requirement that you need,
because it seems as that any scheduling or kernel event alone may be enough
to break it.

> Yes - this was my idea too. Just beginnig a pice of assembler code at
> the FIQ address. (Even without a jump because it is at the end of the
vector
> table)  Since the FIQ has 8 banked registers I fortunately do not even need
a
> stack.

> I'd like to place the ring-buffer into the fast onchip sram.
> Can I just define some symbols in the linker script for that purpose?
> Or can I tell the assembler to generate some symbols in a special section
> like
> 
> .section ".sram_data"
> _adc_buffer:
> 	.rept 64
> 	.long 0
> 	.endr
> _adc_buffer_start:
> 	.long 0
> _adc_buffer_end:
> 	.long 0

You probably don't even need to do that unless you have other external code
that needs to deal with it.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Martin Laabs | 16 Feb 2009 13:32
Picon

Re: How to handle very fast repeating interrupts?

Hello,

On Mon, 16 Feb 2009 13:08:34 +0100, Chris Zimman <czimman <at> bloomberg.com> wrote:

>> I use the scheduler...
>
> Then I'm surprised you're able to maintain the RT requirement that you need,
> because it seems as that any scheduling or kernel event alone may be enough
> to break it.

Is the FIQ interrupt disabled while scheduling? (And if so - is it
disabled that long time?) I hope it isn't ...
The only RT requirement is to read the data from the memory bus
12us after the interrupt at the latest. The processing afterwards
can be done in non-RT.

>> I'd like to place the ring-buffer into the fast onchip sram.
>> Can I just define some symbols in the linker script for that purpose?
>> Or can I tell the assembler to generate some symbols in a special section
>> like
>>
>> .section ".sram_data"
>> _adc_buffer:
>> 	.rept 64
>> 	.long 0
>> 	.endr
>> _adc_buffer_start:
>> 	.long 0
>> _adc_buffer_end:
>> 	.long 0
(Continue reading)

Permalink | Reply | 2 comments |
headers
Chris Zimman | 16 Feb 2009 13:48
Favicon

RE: How to handle very fast repeating interrupts?

> Is the FIQ interrupt disabled while scheduling? (And if so - is it
> disabled that long time?) I hope it isn't ...
> The only RT requirement is to read the data from the memory bus
> 12us after the interrupt at the latest. The processing afterwards
> can be done in non-RT.

Interrupts have to be disabled while you're in an ISR, and since the
scheduler is typically driven from a timer interrupt, you are going to run
into that.
I would be concerned that the time it takes to schedule anything may
interfere with the RT window that you need to operate in.

Not being familiar with your project, I can't really say, but if I were to
design something that needed this level of RT performance, I would probably
use a faster processor or a small CPLD/FPGA to help with the data
acquisition.

> I'd like to read the data out of the buffer in a thread to filter and
> store it afterwards. So I need some sort of external accessable buffer.
> I imagine that the FIQ stores the data into a ring buffer and a normal
> eCos thread is going to read out and process the data which accumulated
> in the buffer since the last time.

That's fine -- this can work just the way you want it to.

> Do I really have to use the _fiq appendix for the registers in the FIQ?
> Anyway - this is very like I'd try it. But since a thread has to access
> the buffer I have to implement a ringbuffer. (Because it could be
> interrupted by the FIQ and this would overwrite the data in the buffer
and/or
(Continue reading)

Permalink | Reply | 1 comment |
headers
Martin Laabs | 16 Feb 2009 13:57
Picon

Re: How to handle very fast repeating interrupts?

Hi,

On Mon, 16 Feb 2009 13:48:22 +0100, Chris Zimman <czimman <at> bloomberg.com> wrote:

>> Is the FIQ interrupt disabled while scheduling? (And if so - is it
>> disabled that long time?) I hope it isn't ...
>> The only RT requirement is to read the data from the memory bus
>> 12us after the interrupt at the latest. The processing afterwards
>> can be done in non-RT.
>
> Interrupts have to be disabled while you're in an ISR, and since the
> scheduler is typically driven from a timer interrupt, you are going to run
> into that.

There is an option to allow nested interrupts. Since the FIQ priority
is higher than that of the timer (typical priority 0) it would interrupt
it.

> Not being familiar with your project, I can't really say, but if I were to
> design something that needed this level of RT performance, I would probably
> use a faster processor or a small CPLD/FPGA to help with the data
> acquisition.

There is a cpld already do deserialize the data. However - it has not enought
flipflops/macrocells to provide a buffer. (And no external or dualport memory.)

I will try the FIQ and nested interrupt aproach this evening and report the
results.

Greetings,
(Continue reading)

Permalink | Reply | 0 comments |

Gmane