Category Archives: i2c

Weather 2 Board and ESP8266

December 4, 2016BME280, ESP-12, ESP-12E, ESP-12F, ESP8266, i2c, SI1132Pete

NOT the cheapest board on the planet, I was handed a couple of these little boards by a friend this weekend.. the weather-2 board.

The board uses 2 i2c chips – the BME280 which as you may know is a miraculous little chip offering temperature, humidity and pressure readings all in one chip. I already support that in my ESP8266 code. Nothing new there and the chip works as expected when plugged in using this module.

What this board brings to the party is a chip I was previously unaware of – the si1132 – which in one chip offers readings of visible light level, UV level and IR levels.

The original library for this used floats and I’ve reduced that down to integers – looking at the variations I doubt I’ve affected accuracy at all – and these now come in the form of I2c commands in my ESP8266 code..

{si1132_uv}

{si1132_ir}

{si1132_visible}

Assuming the board is attached (or a board containing that chip that works at the same I2c address) – you can grab readings from this chip no problem.

I could envisage one of these outside – in a cover that protects it from the direct light and direct heat of the sun, offering all 6 readings – handy for lots of things. Or maybe you just want an alarm when you’ve had too much sunbathing – I’ll leave it to others to figure out best uses.

Makes a useful addition to the home control project. Source of the ESP8266 code available as are ROMS.

I2C Expansion for Pi and ESP8266

November 11, 2016ESP8266, i2c, Raspberry Pi 2, Raspberry Pi 3I2C Expansion on Raspberry Pi and ESP8266Pete

Want 64 GPIO pins on your ESP8266 or Raspberry Pi? Read on.

If like me you are not THAT familiar with I2c, you might find the results of my experiments interesting and perhaps even useful.

So I bought a couple of these i2c port expanders from China – mainly because I wanted something simple to mess with i2c on the ESP8266. It occurred to me that if I could get these working on a Pi, so I was sure of the addresses and commands etc., then on the ESP, I’d then get the confidence to do something more dramatic on the ESP8266 with i2c.

So ignoring for a minute the interrupt capability, these are pretty basic devices – using up 2 port bits (SDA and SCL) on your Pi or ESP, send an i2c start to them followed by an address then a byte to them – and the outputs light up accordingly. Set the outputs to 255 and read back a byte and you get the state of the pins as inputs. It doesn’t get any easier.

Well, not unless you completely mis-interpret the addressing as I did and spend ages chattering away to the wrong address. Anyway, let’s not dwell on that.

I noted that the outputs are HIGH by default. Also note that in my experiments I have set the 3 DIP switches to ON (NOT as in the photo above).

Armed with the latest version of Raspbian Jessie on a pi2 or Pi3, connect ground on the device to ground on the Pi, VCC to 3v3 on the Pi, SDA to SDA (blue) on the Pi, SCL to SCL on the Pi. Simples. The boards have built-in pull-up resistors for i2c (which could pose an issue if you parallel a bunch of them up of course) so that’s it – no other new components needed other than a LED for testing. I used a 470r resistor in series with the LED.

Open a terminal on the Pi and type:

sudo pigpiod

That starts the new GPIO library daemon running in the background.

Now here is a short file that will set all the outputs to 0 – running Python…

import pigpio

pi1 = pigpio.pi()
pi1.write(18, 0)

b=pi1.i2c_open(1,39)
pi1.i2c_write_byte(b,0)
pi1.i2c_close(5)

Nice but then my pal Peter Oakes pointed out to me that I’d end up loading the entire Python environment every time I wanted to change an output.. so I started experimenting with C code… just turning GPIO18 (on the Pi) on and off for starters…. see the line that says gpioWrite(18,0); that turns the port off. Substitute a “1” to get the opposite effect. All of this worked a treat.. “b” here ends up containing a handle.

#include <pigpio.h>
#include <stdio.h>

void main()
{
if (gpioInitialise() < 0)
{
puts("erm no"); // pigpio initialisation failed.
}
else
{
gpioSetMode(18, PI_OUTPUT);
// pigpio initialised okay.
gpioWrite(18, 0);
}
}

The code above once compiled failed the first time – I realised you must NOT have the daemon running when using this. so a quick reboot later and I was in business.

Oh, here’s how to compile a simple C program like that – make sure it’s a text file, say in your /home/pi directory.

gcc -Wall -pthread -o prog prog.c -lpigpiod_if2 –lrt

