Monthly Archives: July 2016

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.

Node-Red on a Phone

July 30, 2016Node, Node Red, node-red, node-red-dashboard, node.jsNode-Red on a phonePete

I have to hand ALL the credit to Dave at the Node-Red Google Groups for this – and you might want to pop any questions in that direction because I know even less about running Android at the command prompt than I do Debian!

Running Node-Red on your Android phone or tablet!! Yes you CAN. it turns out that it is dead easy. Using a terminal program (App store) such as Termux.

So basically install Termux as you would any other app.. and run it – you get the usual black terminal screen. I did this just now on my HTC ONE-M8 – might work on yours – might not.

apt update
apt upgrade
apt install coreutils nano nodejs
npm install -g --unsafe-perm node-red
node-red

That’s it - you’re up and running.

Well, so that is Node-Red running – of course if you close the terminal you stop Node-Red so the first thing to find out is how to press control-C in that terminal!!! Any ideas anyone?

Once I got back in – instead of starting Node-red I did the following..

cd .node-red

npm install node-red-dashboard

npm install node-red-contrib-admin

npm install node-red-contrib-bigtimer

cd

node-red

Once you run node-red – you can go into the browser on the phone and run 127.0.0.1:1880 and lo and behold- node-red - probably more usefully would be to go to the phone’s WIFI setup and find out what the IP address is – and run Node-Red in a browser on your PC and that same port number.

