9 years, 1 month ago.

Equivalent to Arduino millis()

Hi,

Arduino has the fairly convenient `millis()` function which returns the number of milliseconds since boot. What is the situation for that on mBed. As far as I can tell mBed has these:

• clock() - Returns number of CPU ticks, as defined by CLOCKS_PER_SEC. Unfortunately that is a) not constant, and b) not very fine-grained. For example on nRF51822 CLOCKS_PER_SEC is 100.

• time_t time(...) - Standard POSIX time call, but unfortunately this just returns 0 on boards without a real RTC.

• us_ticker_read() - This always returns microseconds since boot, and is required for mBed, but it has an ugly name and is an internal API.

• As mentioned in the answer below, you can make an instance of Timer, but a) you have to manually start it, b) it isn't global, c) the name of the instance isn't fixed, d) you have to put it in your own Globals.h header (or similar).

This seems like a sorry situation for mBed's otherwise great API. I would suggest adding some non-internal functions like this:

float clock_s() { return us_ticker_read() / 1000000.0f; }
uint64_t clock_ms() { return us_ticker_read() / 1000; }
uint64_t clock_us() { return us_ticker_read(); }

Who's with me? (By the way the name is a bit unfortunate - it could cause confusion with clock() - but I couldn't think of anything better.)

Solution

Ok I decided to implement those functions, and while I was at it I made them not overflow after an hour like all the existing mBed time functions do (us_ticker_read(), Timer, Ticker, etc.). This code should last thousands of years without overflowing.

It assumes that the internal microsecond ticker wraps at 32 bits, which I'm *fairly* sure is always the case.

Clock.h

#pragma once

#include <stdint.h>

// Return the number of seconds since boot.
float clock_s();

// Return the number of milliseconds since boot.
uint64_t clock_ms();

// Return the number of microseconds since boot.
uint64_t clock_us();

Clock.cpp

#include <mbed.h>

// The us ticker is a wrapping uint32_t. We insert interrupts at
// 0, 0x40000000, 0x8000000, and 0xC0000000, rather than just 0 or just 0xFFFFFFFF because there is
// code that calls interrupts that are "very soon" immediately and we don't
// want that. Also because if we only use 0 and 0x80000000 then there is a chance it would
// be considered to be in the past and executed immediately.

class ExtendedClock : public TimerEvent
{
public:
	ExtendedClock()
	{
		// This also starts the us ticker.
		insert(0x40000000);
	}

	float read()
	{
		return read_us() / 1000000.0f;
	}

	uint64_t read_ms()
	{
		return read_us() / 1000;
	}

	uint64_t read_us()
	{
		return mTriggers * 0x40000000ull + (ticker_read(_ticker_data) & 0x3FFFFFFF);
	}

private:
	void handler() override
	{
		++mTriggers;
		// If this is the first time we've been called (at 0x4...)
		// then mTriggers now equals 1 and we want to insert at 0x80000000.
		insert((mTriggers+1) * 0x40000000);
	}

	// The number of times the us_ticker has rolled over.
	uint32_t mTriggers = 0;
};

static ExtendedClock _GlobalClock;

// Return the number of seconds since boot.
float clock_s()
{
	return _GlobalClock.read();
}

// Return the number of milliseconds since boot.
uint64_t clock_ms()
{
	return _GlobalClock.read_ms();
}

// Return the number of microseconds since boot.
uint64_t clock_us()
{
	return _GlobalClock.read_us();
}

Edit: I updated it to use 4 timer inserts instead of 2 - some implementations (the good ones) execute events that are 'in the past' immediately, so there is a chance that insert(0x80000000) when we are at 0 will happen immediately. This fixes that.

Also, if you are using nRF51 there are some bugs in the us ticker implementation that cause this to crash. See this bug and the pull requests on it: https://github.com/ARMmbed/mbed-hal-nrf51822-mcu/issues/53