Jump to content

All Activity

This stream auto-updates     

  1. Today
  2. 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 wine 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. ____
  3. 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.
  4. Earlier
  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...