ESP8266 Wi-Fi button – DIY Amazon dash button clone

p-wi-fi-button-thumbnail-jpg-600

Rui Santos over at Random Nerd Tutorials posted a step by step guide on building an ESP8266 Wi-Fi button:

In this project you’re going to build an ESP8266 Wi-Fi Button that can trigger any home automation event. This is like a remote control that you can take in your pocket or place anywhere that when pressed sends out an email. It can also be called a DIY Amazon Dash Button clone.

Check out the video after the break.

 

Yellowstone JTAG debugging

p-20180117_143337-600

A follow-up to the FPGA-based disk controller for Apple II post, Steve writes:

After a month of inactivity, I finally returned to my unfinished Yellowstone disk controller project to investigate the JTAG programming problems. Yellowstone is an FPGA-based disk controller card for the Apple II family, that aims to emulate a Liron disk controller or other models of vintage disk controller. It’s still a work in progress.
Last month I discovered some JTAG problems. With the Yellowstone card naked on my desk, and powered from an external 5V supply, JTAG programming works fine.

More details at Big Mess o’ Wires.

Xerox Alto’s 3 Mb/s Ethernet: Building a gateway with a BeagleBone

p-gateway-v2-600

Ken Shirriff documented his experience building a gateway using the BeagleBone single-board computer to communicate with the Alto’s Ethernet we covered previously:

I decided to build a gateway that would allow the Alto to communicate with a modern system. The gateway would communicate with the Alto using its obsolete 3Mb/s Ethernet, but could also communicate with the outside world. This would let us network boot the Alto, transfer files to and from the Alto and backup disks. I expected this project to take a few weeks, but it ended up taking a year.

See the full post at Ken Shirriff’s blog.

ESP32 (29) – Deep sleep

One of the major concerns for embedded devices is the power consumption. If the device you’re designing will be battery powered, it’s indeed important to reduce as much as possible its power consumption  to maximize the autonomy (= the working time before it’s necessary to replace or recharge the battery).

The esp32 chip offers 5 different power modes. The “normal” mode is named active mode; in this mode all the features of the chip are available. By starting to reduce the CPU speed and disabling some peripherals and cores, the chip switches to different power saving modes, as summarized in the following diagram:

sleep-001

In this first post about the esp32 power saving modes, I’ll explain the deep sleep mode.

Deep sleep

The esp-idf framework actually supports two power saving modes: light sleep and deep sleep. Between the two, the deep sleep mode is the one which offers greater energy savings. In this mode, are turned off:

  • both the CPUs
  • most of the RAM memory
  • all the peripherals

by default are instead kept active:

  • the RTC controller
  • the RTC peripherals, including the ULP coprocessor
  • the RTC memories (slowfast)

You can put the chip in deep sleep with the esp_deep_sleep_start() method, while it’s possible to wake up it via different events:

sleep-002

When the chip wakes up from deep sleep, a new boot sequence is performed. It’s therefore very important to understand that the execution of your program does not restart at the point where the esp_deep_sleep_start() method is called.

Let’s see how to configure and use two wake up events; in a future post I’ll write about touch pad and ULP.

Timer

The simplest wake up event is for sure the one which leverages a timer of the RTC controller. Thanks to the method:

esp_err_t esp_sleep_enable_timer_wakeup(uint64_t time_in_us)

you can wake up the esp32 chip after the specified number of milliseconds. The method must be called before entering the deep sleep mode:

// wakeup after 10 seconds
esp_sleep_enable_timer_wakeup(10000000);
esp_deep_sleep_start();

I/O triggers

In a previous post I’ve already blogged about the possibility to receive interrupts when a digital pin of the chip changes its status. We can leverage a similar functionality to wake up the chip from sleep.

With the method

esp_err_t esp_sleep_enable_ext0_wakeup(gpio_num_t gpio_num, int level)

you can enable the wake up if the specified pin (gpio_num) changes its status (level).

You can only use the pins with RTC function (0, 2, 4, 12-15, 25-27, 32-39) and the possible levels are 0 (= low) or 1 (high). If, for example, you want to wake up the chip from deep sleep if pin 4 has a low level, you’ll write:

esp_sleep_enable_ext0_wakeup(4, 0);

The framework also offers a method to monitor different pins:

esp_err_t esp_sleep_enable_ext1_wakeup(uint64_t mask, esp_sleep_ext1_wakeup_mode_t mode)

the pins (this method also accepts only the ones specified above) must be specified in a bitmask and  the wakeup modes are:

  • ESP_EXT1_WAKEUP_ALL_LOW = wakeup  when all the pins are low
  • ESP_EXT1_WAKEUP_ANY_HIGH = wakeup when at least one pin is high
When the chip wakes up from the sleep, the pins specified will be configured as RTC IO. To be able to use them again as normal digital pins, you have first to call the rtc_gpio_deinit(gpio_num) method. The ext0_wakeup method at the moment cannot be used together with touch pad or ULP events.

After the wake up…

If you configured more than one wake up event, you can know which specific event woke up the chip with:

esp_sleep_wakeup_cause_t esp_sleep_get_wakeup_cause()

The possible constants are:

sleep-003

For the ext1_wakeup event, a specific method is available to get the bitmask of the pins:

uint64_t esp_sleep_get_ext1_wakeup_status()

Memory

As explained above, in deep sleep mode the content of the RTC fast and RTC slow memories is preserved. You can therefore use those memory segments to store data that must be retained during the sleep.

To ask the compiler to store a variable in the RTC slow memory, you can use the RTC_DATA_ATTR attribute, or the RTC_RODATA_ATTR one if the variable is read only:

RTC_DATA_ATTR static time_t last;

Demo

I wrote a program (its source code is in my Github repository) to demonstrate the deep sleep mode and two different wake up events:

App note: Adding flexibility by using multiple footprints for I2C™ serial EEPROMs

an_microchip_an1418

Save PCB space by utilizing EEPROM SOIC-8 area, here’s an application note from Microchip. Link here (PDF)

For many years, the 8-lead SOIC package has been the most popular package for serial EEPROMs, but now smaller packages are becoming more commonplace. This offers a number of benefits; the reductions in footprint size and component height are some of the more obvious ones. Smaller packages also generally offer a cost advantage over their larger counterparts.

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

an_microchip_an1983

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

stm32vsgd32

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 smdprutser.nl.

TWANG, an Arduino-based dungeon crawler

20180111_130909-1-600

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 Buildlog.net blog.