See where it says “prog” – change that to the name of your program. Takes seconds.

Anyway, I was just about to set everything up in C for i2c etc. when I discovered… PIGS

sudo pigpiod
pigs w 18 0
pigs w 18 1

Note – no sudo needed for the commands and presumably one would run that daemon (pigpiod) at startup. This looked like a nice simple route – dead easy for Node-Red as you can just issue the commands in an EXEC function and pass the parameters in the payload – so next would be to try i2c….

pigs i2co 1 39 0
pigs i2cwb 0 0 0
pigs i2cwb 0 0 255
pigs i2cwb 0 0 1
pigs i2cwb 0 0 2
pigs i2cc 0

The first command visually returned 0 – hence my use of 0 later in the code as the “handle”. I order, I set the expander to all off, all on, then the first bit only on – then the second bit only on and finally I closed the handle.

Something to note is that I2c lines need pull-up resistors – and this board has them already built in – unfortunately they are 1k pullups – fine if you only have one board, not a lot of use if you want to put several in parallel. After discussion we think that possibly the two relevant resistors might be replaced by 10k in which case you could then run several in parallel (with different addresses) but we’ve not tested that.

Oh, making that daemon permanent… I did that with a command line edit “sudo nano /etc/rc.local” - and added the line “sudo /usr/bin/pigpiod” – and rebooted…. no problem.

Update November 9, 2016

The final stage of this experiment gives my ESP8266 software the ability to achieve the same thing, losing 2 wires to get 64 new ones (YES, 64), a net benefit of 62 I/O lines, could be worthwhile as the ESP8266 isn’t exactly brimming with IO lines.

Above you see (blue) our ESP-12 board, fastened to an FTDI for power, and wired by jumper to one of the PCF8574T boards - clearly you'd need 8 of them to get 64 lines and I'd be wary as they have pullup resistors on the data lines. I'd remove them on all but one.

With a typical Chinese PCF8574T board which includes pullups, I’ve added new commands to the ESP8266 Home Control software as of my software version 1.6.52 – the xport command.

Example:

{xport:0,1}

sets the lowest bit of the first (address 39) expander high (the 0 is a mandatory argument above – see future blogs) whereas:

{xport:0}

returns the state of the first (LSB) bit of the first of up to 64 bits.

On power up these devices are HIGH - and the software defaults to high on power up. If you mess with a port bit, you need to set a bit high before you can use it as an input. Here is the datasheet for this chip – and here is a typical Chinese expansion board. With GPIO4 on our little boards hooked to SCL and GPIO5 hooked to SDA – the new commands work a treat.

