Category Archives: ESP12E

The Wall Display

ESP8266 Wall DisplayThis blog has been updated as I've discovered that these displays are, after all, still freely available from AliExpress. I’ve recently spent time working on my hallway wall display, an amount of time which would be considered commercial suicide. Good job it isn’t commercial.

Of course I’ve not just been working on the pretty colours – I’ve revamped the control codes for the ESP8266-driven controller twice, discovered and fixed an OTA flaw in the code, re-hashed the Node-Red driving code, found and fixed countless other bits and pieces… you know – in other words – pretty much revamped everything just to improve a simple display.

Continue reading The Wall Display

Facebooktwittergoogle_pluspinterestlinkedin

Arduino Peripheral for HC2018

As many of you know, I don’t have a great deal of time for Arduino for WIFI/Ethernet – I cannot tell you how many months I wasted on those daft cheap Ethernet boards for them which never really worked reliably no matter what I did – so I probably have a mental block by now. My friend Aidan has had some luck with the Wiznet chip but I’m vommitted to the ESP8266.

However, there can be no arguing that a board costing £1.28 inc. postage has to be worth using as a peripheral. The picture below shows where this all fits into the scheme of things…

The script and more

And so it was that recently, I’d just finished putting some polishing touches on the I2c code, fresh from having gotten the BMP280 working – and I was looking at A/D boards to add to the arsenal when I remembered that Arduinos have A/D in… 10 bits - not stunningly high definition but good enough for checking batteries and light levels and much more.

Nano[6]At that point, mid-coffee I remembered I’d bought one of these little critters from AliExpress. Be careful – not all of these bring A4 and A5 out, some have micro-usb connectors, others don’t. Some have 3v3 regulators, some don’t.  I find the most useful ones just have the FTDI connector on them and no USB – but then I have FTDI connectors coming out of my ears.

For the purposes of this item – a 3v3 regulator is not needed as presumably if you’re fastening I2c devices to the ESP8266, you’ll feed 3v3 to the whole lot. Anyway, use whichever suits you best. I’m also assuming pullups are in place – the Arduino has pull-ups but I doubt they are strong enough.

Most of these boards do have regulators and the Nano clone has microUSB. The Pro variant here does not. Both are good. I now ONLY use ones with A6 and A7 brought out.

SO – the point of this is – it is quite easy to make an Arduino clone into an I2c slave – so for under £1.50 you can make a port extender, more inputs, some analog inputs, PWM outputs inc fading – just about anything really as long as whatever it is doing doesn’t take up any time as the board needs to respond to I2c commands quickly.

The simple WIRE library with a little custom code turns the Nano or similar into a peripheral device – I’ve chosen to make it DEVICE 9 by default  – don’t REALLY want to use up ports to make that address programmable but then because the board has EEPROM I’ve made a hopefully reliable method to store the device number in EEPROM!

In the simplest example, sending I2c commands (special command NANO) to this device from the home control software discussed elsewhere in this blog – let’s say to turn output 13 on…

{nano:9,1,13,1}

And indeed that was the very first command I made it respond to as an I2c slave – mainly because on these boards, port 13 has a LED attached to it!!!

Clearly turning it off would be:

{nano:9,1,13,0}

Or how about reading the state of input 10?

{nano:9,2,10}

So here I’ve chosen to create the command nano – command 1 is set ports (2 is read ports)… actual output port is 13, last parameter is 1 or 0 for on or off.  Immediately we have a port expander with several useful ports. For ease, the software I put into the Nano checks to see if the port has already been setup correctly and does that if not – hence avoiding annoying setup code at the ESP end.

With the simplest code and assuming A4 is used as the SCL and A5 is used as SDA, you end up with a “nano i2c peripheral” able to offer (if you get the right board offering A0-A7):

  • 6 8-bit PWM channels (2 – RGB channels)
  • 6 8-bit ANALOG inputs
  • 6 DIGITAL INPUTS or OUTPUTS

i.e. ALL of that.

I’m sure it would not take most of you too long to figure out ALL SORTS of other configurations but for the sake of this project and this board example– there are ports 2-21 where Arduino A0 is numbered 14. Now,  if your board DOES have A6 and A7, note that they can ONLY be used as analog inputs – they cannot be used as ordinary inputs OR outputs – that’s just a simple feature of the board, not the software.

