App note: Writing to flash and EEPROM on the tinyAVR 1-series


Update your tinyAVR code to access memories when using 1-series tinyAVRs. Link here (PDF)

On tinyAVR® 1-series devices, access to Flash memory and EEPROM has been changed from that on previous tinyAVR devices. This means that existing code for writing to Flash and EEPROM on older devices must be modified in order to function properly on tinyAVR 1-series devices. This application note describes what has changed and how to adapt code to these changes.

STM32F103 vs GD32F103


Sjaak wrote about a Chinese ARM chip compared to a ST ARM chip:

Most of us do know the ST line of ARM chips called STM32. They come in multiple flavours and the STM32F103 is one of the most common entry level family of chips. They are called by ST as mainstream. They are a full featured 32 bit ARM Cortex M3 chip running at max. 72MHz with all the requisite peripherals like ADC, DAC, USB, CAN, I2C, I2S, SPI, SDIO, PWM, RTC, interrupts and various timers. Lets zoom into the STM32F103C8 chip (which seems the be the go-to choice of the Chinese el-cheapo development breakout boards)

See the full post at

TWANG, an Arduino-based dungeon crawler


Bdring built his own Arduino-based 1D dungeon crawler inspired by Robin Baumgarten’s  Line Wobbler:

I have been a Patron of Robin Baumgarten for a while. He makes experimental hardware for games. His Line Wobbler one dimensional dungeon crawler is my favorite and I have always wanted to play it. It uses a door stop spring as the controller. An accelerometer in the knob allows it to work like a joystick and also detect the wobble used to attack the enemies.

More details at blog.

Yield function, printable class and mapping arrays: Useful but unknown features from Arduino core


Yahya Tawil over at Atadiat wrote a new tip for Arduino developers about three hidden and useful features in Arduino core:

Arduino core, the source code of Arduino API functions and classes, has three useful features that can be used effectively. As the Arduino core documentation doesn’t mention them (at least until the time of publishing this micro-blog), these features are not well-known for arduino developers. Let’s discuss each feature of them one by one.

More details at Atadiat blog.

Via the contact form.


Parsing a packet using structs

When I was analyzing the source code of an opensource software, I found an interesting technique to parse incoming data in a very efficient way, using a struct.

This technique works if the received data has a fixed length and structure; for example it applies very well to data “packets”.

When receiving, the program normally stores incoming data in a buffer in the RAM memory. For example let’s assume that the packet has a length of 14 bytes:

char rx_buffer[14];

Your specific protocol defines the following fields in the packet:

  • address, 5 bytes
  • temperature value, 3 bytes
  • humidity value, 3 bytes
  • TX counter, 1 bytes
  • checksum, 2 bytes

You can define a struct that represents the structure of the packet:

typedef struct {
  uint8_t address[5];
  uint8_t temperature[3];
  uint8_t humidity[3];
  uint8_t tx;
  uint8_t checksum[2];
} my_packet;

The technique consists in applying, as if it were a template, the struct to the buffer:


in this way the received bytes are automatically divided into the different fields:


Therefore, to parse the data you only need to cast the buffer:

my_packet* parsed_data = (my_packet*)rx_buffer;

and access the struct fields:


Padding and packed

You still have a problem: to make it more efficient to access the memory, compliers normally align the variables based on their size. This means that – when a compiler allocates memory for your struct – some empty space (named padding) could be added between the different variables:


The presence of the padding space causes a misalignment if you apply the struct to the buffer with the received data (which are instead continous). Fortunately, it is possible to ask the compiler not to insert padding using the packed attribute:

typedef struct {
  uint8_t address[5];
  uint8_t temperature[3];
  uint8_t humidity[3];
  uint8_t tx;
  uint8_t checksum[2];
}__attribute__((packed)) my_packet;

If you remember to add this attribute, the technique works perfectly!

A journey into Capcom’s CPS2 silicon – Part 2


Here’s an informative part 2 of the Capcom CPS2 reverse engineering series by Eduardo Cruz:

Capcom’s Play System 2, also known as CPS2, was a new arcade platform introduced in 1993 and a firm call on bootlegging. Featuring similar but improved specs to its predecessor CPS1, the system introduced a new security architecture that gave Capcom for the first time a piracy-free platform. A fact that remained true for its main commercial lifespan and that even prevented projects like Mame from gaining proper emulation of the system for years.

See the full post on the Arcade Hacker blog. Be sure to see Part 1 here.

Programming STM32F103 Blue Pill using USB bootloader and PlatformIO


Coyt Barringer wrote a post on his blog showing how he program the Blue Pill STM32F103 using USB Bootloader and PlatformIO:

This is the infamous Blue Pill board – a $2 ARM STM32F103 development board with all the capabilities of a Teensy 3.x at a fraction of the price of an Arduino. So what’s the catch?
I’ll tell you – software support.
A couple weeks ago I decided to invest some time learning this platform because I was sick of paying 20+ dollars for a Teensy. While the PJRC platforms are fantastic, they are expensive and need a proprietary boot loader in order to work. I want a small and powerful arm chip which I can integrate INTO my own PCBs and the Teensy does not easily or cheaply allow this. The Blue Pill and it’s derivatives appear to be just the thing I need!

See the full post at

Arduino Tutorial: Adding sensors to your data logger

Float configuration deploymnet on new housings

Edward Mallon writes:

This post isn’t another How-To tutorial for a specific sensor because the Arduino community has already produced a considerable number of resources like that.  You’d be hard pressed to find any sensor in the DIY market that doesn’t give you a dozen cookbook recipes to follow after a simple Google search. In fact, you get so many results from “How to use SensorX with Arduino” that beginners are overwhelmed because few of those tutorials help people decide which type of sensor suits their skill level. This post attempts to put the range of different options you can use with a Cave Pearl data logger into a conceptual framework, with links to examples that illustrate the ideas in text.

More details at