Looking for very low power SBC/SoM
 

Hi All,

I'm wondering if anyone can advise me whether a SBC/SoM with specs similar to the following exists?

I'm looking for a device which can be run from a battery for a long time, i.e., months to years. The device should be capable of hibernating most of the time, shutting everything off. It should be able to cold boot and wake from hibernate to full functionality within ~2s or so. The use case is an IoT device which can periodically read sensors, phone home, etc.

It would need:

* Linux capable micro, Arm Cortex-A series most likely.
* Modest RAM, 128-512MB.
* Moderate storage, 1GB or so, though with fast interface to allow quick hibernation and boot.
* Decent set of IO peripherals, multiple each of I2C, SPI, UARTs.
* USB (OTG preferably)
* Possibly on-board WiFi or Cellular options.

The obvious answer to this question is that I should be looking for a microcontroller based solution. I'm asking for this specifically because I've worked on products like this in the past and had a lot of trouble with the complexity required in developing the microC based solution. To be able to access proper battle-tested networking and USB stacks would be a huge win.

Thanks very much.
--Frampy

Maybe look at Raspberry Pi, lots of commercial business use them.

Look at ATMEL

I'll take a swing: if you want Linux on it, then one of the Pi's - RaspberryPi, BananaPi, OrangePi... You could look SlackwareARM's or OpenBSD's websites for a few examples of what they can run on.

If you want just a microcontroller board, then something along the lines of STM32, ESP32, Arduino...

There are so many, some use ARM and some use other. You're going to have to dig yourself for what meets your needs.

I'll follow up this post with a few links.

TKS

ESP32
https://www.espressif.com/

STM32
https://www.st.com/content/st_com/en.html
and more specfically
https://www.st.com/en/microcontrolle...rtex-mcus.html
https://www.st.com/en/microcontrolle...rtex-mpus.html
I just saw they have a Linux distribution

An ESP32 dev board I picked up to play around with:
https://www.banggood.com/ESP32-Devel...r_warehouse=CN

For just a few examples of what Slackware and OpenBSD have been run on and how to install them. Might be of some use, even if you install other OSs:
https://arm.slackware.com/slackwarearm-devel/
https://docs.slackware.com/ [ search "ARM" ]
https://cdn.openbsd.org/pub/OpenBSD/.../INSTALL.arm64
https://cdn.openbsd.org/pub/OpenBSD/.../INSTALL.armv7

https://conclusive.pl/devices/product/KSTR-SAMA5D27
https://www.acmesystems.it/roadrunner with the Berta D2 dev board.

Both based on the same chipset. I've been trying to get them working for my project. They're the lightest SBCs I've found, but still power hungry next to a uC. Battery-backed RTC which helps for long sleeps between sensor reads. Idle power consumption I'm seeing out of the box is around ~0.5W, I haven't measured sleep. Conclusive claims their idle power is a good bit lower than I measured but I haven't done any optimizations to test that.

The KSTR hangs on reboot out of the box, and I've had to mess with kernel config and DT a good bit just to get the USB host working for full speed (rather than high speed) devices. Conclusive quoted me a pretty significant sum to investigate the reboot issue.

Speed is the principal reason for high power.

I remember running a PIC µController @32.768khz to drive a clock and display. It comsumed 1mA and the whole circuit ran on batteries. Back in 2000, that was unconventional but effective.

If you don't need much speed or I/O, consider some low frequency options. I programmed my little thing in Assembler. I had a headache for a month, but then it got easy. It's amazing what you do when you're hard up.

EDIT: Just looking at post 1, you're overspeccing your hardware, and won't get the battery life. Maybe stick in a 12V 8AH sealed lead-acid battery, and you might. USB can be current expensive

This sounds like you don't need a full blown OS like on a RPI (which doesn't hibernate anyway I believe). Your over specifying what you need. Just something that allows you to read a few sensors, connect to another box to dump information, and go back to sleep. This seems like it could be handled by many small low power boards out there like mentioned about ESP32 or STM32 boards, maybe even the little $6 RPI Pico W board which I think supports deep sleep. Google for 'rp2040 deep sleep' for info. I am assuming it would need something like Wifi/cellular onboard to 'phone home'.

Go down with your spec: else you will need a lot of juice out of the battery.
Staggered system? low power system starting another system on-demand etc. = not the full board spec from the first boot on. Interesting board https://udamonic.com/what-is-a-scamp.html (however, similar to the previous proposal with assembler).

Looking for very low power SBC/SoM
 

I don't know of a single board computer or embedded hardware that will match all your requirements. I can suggest some saner options.

You probably will want to have a built in eMMC module as storage and to load the OS. You will not meet your low power requirements if you include USB. You should consider a board with some gpio pins to access the device over serial console while you develop it. The bootloader should be in SPI flash memory. A sd card is useful, but as I understand it, uses some significant power. Maybe lower the requirements of usb otg or usb ports to a single micro usb port.

Looking for very low power SBC/SoM
 

Additionally, build a busybox environment as your OS. Raspbian on a raspberry pi uses a lot of space and RAM for a project like this.

Don't underestimate the power savings invoolved in lowering the frequency. In 2000 I built a controller (for money) that drove a prototype display. The display was capacitive and slow. I was using a decent PIC *µController. I ran it at 32.768khz and programmed in Assembler, and it used 0.65mA.

That's how much you can save from slow frequency. I took the extra precaution of Assembler programming. You should stuff in a mobile phone battery. If you don't need cpu speed, don't supply it.