18 comments

[ 4.0 ms ] story [ 49.4 ms ] thread
I'm curious to see the niche, if any, that this is able to carve out for itself. It's low on RAM, but might fit the same sort of profile as a Raspberry Pi W, even on price. That said, the RISC-V architecture will make things interesting--ARM cross-compilation is pretty well supported by most tiolchains now, even for older architectures. Should be interesting to see if that affects community interest, as I think onboard compilation of anything remotely complicated is probably going to be a no-go.
64MB used to be a lot of memory even for Linux. It is fine unless you're trying to run very bloaty software like web browsers. I wrote a fairly substantial embedded app for a 64MB ARM board running some forerunner of Angstrom Linux, in CPython, that used around 20 threads to talk to different peripherals. It wasn't terribly short on memory. It felt like a mini server. It ran Emacs just fine, and Emacs was once jokingly called "Eight Megabytes And Constantly Swapping" because 8MB was in those days huge. 64MB leaves plenty of space for it.

The Raspberry Pi W is overpowered because it's basically a media processor. It's not for what we usually think of as embedded apps.

The difference between the Linux and RTOS versions of this Pine board seems to be the amount of on-board flash. But given the built-in MicroSD slot, maybe that doesn't matter and you can run Linux on both.

I think theres a pretty good niche to be carved out here, the Raspberry Pi Pico is just too minimal to run Linux or another "full" operating system like it, which can give you several quality of life features for free especially networking related ones like DHCP/mDNS/etc... meanwhile the Raspberry Pi Zero family are all but impossible to get in stock to experiment with let alone rely on getting a hold of, its more powerful than you need for a lot of smaller applications. I've got one use where it was the only good choice but it always rubbed me the wrong way I was seeing such a big premium in getting a Zero W + shipping (locals never in stock) + time spent hunting, just to get USB-OTG to pretend to be a keyboard and have linux networking for 3-way network based auto-discovery service between the 3 devices I was building. The Ox64 can definitely be a very competitive new product in the "low end but not arduino" area, I wont be surprised if this quickly becomes one of the best supported devices Pine ever make once a lot of people have gotten their hands on it and started tinkering.
> which can give you several quality of life features for free especially networking related ones like DHCP/mDNS/etc > just to get USB-OTG to pretend to be a keyboard and have linux networking for 3-way network based auto-discovery service between the 3 devices I was building

The Ox64 and Pi Zero W have another advantage over the Pico: USB 2.0.

I had a somewhat similar use case, bridging a USB stream to a TCP connection. Unfortunately, the device I was using had a non-compliant HS (12Mbit) USB implementation and in the end it was just simpler to use an Orange Pi Zero than mess around with the Pico. However, Linux boot times are atrocious, in the 30 second range.

This is where the Ox64 might shine, having USB 2.0, but also running a (presumably) minimal RTOS with boot times far faster than Debian.

> However, Linux boot times are atrocious, in the 30 second range.

That's wrong. It takes time to optimize it but as long as you're willing to make the effort and don't have too much dependencies you can strip a lot of stuff to make it really quick e.g.: https://www.furkantokac.com/rpi3-fast-boot-less-than-2-secon...

Not sure if you can do this easily on OPIZ since it's a RPi clone it might be less open

I think there are a lot of new applications something like this can fill. Farmbots are a good example, requiring ML, cameras, low power operation, radio (lora would be better here, but you should be able to add it easily

https://lupyuen.github.io/articles/lora2).

The other thing to note here is that the bl808 is likely to be completely open, no binary blobs. To be this full featured in the cpu, npu, mcu, IO, and radio space for such a low price, and open source firmware is unheard of.

I can actually see many hobby OSes supporting a device like this as it's a single open target- driver support should not be an issue.

I am somewhat confused over the CPU design. Does anyone know what the reason or advantage is for having 2 different architecture processors running at different clock speeds in the same SOC sharing the same ram?

Was this an accident or did it serve a specific purpose?

I think it's for hi/low power switching- radio stacks and ML models can be shared, so you don't need to reinitialise them, and you can activate only the high power cpu when required.

Farmbots and wearables are a couple of applications that would match this pattern. Camera AI and radio but running on battery.

Interesting! I didn't consider power draw at all.

That is kind of weird as the whole system only draws (5v/0.5a = 2.5w) and I can't find anything that states that the power draw would radically alter for utilizing only 1 core.

At 2.5w a 10,000wh battery would run this non-stop for weeks.

Does anyone know if the two cores share memory? The datasheet and manual suggest the same memory map, but the block diagram suggests some kind of distinction between the two cores. Would be an interesting thing to target.
The other popular hobbyist board lineup with Zigbee is based on the nRF52840. Most of those boards are $20+, so it will be interesting to see what DIY low power IOT options this opens up at the $6 price point (if not perpetually out of stock).

Personally, I'm excited to build a Zigbee local-only garage door opener (my current one is a WiFi based Ratgdo), neophillia might finally motivate me to do it.

Does anyone know if this would be able to control a pair of relays on a network? I'm looking to control two electric heaters in my garage. I'd also like a pair of temp sensors. The hardest part of the project so far is the voltage to run a 240v relay is higher than the boards I've looked at can put out.

Any advice, or places I can go to for advice on projects like these would be appreciated.

Voltage or current? Either way, chaining relays (or maybe a transistor) would be the answer. I.e. use a 10mA output to run a transistor, providing the 250mA that the relay needs. Use a parametric search (like digikey, mouser) to find a relay with a low voltage coil and high voltage/current contacts.
It's probably both, I haven't checked the current requirements yet. I was originally planning to use a raspberry pi zero. the GPIO pins put out 5 or 9v, but the relays that handle 240v run on...I think it was 12v.
What about Solid State Relays? I think one of mine takes 5v-30v input and I switch mains with it.