FW: rtems on nios2 collaborative efforts

[Sebastian Huber]

On 04/02/2012 11:58 PM, Hill, Jeffrey O wrote:
> Thanks for your response.
>
>> >  You should use printk() in this context.
> Sorry, meant to say printk, but somehow my dyslexia substituted vprintf:-)
>
>> >  I tried hard to configure everything at link or run-time time.  This keeps
>> >  the cpukit free from conditional compilation.
> And so I suspect that you wouldn't like to see the RTEMS build complicated by an NIOS2_IIC and NIOS2_EIC options. We could of course assert fail during initialization if they don't run the cpukit code on the correct type of CPU.

To keep the cpukit free from conditional compilation defined by BSP specific 
defines is not my policy.  This is a general RTEMS policy.  The aim is to 
provide a BSP independent cpukit as a library.

>
> (*** sorry I probably have already mentioned the idea in this paragraph ****)
> It seems that, if one is using the IIC, that it's a good idea to support prioritized dispatch of interrupts so that, for example, low order bits in the ipending/ienable register get handled first. Furthermore, I am drawn into the conclusion that to create an implementation consistent with RTEMS architecture then, when the IIC is in use, the interrupt level isn't set in the status register, but instead in the ienable register.

Yes, this probably makes sense with the IIC, but do you really need more than 
two interrupt levels (level 0 == interrupts enabled, level 1 == interrupts 
disabled)?

>
> I attached my current implementation of _CPU_ISR_Set/Get_level (which is based on a test of an _nios2HasExtInteruptController variable in RAM which should be similar maybe to the cost of another runtime option - a function jump table). Considering further, we could have both types of _CPU_ISR_Set/Get_level in the CPU kit and maybe choose which one in the BSP with a macro. I will have to look into how that might be configured.

Please avoid BSP specific defines in the cpukit.  The execution speed of the 
_CPU_ISR_Set/Get_level is not critical.

>
> Perhaps we are not overly concerned about the CPU overhead of _CPU_ISR_Set/Get_level because this is, in RTEMS, typically called only when we launch a thread. Certainly much less often compared to _CPU_ISR_ENABLE/DISABLE for example?

Yes, _CPU_ISR_ENABLE/DISABLE should be with a low overhead since it is used on 
many places in the kernel.  In

>
> One point which I am not certain about; in RTEMS architecture is the global interrupt enable separate and independent of the interrupt level? Perhaps the global interrupt enable is set by _CPU_ISR_ENABLE/DISABLE, only involves pie, but preserves otherwise the entire state of the status register. In contrast, perhaps _CPU_ISR_Set/Get_level manipulates only the interrupt level in the status register (but not PIE) if its EIC, and otherwise just touches ienable register if its IIC. Your thoughts? I could certainly change the implementation below so that it disables interrupts globally at the highest level (when it's IIC). Is this a per-cpu discretion in the RTEMS cpiukit?

The global interrupt enable and independent of the interrupt level map to the 
same architecture specific concept.  Many architectures have only two levels 
(enabled/disabled interrupts).  Other like the ARMv7-M or the Nios II with EIC 
have more levels.

>
> There is also the additional overhead that the ienable register becomes part of the context switch if its IIC, and the interrupt level is determined by the ienable register. Is that an unacceptable hit for the EIC? Maybe there is a way to hide this also in a macro configured by the BSP. Maybe there are two different context switch stubs in the CPU kit (selected by a macro in the bsp)?

To increase the context by four bytes is not a problem.

-- 
Sebastian Huber, embedded brains GmbH

Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany
Phone   : +49 89 18 90 80 79-6
Fax     : +49 89 18 90 80 79-9
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.