Lpc2000

--- In lpc2000@yahoogroups.com, "jayasooriah" <jayasooriah@...> wrote:
>
> --- In lpc2000@yahoogroups.com, "John Heenan" <l10@> wrote:
> 
> > > It certainly dismisses the myth that one can disable interrupts 
> > while
> > > in 16-bit mode without interworking!
> > 
> > I was not aware of any such myths.
> 
> I was referring to the persistent request (to which your first post
> was a response) that my interrupts example can be extended to 16-bit
> mode without interworking.

I have not seen your examples. Please provide a link or message 
number. My posting was simply to provide examples of how inline ARM 
assembler could be called from Thumb through a function wrapper.

I get a daily digest of the list and may go for days without even 
opening it, let alone scanning it. When I do scan it I look for names 
that provide useful information.  Top of my list is Philips_apps and 
Tom Walsh. I generally do not scan past even the first few words in a 
subject line. The only reason I posted to this thread was because I 
scanned with amusement the words 'I give up' by Brendan Murphy and 
because I hope I can pay back those who have given up their time 
freely with something useful myself.

Like many I find vague and unsubstantiated accusatory information 
irritating, not because I find the people irritating but because I 
find having my time wasted by unnecessary drama irritating.

> 
> > Interrupts can be disabled without interworking on the LPC2xxx 
> > through the VIC registers while in Thumb mode. I have brief notes 
in 
> > preperation to be submitted as a file to the group.
> 
> Yes but there are costs.  The first (and prohibitive as I have 
argued)
> is that the implementation of VIC on the LPC family (based on PL190
> design) causes spurious interrupts to be generated when you do this.
> 
> The second (probably more insidious) is that the distinction between
> of user and system modes appear to have been lost in the process.
> 
> > As I said it is just standard code adapted to fit a simple idea, 
> > namely force industry standard ARM assembler code into a form 
> > suitable for Thumb through functions compiled for interworking.
> 
> The term "industry standard" cuts both ways -- see comment below :)
> 
> > Both ARM and Philips state a 
> > default handler must be assigned using the standard examples they 
> > provide that has been incorparated into the code.
> 
> The "default" handler in VIC (PL190) is to handle interrupts that 
are
> not vectored.  If all the interrupts are vectored, one does not need
> to dismiss interrupts through the default handler -- one can take a
> kernel panic when this happens as it indicates a system failure.
> 
> Philips requirement is different -- it a default interrupt handler 
is
> required to dismiss spurious interrupts generated by LPC 
peripherals.

Why the drama over a peripheral that can sensibly clear its own 
interrupt source?

I refused to buy into the 'interrupt debate' as I saw the debate as 
less illuminating and coherent than the information already 
available. An application note on spurious interrupts by Philips 
exapands on information provided by ARM and by Philips in all of 
their manuals.

Leaving aside the issue of IRQ and FIQ disablement, which is well 
discussed in the manuals and does not require use of a default 
handler, Philips clearly points out a default handler is required 
when the VIC may change state in the pipeline between the core 
latching an interrupt and between when the ISR address is read from 
the VIC. 

The application note provides two examples of the VIC changing state 
as above: one when code changes the VIC state through assignment to 
VICIntEnClr to feed the watchdog and another when a peripheral 
changes the VIC state without user code through a UART FIFO clearing 
an interrupt source. Clearly another way to change the VIC state in a 
way that may require a default handler is to clear an interrupt 
source with user code outside an interrupt while interrupts are 
enabled.

I don't feel there is a real problem. Setting up a default handler is 
trivial and good practice. It is not even necessary to update 
hardware priority logic through assignment to VicVectAddr if there 
are no real default interrupts to be handled. The handler can remain 
empty as the interrupt call will be reissued if the interrupt source 
is still present.


