Monday, September 19, 2016

NodeMCU as provider of NTP date and time over serial port

I've boon looking for possibility to have current date and time on my Arduino projects. Arduino itself has limited resources and I would like to use them for the actual work. So I've decided to take NodeMCU with Lua language and use it to access date and time form the internet, format it in the way that meets my requirements and provide such result over serial port.

There are many different ways to access local date and time from the internet, but mostly those interfaces change over time and code using them has to be adopted. I was looking for something that would last for years without interaction form my side. That's why I've decided to use Network Time Protocol. There is only one catch: it's UTC time without date. It was not such a big deal, because there are lot of algorithms out there so I've just adopted one of them.

Now it's possible to obtain local date and time from NodeMCU over serial port and the whole thing is reliable and will last for many years without touching it :)

Here is the source code:

The whole implementation is dividend into small building blocks, putting them together will give you desired serial API. This is just short overview:

  • Date Format - calculates local date and time based on timestamp
  • WiFi Access  - simple facade for connecting to WiFi
  • NTP Time - obtains UTC timestamp form give NTP server
  • NTP Clock - keeps actual UTC timestamp and synchronizes it periodically with NTP server
  • Serial API - finally this one provides API for date and time

Date Format

Provides functionality to get local date and time from timestamp given in seconds since 1970.01.01

For such code:
collectgarbage() print("heap before", node.heap())

require "dateformat"
require "dateformatEurope"
local ts = 1463145687
df.setEuropeTime(ts, 3600) -- function requires GMT offset for your city

print(string.format("%04u-%02u-%02u %02u:%02u:%02d", 
    df.year, df.month,, df.hour, df.min, df.sec))
print("DayOfWeek: ", df.dayOfWeek)

collectgarbage() print("heap after", node.heap())

you will get this output:
heap before 44704
2016-05-13 15:21:27
DayOfWeek:  6
heap after  39280

In order to format date for USA you have to replace require "dateformatEurope" with require "dateformatAmerica" and call setAmericaTime instead of setEuropeTime. Functionality is divided into small scripts in order to save some RAM.

WiFi Access

It's simple facade for connecting to WiFi. You have to provide connection credentials and function that will be executed after the connection has been established.

execute(...) connects to WiFi and this can take some time. You can still call this method multiple times. In such case callbacks will be stored in the queue and executed after WiFi connection has been established.

require "wlan"

wlan.debug = true

local function printAbc() 

wlan.setup("free wlan", "12345678")

Configuring WiFi on:   free wlan
status  1
status  1
status  5
Got WiFi connection:

NTP Time

This simple facade connects to given NTP server, request UTC time from it and once response has been received it calls given callback function. 

Example below executes following chain: WiFi -> NTP -> Date Format. 
So in the fist step we are creating WLAN connection and registering callback function that will be executed after connection has been established. This callback function requests time from NTP server (ntp.requestTime). 
On the ntp object we are registering another function that will get called after NTP response has been received: printTime(ts).

collectgarbage() print("RAM init", node.heap())

require "wlan"
require "ntp"
require "dateformatEurope";

collectgarbage() print("RAM after require", node.heap())

ntp = NtpFactory:fromDefaultServer():withDebug()
wlan.debug = true

local function printTime(ts) 
    collectgarbage() print("RAM before printTime", node.heap())
    df.setEuropeTime(ts, 3600)
    print("NTP Local Time:", string.format("%04u-%02u-%02u %02u:%02u:%02d", 
        df.year, df.month,, df.hour, df.min, df.sec))
    print("Summer Time:", df.summerTime)
    print("Day of Week:", df.dayOfWeek)
    collectgarbage() print("RAM after printTime", node.heap())


wlan.setup("free wlan", "12345678")
wlan.execute(function() ntp:requestTime() end)

collectgarbage() print("RAM callbacks", node.heap())

