(Cross-posting this across several communities in hopes of getting some discussion.)

I'm currently building some indoor climate sensors for my home. My idea is to have temperature, humidity, noise, light, VOC and CO2 readings at a relatively high frequency reporting to my MQTT server.

I am currently setting up some different temperature sensors, and I want to calibrate them (hopefully just a linear offset) and evaluate them on some metrics, such as sensor-to-sensor consistency and accuracy.

To calibrate and evaluate the accuracy, I would need a source of truth, and ideally I would also be able to cycle it through a range of realistic values for the given metric.

What are your strategies to tackling these things? Do you assume the sensors are already well-calibrated and don't bother with this? Do you have a dedicated reader for any sensor value you would want to calibrate?

Astrobe is a complete integrated embedded Oberon software rapid development system running.

Use it to develop reliable embedded software to run on the powerful Arm Cortex-M families of microcontrollers.

This includes RP2040 (Cortex-M0+) / RP2350 (Cortex-M33) devices from Raspberry Pi and Cortex-M0/M0+, M3, M4 and M7 devices from STMicroelectronics.

cross-posted from: https://lemmy.ml/post/19385436

link to crate : https://crates.io/crates/st7567_rs

cross-posted from: https://lemmy.world/post/11673921

I want to build my own portable E-Reader like a Tolino/Kindle in DIN-A5 format (I know there are similar projects, like the Open Book from joeycastillo, but I want to make my own just for fun). I'm considering using the Compute Module 4 from Raspberry Pi. That, at least according to my theories, would have the advantage of me not needing to create my own OS, and the availability of already existing EPUB/HTML (EPUB is essentially just HTML) & PDF parsers and UI libraries hopefully makes my life easier. I don't want to use a default Raspberry Pi, because I don't need all the ports and I want the size of the E-Reader to be not unnecessarily thick.

The modules I need/want:

• Micro SD Card Reader for internal Storage (or just using eMMC Storage, have not settled yet on that topic)
• SD Card Reader (large/normal sized SD Cards), with a snap-in/spring mechanism (like with Nintendo (3)DS cartridges)
• E-Paper Display (e.g. a waveshare)
• USB-C Port for charging the battery (and maybe, if possible also file transfer and if possible maybe also to connect to a docking station)
• Battery

What is your experience with the Compute Module (4) and do you have good resources for creating my own PCB extension module for the Compute Module you would like to share? Do you have constructive critique for my project idea?

I have an idea in mind, where I want to share "large" static amounts of data (at max 10mb). Are there NFC-"Tags" which can hold that amount of data, or even more (in the Gigabytes)? If so, which ones and do you have experience with them?

A micro Erlang VM for embedded devices like ESP32 and Raspberry Pico

cross-posted from: https://lemmy.ml/post/221845

This is arguably one of the most important archives of computer science and engineering information available. And 50 years of it is now free. Get out there and play while educating yourself on things you didn't know were ancient history!

When last I wrote about COROS I explored the EVQ component of it with a focus on the API and some of its underlying construction. In this post I will expand on that underlying construction giving reasons for some of the design decisions, as well as providing some example use cases for this.

With coroutines and their use cases at least reasonably well established, the event queue mechanism of COROS is introduced to tie them up into a convenient architecture.

The first piece of COROS explored was the coroutine system, but coroutines are not a well-understood facility in programming circles for some reason. This article builds up some use cases for coroutines and their application in preparation for the next major component of COROS.

The first in a series of articles that builds up a coroutine-based RTOS for use primarily in memory-constrained embedded systems. Future articles will expound on other pieces of the RTOS after which the full, production-ready source will be published under my usual choice of the WTFPL2 license.

Dynamic SRAM allocation is the device-killer …

… but it doesn't have to be.

This is probably meta, but I'd like to know what are the boards in the picture in the banner of the sublemmy?

Following-up to my post about LuatOS yesterday, this is the underlying RTOS that LuatOS builds upon. The English language site is not as complete and all-encompassing as the Chinese site, but it's more than enough to get a taste of the system and even put it to use.

One of the things that projects like LuatOS and RT-Thread highlight is that the days of China just consuming western technology are over. Homegrown software is rapidly spreading through the country's engineering world (RT-Thread is in a bewildering variety of products now!) and even homegrown hardware, down to home-grown ISAs like the XuanTie XT804 cores, is starting to supplant imports.

The future is looking decidedly interesting.

eLua as a project died. But from its ashes, and paired with the Chinese RT-Thread project, LuatOS has arisen.

Using this if you can't do Chinese will be a bit of a challenge, but it's not impossible.

Build your own 8-bit computer on a breadboard. 3 times Picture

Based on the CM/P Turbo Modula 2 this implements a re-engineered version to run in a 64K virtual machine on any platform. Small enough to fit on almost every micro-controller like AVR.