The point being – they are SO cheap and with this code make good general purpose I2c peripherals – you have to ask yourself – in some cases, why you would use anything else!

So before we start – this will only work for short strings or series of numbers with the standard WIRE library for Arduino – see the blog where I learned the hard way this weekend that WIRE has a 32 byte incoming buffer AND a 32 byte transfer buffer and if you try to send more than that – the Arduino crashes – I’ve updated my WIRE to 128 bytes (so that’s 192 bytes more than before ) and it is working a treat with long strings – the reason I want that is because though you won’t see it in this basic code, I’m now working on running QTECH 160*120 displays in the Arduino peripheral.

I’ve updated the code and here is the current state of affairs – evolving rapidly, for the Nano - expect this to change – again  -  this time tomorrow it will no doubt have changed - again.

 

[pcsh lang="cpp" tab_size="4" message="" hl_lines="" provider="manual"]

//
// A simple i2c SLAVE - default device number 9 - reads instructions from
// master and either sets outputs or returns inputs accordingly.
//
// 
#include <Wire.h>
#include <EEPROM.h>

#define MAXPORTS 21
#define ADDR_LOC1 0
#define ADDR_LOC2 1

#define SET_OUTPUT  1
#define READ_INPUT  2
#define READ_INPUT_PULLUP 3
#define SET_PWM     4
#define READ_ANALOG 5
#define SET_ADDRESS 6

byte ports[MAXPORTS];
byte params[6];
byte paramp;
byte retParam;
byte bigcount;
byte device=9;

void setup() {

  byte eeprom1,eeprom2;
  eeprom1=EEPROM.read(ADDR_LOC1); eeprom2=EEPROM.read(ADDR_LOC2); 
  if ((eeprom1^eeprom2)==255) device=eeprom1; // programmable address
  bigcount=0;
  Wire.begin(device);           // join i2c bus with address #9 by default
  Wire.onReceive(receiveEvent);
  Wire.onRequest(requestEvent); 
  for (int a=0;a<MAXPORTS;a++) ports[a]=0;
  paramp=0;
  retParam=0;
}

void loop() {}  // not used yet

// function that executes whenever data is requested by master
// this function is registered as an event, see setup()
void requestEvent() {

  Wire.write(retParam); // respond with message of 1 bytes as expected by master
  //Wire.write(34); // respond with message of 1 bytes as expected by master
  //Wire.write(45); // test
  //Wire.write("This is it you know",19);
}

// function that executes whenever data is requested by master
// this function is registered as an event, see setup()
void receiveEvent(int count) {
int tcount;
tcount=count;
paramp=0;
// no time consuming in here or the routine to send a byte back will be missed.
  while ((tcount--)&&(paramp<128))
   {
    params[paramp++]=Wire.read(); 
   }
  switch (params[0])
    {
    case SET_OUTPUT:
          if (ports[params[1]]!=1) { ports[params[1]]=1; pinMode(params[1],OUTPUT); } 
          digitalWrite(params[1],params[2]? HIGH : LOW); params[0]=0;
          break;
    case READ_INPUT:
          if (ports[params[1]]!=2) { ports[params[1]]=2; pinMode(params[1],INPUT); } 
          retParam=digitalRead(params[1]); params[0]=0;
          break;
    case READ_INPUT_PULLUP:
          if (ports[params[1]]!=3) { ports[params[1]]=3; pinMode(params[1],INPUT_PULLUP); } 
          retParam=digitalRead(params[1]); params[0]=0;
          break;          
    case SET_PWM:
          if (ports[params[1]]!=4) { ports[params[1]]=4; pinMode(params[1],OUTPUT); } 
          analogWrite(params[1],params[2]); params[0]=0;
          break;
    case READ_ANALOG:
          if (ports[params[1]]!=2) { ports[params[1]]=2; pinMode(params[1],INPUT); } 
          retParam=analogRead(params[1]); params[0]=0;
          break;    
    case SET_ADDRESS:
          EEPROM.update(ADDR_LOC1,params[1]); EEPROM.update(ADDR_LOC2,params[1]^255); 
          // update address - will take effect on next powerup of the device as you 
          // can only call "begin" once
          break;      
    default: break;  
    }
}