and console output:
RAM init    43328
RAM after require   30920
Configuring WiFi on:   free wlan
RAM callbacks   30688
status  1
status  1
status  5
Got WiFi connection:
NTP request:
NTP request:
NTP response:   11:59:34
RAM before printTime    31120
NTP Local Time: 2016-07-12 13:59:34
Summer Time: 
Day of Week:    3
RAM after printTime 30928

NTP Clock

This script provides functionality to run a clock with precision of one second and to synchronise this clock every few hours with NTP server. 

In the code below we first configure WiFi access. Once the WiFi access has been established it will call ntpc.start(). This function will start clock that will get synchronized with given NTP server every minute. Now you can access actual UTC time in seconds over ntpc.current. In order to show that it's working we have registered timer that will call printTime() every second. This function reads current time as ntpc.current and prints it as local time. 

collectgarbage() print("RAM init", node.heap())

require "dateformatEurope";
require "ntpClock";
require "wlan";

collectgarbage() print("RAM after require", node.heap())

ntpc.debug = true
wlan.debug = true

wlan.setup("free wlan", "12345678")
wlan.execute(function() ntpc.start("", 60) end)

local function printTime() 
    collectgarbage() print("RAM in printTime", node.heap())
    df.setEuropeTime(ntpc.current, 3600)
    print("Time:", string.format("%04u-%02u-%02u %02u:%02u:%02d", 
        df.year, df.month,, df.hour, df.min, df.sec))
    print("Summer Time:", df.summerTime)
    print("Day of Week:", df.dayOfWeek)

tmr.alarm(2, 30000, tmr.ALARM_AUTO, printTime)

so this is the output:
RAM init    43784
RAM after require   29408
Configuring WiFi on:    free wlan
status  1
status  5
Got WiFi connection:

NTP request:
NTP request:
NTP response:   17:09:46

RAM in printTime    29664
Time:   2016-08-08 19:10:08
Summer Time:    true
Day of Week:    2

RAM in printTime    29808
Time:   2016-08-08 19:10:38
Summer Time:    true
Day of Week:    2

NTP request:
NTP request:
NTP response:   17:10:46

RAM in printTime    29680
Time:   2016-08-08 19:11:08
Summer Time:    true
Day of Week:    2

RAM in printTime    29808
Time:   2016-08-08 19:11:38
Summer Time:    true
Day of Week:    2

NTP request:
NTP request:
NTP response:   17:11:46

RAM in printTime    29680
Time:   2016-08-08 19:12:08
Summer Time:    true
Day of Week:    2

RAM in printTime    29808
Time:   2016-08-08 19:12:38
Summer Time:    true
Day of Week:    2

Serial API

Serial API exposes simple interface that provides access to diagnostic info and date so that it can be accessed outside NodeMCU - for example by Arduino.

Serial API is divided into few Lua scripts. Loading of each script will automatically add new API commands:
- serialAPI.lua - has to be always loaded. It initializes serial interface with few diagnostics commands.
- serialAPIClock.lua - access to clock including date formatter.

Each script above registers set of commands as keys of scmd table - inside of each script you will find further documentation.

Example below provides date access over serial port:

require "credentials"
require "serialAPI"
require "serialAPIClock"

ntpc.syncPeriodSec = 900 -- 15 min
sapi.baud = 115200

-- setup wlan required by NTP clock
wlan.setup("free wlan", "12345678")

-- start serial API by enabling gpio and uart

-- start NTP synchronization

Here are few Serial API commands and their responses:
# free ram

# WiFi status

# date and time (24h) in format: yyyy-mm-dd HHLmm:ss
2016-09-16 10:45:25

# date in format: yyyy-mm-dd


Executing multiple scripts can lead to out of memory issues on NodeMCU. One possibility to solve it is to build custom firmware containing only minimal set of node-mcu modules: cjson, file, gpio, net, node, tmr, uart, wifi. This blog provides detailed upgrade procedure:

Wednesday, August 17, 2016

Upgrading NodeMCU Firmware to v1.5 on EPS8266 (ESP-12E)

