My “nano peripheral” started life as a simple attempt to expand the ESP8266 by making use of the IO on a really cheap Chinese board, an Arduino Nano equivalent Chinese £1.20 rip-off (After all, any Arduino is basically little more than an Atmel chip with reset and power circuitry and a “bootloader”).
UPDATE: Now working on IR – receiver already tested – see experimental version further down…
The idea was to build a dirt-cheap I2c peripheral, suitable for use with my ESP8266 code but now, with improved access to i2c on various boards such as the Orange Pi Zero (2 i2c channels), FriendlyArm NEO, M3, Raspberry Pi and others (see blog entry on i2c) it makes sense to look at this for general use – and with a widened range of capabilities.
Regular readers may recall some time ago I was buying all sorts of parts – A/D converters, port expanders etc. to help with my solar monitoring – and so some time ago I had a shot at making an I2c peripheral using an Arduino Nano…I even went as far as putting a display on the board – which I never ended up using and it occurred to me that it might be better to have the extra pins for general IO – that applies more than ever as my own ESP8266 now caters for the likes of the SSD1306 OLEDs as does widely available software for the likes of the NanoPi NEOs (also covered in the blog). Hence this new version of the NANO section of my home control diagram – but this is stand-alone – as long as you know how to use I2c you can use this.
What is i2c? Well, it’s a simple serial protocol involving 2 wires – one for the “clock” and the other for “data”. The “master” unit controls the clock and either sends data to “slaves” or receives data from them – or both.
As well as for the ESP8266, this makes a useful peripheral to control from one of the many single board computers such as Nanos, Raspberry Pi etc. Some of these boards do not like any significant load putting on their GPIO and let’s face it, PWM on most of these boards is not that clever due to the operating system not really being real-time. Most have ONE proper PWM channel if you can figure out how to use it – yet for VERY little money you can have so much more. I’ve referred to i2c in another blog – it is now easy to use on most of these boards WITHOUT root access (sadly some folk can’t see past this and keep producing stuff that needs root access).
I recall trying PWM on a NEO to soft-fade a LED and while I could get one hardware supported PWM output, the software PWM was atrociously noisy. So immediately here, instead, you get half a dozen perfectly useful 8-bit PWM outputs on a little board costing less than a beer. Not only that but I’ve added a soft-fade version of PWM so that for example with RGB lighting you can fade from one colour to another without any other overhead or delays.
So above, in one scenario, you see where it fits in the scheme of things (the green block entitled “Nano Expansion” – my general controller is an ESP8266 board with a boatload of properties – one of them being able to talk via I2c to various devices.
So the idea of this device is a “jack of all trades” – unfeasibly cheap yet having useful specs – for example the A/D converter inputs are 10-bit – perfectly adequate for measuring battery voltages (you might need resistive dividers as the Arduino A/D input is 1.1v max in this case for value 1023).
This new device then is (by default) device 9 on the i2c bus though you can change that (stored in EEPROM). Some pins are useful – others not so much – here below is an image of this “peripheral” which, hardware wise is nothing more than a programmed up Chinese £1.50 “Nano” board.
So as you can see (and bear in mind that not all NANO devices have the same pin-out) I’m making reasonable use of the pins. With I2c you can set outputs, read inputs, read analog inputs and set PWM or servo outputs as well as sending a message out through the serial port. You could of course get up to 14 PWM pins by using the Arduino Mega256 – but then the cost of that, even from China puts it way more expensive than a dedicated PWM peripheral – the magic of the Nano from China is that it is cheaper than most peripheral chips.
Don’t forget however if you are using this device on it’s own with no other I2c devices – you may need resistive pull-ups on SDA and SCL – certainly if driving this from an ESP8266. I use 2k2. If driving from a Raspberry Pi, well that has it’s own pull-ups. And of course you may want more than one device – if so, one at a time you’ll want to reprogram their number from the original 9, taking care to avoid numbers that might be used in other i2c peripherals you plan to add. Alterations to the device number are stored in EEPROM. Changing device numbers is as simple as any other command.
If using this with my ESP8266 control software you need version 1.91 or better (updated 11/06/2017) as there was a timing error with earlier versions which prevented ADC reading.
I’m connecting this to the 5v supply on a WEMOS D1 (this Nano has it’s own 5v regulator) and no conversion of voltage levels is needed. Similarly I’ve plugged this into various NEO/Orange-Pi-Zero type boards with no ill effect (indeed up to now I’ve not even needed the pull-ups on these but I’m sure that’s a fluke with some – the Raspberry Pi DOES have pullups on the two I2c pins).
The Home control manual has been updated so you have the commands in there – and the source code for the peripheral is on BitBucket and is likely to grown in the future,
Servos:
I added in servos after an almost expensive learning exercise. You can control servos on any of the pins 2-13 – that’s a lot of servos – but as I found out – you can’t just run servos off the supply, say USB to the processor board. These things can take a fair bit of current (not control signal but power) so make sure they have adequate power – just one of them I tried was using 250ma when moving from A to B and that was just a little £4 toy servo (I’m talking power to the servo, not signal here). Consumption when still was nothing significant.
I learned a lot doing this – a quick look through the web showed that Arduino supports only 2 servos at once – and that PWM works – well both of those are WRONG. PWM does not work and made one of my servos get very hot… and the info out there about how many servos the Arduino can handle was also out a date – a simple trip to the Arduino site itself shows that the standard servo library can handle lots of them. So PWM is about the ratio between the ON time and the OFF time – servo driving is about the actual ON period.
So – I made servo control available on all of the pins up to and including 13 – so that’s 2-13 – not just the pins that handle PWM (use ANY servo and you lose PWM on pins 9 and 10 – no big deal there).
I’ve also made use of the Arduino TONE command, letting you play simple tones either continuously or for a defined period. Be aware that you cannot use the PWM on pins 3 and 13 when using TONE as they share the same interrupt to do the job. This is a function of the Arduino code, not mine.
On wiring for servo use – and this will vary from servo to servo – I found (despite not finding this on the web) that of the 3 wires – brown, red and orange – the brown was ground, red was +5v and the orange was a signal wire I could put straight onto a pin on the nano.
One of the annoying features of some Nano boards is lack of power and ground spares. Check this one out –
DALLAS DS18b20
I love these chip – pretty easy to understand and long ago I figured a way around the delay as long as you don’t need to SEARCH – so that’s one chip per GPIO – generally. For a particular project – my hot tub solar heating, I needed two temperature sensors – in and out – as it happens and decided that was as good a reason as any to add this to the Nano project.
Well, did I have some learning to do – even with the fast speed I found that the i2c requestEvent was occurring before the receiveEvent was finished. We’ll cut a long story of dead ends here – but suffice it to say I decided that as this only affected the few commands that RETURN info – ie INPUT and now DALLAS – I would add a third byte to the return value reflecting the STATE of the receiveEvent – done merely by setting a byte to 1 at the start of that event – and resetting it at the end. The requestEvent (ie sending data back) could not look at that FLAG.
Here you see this in action in Node-Red on a Raspberry Pi – this is the simple INPUT command – ensuring you’re getting the data from the current command and not the previous one..
var i2c=global.get(“i2c”);
i2c1 = i2c.openSync(1);
var buf2=new Buffer([2,8,0]);
i2c1.i2cWriteSync(9, 2, buf2);
do {
i2c1.i2cReadSync(9,3,buf2);
} while (buf2[2]==1);
i2c1.closeSync();
msg.payload=buf2[1];
return msg;
Lots going on above- the WriteSync command sends a 2 byte buffer to device 9 – and in that buffer we have 2 (command 2) and pin number (8). We then look at the return 3 bytes until the third byte is TRUE… i.e flag says we’re done. In the case of this command that will be REALLY fast. We then output the data in this case a 1 or a 0.
and here it is in action for the DALLAS chip.
var i2c=global.get(“i2c”);
i2c1 = i2c.openSync(1);
var buf2=new Buffer([15,14,0]);
i2c1.i2cWriteSync(9, 2, buf2);
do
{
i2c1.i2cReadSync(9, 3, buf2);
} while (buf2[2]==1);
i2c1.closeSync();
var result;
result=(buf2[0]<<8)+buf2[1];msg.payload=(Math.round( (result/16) * 10 ) / 10) +”c”;
return msg;
Here I send command 15 to input 14 (A0). Again, when READING the return data I read 3 bytes – the last one has the flag as above – so I can check if the processing event is still going on and loop until it isn’t. This all happens instantly for all practical purposes – we’re not talking hundreds of milliseconds or anything near it.
So how does this work? I issue the command to get one of up to 2 Dallas chips (on different, selectable inputs) – my Dallas command reads the state of the chip – THEN starts the conversion process – which means the first reading is always naff – BUT because I have the pin stored in EEPROM – the very first thing I do in the setup is to read one or two Dallas chips- so their conversion has already started by the time the Nano is ready to go – so you never see the duff result except when CHANGING pins – as the working pins are stored in this case in EEPROM.
You are of course reading the temperature as it was at the LAST reading but on the assumption that the chip is read – lets say every 10 seconds or every minute or 5 minutes – whatever – I can’t imagine that being an issue.
In the case of simple inputs – the flag assures that you are getting the CURRENT state of the input.
Use with Node-Red on an Orange Pi Zero, NEO or similar:
Assuming you have i2c running as per my blog entry on the subject…
Current commands are:
| Command | Value | Parameters | Comment |
| SET_OUTPUT | 1 | port and value | value 0 or 1 |
| READ_INPUT | 2 | port | 3 bytes read… byte 2 is the value, byte 3 is the flag – 1 means busy ** |
| READ_INPUT_PULLUP | 3 | port | 3 bytes read… byte 2 is the value, byte 3 is the flag – 1 means busy |
| SET_PWM | 4 | port and value | value 0-255 (corrected for vision) |
| READ_ANALOG | 5 | port | returns 16 bit value (10 bits used) |
| SET_ADDRESS | 6 | new 8-bit add | |
| SEROUT | 10 | Up to 126 bytes | add zero at end of string |
| SERVO | 11 | port and value | |
| FADE | 12 | port and value | |
| TONE | 13 | port and value | value 16 bit, optionally add 16-bit timeout in ms |
| NOTONE | 14 | port | only used if no timeout used above |
| DALLAS1 | 15 | port | Should reset after making a change if the first reading is important. 3 bytes – the first two represent the word value of temperature *16, the third byte is a flag – read until zero ** |
| DALLAS2 | 16 | port | Should reset after making a change if the first reading is important. 3 bytes – the first two represent the word value of temperature *16, the third byte is a flag – read until zero ** |
Output
var i2c=global.get(“i2c”);
i2c1 = i2c.openSync(1);
var buffer=new Buffer([1,11,0]);
buffer[2]=msg.payload;
i2c1.i2cWriteSync(9, 3, buffer);
i2c1.closeSync();
Here, 3 bytes are sent to device 9 – 1 for command, output 11 and in the next line we set the output value to whatever is coming into the Node-Red function.
Getting info BACK for example from the A/D inputs…. that’s command 12
var i2c=global.get(“i2c”);
i2c1 = i2c.openSync(0);
var buf2=new Buffer([5,14]);
i2c1.i2cWriteSync(9, 2, buf2);
do
{
i2c1.i2cReadSync(9,3,buf2);
} while (buf2[2]==1);
i2c1.closeSync();
var result;
result=(buf2[0]<<8)+buf2[1];
msg.payload=result;
return msg;
Note this time I use the simpler basic i2c commands… these could also be used in the previous example.. instead of sending a command with a buffer (a command is just another byte)…
This Node-Red code is thanks to an i2c NodeJS library added into “the script”. If you don’t use this – look at the i2c blog article as you can add it to your own installation.
In the above example we are retrieving a 16-bit value from the A/D (0-1023).
Latest version stored here –https://bitbucket.org/snippets/scargill/kRg5o
The internal Nano code above is ALL that is needed to return the temperature to a reasonable degree of accuracy (10th degree) – note the code has been checked for negative values – testing with freezer spray to –20c.
I’ve added this for up to 2 sensing pins. A simple read will pull in the temperature to 0.1 degree repeatability – the reading value was calculated after the LAST read or after power up..
With VERY little extra effort – but considerably more money at nearly £7 inc postage – you could use a mini-MEGA board to get a LOT more IO – https://goo.gl/ZyTmt6 – I put that there as it is a neat board but the price really does make the difference between worth doing and not worth doing. IMHO the little Nano rip-off boards do take some beating for the above purpose.
Timers: Bear in mind when considering the use of PWM, the beepers and servos… there are only so many timers on the Nano and similar boards and so you can’t do everything at once:
Timer 0 is used by the millis() function – necessary for loads of timing operations – for example I use this to control the fade-out of PWM LEDs.
Timer 1 is used for the servo library
Timer 2 is used by the tone library
When using PWM – timer 0 is needed for pins 5 and 6 – this does not affect millis(). Timer 1 is used for pins 9 and 10 and timer 23 is used for pins 11 and 3. So bear this in mind when considering what you want to do with the board.
The Experimental Version – I’m currently working on an experimental version which includes infra-red – the IR receiver side is tested, working and does not interfere with PWM – but I’ve not tested the IR TX (or documented it) – the new version has a 6-byte return package (last byte status) to handle the IR 32 bit number. Returns NEC and similar formats no problem – I’ve stopped it returning repeats (ffffffff). Of all my IR remotes the only one it does not currently return is the TCL TV (probably as it is cheap).
Temporary link in case you want to have a look… https://bitbucket.org/snippets/scargill/yR5nkB
and here’s how this one looks…
I’m about to go AWOL for a couple of days so I thought I’d just park that there for now. Way better instructions will follow if I don’t hit any snags.
The magical 1284 – for more pins you could look at the Atmega1284 – a lovely chip which some might argue is even more useful than the Atmega 2560 – check out this link for driving from Arduino – https://github.com/MCUdude/MightyCore and here is my all time favourite article on this chip – including pin-outs – https://maniacbug.wordpress.com/2011/11/27/arduino-on-atmega1284p-4/
I have the code running on a 1284 right here – trivial changes to some array sizes and pin numbers and it works just fine – note that the 1284 (which of course is more expensive than a little Nano) is available both surface mount and as a 40 pin DIL package – and has 8 analog inputs, 7 PWM outputs and in total 31 usable pins!!! D16 and 17 are used for I2c (no change to i2c code). I only made this work as I have lots of these boards lying around.
And now for something completely different…
Unfinished experiment which may never finish!
Meanwhile we have in here a discussion about the STM32 boards and there is indeed a very cheap version which would make a superb peripheral. The board is as cheap as £1.30 with free postage in the UK – sadly the postage in Spain is a further £1.31 which kind of kills that off though buying several at a time would offset that. I should stress at this point that i2c slave software is not yet working properly, awaiting library improvements – but as the boards are so cheap I’ve included mention of them.
Here is a diagram to show you what it can, in theory, do.
Getting anywhere with this board has proven to be an up-hill struggle with some STM-Arduino libraries not even mentioning I2c slave – and lots of dialog out there as to how it does not work. Well, as of tonight – I have Arduino environment 1.83 and the “official” STM library which includes the “Bluepill” board we see here and I’ve managed to get i2c RECEIVE working – and have sent the results of a multi-byte package to the serial port.
You’ll notice here the same issue that other drawings have – the SDA and SCL lines appear to show 3 sets of i2c – two of them with the same pin names – that needs resolving. For now… I have 0v and 3v3 going to that edge connector at the top end. I have an FTDI firing out 3v3 and ground to that. The FTDI is also firing serial signals to serial1 TX and RX – and this is referred to as “Serial1” in the Arduino info for sending data – i.e. Serial1.print etc. That works. The green light (the rightmost of the two in the drawing above) is called PC13 – and can be referred to that way in digitalWrite(PC13,0) etc.
Meanwhile I’m using the SDA and SCL lines referred to as PB_6 and PB_7. For programming you can put a new boot in there but to keep things simple, see the two yellow links above. With the LEFT one moved UP, you can program the board after reset using the serial mode of connection… the board starts up after programming but after root goes back to programming mode. With that link removed or DOWN as shown, reset forces a restart – consider it like GPIO0 on the ESP8266 !! Hmm, a button would be better. Press before reset to program….
Anyway I have I2c data going OUT to the board… next job is to get data BACK to Node-Red. Right now the Bluepill callback to send data back is not even being called even though a NANO version of exactly the same code works… and there is no working solution as confirmed by people who did the software – indeed one suggested I might consider implementing that myself – but that requires more knowledge of these particular chips than I care to acquire.
As for Roger Clark’s Arduino repository – we can forget that for i2c slave. I wrote on the subject and the latest post in there is “Closed as there are no plans to support this feature”. At the end of play today he is suggesting someone else write this – so I think we can write this one off for the purposes of this article.
https://github.com/rogerclarkmelbourne/Arduino_STM32
It is all down the official repository now….
But it gets worse – if you look at the STM diagram above – most of those pins which are supposedly PWM – are not in the official software for the Bluepill board (which apparently isn’t official yet) – so while I got some of them to work (PA7 for example) – others don’t.
Here we have a “fix” for the slave RX/TX issue
I very carefully added that and made the changes to my sketch – made no difference whatsoever and it still crashed.
All seems a little messy. Between that and the PWM, I’m parking this chip – last time I parked it, it took a year to get back to this and still not a lot further forward so don’t get too excited – for now, the NANO solution works perfectly (as do variations with other Arduino-type boards) and there is more to come.
I have tried to connect a DS3231to the i2c line and read and write to it from the NANO.
Now I must conclude after many investigations that it functions from the NANO side, but at the ESP8266 the driver does not respect the fact that the bus might be busy.
It just breaks in on the read function for the RTC and let it fail. I did some logic with busy = true or false in the NANO and can just reconnect the i2c bus with a Wire.begin(9) when the next message comes. However, after some time this also fails and the bus becomes in a state that it causes a boot loop in the ESP8266. I have read your blog about speeding up the i2c bus and have the strong suspicion you incidentally took out the bus busy checking in these exercises.
I measured the speed of the i2c bus to be about 150kHz. I really don’t need that speed in this case. So I hope I can go back to the original i2c routines in the HC firmware, but how to do that? I then can make a special version that might work with 2 (or more) masters in the i2c.
I also found the following – http://www.robotroom.com/Atmel-AVR-TWI-I2C-Multi-Master-Problem.html – which describes a solution for some problem. Can this be integrated into the twi/i2c routines???
Almost all of the stuff written about i2c and the things you did in the i2c-driver are tough to understand. Can I use some standard library on the ESP8266 to use i2c?
What I also did is setting the clock from Node-Red with a command directly to the address 104 of the RTC. Works OK. I set the clock when a ESP8266 startup happens.
var i2c_pl = "i2c:"+i2c_addr+",0,"+regs+","+decToBcd(dt.getSeconds()).toString();
var msg1 = {topic:unitid + "/toesp",payload: "{"+i2c_pl+"}"};
node.send(msg1);
And for min,hours & date too.
A workaround would be to integrate SoftI2c into the NANO and make a separate I2c bus( https://github.com/cirthix/SoftIIC ). But that might be too much for the NANO ROM/RAM space. The Wire library in there can only be used for the built-in hardware in the NANO??
I was hoping to get some guidance if you see a solution to my problems. If you have some spare time to have a short look to my questions.
How about this? https://github.com/pasko-zh/brzo_i2c
Warning to everyone using nano i2c peripheral. I found out it only works when my Wemos D1 is set to a cpu freq. of 160MHz. At 80 MHz there is some timing problem and I start missing messages in the nano ,coming out at the next command.
I agree about not paying bunches, but perhaps I should have been more clear. The FIRST link I posted for the Nano and for the Pro Mini were to the Official and Original sources, ie: to what our usual Chinese sources are cloning from. Those are certainly not where I’d buy one today, tho!
Not just the APM and Nano are way more expensive from the original source, but also the Uno and Mega etc. When the Raspberry Pi was introduced, it was cheaper than buying a Uno from Arduino.cc, but of course rather more expensive (as a ratio) then the clones.
I get that you are talking about both the Nano and the Pro Micro (APM) when you refer to a “nano” (tho almost always the latter from what I’ve read on your valuable blog). But while they have similar niches (cheap, small, breadboard compatible clones of Arduino boards), there are enough differences (30 pin vs 24 pin with different arrangements, etc) that I would be helpful to distinguish, if you can.
I think it’s too bad Arduino went with the 1280 & 2560 rather than the more useful 1284, and thus 1284 based boards are not so cheap. I just discovered those Robotdyne Mega 2560 Pro boards from Robotdyn earler today, browsing older “mailbag’ videos on Andreas Spies’ channel; there’s probably a niche for that. Too bad they didn’t break out more pins than the Arduino Mega, which I think I recall could support more SPI or I2c channels if different or additional pins from the chip had been broken out (recalling a disappointment from a few years ago). But I guess they wanted to be closely compatible with the Arduino Mega, and nothing more.
And the STM32F103 boards would be the best bang per pound modules out there for this niche if they were fully supported. I follow your adventures with those, hoping for further advances with that chip.
Cheers
Let’s clear something up once and for all (this was mentioned briefly in another comment but I want to make it very clear). There are TWO cheap and widely available breadboard compatible versions of the Arduino.
The Arduino Nano (https://store .arduino.cc/usa/arduino-nano) is a 30 pin module with a USB to Serial adapter on board, and a 6 pin ICSP connector. It’s typically a 5v/16Mhz ATMega328p. Clones typically follow this pinout or similar: http://www.keywild.com/arduino/gallery/Nano_PinOut.png
–
The Arduino Pro Mini (https://store.arduino.cc/usa/arduino-pro-mini) is a smaller 24 pin module with no USB, instead relying on an external FTDI/ch340/etc serial interface using 6 extra pins on one end. It’s typically a bit cheaper. It’s widely available in 5v/16Mhz and 3.3v/8MHz versions (sometimes as 16Mhz with solder adjustment for 3.3v vs 5v). It is widely available with the ATMega328p, or the ATMega168p for a few cents less. Most clones follow the same pinout for the 24 outer (breadboard compatible) pins, but A4, A5, A6 & A7 vary between inner (non-edge) locations and edge locations (opposite the serial interface); there even may still be some without A6 & A7. One pinout, with non-edge locations for all 4: http://www.dominicdube.com/wp-content/uploads/ProMiniPinout.png
The latter (Arduino Pro Mini, aka APM) is popular because finished projects often don’t need the onboard USB to Serial converter, or its power consumption, or the larger size. If you desolder the power LED on the APM, you can reduce the sleep current quite a bit, and if you can desolder the voltage regulator (eg: to run on battery) then very low sleep current is possible so this (lightly modified) module is a champ in the long battery life niche. If you use a 3.3v/8MHz version, you can interface directly with many sensors, and it can use even less power.
On the other hand, the original Nano and at least the clones I’ve bought, have both 5v and 3.3v (generated by the USB to serial converter) on board, tho the processor is 5v.
You are often referring to what’s obviously an APM as a “Nano” which could cause confusion if people search for purchasing, or to look for pinouts or tips. So referring to the Arduino Pro Mini (when that’s what you are using) would be a simple and helpful change.
Thanks for your many contributions!
Oh, and one tip: there are cheap socket-to-screw terminal adaptors for the (real) Nano. SInce it’s just a passive 30 pin PCB, these adaptors can be used for other small devices in a 0.6″ wide format (between pin rows, more like 0.7″ overall).
Thanks for that – but some points… the first link you supplied doesn’t work – I did eventually extract the working URL – and was greeted with a Nano (I guess original) that cost a STAGGERING amount – you won’t believe this – they want 20 EUROS plus 7.51 postage (very cheapest rate) + VAT which is something in the region of 33 Euros – about the price of a Raspberry Pi 3. I think someone was having a laugh there. Seriously – do people REALLY pay those prices in the US? I could buy THIRTY “Pro Mini” boards for that.
In the second link – the Arduino Pro Mini – the website says clearly that the product is retired so one can be forgiven for only checking out the chinese versions.
So – for clarification when I say a NANO – I mean anything that costs under £2 and is classed as NANO or PRO MINI
Here are a couple of examples of boards…
This is referred to as a Nano – whether that’s the correct name or not, given the apparent price differential I’m guessing most people will go for something like this… I hope these links works – the originals are a bit long…
This version is referred to as a NANO and has a mini USB connection – and so a USB conversion chip… handy for ease of use..(some I’ve seen have micro-USB connections).
https://goo.gl/MSMG5T
The one below is referred to as a Pro Mini – it does not have a USB chip – and if you happen to be familiar with using FTDIs – well you might prefer this one… as it is a tad cheaper..
https://goo.gl/m1nyLe
There are variations – just ensure you get one with A6 and A7 brought out because not ALL boards have this available.
I probably use these terms lightly because I would never even LOOK at a site that charged more than two or three pounds sterling for these boards. At best they have a cheap 328 chip, a USB chip, Xtal, connector and a few passives all of which cost VERY little.
NOW – if you’re looking for something up-market with a LOT more power – there is of course a Pro-Mini type board with an ATMEGA2560 on it and extra pins – check THIS out https://goo.gl/3Ji1J6 that costs a whopping £7 or so but you’re getting far more power. My personal favourites are boards using the Atmega1284p chip but sadly they are not so popular – it has even more RAM than the 2560 – yet runs normal Arduino code no problem with a few pin changes for I2c and SPI…. I wrote about this a LONG time ago when I was heavily into this – https://tech.scargill.net/the-mighty-1284p/ – check it out… I’ve already played with this as a successor for my Nano peripheral – but I’m waiting for the STM32 to get proper slave I2c support as I think that’ll be better value for money.
I just managed to get a Arduino nano to do what I want.
There are few things I do not understand or need attention.
1. The ESP8266 has outputs and is supplied by 3.3V. Still you are making a drawing with 3 nano’s pulled up to 5V with 2.2k? I have 3.3V pullup with 2k and it works as expected.
2. I had to interchange SCL and SDA to GPIO4 and GPIO5, not as mentioned in the docu.
3. This blog has the complete command list, not the docu. I “found” it in the source too, of course(coded).
4. In this article there are no links to the source for the nano. I “found” them in the i2c blog(here it is https://bitbucket.org/snippets/scargill/kRg5o ). Also a few handy remarks in there what inputs and outputs to use for what..
5. I have a different nano and found out that A4/A5 is used for i2c SDA/SCL. In the drawing with the 3 nano’s it is suggested it is on connection 18/19(AREF/A0 on my board). So the connections where the biggest challenge. The Arduino. cc at least has a drawing which resembles my board. There must be more variants around.
This is really a great economic solution for PWM outputs. I have them now directly on the ESP and there are small flashes now and then which I hope will be gone with this HW PWM.
It was nice I could alter the source to integrate some serial printing for debug purposes.
Great combination with ESP!!!
1. The inputs can go to 5v (high impedance) without issue.
2. We’ve mentioned several times that some boards including ones we used to use a lot, had GPIO4 and 5 reversed – so I reversed them in software.
4. Glad you put the link in here – I’ll update the blog after this response. It was there – but just not a link.
5. Indeed they ARE A4 and A5 but not all board mark them that way – as D finishes at 13, you’ll find that 18 and 19 correspond to A4 and 5 if you start A0 at position 14.
Indeed, given the very low cost of these boards from China, for many purposes they make more sense as an I2c peripheral than some of the dedicated peripherals. I’ve also remarked somewhere on using these directly from I2c on the various PI boards. As time permits I will add more features – there is still plenty of FLASH left, though not so much RAM. The cheap STM32 is STILL not supported for I2c slave so for now the Nano remains king.
The IR works but I’ve not yet had time to give it a good hammering.
I loose a lot of time searching for the right connection on all those boards. I wonder if there is anyone doing monk’s work gathering and publishing those connection data. I remember I came across one of your blogs there is a initiative, but the subject was not interesting for me.
You write so many stories in your blog the information is scattered all over the web(OK keep on going, doing all that frontier work!). Keep in mind that information that stays should be found easier. That big table about commands for nanoin the blog for example can be found easier with a link to the documentation. I think we need a Wiki, you should make one….. when you can find some time for it!………. There are conversion tools, may be you already stumbled over them!
And yes I just found out the interchanging of SCL/SDA because I had it before it was not according to docu.
Pascual – and all…
Just to confirm as I’ve been away for a few days and am just catching up – I mentioned IR input on the Nano Device – the software library also does IR output – however I need time to test to ensure this does not mess up interrupts – i.e. that using the IR output does not un-necessarily remove other functionality. It also of course uses up another pin on the Nano Device. I hope to test this further over the weekend and will comment accordingly.
eventually can be added a compile time flag to enable this feature or others, if some of them would break this or viceversa? so if someone needs ir out but not, for example, pwm, this can be easily done? thanks 🙂
Not quite that simple as some libs need global init
ok, let’s hope that nothing is broken and everything can coexist in a single build, then 🙂
BTW, I hope to get to play with the I2C stuff on my PIC32 chips. If I understand this correctly I should be able to build) and have a working i2C setup. I’ll let you know how that goes.
Peter, you keep calling the Arduino – Nano, which may confuse new reader, it’s the MINI not the NANO 🙂 The Nano has USB ports, the Mini does not 🙂
Read update to blog – second experimental version with infra-red remote control in addition – looking good but I’m having a couple of days break in the sun… more on this later as I test various remotes.
Excellent work Pete – we appreciate all the hard work and persistence that you put into these things – enjoy some well earned rest, it’ll do you good.
I’m hoping for some good weather next week as I have next week and the weekends either side at our beach chalet but sadly not blessed with the Spanish climate but rather the rather less reliable Norfolk UK offering! I’ve got some IoT kit ready to connect up and configure there if the weather is a let down but equally I’d enjoy some time away from geeky temptation as “just another half hour and it’ll be working” always ends up being much longer than that so proper time away from things is the plan…
Cheers & Beers!
Thanks Darren (quick check of emails before heading off first thing). Yes, sadly, these “half hour” projects do tend to escalate. the Nano project started off as merely an interest in i2c on the ESP8266 but as I got to grips with it, I was determined to have the same on my FriendlyArm boards – and so on to the Raspberry Pi. Now that all of this seems trivial and I’ve even gotten to grips with GPIO on the likes of the Pi, the limits become apparent (only one true PWM etc, no A/D)… and so as AliExpress keep dropping the price of the Nano-type Arduino boards (just over £1 at last check) it seems madness NOT to make best use of this little board as a peripheral.
I’d not looked at infra-red remote for some time and the IR2 library looked quite good – so I tried adding that and quickly come unstuck with interrupts until a reply from the designer who pointed me to various options and suddenly I found myself able to receive IR from a range of controls – without any apparent ill effect on other features of the Nano (aside from the loss of one GPIO pin). So, that’s the next step. But first a little break.
very good! so it can be a substitute for this, maybe?
there’s a newer version witi rf433, too… next addition? 🙂
i’ve seen some videos about a little web gui where you press a key (let’s say ON for living room light), and it goes in learning mode… you press the ON button on an IR or 433mhz remote, and it associate it, storing in db… very useful, who knows if such a node already exist…
I’ve never found those units to be much use – apart from the normal ALLFORONE type learning remote controls which are invaluable for replacing umpteen controls at once. No, I see this as just another useful tool to add to the peripheral for maybe controlling lighting or whatever. It would be easy to take any old control and have it control RGB lighting – the same board of course can handle several soft-fade PWM channels all under the master control of a Pi or similar. A nice waterproof IR controller would be good for turning my misting system on and off. Doing that with a phone while you’re getting soaked is not a good idea.
Just picked up 2 RM Mini 3 devices. Let see what I can come up with. I did find a nice thread about the blackbeancontrol.py so it should be too difficult to mangle.
this? https://github.com/davorf/BlackBeanControl
Yes, that one. I also found this:
https://community.openhab.org/t/broadlink-black-bean-rm-3-mini-ir-controller-integration-in-openhab/11453/104
And/Or this one (Broadlink-mqtt):
https://github.com/eschava/broadlink-mqtt
Dr Fragle and Mr Shark, I have the devices, set them up (didn’t bother with the Phone App once setup) and it learns with the:
BlackBeanControl.py -c Power
then replays the IR with the same command. I setup the general with the IP, MAC, port and timeout (learning timeout). I set it to 10 seconds which seems a bit high. I’ll set the individual devices a bit later.
Oh, the documentation is not great. I might write up what I’ve learned and send it to the author. Now to Test it on my wife’s TV. I think I won’t tell her (nah she’ll figure it out pretty dang quick).
oh, thanks, and please share your findings, then 🙂
I’ve posted my initial code (nasty code, with some hard coded values), pre-alpha. It’s posted here:
https://github.com/linuxha/Broadlink-RM3-MQTTBridge
I’ve not taken the raw data from the RM3 and converted it into a consistent string. Not sure how to approach that yet. More learning to do.
thanks, starred the git repo, i’ve not my blackbean with me now
It’s not up to my usual coding standards but I always seem to be tired lately so rather than wait I’ll post and fix as I go.
I know the timeout logic is a bit off (but it works). I’ve updated the README, found interesting translation other code (not used) and found some information on the sending format. Should be useful for interpreting also.
You can find a lot of projects related to broadlink devices for python, node.js, etc. A little bit hard is to get to know devices supported. There are nodes for node-red already implemented. I bought one some months ago just for one thing, controlling my AirCon. It is a very powerful emitter so you can place it almost anywhere in the room. So, integrated with node-red is an easy way to control AirCons almost just out of the box.
Nodes are not that difficult to write yourself, I’ve written several… or of course you can simply write a function.
can you share the node names, please? thanks
Erm all starting with node-red-contrib-
bigtimer, diode, esplogin, timeout (I think… I am on a tour bus in Toledo)… all in “the script”
lol, i obviously know yours, i commented to Pascual for the nodes for the BlackBean 😀
😀😀
When I was looking for a lib for c# or python I recall finding something about node-red and several projects at github for node.js. Just a quick googling and I found some entries:
NPM Packages
https://www.npmjs.com/package/node-red-contrib-broadlink
https://www.npmjs.com/package/node-red-contrib-broadlink-devices
YARN Packages (same projects but you can see file content here)
https://yarnpkg.com/en/package/node-red-contrib-broadlink
https://yarnpkg.com/en/package/node-red-contrib-broadlink-devices
GITHUB
https://github.com/jtomaszk/node-red-node-broadlink
I haven’t tested any of these and you may need to do some mix and match to get it working. I think most of them are ports from python, so you shouldn’t have many issues.
Okay, I can learn and send with the Python (BlackBeanControl.py) but it doesn’t appear that I can listen. I’ll need to have a look at the python-brodlink library to see if the listen function will do what I want. I hope this thing supports simultaneous send and receive connections.
I haven’t been able to make heads or tails of the node-red code. It lacks documentation and I can’t get a vaild config for the RM node. It just gives me an orange triangle with no hint of why (and why it can’t deploy).
Okay, a bit more, I can loop it in python to read the data (if any). So to listen for IR I’ll need a polling node (set the device to learn, wait for a timeout, set it to listen …).
The purpose of the broadlink device (at least RM3) is to be an IR “output” device, that I think it is the opposite to Pete’s target (and yours), this is, using IR as an “input”. The point of this device is to control remotely IR devices with the advantage that you can create “scenes”, schedules and some more features.
If the goal is to trigger “actions” with an IR remote, I’d follow a different way. One is the using an arduino/esp8266/similar with an IR sensor together with an IR lib (most of them ports from Ken Shirriff’s code). Simple electronics and able to decode most of the common IR protocols in the market or even learn. Just bear in mind that some remotes use very long IR frames, specially A/C ones, what can be an issue in terms of memory. Another option is the LIRC way, which works with many IR devices like the IR Toy from Dangerous Prototypes (I mention this one because it’s not too expensive). And I think there’s a node for LIRC too.
but the R3 has a constallation if IR sensors, so it works in any direction if put in a good point in the room 🙂
I can make the Broadlink work, I wrote a quick python loop last night to test it. Since it loops/polls pretty heavily (UDP heavy?) I’ll probably create an external program the will read/write to an MQTT topic. I can’t see that working well in Node-Red.
I would prefer a nice ESP to do this as it can be made to send and receive in a manner that a nice Node-Red interface can work with. The Broadlink has the powerful output, but lacks the flexibility. The ESP transceiver has the flexibility but lacks being built (at this time).
Oddly enough I just found one of my old RS232 IR transceivers. So I’ll try that out with LIRC in a Pi Zero (later).
Hi Peter, About DS18B20 , you can run multiple of them using just one wire. See two schematics here: https://myesp8266.blogspot.nl/2016/08/ds18b20-temperature-sensor-and-esp8266.html
Hi there Kata – yes fully aware of that and have done in the past. However, the goal here is to minimise software overhead – as the chip is also acting as an I2c slave. In this instance I have the overhead down to next to nothing and that is more important than saving a pin. If and when the ST Bluepill board ever gets full I2c slave support, saving pins will be even less important. Of course if someone wanted this – then as the source is available they could always “roll their own”.
Update – the STM solution, at least for the cheap BLUEPILL board is still way too messy and simultaneous slave read/write just doesn’t work. Not only that but the diagram suggests PWM ports half of which are not defined in the current code. For now I’m happy to stick with the NANO solution – when the official ST library and core work – I’ll take another look.
Don’t ever let it be said I don’t try. Got the “Blue Pill” STM board up and running, not before utterly wiping my Arduino setup and starting again with the official ST Arduino software for this board – which DOES have I2c slave demos. Sadly it does not say WHICH I2c or how to select them – and there are three I2cs as far as I can see – presumably incorrectly named on most of the images out there including the diagram I put on the blog – as they show a pair of SDA1/SCL1 and then a single set of SDA2/SCL2. Other diagrams of the CHIP suggest they should be SDA1/SCL1, SDA2, SCL2, SDA2, SCL3. However (and with pullups attached before anyone asks) no matter which combinations I use (6 variations) I cannot get an I2CD check to show up the I2c on the STM board while running the simple I2c SLAVE tests — which default to device 4 and should therefore show device 4 as being present.
I’m not stupid most of the time and if I can’t get this simple presence detection to work on the very latest Arduino IDE (1.83) and very latest ST official library… I’m wondering if anyone else has – unless I’m missing something very obvious….
Suggestion for you Pete: quadrature encode support? This might be useful for getting angular position for a lot of applications. Might not be too large, and it can be seen as the reverse of PWM.
Not something I’m familiar with so I’d need an example…
http://playground.arduino.cc/Main/RotaryEncoders
You should consider using the STM32 blue-pill boards as they are affectionately called, 128kb flash, 20k ram, 72mhz, very low power and enough io to sink a battleship.
https://www.aliexpress.com/item/mini-Stm32f103c8t6-system-board-stm32-learning-development-board/1568685935.html
Best of all, £1.34, so much power, so little money 🙂
Wiki link for the chip http://wiki.stm32duino.com/index.php?title=Blue_Pill
I ABSOLUTELY would agree with you Glen.. but… last time I looked – there was an issue with I2c SLAVE software (hardware glitch) for those boards and without that….. interrupt-driven i2c is a must so you can do other timing stuff on the board. Yes – I would welcome more IO….
Do you know different? And do they have some A/D inputs?
Right – I have one here… bought a year ago the first time this was discussed… if anyone can point me to a current Arduino DEV add-on which includes working I2c slave – I’ll do it.
http://www.stm32duino.com/viewtopic.php?f=48&t=2127&sid=135648555ee26ceb60d2b524db45abb7&start=10
This indicates to me that i2c slave mode is still not totally resolved
Hi Peter,
Following that thread, it would appear as though the issue is fixed with i2c slave.
I’ll give it a quick try but the repository doesn’t say they’ve fixed it – the most relevant comment says “This software is experimental and a work in progress. Under no circumstances should these files be used in relation to any critical system(s). Use of these files is at your own risk”
Not too inspiring…
Well, I got the blink sketch working…. that’s a start….
For wiring up power and serial this helped immensely..
And from there it goes downhill – a standard slave setup as used on a Nano…. with the latest STM code as of 2 days ago with i2c improvements in…
error: ‘class HardWire’ has no member named ‘onReceive’
error: ‘class HardWire’ has no member named ‘onRequest’
I can’t help thinking this is as far as I got a year ago with this board….
Hi Peter,
Is the source for the atmega on bitbucket? Can you provide a link and I’ll take a look.
Cheers
It’s in the blog – at the end… source for the Arduino Nano – ie 328 chip. The i2c slave software there is pretty straightforward – but the routines don’t seem to be in the STM library – backing up comments from earlier that they’ve failed to get I2c slave working. I’m not finding anything concrete to contradict that. Could be one reason the boards are so cheap?
try ask here, too, very recent discussion about i2c slave…
https://community.st.com/thread/42217-do-i-need-one-handle-per-i2c-slave-device-or-per-stm32-i2c-interface
Sadly not an Arduino discussion – another environment to learn…. If this is going to work it has to work in familiar environment with familiar comments. Life is too short.
let’s discuss here what we were chatting, so other can share their thoughts 🙂
so, here’s how to have more memory on your Nano, making it look like an Uno 🙂
you pointed out that has to be tested if in this way the analog pins A6 and A7 that are on the Nano but NOT on the Uno can be used…
i think they should work…
1) they are inside the atmel chip itself, only difference is that on SOME nano are brought out to actual pins
2) i took the standard analoginput sample sketch, changed a0 to a6 and compiled using UNO as target, and it worked… same using a7
and from: http://forum.arduino.cc/index.php?topic=152724.0
“Just a reminder that this TQFP package (AU) has 2 more ADC’s than the DIP package (P), but (Arduino) A6 and A7 are only analog inputs, they cannot be used for outputs – nor do they have any pull-ups on them.”
“You can’t set A6/A7 as inputs, because they’re ONLY connected to the A-D convert mux. (so you can instruct the A-D converter to “read pin A6″.) No resistor required, though…”
“A6 and A7 are 100% analog only pins and they are only available onboards with the surface mount version of the ATmega328. Don’t try to treat them as digital inputs.”
“According to the ATmega328P datasheet, ADC0 through ADC5 are on port C, which is also a regular digital I/O port. However, ADC6 and ADC7 are orphans that can be addressed directly but aren’t part of a digital I/O port. I have no idea why the MCU was designed that way, but that’s the way it is.”
“So you should be able to use A6 and A7 as analog inputs, but you can’t use them as digital outputs. Sorry. It’s not a specific limitation of our boards as opposed to any other Arduino-compatible board, it’s just a limitation of the MCU itself.”
Good to see the torrent of ‘404’s that today blighted my daily favourite foray into barely comprehensible tech in a vain attempt to drink at the fountain of truth has been dried up. Repeated thanks for the entertaining lessons.
HI there
Apologies to all – still not completely sorted – the service provider is at a loss as to why this has happened. I’ve reverted to short permalinks for a time to resolve this – which won’t please Google.
Hi peter, I got my PRO mini boards with the 3 rows of pins on either side, SVG, so plenty of +v and gnd connections. Boards look nice and pitch across outer pins is 1.1″ so they will span two breadboards set up side by side, nice! I got them from the link you provided. These will make a good I2C extension board for the ESP8266 as per your various developments. I hope you got yours too.
On another subject did you ever get node-red running on your Synology drive? I need some help setting mine up. I got MQTT broker running at treat.
Mine turned up today – lovely little boards. I’d post a picture but right now I’m getting 404 errors on the site.