[/pcsh]

Facebooktwittergoogle_pluspinterestlinkedin

HC 2018 Experiments

Throughout the development of the Home Control 2018 project I’ve constantly had the software tied a via a serial umbilical to my PC to monitor passing messages, make sure all is well etc. and to periodically check on RAM space to make sure nothing I’m doing is running away with precious memory.

You may have seen elsewhere that I’ve been working with a prototyping board which is basically an ESP12 with a prototyping area in which I’ve put rows of pins for ground, 3v3, 5v and the two lines I use for I2c as I add various peripherals culminating in the recent idea to use an Arduino 328 chip as an “ultimate peripheral”.

Well, we’ve taken that one a stage further and we’ve been discussing making our own prototyping board (Aidan’s a whizz at PCBs and of course we use the likes of Dirty PCBs in China so it is quite cheap to knock up a few boards) and the last few days I’ve been formulating a planas Aidan puts together the schematic. What I’ve realised is that I always run out of the power and ground lines no matter what I do. Add to that the FTDI so I can monitor serial Comms and it all gets a bit messy.

Display for HC2016

So right now we’ve been discussing a board with the ESP-12 module with lots of pins and additionally a 328 SMT chip with Xtal. Of course that means 2 serial monitors. I’ve been playing with the old QDTech 128*160 displays since I discovered that they work pretty well when driven from the proper SPI pins on Arduinos (don’t even think of using software SPI on them) and ramping up the SPI speed – and so it was that in conversation, we were saying “if only you could scroll them” – that led to thoughts of having a RAM buffer larger than the total available on the ESP8266 or Arduino and… well, I thought I’d use our friend Google to go take a look. It turns out – I was completely unaware of this and VERY pleasantly surprised to find – that the QDTECH chip has the ability to scroll up built in – all that is needed is to scroll up an area then paint a fast horizontal black line after each scroll.

There is a version of the driver for the board here and at some point in 2014, it turns out that an M J Sage added this scrolling ability. Well done.  I wonder if he or she realised what a useful addition this could be.

So now we have a display, easily driven by the 328 which can scroll constantly (I’ve had it on several night’s test) and hence provide a boatload of status info. Top and bottom can if needed remain static.

First Stab

We’re going to incorporate the display onto the prototyping board and it won’t take any additional space as it will sit neatly over the other components! The image above probably bears no relation to the final board but I’m just trying to convey an idea here. The prototyping area on the right of the board will be chock-full of PTH holes but there will be long runs of connected holes for power and I2c as these end up being needed the most with connector wires. All 0.1” of course.

With the QDTech display you can connect the reset line to the 328 reset and hence here are my first thoughts at the use of the 328 which will have access to A6 and A7. I’ve pretty much got this working – just need to add in the temperature handling code I already have for Dallas and DHT chips.

D0-7 – general purpose port extender – inputs or outputs or any mix
D8     D/C for QDTECH
D9     16- BIT PWM out
D10  16-BIT PWM out
D11   MOSI for QDTECH
D12   MISO
D13   SCLK for QDTECH
A0      CS for QDTECH
A1      Temperature
A2      Temperature
A3       Debounced input
A4      I2C to ESP
A5      I2C to ESP
A6      Analog in 1
A7      Analog in 2

Aside from losing GPIO2 and GPIO14 inputs (as they’ll run the I2c) the ESP use will remain the same.  The only restriction being that we cannot run ESP PWM at the same time as the I2c due to timing interference– a pain but not something I can see away around. The I2c 16-channel PWM controller does seem a good way around this as it offloads all PWM work onto a cheap board – for single colour PWM lighting the new 16-bit PWM on the 328 works fabulously.

Given that the 328 can handle inputs for the main board we can do away with our normal GPIO2 and GPIO14 and they can have the job of I2c, leaving all normal outputs as for the existing system.

I guess the end-game here will be the smallest possible board that contains both the 328 and the ESP wired to this spec for general use. But that comes later after we see how well all of this works in practice. First the prototyping board. Watch this space.