In the above photo – address 39 equates to all DIP switches set to ON (that’s high or 7). If you set number 3 to off – that is address 38 (bits 8-15) etc. (simple binary selections – you can make the device work as anything from 32 (all switches OFF) to 39 (all switches ON) but before you go connecting eight of them up – bear in mind the comments about pull-ups above.

I’ve been doing a little more on these as you’ll see in other parts of the blog – but the upshot is – you have to ask yourself if these are worth the money. In my original blog I pointed to an Ebay price of £2.35 - but in fact from AliExpress they are only £1.20 and so I’ve amended the link in the blog accordingly. However as you’ll see in other blog items – as I’ve learned I’ve realised they are not necessarily the best bet. I’ve now made a simple “Nano i2c peripheral” from a Nano board – and they cost just a few pence more – but you can make NOT only an 8-bit expander but also get some A/D, some PWM and some A/D thrown in – hell I’m even putting an LCD display driver in just for the sake of it – and I’ll call it the kitchen sink peripheral.

However if you do like the look of these chips, you’ll note they say they work on 100Khz I2c. That of course is true and I’ve not experimented with anything other than close up – lets say less than 250mm away – but I’m currently running them a HELL of a lot faster than that. I’ve only speeded up the clock for writes and reads – note the wide bits around the edges but still – quite nippy.

Hope you found the above useful. For more information on the ESP software – go to the relevant page on the blog. There is of course the main Home Control 2016 page.

The Light Fantastic

November 4, 2016ESP8266, GY-30, home control, i2cCY-30 Light sensor LUXPete

This morning, a long-forgotten package turned up for me – a cheap but accurate light level sensor from China – claimed to be around 1 lux accuracy and giving a direct output in lux. A small board is available here in Britain for around £4 or the identical board from China for 98 pence. I chose the latter. It is called the GY-30 board.

The tiny board comes complete with connector which takes seconds to solder on (I put mine on the underside). There is an address line which does not need connecting and the I2c has pull-up resistors already in place so basically you provide ground, 3v3 and I2c.

I plugged this into one of our ESP826 boards and did the I2c search – it came back with device 35 (0x23).

The documentation has various modes but unless you are power saving (in which case the ESP8266 might not be your best call) you can just leave the thing on converting at high resolution 0-65k. I wrote two functions – one to initialise the I2c and to start the conversion off – the other function to read back the 16 bit value from the device.

At maximum resolution, you have to leave around 180ms between readings and of course it won’t start the next check until you read it so the best thing to do is just grab the readings maybe every few seconds depending on your application (once every 15 minutes would do me) and store it away somewhere.

Anyway I’ve added the code to the house control code – boards suitably updated (v1.6.50 or higher) can issue {gy30_init:35} and {gy30_read:35} commands. If you cover the sensor with your hand you will typically get a value of 4 or less. Ambient light in my office produces around 80-100 and pointing the unit up to the lights produces a reading of around 1000. Don’t ask me to do a sunlight test – wrong time of the year here in the frozen wastes of the Northeast of England.

I do plan to stick one in the window and log it – so when I’m off in Spain and people back here are saying “oh, it’s lovely and bright here” I can tell if they are telling fibs. Check out the blog entries on home control 2016, flashing the code for more info.

Enjoy.

Faster ESP I2C

August 30, 2016Arduino, ESP12, ESP12E, ESP12F, ESP8266, ESP8266 SDK, i2cPete

Experimenting with I2c on the ESP8266? I am – and I’m having a great time with it. If you’re using my code you don’t really need to think about it but if you’re hunting around for better I2c for the ESP – or maybe interfacing the ESP8266 to Arduino – then you’ll love the stuff I’m doing right now – and yes, I AM looking for I2c experts to tell me if I’m doing something wrong because it is all going rather too smoothly.

I decided to take the end from the info from the last blog entry and separate it off as I learn more about I2c (which to recall is a simple 2-wire multi-drop serial communication protocol with separate clock and data).

Why read this? Well, up to now because I spotted a howling issue in the WIRE library for Arduino, found an improvement on the ESP8266 SDK I2C code in the ESPRUINO changes to the Espressif I2c code - I think I found a mistake in it, fixed it then SAILED past the original speeds, reducing a 15ms package best case to well under 3ms while adding clock stretching into the bargain. I should clarify at this point that I am NOT an expert in I2C but hey – I can’t get this to fail so I might be onto something! Read on!

So firstly let’s recall - I’ve been trying to make an Arduino peripheral for the ESP8266 Home Control 2016 project. I started with the WIRE library in Arduino, working on a small NANO device. I discovered that there are two buffers in WIRE that are 32 bytes in length and hence limit packages to less than that - I replaced them with a couple of 128 byte buffers and solved lots of issues I’d been having – that is detailed in the last blog.

Where we left off, I’d made a test setup to send a message to the newly-created NANO peripheral which right now on my bench handles a QTECH display and some IO. The ESP8266 I2C is also talking to a BME280 temperature/pressure/humidity sensor and a PWM expander board – so there are 3 devices – some input, some output.

In the last blog entry I’d added a test command for the ESP which could be sent to the board serially or by MQTT and went like this…

{nano:9,7,"how are you today and the weather is nice - NO REALLY it certainly is.",0}

Simple enough – send a message to device 9 (my chosen default address for the NANO peripheral), command 7, a string – and a dummy 0 on the end to tell the device not to bother sending any return info.

As you can see below, this operation takes, using the standard Espressif Ic2 Master code, 15ms in total – not stunningly fast but ok.

Flush with the success of finding that buffer issue, I decided to go into the ESP I2C library and have a tinker – changing all the delays into ‘'#defines so I could mess with them. So without any real effort I could reduce delays from 14ms to 6ms – a very worthwhile improvement. bear in mind however that the ESP code has no clock-stretching and hence no way for the peripheral to slow things down. I am told that the call-back routine within WIRE holds the clock down until it is finished, in order to slow things down – this would do nothing but cause havoc for the Espressif code.

Below is a read operation which I got to work properly after reading this video – as I had no idea what a re-start was – see the little green circle just after the third byte.

As you can see in the image above I address device 9 (18 as it is shifted left by one – i.e. 7 bit addresses but the bottom bit is reserved to indicate a read or write) – I fire command 2 to read port 4 – then with an I2s restart (start without a preceding stop), I resend to the device with the LSB set (ie 19) and get a value 0 back (from a pin) All in a matter of a millisecond.

I was at this point getting worried about lack of clock-stretching – in which a slave can hold the clock low to “stretch” things out a bit – about the only control the slave has!

It looked as if this forum might have some answers as their modification of the ESPRESSIF code certainly had clock stretching in it. It involved some changes and I decided to pick the best bits from their modification.

So they’ve simplified the code a little – while adding in clock-stretching – by replacing a simple delay with a check for clock low – easy enough when you look at it… but they also seemed to have completely messed up master_start – at least, they had it the opposite way to Espressif – and accordingly, repeated starts – as I use in getting data out of a Nano above – simply failed. The logic probe said this was all wrong.

So I reversed master_start back to the way Espressif have it –so I ended up with a mix of the old and new – and the result – well, up to now everything works – and that long 15ms string send was now reduced to under 5ms from 15ms.

I tested the code with the PWM chip I’ve been playing with and the BME280 – so that is both reading and writing and up to now both were working perfectly.

It was notable that the clock low period was now much longer than the clock high period and I wondered if there is any way to shorten that. You know when you get deeply into code and all of a sudden it all becomes clear. I realised that setting and checking ACK signals was a function – with all that entails – I changed that to a macro. I realised that delays in loops were really un-necessary as the loop itself would cause delays.. I took them out.

At this point I had backed everything up expecting my experiments to fail miserably. I tested the new code and everything worked. I got the logic probe out again.

My original test string at 15ms was now down to 3ms and according to the probe – all is well. I DID get it down to 2.5ms but the probe said I was doing restarts in the middle of the string – I’ll find another way around that one. Current state of the art – 2.9ms

As for reads – my original byte read was taking somewhat over 1ms – it now takes 0.25ms.

And of course I’ve concentrated on the read and write routines leaving the inter-byte handshaking pretty much along so maybe there’s another 10% improvement to make here without dipping into ESP assembly language.

https://bitbucket.org/scargill/esp-mqtt-dev/src

The driver and firmware libraries in the repository above contain the modified Espressif i2c_master code – and also other I2c wrappers for sending packages – they are fine – any further optimisation needs a good solid look at the one file (and it’s header) for i2c_master. Open to ideas (that don’t involve converting Arduino assembly language to work with the ESP SDK – been there, failed).

I have just noticed that in the write cycles, there is still more off-time than on for the clock – and so I just took a delay out – which SHOULD mean the off-time is way too slow but because of the time taken to call and process the function – we still end up with 0.9us on time and 1.3us off time – everything continues to work on the tests I have – yet the total time for that read drops from 0.25ms to 0.21ms and the string write time from 2.9ms to about 2.2ms – again – worthwhile improvements.

That simple change was made in the write routine…

void ICACHE_FLASH_ATTR
i2c_master_writeByte(uint8 wrdata)
{
    uint8 dat;
    sint8 i;

    for (i = 7; i >= 0; i--) {
        dat = wrdata >> i;
        I2C_MASTER_SET_DC(dat,0);
      // i2c_master_wait(I2C_DELAY_5);
        I2C_MASTER_SET_DC(dat,1);
        while (!GPIO_INPUT_GET(GPIO_ID_PIN(I2C_MASTER_SCL_GPIO))) {}
       I2C_MASTER_SET_DC(dat,0);
    }
}

Logic analyser says yes, 3 test items say yes… how low can it go!

I2C the Easy Way

August 29, 2016Arduino, ESP12, ESP12E, ESP12F, ESP8266, i2cPete

If you’re going to experiment with I2C – may as well do it the easy way. Having spent the past few days with a desk that looks remarkably like a bowl of spaghetti, I’ve finally gotten around to making a special IOTBEAR board up for the job. 18 each of ground, +3v3 and +5v lines – and 16 each of GPIO4 and GPIO5.

This gave me the opportunity to tackle that long string problem in Arduino Wire. A brief attempt with the logic analyser suggested that my ESP i2c was sending out at least one byte more than the Arduino was receiving – impossible to tell if more because the ESP would stop sending as soon as the Arduino would stop receiving.

And that brings me to a question – is anyone aware of a nice, pretty I2c and other protocol analyser based on a Raspberry Pi? Seems to me that would be a good use for an old RPI2?

Anyway I digress… I’ve had issues with I2c experiments in the past – usually when sending strings. I’ve looked up the issue on Google and found nothing. I was convinced it was a timing issue and at that point I Skyped my friend Peter Oakes in Canada – just as with Aidan who you’ll have read about in here, I often find that “two heads are better than one” when I’m getting bogged down.

We started sending I2c strings to the Arduino who’s receive buffer I’d put a Serial.println() statement in – to see how many characters it THOUGHT it was receiving.

29…. 30… 31… 32… 32 - EH

As I increased the length of string sent from the ESP (using ESP software I2c) to the Arduino (using the WIRE library) at 33 characters the Arduino thought it was getting 32 – at 34 it went to meet it’s maker.

VOILA – the WIRE library clearly has a buffer to store stuff – I did not believe at first that 1. the buffer would be so small and 2. this would result in a crude crash. I went into the Wire Library (that’s a long story – I have dozens of WIRE libraries and it took a while to find the right one) – updated the buffer size in wire.h and… nothing – made no difference. I introduced an error into the .h file to make sure I had the right one – sure enough - but no joy on fixing the problem.

I don’t know if Peter or I twigged first but in my ESP SERIAL buffering which I wrote myself, I have a 256 buffer for incoming characters – which fills until it gets a CRLF then transfers that to an output buffer of the same size – so that incoming characters can continue to arrive while processing the buffer. It occurred to us that maybe the Wire library has the same setup – SURE ENOUGH. Not only is there a buffer definition in arduino/hardware/arduino/avr/libraries/wire/src/wire.h but also in arduino/hardware/arduino/avr/libraries/wire/src/utility/twi.h

And yes, the directory structure IS that complicated (I’m on Arduino 1.69) – sure enough two separate 32 byte buffers are created. As I have never seen this covered so I assume I’m the only person in the world who’s ever sent 32 bytes via I2c… but if you’re about to try the same – and you’ll need to if you want to try my peripheral software, then I suggest despite the deep hole this will leave in RAM (all 2K of it) – making both of these 128 bytes.

Since amending and re-compiling – I can now send long strings to the Arduino absolutely to my heart’s content!

{nano:9,7,"how are you today and the weather is nice - NO REALLY it certainly is.",0}

Around 15ms in total – not stunningly fast but fast enough not to interfere with the running of anything.

For more on I2C – see the blog entry “Faster ESP I2C”

Midweek Ramblings

August 17, 2016hardware, home control, i2c, Temperature loggingHome Control 2016 mid-week ramblingsPete

Following my addition of the BME280 code to Home Control 2016, a couple of guys have suggested they might like to see more accuracy than the integer I use for temperature so I’ve added a new polled value {hightemperature} which is simply the temperature value *10 – but with that extra accuracy – so for example hightemperature mod 10 would give you the decimal point. Not sure I see a need for even higher precision so we’ll leave it at that – personally I just use temperature to the nearest degree.

I’m also playing as you know with port expanders and having already ran out of ports I’ve added an experimental additional 8 port outputs via one of those cheap port expanders I referred to in a previous blog entry. So assuming this is set to address 38 (typically that’s switch 3 set to off, the others set to on) you can do simply control of out17 to 24, bearing in mind these things start off as inputs floating high.

I’ve not attempted at this point to store values in FLASH or preset them on power up – let’s see how much use this gets.

See the Home Control 2016 manual for updates.

On a different tack, this might seem obvious to the hardware guys here and it should have been obvious to me as I’ve been working with electronic hardware since I was old enough to think - but I made the mistake of getting lazy recently – on my new pergola. I set up on of our boards with a cheap Chinese relay board on GPIO12 – to control a water mister (it gets hot here). So I would use the timed outputs for example {out12:6,2] which sets output 12 on for 2 minutes before timing out back to OFF state.

I had the water fittings all set to go, got my Imperihome App out, pressed the button and sure enough – excellent misting. I pressed the button to turn the mist off and…. nothing.

I figured a jammed relay – but no. Out of desperation I checked the actual state of the port as set in memory – and it said the output was on – but I’d turned it off – this was impossible. I sat and went through the code over and over – no issues.

I made the classic mistake of assuming the hardware was perfect and it had to be a software issue. In FACT, even though the misting system was kind of isolated from the board by the little external relay board, said relay was powering a 12v washing machine coil – and as it turns out the backlash from the coil was having the weirdest effect on the board – stopping that port turning off – to this day I still can’t explain it as it was actually affecting storage of info in the chip. I can only assume a voltage spike getting back to the board itself.

I know, sounds daft, so I put a diode across the washing machine solenoid – something I should have done in the first place. Immediately – 100% perfect operation tested over and over. Worth knowing about. See purple diode below.

Also added {reset_config} command so that from serial you can reset the board to defaults - for security this will not work from MQTT.

I2C Continuum

July 31, 2016Arduino, ESP12, ESP12E, ESP12F, ESP8266, i2c, LCD, OLEDI2C LCD for the Home Control 2016 projectPete

Updated August 07. 2016: This article which started off discussing the “new addition” of i2c to the home control software, is now NOT ONLY about an I2c 2/4 line LCD display facility recently added to the ESP8266 boards – but there’s a PARALLEL version as well, making use of GPIO 4,5,12,13,15 and 16. And NOW – I’m adding a pretty crude interface for the Seeeed OLED displays with other OLEDs to follow.

Comments below about format apply equally to the I2c and parallel versions – for the latter, simply use device 255. Note when you do that you lose GPIO13 as an indicator automatically until next power-up.

Success with I2c – once I realised there was something up at the Arduino end which I could work around, my ESP8266 I2c endeavours have been coming on in leaps and bounds!

And here is my test rig – or one of them – I have one for I2c display and another for parallel display - the latter is just as messy and has more wires:

So what you’re looking at there from top to bottom – is a prototyping ESP8266 board (the author will recognise it) just because I had it handy – ESP-12 based, running my rapidly developing software (which now has loads of spare RAM thanks to the SDK 2.0). I put a simple set of i2c commands in there then promptly realised that a series of commands sent by MQTT would not be a lot of use. I then proceeded to waste the day, having already talked successfully to an 8-bit port expander, trying to get one of those back-of-an-LCD I2C boards to work – as it was based on the same chip.

After several hours of considering taking up brick-laying I realised the damned thing was bust – and went off in search of my cheap Chinese port expander – that’s the red thing you see in the middle. The only difference is this does not have a transistor to power an LCD backlight so I just hardwired that. At the bottom – the original test 4-line LCD. Over on the right, an irrelevant Arduino-type board which is also talking I2c successfully.

Having decided I liked the idea of plugging one of the cheap LCDs onto the odd home control board for information purposes, I set about doing something I’ve never done before – reading the Hitachi data sheet. These things are quite cute once you get over starting in 8-bit mode then switching to 4-bit to save on wires etc… (so in total you only need 6 signals to talk to the LCD) and after some timing experimenting (clear screen command takes a while – over 1.5ms) as you can see I finally have a working LCD – and by the look of it, rock-solid reliable.

So what is driving that display (which is updating every second virtually instantly)…

This:

and inside that inject?

Topic: freddy/toesp

Payload: {hitachi:39,"$1MQTT test$2$i$3Time $t$4Date $d"}

For clarification - that is a string - which starts and ends with "{" - it is not JASON or ann object. So if you want to send this from, say a Node-Red function you'll have to consider escaping strings.

You might wrap the whole thing in single quotes for example.

That’s all. So assuming you’re familiar with MQTT (if not – look at other articled in here) the destination is the little board “freddy” – and the new command I’ve just added – “hitachi” talks to an i2c board (the expander) device #39 and sends out that string.

Rather than have a boatload of commands which would be unwieldy in the home control setup – or special characters which might cause issues – I used the dollar as an escape character. Here’s what I’ve implemented up to now

$$ - well that shows a dollar on the screen !!
$s - setup – sets up a virgin LCD and clears the screen
$c - clear the screen
$1 – set the cursor to line 1 - ($2 $3 $4)
$t - fire out the time
$d – fire out the date
$i - fire out the current ip address

I’ll probably settle on a 2-liner as they are sub-£2 from China – indeed for 20-off just over £1 – and at £1.34 for the port expander – around £3 to add a nice little display to some of the ESP8266 boards – can’t be bad. indeed, using one of the port expanders for an ultra-low-cost i2c keypad isn’t a bad idea. 45p for the keyboard, £1.34 for the expander… Sub-£2 keypad.

Clearly one way to wipe a line would be “$1 $1” which is probably fast enough for most purposes. I’ll likely think of some more commands.

A reminder that the right hand side of this blog contains links to the Home Control 2016 project, ROMs etc.

And now I have this big decision.. whether to spend £1.34 on a PCF-base port expander… which I need to poll regularly if attaching a keyboard – and no spare pins for a beeper – OR to spend £1.68 on an Arduino Nano which can be turned into an I2c peripheral (granted I might need 2 pull-up resistors) with keyboard buffering and a beep facility….. OR…. go the whole hog and use another ESP8266 to make a completely wireless keypad.

And on that latter note – if you abandoned serial I/O which would net one more output – that gives up to 10 control pins – enough for a keyboard and beeper and light. Hmm…£1.43 for an ESP12, 17 pence for a 0.1” adaptor board. Fully buffered keypad…. Big decision…

And finally – device 255 is reserved for a PARALLEL version of this using 6 GPIO pins – 3,4,12,13,15 and 16 – operation is identical. All in the code – including the OTA ROMS. Documented in the WORD manual.

Update: On the right you see a Seeed OLED – I starting with this library, code intended for Arduino, I’ve heavily modified it to run in the normal ESPRESSIF SDK environment – but I have to say – the original Arduino version was SLOW, so VERY slow and this is still a little slow – especially the screen clear – I’ve pulled that into one function with an inner loop of I2c bytes, way faster than the original but even THEN it is hardly nippy – but the important thing is that “Hello World” works – so soon I’ll add the above commands and then figure out a way to speed it up. Right now I can manage {seeed:”Hello world”} or similar. Current software and ROMs are on the web.

I2C Conundrums

July 28, 2016i2cI2C ConundrumsPete

Resolved - working though still don't know why Arduino single write was causing problems - however - got a way around it.

Firstly why am I doing this i2c thing? Well, the little ESP8266 is a wonderful thing but there are some chips out there that are really neat and work on I2c. More’s the point there are some REALLY cheap and powerful Arduino-compatible boards out there which benefit from the vast wealth of Arduino libraries – but don’t have WIFI..

So it occurred to me to add an I2c interface to my software – to talk to the likes of the Arduino.

And that it does – kind of – but I’m hitting a brick wall on return data. That is, return data over one byte – well, kind of… let me explain.

The ESP i2c is of course bit-banged because the chip itself does not do I2c – but it is fast at 80Mbps so you would expect it would work without issue. I am using the i2c master software that comes in the Espressif SDK – I’m using version 2.00. I’m programming in C.

The Arduino code is using the latest Arduino IDE 1.69 and straight forward WIRE code. This is the SLAVE.

I can send multiple bytes to the Arduino - no problem - and I can get a byte back into the ESP no problem.

Now bearing in mind that [a] my experience with i2c is minimal [b] the Arduino I2c looks completely different to the ESP I2c....

When I first wrote this – I was getting reboot problems with the ESP when trying to return multiple bytes. Not every time – just every now and then.

I checked my code and I am initialising the I2c every time I use it – for various reasons. When I put a logic analyser on the 2 i2c lines, I could see what looked like good i2c – but at the start, a whole load of clock pulses. 48 of them in fact. I went into the Espressif code only to find a loop in the initialisation – (it is in i2c.c).

void ICACHE_FLASH_ATTR
i2c_master_init(void)
{
/*
uint8 i;

    i2c_master_setDC(1, 0);
i2c_master_wait(5);

    // when SCL = 0, toggle SDA to clear up
i2c_master_setDC(0, 0) ;
i2c_master_wait(5);
i2c_master_setDC(1, 0) ;
i2c_master_wait(5);

    // set data_cnt to max value
for (i = 0; i < 28; i++) {
i2c_master_setDC(1, 0);
i2c_master_wait(5);    // sda 1, scl 0
i2c_master_setDC(1, 1);
i2c_master_wait(5);    // sda 1, scl 1
}

    // reset all
i2c_master_stop();
return;
*/
i2c_master_setDC(1, 1);
}

I have absolutely no idea why that is in there but it does not appear to be part of the I2c specification – so I cut it out – all that’s needed at the beginning as far as I can see is for data and clock to be high. The main init routine which calls this one (i2c_master_gpio_init()) sets the pins up the right way (pins 4 and 5 by default).

Well, this did not seem to have a lot of effect – except that now I can’t crash the ESP8266.

So – I can send data to an Arduino with I2c slave running – and I can receive a byte back – wheeeeee.

If I return one byte to the ESP - all is fine - works perfectly – but then the rot….
So --- Arduino...

//function that executes whenever data is requested by master
// this function is registered as an event, see setup()
void requestEvent() {
Wire.write(retParam); // *****
}

That works – and now the ESP

i2c_master_gpio_init();
i2c_master_start();
i2c_master_writeByte((arg1<<1)|1);
if (!i2c_master_checkAck())
{
i2c_master_stop();
os_sprintf(strValue, "duff i2c");
}
else
{
uint8_t a;
a=i2c_master_readByte(); //*******
i2c_master_stop();
os_sprintf(strValue, "%d",a);
}

That also works... but add another write for the Arduino where I've put stars *** and another read in the ESP code where I've put stars – even with a i2c_master_send_ack() in between - it does not work – the second byte is returned (not the first) and then a 255 is returned.

So here is the multi-byte return on the ESP side..

a=i2c_master_readByte();
i2c_master_send_ack();
b=i2c_master_readByte();

i2c_master_stop();
os_sprintf(strValue, "%d %d",a,b);

Sending 2 bytes from the Arduino…

void requestEvent() {
Wire.write(33);
Wire.write(45);
}

FAILS!!!

This however SEEMS to succeed and since my other change – seems to work reliably.

Wire.write("This is it you know",X);
// where X is how many chars to send out - I've tested 19 chars repeatedly.

In the above I’m just returning the first 2 bytes of course and this can be turned into byte arrays or whatever..

But the question is – WHY does the first version screw up?

Anyway here is the ESP code that works with the above where X is 19...

i2c_master_gpio_init();
                  i2c_master_start();
                  i2c_master_writeByte((arg1<<1)|1); // send a read command
                  if (!i2c_master_checkAck())
                      {
                          i2c_master_stop();
                          os_sprintf(strValue, "duff i2c");
                      }
                  else
                      {
                            uint8_t buff[40],a;
#define I2CINB 19
                            for (a=0;a<I2CINB;a++) {
                                buff[a]=i2c_master_readByte();
                                if (a<(I2CINB-1)) i2c_master_send_ack();
                            }
                            buff[a]=0;
                          i2c_master_send_nack();
                            i2c_master_stop();
                            os_sprintf(strValue, "%s",buff);
                      }

Lovely – now I need to find some i2c chips to experiment with. I have an ATMEGA1284 setup to respond to i2c for port input, output with PWM and analog in where appropriate – the 1284 you may recall has a lot more pins than the Arduino. I have a few variations of miniature boards on the way to test. When I really go to town on this I’ll no doubt blog it.

Sunday Morning Experimenting

July 17, 2016ESP32, ESP8266, i2ci2c expansion for ESP8266Pete

I figured after a couple of horrendous days figuring out what was wrong with my ROMS, it was time for a morning’s relaxing. Some time ago I added I2c to the Home Control software but never actually got around to doing anything with it. The i2c parallel expansion modules I got from Ebay have their own pull-up resistors on them… could I get away with hooking 2 boards up without having to dismantle surface-mount pull-ups on on?

So first things first I wired up some test LEDs comprising a some AQUA LEDs I had lying around and 120r resistors. I looked all over for pre-made leads with female 0.1” connectors on them but as usual ended up making up my own. If anyone knows of a good cheap source of these – do let us know in here.

Next stop I needed a test board and the obvious one to use was one of the samples I got from Bob Elmour.

A few extra ground, 3v3 and 5v lines (0.1” connector strip) along with GPIO4 and GPIO5 brought out and I was in business. Ok, not the prettiest layout but good enough for testing.

And… yes, I’m not sure I’d want to go beyond two without removing resistors – but they work. With one DIP switch set to ON-ON-ON and the other to ON-ON-OFF I found I could easily use i2c to turn on and off LEDS on both boards at addresses 39 and 38 respectively.

It is worth noting that the output DRIVE capability of the little red boards is not that good (as the outputs are also used as inputs with pull-ups) and so to get a decent output I fastened the LED + leads to +3v3 and used the expander boards to SINK current (which means the output logic is inverted).

Using the come control software, lighting up those 4 LEDS is simple.

{i2c:39,0,3}

{i2c:38,0,3}

(The zero is a recent addition and simply says there is nothing being returned. See future blogs for more extensive use involving multiple parameters and an optional return value).

So for the loss of 2 wires, you get 16 outputs using I2c and at a cost for boards of around a fiver. Not entirely sure how well that compares to sticking an ATMEGA24560 onto the ESP and doing some custom software to let you control the outputs (I have thought about this)… but it is certainly one easy way to get more inputs and outputs.

Scargill's Tech Blog

Anything to do with gadgets – the stuff that gets me up in the morning full of enthusiasm