Hello,

has anyone already written a busy wait procedure for AVR or any other embedded processors?
I'm currently facing issues converting Arduino's calculation of time (millisecons/microseconds) to cpu cycles as they rely on compile time elimination of floating point calculation.

Kind regards
Simon Ameis

No, but I would search something published freely or having a fitting license like BSD and translate it to Pascal.

Look there for eample:
https://www.mikrocontroller.net/articles/AVR

There are lot of projects, the complicated part will be to find the license. But if you write soemthing inspired by existing code but do it yourself, imho will be OK.

Marc

In general I already know these documents; what I'm looking for is an implementation of a busy wait, not how to use it.
For C/C++ it's easy to get the code files. But I don't know where to get compiler built-in procedures for gcc or other language's compilers.

The algorithm itself isn't that complicated:
1. assume you know how fast the cpu is (e.g. 1 MHz, 12 MHz or what ever fixed value)
2. calculate cpu cycles for given time to wait: cycle count := time to wait / (1/(cpu speed in MHz))
3. call a loop with known cpu cycle usage

Point 1 a fixed cpu speed is assumed for ease and compile time optimization (in fact you always need to know the speed of the clock source as it can't be determined by the MCU).
For point 3 there is a very good explanation in German at http://www.avr-asm-tutorial.net/avr_de/zeitschleifen/index.html.

The wicked thing is the calculation of the cpu cycles. The C implementation uses floating point arithmetics wich is evaluated at compile time. It doesn't work with wait times which are calculated at runtime.

Simon Ameis wrote

In general I already know these documents; what I'm looking for is an implementation of a busy wait, not how to use it. For C/C++ it's easy to get the code files. But I don't know where to get compiler built-in procedures for gcc or other language's compilers.

If you want to write Pascal code and don not need nano seconds accuracy, you have no need to now compiler internals. Only use time values and the divider factors.

In cas of AVR you need to use the prescalers value, too. Look in the datasheet for the chip used, it has good information and code samples (although in C and Assembler).

There is normally a definition set in the Makefile or in the C-Code. And since you are building the firmware code you should now it's name.

sth. like

#define SYSTEM_CLOCK 16000000ULL

In Pascal this would be a constant:

const
  SYSTEM_CLOCK = 16000000;

This constant can well be used in any calculation.

Why not use calculated constants? The compiler can evaluate simple arithmetics at compile time:

const
  sclk = int(round(SYSTEM_CLOCK / 42));

The resulting number will be as close to the float value as possible.

There is a lot of useful information in avr-gcc code, once you can see past the peculiarities of C. See the implementation of avr-gcc's delay here: cvs.savannah.gnu.org/viewvc/avr-libc/include/util/delay.h and delay_basic.h in the same folder. Basically they use op codes with fixed cpu cycles to construct the inside of the loop and use compile time constants to calculate the number of iterations required for a delay. The focus of the code is to get accurate delays down to a few cpu cycles.

The Linux sleep system call provides a microsecond "busy" wait ,but only when used with root privilege .

-Michael

Christo Crause wrote

There is a lot of useful information in avr-gcc code, once you can see past the peculiarities of C.

I agrre, but normally I don't need such precision. If working in a millisecond range it's really overkill to use less than 100 nanosecond accuracy, me thinks.

Well, if writing hard realtime OS timing functions or precise measuring algorithms, that would be good.

See the implementation of avr-gcc's delay here: cvs.savannah.gnu.org/viewvc/avr-libc/include/util/delay.h and delay_basic.h in the same folder.

Thanks for the link.

Basically they use op codes with fixed cpu cycles to construct the inside of the loop and use compile time constants to calculate the number of iterations required for a delay. The focus of the code is to get accurate delays down to a few cpu cycles.

I've written some program parts in ARM Assembler, but generally I like to avoid using it because of portability.

Christo Crause wrote

The focus of the code is to get accurate delays down to a few cpu cycles.

This is impossible when running in any normal OS.(Of course you can run an fpc project "bare bone" without an OS),

-Michael

Which is generally the case on AVR. Those are 8 Bit µControllers having a 32 Bit core.

If there is any type of OS that would be mostly FreeRTOS (if that fits, not sure) or NutOS , µCOSII, or maybe even Contiki.

Haven't seen any type of minimalized Linux yet, although it could exist. Common ATmega controllers have 2 kB of RAM.

an fpc project "bare bone" without an OS),

Depends on the OS. E.g. in our microkernel based realtime OS you can run a process at realtime priority (thus avoiding the scheduler) and if you then avoid kernel calls by e.g. using an assembler loop you can wait eater accurately. And our OS runs normal applications as well (e.g. fpc :P ).

Regards,
Sven

I don't talk of FPC compiler internals but of gcc compiler internals. E.g. the C implementation uses a compiler specific procedure __builtin_avr_delay_cycles; I can't find a source to get known how it is inlined in the resulting assembler code.
Please see for reference:
https://gcc.gnu.org/onlinedocs/gcc-4.7.1/gcc/AVR-Built_002din-Functions.html

The same is true for Basic.

FPC doesn't support floating point on AVR; thus no floating point constants are allowed, even if they can be evaluated to an integer expression at compile time. FPC obviously first checks types and then does optimization on known types.