Sadly in the link I’ve enclosed, the author refers to Banggood who used indeed to offer these displays for under £3 at a time when there were no software drivers for them – (I think we paid £2.60) but I’ve noticed recently that Banggood have been getting greedy and jacking their prices up – a cursory check of the link shows they now want £5.48 for these simple LCD displays – well good luck with that Banggood.

The only ones I’ve found up to now – and the price is good – as usual – is AliExpress.

Someone have another link?  the board has an 8-way connector at one end and a larger connector at the other – with a full size SD socket on the underside. See the AliExpress link.

This blog entry could well change dramatically as we spot fatal flaws in the plan above Smile

Facebooktwittergoogle_pluspinterestlinkedin

The Script and ESP8266 Code for Beginners

I’m often asked about setting up MQTT, Node-Red etc. on the likes of Raspberry Pi, NanoPi or similar, with a view to controlling ESP8266 devices.

Novice readers start here

Usually it is difficult for me to see this from a beginner perspective, but having spent 2 months in hospital thanks to an untimely stroke from which I’m still recovering, 4 months after the event, I recently found myself doing new installs without the benefit of doing this stuff every day. I am just SO glad I blog everything.

Array of Raspberry PIs

Continue reading The Script and ESP8266 Code for Beginners

Facebooktwittergoogle_pluspinterestlinkedin

ESP8266 and ATMEGA2560 Mega Board

ESP8266 and Atmega 2560You may recall my blog entry about my “universal peripheral” – using the little Arduino Nano or similar clones with an ESP8266 – with the former providing GPIO via an I2c connection.

Well, that led me to getting this little number from Banggood – the Wemos Atmega + WiFi R2 Atmega2560+ESP8266 32Mb Memory board.

It’s not 32 MEG of course – it is 4MB – but that’s the same as a normal ESP12. but with the GPIO power of an Atmega 2560 – all in one neat board.

Initial impressions – it looks well put together.  According to the underside, it takes DC 7-16v in – and has DC out at 5v 1.6A and 3.3v at 1 amp – so it actually is a little more than just the two boards – looks like there’s lots of power there for peripherals.

Continue reading ESP8266 and ATMEGA2560 Mega Board

Facebooktwittergoogle_pluspinterestlinkedin

The Script and RPI 3 Update

Having started putting together “the script” a long time ago, long before the Raspberry Pi 3 came out – and having developed it to handle a wide range of boards and scenarios including of course the Pi3, I found it interesting to return today to installing “the script” on the Raspberry Pi 3 – and of course I wanted to ensure that nothing had changed recently which might stop others doing the same.

Continue reading The Script and RPI 3 Update

Facebooktwittergoogle_pluspinterestlinkedin

Simple Scope

SPIYou may have noticed that I’ve been working on my ESP8266 home control software (see the updates elsewhere along with new diagram), specifically upgrading and adding to the number of OLED and LCD displays I can handle, either by I2c or SPI.

I’ve been doing a lot of optimising and simplifying – for example with SPI – assuming that there will only be the one SPI device at once on an ESP means you don’t need the CS line which can be grounded.  But there’s more….

Continue reading Simple Scope

Facebooktwittergoogle_pluspinterestlinkedin

Icons

QD-TechIn case you were wondering – no, I’ve not gone off the boil, I’ve been quietly beavering away on my ESP8266 code since deciding to abandon the old ESP-01 and adding fonts for displays. Right now I’m focussing on the QD-Tech boards – 120x160 but I’ll eventually migrate the use of the various icons to the other displays now that I’m not terrified of running out of space.

Continue reading Icons

Facebooktwittergoogle_pluspinterestlinkedin

Grove LCD RGB Backlight

tmpD3E6Now, before anyone says anything – no I’m not advertising Seeed or their Grove stuff. It just so happens that over the weekend my pal brought some of their stuff over to have a play with and I was particularly taken by the LCD display. This is a typical Hitachi-style 16-character by 2 line LCD of the type that have been floating around since last century but which still are popular today I guess because of price. Anyway, this one marked “Grove-LCD RGB Backlight v1.0” is not particularly cheap but it has an RGB LED background and runs off I2c.