> > Point accepted. Saw THUMB_INTERWORK in another example and took a 
> > punt it was standard. I was wrong.
> 
> I like to make the distinction between "practice" and "standards". 
> This is what I meant by "cuts both ways" earlier :)
> 
> > It reflects my attitudes to macros and functions. I tend to make 
> > function names reflect what is really going on at the lower level 
and 
> > make them lower case. I tend to make macros names closer to the 
real 
> > intention of the macro is and in upper case. It is a practice 
that 
> > serves me well personally. I get a marriage of intention (macro 
name) 
> > with implementation (function name), all in a single line 
definition! 
> > 
> > However it is a practice I can be divorced from if is the 
democratic 
> > will!
> 
> My experience from having to look at historical code base, is that
> this is one of the biggest impediments to code life.  The next 
person
> has to not only understand and appreciate how the features of the
> language are used, but also understand new abstractions that 
sometimes
> obfuscate the original intent;
> 
> For example:
> 
>  SAVE_INTERRUPT_STATE;
> 
> and
> 
>  int mode;
> 
>  mode = getInterruptState()
> 
> say quite different things.  The latter can be understood by anyone
> with just the language semantics, but to understand the former, one
> has to include the mind set of the original programmer to discover 
how
> is the save achieved, where is it saved, and how does one restore 
the
> saved state, what happens when there are more than one saved state, 
etc.
> 
> I advocate the philosophy that one uses as much of what is there
> rather than creating new abstractions, and that a strong case be 
made
> each time a new abstraction is contemplated.
> 
> Programs express precisely what we cannot easily do as prose.  
Making
> program look like prose usually works against KISS rules.
> 

It is not fair to apply good practice rules of database and business 
rules programming (such as forms and reports programming) to hardware 
and embedded programmers. Business rules programmers uses highly 
abstracted tools that hide the horribly complex APIs. At some point 
abstraction breaks down, it has to, the real world is not an abstract 
entity. In this case it helps to know what functions are performing 
direct hardware tasks as opposed to functions which are deliberately 
abstractive.  For my own programming if a function performing 
hardware tasks need to be used by an abstract set of functions then I 
use a function pointer, as macros are unsitable at this level. 
Function pointers are not used by database and business rules 
programmers.

I don't think it is worth making a fuss about, I will probably accede 
because I have better things to do than have questions raised by 
theorists over how functions are named and to provide ammunition for 
backroom gossip and amusement. There can't be much wrong in the IT 
world if abstract naming is a central preoccupation!

> 
> > > I prefer to avoid having to name registers explicitly so as not 
to
> > > impose additional constraints on register optimisation.
> >  
> > I only named one register, r3, and specified it was clobbered. 
Since 
> > the register cannot be attached to an input or output variable 
and 
> > since I did not to troll through the horrific GAS assembler 
> > documentation to see if there was a qualifier to specify working 
> > registers r0-r3 or r12 only, I took the easy way out.
> 
> You are right in that there is no way to allocate a register that is
> not attached.  However I thought the method I originally proposed 
that
> does exactly the same overcomes this limitation.
> 
> > Inline code CANNOT get rid of the call and return bx instructions 
> > (bxl for Thumb also) as these instructions are the mode change 
> > instructions. Inline code expands TOTAL code size but does have 
the 
> > advantage of not refilling the fetch/decode/execute pipeline.
> 
> Not true.  The compiler is able to optimise prolog/epilog when it
> instantiates functions inline.  Have look at my original example
> carefully.

Please provide a link or message number.

You are not providing a complete picture. 

In my example the only epilogue was BX and there was no prologue. BX 
just does more than return, it also changes back to the Thumb state. 
While a large prologue and epilogue can be reduced (if not 
eliminated) and more optimisation can be performed if the code is 
inlined, if the same function is inlined many times then the overall 
code size is increased. People use Thumb to reduce code size.

Even if ARM code was inlined between Thumb code, the BX instruction 
is required to enter ARM state. Since BX is a branch instruction it 
will probably automatically refill the fetch/decode/execute pipeline 
(can be tested by BX to inline ARM/ARM or Thumb/Thumb) and will need 
to discard the current pipeline anyway due to how the current 
pipeline has been interpreted and has the wrong size of information.

I have reviewed the RealView assembler guide and discovered there are 
Thumb instructions for changing the interrupt state. They are CPSID 
and CPSIE. They cannot be used to change to ARM state inline and so 
avoid a branch penalty. However the instructions mean interrupts can 
be disabled and enabled without entering ARM state through 
interworking. 

However the principle of my example remains, which is how to allow 
inline ARM code to be used by Thumb code. The fact that the code was 
interrupt related code was irrelevant. it just happened to be 'on 
hand' and regrettably has drawn me into a debate I don't want to be a 
part of and started anoter debate I don't want to be a part of 
(abstract naming).

I am grateful for useful information when it is provided and am keen 
to provide useful information in return.

John Heenan

> 
> Regards,
> 
> Jaya
>