I've been updating firmware on my NodeMCU few times without issues - at least up to 0.9
The installation procedure has changed with SDK 1.5 - I've spent few hours before I got it right, so maybe this post will help you to save some time.

Here you will find all required information, but depending on your chip manufacturer you will need different combination of some options, and this is exactly the part when it's getting a bit tricky.

Since things are changing rapidly, I will point out exact versions in this tutorial, so that it's clear what was working with what at time of this writing.

Installing esptool

Download esptool v1.1 and unzip it.
This will give you possibility to execute form command line - we will use it below.

Determining version of your ESP8266 chip

As usual there are different versions, and probably you will have to modify flashing commands if you have different one.
sudo python -p /dev/tty.wchusbserial1410 flash_id v1.2-dev
Manufacturer: e0
Device: 4016

Well it's obviously ESP-12E with 4MB flash:

How do you tell? I've no idea - just google for "Manufacturer: e0 Device: 4016" and check what people are thinking.

Building custom firmware 

Now we have to obtain firmware containing Lua interpreter for our chip - it's everything that you will need in order to upload Lua scripts over serial. 

Basically you will need two binary files: 
  • custom firmware - something like: nodemcu-dev-7-modules-2016-08-10-10-43-59-integer.bin
  • initial-data-block (esp_init_data_default.bin)
Obviously you will need matching versions. 

There are two options to get those files: 
  • you can download it from my github repo - this will give you SDK
  • you can also use cloud service to build latest release. The link to latest initial-data-block can be found here - just search for esp_init_data_default.bin
I would prefer a latest version - as usual. But in case of some problems you can try using version provided on my github repo. At least this one was working in my case with ESP-12E, this might help you to locale a problem.

Erase flash

Put your chip into flash mode as described here. If you have development board it should have two buttons: flash and reset. In such case press flash and without releasing it press reset, after that release reset.

Now you have to determine com port, and change it in all commands in this tutorial. In my case it's: /dev/tty.wchusbserial1410

Let's finally erase flash!
sudo python -p /dev/tty.wchusbserial1410 erase_flash v1.1
Erasing flash (this may take a while)...

Now disconnect ESP from usb port, so that it can fully reset - pressing reset button does not have the same effect !

Flashing new firmware

Put your chip again into flash mode.
I am assuming that you have in you current directory two binary files: one with firmware (nodemcu-dev-7-modules-2016-08-10-10-43-59-integer.bin) and second with init-stuff (esp_init_data_default.bin).
sudo python -p /dev/tty.wchusbserial1410 write_flash -fm dio -fs 32m 0x000000 nodemcu-master-7-modules-2016-08-10-10-45-03-integer.bin 0x3fc000  esp_init_data_default.bin v1.1
Running Cesanta flasher stub...
Flash params set to 0x0240
Writing 385024 @ 0x0... 385024 (100 %)
Wrote 385024 bytes at 0x0 in 33.4 seconds (92.2 kbit/s)...
Writing 4096 @ 0x3fc000... 4096 (100 %)
Wrote 4096 bytes at 0x3fc000 in 0.4 seconds (80.0 kbit/s)...


I've used ESPlorer, and it looks just fine.

Thursday, May 12, 2016

TS 555 timer with trigger network

I wanted to pimp my son's bobby car by installing few lights, they should go on for a few minutes once he starts moving the car. For this I've installed few LEDs and an micro switch attached to rear axle. So that the micro switch will get triggered from time to time.

Connecting LEDs was quiet simple, but I had some difficulties to build circuit that will enable the lights for few minutes. I've decided to use 555 timer - there are plenty of examples out there how to assemble it. I just wanted one, that will be energy efficient on stand by, and the lights should always go off after few minutes. This was not so easy, because you have to trigger the 555 by short impulse, otherwise it will never go off. My solution with micro switch has this one catch, that it can remain shorted for very long time. I've could ask my son to keep pushing the car until he hears the second click..... instead I've used a trigger network.