We tested it using the Seeed Studio WIO boards (more on that later). Lovely – want a pink background, or how about aqua, or mint -  well, you have full control over the RGB background with values 0-255 for each colour. It occurred to me that this really transforms the otherwise boring LCD display as you can use colour to indicate alerts etc.  For example on a thermostat display you could use orange for on, green for “reached set temperature” and blue for standby.

tmp52FBAnyway, as the WIO modules are little more than an ESP12 I thought it might be more useful to incorporate a driver for this display into my own ESP8266 code. Those of you familiar with the home control project will know that I keep updating the code for the Home Control 2016 project. So – I took a look at the Grove driver for this display – sadly it is in Arduino C++ format so I ended up doing quite a bit of changing to make it do what I wanted and in C – but ultimately it is in there and works a treat. Here are the new commands you can fire out in MQTT to the board with the new software on, using as usual GPIO4 and 5 for I2c.

{rgb_lcd_setup}

{rgb-lcd_clear}

{rgb_lcd_cursor:X,Y}

{rgb_lcd_background:RED,GREEN,BLUE}  // values 0-255 in each case

{rgb_lcd_write:”Your text”}

And that’s all there is to it. A nice addition to the code. I could add more if needed but I figured this minimal set of commands will do for most purposes.

I’m sure there will be other, compatible boards out there – if you know of them – do let us know.

So on the subject of the Seeed WIO boards, I’ve made a separate blog to follow on that – turns out that if you want to have a play, you can blow their code into an ESP-12 – but read the article coming soon.

Facebooktwittergoogle_pluspinterestlinkedin

VT100 Terminal for HC2018

rear view ESP8266 VT100Well, I had to give it a go, didn’t I – porting the code for the cheap VT100-type serial terminal into the main ESP8266 home control software.

BOY was that difficult but… after 2 days of head-scratching – check out the home control manual in the source code repository for Home Control 2018 – this  uses up four precious port bits (GPIO 13,14,15,16).

I have the terminal code up and running (minus baud rate controls… and the bottom line is now a general status line) and I have to say, fast doesn’t start to explain it.

As you can see in the image above, all we have here is the display with a slim ESP8266 board behind it – a WEMO D1 does the job superbly and you can use double sided tape to fasten the ESP8266 to the flat part of the board.  I just used a board I had handy The FTDI you see attached to the back is merely there to provide 5v power and, erm, stand the unit up!!!

At this point I’ll add what I seemed to have missed out of the original article – the pins!

Connections:  Connect VCC to 5v, ground to ground, light to 3v3.   GPIO16 to D/C, GPIO15 to CS, GPIO14 to SCK and GPIO13 to SDI (MOSI).  Connect RESET to RESET.  Leave the SDO (MISO) on the display unconnected.  The whole thing should light up.. and when you give the {ili_set:1} command and reboot the ESP, the display should clear and put up the header. That’s it.

