Skip navigation

Introduction

 

So it's 2017 and whether you use bitcoin in your everyday lives, for future investment or don't know enough about it to use it we've all still at least heard of it!

 

Bitcoin was the first of its kind and remains today as the major player in the crytocurrency market, if you've never really bothered with cryptocurrencies you might be surprised to realize that bitcoin isn't the only cryptocurrency in the market there are others too such as ethereum, ripple, litecoin, monero and dark coin plus hundreds more but none have yet overcome bitcoin in market share. In Newyork you can buy coffee from street cafe's using your bitcoin, buy groceries even but not everywhere has taken to it equally, people are still suspicious but despite this there are some steps forward being made, bitcoin ATM's are starting to appear on high streets and in convenience stores around the world you can even check google for the location of a bitcoin ATM near you where you can load up your bitcoin wallet with regular cash or transactions.

 

But did you know the bitcoin system isn't perfect? The bitcoin system does change gradually when everybody in its development system agrees, if there isn't unanimous agreement to the changes then they are simply not added to the system. But what happens when somebody is so sure a change is a good idea that they want it implementing whether everybody agrees or not? A hard Fork thats what!

 

So What Is A Hard Fork?

 

Well a little bit of background first, the bitcoin system works through blockchain technology, where bitcoin mining creates new blocks and each block can hold 1MB of transaction data which worked really well until the system hit an invisible wall. This occurred because so many transactions were happening that the miners couldn't produce enough new blocks to store all of those transactions so the system ground to a halt and slowly recovered over the course of a few days. During this time transactions were taking hours, even days to resolve on the network and alarm bells started to ring. The bitcoin system needed and upgrade and so one was suggested, the new upgrade would allow the blocks to be scalable in size so rather than a block being able to only hold 1MB of transaction data, over time these could be scaled up to 8MB size blocks that could hold more data and absorb the effects rapid transactions but not everybody was in agreement that this would be the best way to move forward and this is where a hard fork happened in the bitcoin system.

 

On the 1st Aug 2017 the bitcoin system stopped trading for a few hours while a copy of its blockchain happened (the blockchain contains every transaction ever made by the bitcoin system). Bitcoin started trading again as normal but the copy of the blockchain produced a completely new currency which was to be called "bitcoin cash" It has all of the original history of bitcoin but it was free to implement its scaling block size feature. If you owned any bitcoins at this moment in time, you got to keep your original bitcoins but because this new currency copied the original blockchain it meant that you got that same amount of coins in the new currency too.

 

So on 1st Aug 2017 if you had just 1 bitcoin its value was $2,735.59 at close of trading, now when the fork happened you kept that bitcoin(BTC) but also gain 1 coin of bitcoincash(BCH). Fastforward a couple of months and as I write this the value of this new currency is $322.14 per coin of bitcoin cash(BCH) so you would have gained that for doing absolutely nothing. (not to mention that the value of the original bitcoin(BTC) is now worth $6080.42 so if you did have just 1 bitcoin back then you would have more than doubled your money in the space of a couple of months!)

 

And What Does This Have To Do With Raspberry Pi's?

 

Well the process of making new blocks on the blockchain happens when a bitcoin miner successfully solves SHA256 hash algorithms which means that anybody with spare computer time can dedicate it to solving these algorithms, producing new blocks and in turn earning some bitcoin for the effort. Of course Raspberry Pi's were soon on the scene and for a relatively small investment people could have a dedicated bitcoin miner which worked 100% of the time contributing to the bitcoin system and earning them bitcoins as they slept! People started setting up distributed computing systems and Raspberry Pi cluster to gain the upper hand but it wasn't long before other technology took over in the name of FPGA's. People realized that SHA256 algorithms could be solved orders of magnitude faster using dedicated FPGA's which meant that slower systems li9ke Raspberry Pi's stood no chance of competing and soon bitcoin mining on processor based system became a worthless fruitless endeaver.

 