On the end I had to find right values for all components in the way that it will guarantee the functionality and ensure low power consumption to not to drain batteries over few days. Actually I did not calculate those values, I've just used oscilloscope to make sure that timing on 555 pins is right. Probably I've got not a perfect values, but on the other hand side it does what is suppose to be doing and it runs on single battery for months :)

Here is the Fritzing drawing.

Thursday, February 4, 2016

Arduino LED Display

My latest project ( contains driver for 8x8 LED Modules controlled via MAX722xx. It allows you to build display of custom size that is only limited by the hardware itself. Vertical and horizontal size can contain up to 256 modules, but before reaching this limit you would run out of Slave Select lines for controlling MAX chips, or you would be limited by amount of RAM. The fact is: you can control reasonable amount of MAX chips and build display of custom size ;)

I've tested the whole idea on display that consist of 8 LED Modules in horizontal and 3 in vertical position. This gives us 24 modules which are containing 1536 LEDs (88 * 38).


First let's start with the controller, actually any Arduino will work, I've used Mega due to large number of digital output pins. You could also use Nano with shift register and alter way of addressing Select Slave lines in Display::send(...).

You will need extra power supply for driving LEDs - assuming that you are going to use more than one LED Matrix.

Driving single LED Matrix Module

I've used the MAX7219 and 788BS LED Matrix, this is the one with common anode. The schematic below illustrates wiring of LEDs, MAX and Arduino:

 This one is equivalent, but instead of single LEDs we have PIN layout of LED Module:
It might happen, that your LED Module has common cathode, in this case you have to rewire connection to MAX chip. You just have to keep in mind, that MAX hat two sets of pins, that are relevant here: Dig0-Dig7 are supposed to be connected to cathodes (-) and SegA-SegG to anodes(+). Additionally such change will swap rows with columns within sine LED module.

Connecting all LED Matrix together