Thus only this code is valid on AVR:
const
  sclk = SYSTEM_CLOCK div 42;

The question isn't how to calculate this but how to fit it into a word boundary for function call without loosing required accuracy.

Michael Schnell wrote

The Linux sleep system call provides a microsecond "busy" wait ,but only when used with root privilege .

Nice to know, but I asked for an AVR implementation. Although I've seen a report describing an ARM emulation on AVR running Linux I don't think thats what is usefull for just delaying some milliseconds.

Well, this is the fpc mailing list ...
How about asking the gcc guys that question?

You could also easily fetch the gcc source code and 'grep' it.

$ cd gcc-src
$ grep -r * "_builtin_avr_delay_cycles"

And if that doesn't help, write a short C code snippet using that function and then call the compiler like this:

$ arm-gcc -nostdinc -c -S yoursnippet.c

That will leave the asm (.s or .S) file for you to look at.

OK, good to know.

The question isn't how to calculate this but how to fit it into a word boundary for function call without loosing required accuracy.

I don't understand. Fitting in a word boundary would be done using a compiler switch in code, IIRC "{$align 2}" or similar. If that's true for function implementations isn't clear, I cannot image it is. If you want to use Assembler code in Pascal there is documentation in the programmers manual, chapter 3.

I've now come up with the code below.

The main problem is, that FPC doesn't inline the procedure _delay_ms. Thus the calculation of the required ticks is done at runtime wich timing is merely unpredictable.

What must be done to get this procedure inlined?

The documentation isn't very extensive on this topic (size and recustion are mentioned).

{$DEFINE F_CPU_HZ :=12000000}
procedure delay_loop_1(__count: Byte); assembler;
label loop;
asm
  loop:
  dec __count
  brne loop
end;

procedure delay_loop_2(__count: Word); assembler;
label loop;
asm
loop:
sbiw __count,1
brne loop
end;

procedure _delay_ms(__ms: Word); inline;
type
  TLongWordRecord = record
  case Integer of
    1: (Value: Longword;);
    2: (low_word: Word; High_Word: Word;)
  end;
var
  ticks: TLongWordRecord;
  ticks_dword    : Longword absolute ticks.Value;
  ticks_word     : Word     absolute ticks.low_word;
  ticks_high_word: Word     absolute ticks.High_Word;
begin
  ticks_dword     := (F_CPU_HZ div 1000) * __ms;
  while ticks_high_word > 0 do
  begin
    delay_loop_2(high(Word)); // TODO: substract loop cycles
    dec(ticks_high_word);
  end;
  if ticks_word > $00FF then
    delay_loop_2(ticks_word)
  else
    delay_loop_1(lo(ticks_word));
end;

Here it does. Did you add {$inline on} ?

It probably doesn't if delay_loop_1 and delay_loop_2 are private procedures inside a unit referenced from another unit. Then _delay_ms would be a procedure referencing the static symbol table. Could that be what's going on?

Thanks for the hint! I've had declared delay_loop_1 and delay_loop_2 just inside the implementation section.

Maybe these points should be added to documentation for inlining?
- assembler procecedure currently can't be inlined (may change)
- all procedures called by the procedure and all types used by variables inside the procedure and must be visible at the calling point; this also disallows unit private types (but procedure local types are okay).

Simon Ameis wrote

Thanks for the hint! I've had declared delay_loop_1 and delay_loop_2 just inside the implementation section. Maybe these points should be added to documentation for inlining?

I am against documenting this:
- inline is only a hint to the compiler
- the exact rules are very subtile and might differ between platforms/abi
- the behaviour might change between different compiler versions So it is hard to document this precisely.

IMO the only proper solution is to implement delaying as compiler intrinsics as it is done by gcc as well.

Florian Klaempfl wrote

IMO the only proper solution is to implement delaying as compiler intrinsics as it is done by gcc as well.

Besides using a hardware timer on embedded platforms. Older µC like AVR do not have too much hardware timers, but modern ones normally have a lot.

Waiting in a loop is not the best way to delay when using multitasking. One will never know if the timing is disturbed by an interrupt. Or does the gcc implementation handle this case?

The topic of this discussion is how to do a delay loop on avr. Not if a delay loop is useful.

Would it be possible to issue a hint why a procedure can't be inlined at a specific call?
This could change with the compiler and the user knows what to change for inlining.

Where do I find documentation/examples on how to define a compiler intrinsic procedure?

Simon Ameis wrote

Would it be possible to issue a hint why a procedure can't be inlined at a specific call? This could change with the compiler and the user knows what to change for inlining.

The compiler tries to do this as debug info (-vd), see also fpc/compiler/ncal.pas:4007+. This is printed only at -vd level because it is not detailed enough.

Where do I find documentation/examples on how to define a compiler intrinsic procedure?

Good starting point are fpc/compiler/ninl.pas, fpc/compiler/ncginl.pas and tcgavr.g_concatcopy in fpc/compiler/cgcpu.pas.

But if you provide a good pseudo code description, how such a delay loop should look like (e.g. depending on avr type, delay count etc.) I can offer to implement it in the compiler as well.