FPGA mining became so popular that the big players got together and developed a custom ASIC to do the job of mining, where a processer can mine 5-10MH/s the custom ASIC's can mine 5-10TH/s which is pretty much a million times more per second than processor based systems.

 

The original idea of bitcoin was for it to be a decentralized currency where no 1 person or collective of people can make changes that would restrict its normal value but as less and less people are contributing towards bitcoin mining because of these big players its soon going to leave just a consortium of large organised ASIC based bitcoin miners who would then have the ability to increase or restrict the flow of bitcoins into the market thereby gaining control over the value of the currency. By controlling the system they could decide how many blocks to add into the blockchain and control the rate of transactions.

 

In an attempt to restore this de-centralization a new hard fork is going to occur (planned for 25th October 2017) to create a new currency called bitcoin gold(BTG) where the major change will be the algorithms that need resolving to create new blocks on the blockchain, the original bitcoin will still exist and as before you keep your original coins but also gain that same amount of coins in the new currency.

 

So What Are These Changes And What Does They Have To Do With Raspberry Pi's?

 

Well the new coin Bitcoin Gold(BTG) aims to make mining bitcoins a more level playing field once again by using Equihash mining rather SHA256 mining. Equihash mining is more complex and requires more memory based solutions transferring values backwards and forwards which should take away some of the advantage of using ASIC's. Its thought that using an equihash based system normal processors will be able to mine at around 10-30H/s and FPGA/ASIC systems will mine at around 1000-3000H/s so the ASIC based systems will still have an advantage but only in the order of about 100 times more per second rather than the million times it is with SHA256.

 

And what does it have to do with Raspberry Pi's? well if this new cryptocurrency takes off we should start seeing more people mining bitcoins with processor based systems again and renewed interest in Rasberry Pi based bitcoin miners if you have one sat collecting dust in a drawer maybe you should think about mining Bitcoin Gold(BTG) with it while you sleep!

 

Will Bitcoin Gold Take Off?

 

Bitcoin gold isn't the only hard fork coming up, theres also the segwit2x/BTC1 fork approaching too and with a previous hard fork Bitcoin Cash it means that there are a lot of cryptocurrencies appearing based upon the original bitcoin which I think we can agree will always be there but who knows if these new currencies produced by hard forks are going to stand the test of time. I suppose it depends on whether people actually use them, invest in them and most importantly whether their promises work out. All it takes is for somebody to create an FPGA/processor hybrid that can gain huge advantage over normal processor based system again to sink the dreams of Bitcoin Gold. We'll have to wait and see!

 

Do you have any thoughts? Is it going to work out? Do you want to hear more about bitcoin and cryptocurrencies? Leave your comments below!

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.

 

IMG_2124.JPG

 

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.

 

IMG_2128.JPG

 

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...

 

IMG_2145.JPG

 

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 tozer

Upcoming Projects

Posted by lucie tozer Top Member Jul 20, 2015

Lucie's Upcoming Project Overview

  lem.png

 

 

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?

 

Right now I have a nifty little system developed where the BBB hosts a simple web server. The BBB web server hosts internet pages like any other webserver. When a user navigates to the BBB, it serves them up a web page with standard HTML buttons. Clicking on a button allows a Javascript function to run.

 

So far, the HTML and Javascript originated from the BBB but it's all been transferred and is running on the clients system rather than the BBB server. So if it's all running on the clients system, how do we get it to control the BBB??

 

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...).

 

All that's needed now is something that can talk between the webpage on the client device and the Python scripts on the BBB. The answer comes in the form of XMLHTTPRequest's ; The Javascript functions on the web page can use XMLHttpRequest() to send and receive information from the Python scripts which can in turn control the hardware, COOL!!!

 

  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."

 

a.jpg

 

a1.jpg

 

b.jpg

 

d.jpg

 

e.jpg

 

f.jpg

 

g.jpg

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!!!

 

 

