Just bought a new Raspberry Pi 3 with WIFI and Bluetooth? Using it in a project with serial? Happy?
Well, you might not be so happy when you find out what I just found out. I had my Node-Red project that has been controlling the house for around 18 months on a Pi2 and I was starting to have issues – I thought it time to upgrade. So I made a new installation, faithfully copied everything over, plugged in the board… everything was fine.
Except it wasn’t – nothing was coming out of the serial port. Well, it turns out they stole the serial port for the Bluetooth. There is a second port – of a kind – which can be set to work with the GPIO pins 14 and 15… but Node-Red serial node was NOT having it – I put a scope on the output – nothing. I followed instructions to use an alternative “serial port” – which appeared and – the Node-Red Serial port input would not recognise it.
Anyway, it isn’t all bad – thanks to Dave at IBM who put me onto this link…
http://raspberrypi.stackexchange.com/questions/45570/how-do-i-make-serial-work-on-the-raspberry-pi3
Ignore most of the content and head to the end – Answer number FIVE. This got me back up and running with a high speed serial port – but – no Bluetooth of course. I’m assuming I can just stick in a Bluetooth dongle – time will tell.
Essentially assuming an up to date Pi3, the key line is the one where you add
dtoverlay=pi3-miniuart-bt”"to the /boot/config.txt file.
I’m liking FriendlyArm more and more (I’d like them even MORE if they’d put more RAM in their boards) but at least, for today, I’m up and running.
I’m trying to get a Linksprite rpi rs485 shield to work on an rpi3. Everything seems right, ive disabled BT and taken the consoleoff tty/AMA0but i cant seem to set the baud rate to 250k. any tips?
The core-freq=250 change might explain why my Enocean switches often failed and came back to life after I tap on the touch screen. I can only assume it was in a lower power mode. Will see if this fixes it.
TKaiser – re “https://www.amazon.com/gp/customer-reviews/R3LEZR7RRTC2IX”
I can see that hardware checker you mentioned getting a good workout when my new 16GB drives arrive from Amazon!
Checkout the new Orange Pi’s with 2GB of ram announced the other day (http://www.cnx-software.com/2017/04/04/shenzhen-xunlong-releases-two-orange-pi-boards-with-64-bit-arm-processor-2gb-ram/). Very close to the NanoPi hardware and armbian should run on the Prime already. I’m personally running my home automation off a odroid c2 with ups but may switch soon and move the c2 into my arm kubernetes cluster.
Hi Vincent.
I had a rather bad start with Orange Pi – their support is – or was – utterly zero – they didn’t respond to calls, their stuff was on a hard to get Chinese server, relying on the likes of Armbian as their offerings were crap. Getting reliable WIFI on the Orange Pi Zero is STILL an issue (see note on the Armbian site in the Orange Pi Zero section)… and as for the newboard – in your link from CNX..
“Note that while Armbian image with mainline Linux may have improved security and potentially better performance, a few things like GPIOs may not be working yet”
Just a minor detail – “gpio may not be working yet”.
With all of that in mind I look forward to seeing their offerings but won’t be putting any hard earned cash out until I’ve seen other reviews that say “everything works” 🙂
I’m increasingly getting impatient with this – none of these chips are new yet people throw out boards with some of the stuff either partly supported or not supported at all.
I have to say of all the boards I think the Odroid C2 is one of the better ones and that of course as you know has 2GB RAM… with only a couple of comments (1) it is a tad expensive and (b) it’s about time they got their act together and moved on from Android 5.1 – we’re up to version 7+ on phones.
> “none of these chips are new”
Pardon? H5 as used on Orange Pi PC 2, NanoPi NEO 2, now Orange Pi Prime (and soon NanoPi NEO Plus 2 and M1 Plus 2) is brand new. We had the first devices in hand in November and only due to H5 being somewhat a mixture of older A64 and H3 SoCs and awesome linux-sunxi community doing such a great job we can run already mainline kernel on it (thanks to Armbian’s build system making all those patches flowing around useable).
Jean-Luc’s sentence mentioning GPIO is a reaction of me having told him that the same is true for NanoPi NEO 2 now when using Armbian. TL;DR: on all those boards that support HATs and stuff kernel maintainers don’t want to enable anything by default (for reasons I don’t fully understand but I gave up argueing with them) so you need device-tree overlays now. We’re implementing this feature currently in Armbian but focus is on old/mature platforms and not brand new H5 now. See also http://www.cnx-software.com/2017/04/02/nanopi-neo-2-board-benchmarks-with-ubuntu-16-04-2-using-linux-3-10-and-linux-4-10/#comment-540943
BTW: ‘GPIO’ will be useable through sysfs, but features like SPI, I2C and such stuff not since ultra low priority to deal with this stuff when H5 software support is still a moving target (mainline kernel, the stuff no one cares about).
I agree that vendor software offerings are crap (and not that trustworthy in general) but since on Allwinner boards community does all the work and the ‘peer review process’ that guarantees quality when working on upstream mainline kernel takes some time also some patience is needed.
If you don’t care about software quality and also don’t care using a smelly/crappy vendor kernel (as most users do) and don’t like Xunlong for being not ‘that’ responsive simply wait some time for NanoPi M1 Plus 2 also featuring H5 but only with 1 GB DRAM (we had a discussion with FriendlyELEC engineers, they understood that Allwinner’s shitty BSP kernel currently fails with voltage regulation and now they redesign M1 Plus 2 PCB partially to keep up with Xunlong since the latter use a way better voltage regulation on their larger boards –> end result: both lower overall consumption and higher performance possible)
Regarding Android: Just check ayufan’s community Android builds for A64 devices (really, both device and hardware vendor doesn’t matter, all those boards are more or less the same since based on Allwinner’s reference design and only needing some tweaks in config files). Android community build for Pine64 & friends is at 7.1 already IIRC: https://github.com/ayufan-pine64 (I doubt this will repeat with H5 since H6 is already announced and this one has an impressive feature set so developers most probably will skip H5 for multimedia/Android stuff, focus now on A64 and later on H6)
November – as did I – so as I said …. not new! It is 5 months later now. We tried latest Android on the Pine64… might have just picked wrong releases but they didn’t work properly – not as you might’ve expected on a 64-bit chip though to be honest the Pine64 was so big I quickly put it to one side anyway.
and GPIO – the very nature of these boards, when not used as simple media centres, suggests people will want to use GPIO including SPI etc… ESPECIALLY as the salesmen always make sure they feature this stuff in their ads then fail to mention that while the hardware may support this, they’ve not bothered to make sure the software they supply supports i – this particular tactic annoys me immensely.
Talking about Bluetooth, you can’t use the audio board on the board either. I found out it was the bus. So I added a external usb audio card. It worked well for 2 dollars Australian.
It gets worse! I guess the thing here is – if you have to add external stuff to make it work, it makes the Pi3 less unique as a proposition.
I have to say, the NanoPi M1+ I reviewed here – https://tech.scargill.net/tag/the-nanopi-m1-from-friendlyarm/ is getting closer to my heart by the minute and has NO shortage of UARTS – has audio, has Giganet Ethernet and WIFI and Bluetooth… I could see a job here moving my stuff over to that board… by the time you pay post it is probably marginally more than the Pi3 and it is only an H3 but with eMMC it certainly seemed fast to me and none of this nonsense…. no SD BACKUP which is so very easy to use, sadly.
I ordered a Banana Pi, BPI-M2 Ultra with the R40. 8GB EMMC and 2GB RAM etc. Even real SATA…
The eMMC there is the slowest/crappiest used by any SBC vendor currently, the ‘real SATA’ is unfortunately the same joke as with A20 boards (write performance on USB ports is slightly faster than SATA), the software and support are horrible. Good luck with that device.
So – rather than tell us what is bad about all of these things (you have said at one point or another that just about everything is bad) – how about a solution.. what would you recommend to last the LONGEST and most RELIABLE… a particular eMMC or a particular type of SD or a hard drive etc….
I need my solution to work for a lot longer than a year.
I answered above with two recommendations but comments got lost somehow (or you need to confirm them? Got the message ‘duplicate comment’ when trying to re-submit).
Anyway: reducing flash wear-out can also be done in software and good OS images take care of this (I elaborated on this also but… comment gone)
Hi… “duplicate comment” usually happens if someone pressed enter twice – maybe due to blog running slow. First comment will have gone in. Your comments no longer need confirming.. so I don’t have an answer as to what might have happened.
I’m busy reading about making changes in fstab to put logs etc into RAm, but of course that eats up RAM and some of these boards are are a bit short of RAM to start with.
Hmm… I answered Doug above and also to your answer to him. Both lost. Anyway ‘SanDisk Extreme Plus’ has been chosen by a german vendor using ODROID-C1+/C2 in an appliance over Hardkernel’s eMMC for only one reason: endurance.
Don’t think about this when it’s about consumer grade eMMC on SBC, better use expensive SD cards (or check industrial SD cards, they always show a TBW rating). This is FriendlyELECs eMMC http://www.datasheetspdf.com/PDF/KLMAG2WEPD-B031/959544/4 (no TBW, not even maximum P/E cycles mentioned). And the eMMC used on Banana boards is even worse. While the eMMC on Olimex devices is quite the opposite (it’s slow as hell but made for inudstrial applications). So it always depends.
You need a bit more than just lines in /etc/fstab, eg. https://github.com/igorpecovnik/lib/tree/master/scripts/log2ram (stuff has to be synced with disk). But it also helps already a lot to increase the commit interval to get many small changes being written in one large chunk to flash media reducing write amplification a lot (Armbian uses ‘commit=600’ for ext4 so trying to write only every 10 minutes)
And yes your concerns about waste of RAM are valid, we’re currently looking into stuff like zram (that’s a replacement for swap that should work way better on systems with low RAM, especially thinking about NEO 2 here) and to use compressed tmpfs for those logs. Will take some time but as soon as we found a solution this will become part of Armbian on all supported platforms.
I could see this subject rolling on for a while so I’ve written a completely separate blog on the subject – here – https://tech.scargill.net/a-question-of-lifespan/
I’ve included some snippets from your comments – feel free to elaborate there where people can focus on the one subject – making your SBC project last longer… I’d read about log2ram then forgotten all about it – investigating that link now.
well, despite what others say, use dietpi, which has great tool to backup and for moving stuff in ram and reduce sd card wear issues… just a few clicks, done… someone wants to use these boards and not just collecting and benchmarking them, so, when armbian will end his journey towards the perfect kernel and will start caring of user experience, too, we’ll be all happy to have a better overall built distro… for now, i’ll stick to dietpi, less hassle…
I TEND to agree BUT… I had to move my latest RPI2 setup (the one controlling 433Mhz radio) back to Raspbian because I simply could not get AUDIO to work properly in MPG123 on DietPi.
If something as normal and basic as audio on a Pi2 is a problem in DietPi, it makes me wonder….
Here is my understanding of the ports as of now (ie I did this in April 2017) – based on this .
http://spellfoundry.com/2016/05/29/configuring-gpio-serial-port-raspbian-jessie-including-pi-3/
So – you CAN get the serial port back – I have it back on GPIO14 and 15 at the expense of Bluetooth. The “other” serial just does not want to know about Node-Red so I had to make the change suggested here.
You can swap the names around – and even swap the ports – but as the “real” uart was chosen for BT for performance, swapping ports will presumably take you back to square one for UART use on GPIO14 and 15 – but leave you with a rubbish serial on Bluetooth – not a lot of use if you are constantly reading data from sensors.
As far as I can make out – in order to get back to RPI2 status with serial – you can kiss goodbye to BT – requiring the use of a Dongle.
This is so silly – many of the other boards out there offer up to 4 uarts – would it have been that big a deal for RPI to come up with the same? Maybe despite the undoubted great user-base – the hardware people at RPi are just not on the ball? Certainly PIXEL is great – the SD backup is great – but hardware and performance wise I’m thinking for example ODroid 2 and others….
Haven’t seen this before… RPi hardware isn’t really that great (especially compared to great user base and software support situation now — this has been totally different in the beginning as well remember).
All RPi use a horribly outdated SoC dating back to 2011 designed for devices like an iPod or an entry-level smartphone (wikipedia –> videocore 4). The only ‘invention’ was exchanging the CPU cores two times and doing some really really dirty hacks to get that thing running with 1GB. The girl who developed (not any longer) an alternative to the closed ‘firmware’ shared a lot of interesting/amusing details here: https://irclog.whitequark.org/linux-sunxi/2017-04-02#19158422
I use a Pi3 with a USB to serial adapter to receive serial data … I never even thought to connect it to the serial port pins I just plugged it into the USB.
Me too. I always considered the embedded UART to be used mostly as a debug tty console.
Nope normally it is a fine uart – I’ve used it to provide a front panel control using a Nextion board – been running for maybe 18 months – anyway the fix of disabling Bluetooth works and if I need Bluetooth – adaptors cost next to nothing.
don’t know if it’s the same guide you have found, but here explains how to move BT on the other serial, or how to access it anyway, so maybe even via node-red:
https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=159483
I noted that but I was not particularly interested in Bluetooth for now – though I do eventually want a garden sensor in the house for the plants which is BT – for now it isn’t important. You have to wonder what they were thinking about – with such a large user base some of whom might have all sorts of uses for the serial port, messing things about like that.
I had planned to move lock-stock and barrel to a NEO2 but that has only 512MB of RAM and though everything installed on it, as I started moving FLOWS from the old system to the new, Node-Red gave up eventually – the same operation on the Pi3 went through no problem.
I’ll re-tackle THAT issue once I’m happy everything is working.
For those wondering what I’m on about – a lesson about backups: My home controller has been working fine for over a year and all of a sudden, using PIXEL would crash the Pi2. A reboot fixed it but using PIXEL again would crash the board – something that has never happened before.
Here’s where it gets strange. I knew there was something wrong but apart from the crash I could not fathom it out. Then I made a brand new Pi3 installation and copied folders etc across to the new one.
I figured I’d make the old system a different IP number (fixed) so I could ensure I’d succeeded in copying everything. I changed the Pi2 from 192.168.0.20 to 192.168.0.19 – and rebooted. Absolutely no change.
I checked my changes and they’d reverted back. I read up loads on fixed IP on the Pi – what a load of old outdated rubbish there is out there. Finally I found an up to date article – and followed that – still no change – after reboot the old IP was back. I asked Antonio for ideas and he suggested stuff – none of that worked.
Then on a WILD hunch I wrote a small file and put it in the Pi directory. I checked – it was there. I rebooted, it was gone.
I tried the same in another directory – same result.
Somehow for the past few days my entire house controller has been – or so it seems, running out of RAM!!!
I tried formatting the SD – it would not format – write protected. I used tools to unprotect SDs – they said yes, but SD Formatter said no.
I used Win32DiskManager to write a virgin Raspbian to the SD – Win32DiskManager said yes, but on loading up the SD – the old code was still there (a lesson there somewhere perhaps).
I’ve never come across anything like this ever. The SD is read-only – and has been for days yet everything seemed to work and I didn’t see any error messages!!!
Anyway, all is restored, I’ve made 2 backup SDs and ordered replacement SDs… but that is the FIRST time I have ever suffered any issue with SDs – and that was a decent Samsung EVO!!!
i had similar problems with a collegue sd card, in his phone… he couldn’t move photos between phone and sdcard… formatted sd, program said it did, restart, nothing, all the old stuff still there
Had the exact same issue recently with a Pi2. The SD card went read-only on me. I ended up having to replace the card. Definitely took some noodling to figure that one out.
So – not just me then – anyone else come across this? SD card going read-only and needing scrapping?? Any why did (almost) everything keep working?
Sure, SD cards and all other flash based media will die. Only question is when.
And the reason why (almost) everything keeps working is the kernel buffering/caching all writes to disk in memory. So as long as all stuff written is still in the cache it will not even be read from disk. When such a Linux thingie runs over a long period all ‘free memory’ most probably has been eaten and most of this will now be used for buffers/caches. A simple ‘vmstat’ will tell and another simple ‘sync; echo 3 >/proc/sys/vm/drop_caches’ would flush all cashes and then things start to go wrong if either filesystem or card went read-only in the meantime.
I’ve been avoiding using a little 2.5″ hard disk on the assumption that solid state is better – but having seen this I’m beginning to think I might be better off using a disk – I could not tell you the last time a hard disk died on me.
Hehe, spinning rust will also die. The problem with flash storage that’s it’s insanely easy to sell counterfeit cards (you get them everywhere, you can trust in not a single seller since they even don’t know or could check that they sell fakes). Just do a google search for eg ‘counterfeit sd card site:amazon.com’.
Also happy reading:
17 out of 20 cards were fake: http://www.happybison.com/reviews/how-to-check-and-spot-fake-micro-sd-card-8/
And what happens if you bought a ‘genuine 32 GB Samsung’ that is in reality a fake 8 GB card. As soon as you exceed 8GB writes in total the card wents read-only (since the filesystem information should now be written beyond the physical available space which is simply not possible).
It’s so easy to check for this and nobody does it: the tools are called F3 or H2testw and available for free: https://docs.armbian.com/User-Guide_Getting-Started/#how-to-prepare-a-sd-card
Another nice read regarding the ‘SD card went read-only’ issue: https://www.amazon.com/gp/customer-reviews/R3LEZR7RRTC2IX
me, now… or i think a few days ago, when my rpi3 became unresponsive, and have to pull power cable and restart… i was testing audio, as i said to you on skype, and i had never enabled audio… i used dietpi-config to enable audio via 3.5 jack, rebooted, and tadà! Files and folders i removed more than a week ago back there… created a few new ones, deleted others, rebooted, again, folder as it was a week ago… damn… i use dietpi just because it allows to have logs in ram or purged every hour, to stress less the sdcard…
That’s why Etcher is so great: https://etcher.io
Verifies media while and after writing so you do not only catch this error but also all sorts of silent data corruption (happens very often, Armbian forum for example is full of threads that are only caused by ‘good weather’ burning tools that do not care whether they write garbage or anything at all on SD cards).
You could try SD Formatter’s ‘FULL (Erase)’ mode that works completely different than the two other modes. Maybe that helps.
Tkaiser – I will give Etcher a go in future. I’ve downloaded it. Good idea to try full erase but no – the SD is simply not having it. Write protected – ie BUST.
Well, Samsung EVO/EVO+ should support it. My only advice here is to always check for counterfeit/bad cards directly after purchase: https://docs.armbian.com/User-Guide_Getting-Started/#how-to-prepare-a-sd-card
If people would do that maybe 25% of all posts in Armbian forum dealing with mysterious problems (that are in reality due to crappy SD cards) could be saved.
My mentions of EMMS being prefered for embedded was because I was told by someone who has run lots of embedded devices and told me to stay away from SD because of what you observed. They don’t last long( 1 year is a short time for a home controller).
I suppose the other side of the coin is that you can take out an SD and replicate it easily. Replicating an entire setup including the operating system on eMMC not quite so easy.
Hard disk is getting more attractive by the day.
If there’s an SD card slot also on the board you can just ignore eMMC that died (at least when boot priority prefers SD over eMMC). We have already the first reports of dead eMMC in Armbian forum (caused by Firefox/Chromium constantly hammering the disk).
The cheap eMMC on SBC isn’t better than quality SD cards. Key words are ‘endurance’, ‘TBW’ and P/E cycles. And writing strategy (that’s an OS thing): http://electronics.stackexchange.com/questions/218914/how-long-until-my-emmc-is-dead
TL;DR: if you care about endurance, then search for endurance (and pay a lot more, a SanDisk Extreme Plus is much more expensive than the cheap stuff people buy but lasts a lot longer — there’s even ‘industrial SD cards’ with endurance ratings).
Simply not true. While eMMC shows usually better random IO performance you can also get stuff sucking at endurance.
If you care about that just don’t buy the cheap (fake) cards somewhere but start to inform you, check the meaning of TBW and spend a lot more on your cards (a guy using ODROID-C1+ and C2 in commercial products said after some extensive testing they voted against Hardkernel’s eMMC but chose SanDisk Extreme Plus — yeah ‘Plus’ not ‘Pro’, the ‘twice the price’ variant and that’s only due to longevity concerns)
Some manufacturers also sell ‘industrial SD cards’ meant to withstand harsh conditions but more importantly coming with endurance ratings. While cheap consumer grade eMMC doesn’t mention endurance/TBW or even maximum P/E cycles at all: http://www.datasheetspdf.com/PDF/KLMAG2WEPD-B031/959544/4 (that’s the eMMC used by FriendlyELEC currently)
The real problem with SD cards is that people are not aware what’s performance relevant and… counterfeit cards (people start to care about only after they already lost data and hours of their life trying to figure out what went wrong)
And there’s another problem called ‘write amplification’: the patterns how the OS writes to card/eMMC are important since writing constantly small chunks of data to flash media will destroy it much earlier (that’s why Armbian for example has a 10 minute commit interval to flash so that writes are combined and therefor have a much lower write amplification and less wear out). http://electronics.stackexchange.com/questions/218914/how-long-until-my-emmc-is-dead