MAX32660 Evaluation Kit - part 4a: Low Power Sensor design - Barometer Hardware

When I submitted my proposals for the road tests, I promised this for the ROHM kit: "... I will try to get each of them working on a different microcontroller ...".

For the MAXIM road test, I wrote: "I will design an application that collects data from a sensor at regular times, collect that info, then share in bulk with a consuming device.

I will check how low the energy use is inbetween the measurements. I will also check how easy it is to wake up, what the possible wake-up triggers are.

I will check if it is easy or hard to work with the device’s peripherals.".

I had another controller in mind then - didn't know I would be selected for the MAXIM controller. That makes it extra interesting.

Big promises. I hope I make them true with this project.

Hardware Choices

Sensor:

I selected the ROHM BM1383AGLV Pressure Sensor. I want to build a device that collects data at a slow pace. Accelerometers and other sensors from the ROHM kit are targetting real time use.

But the pressure sensor is a good candidate for slow, time based, data collection.

And it supports 1.8 V, the same as what I'm running the MAX32660 on. Plus it has a "data ready" trigger pin.

Finally, I didn't review this sensor as part of the Rohm SensorShield-EVK-003 (Arduino Compatible) - Review, so I can do that in this post.

MAX32660 Pin Assignments:

I want to support a set of functions with as little interference to the MAX32660 evaluation board as possible.

The USB port of the EVK is linked to the contrllers's UART 1A. I should stay away from pins P0_10 and P0_11.

I want to keep the option open to use another UART to exchange data with an IOT edge device.

That - if it happens - is going to be UART 1B on P0_0 and P0_1.

Communication to the ROHM BM1383AGLV pressure sensor should go via I2C 0A, pins P0_8 and P0_9.

Maybe, if I can remove the crystal, I'll use a 2nd i2c as gateway to the edge device. i2c is more forgiving for jitter than UART.

Power Management:

I'd like to put the controller in an as deep as possible sleep between activation. A sleep mode I can recover from using the clocks.

During that time, I'd also like to deactivate the sensor's supply.

I'll have to check if I can source its power from a GIO pin.

It seems to be possible. THe MAX32660 can source 1 mA - the absolute maximum current draw for the sensor.

After wake-up, I should send commands to the sensor, then sleep again until it reports that data is ready on it's DRDY pin.

Staged Approach

I want to get the whole device working without power optimisation, but will keep all functionality isolated so that I can flex.

Then I'll try to introduce a clock based sleep.

After that I'll try to add an additional sleep between asking data and data ready.

Then I'll step it up and control the power to the sensor via the MAC32660.

Depending on how easy or difficult this is, it may be one or many blog posts.

Your help is welcome.