Hi

I'm using uvision and I'm trying to find an accurate delay routine to be
used for microsecond delays.

I found the following file in the forum file area
http://f1.grp.yahoofs.com/v1/cFHQTwKGMwfhFULEHzRNBD2QyQNeF258SofnvrkUx8xyLwhR6naRC3y-hmNhng5R4mao10M40At4JVCPL8A_KnfahRaUevi5/delay.zip

The core function in that file is the following four clock delay routine



This code doesn't compile in uvision.
I searched the manuals and found that the inline directives are __inline
and __forceinline, I have used the second one.
Then according to the manual there is a __asm directive (asm gives
error) so the function became



This gives an error (#1113: Inline assembler not permitted when
generating Thumb code) in LPc13xx, 177x etc but I'm not using the thumb
mode.
Anyway , I have changed the function once more to



But now the error I get "error: A1137E: Unexpected characters at end of
line" and I can't get rid of it, I tried whatever I could think of but I
don't know much about asm.

I would be grateful if someone can provide a solution or another routine
that can be used for delay .
The alternative for me would be to use a loop in C but It wouldn't be
easy to predict the actual result.
Please note that I don't want to use the systick or a timer and
preferably I would want a routine that can work in ARM7, CortexM3 and
CortexM0

Thank you
Alex Start a New Thread

You are compiling for the Cortex microcontrollers, therefore you are always
using Thumb mode as the Cortex cores do not support ARM mode.

Cortex is NOT an ARM7.

Regards

Phil. Start a New Thread

I have used the assembler subroutine below on LPC chips in ARM mode
(sorry, no thumb). The complexity is due to the need to run from RAM,
and the calculation of the number of cycles from the wait time in us.

I edited out some parts that had to do with running only from RAM, I
hope I did not make (many) mistakes.

Note that this was part of a .s file, not embedded in C.





Wouter van Ooijen
-- -------
Van Ooijen Technische Informatica: www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: www.voti.nl/hvu
C++ on uC blog: http://www.voti.nl/erblog
Start a New Thread

As far as I know the M3 does support ARM-mode, however M0 does not.
However I'm not sure if ARM7 supports thumb. Start a New Thread

>As far as I know the M3 does support ARM-mode, however M0 does not.

Then you know it wrong.

No ARM mode is the price for the relatively small area (read: decrease in chip price) of the whole M-series ARM Cortexs.

JW Start a New Thread

On 07.06.2012 14:04, Kevin wrote:
> As far as I know the M3 does support ARM-mode...

No ARM, sorry:

http://www.arm.com/products/processors/cortex-m/cortex-m3.php

--

Timo Start a New Thread

Nevertheless, I fail to see why subs and bne wouldn't assemble in Thumb mode. Must be Keil limitation.

OTOH, for example the Cortex-M3 manual has this to say about the conditional branches:
Conditional B<cc> <label> 1 or 1 + P
where 1 is for branch not taken
and P is "The number of cycles required for a pipeline refill. This ranges from 1 to 3
depending on the alignment and width of the target instruction, and whether the
processor manages to speculate the address early."

Now in that cycle the branch will be taken most of the time, and the words "whether the processor manages to speculate the address early" sound to me just like "it's kind of a lottery".

What's wrong with a bunch of NOPs - provided by CMSIS as __NOP() intrinsics - anyway?

JW Start a New Thread

You are correct i looked it up and indeed no ARM-mode. I was mistaken with the LPC2468 which can use both ARM-mode and thumb-mode, however that chip is not an cortex. Start a New Thread

ARM7 did not support thumb mode.

ARM7T did ( that's what the T means ).

In reality the core most people used for ARM7 is the ARM7TDMI

Cortex are all THUMB derivatives, there are multiple versions of the thumb
architecture so M3 supports an extended instruction set compared to M0, but
NOT the ARM instruction set.

M0 is ARMv6-M ( document DDI0419C ), whereras M3 is ARMv7-M ( document
DDI403D )

Regards

Phil. Start a New Thread

> What's wrong with a bunch of NOPs - provided by CMSIS as __NOP() intrinsics - anyway?
>
> JW

NOP's can't be used, the datasheet of the lpc1766 has this to say about it (and I think it will hold true for most of M3 controllers):

NOP does nothing. NOP is not necessarily a time-consuming NOP. The processor might remove it from the pipeline before it reaches the execution stage. Start a New Thread