Now why on EARTH would you want to do this. Well, if you could get node-red running as a service on an old tablet – along with MQTT (not sure about that one) all as services – you have a home control server base – with several hours of reliable battery backup (you’d have to run a task to stop the thing turning off I guess.

Well, something for the weekend! As answers (hopefully) emerge for the following – also running my phone with SCP from the PC would be good… I’ve no idea what the user is or the password!!!! I’ll update this.

And the first update – control characters on that terminal… here.

Meanwhile – MQTT Broker Pro which will soon have it’s own basic authentication and which already comes up on phone boot – works a treat – here are the two of them running together as seen on my PC browser.

Be aware – that the MQTT server does not work if you use “localhost” – you need to use “127.0.0.1” or if you want to access the MQTT server externally – the IP address of the phone. And yes I’ve tested accessing the MQTT broker externally – which is another good reason for it to have a user name and password.

All good stuff.

Nextion Update

July 29, 2016ESP12, ESP8266, nextion, node-redNextion Display RevisitedPete

As you may know the home control software can work with Nextion displays and there is a project on the blog on that subject – I note that one or two people are having issues here so rather than reply without pictures - here’s a general update.

Currently with the home control software, version 1.531 (see right) and Nextion Editor version 0.36 (it just updated on my automatically) and I’m doing this on Windows 10.

After powering up the home control board, you MUST for the first time issue the instruction {set_serial:2} to the ESP8266 at which point the board will reboot and part of the start up serial info will show as on the right – “Initialised software serial to 57600 baud” – this indicates that the unit is ready to work with the Nextion display. GPIO4 and 5 are used for this purpose and the Nextion board can be powered directly from ours. Ground, to_nextion, from_nextion, 5v – that is how our board is marked but of course you don’t need to use our board. Incidentally don’t be tempted to use your 5v FTDI to power any but the smallest of Nextion boards – I tried this on the large 7” model and killed the FTDI…you’ll need a separate (common ground) power supply for that and most likely anything over the 4.2” display. Don’t forget to change that set_serial command if you plan to use GPIO4 and 5 for something else as the setting is stored in FLASH.

In a simple test I have a plain Nextion panel with two buttons on it. In the background to the page – in the Nextion Editor – I have a “preinitialize event” which contains nothing more than “bauds=57600” without the quotes – this ensures the Nextion board powers up at 57600 baud for the purpose of sending data back and forth.

The two example buttons are marked “up” and “down” and the “touch press event” for each is as follows..

get "nodered~up"

and

get "nodered~down"

If you look at my documentation - this is a notation I created that returns the above – for example the first one, to the ESP8266 and converts that into an MQTT message:

topic: nodered

payload: up

That’s it – press the up button and the message “up” is sent to topic “nodered” – could be any message you like – and any payload. You can use this directly to turn things on and off without even passing through Node-Red – OR you you have node-red intercept the incoming MQTT message and do something with it. So pressing a button might have an effect on the Nextion display for example. If you see the Nextion WIFI touch-display project you’ll see you can get WAY more ambitious than just a couple of buttons.

And lo – as I press buttons – you see the messages coming into MQTT-SPY (or whatever you use to test your MQTT).

That just leaves output to the Nextion itself from the board.

Again for the purposes of demonstration I add a text box in the Nextion editor – the default name for the first new text box would be “t0” so I rename this to “mytext”.

Not very pretty and normally I would NOT use their buttons etc. but make up my own imagery using PowerPoint or similar – but it’ll do for demo purposes.

Now I have to say, the worst part of this is the Nextion editor – progress is moving slowly with this – when you come to program it – make sure you have the right port address because it is hopeless at searching – and if it gets stuck you end up using task manager to reset it – comes up as PRJ or something – I’d so like to get my hands on the source code to give it a good shake-up.

Anyway, there it is- you end up with a window in this case with default text “newtxt”.

Fire out the command {to_nextion:"mytext.txt=\"Hello\""}

You can do this serially or via MQTT- as the example from MQTT_spy shows.

This results in “Hello” without quotes appearing in the text box. Why the backslashes – that is to “escape” the quotes so they don’t end up terminating the string above – in other words so the quotes are passed through.

The WORD manual for my software describes the “to_nextion” and “set_serial” commands.

Have fun.

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.

Node Red Dashboard

July 27, 2016node-red, node-red-dashboardNode-Red-DashboardPete

As regular readers and fans of node-red will know, I’ve been a fan of node-red-contrib-ui for some time – I wrote about adding security to it some time ago and until Imperihome came to my attention I was developing pages based on this. But, sadly the fellow developing it ran out of time I guess. One day he was working hard on it – the next – nothing.

Some time ago I became aware that the Node-Red guys were developing this and today they announced that Node-Red-Dashboard was available on NPN.

If you have node-red-contrib-ui on your Node-Red installation – and are not using it – simple uninstall.

I stopped Node-Red, in a terminal went to my .node-red directory and..

npm remove node-red-contrib-ui

npm install node-red-dashboard

That simple really, at least it was for me – unless you’ve heavily invested in the former there is no point in keeping it any more as development has stopped. So – what’s new – well, it is early days, if you don’t like simple light or dark – well, that’s unfortunate because right now you have two theme options – but that’s a start and the gauge and graphs shown above right took seconds to set up with this simple set of nodes – a couple of injectors firing out 2 numbers – and the gauge and graph nodes – that’s it.

Dashboard looks remarkably similar to node-red-contrib-ui and time will tell how compatible it is but the gauge alone has been markedly improved and is lovely – you can control size, there are four different types of gauge – it really is easier to try it out than to discuss. There is now a simple dashboard on the right of the Node-Red web page to allow you to re-arrange items by drag and drop – this is a great improvement.

You’ll be making simple pages of imagery in no time – as for actually making worthwhile dashboards – well I suspect that will be down to how good the documentation is.

Let us know your experiences with this.

WIFI Smart Socket

July 18, 2016itead, sonoff, wall socket, wifi wall socketItead WiFi Wall SocketPete

It looks like Itead have done it again – another winner – well that’s all down to the price and I’ll leave you to look that one up…the site says £9.76 for the unit which is reasonable – but I didn’t check postage.

The first modern WIFI wall socket I had was the Orbvibo Smart socket. I could not re-program it but I did manage to get Node-Red to talk to it over a websocket interface. I think it lasted a week before losing the info, then I discovered that Amazon had stopped selling them because of some regulation or other. Not a nice experience – but they DID look nice.

Similarly – the Itead unit is good looking (though you would not tell it was theirs based on the one I have – there’s no reference to Itead on there at all and there were no instructions in the (very pretty) box. Probably because this is new (but available). This is an EU socket not UK so if you’re in the UK you’ll need a simple adaptor unless you want to live dangerously.

There is a programming button – which handily goes to GPIO0 on the ESP8266. Again a slight gripe here, once again they’ve used a 1MB FLASH - fine for their purposes but if ONLY they’d used the same as the ESP-12 (4MB) I could have done OTA – I believe there is other software that might be suitable which fits into the smaller space. However – not that big a deal. When my new 4MB Flash chips turn up I may just replace theirs.

The Smart Socket is designed to work with Itead’s APP – and if that’s what you want – read no further. It makes for a nice cheap WIFI controlled socket.

In my case of course I wanted it to work with our own software and hence remotely over Node-Red and MQTT – I suspect readers in here will want the same. So – out with the screwdriver – it turns out this was to be incredibly simple, once screw then finger-nails in the edge and it pops open – there’s a 4-way set of holes which you can just shove wires into – ground, TX, RX and VCC. I applied the relevant wires from my FTDI (obviously RX to TX etc) to the holes – ensuring that [a] my finger was on the programming button at the time and [b] my FTDI was set to 3v3 – not 5v (important). I blew the ROMs into the unit – this is covered elsewhere in the blog and is easy) and lo – one WIFI controlled switch I can control over MQTT etc.

I mean – it was that easy - I’m missing the bit out about making a change to my program to slow the flashing light down as the lights in this thing are BRIGHT. So the green light is the general indicator (GPIO13) which I use all the time (thank heavens) and as in the SONOFF they use GPIO12 for the relay AND a nice blue light – so when the unit is running it is flashing green – if the output is on there is also a blue glow. Very nice.

So – there you have it – another winner. It’s all down to postal charges really… oh, the relay claims 2KW – I’ll leave it up to someone else to see if it is up to that – I’d suggest that putting a 2KW electric heater on it will probably not work too well. It would be nice if a 1KW heater would work… anyone up to testing that ?

ESP8266 Meets Arduino via I2C

July 17, 20161284, Arduino, ESP-12, ESP-12E, ESP-12F, ESP8266Arduino ESP8266 and I2CPete

If you’ve been reading the blog regularly you’ll know I added I2c to the ESP8266 code some time ago – that is, the ability to send an I2c message either to read or write – originally intended and still working with cheap I/O expanders – so you lose 2 wires (GPIO4 and 5) and gain another 6 or 14 for one or two I/O expander boards.

Well, I’ve updated it as of tonight.

Of course, ESP12 talking to Arduino is nothing new but given what we’ve built up here with the ESP boards and Node-Red I thought it might be useful to have the option to expand further.

What a few hours ago seems like something in the distance – well, it is done – and it works – and it has LOTS of potential. Read on.

What you see above (the FTDI is just stuck into the ESP8266 board for power) is a 1284 Aiduino boards flashing lights - controlled by MQTT – that is, the ESP12 board on the RIGHT is taking in the MQTT and sending commands via I2c to the 1284-based board and to the little red expander in the middle (on the same 2 pins).

Hence, I’ve spent the day working on the I2c code adding the ability to send multiple byte parameters and to receive a byte (I could have made it receive multiple bytes but for simple control a byte will do).

The next step was to set up an Arduino – or in my case specifically an ATMEGA1284 chip to talk to the ESP – hence giving us the ability to control Arduino ports via Node-Red. Now as yet another blog entry here will testify, you can of course connect (now that the node is fixed) an Arduino directly to the Raspberry Pi in charge – but puts too many physical constraints up. I had no intention of developing Firmata on the ESP – and so a simple i2c protocol was develop and SO much more can be done.

Right now I have an ESP8266 on the bench with a 2-wire I2c connection to an I/O expander – and an Arduino-type board using the 1284. I can talk to both from the ESP (and hence from my Arduino wirelessly via MQTT) and can control the following:

Any pin as an output (and PWM outputs where appropriate
Any pin as an input (and analog inputs where appropriate)

So first things first – I used the Atmega1284 simply as I have loads of them – both DIP40 and surface mount in our little AIDUINO boards. The 1284 has twice the RAM of a 2560 and is easy to use. However this would work equally well in a normal Arduino or in the massive 2560 boards.. the only difference being which two pins are used for i2c. The red chart above, shamelessly stolen from ManicBug’s website shows the pins (in parentheses the numbering system I use).

So in the ESP8266 (grab the latest ROMS or SOURCE) I have a simple method of communication which can be used by MQTT or serial. The format is similar to that used elsewhere in the home control system.

i2c: device, return, param1, param2, param3, param4, param5.

Not all parameters are needed.

So – to talk to an i2c expander sitting as device 39, connected to pins 4 and 5 of the ESP board…

{i2c:39,0,3}

device 39, no return value, send out 3 (which lights up the bottom 2 LEDS.

{i2c:39}

This returns the value in the port expander. this is covered in two previous blogs.

https://tech.scargill.net/sunday-morning-experimenting/

https://tech.scargill.net/i2c-expansion-for-raspberry-pi/

So what has changed is that the code can now send out multiple parameters – and optionally receive information back.

{i2c:8,0,1,20,1}

The above sends out to device 8, expecting nothing back, type 1 means set a port bit, bit 20 in this case (see red table above) – to 1.

{i2c:8,1,4,30}

Above – device 8, 1 means return a byte, type 4 means read analog value and port number is 30 – the instruction will return the value of the analog input.

1 is digital out, 2 is digital in, 3 is PWM out, 4 is analog in – you must use appropriate ports – not all are able to handle analog in or PWM out… and you don’t have to worry about port direction setting – this is checked before any operation and set.

There is SO much more potential here but only so many hours. I will likely make the settings for outputs non-volatile at some point – and add in all manner of device monitoring and probably also make use of the multiple serial ports on these devices.

For now that’s not bad for a Sunday session. If you’re seriously interested I’ll make the Arduino code available but right now it is highly volatile – but it works!!

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.

ESP SDK and RBoot Woes

July 16, 2016GeneralEspressif SDK 1.541Pete

Remember I did an article entitles Serial Woes? Well that’s been changed to serial success as we found bugs in tools and gained an understanding of the USB FTDI handshaking lines – which altogether led to improvements in the Node-Red Arduino node and a completely working solution for USB Serial on the Raspberry Pi.

Well for the last few days I’ve been at the WOES part of a serious issue with our ESP8266 code. I’m hoping if Espressif see this and Richard of RBoot fame see this and we can get a little interaction – so that what looks like an issue with Espressif SDK 1.5.4 and Rboot can be resolved. I’ll update this as we go along.

So – those of you who’ve been reading this blog for a while will know that I’ve put a lot of work into developing my own code (along with a lot of help from others) for the ESP8266 to control ESP-12-based boards designed by Aidan Ruff – the software talking via MQTT back to a central controller – this is all working and is regularly updated. The software is BIG (well over 0.5 meg and hence for OTA purposes needs boards with a 4MB FLASH like the ESP-12 though currently it will work without OTA on the likes of the Sonoff controllers) – and is available as source code and .ROM files.

So a few days ago some guys in the blog wrote in to say they were having horrible difficulty flashing my ROMs and indeed that their boards were apparently broken!!!

I could not replicate this behaviour – I would take my ROMS, blow them – and all was well, my code worked. The code uses Richard Burton’s RBOOT to allow for OTA (over the air updating).

And then… I tried blowing the ROMS into a virgin ESP8266 board (and I mean virgin with no software on it – not one stocked with AT software). DEAD. But not just dead. Dead sometimes… and when it worked – it worked kind of.

Here’s what I mean. Look at the first image above – that’s a normal boot up of my code. “ESP starting…” some info on the use of GPIOs etc., software version and right at the end, another function is called which outputs “Web page control enabled” (or disabled).

Now look at the code below.. this is the output when I CAN get the code to work with SDK 1.5.4.1.

Do you see what is wrong – the “web page control enabled” message comes up FIRST – you might say that is IMPOSSIBLE – that code does not run until after the other stuff is all done… and there are bits missing – but more often than not the code does not run at all - and that is what pointed me to the problem – and the “solution”.

Here are sequences of events..

Start with an existing ESP
Flash my code
Output probably ok
Start with something like the NodeMCU software rom
Flash my code
Output seems ok but has the above nonsense (but works)
Entirely WIPE the FLASH (yes, there is a quick way)
Flash the new code
Nothing works
Load the NodeMCU rom (works mainly)
Flash my code
Works sometimes – might not work after reboot – but might.

This is cutting a LONG story short – a story of using various programs to try to wipe the 4MBYTES of the ESP-12 only to find in one case that the final meg would not erase – or in another case that no matter what address you put in it was always ONLY the bottom MB that was being erased – that wasted a few hours I can tell you!!!

Finally I hit on this – more by accident than anything else:

C:\Espressif\utils>esptool.py -p COM3 -b 115200 erase_flash

This took an instant and appears to wipe the entire Flash perfectly.

Even using the official tool would seem to work – but when you watched the addresses go by – it was obvious that only the bottom 1 meg was being erased!!

But I digress.

So when I finally got to analysing the problem (scratching my last hairs out) and realising that something was wrong – maybe a start up vector in RAM not being set properly, I decided to try something – instead of using the latest Espressif SDK 1.541 (which coincidentally I loaded and compiled at about the time people started griping about non-working boards – but of course I was simply OTA-ing my existing, working boards and seeing nothing) – I went back a version to 1.53 – and….

IMMEDIATELY (thank heavens) the problem went away – I could now program the boards in the normal way and they worked (work) perfectly.

So at www.scargill.net there are some working roms using SDK 1.53

rboot.bin and romx.bin

The above work (for example http://www.scargill.net/romx.bin)

Here is the same compiled under 1.541

rboot_duff_154.bin and romx_duff_154.bin

These are the ones that were up there until now – and were giving trouble. I’ve just renamed them. Easy to test – put the first at 0x00000 and the second at 0x2000 (that’s 0x2000 NOT 0x20000) after running that erase procedure above – and one will work – the other will not.

So – the question is now – is there something wrong with the Espressif SDK 1.541 – or have they moved or changed something that is giving Richard’s RBOOT (which has not changed for a long while and which has proven to work perfectly) trouble. Surely it has to be one or the other. My impression, rightly or wrongly is that the code is starting up in the wrong place – sometimes in the middle of no-where, sometimes almost in the right place (hence the re-arrangement of output).

I’ve pointed both Richard and Espressif to this as it is possible to replicate the issues quite easily on an ESP-12 (my viewable serial output at powerup is 115k baud after the usual 78k debug info).

Hopefully this will become a shorter success story with a fix somewhere. If it is affecting my code – it has to be affecting other code (and no I’m not running out of variable RAM – thought of that). Right now I simply cannot use SDK 1.541

Thoughts?

NanoPi M2

July 15, 2016UncategorizedPete

More from FriendlyArm – this time the NanoPi M2. I’ve had this board running both Debian and Android – but first – a little about the boards. Like the M1 these are small – around 65mm by 60mm so much smaller than Raspberry Pi. They are also cheaper than the Pi but but this time more powerful than the M1 and most likely the Pi, also.

Unlike the M1, the board comes with a connector for FriendlyArm’s touch-LCD display and also unlike the M1 which comes with an awful Android with no Play Store, this one is a 5.11 version with full playstore. I’ve tried it with BBC video and it runs flat out so I have no doubt this would make a media centre for anyone interested. Indeed I’m waiting for a wireless keyboard/mouse arrangement turning up and one of these might just end up as a media centre.

The board has 2 USBs connectors and it has 0.1” connectors on board for a further two. It has up to 1GBPS Ethernet connection, audio jack, microphone, camera connector, standard HDMI out and a microSD slot on the underside. Mine came with 1GB RAM. There is also a header for a serial console.

The processor is a Samsung S5P4418 quad core Cortex A9 running between 400Mhz and 1.4Ghz. There is also a Mali GPU. I’ve not yet done speed tests but I’d expect this to give the Pi a run for it’s money – again – how they compare depends on postal charges in your area.

My next step will be to install my usual software script on this board in Debian and we’ll see then how easy or otherwise it is to get port and serial access. Keep looking in.

Raspberry Pi Node Red Serial Delight

July 15, 2016Raspberry Pi 2Pete

Or – how to get USB serial ports working on the Raspberry Pi

This originally was a cry for help – I wanted a second serial port on the Raspberry Pi AND I made the mistake of trying out Firmata on the Arduino at the same time – resulting collection of failures had me scratching out my few remaining hairs – but thanks to a lot of work – two lots of changes to the Arduino node itself and some reader insights in here, I can now confidently say that:

1. You CAN add more serial ports to your Raspberry Pi

2. You CAN talk from the Pi (or similar) to Arduino gaining access to ports for things like port on/off, PWM etc. with ease.

It all started when I innocently plugged a USB FTDI into the Raspberry Pi USB connector to give me a second serial port to play with as I was using the first one to talk to a Nextion display. I checked in Debian in the /dev directory and it up came /dev/ttyUSB0. When I checked in Node-Red it came up with the same – magic. Great start.

I added in the serial node to Node-Red – set up an inject – and a debug node.

I shorted TRX and TX on the serial and… nothing.

(Serial set to a decent baud rate with 100ms timeout).

I could see on the FTDI flashing lights indicating that not only was data coming out - but also going back in.

I decided to test this and hooked up the internal serial on the Raspberry Pi. I had mistakenly thought that the graphical control in the new Jessie allowed you to turn the serial login terminal on and off – so I turned off serial. BAD mistake – not only did the serial not work but the GPIO node failed as well! I turned the serial back on – rebooted, back to square one.

I updated /boot/cmdline.text to remove reference to the serial port… and read THIS - so now I had serial working.

I tested as you see above. I shorted TX and RX on the internal serial – and sent some text – smashing – the text shows up in the debug.

So now I connected the serial out from the USB serial – to the serial in on the Pi (ensuring 3v3 output) – MAGIC – that worked.

So all that appeared to be NOT working – was the serial in on the USB FTDI serial – yet there are were error messages.

Is this familiar to anyone? I tried various combinations of the RTS and DTR lines – no difference. All looks fine and connected but the USB0 serial in appeared to do nothing.

Stage 2:

I took out the FTDI - put another one in - that appeared as USB1 (yes, the SAME ONE)... but it worked - I took that out and plugged the ORIGINAL back in - now this appeared as USB2 and worked – but how the hell are you supposed to use a port if it keeps renaming itself. Read on.

I rebooted the Pi (NOT removing power, just rebooted) - it went back to being USB0 - it worked. I turned the power off, them on - no serial in.

So…. I took the FTDI out - and put it back in - now it appeared as USB1 - adjusted the setting on Node-Red accordingly - it worked. Rebooted…No USB 1 – looked in the node settings – USB0 was back. Adjusted. All was well on USB0.

I turned the power back off then on (for the whole lot)…. Green connected lights on the in and out nodes, all’s well – BUT – no input. I could again see both lights on the FTDI indicating that it is not only sending but pulling back in – but nothing in the debug window when injecting text.

But this had WORKED after a reboot… but not after power up… so – I tried rebooting again…surely it would work? No.

I pulled the FTDI out – and plugged it back in… USB0 disappeared but USB1 was valid…. I changed the node to work with USB1 – it worked.

So it seems that the only situation when the input would not work – was when both the Pi and the FTDI had been powered down and back up. Which of course is every time you turn the stuff off and on!! And the name was changing – which is just useless.

The Solutions:

Well, thanks to readers in here I managed to split this problem down into sections. The first was this issue of the name keep changing. As it happens this one is RELATIVELY simple.

pi@bedrock2:~ $ sudo lsusb -v | more

Bus 001 Device 005: ID 0403:6001 Future Technology Devices International, Ltd FT
232 USB-Serial (UART) IC
Device Descriptor:
bLength                18
bDescriptorType         1
bcdUSB               2.00
bDeviceClass            0 (Defined at Interface level)
bDeviceSubClass         0
bDeviceProtocol         0
bMaxPacketSize0         8
idVendor           0x0403 Future Technology Devices International, Ltd
idProduct          0x6001 FT232 USB-Serial (UART) IC
bcdDevice            6.00
iManufacturer           1 FTDI
iProduct                2 FT232R USB UART
iSerial                 3 A50285BI
bNumConfigurations      1
Configuration Descriptor:
bLength                 9
bDescriptorType         2
wTotalLength           32
bNumInterfaces          1

So looking at the code above created by running the command at the top above – starting “sudo”…

This told me all about the last USB item plugged in – sure enough my Future technology USB FTDI

I made a note as instructed by reader Alex - of idVentor, idProduct and iSerial and put them into a file:

sudo nano /etc/udev/rules.d/99-usb-serial.rules

The one and only line in that file would be..

SUBSYSTEM=="tty",ATTRS{idVendor}=="0x0403",ATTRS{idProduct}=="0x6001",SYMLINK+="ttyUSB-PETER"

Tried it – failed. Of course I was trying to use vendor 0x0403 – when I took off the 0x it worked a lot better. I’ve no idea why. With further help from Alex the solution appeared as

SUBSYSTEM=="tty",ATTRS{idVendor}=="0403",ATTRS{idProduct}=="6001",ATTRS{serial}==”A50285BI”,SYMLINK+="ttyUSB-PETER"

All of that was great – on power up the unit would come up with my chosen name – also after reboot – and after disconnecting.

All worked well…one problem apparently solved…

But… from time to time I would lose the output – the lights on the FTDI would show up – but nothing would come back in to Node-Red. Another reader – Christopher had suggested that in some cases you need to short DTR and DCD, also RTS and CTS. if these were floating and if they WERE important – I could see why I’d be getting strange results. I put links on these.

Voila. Reliable serial connection. It would be nice to clarify why the word “serial” and not “iSerial” – and why you need to miss off the “0x” – but it worked reliably.

Though it works perfectly as a serial port in Node-Red – Node-Red cannot see the new port probably because this is just a shortcut or symbol – if you type it in – it worked – but Node-Red could not (and will not) search for it – not too much of a hassle to put in manually.

But – the ARDUINO node for Node-Red would NOT accept the manual input.

By specifying ttyUSB0 I managed to flash a light with this Firmata-based node – but any attempts to change things around, try PWM on a pin etc. would result in Node-Red dying temporarily. I talked to the developer of the Firmata node as I noted the serial node NEVER crashed Node-Red. Result – thank heavens – a bug – now removed.

Reading a reply in the Node-Red Google group, it was suggested for a while NOT to use the Arduino node but to scrap that and use the contrib-gpio node (the yellow one) – as it happened I had that installed. I used my shortcut (may as well go in at the deep end) – and LO – no more Node-Red crashing.

I tested port digital control as well as PWM and they all worked.. BUT – changing mid-stream – i.e. opening the node and changing the port bit FAILED like the Arduino node – but did not crash Node-Red – this let me experiment a LOT more. I killed the Node-Red service and ran it manually. But at this point, making a change to the node and then running deploy would result in the node sitting with “connecting” and just refusing to connect to the serial port. Simply stopping and starting Node-Red fixed the issue every time.

The author was playing with this and could not replicate this – but it turns out he was using Node-Red’s DEPLOY ALL mode – whereas I just deploy all changed nodes (so my house control doesn’t fall to bits when I’m experimenting). I just had a call to say he can now replicate this.

WHICH MEANS the yellow GPIO node also has this issue! I’ll let them know.

So now that it looks like Firmata will work but does not like change.

Dave at IBM who has been working on the Arduino node has now FIXED this issue in Arduino node version 0.09 (npm install node-red-node-arduino). I have tried port 23 to make sure the MEGA version of this is running – and sure enough – it is running.

Lovely. Multiple Serial ports on the Pi – and LOTS of GPIO cheap add on – what more could you want. My thanks to Dave for quick action and to everyone for their helpful comments which brought us this far.

The node-red-contrib-gpio node has exactly the same issue that the Arduino node HAD – I’ve left an issue in the repository of the latter.

Update September 32, 2016: I have to say that all of this is working exceedingly well, EXCEPT for Firmata on the Arduino. I left my main Raspberry Pi talking to the USB serial and sending commands to flash a light on an Arduino MEGA2560 board via Firmata. Simple enough... we've had power cuts, I've been experimenting with the Pi etc over all this time since I wrote the blog entry and I can see by the FTDI that once-per-second commands are heading out to the Arduino 24-7 - but every now and then, maybe every few days I look up and that light is not flashing. A quick power cycle on the Arduino board brings it back up - but Firmata is simply NOT that reliable.

Chip First Looks

July 13, 2016Generalbreadboad, Chip and FriendlyArmPete

Right now I’m finishing up my installation on the little CHIP board – only to find that WEBMIN would not work – and why is that? Well, the entire WEBMIN site down and also this morning – SOURCEFORGE website was down!!! it’s back up now and webmin is now nicely installed on CHIP along with PHP, SQLITE, PHPLiteAdmin, Node-Red, Mosquitto and PHPSYSINFO which tells me that I have used up over half of my RAM but only a small part of the 4GB of internal storage. I could become a fan of CHIP –though it is a tad SLOW – on the other hand it’s a tad inexpensive.

Scargill's Tech Blog

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