In the previous chapter we've seen how to connect single LED Module with MAX chip. Now we will connect multiple LED Modules together into one large display. Below is the physical display that I've used for testing and examples. Each LED Module has label indicating its position and Select Slave line.
Here is the wiring (and image below in original size

Each 3-PIN connector on schematic above symbolizes one module described in previous chapter (LED Matrix + MAX72xx), now we've connected all those modules together.

All MAX722xx chips share common MOSI and SCK lines, MISO is not used, each chip occupies separate Slave Select line.

The position of LED Matrix on the schematic above directly corresponds to their location on the physical display that I've used for testing. Additionally each module has description indicating it's position and Select Slave line, so for example: (2,1) SS: 35 gives us second module on third row (counting from zero) and PIN:35 on Arduino for Select Slave line.





We are using standard Arduino libraries, so they are already available, the only exception is ArdLog. You have to import this LIB into your IDE. This basically means, that you have to download right release: and unzip it into folder, where you usually place external libraries. In case of standard Arduino IDE on Mac it's ~/Documents/Arduino/libraries. On the end you should have following structure:

$ pwd

$ ls
ArdLog.cpp ArdLog.h   LICENSE


Communication with MAX72xxx

We are using standard SPI library and Select Slave line on MAX chip for addressing. MAX is configured in LED Matrix mode - so there is nothing special. The setup method can be found in: Display::setup()


Setting things up

The main class of our interest will be the Display - it's responsible for setup of MAX chips and provides API for painting.
Before we start painting it's necessary to set thing up. Code below creates 2D array containing Select Slave lines and initializes display. The display itself consist of 3 rows, each one has 8 LED Modules. Obviously you can choose any responsible size, but I will stick to this one.

The layout of mentioned 2D array corresponds to physical display: each LED Module has dedicated MAX chip, and each chip has dedicated Select Slave line. First dimension of our array indicates physical row on display, second dimension indicates LED Module within this row, and the value itself contains PIN number for Select Slave line.

#include <Display.h>

Display *disp;

 * Orientation of LED Kits (8x8 LED matrix) on display that I've used for testing.
 * The numbers are indicating Select Slave line of MAX7219.
 * 48, 46, 49, 47, 45, 43, 41, 39
 * 36, 34, 32, 30, 28, 26, 24, 22
 * 37, 35, 33, 31, 29, 27, 25, 23
ss_t **ss;

ss_t** createSS() {
  ss_t **ss = alloc2DArray8(3, 8);

  // first row
  ss[0][0] = 48;
  ss[0][1] = 46;
  ss[0][2] = 49;
  ss[0][3] = 47;
  ss[0][4] = 45;
  ss[0][5] = 43;
  ss[0][6] = 41;
  ss[0][7] = 39;

  // second row
  ss[1][0] = 36;
  ss[1][1] = 34;
  ss[1][2] = 32;
  ss[1][3] = 30;
  ss[1][4] = 28;
  ss[1][5] = 26;
  ss[1][6] = 24;
  ss[1][7] = 22;

  // third row
  ss[2][0] = 37;
  ss[2][1] = 35;
  ss[2][2] = 33;
  ss[2][3] = 31;
  ss[2][4] = 29;
  ss[2][5] = 27;
  ss[2][6] = 25;
  ss[2][7] = 23;

  return ss;

void setup() {

  ss = createSS();

  // Test display consist of 8x3 LED Modules (3 rows, each one 8 Modules)
  disp = new Display(8, 3, ss);

There is one more method worth mentioning: log_setup(). Whole project has quiet precise logger - so that you can see what is actually happening. By default it's disabled, in order to enable it check out its documentation:


Painting on the display 

Display consists of a few LED Modules, but form API perspective they are connected together into one continuous canvas. You can place on this canvas bitmap on any position given by such coordinates:

 (0,0) -----------------------------> (x)
      |                            (x max, y max)
      v (y)

The paint method has following syntax: paint(pixel_t x, pixel_t y, pixel_t width, pixel_t height, uint8_t data).

It allows you to paint a bitmap on given coordinates with limited width and height. So you can for example paint a bitmap on (3,4) that has 25x3 pixels. It might be larger than a actual display size - in this case it will get trimmed.

This is obvious and simple, but there is one catch - you have to provide right data. This is 2D array, where first dimension indicates vertical and second horizontal position on the display. Technically speaking data is flat array of pointers and each pointer points to array that represents one horizontal line on the display.

Moving over first dimension of data traverses over lines of the display. The second dimension of data represents horizontal pixels within single line, where each byte represents 8 pixels. Since our display consist of simple LEDs they can be either in on or off state, so each pixel is not being represented by one byte, but by one bit. In order to cover 16 pixels in horizontal position we need two bytes, 24 pixels require 3 bytes, and so on.
For example to fully cover display consisting of 8x3 LED kits (one used in our examples) we would need data[3][8]. Usually you will take array small enough to fit your bitmap and not one that will cover up whole display.

The paint(...) method updates internal buffer, in order to send content of this buffer to MAX chips you have to call flush(). The idea behind is to give you possibility to display few bitmaps on the display and after that paint the result. You can program few independent routines, that will update different part of the display and flush all changes at once.

Communication with MAX chips is not very fast and sending content of the whole display with every flush() is time consuming. You might be able to speed up this process by enabling double buffering (set DEOUBLE_BUFFER in Display.h to true). In this case flush() method will send only bytes that have changed, so you can call flush() with every loop and do not have to worry about loosing performance. The only drawback is increased usage of RAM: we are creating 2D array that allocates 8 bytes per each LED Kit plus few pointers that are usually required to maintain arrays.

2D arrays in this project have reduced memory footprint, because in order to create dynamic 2D array, we are creating actually 2 arrays with calculated offset (see: alloc2DArray8(....) in Util.h).


Requires Libs

Examples are using ArdLog, so you have to import this lib into Arduino IDE. Here are instructions:


Simple Bitmap 

In this example we will display simple static bitmap with 8x8 pixels:
Here is the Arduino sketch: SimpleBitmap, now lest go over it:

First we have to initialize display, as we have done in above in chapter Setting things up. Next we have to create data that can hold our bitmap - it will have 8x2 bytes. This gives us up to 8 lines and 16 horizontal pixels. But the size of our bitmap is 9x8 pixels (width x height) and this will be also the size of the painted rectangle. It should be as small as possible, so that you could place another bitmap right next to it.

The display will obviously only paint the rectangle given by width/height and not whole data array. This is normal, that data array can hold more pixels than accrual size of out bitmap, because size of data is a multiplication o 8 and bitmap not necessary.

void setup() {

  ss = createSS();

  disp = new Display(8, 3, ss);

  data = alloc2DArray8(8, 2);
  data[0][0] = B01100001; data[0][1] = B10000000;
  data[1][0] = B01100001; data[1][1] = B10000000;
  data[2][0] = B01100001; data[2][1] = B10000000;
  data[3][0] = B01100001; data[3][1] = B10000000;
  data[4][0] = B01100001; data[4][1] = B10000000;
  data[5][0] = B00110011; data[5][1] = B00000000;
  data[6][0] = B00011110; data[6][1] = B00000000;
  data[7][0] = B00001100; data[7][1] = B00000000;

  disp->paint(27, 9, 9, 8, data);

void loop() {

  // Paint method updates only internal buffer, in order to send data to 
  // MAX chips you have to flush display. 



Static Text 

Now we will display static text, actually those are going to be two independent lines.

Here you can find Arduino sketch containing whole example: StaticText.

Your sketch needs setup method as we've already seen above (chapter: Setting things up), so we will not discus it again.

In order to display text you should use StaticText8x8.

Font is defined in: Font8x8, each character has 8x8 pixels.

Your code could look like this one (plus initialization stuff from Setting things up):

StaticText8x8 *sta1;
StaticText8x8 *sta2;

void setup() {

  ss = createSS();

  disp = new Display(8, 3, ss);

  sta1 = new StaticText8x8(disp, 64);
  sta1->box(14, 2, "Hello");

  sta2 = new StaticText8x8(disp, 64);
  sta2->box(5, 15, "World !");

void loop() {


We have created two text areas, each one containing different text and being display one under another.


Single Scrolling Text

This time we are going to display area containing text that will scroll from left to right. Link below contains youtube video - you can start it by clicking on it.
Lest analyze code (Arduino sketch):

Display *disp;

ScrollingText8x8 *message;
const char *textMessage;

void setup() {

  ss = createSS();

  disp = new Display(8, 3, ss);

  message = new ScrollingText8x8(disp, 48, 50, 5);
  textMessage = "This is an example of multiple scorlling areas ;)";
  message->scroll(8, 8, ScrollingText8x8::LOOP, textMessage);

void loop() {



The initialization of the display is the same as in examples above, so it's omitted here.

In order to display scrolling text we are using ScrollingText8x8. In setup() we are creating instance of this class and calling method scroll(...). This part only initializes scrolling, but does not play the animation itself. In order to play the animation you have to call cycle() and flush() in main loop and you must not have any additional delays there, otherwise you might get jagged animation.

During creation of ScrollingText8x8 we have provided speed of animation - actually it's a delay of 50ms per frame. Now calling cycle() in main loop will produce frames of animation according to provided delay. When the time comes the method cycle() will update display and finally method flush() will send updated content to MAX chips.

The whole implementation of ScrollingText8x8 is non blocking and it consumes CPU only when there is something to be done. Internally it's using simple State Machine.

There is one last thing: you have to keep text used for animation in global variable in order to avoid garbage collection. It's not being copied in scroll() to avoid memory fragmentation.


Scrolling Text Mixed 

This example is similar to one above, but this time we will display several scrolling areas:

Here is the sketch.
This code is similar to one with one scrolling area, but this time we have a few:

void setup() {

  ss = createSS();

  disp = new Display(8, 3, ss);

  uint8_t borderSpeed = 20;
  textUpDown = "* * * * * ";
  up = new ScrollingText8x8(disp, 64, borderSpeed, 1);
  up->scroll(0, 0, ScrollingText8x8::CONTINOUS_LOOP, textUpDown);

  down = new ScrollingText8x8(disp, 64, borderSpeed, 2);
  down->scroll(0, 16, ScrollingText8x8::CONTINOUS_LOOP, textUpDown);

  textLeftRight = "* ";
  left = new ScrollingText8x8(disp, 8, borderSpeed, 3);
  left->scroll(0, 8, ScrollingText8x8::CONTINOUS_LOOP, textLeftRight);

  right = new ScrollingText8x8(disp, 8, borderSpeed, 4);
  right->scroll(56, 8, ScrollingText8x8::CONTINOUS_LOOP, textLeftRight);

  message = new ScrollingText8x8(disp, 48, 50, 5);
  textMessage = "This is an example of multiple scrolling areas ;)";
  message->scroll(8, 8, ScrollingText8x8::LOOP, textMessage);

void loop() {



We have created few instances of ScrollingText8x8, each one containing different text and position on the display. In order to play animation you have to call cycle() on each instance, but you have to call only once flush(). Each call on cycle() will update it's part of the display and flush will send changed display to MAX chips.

Wednesday, February 3, 2016

Logger for Arduino over Serial Port

I am bit tired of using Serial as logger - mainly for two reasons: it does not support sprintf syntax and string are being held in RAM. For this reason I've implemented new library:

ArdLog serves as simple logger for Arduino that creates formatted messages over Serial:
  • Each message has timestamp.
  • Each message within single loop has the same timestamp, so that you can logically connect activities together.
  • Messages can be formatted using sprintf syntax.
  • Text for the messages is being held in PROGMEM.


In order to install ArdLog you have to download desired release and unpack in into folder containing Arduino libraries. The is the result on MacOS:

$ pwd

$ ls
ArdLog.cpp ArdLog.h   LICENSE


  • Logger is disabled by default, in order to enable it set LOG to true.
  • Messages are created over default Serial port. You can choose alternative port by setting: USE_SERIAL_1, USE_SERIAL_2 or USE_SERIAL_3 to true.
  • In order to print current time for each message set USE_CURRENT_TIME to true. By default logger will sample time only once at the beginning of each loop.

Getting up and running  

  1. Choose suitable configuration in ArdLog.h. In most cases you have to only set LOG to true.
  2. Call log_setup() in setup() method - this will initialize serial port.
  3. Call log_cycle() at the beginning of each loop() - it will sample current time.
  4. Put log messages into #if LOG log(F("....") #endif - once logger is disabled, it will not waste RAM and CUP.

#include <ArdLog.h>

uint16_t loopIdex = 0;

void setup() {

void loop() {


  #if LOG
    log(F("**** Loop %d ****"), loopIdex);
    log(F("T1 = %ld"), millis());


  #if LOG
    log(F("T2 = %ld"), millis());

This is output created by example above:

>>[000-00:00:00,000]-> Logger initialized, free RAM: 1537
>>[000-00:00:00,003]-> Free RAM: 1527
>>[000-00:00:00,003]-> **** Loop 1 ****
>>[000-00:00:00,003]-> T1 = 9
>>[000-00:00:00,003]-> T2 = 112
>>[000-00:00:01,113]-> **** Loop 2 ****
>>[000-00:00:01,113]-> T1 = 1114
>>[000-00:00:01,113]-> T2 = 1215
>>[000-00:00:02,215]-> **** Loop 3 ****
>>[000-00:00:02,215]-> T1 = 2217
>>[000-00:00:02,215]-> T2 = 2318
>>[000-00:00:03,319]-> **** Loop 4 ****
>>[000-00:00:03,319]-> T1 = 3320
>>[000-00:00:03,319]-> T2 = 3421
>>[000-00:00:04,422]-> **** Loop 5 ****
>>[000-00:00:04,422]-> T1 = 4423
>>[000-00:00:04,422]-> T2 = 4525

Saturday, May 16, 2015

Direct Digital Synthesizer based on plain Arduino

Microcontroller is meant to control stuff and not to generate periodic signals - for this propose we would use a dedicated hardware - something like Atmega328 and AD9850.
But on the other side this might be an interesting project - not very useful, but at least we can manually build DDS and get good understanding of its functionality. The basic idea of such synthesizer is to create a software loop where each iteration will output single point of particular wave. Higher amount of points within single period increases resolution and reduces frequency - due to limited processing power.
There is also a good motivation to optimize the code - each extra operation consumes CPU cycles and decreases maximal output frequency.

Generated wave signals

Sine with 120 probes per period

Sine with 360 probes per period
Max frequency is limited to 1.8Khz where sine with 120 steps reaches 5.58Khz

Signal at 10Hz is smoother when compared to sine with 120 steps.



Wave Generator

Arduino does not have Digital to Analog Converter - there is only PWM generator, but in order to generate smooth wave we need stable analog voltage. Common pattern to solve this problem is to take a few digital outputs and connect them together trough voltage divider - you can see that on schematics in the right bottom corner. We are using Arduino's digital output D0-D7 because they are all managed by single register (Port D). This means that we can change value of all 8 bits (D0-D7) with single assignment, for example: PODTD = B10000001 would set D0 and D7 to 1. This also means that mapping between byte value and analog output is linear, here are few examples that I've measured using oscilloscope:

B00000001 22 mV
B00000010 38 mV
B00000100 73 mV
B00001000 140 mV
B00010000 276 mV
B00100000 545 mV
B01000000 1.08 V
B10000000 2.18 V

B00000001 22 mV
B00000011 56 mV
B00000111 125 mV
B00001111 265 mV
B00011111 543 mV
B00111111 1.1 V
B01111111 2.23 V
B11111111 4.47 V
Each generated wave consist of few steps - for example sine has 120 (or 360 because there are two versions). Each step is pre-calculated and stored in an array - main loop simply goes over this array and assigns value from it to PORTD.

To smooth out generated signal I've used capacitor 470pF on the output. The op-amp works as a buffer so that resistance of a device connected to the output cannot influence generated wave - capacitor would discharge faster and we would change characteristics of voltage divider.


There are four buttons:
  • Frequency Up - increase frequency
  • Frequency Down - decrease frequency
  • Delay Step - value of the step for frequency change
  • Select Wave -  you can choose from from sine 120, sine 360, square and saw
Reaction on buttons is handled by interrupts, so that the main loop can concentrate on generating high frequency wave.

Frequency adjustment

There is a small catch... single press on Frequency Up does not necessary change the frequency by one hertz, but it changes the amount of wasted CPU cycles per step .... I will try to explain this from the beginning:
as you remember we are generating wave by going over pre-calculated table - each byte in such table will be assigned to PORTD and this happens within a single "step". In order to plot wave we have to go over whole table, once we are done, we have to start from the beginning. In order to change frequency, we have to alter time for each step - this is the only possibility to proportionally scale up he whole wave. The smallest amount of delay in our case is the single CPU operation - it's called NOP and it takes 1327 nano seconds - NOP itself is quicker but I've also considered time required to call a method.
For example single period of sine consist of 120 steps, increasing delay by one, would add one NOP operation to each step, meaning that single period would take additional 120 * 1327ns.
The good news is, that LCD display always displays correct frequency in hertz, only pressing Up and Down buttons changes it by few hertz. The bottom line of LCD display shows period time in nano seconds.

Code Optimization

My first version has used Arduino API and I was getting about 150Hz for sine with 120 steps - final optimization went up to 5,6KHz. I've used interrupts to handle input from buttons,  direct registry access, removed all unnecessary method calls, reduced size of a variables  - like from 16 to 8bits and finally exchanged floating points with integers.

There is always a tradeoff - code readability had decreased, direct access to  registers is also tricky, because they can be used for different proposals. Arduino API takes care of all those problems, but it need few extra CPU cycles.

Source Code

is on github