ESP8266 VT100 front viewI did some tests to see if how fast I could make it -  I’ve already optimised the SPI and character routines – the board will not operate at all under ESP8266 at the fastest SPI speed so that is probably a dead-end, I tried caching the ROM reads (which are 8 bits – meaning you have to read 32 bits at a time and select the right 8 bits.

Caching that info actually very marginally slowed things down – I tried all sorts, writing 16 bits at a time to SPI – and finally after being able to obtain no more speed improvements, I stopped – not sure why I needed any of this as it was already blazingly fast.  Now, writing an X to every location on the screen (that’s 1600 character writes) takes 330ms so that is 200us per character (5*7). I think that is fast enough for now. Clear screen is near enough instant and scrolling is instant.

See this demo video of the ESP8266 version – the 328 version isn’t  quite THIS fast but it is still fast.

https://www.youtube.com/watch?v=YXqLVmoyKPE

So I’ve added some commands in the HC2018 project code

{ili_set:1}
The above will setup the display and make it available to accept data – once set the display will set itself up on power up of the unit.  Setting that command to 0 stops any data and from there on the display will NOT initialise on powerup.
{ili_text:"\e[35;40mHello there \e[32;40mmate\r\n"}
{ili_status:"All working exceedingly well"}
{ili_title:"\e[37;40mESP8266 Status Monitor"}

In addition to the above, {ili_rssi} puts the time and date down in the status area AND puts a nice phone-like RSSI indicator on the bottom right, showing the current WIFI signal strength of the ESP board. {ili_reset} resets the display after clearing it – to show the header and the LED rectangles on the top.

If you want to experiment with lines – and remember this is going via MQTT so don’t plan on making complex objects…  {ili_line:x1,y1,x2,x2,colour} but YOU WILL need to clear the screen first -  you can do that with  {ili_text:"\e[2J"} and when you’re done you can return the display to normal with {ili_reset}

{ili_pixel:x,y,colour} will draw a dot. {ili_rect:x1,y1,x2,y2,colour,background_colour} will draw a filled rectangle.
{ili_string:x1,y1,string} will position a string at an arbitrary location
{ili_fore:colour} will set the foreground colour for future strings
{ili_back:colour} will set the background colour for future strings

All of the above require that you clear the screen – you cannot do the scrolling terminal – and arbitrary text and lines at the same time but this does add a lot of flexibility (which I thought of much later than when I wrote this article originally).

The manual that comes with the bitbucket download is updated with new commands.

Hence by firing serial or MQTT commands at the board, I can get stuff onto the display.  To monitor all MQTT traffic was easy – over to the Pi and MQTT..

In Node-Red – a simple MQTT node picks up all traffic, passes it to a function – which then passes the result to the board which in this case is called “thisone”.

tmpPayload=”  “ + msg.payload;
tmpTopic="
\\e[36;40m"+msg.topic+"\\e[32;40m\r\n";
if (msg.topic!="thisone/toesp")
{
msg.topic="thisone/toesp";
msg.payload="{ili_text:\"" + tmpTopic + tmpPayload + "\r\n\"}";
return msg;
}

DisplayHence the board gets all traffic except for traffic destined for the board (which could end up in an infinite loop).

And now thanks to a conversation with reader Bob Green –  a WIFI signal strength (RSSI) indicator for the board and the time in the bottom left. I deliberately left the seconds out as this would typically not be refreshed that often – maybe every couple of seconds...

Bob suggested that by plugging the board into a battery pack you have a simple range tester and he’s absolutely right of course. Now, how to teach it to make coffee…

On the subject of terminals

No need to talk about VT100-type terminals for PCs – they’re coming out of our ears – but…

Android

I’d put this all together and I thought…an 80 line or 132 line version of this would be nice – I’ll put one on my Android phone. Well, you may well write in and tell me I’m wrong but I cannot find a VT-100 compatible serial modem for Android anywhere (I did find one but it was not clear if scrolling regions worked and it had a limited range of serial settings). Surprising considering that it can be done on a  relatively simple unit like the ESP8266

Linux

And that led me to Linux - or rather - I was thinking about the various single board computers I have lying around - a Pi would do but I have a rather nice FriendlyArm NanoPC T2 which was not quite fast enough for Android but runs a nice Debian.  I started looking for fancy graphical terminals - not a lot - nothing to anywhere near TOUCH some of the stuff on Windows - however I had this T3 with a little 7" LCD touch screen lying around and was determined it would not go to waste.

It turns out that the humble LX terminal does at least some VT 100 - but that pulls up a command line and lets you interact with it  -was there any way to get it to talk to serial instead - preferably one of it's own rather than a USB serial as it has FOUR serial ports on it.

Well, yes. I discovered this..

cu -l /dev/device -s baud-rate-speed

It looked as if this would let me use the terminal with serial instead of a keyboard- but of course when I tried it using:

cu -l /dev/ttyAMAT3-s 115200

I got zilch. The system didn't have a clue what CU is (neither did I for that matter).

Anyway, just for a laugh I tried SUDO APT-GET CU

And it worked. I tried again. THIS time all was well - but it could not contact the serial port - as it was "busy" - yeah right.

I added user FA (the user in control of that terminal session) to the relevant group - no difference - so as is often the case I just gave 777 permissions to the serial port and VOILA.

Terminal on Debian running serial

I tested some colour escape sequences from my PC Serial Terminal I wrote some time ago (and just recently updated to let me put ESC in there) and all worked well but for some visible representation of the ESCAPE sequences (which still worked). I continued experimenting and the UX terminal that comes with Debian LDXE does not suffer that particular issue – so it has the job!!!

Facebooktwittergoogle_pluspinterestlinkedin