I’ve used the NEO and this is definitely an improvement – H5 processor, the Ethernet connector is giga-speed, 2 USB sockets, Bluetooth and WIFI (with external aerial which I hate using), 1GB RAM and 8GB eMMC on-board, the board looks like it could be a little winner – but as always it’s as much the software that matters as anything else. the board also has audio out on an (unpopulated) 2mm connector and gets it’s power from microUSB. Size is 40mm x 52mm. Starting to look good already…
- A3 Octa-Core processor (handy for multimedia) S5P6818
- 1GB Ram
- 3.5mm audio jack
- 1GBPS Ethernet port
- MicroUSB for power
- 2 USB host ports and an additional two on the board connectors
- LCD interface
- Camera interface
- Debug UART
- TFT socket
- Built-in WIFI and antennae
You get to choose between Ubuntu, Armbian and an old (5.1) Android from Friendlyarm (why are people still using this – we’re up to version 7 now). Also though I’m pleased to see that Debian automatically resizes the SD on install – the Android installation does not – you have to do that “on your PC” and once again they make the assumption that we all have Linux PCs – which could not be further from the truth.
Android: I grabbed the Android file from their site, put it into an SD and banged that into a USB port adaptor on my Raspberry Pi to follow the (simple) procedure to resize Android. Before long I had a full Android 5.1 running complete with Bluetooth (to clarify – a Bluetooth keyboard worked perfectly, a Bluetooth mouse appeared to connect but no pointer movement). From what I’ve seen that’s more than we can currently expect from a Raspberry Pi because all the videos I’ve seen which say you CAN put Android on the Raspberry Pi, end quietly, usually along the lines of “videos are jittery right now”. That could all change in the future of course.
THEN I read about enabling developer mode and using a tool on a PC called ADB which allows for changing overscan and screen resolution WITHOUT rooting Android – I ran that and adjusted the screen size to get rid of the overscan – no problem. The result? With Kodi, a very nice setup for a media centre indeed– quite fast compared to other boards I’ve tried – and no jitter when watching video. The only issue being I’d started off with an 8GB SD card for testing – daft idea. So – I started again this time with a 64GB card. By the time I’d finished I had around 56GB left – that should keep me going for a while.
I tried running with the fan off but the heatsink gets just a tad too warm for comfort (as against “cool” with the fan on. There is a tiny amount of noise with the fan on so I’d recommend putting the unit on soft pads in a box somewhere. (Update, one of the two units I had, came with a 0.21 amp fan, the other with a much quieter 0.15amp fan - so I replaced the more powerful one (only a quid from China) and it now runs quietly.
I’ve been running this now checking out radio stations, watching TV stations and local videos – all without any issues. But check out my blog entry on the T3 for a surprise! https://tech.scargill.net/the-mighty-t3/
All in all, for media, up to now one of the better boards I’ve come across recently.
Debian: I then grabbed their Debian offering and installed that. After some updating (as it was ancient) I set up the WIFI. This was not trivial I have to say but the end result seems to be rock-solid WIFI - I've had 2 of these boards now running on and off for ages and they are just fine. I've had trouble with the WIFI with my ALEXA unit saying it is having trouble connecting - so I've had to yank the access point out of the wall a few times... throughout all of this - both units remain connected no problem at all. More than can be said for a lot of WIFI setups!! Using Debian these units run luke-warm with the fans on.
Recent updates have meant it is now possible to use the GPIO from the likes of Node-Red quite easily using these boards but I noted that there was a connector called the LVDS connector and no-where on the website does it tell you about this connector. I contacted FriendlyArm and they sent me schematics etc. In case you are messing around with GPIO and you want to make use of every last GPIO pin, you might find this interesting.
What, not ANOTHER board from FriendlyArm? And yes, you’d be right to wonder why I’m doing a bunch of articles on them right now – well, it just so happens I got a box of stuff all at once so I thought I’d get them all out of the way at once.
I have covered the FriendlyArm NEO and NEO2 boards here before now and generally been in favour – but for one little item in common with many other boards – little or no IO support – well, that just changed. Read on…
With no apparent way to get to the IO on this cute little board, I promised I would write to FriendlyArm and ask for WIRINGPI and that I did. In the meanwhile if you take a look at the relevant blog entry you’ll see I made a start at using GPIO the hard way and even found a WIRINGOP (OP – Orange Pi) variation that would do basic IO if you could guess the right IO pins, but that was about it.
These are just thoughts – hopefully someone is going to write in and tell me I have it all wrong.
As regular readers will know I have reviewed (and messed with) MANY small Pi-type boards including the Raspberry Pi, Banana Pi, NanoPi etc etc. I’ve also had a go with some power supplies and even made up my own solutions at board level. We’ve had discussions about the issues with FLASH and minimising writes and so mentally it all seems to be coming together. What is needed for our home control central control projects is:
A cheap SBC with enough RAM to be able to lose some for LOG2RAM and buffering for datbases etc to utterly minimise writes to FLASH – so ideally maybe once per day, stuff in RAM would be written to FLASH.
To go with the above then – clearly a power supply is needed that will not fail – i.e. with battery backup.
Sure, if you through enough money at this – there are solutions for everything but at a budget?
Firstly, RAM – just not enough – some of these boards have 256Meg and 512 Meg - enough for normal use but if you start stealing some of it to run Log2RAM and RAM-buffering databases (RAMDISK) then you start to run out – it seems to be that 2GB of RAM would be a nice figure yet I’m only aware of a small number of these boards that have this much – if memory serves me well, the Odroid C2 – and a board I’ve only just recently heard of – the FriendlyArm NanoPi K2. There will be one or two others I’ve long since forgotten. The Raspberry Pi people for example apparently have no intention of moving to 2GB in the near future. We see people using these boards for media management yet if you look at the notes from the designers of such software they usually suggest 2GB minimum RAM! I don’t do media management but our chats about FLASH have me using Log2RAM and RAMDISK and depending on your needs you could be looking at losing 512Meg or your precious RAM.
Power supplies – especially important given the above - recent testing has shown that we don’t seem to have a single low cost unit available that can handle the battery going down to zero – and recovering gracefully while the the load is connected or having to press a button or some impractical manual interjection – and bearing in mind that several of the better boards need 2amps+. Looking back through the blog there is not one – there’s one on Kickstarter but that is now way, way late in appearing and for all we know THAT might not do the job.
What are people’s thoughts – am I talking nonsense? Am I missing some products? What do you think? Do people have low-cost solutions I’m not aware of?
You may well have read my review of the NanoPi NEO back in August 2016 – a nice little H3 unit available in two versions, 256Meg and 512Meg RAM. Well, the new unit has an H5 64-bit processor and comes with 512MB RAM and although there is only one USB connector – there are three USBs available. Size is 40mm square! The NEO 2, however is more expensive than the original at $15 + post etc.
There are lots of add-ons available for it including WIFI, a TTL-RS232 module (just an FTDI but cheap enough), power dock, prototype board etc etc – you can read about it here so I won’t go into too much detail. Personally I wonder about the logic of bringing out add-ons for such a small board – would you not be better off buying more complete board in the first place? Where this board scores is size – it really is small.
So – nice looking - I’m not sure why they chose hardwired Ethernet over WIFI – I’d have gone the other way and kept the height down – but there you are. The existing case for the NEO does not fit the new model incidentally.
The board DOES have fast Ethernet which is a plus – but then if you were going to use it as a NAS the 512Meg RAM might be a limitation?
So you can log into the board via the FTDI or by normal micro-USB serial. At this point I headed off to the WIKI to get the operating system image..
One thing that worried me – and I’ve complained about this before – the requirements are: A NEO2 (obviously), a micro TFT card, a power supply and “a computer running Ubuntu 14.04 64 bit” - FRIENDLYARM - YOU MUST BE JOKING! Most of us in the west have Microsoft Windows PCs. I do have one PC running Linux – it is running MINT and I’ve no intention of changing that just for one new board!!!
I was a little disappointed to find that the website has only Ubuntu Core available – unlike the M3 and M1 both of which have excellent DEBIAN images which work straight out of the box. Again – this fascination with Ubuntu – a bit disappointing to those of us who like Debian and have used it on previous boards – however – the current version is 16.04 which is up to date.
At the time of writing, the ARMBIAN site had only nightly releases available and they refer to WIFI – so not exactly customised to this board which by default does not have WIFI !!
So, despite desire for Debian, I downloaded the Ubuntu Core software from the FriendlyArm WIKI site. I blew the image file with Win32 Disk Imager as usual and plugged it into the NEO 2 board. From what I could read, this would expand on first use and might take some time.
Power on and both the green and blue lights flashed for a moment then the green went full on – and the blue continued to flash. A quick check with Advanced IP Scanner showed the board sitting at 192.168.0.193.
I opened winSCP as usual and I tried logging in as root with password fa.
Having ran the script and that having created a PI user – I went off to log in as user PI – loaded and ran the script again. While all of this was running the processor was running at 53c, so depending on use, the heatsink may not be needed after all.
I cannot tell you how many times I have impressed on various companies – you cannot just put out hardware without software support – and Ubuntu 16.04 (if you have to use Ubuntu) is pretty standard stuff.
And yes the board is fast. Total Time using the nightly built from Armbian to install the script was 46 minutes – as against several hours on the Raspberry Pi Zero WIFI !! Using the default Ubuntu from FriendlyArm, my script took about an hour.
I have however noted some issues with the utility program as I could not get the unit to set up for 3.5mm jack audio. I got an error message. There were a couple of other minor niggles which I've reported and no doubt will be fixed. I've also noted that for the first time, they've created a PI user but when I used that for the script, it kept asking me for the password which was marginally annoying so I ran:
and changed the sudo line to read
%sudo ALL=(ALL) NOPASSWD: ALL
That sorted that out. Annoying but not that critical.
A brief check of my script and everything worked - so at least there are no negative changes and far less messing about than there was when I started this blog entry. I tried a typical Chinese WIFI dongle known to work with the M3 and similar boards – although IFCONFIG was aware that something was plugged in, no WLAN messages came up. GPIO apparently is on the way.
I think a little more time is needed before we can say this is a winner. I never understand why companies release boards without full GPIO support when the openly available competition such as the Raspberry Pi has support by the shedload.
Where I WAS disappointed was when testing the SERIAL ports – there are 4 of them – with serial port 0 being used for debug. Node-Red recognised all 4 of them and even said it was connected – but ONLY serial port 0 seems to be working. That is a real shame as there simply isn’t enough info out there to figure out how to get the others to work. Whether this is an issue with the operating system or the Node-Red serial port I don’t know but that’s a disappointment.
Update 9 May 2017
I've now heard back from FriendlyArm on the subject of GPIO and the issues I had - they have fixed the most trivial - the temperature display - here is the link - https://www.sendspace.com/file/eqh907
But they still have not addressed the almost total lack of information on GPIO, SPI, I2C and serial ports. I decided to go see, because this board uses the H5, if there was a WIRINGPI or WIRINGOP library for it. Well, what a disaster – there are several for the H3 but the only links I could find suggesting an H5 build FAILED until I came across this link - http://www.jianshu.com/p/0ee31099983e
I tried the instructions:
git clone https://github.com/kazukioishi/WiringOP.git -b h5 cd WiringOP chmod +x ./build sudo ./build
and sure enough it all compiled. I then went off to my favourite easy-to-use facility GPIO
By trial and error I discovered that setting pins 7 and 10 to outputs worked. That corresponded to FriendlyArm 198 and 67 respectively (goodness knows where they get these numbers from).
Of course – as the numbers were wrong – I could not see how things like serial and I2c could work – it would be up to FriendlyArm to amend the code for their board and I have pointed this out to them - it seems sensible to me that if the market leader i.e. Raspberry Pi -as open source WiringPi with the GPIO utility, then it would make sense for those bringing out products in a similar market space to modify this code for their own use - indeed I believe that Orange Pi do have a version called WIRINGOP to do this and that too is open source. Let’s hope FriendlyArm take notice as their products are good but when you can't do something as easy as GPIO without having to resort to fumbling around with sys/class etc that's not very good – but at least that’s an easy way to get to normal IO. The likes of PWM would not work either and I found the i2cdetect command missing. FriendlyArm pointed out that this link takes you to the I2c pins but that still doesn't help as the likes of GPIO is expecting other pins.
Friendlyarm have recently written to say that they WILL bring out a version of WIRINGPI to go with this board – the sooner the better – if you want this – be sure to write to them to let them know others are interested. The GPIO utility is really easy to use.
So first of all what is it? – this is a small SBC, a development from the Nanopi M1 which I’ve reviewed here before. So is this worth reading? I would say YES. The M1+ comes complete with 8GB of EMMC which as we’ve seen with other boards makes a significant difference to speed. It can of course handle SD.
The most important features are:
- H3-based (which means there is code out there for the GPIO)
- Mali GPU
- 1GB DDR3 RAM
- 8GB eMMC
- WIFI, Bluetooth (4.0 dual mode)
- Gigabit Ethernet
- 3.5mm Audio jack
- Microphone on board
- IR sensor
- 2 USB-2
- 2 USB Type A
- DVP Camera
- Serial Debug port….
As usual 4 serial ports, though one is debug and one will be tied up with Bluetooth – but that still leaves the Pi wanting.
I opened up the box, downloaded the EMMC loader image from the FriendlyArm site onto a 16GB SD and ran it on the hardwired Ethernet connector. A box popped up offering to install one of two operating systems, I picked Debian. Minutes later I turned it off – took out the SD, turned it on and… working complete with LDXE. Size – around 70mm * 65mm.
I don’t remember an easier setup – everything worked including SCP access to both users FA and ROOT. I logged in as root from WinSCP, copied my script across – ran it – it created the Pi user, I logged in as Pi, ran the script and went off for coffee. Exactly 58 minutes later the whole thing was done and dusted with all my favourite software in place.
This time I’d put in a new addition to the script…AVAHI. Once the script finished I popped into the HOSTS file and the HOSTNAME file and changed the name from “friendlyarm” to “m1plus” and rebooted the board. Antonio who gave me this mod had assured me that this would now mean local access to the boards by name – which should work but hasn’t in the past. I went to my browser on the main pc and typed http://m1plus.lan and sure enough – up popped the board. I tested all my main programs – all work. Actually, just http://m1plus works too.
I’ve not done any speed tests other than the script install which at 58 minutes is not bad…. but the whole thing has a good feeling of speed about it. This could be my new favourite board. Up to now it has been the M3 boards but the fan noise is getting on my nerves a bit – need to sort that – the M1+ definitely does not need a fan. I have hardwired Ethernet on one IP, WIFI on another – the WIFI is reporting a good signal WITHOUT an external aerial. I checked the Bluetooth and it immediately found my Bluetooth speakers.
So up to now, all looks good and as we’ve seen the H3 before there should be no horrible surprises anywhere.
I’ll let you know more about speed and reliability as I get into using this little board. Just a shame they’d not put the connector on for their LCDs… but hey – you can’t have everything.
This could be one of the shortest reviews I’ve ever done! The S430 is a low-cost 4.3” capacitive touch-display designed to work with FriendlyArm boards such as the NanoPi S2, M2, M3, the NanoPC T2 and T3 and finally the Smart4418.
When I think of the HASSLE I’ve had getting a cheap(ish) Chinese display to work with my Raspberry Pi 3 (read elsewhere – still not resolved – you have to make changes to the Raspbian system but more importantly alignment no longer seems to work so the touch part is useless and no-one has a solution).. I spend days on this and finally settled for a display with no touch!
But I digress. The S430 offers 480*800 resolution, is bright, clear and has 4 nice recessed mounting holes and a ribbon cable out the back - none of this HDMI-awkward-connector nonsense as per the above.
And that’s it. I unpackaged the unit, I took a NanoPi M3 which was sitting minding it’s own business serving up Node-Red – I turned it off – plugged in the ribbon cable, turned it on – and immediately, lightning fast text – no drivers, no setup, nothing. When the board eventually popped up with Debian – everything worked – accurate positioning, sensitive capacitive touch etc.
As you can see, I just happen to have everything set up in portrait mode and it all just works. Being capacitive I’ll have to go find a proper capacitive pen as you can’t just use any old bit of plastic as you would with the resistive displays – on the other hand – no pressure is needed either.
I could see this working a TREAT with Node-Red Dashboard. Images in here will expand if you click on them.
I’m quite excited as you can tell.
There is a BIG caveat to all of this which may or may not be important to you – I asked FriendlyArm about landscape mode and they said they had “not implemented landscape mode” – something I find extremely strange… that’s going to limit things a bit….
Don’t you love reviews that tell you all about a new product, print out all the specs then leave you to discover the horrors all on your own because they didn’t ACTUALLY test the thing? Well, this isn’t one of those reviews. But I will give you the spec. Even if this particular board doesn’t get your interest, you might learn some things just as I did in the process of doing the review.
What is it ? The FriendlyArm NanoPi A64 is as you might expect a 64 bit SBC. It looks lovely, has 4 serial ports (you can only really use two as one is for debug, the other for Bluetooth), Gigabit Ethernet, WIFI and more – here’s a list. OH and it is cheap at (in US dollars) $25 plus post.
- Allwinner A64 quad-core Cortex A53
- GPU Mali400MP2
- 1GB DDR3 Ram
- Gigabit Ethernet
- WIFI + Audio + IR + USBx2
- 5v @ 2A
So on the surface of it a fast 64 bit processor – what more could you want – and it is small. You can buy an optional heatsink with fan – but there are no special pins to attach the fan to, unlike other products by the same company. No matter, it does not get warm enough to need the fan in my experience.
I could give you a lot of other technical information which most people would not understand or have time to read – so instead I will cut straight to the point.
Operating Systems: If you check, operating systems for this includes Ubuntu Core and Ubuntu MATE. No Debian, no Android… so to some extent that defeats the object of having the decent graphics chip as you’re less likely to use it as a media centre than if you had Android. Well, I am anyway. I was disappointed not to see Debian but then that’s me. So I started off trying out the full Ubuntu Mate.
The download took an age and I have pointed out to FriendlyArm that they should take a look at how they make their file available – 8 hours to download an image is not very funny. This would not normally bother me as I tend to look first at the Armbian and DietPi sites – but they have nothing for this board. You might think that an operating system tailored for other A64 systems like the PINE would be good – but no – won’t even boot.
So Ubuntu Mate came up fine first time – and I set off running my script – which didn’t work – NPN would not install. It turns out that ONE reason for this was not as you might expect, lack of support for 64 bit systems (though that could be an issue) but the fact that this was Ubuntu 15.10 – which is ancient.
With help from Mr Shark we set about upgrading this to 16.04 Xenial. Well, that took nearly a DAY and was definitely NOT fun. At the end of it, we had 16.04 running – but the Ubuntu equivalent of the APP store was empty. I installed Chromium without it, clicked on the shortcut and… nothing – it simply would not run.
I tried my script and MOSTLY everything worked. A couple of tweaks and all was well, but I was not happy about the Chromium issue. If that was bust, what else was bust? I put the SD to one side and downloaded the much smaller Ubuntu CORE.
After downloading software for these boards you must issue a couple of resizing options – I’ve already suggested to FriendlyArm that this should be part of their start-up script – you don’t have to mess with this with the Raspberry Pi and could put off beginners. Same again – 15.10 version – oh, dear. Anyway…
I started the resize operation…
sudo umount /dev/sdx? sudo parted /dev/sdx unit % resizepart 2 100 unit MB print sudo resize2fs -f /dev/sdx2
No sudo. What!!?!?!?!
I went off and grabbed SUDO. I started again.
I grabbed that, ran the instructions and resized the board.
This time the upgrade was no so successful with lots of errors appearing – now I KNOW there are Linux fanatics out there dying to say “but that’s part of the fun”. No, it ISN’T part of the fun. Writing code is part of the fun, not messing with something that should have been sorted. It would be like buying a car and the engine is broken and the salesmen says “well, repairs are all part of the journey”.
Determined not to be put off, I went back to the original SD and decided to remove the entire desktop environment as it was not needed anyway. Well, I can tell you that most of the information out there on doing this is SHITE. No matter how many commands I ran – and how many confirmations I got that Mate desktop was no longer there, when I rebooted, up came the graphical environment. Eventually, with help from Anthony, I got rid of the lot. I ran my script and – lovely – all working.
I came to back this up using WinDiskManager and “sorry – the image is bigger than the disk” – apparently not all 16GB disks are created equal.
The backup: Having put all this work into getting a board up and running I was not about to change it failing due to an SD issue. It was at this point that I had my first attempt to do a live backup – hey – what did I have to lose. I’ll cut a long story short here as I got the sector numbers wrong in the first place…
dd if=/dev/mmcblk0 of=/dev/sda bs=1M count=15000 status=progress
So dd is a very well known Linux program if you’re into Linux – I’d heard of it but that’s it – so this was my first attempt. I had to get the image backed up onto my SD that would work, without going out and buying a larger SD just to see most of it going to waste. Someday I will write a script to go through my installations and rename all the commands. How about “backup”. But I digress.
So – IF means input file, OF means output file, 1M is the buffer size – in short if you miss that of it takes longer – and status=progress is relatively new and lets you see a moving count while copying instead of wondering if it was working or dead.
This, of course, is highly discouraged by the community – attempting a backup while the system is running is asking for the death penalty or worse and for good reason! As for the count – not only was it incorrect, it was a GUESS – I figured I needed to copy enough to cater for all working areas of the SD – but somewhat less than the actual size or I’d be no better of and the system would gripe about not enough room as does WinDiskManager.
For good measure I also added another command – just because I’d seen this used in the FriendlyArm literature after resizing a disk…. resize2fs /dev/sda2
Well, it was a bit of a long shot – I took out the original SD (mmcblk0) and put the new SD (which had been sitting in a USB holder and hence appeared as SDA - and put the new SD in. Applied power and….
Success: Well, I was expecting nothing so as not to be disappointed – to my surprise – up came the prompt. I checked all of my programs and bingo – everything works. I followed advice from Anthony who was being kept up to date and dumped an empty file called “forcefsck” into the outer directory (i.e. just created an empty file with Nano (the editor)). Rebooted – no error messages – job’s done!
WiFi: The NEXT step having satisfied myself that the board works and realising I could steal my M3 case as the sizes are the same, was to get WIFI working. After above I was not that confident. I read up about the command “nmcli”. This stubbornly refused to work until I realised I was actually typing “nmclie” every time… at which point a quick scan of the networks immediately showed up my local WIFI access point. I stumbled on this item, detailing usage.
Even with one coffee and even though listing the WIFI was easy enough, actually getting a connection proved to be a challenge. Anyway, after reading this item…http://askubuntu.com/questions/461825/connect-to-wifi-from-command-line/461831#461831 I managed to get the WIFI working by putting the relevant login information into a new file /etc/wpa_supplicant.conf and trying out the commands. To cut a long story short I soon realised I had a WIFI connection, disconnected the Ethernet connection, rebooted and lo – WIFI. All seemed like a lot of hard work BUT what WAS noticeable was the speed. Where the likes of the Orange Pi have given me unreliable connections where you could SEE in using the terminal that the WIFI was not right, this seemed to go like a rocket. I tried an apt-get update/upgrade… seemed as fast as the Ethernet version.
Benchmarks: I could not, originally, test my Raspberry Pi due to some missing dependency when loading SYSBENCH. But I did look here… and in particular the following tests:
sysbench --num-threads=1 --test=cpu --cpu-max-prime=20000 --validate run
sysbench --num-threads=4 --test=cpu --cpu-max-prime=20000 --validate run
well, someone apparently produced results of 768 seconds for the RPi2 on 1 thread and for the RPI3, 192 seconds for 4 threads – fair enough…
Finally, I managed to get my RPI2 updated to grab Sysbench and do the same test – 202 seconds for 4 threads… but here's the thing.... the A64 using the identical test - 4 threads - 8 seconds. I did say it looked FAST but really?
I have another Pi2 sitting doing nothing – zilch on the bench – I installed the same Sysbench and ran the same test again on the Pi2 and on the A64 – 8 seconds for the A64, 123 seconds for the Pi2.
Conclusion – the A64 on a simple CPU test, ABSOLUTELY and utterly WIPES THE FLOOR with the Raspberry Pi units.
Eventually: So – am I happy? Yes - I have a rather fast board to play with. I contacted FriendlyArm to find out the status of their version of the GPIO control software to see if it is available for this board. Erm, no. That is going to make it a little difficult for Node-Red to control ports.
So would I recommend this to others? If you’re comfortable with what you have read here and hopefully find my efforts a bit on the amateur side then yes, it looks like a really good board and it is certainly well-made and I DID get everything to work in the end (and I am by no means a Linux expert). If you struggled with this blog – I suggest looking elsewhere or wait for WAY more support to appear. GPIO could be fun getting to work.
Some of these other-board manufacturers do a cracking job – many of these boards are well made, well priced and generally very professional, but I’m sorry, all those claims for I2c, SPi, GPIO etc. are MEANINGLESS to most of use unless backed up – at the least this board needs an up to date version of Debian or Ubuntu complete with GPIO support and examples and right now that is not on offer. I know how I2c works, I know how to use it. I neither know nor, in any ware, care AT ALL how it is implemented in the operating system of how to implement it myself. Life is too short.
But give it time, if you’ve read my other reviews I’m usually quiet supportive. If you want more info – simply look up NanoPi A4, there is a ton of info on their WIKI.
Follow-up and WIFI: Two days later and I’m still messing with these boards – I have Ubuntu pretty much the way I want is and DD continues to do the job for backing up – so I have two of them, identical, sitting side by side. I used this link to get colourful terminal commands (why on earth in the 21st century are we still using boring black and white for Linux terminals) and I I have both machines accessible by name (FriendlyARM1 and FriendlyARM2) on WIFI and now the final touch – I was pondering a cron job to make sure they recover from duff wifi but on test, disconnecting the WIFI – the terminals go dead, reconnecting the WIFI – in both cases they recovered automatically. I tried this several times – a shame some other operating systems and boards don’t fare so well!
Let me clarify that – a good day considering I’m in the Northeast of England, wishing I was in the south of Spain and currently freezing to death.
I got up far too early with ideas in my head about the Thermostat – to cut a long story short, I had some ideas about introducing status colours into the top part of the display to show when the stat is off automatic or in away mode – that went fabulously well as you can see on the right – the status colours show up if you go off automatic – making it much more obvious. Preliminary Node-Red flow here - see previous blog about requirements. I have now updated the original Thermostat blog entry here.
Incidentally – once again, yesterday set a record for views on the blog – so thanks to all the new readers in here – I trust you’re finding this interesting.
Meanwhile a boatload of post turned up for me including a mountain of ONION2 peripherals which I’ll blog as soon as I get a minute – and the new FriendlyArm A64 board. I’ve been working with Antonio (MrShark) on this on and off as the operating system that came with it was ancient. A long conversation for another time, suffice it to say that right now we have Xenial and my script running on it but a few mods are going to be needed to accommodate this powerful 64-bit SBC.
I ALSO got some tiny DC/DC convertors I’ve been waiting for. I’d originally planned to make up a 24 volt solar system for Spain and of course all my stuff runs on 5v or 12v – slightly less of a worry now I’m going down the 12v route (I have a very nice 12v 500w full sine wave invertor sitting in front of me) but these boards are CUTE – size of my thumb-end and take up to 30v in with variable output. Cheap, too. https://www.aliexpress.com/item/20-pcs-Ultra-Small-Size-DC-DC-Step-Down-Power-Supply-Module-3A-Adjustable-Step-Down/32262311443.html?spm=2114.13010608.0.0.4iRhaN
Now, they CLAIM 3amps, I don’t believe it but they were so cheap if they do 2amps I’ll be happy – however it just so happens I have a 1R resistor – so, I may just test one to destruction – the worst that can happen is a smell of burning plastic on test. Just before giving up for the night - I set the output to 3v, input 30v supply and banged a 1r 10w resistor on the output - which rose slightly to 3.2v (hence 3.2 amps) and within 20 second the resistor was quite warm and the pcb I would say hot... but no very hot. I could see 2 amps coming out, yes....
As always some great comments in the various blog areas - I need a system to star rate comments and make them available in a “most useful” list order… a lot of great info from some great people hidden away.
That and some really pretty microUSB THICK leads from Ebay and home-made soup for lunch, not a bad day at all. More tomorrow –I have high hopes for the FriendlyArm board – and it is cheap, too!
Just today – an upgrade notice for Node-Red appeared in my in-box. Upgrade details are here.
What is Node-Red? Details here – if you’re not using it or at least investigating it – you may be missing out.
Now, the support guys (Google groups here) are VERY clear about required versions of NPN etc. so I suggest you read that update page carefully. Because I had 2 identical machines (NanoPi M1 as it happens) I thought I’d go for broke. Don’t copy me unless you have a reliable, easy to get to backup – it may well go wrong (mine didn’t) and you’ll be on your own for not precisely following the instructions.
sudo npm cache clean
sudo npm update -g --unsafe-perm node-red
I had already installed the latest (previous Node-Red – maybe a couple of weeks old) – not the default Raspberry Pi version but a manually installed version – along with NPM and the latest NODE and that is NOT what they recommend. I turned Node-Red off (node-red-stop) and used the above commands as PI user (I know, not on a Raspberry Pi but to make my life easy I always make a PI user who belongs to all the PI groups including SUDO) - I then turned Node-Red on (node-red-start).
Voila. It worked first time. 0.14.0
Now – so what’s special – well, one of my issues with Node-Red has been initialisation of variables – sometimes a global variable can get used before it has been defined!!
The team told me a while ago that the LEFT-MOST tab gets run first – of course that’s no good if your inits are not in the left most tab (I have a tab called “init”). Well now it is because you can SLIDE the tab order about with the mouse – how neat is that!
The DEBUG panel now lets you see message from all over – or just the current tab – which is nice and there are some new nodes and other improvements – I’ll let you read all about them here. The big one that stands out is the LINK node. I HATE making large tabs that are really complicated – but to split them up involves passing messages between tabs – and until now that had to be done the hard way – by global variables (not ideal as you have to poll them) or MQTT or similar. Well now there is a node for THAT as well.
Then I spotted a bug – the exec function would no longer take numbers as arguments – only strings (which is what you’d expect but it had always accepted numbers). I reported this early evening. Meanwhile someone reported an issue with MQTT… so the guys amazingly quickly fixed all this.
sudo npm cache clean
sudo npm update -g --unsafe-perm node-red
Erm, no – this time no messages, just accepted my commands but no update. It was a bit late to expect answers out of anyone… so KNOWING I HAD A BACKUP and stopping Node-Red first then restarting afterwards…
sudo npm cache clean
sudo npm install -g --unsafe-perm node-red
Worked a TREAT – I’m now sitting on version 0.14.3 with all my flows intact. The exec issue has gone away and here we are the next morning, after a few more checks I’ll progress with updating my other installations.
The team are to be congratulated on the work they’ve done on this tool – it costs us nothing but opens up entirely new possibilities to both beginners and seasoned programmers. Very different image of IBM to the one I had when I was a kid (huge buildings, everyone talking in abbreviations, obscenely expensive leased servers) – at least that’s what I remember - probably wrong
Recently I blogged about an update to pricing for the Sonoff mains control units – now down to £3.50 ($4.85) and our readers even reminded us of some potentially great software for those units (as well as my own but then mine is more of a kitchen sink approach and the Sonoffs have only 1Meg of Flash so you lose OTA). Lots of comments – all good.
Updates at the end – slowly cracking the GPIO – got some I/O working!
Meanwhile, you’ll have noted elsewhere on the blog that I’ve found a fabulous, hassle-free battery backup solution in the Ravpower units.
Much MORE Cheapness: And now…. a possible CHEAP alternative to Raspberry Pi for a central controller.
I know – heard it all before… so have I but read on…
As some of you know, I’ve pretty much settled on Debian as the base for a central controller using Node-Red, SQLITE, Mosquitto MQTT and Apache/PHP (to run the likes of PHPLiteAdmin) and I’ve done that based on a Raspberry Pi2/3 for a number of reasons – including working 3.5mm audio, speed, ease of use, support, hardwired network (I think the central controller should be hardwired as it has to be rock-solid), less to learn and… well you can read all my reasons elsewhere.
Well, I’ve been experimenting with the latest FriendlyArm units and one of them stands out a mile as a possible contender for cheapest central controller (Pi Zero is out as it does not have an Ethernet connector, audio connector etc and by the time you add in connectors and the other stuff it is no longer cheap).. How about a Pi lookalike that is SMALLER than a Pi, for well under £10 + post – hence when put together forming what HAS to be the cheapest overall IOT setup on the planet??
Check out the FriendlyArm NanoPi-M1 – a small, square ARM-based unit with the following Spec (you can read the full spec on their site – these are just the important bits)
- Allwinner H3, quad-core Cortex A7 running in this case – JESSIE
- Mali 300 graphic chip
- 512MB RAM (1Gig available)
- 10/100 Ethernet
- 3.5mm or HDMI audio
- IR Receiver
- USB * 3
- HDMI out
- Camera interface
- Debug serial and GPIO
They are the important details – what IS equally important for me is that it works with my installation script – hence the whole setup as described above can be done easily in maybe a couple of hours. https://bitbucket.org/snippets/scargill/KqgAe – you should be familiar with running scripts before tacking this – this one was meant for the Pi – not the M1 – and you absolutely must read the comments as the script is general in nature – for the M1 you need to create the Pi user and groups manually (easy – commented in the script just to keep everything in one place) and set up the hostname (2 files ) to whatever you want – then copy the script over and give it the extra permission before running. I’ve just got it working and can confirm that SQLITE and PHPLITEADMIN work (hence Apache and PHP), Node-Red, Webmin and Mosquitto all work and in Node-Red I can access THREE UARTS – the first one of four is for debug so you can’t rssily get to that but it beats having to disable it as on the Pi. I can access Node-Red as nanopim1:2880
Not touched GPIO but that’s an issue for most non-Pi boards… hopefully someone can tackle that and make the GPIO available within Node-Red. This is looking REALLY good.
Audio works – but (and I had this on the Orange Pi PC) there is a very short burst of sound on the end of the IVONA recording – it has to be some kind of special character getting through – it is most definitely NOT the MP3 playback and when Ivona processes the file name it adds nothing on…. anyway, something for the weekend as they say along with polishing this blog up – for now – it seems like it might be possible to make a minimal IOT solution with a central processor and some mains controllers for under 20 quid!!!!! Stunning.
As I was writing this, and as the Debian image available with the M1 is only 4GB long – I was awaiting info from FriendlyArm as to how to expand as you might find with a Raspberry Pi to the full size of the SD. There are solutions out there and if you’re going to live forever there’s plenty of time to understand most of them.
FriendlyArm came back to me this morning with a simple solution. My 8GB card was sitting with half of it’s space unavailable. Support sent me some instructions for sending data over the serial debug port – but it turned out this was just exactly the same as I could achieve with a terminal.
it was suggested I reboot – and lo – the full size of the SD became available to me – 8GB. I wondered if I could push my luck – so I used Win232DiskManager to make a copy of the 8GB disk…. and then copied that image to a 16GB SD. I installed the 16GB SD into the M1 – powered up and tried the same again.
I have to say I was not expecting miracles – but the results were the same and after a reboot I had my normal 16GB SD setup, no problem.
You could of course install Armbian for the M1 which automatically resizes to fit the SD but I’ve not yet tried this to make sure my stuff works so you’re on you’re own there – I did install it and it does work as a desktop complete with Libre Office etc. if that’s your thing.
Lovely – and so here is a cheap way to get Node-Red and other tools running pretty much as if you were on a Raspberry Pi – except of course for GPIO. None of the usual Pi tools are available - I’ve have settled for the command line PIGPIO or similar as you can call that from a node – but no – there still remains a pretty uncomfortable learning exercise perhaps with some compiling to get control over the GPIO. In this instance I don’t need GPIO so its not a problem but I do with the designers of these systems would recognise that Raspberry Pi has set the pace.
I have tested taking their MATRIX examples of C code – and loading them into the M1 and compiling using the GEANY editor that comes with the Debian setup – almost – and by copying all of the C files into one and adjusting include paths, I HAVE compiled some GPIO control that a ROOT user can use – but I just don’t know enough about the MAKE files to alter the path to do this properly.
Still – the point here is – the board seems to work well and is a CHEAP solution. When I think of the hassle I had trying to get an Orange Pi to do this….
Benchmarks: So I guess what might be on your mind is… and so this cheap board – how does it compare to the Raspberry Pi 2 and 3? I only had a 2 handy for testing and some tests too longer, some less, overall the M1 was MARGINALLY faster than the Pi2 – I would go so far as to say they are comparable.
The test I’m running incidentally is a simple one – so you know..
To install (as root): apt-get install sysbench
To run (as root): sysbench --test=cpu --cpu-max-prime=20000 run
The M1 as an infra-red input which I’ve not tested – it would be nice if someone got that working with Node-Red.
GPIO Update: I was looking for stuff on GPIO on the M1 when I spotted in a forum the chap who developed Armbian talking – and he mentioned that the hardware in the M1 is the same as the Orange Pi One. Well, off I went in search of GPIO for THAT board.
I found this.
Now – it still needs ROOT access which is a pain in the bum… but… I followed the instructions – as ROOT user – but in my /home/pi directory I’d created…. I went to the examples – and ran the one called blink_led.py – nothing – I tried every pin on the connector. I figured nothing gained, nothing lost – so I change the port (led=port.X) to PA9 – LO – a flashing LED – PA19 (purely at random) – LO – another flashing light.
So a lookup table is needed to get the ports to match those on the M1 – and there has to be a way to avoid ROOT access as I want to call this stuff in Node-Red – but GPIO – works. I’m sure there will be other stuff for the Orange Pi One by now – worth checking. I guess what is needed is some kind of daemon running as root user that an exe file running as a normal user can fire parameters at. I’m sure someone cleverer than I could adapt PIGPIO or similar.
Anyway – there you go – just about everything a Pi2 does – and 3 fully usable UARTS and now – some GPIO. All for a fraction of the cost of a Pi2. Got to be worth investigating.
and THEN I discovered THIS…..
I typed as per the link:
The prompt returned as if nothing had happened – but then…. I noted on refresh that/sys/class/gpio_sw directory had magically appeared.
echo 1 > /sys/class/gpio_sw/normal_led/data
That’s one of the examples in that link – erm… NOPE it didn’t work…. no such thing.
So I gave this a try
echo 1 > /sys/class/gpio_sw/PA9/data
YUP – GPIOA9 on the connector lit up.
Sadly again – this stuff would not work for user PI but by the morning I’d pieced together that you need that “data” to have write permissions for other than the OWNER!
As ROOT – this works.
/bin/chmod -R 0666 /sys/class/gpio_sw/*/data
So I put that into the /etc/rc.local file just before “exit 0”, saved and rebooted. LO and behold – it all works as user Pi !!! I can now at least do simple GPIO output from Node-Red using an EXEC node. Well, it’s a start!
I’ve tested the Pxx items available in /sys/class/gpio_sw and the ones that seem to work AND are on the connector include: PA0,PA1,PA6,PA7,PA8,PA9,PA21,PG6,PG7,PG8,PG9. I have avoided touching the UART pins as I think I’d rather have the UARTS available.
Of course at this point I’ve no idea how to READ one of those pins.
WiringPi and GPIO: I did originally try the adaptation of WIRINGPI here and hence the GPIO command line utility – which didn’t seem to object to any commands – but on the other hand didn’t do a THING with them.
Then armed with my successes above, I ran
This produced a list of states of pins with no resemblance to what I was using – but as I toggled PA9 on and off I noted a change from the readall command on GPIO.23.
Could it be:
gpio write 23 1
YES – it turned on PA9.
gpio read 23
YES, it returned the value.
gpio mode 23 in
The light went out and I realised that floating the pin would return 1, grounding the pin would return 0.
I looked for more info on WiringPi and found this - https://projects.drogon.net/raspberry-pi/wiringpi/the-gpio-utility/
With my pin set as an input – the pullup modes worked too.
gpio mode 23 up/down/tri
It turns out that what I was calling PA6 is called GPIO.7 in the WiringPi setup – and this is a PWM pin – could I be so lucky?
No. No matter what pin number I tried – setting PWM mode was not having it. Still – input and output – that’s a step up!! It also turns out that the second part of my rc.local work is NOT needed for WiringPi – just the first line (ie. the modprobe bit).
- Pin 40 GPIOA14 gpio write 16 on
- Pin 38 GPIOA15 gpio nothing default on
- Pin 36 GPIOA13 gpio write 15 on
- Pin 32 GPIOA7 gpio write 26 on
- Pin 28 GPIOA18 gpio write 21 on
- Pin 26 GPIOA17 nothing default off
- Pin 24 GPIOC3 gpio write 10 on
- Pin 22 GPIOA1 gpio write 0 on
- Pin 18 GPIOG9 gpio write 27 on
- Pin 16 GPIOG8 gpio write 26 on
- Pin 12 GPIOA6 gpio write 7 on (also PWM test pin see further down)
- Pin 10 GPIOG7 gpio write 29 on
- Pin 8 GPIOG6 gpio write 28 on
- Pin 7 GPIOG11 nothing default on
- Pin 11 GPIOA0 gpio write 2 on
- Pin 13 GPIOA2 gpio write 6 on
- Pin 15 GPIOA3 gpio write 3 on
- Pin 19 GPIOC0 gpio write 12 on
- Pin 21 GPIOC1 gpio write 13 on
- Pin 23 GPIOC2 gpio write 14 on
- Pin 27 GPIA19 gpio write 30 on
- Pin 29 GPIA20 gpio write 25 on
- Pin 31 GPIOA21 gpio write 11 on
- Pin 33 GPIOA8 gpio write 22 on
- Pin 35 GPIOA16 nothing default on
- Pin 37 GPIOA9 gpio write 23 on
SO – then after all of this – one of our readers pointed me to a C program (see link below), easily compiled on the M1 or any other similar program that in this case simply runs PWM – of course – for a particular pin – but that’s not a problem – you could easily pass parameters – and one WILL.
NOW – that’s all fine and good but it will only run as user ROOT which if you are running node-red – is about as much use as a chocolate fireguard. Until I read THIS (for me game-changing) example about changing the user… so assuming our compiled program is called PWM and is run as ./PWM except it won’t as user PI for example…
Take your C program and
gcc -o pwm pwm.c -l wiringPi
sudo chown root:root pwm
sudo chmod 4755 pwm
I have to tell you I am WELL chuffed about THIS discovery because essentially it means I can make my OWN command line program… and customise it for different boards!!!! AND it will run as user Pi on Node-Red using the EXEC node. Our friend might call the C program a very simple one – but that and the conversion to run as Pi or similar user – makes a BIG difference to a lot of us!!
I HAVE tried this and it DOES PWM modulate that pin – which means getting other pins to work should be a breeze.
THE ONLY PROBLEM is that this is software PWM – because despite the fact that the pin corresponding to 7 is in fact a PWM pin – if you try the wiringPi command for proper PWM – the system objects – and throws a message out – clearly the pins that can be set as PWM are predefined for another board… does anyone out there understand the Wiring Pi code sufficiently to modify it? If PWM won’t work properly – maybe the likes of I2c etc will suffer a similar fate.
But here’s the problem – though WiringOp just happens to work for GPIO on both the M1 and the NEO, and compiled WiringOp programs can be made to work as user Pi, as the company’s Matrix software which DOES give you access to I2c etc. seems to have some issues with any other than ROOT access - and FriendlyArm do not currently know how to get around that. The manual for the Matrix software is even now in Chinese only!