So I've been working on getting the de0-nano fpga to control an 32x32 LED matrix display and struggled to get any expected output, so I switched to using a beaglebone black to try controlling in a way that I'd done with a previous display only to get the same results. See the picture below. I can light up different rows but only the first 16 LED's seem to light up reliably and only in green, sometimes the red ones blink on for a few seconds but thats all I can get.
Knowing that what I'd tried with the Beaglebone should work as it has done before I decided to look at the matrix display itself and decided the capacitors looked a bit yucky at the bottom (pic below) so decided to change them out for some fresh ones.
After I got the first one switched out, something caught my eye. One of the IC's has a hole going straight through the top of it into the die. Most of the IC's do have bubbles formed on the top of them due to the coating that covers the entire board but this is definitely a hole...
It looks like Im going to have to find another project for the de0-nano, though I will be ordering another one of these displays in the future. I bought this as a lot of 2 from ebay and the first one I used worked perfectly fine it really is a shame this one doesn't as I was looking forward to expanding on what I'd done with the first screen and displaying moving images
After a busy couple of months spent moving house, doing renovations and re-arranging work I've finally got my BigTrak project back out. I tested a circuit to allow me to re-use the existing optical encoders, burnt a couple of transistors testing out a H-bridge before settling for an off the shelf motor driver from ebay! (I guess bc237/bc238 transistor combo's just aren't cut out for driving motors but theyre the beefiest I had to hand... )
The 2nd part of this mini series goes through the motions of desoldering the motors right-angle daughter board from the main circuit board, removing the optical encoders and looking closer at the motor control circuit and how it differs from the original bigtrak model.
For the BigTrak conversion project, I plan to retrofit the lunar rover toy with a modern small board computer like a Raspberry Pi or something similar, my plans to start with are to install the new hardware and get it to function like the original device and then add other hardware/software components at a later time.
Today I took apart the bigtrak lunar rover toy for some preliminary investigations, I discovered that the drive trains feedback system uses optical encoders rather than hall effect sensors which are described in the wikipedia article.
There are magnets attached to the motors but these form a rudimentary synch lock mechanism, while the bigtrak is driving in a straight line the magnets pull each other forward or drag backwards to correct for slight drift in the motors.
I had a quick look at the main circuit board too, its pretty crusty and the ic's are black blobs but interestingly not formed on the main circuit board, they've been blob formed onto a separate circuit bard which has been cut out and then soldered onto the main circuit board.
Finally a quick look at the sounds the bigtrak makes using an oscilloscope. It'd be great to keep the original sounds which are quite basic tones so I plan to find their frequencies to replicate them.
Lucie's Upcoming Project Overview
Below is a quick outline of ongoing projects that are going to be cropping up in my blog and other relevant sections. Each will have their own content index page that will be updated with relevant posts, the first should be coming soon!!
Project 1 - Adventures With Beaglebone Black
Recently, I've been meddling with different ways to control the GPIO and other on board peripherals of the BBB to help with the work flow of a different project. Being informative in it's own right, I gathered plenty of information along the way to create a mini blog series when time came available.
And then..... a discussion started here on element14 which has spurred me to advance on this project and hopefully open up more of the potential locked in the BBB to non-programmers and end users.
So what's the plan?
We can create small Python scripts that stay on the BBB, these will be responsible for doing the actual device control (turning gpio on and off, reading values etc...).
And that's where things are right now. The "Plan" is to evolve this into much more all round system that will enable full device control using a graphical interface / toolkit. Keeping the graphical front end as a different system to the Python scripts running on the "back end" should allow it to adapt much more readily to other SBC's and device upgrades.
It's not all plain sailing though, thar be many a hidden pitfall ahead....
Project 2 - Practical IC's For Meddling Modders!!
Integrated Circuits are a great way to add extra abilities, tweaks and mod's to projects. In a time where everything seems to be about super small board computers and the Internet of Things, it's easy to get caught up in the latest trends and forget about what IC's have to offer.
Practical IC's is a video series exploring some common parts, testing out their features in a breadboard and seeing what uses we can put them to!!
Project 3 - Fun With Robots!!
Looking through some boxes a few weeks ago, I came across an old robot I made many moons ago. All broken up yet still recognisable, my eyes were looking upon a very sorry state indeed... I was sad
Bugsy was never meant to be a serious robot, he was more of a plaything and made me happy... Getting accurate sensor data, precise localisations, highly tuned actuator response and all of the other boring stuff was never what Bugsy was about... He was the type of robot where personality and not taking life too seriously really mattered, he enjoyed running round chasing the sun and hiding in the shadows ready to pounce on unsuspecting moving objects while all the other robots drove each other into the wall jostling for a place on the electron super highway...
Fun With Robots is a blog series inspired by the same concept as Bugsy. Developing a robot for fun, not being too serious and keeping within the realms of what's realistic. Full HD stereo vision might seem like a bright idea but it's a time trap, ready to capture the unsuspecting and make them forget what they were doing in the first place (plus it's just an unrealistic amount of work for something that's gonna fit onto a small robot - not to mention that real bugs don't see that well so it cant be that important...).
Getting the physical frame and moving parts working is first on the agenda. Bugsy v1 had a PIC16F74 and Bugsy v2 had a PIC18F4550 as the main processor, there are vastly more powerful options available now opening up a whole new world of possibilities.
One thing that I meant to implement never did, is to implement some level of sound capture and possibly recognition. Once things are up and running, this is going to be a regular point of focus; sound recognition has it's own unexplored but very much intriguing depths for me... working with most data is fairly obvious, especially things like pictures where the data range is within geometric bounds (as in X,Y,Z). To be able to form a patternation out of sound, one of those geometries is time. In other words, you can see all of the data in a picture at once but sound data isn't all heard at once, it comes into the ear gradually. I have some ideas for working with this starting with the very very basic...
In Memory Of Bugsy
"dear bugsy, let no mortal human say you died in vain.. while your legacy carries on into a new form, so your spirit shall live on."
The past few days, I've been sketching up a few ideas for how the enclosure or console case should look. Yesterday was spent drawing up a finalised design and tweaking it a bit then working out the other electronic components that are going to be needed.
My original intention was to just post up some design pictures, but during a spell of insomnia last night, decided to do a quick video about it all. Its pretty long (about half an hour); I was in my own little world and full on natter mode at the same time.. I'll be surprised if anybody gets to the end of the video with all my chattering hah!!
There's some pictures below that I pulled out of the video for those who want a brief overview instead of being incessantly talked at!
A quick round up of whats going on..
Firstly the dimensions of Gizmo2 were sketched out as a starting point, Then using tracing paper, added an overlay to draw out a top down view of the enclosure to actual size. Another overlay placed on the top fills the design with colour.
Sometimes I do things in graphics packages on the computer but I also love to sit back and design things on paper too! I love using a compass and ruler / straight edge Euclidian style designing!!
After that, I went through the materials I had to make the case out of, mainly being 2 types of Aluminium composite (a sheet of polycarbonate sandwiched between 2 thin layers of aluminium) in black and brushed steel effect. Then some translucent orange acrylic sheet .
Extra components that are going to be used include:
- Espruino to fast prototype external logic
- I2C port expanders to control activity Led's
- Bar graph displays
- Red or Orange 16x2 character LCD (ive not decided on the final colour yet).
- plus a few other bits and bobs and ramblings!!!
From the first thoughts on this project, I knew there needs to be an LCD on the gaming console. It's something that I've never seen before on one, but think it would add so much to the overall look of the system.
It's not a simple task by any means to incorporate an LCD screen and means working out how to control the GPIO through ubuntu, but it becomes more difficult thinking about the information actually displayed. What's going to be written on it?
The easiest messages to display are "booting up" and "closing down", maybe temperature data, fan speed, time, volume and the usual things on a computer based LCD (they're not overly common but I've fitted a few in the past). But I really want it to be a bit more interactive with what's going on in the system as well.
If its going to need to display the time when the console is powered off then do I need to have a separate controller for it? If so should I start working on an I2C bridge controller to control the display and allow it to keep powered up but dimmed in standby mode? Extra scripts would be needed to synch the system clocks together. choices choices...
At the minute, I'm looking at launching the games as individual xsession's from the login screen without any desktop environment. If I go in this direction, there should be an opportunity to write a configuration script for each game in Python based around a universal template. Rather than launch the game directly, it would be the script that gets launched that opens up more interactivity as demonstrated below:-
1) A list of games displays on the login screen or in a custom menu
2) An initialisation Python script sends a welcome message to the LCD
3) User selects game from a list.
4) A Python configuration script executes
5) The script sends a "loading.. please wait" message to the LCD
6) The script starts the game as a system task
7) Once ready, the script displays the name of the game on the LCD
8) When the game closes, the script sends a closing message to the LCD
9) The script exits once the system task has exited
10) return to the menu / log in screen
If there's any other information that can be syphoned off with Python then I'll see what I can do with it.
The first part of the Hadron Vortex G2 project is all about the software. Important milestone are installing and configuring an operating system for administration, Installing and configuring gaming emulators, creating custom launchers for the games to run independantly without desktop support.
Risers have been installed onto the four corners of the Gizmo 2 board to act as legs and keep it's base raised above my desk to prevent any short circuits or static generated from the surface it's sat on.
Included In This Update:
1) Hardinfo reports - hardinfo is an application that creates a hardware and software profile of the system and does some basic benchmarking. *
2) Fitting mSata ssd drive.
3) Installing an operating system.
4) Video recording of boot up demonstrating expected turn on times.
Additional Pictures Included At The Bottom.
* one important thing of note regarding hardware reports is the system memory is only ever showing a maximum of 750MB rather than the 1GB that is installed. I expect that the missing 250MB is allocated to the onchip graphics, or to manage data between the dual cores and the system as a whole.
hardinfo generates a complete system report as a HTML file, click on the links below to view them.
The msata drive fits into the socket easily from a slight angle, though it doesn't plug or clip into the socket and bounces back up so it needs to be fixed down with plugs or screws. In it's natural flat position, it hovers over the main board by about 4mm so risers or sprung plugs would make good mounting options.
I was hoping to use some of the spring mount plugs that are used to fit heatsinks over North Bridges and Processors but couldn't find any suitable, I did find that the small risers that are provided on VGA sockets that the plugs screw into are perfect.
Images of the fitting:
The system I've been using for testing the emulators is running Ubuntu Linux. Knowing that this worked well, I decided to keep with it and use it as a base operating system.
Until the mSATA drive arrived, I was stuck with using bootable USB images. I had a brief look at the Timesys system that was shipped with the Gizmo 2 and was a pretty much basic system with a proprietry GUI. I think others have previously mentioned that the GUI isn't overly intuitive which it isn't if you consider it as a computer. Being looked at as a media centre, it's just another menu driven system that a home user would get used to.
The main problem with the software that is shipped is the lack of configurability. It's kind of a what you see is what you get and doesn't have any easy method for adding your own software.
** Another variant of Linux I used on Gizmo was a distribution called Macpup; which is a very lightweight but powerful operating system that has been designed to visually resemble mac operating systems. Once on a USB drive, it quickly unpacks its entire compressed filesystem into ram and uses this as a ramdisk as it's root. This means that files are aready present in ram so makes for a super speedy experience. There's all the usual software installed and also comes with it's own graphical based package manager to help install other software. Most of what's available in the package manager is useful, functional, lightweight and fast. It's a great little operating system, handy to have around on a USB drive for system recoveries or maintenance but probably not the best option if you don't have much knowledge of Linux. **
Once I had the mSata I downloaded an image of Ubuntu 14.10 (Utopic). There has been a new release since that one (15.4 Vivid Vole) but again, I wanted to match the system I already had working well. The image booted up straight away and installed like a dream, If you've never tried Linux before then I urge you to give Ubuntu a try, it really does make Linux user friendly enough for anybody to get to grips with.
After Installation, there is a default desktop (Unity) that ships with it, I prefer to use Gnome as a desktop shell and then have Cairo Dock running at the same time which is a very powerful and configurable application toolbar.
Originally, I was going to completely remove the feature rich Desktop and File Manager in favour of a lightweight version like XFDE or LXDE but my experiences with Gizmo 2 so far made me realise it was more powerful than I originally thought and decided to push the system further than I originally intended.
I'm only about a quarter of the way through configuring the system to how I like it but the installation process including terminal commands are in the document below. This stage is all about configuring the environment to perform system administration and general computer use on. I haven't started with the emulators yet as they are going to be launched without a desktop environment to utilise as much of the hardware capabilities as possible without the burden of other background software that normally runs alongside games.
The video below shows the initial boot up performance of the Gizmo2 board running Ubuntu.
Boot Time to login manager: 25 seconds (4 seconds in --> 29 seconds in).
-This is where the game selector menu will be.
Ubuntu Unity start time from login manager: 16 seconds (34 seconds in --> 50 seconds in).
What is it?
It's the project I'm working on in order to review the Gizmo2 single board computer as part of a roadtest here at Element 14.
For my project, I chose to make a retro style games console that plays emulated games initially from the amiga and arcade machine platforms.
Why "Hadron Vortex G2?"
With it being retro styled I also wanted it have a retro type name. The very first video game system was called the Magnavox Odyssey and then came name like Master System and Mega Drive. I think Hadron Vortex G2 fits in quite well with the video console names from the past! (plus it took me a full night to think it up and now I've chosen it, It's set in stone..)
Here's a little more about the project
Ubuntu is going to be the main operating system, but it's going to be heavily modified. There is going to be a standard desktop environment for system maintenance and administration but the emulators that are going to be installed will run straight their own xsessions so more of the system resources can be used for gaming instead of having a desktop shell, file manager and all other bits and pieces to slow it down.
The Gizmo 2 is of course going to be at the heart of the project, I won't list it's technical qualities here, I'm sure I'll be including them in more of a dedicated blog. The software is going to run from an mSATA ssd drive, compatability software to use USB Playstation gamepads will also be installed.
There are some GPIO ports on the Gizmo2 that I am expecting to connect other electronics hardware and interfaces to.
When this project is finished, I want to have it installed in a custom enclosure. I haven't decided on a final design yet; but do have some ideas, overall I'm hoping to make a futuristic looking console with features from older gaming consoles all in a style befitting a cybergrunge look.
As mentioned above, there are some GPIO ports available to use. My original idea was to attach a VFD display, but I already used that in a project for customer. I do have a 2 x 16 character LCD display with a blue backlight that should fit in well with the look(although I'm considering getting a red / pink version). Some parts of the case are liable to be clear or translucent so I'll also be looking at controlling some LED's through the GPIO too.
I'm expecting to finish the project by the end of May in time for the Gizmo 2 review, that way, Ive got something to base the review around.
I've already been surprised in a few ways by the Gizmo 2 and have reconsidered some of the things I would have expected but never tried unless I was using it in this project.
visit http://www.element14.com/community/people/violet/blog/2015/04/15/hadron-vortex-g2--content-index for an index of progress reports, technical details and much much more.
Content will be added regularly until the project is complete so don't forget to keep checking back!!
This is where new content updates and links will appear as progress is made:
1) Picture advert exploiting Courseware mode on Tektronix TBS1202B-EDU http://www.element14.com/community/people/violet/blog/2015/04/14/gizmo-2-roadtest-project--hadronvortexg2
2) Cyberpunk distopian style teaser video http://www.element14.com/community/people/violet/blog/2015/04/15/hadron-vortex-g2-video-transmission
5) Some thoughts on interfacing a small LCD http://www.element14.com/community/people/violet/blog/2015/04/16/hadron-vortex-g2--lcd-feature-overview
6) Adding Catalyst fire HD hardware driver http://www.element14.com/community/community/designcenter/single-board-computers/gizmo2/blog/2015/04/17/gizmo-on-fire
7) Testing Gizmo's Graphics Capailities http://www.element14.com/community/community/designcenter/single-board-computers/gizmo2/blog/2015/04/18/gizmo-vs-warsow-flawless-victory
8) Finished installing Core Software plus 64bit upgrade http://www.element14.com/community/community/designcenter/single-board-computers/gizmo2/blog/2015/04/26/hadron-vortex-g2--core-software-finalised
10) Launching applications without a desktop http://www.element14.com/community/community/designcenter/single-board-computers/gizmo2/blog/2015/04/27/hadron-vortex-g2--launching-gui-apps-without-desktop
11) Installing MAME multiple arcade machine emulator http://www.element14.com/community/community/designcenter/single-board-computers/gizmo2/blog/2015/04/28/hadron-vortex-g2--installing-mame
13) Concept artwork and final design for enclosure plus list of extra components, building materials and lots of late night chattering! http://www.element14.com/community/people/violet/blog/2015/05/06/hadron-vortex-g2--enclosure-concept-drawing
16) Launching applications without a desktop http://www.element14.com/community/community/designcenter/single-board-computers/gizmo2/blog/2015/04/27/hadron-vortex-g2--launching-gui-apps-without-desktop
17) Progress update - final look at the case during construction http://www.element14.com/community/community/designcenter/single-board-computers/gizmo2/blog/2015/05/28/hadron-vortex-g2--progress-update-2
Restoring the Espruino bootloader using a Beaglebone Black's serial UART
I recently damaged the firmware and the USB bootloader on my Espruino, remembering that the STM32 which is at the core of the Espruino has a hardcoded bootloader that can be used to restore the firmware by uploading it through 3v TTL serial transfer.
Heading over to the Espruino website, I found this guide http://www.espruino.com/Serial+Bootloader
which has instructions for programming the Espruino using a USB-TTL converter. Not having one of those and exhausting a few other methods I gave up for the time being until I had a new idea.
The BBB has 6 serial UART's on board that run at 3v TTL, however only one of them is enabled as default and that is already in use being linked to the serial console.
The other UART's must be enabled by modifying the uEnv.txt file. An easy way to modify this is to connect the BBB to your computer using a USB cable so it appears as a flash drive. The uEnv.txt file should be located in that drive and can be modified with any standard text editor. (the precise location differs with each variant of Linux, with the standard Debian version, it should appear in the files when you first open the drive).
If you are modifying it from within the BBB's file system then it will be in the /boot/ folder or a child folder within that.
Once it's open, just add the following line:-
I'm not sure that it matters where it goes but I added it straight below the line that says:
##BeagleBone Cape Overrides
Again, there's a likelihood that other variants of Linux may have a different format to the uEnv.txt file, so you will need to use your judgement as to where best modify it.
Once you reset your BBB, UART 4 should be enabled and we can check by connecting to the BBB in a terminal and typing
there should be 2 items returned in the list: /dev/ttyO0 /dev/ttyO4
/dev/ttyO4 is the serial UART we just enabled
It's a good idea from this point to head over to http://www.espruino.com/Serial+Bootloader and follow the guide in order to understand how to put the STM32 into serial bootloader mode.
Download the stm32loader.py script and the latest Espruino binary from the link above and transfer these over to your BBB. I used the scp command from a terminal, but you could even just put them on a micro-sd card and put them onto your BBB like that.
The next step is to connect the Espruino to the BBB, and make sure the Espruino is wired up to enable the serial bootloader as follows:-
Espruino BOOT0 > Espruino 3.3v
Espruino BOOT1(PB2) > Espruino GND
Espruino PA9(tx) > BBB P9 – 11 (rx)
Espruino PA10(rx) > BBB P9 – 13 (tx)
Espruino GND > BBB GND
Espruino 3.3v > BBB 3.3v
*the BOOT0 pin is labelled BOOT0 and is near the STM32 device.
It's probably best to leave connecting the 3.3v supplies until just before you start programming in case the bootloader times out.
Log onto the BBB using a terminal as normal, navigate to the folder where you have your stm32loader.py and espruino binary and enter the following line:
(it's the same as the guide in the link above only we're using a specific serial port)
python stm32loader.py -p /dev/ttyO4 -evw espruino_for_your_device.bin
remember to change the 'espruino_for_your_device.bin' to the specific file that you downloaded, in my case it was:
python stm32loader.py -p /dev/ttyO4 -evw espruino_1v75_espruino_1r3.bin
I waited until just before I pressed enter to make the 3.3v connection between the BBB and the Espruino and as it says on the serial bootloader page on the Espruino website:
Note: The flasher may give you an error message such as Chip replied with a NACK. If so, just try running it again without resetting your board.
This happened with me and the trick really is to not reset your board, just run the command again and it will start programming the Espruino software.
Once finished, disconnect the power to the Espruino, disconnect the BOOT0 and BOOT1 pins and re-apply power, the Espruino should boot up as normal with the new firmware.