Jump to content

All Activity

This stream auto-updates     

  1. Earlier
  2. A few weeks back I was tempted by a Pi - not the one with all the little seeds you understand. No, that one isn't open source engineering, and quite frankly isn't for us professional (retired) engineers. Yes, you've guessed it: Orange Pi! The sub-twenty-UK-pounds of the Orange Pi PC proved just too much to resist. A board with a quad core CPU, 1GB of RAM, WiFi & Ethernet, HDMI video, IR receiver, Camera Port, 3xUSB, etc. at this price level is probably too good to be true. Or is it? I decided that boards which depend on a microSD for program storage are an economy too far. Whilst this bottleneck might be OK in an ultra low cost embedded application development work requires something better. So it was pay the few pounds extra for the eMMC version and see what turned up. As it turned out there wasn't the expected six weeks or more wait for Chinese components, as despite all the world turmoil Orange Pi central had their pretty box on my desk in inside a month. I don't generally rush off and try new gismos the same hour/day, but eyeballing the OP PC+ triggered childhood Christmas Morning Syndrome, and I just had to fire it up right away. I'd omitted to order a power lead but the one 1.7/4.0mm for the Cubieboard 2 did the job fine. Ditto HDMI converter, keyboard etc. for same. Power up time: oh no not Android 4.4 again, and all in CHINESE! This was not a good start! Drawing on all my painful experiences with cheap Chinese Android tablets that had - often mysteriously - factory reset, I navigated through the hieroglyphics and attained English language nirvana! Click on the massive Google Play icon... zilch! Click on every one of the other giant icons... double zilch! It had a dumb deaf and blind Android core installed so I'd need to sideload some apps. But wait; enough of this nonsense; let's boot to a decent Linux distro from the microSD. I'd never tried Armbian before but this seemed like a good time to start. The first attempt at booting Armbian from the microSD didn't go well: I'd naturally chosen the latest version (Focal) but missed a warning that Focal images had been broken. Stepping back to Buster solved this problem, and that booted after a short delay - we were getting somewhere! Set the passwords; do the usual updates... The next step was to transfer Armbian from the microSD to the on-board eMMC so that we could lose the slow card entirely. This proved remarkably easy as there's a pre-written script called nand-sata-install to do exactly this. Now we are flying as a boot is so much faster - yes, eMMC was certainly the right way to go here! You can see the eMMC at the bottom centre (just above the dual row pin header) of the board in the first picture. On the Plus version they've moved the second DRAM to the other side of the board (directly below the visible one near the centre of the board) to make room for it. BTW if you do have the non-Plus version then don't make the mistake of going for a superfast A2 microSD card as there aren't any drivers for these in Armbian (yet) and it will likely run significantly slower than a much cheaper A1 specification card. After my usual desktop tweaks I pulled the D language compiler from the repos: although I like Python, D takes a much better approach to higher level programming and also integrates almost seamlessly with C code for the low level bit twiddling. sudo apt install gdc How are we doing from a thermal stress point of view? Well... so far the H3 isn't under much stress, but it can get a lot hotter! Getting To The Pins Next step was to get at the peripherals, and it turns out that WiringPi has already done the spadework for the H3 here - no sense reinventing the wheel! There's a WiringPi port for the Orange Pi PC to be found here. The H3 sports the following multi-functional input/out pins: Port A (PA): 22 input/output port Port C (PC): 19 input/output port Port D (PD): 18 input/output port Port E (PE): 16 input/output port Port F (PF): 7 input/output port Port G (PG): 14 input/output port Port L (PL): 12 input/output port The Orange Pi Plus PC can't possible provide user access to all these 108 pins within the limited board area, though unused peripherals can generally be reassigned to simple I/O: With WiringPi installed we can now get at the pins at both BASH script and compiled C code level, the package also contains a wealth of examples. I chose to test things out with a tiny script. Just to throw some execution randomness and impose a parallel load on the H3 CPU I ran a HD movie in another window. I can thus report that Kill Bill didn't kill the execution script! PIN=1 while true; do gpio write $PIN 1 sleep 0.05 gpio write $PIN 0 sleep 0.05 done A fairly regular squarewave as expected, so the video playback isn't impacting the hardware timing, however the observant reader may note that the output frequency of the square wave on logical Pin 1 (physical Pin 12 - the red picohook) isn't the 10Hz it should be. This is a - long by about 25% - error in the Armbian sleep routine and nothing directly to do with the hardware. It would be interesting to trace the sleep routine implementation back to see exactly where/how this crept in. Maybe more on this later. The Conclusion... So.. now we have a near perfect development platform for embedded applications. The beauty here is that there are much smaller and even lower cost boards using the same basic hardware configuration but without unnecessary appendages like the HDMI interface to form the basis of really smart hardware. Orange Pi Central has recognised this potential by promising Long Term Support for these boards - hardware projects generally have a far longer useful lifetime than software. Fabricators should therefore be able to depend on continuity of supply! If all this potential is fulfilled then Oranges really could become my favourite fruit! Coming Up I've ordered a few of the Orange Pi PC Plus' smaller even cheaper cousins - the Orange Pi Zero, to embedd in future Stripboard projects, so stay tuned for a first evaluation. _____________________________________ If you enjoyed this article and want to see a lot more then please create a site membership and post a comment - a little encouragement goes a long way! With free membership you can also start new threads in our forums; ask questions; or publish your own constructional articles. Stripboard.com is an advertising free, and non-commercial area of the Internet that has no aspiration toward world domination - or even making anyone any money!
  3. VeeCAD is FREE stripboard design software that nominally runs under Windows, but many in engineering and hobbyist community no longer use Windows. If you aren't tied into the Windows ecosystem commercially - some would talk about M$ tentacles here - there are better and free alternatives amongst the ever expanding distributions of Linux. So how to leverage all this free software into doing something really productive with stripboard? For the home user the Ubuntu distribution of Linux, which is in turn based on the Debian distribution (that's how open source software works folks!), is the first port of call. For that reason we are talking about Ubuntu and in particular the latest 64bit version 20.04 here. Assuming you already have a recent copy of Ubuntu installed proceed as follows: Go to the Wine downloads page and follow their amazingly clear instructions. Click on your operating system, then on the page for that operating system select the most recent stable version - we don't do bleeding edge here! Follow the amazingly clear instructions and then type wine at a terminal window prompt. If all went well you'll get the Usage: wine... help messages and the system will then exit back to the prompt. The Wine install worked for me with Ubuntu 20 without any of the usual snags about dependencies and version incompatibilities. They've quite obviously spent a very long while honing this. Now download VeeCAD from the download page - you'll likely want to download the manual as well. If you download it using the archive manager then there's a direct way of extracting it. If you don't already have a Windows sub-directory in your home directory then create one. If you are well organised you'll create another sub-directory for VeeCAD and place the Setup file there. Now name the .exe as an argument to Wine. The rest is super easy, but as VeeCAD is 32 bit Windows you really should install it to Program Files (x86). . .. Make sure you've checked the place a desktop icon box before you hit [Install]. When install completes then just hit the run now button and presto! Wine stores its Windows file system in a hidden directory called .wine in your home directory, but you don't have to make these files visible to your favourite Linux file manager to manipulate them. Simply type winefile (not winfile) at a terminal prompt and it will throw up its own Windows file-friendly file manager. Hitting the C:\ button at the top will open a child window onto the Wine file system where you've installed to. You can navigate to the VeeCAD.exe file and click on it to start VeeCAD. You can also use winefile to navigate to users -> <your_name> -> Start Menu and click on VeeCAD.lnk to start VeeCAD. It's probably a good idea to put a shortcut to winefile on your Ubuntu toolbar. But shouldn't there be an easier way to start a program? Well, of course there is: when you told Wine to place a Windows desktop icon it went to Linux and did the same thing, but adding in the tricks to start Wine running on the correct .exe file first. Apart from the visual appearance of its window your installed Windows program acts very much like any Linux one. You can right click on the new Linux VeeCAD icon and add it to favourites so that it shows up on your toolbar - nothing could be easier! If you ever feel a need to uninstall a Windows program then simply type wine uninstaller in a Linux terminal window and an (almost) genuine Windows installer dialogue will pop up. A Footnote I subsequently found out that you are supposed to run winecfg to set up the Wine environment for VeeCAD. I found this out from the Help in a running copy of VeeCAD - doh! There wasn't anything to change as the defaults were already as described, but you might want to insert a VeeCAD.exe entry in the winecfg Applications dialogue for completeness - see the Help screens after you run VeeCAD for the first time. Maybe RTFM applies here! ____
  4. A couple of Xmas's back my dear daughter bought me a full licence for Vcad as a present. I used it to redesign a seven segment display stripboard, and then to layout a larger board simply as a trial. The process was reasonably successful and I verified that Vcad wasn't money wasted. The main problem here was the paucity of available component outlines - much of the work in designing a stripboard with Vcad was to flesh out the very bare symbols library. Recently I revisited Vcad on the Windows laptop and decided to port my purchase to "the big screen"; namely the recently built AMD Ryzen 5 based under-desk that delivers more computer power than I've ever dreamed of. The problem was that in the interim I'd finally carried out the switch away from Windows that I'd been promising myself for decades. I was resigned to keeping a low cost Lenovo laptop pretty much only to run Vcad. In the last few days I've been adding more drives in the Ryzen 5's capacious box and it struck me that I should explore using it for stripboard design. I'd had a fair bit of experience with virtualisation on Windows machines, but didn't fancy a Windows virtual machine on a Linux box even though there was now oodles of RAM and twelve fast CPU cores available. Never having bothered with Wine I decided to see if it was still being actively developed and was pleasantly surprised when I arrived at the Wine website. The install instructions were clear to follow and I had it running on Ubuntu 20.04 in no time. I created a Windows sub-directory in my home directory and a child directory for notepad++. The performance of notepad++ was an eye-opener, so how about Vcad? Had there been an upgrade, or had that Aussie guy simply lost interest, like most stripboard design software authors have over the years? Once again things were much more promising than I'd imagined possible, though it took a short while to locate Mr Lascelles site - it had moved, and so had the name of his package! Yes, Vcad is now called VeeCAD, but the main takeaway here is that the nice Mr Lascelles has opened up the source code and isn't now charging for the full version. You can download it (and the manual) for free from his download links. This guy is obviously a stayer in the game, so many have fallen by the wayside over the years. By opening up the internals of VeeCAD there's scope for others to make incremental improvements. Like notepad++ the installation process on Ubuntu 20.04 under Wine was quick and flawless, but I will cover this in another article very soon. I anticipate that VeeCAD will feature heavily on this site before too long, though I hope the odd few stripboard design software packages still standing will tell us all about their products too. Please feel free to post your experiences with this (and other stripboard design software) in our forums, and share you hints and tips.
  5. Making some Cubie I/O connectors for general use is no trivial task as there are no less than 48 pins on each dual row strip and it involves soldering at at 2mm pitch. Above is the original Cubieboard A10 pinout courtesy of Google Groups, and as the A20 pinout is no different and the PCB reportedly identical, it should be safe to follow it. What can we leave out in order to save a bit of work? Well.. unfortunately there's not a great deal if we want to ensure a full gamut of pins to experiment with. The VGA and CVBS (video blanking) signals seem the only obvious ones, and that still leaves 92 connections including the power pins - sigh! OK, we are off to a good start here; not my best joints but there are no dry ones! Working at 2mm pitch is when solder's surface tension and old shaky hands start to cause problems, and it's difficult to regulate the amount of solder when you use a blunderbuss iron! And no, I haven't forgotten the two bits of heat-shrink - they are well away from the heat. Two days later... Exploring Other Linux Distros As a break from the tedium of wiring I decided to have a quick look at other Linux distros for the CubieBoard2. The obvious one was Cubieeze, so I flashed cubieeze-cb2-card-hdmi-v2.0 to a microSD card. The result was disappointing. It's a Debian Wheezy (V7) hack and showing terminal signs of abandonment - like non-functioning repos! They obviously lost interest here around the time Linaro lost interest in supporting ARM. I decided that with Linaro I'd happened on the best available distro the first time around. Apart from the broken repositories, the Cubieeze version of the D compiler was older at a critical period in the D language development, and I've already decided to use D in this project for a number of reasons I won't expand on now but might just become obvious. Doubling down on Linaro I spent a little time on improving the UI of my SSD rooted copy in line with my likely usage. Getting to the Metal Browsing github.com I happened on a repo called sunxi-tools. This proved rather rewarding as I spotted a file called pio.c which contained the raw code for accessing the pins. I wasn't even sure that Linaro contained /dev pin drivers, but my experience is that these can be slow and limiting. Raw C code to the pins can remove these limitations, and the platform specific nature of direct access is no barrier here as it will port to other A20 boards and non-A20 boards are unlikely to have the peripherals (or compatible drivers) anyway. Compiling pio.c into a command line executable turned out to be very simple as it has practically no dependencies. It was only necessary to copy over the source and an odd couple of header files. The missing version.h header file proved simple to create with the autoversion.sh script. ./autoversion.sh >version.h The resulting pio executable can only be run as root due to the security levels all modern CPUs have these days, but that's not a problem here. Now we've got a way to test the I/O without lots of error prone coding! No Easy to Read Pinout? The pretty picture at the very top of this post is just that - a pretty picture. It's near useless, even on a large sized monitor. The other pinouts I located are confusing, and can only be made any sense of once you realise that the author was viewing the board from the wrong side - except they don't explain that. I thought I was going to have to do my own pinning table until... https://lh4.googleusercontent.com/-QvtBLZErfLM/U8ev9qDqfsI/AAAAAAAARYE/HHC_S_JcMRw/s1600/cubiea10_pinout_rev1.2.alfa_screen_size.png Thank you Tiberiu Corbu for responding to the same general complaint from other people - six years ago! Anyway, how is the new custom connector coming on? Finished - well the first of the two anyway. The leads are correctly colour coded and grouped into bundles of ten. Because the socket strip tabs are fragile I've double heat-shrink sleeved the fanout to give it rigidity and strength. The small plugboard is there for illustration only. Now for some testing before we make the second one...
  6. Answering my own question... yes and no! I managed to acquire quite a few of these little modules, and there's still quite a bit of support around. Stay tuned!
  7. Description: Part Number: Category: Sample Supplier: Unit Price: Board reverse showing regulator
  8. COTB

    Free Stripboard Now!

    For the first twenty posters of a project built on Stripboard only: post details and photos of your project built on Stripboard in these forums and I will send you a small pack of Stripboards from my present collection at my sole expense. The simple conditions are: The project must be non-trivial - (no LED plus a resistor!). The project must function in some meaningful way. At least 50% of the wiring must be on an actual piece of standard Stripboard. Your description must run to at least 100 words accompanied by at least two reasonable pictures. You must PM me through this board with the postal address to send your reward to. (I won't exchange e-mails). My decision on if your project qualifies for a reward is final. The ongoing shipping risk is yours once I deliver your reward to my local post office. (no second postings). I will use the cheapest uninsured postal method, so you may have to be patient. Only the first twenty such projects qualify though I might show a little flexibility if there are edge cases here. You should show a little willingness to answer other people's questions about your project. Other benefits of joining in here as a member: Private hobbyists can advertise their surplus components and other electronic junk for free. You'll never be bothered with any on-site advertising or spam emails. (I couldn't give a xxxx if there's zero revenue!). You'll never be asked for sponsorship: my hobby is my hobby. Start (and fully moderate) your own forum, just so long as it's of general interest to electronic hobbyists. (PM me on this). My aim is to get this free and non-commercial forum off the ground, so barriers to freebies will increase as time goes on. I've set about 100 GBP of my own money aside for this little promotion, so hopefully everyone will benefit in some way. I will publicly acknowledge your contribution and advise the date your reward was posted right here on the forums. Quite obviously your personal details won't be published or recorded anywhere on the site. There is no commercial motivation whatsoever behind this offer: this site is purely a recreational hobby! Get constructing!
  9. Or... what can you REALLY do with a CubieBoard2 in 2020? During the recent Covid lock-down I started sorting my technojunk boxes. This came to a halt when I happened on some Cubie purchases from 2013 and fired up a CubieBoard2 I'd never really got to grips with. So why not document my experiences in order to benefit others? Well.. as you ask...! Android 4.2.2: slightly less useful than Fortran 77! The CubieBord2 boots into Android. Not too many of the in-ROM apps still work, and there's no longer much in Play Store that is compatible. I've yet to find an image of a more up-to-date Android, and even then 1GB of RAM (less screen estate) is pathetically little for current Android versions. The 4GB nand Flash capacity is further compromised by all the small partitions on it, resulting in very little free space where it matters. Time to see if we can ditch Android and all its baggage! The most up-to-date Linux distro I could readily find for the CubieBoad2 was Linaro 14.xx - this is a repackaged and much pruned Ubuntu 14 (Warthog?). A boot block on the microSD gets priority over one on the on-board nand so there's no configuration to do in order to boot into an alternative OS. Writing the image file to a microSD was easy and it booted straight away. Here's how to prepare the card using a second Linux machine: # First determine for SURE which device name represents your microSD in the current session (substitute in x below) $ sudo umount /dev/sdx $ sudo dd if=linaro-14.04-desktop-cb2-card0-hdmi-v1.0.img of=/dev/sdx $ sync WARNING: Triple check the outfile device name before invoking dd as there is huge potential here to trash your machine if you accidentally name a working drive! After Linaro booted I copied the SD card's file system to the SSD (also using dd) and expanded the new SSD Linux root partition to 120GB or so. The SSD read and write speeds were way above those from the flash card (and the nand), so even though the O/S was quite dated the overall system started to look very promising. So how about booting directly to the SSD? This isn't possible from the undocumented (and non-programmable) start-up ROM inside the A20. That's understandable as this tiny bit of code that loads and transfers control to u-boot (the second stage of the boot process) isn't SATA aware. The current u-boot doesn't seem to be terribly intelligent either! In any case you need somewhere to locate u-boot that doesn't involve the SATA: this means either in the nand or on the microSD card. First let's try booting through the nand by finding a more intelligent u-boot and flashing it, or somehow patching the nand image to force the Linux root to be on the SSD... Getting serious: re-flashing the onboard Nand Allwinner supply utilities to flash the A20's external nand memory for both Windows and Linux. This is called Phoenix Suit for Windows and LiveSuit for Linux. I went the Linux path, of course! In good old Linux fashion you need to build it yourself. First step is to clone the repo into a working directory on your own machine: If you have a github.com account you can: cd ~/workdir git clone https://github.com/linux-sunxi/sunxi-livesuite.git Or without a github.com account visit https://github.com/linux-sunxi/sunxi-livesuite download the .zip file and expand it into your working directory. Now simply follow the directions in the READ.ME remembering you need to invoke make as superuser (sudo make works of course). Except... the READ.ME omits a few very necessary steps. In particular it fails to tell you that you must invoke depmod before modprobe, and I found that it's use of a kernel subdirectory didn't work (cp to the modules root directory). sudo cp awusb.ko /lib/modules/`uname -r`/ sudo depmod -a sudo modprobe awusb ________________________________ Problems you'll likely encounter: My first attempt at a make threw up mysterious errors until I edited file awusb.c in the awusb directory. The edit required was to change the #include <linux/signal.h> to #include <linux/sched/signal.h>. Now it compiles! A further problem was that Ubuntu (from about version 18 onwards) removed the libpng12-0 libraries that running the LiveSuit binary requires. The fix (acknowledgement here to linuxuprising.com) was: sudo add-apt-repository ppa:linuxuprising/libpng12 sudo apt update sudo apt install libpng12-0 Something else the READ.ME doesn't tell you is that access to the USB port for non-root users is blocked until you enable it by adding a 50-awusb.rules file to the /etc/udev/rules.d directory containing the single line KERNEL=="aw_efex[0-9]*", MODE="0666" then reloading the user device rules with a... sudo udevadm control --reload-rules Reportedly the very latest Ubuntu v20.xx also throws up an additional error due to one of the Linux source code files not being found on the system. The solution involves an apt install linux-source. ________________________________ Allwinner LiveSuit in action! After installing Allwinner's USB driver I had a long hair-tearing session getting an image to flash. Google soon appraised me that I was not alone, and that no one had actually documented a solution. So how many experimenters have given up at this point? LiveSuit was actually failing somewhat after a message about DRAM size, and others have clearly assumed that this was the problem. The whole log output of LiveSuit is basically Chinglish and taking the messages literally is a blind alley to go down. In fact LiveSuit was executing normally, and all the image files I had previously tried had a problem. It took me some time bumbling around the Internet until I found the essential source of cubie image files of unflawed nand images and after that SUCCESS! LiveSuit takes a few minutes and does the image file flash in increments, but it gets there in the end. Getting the Cubieboard2 into FEL mode in order to flash it is described at various places on the Internet, and also in Chinglish on the LiveSuit screen. But on the Cubieboard2 these methods can be awkward (and painful) with the silly positioning of the FEL button right under the mini-USB OTG port. I've found by far the easiest way is to remove both the mini-USB connector and the power jack. Hold the FEL button in and them plug the power jack in. The board is now in FEL mode, so you can release the button at your leisure without any gymnastics or any contact at all with the - also awkwardly placed - power button. To initiate the flash simply plug the mini-USB connector in at your leisure. Nice BUT... Unfortunately my first successful flash was er... Android 4.2.2... because you can't simply take a disk image file and flash it to nand - it has to be in a special format which LiveSuit accepts. Without the memory card we were now booting into a nicer version of Android 4.2.2 with a pretty Allwinner A20 splash screen. Well, proof of concept anyway! Time is pressing, so now that we at least have the technology to engineer a boot without the microSD card, it's time to create a working Linux system that executes out of a big fast SSD and leave the niceties of ditching the memory card to a later session. Boot into the SSD Linux image proved surprisingly easy as all that was actually necessary was to edit the first line of the eEnv.txt text file in the first small partition of the memory card (not the image of this partition on the SSD) to read: root=/dev/sd2 Running the storage system entirely from the SSD made a huge difference to performance and usability! Some perspex plates that came with the board years ago; a few brass spacers; a cheapo hard drive caddy; and a generous helping of self-adhesive Velcro tape, tidied the whole thing up into a compact desktop development system. I created a 2GB swap (Type 82) partition on the SSD and checked that it was working by maxing the swappiness and loading every GUI window I could whilst running the top utility. Oh! Linux doesn't like swapping out RAM: all I was able to force it to use was a paltry few KBytes! 2GB was obviously way excessive here, but even though the system wasn't very swappie I left the swap file in use, because with only 1GB of RAM every little bit helps; the SSD was a lot faster than a normal hard drive swap; and I had loads of unused space on the SSD. Some of the other things I then did: sudo apt remove chromium-browser sudo apt install firefox sudo apt-get autoremove sudo apt install gdc ### The D Language compiler So that's it for now whilst I play with my new Linux development system. Those 2mm row-pitch sockets in foreground of the second photo are to create some custom I/O connectors - but A20 I/O is a story for another day!
  1. Load more activity
×
×
  • Create New...