im1.jpgim2.jpgim3.jpgim4.jpgim5.jpgim6.jpgim7.jpgim8.jpgim9.jpgim10.jpgim11.jpgim12.jpgim13.jpgim14.jpgimbon.jpg

 

DREMEL TIME!!!!

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.

 

Lucie

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.

 

 

 

-----------------------------------------------------------------------------------------

SECTION 1

----------------------------------------------------------------------------------------

 

hardinfo generates a complete system report as a HTML file, click on the links below to view them.

 

http://www.element14.com/community/servlet/JiveServlet/downloadBody/76197-102-1-315694/hardinfo_report_macpup.html.zip

http://www.element14.com/community/servlet/JiveServlet/downloadBody/76198-102-1-315695/hardinfo_report_ubuntu_unity.html.zip

http://www.element14.com/community/servlet/JiveServlet/downloadBody/76199-102-1-315696/hardinfo_report_ubuntu_gnome.html.zip

http://www.element14.com/community/servlet/JiveServlet/downloadBody/76200-102-1-315697/hardinfo_report_ubuntu_gnome_root.html.zip

 

-----------------------------------------------------------------------------------------

SECTION 2

-----------------------------------------------------------------------------------------

 

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:

 

msata1.jpgmsata2.jpg

 

msata3.jpgmsata4.jpg

 

msata5.jpgmsata6.jpg

 

----------------------------------------------------------------------------------------------

SECTION 3

----------------------------------------------------------------------------------------------

 

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.

 

http://www.element14.com/community/servlet/JiveServlet/downloadBody/76201-102-1-315699/SystemConfig1.txt.zip

 

----------------------------------------------------------------------------------------------------

SECTION 4

---------------------------------------------------------------------------------------------------

 

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).

 

Superb Performance!!

 

 

--------------------------------------------------------------------------------------------------

ADDITIONAL PICTURES


extra_pic1.jpg

 

extra_pic1.jpg

 

extra_pic1.jpgextra_pic2.jpg

 

extra_pic3.jpg

 

extra_pic4.jpg

 

extra_pic5.jpg

 

extra_pic6.jpg

 

extra_pic7.jpg

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


Software

 

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.

 

Hardware

 

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.


Enclosure

 

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.


Completion Date


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.



Lucie

 

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!!

 

Lucie

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

3) Project overview http://www.element14.com/community/people/violet/blog/2015/04/15/hadron-vortex-g2-project-overview

4) Progress Update 1 http://www.element14.com/community/people/violet/blog/2015/04/16/hadron-vortex-g2--progress-update-1

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

9) The Amiga Emulator http://www.element14.com/community/community/designcenter/single-board-computers/gizmo2/blog/2015/04/27/hadron-vortex-g2--amiga-emulator

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

12) interim post - using gpio http://www.element14.com/community/community/designcenter/single-board-computers/gizmo2/blog/2015/04/30/hadron-vortex-g2--news-flash-gpio-breakout

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

14) Adding and led lightchaser http://www.element14.com/community/community/designcenter/single-board-computers/gizmo2/blog/2015/05/12/hadron-vortex-g2--light-chaser-mod

15) Case build #1 http://www.element14.com/community/community/designcenter/single-board-computers/gizmo2/blog/2015/05/15/hadron-vortex-g2--first-images-from-case-build

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

18) Disk activity monitor update http://www.element14.com/community/community/designcenter/single-board-computers/gizmo2/blog/2015/05/30/hadron-vortex-g2--disk-activity-monitor-update

mypic.jpg

 

and on the scope:

 

P1020804.JPG

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:-

 

cape_enable=capemgr.enable_partno=BB-UART4

 

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

 

ls /dev/ttyO*

 

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.

 

(You can use this method to transfer your own binaries if you wanted to use the Espruino board without the Javascript interpreter).

 

20150320_134933.resized.jpg

 

20150320_135022.resized.jpg

 

20150320_135039.resized.jpg