DIY Gamer Conversion

[espruino-discuss3]

Posted at 2014-03-04 by mattbrailsford

Thought I'd start this thread off, as I have a few project specific questions I wouldn't mind some assistance with, but first off a bit of background.

I came across this cool kit http://shop.technologywillsaveus.org/collections/frontpage/products/diy-gamer-kit-with-arduino and thought, as it's just a bunch of buttons and an LED matrix, this could be uber cool to convert to use an Espruino.

My first steps are going to be making the Espruino share the same footprint as the Arduino, and for that I'm already working on an adapter (see http://forum.espruino.com/conversations/711/).

Once I have this, it should then be a case of mapping the Arduino pins, to the Espruino and re-writing the library.

After speaking to the producers of the kit, they said the only thing that might cause an issue is that the LED matrix is rated at 5v, so I'd need to use a Logic Level Converter to converts the Espruinos 3.3v to 5v.

So a couple of questions.

1. I'm going to need a 5v supply for the converter, so would it be best to a) run the input power supply through a 5v regulator first, and then to the Espruino and just sprout off from there, b) same as the above but attach the 5v regulator to vbat of the Espruino and feed the power supply straight into the Espruino first or c) use a step-up regulator to step up the 3.3v to 5v?
2. Given the attached diagram of pin usage, and the fact it's the LED display that is rated to 5v, which pins will need to converted to 5v?

Thanks for your help in advance.

Matt

Attachments:

• Capture.PNG

[gfwilliams]

Posted at 2014-03-04 by @gfwilliams

I'm not sure if they're referring to the TLC5916 or the MIC5891 (or even just the LEDs) as being the 5V parts?

The TLC5916 datasheet seems to suggest that it'll happily run off of 3.3V and will work off of 3.3v logic levels. The only problem is when you run it at 5v and it wants 0.7x5v = 3.5v logic inputs.

For the MIC5891, it's hard to tell (I can't find the info for logic levels) but I imagine it would be fine. The only gotcha is that it seems it wants to run on at least 5v.

It's all so close it'll almost certainly 'just work' on 5v - you could just connect it up and see what happens, it's not like anything will get blown up.

The other option is to take the pins that need 5v conversion (I guess Display , MIC and TLC*) and to just pull them up to 5v with a (5kOhm?) resistor. As long as you choose 5v capable pins on Espruino, you can switch them to 'Open Drain' mode, which will mean that when outputting a 1, the resistor will be able to pull the voltage right up to 5v and it'll all be within spec.

If you did want to fit a regulator, I'd put the 5v output to VBat of Espruino so the most voltage you have on the board is 5v. It's not like it really matters though.

[espruino-discuss3]

Posted at 2014-03-19 by mattbrailsford

Whoop! Kit is finally in stock and on order (though subject to a weeks dispatch, sigh!). I've got my basic proto-boards here, but my purpose designed shield adapter is still waiting to be made. Once it's done, it seems to take about a week to get here so depending on when things arrive, I should hopefully get this rolling in a week or two.

Matt

[espruino-discuss3]

Posted at 2014-03-28 by mattbrailsford

Well the gamer has arrived so just waiting for my adapter boards to show up :)

Attachments:

• Photo 26-03-2014 18 20 13.jpg

[espruino-discuss3]

Posted at 2014-04-01 by mattbrailsford

Ok, so today is the day my Arduino adaptors came so I've been testing some of the basic components. So far I can control the LED, I can sound the Buzzer (currently just setting it to high, but will figure out PWMing it later). I've also tested all the buttons which seem to work too (apart from I forgot pin C3 on my arduino shield so had to solder a wire across).

A couple of questions then. If I want to watch all the buttons, do I setup watches on all the pins? or is there a way to watch multiple pins and determine which one was triggered? Also, should I be setting the pinMode myself? or will watching the pins just be enough? if I do set the pinMode, what input mode would I need (I still never quote get when to pullup or pulldown)?

The last "simple" component to test is the light sensor. If I understand this forum post correctly, does this mean I'm not able to watch the pin for changes? rather would need to setInterval and check the value periodically? Probably not a big deal if I do, as power preservation won't be key.

Cheers guys

Matt

[espruino-discuss3]

Posted at 2014-04-01 by mattbrailsford

Thought I'd give the Matrix a try by porting over code from the gamer library here, which has been converted to:

var OE = B6;
var CLK1 = C6;
var CLK2 = C7;
var DAT = C8;
var LAT = C9;

var HIGH = 1;
var LOW = 0;

pinMode(OE,   'output');
pinMode(CLK1, 'output');
pinMode(CLK2, 'output');
pinMode(DAT,  'output');
pinMode(LAT,  'output');

var counter = 0;
var currentRow = 0;
var image = new Uint8Array(8);

var display = [
  [1,1,1,1,1,1,1,1], 
  [1,1,1,1,1,1,1,1], 
  [1,1,0,0,0,0,0,0], 
  [1,1,1,1,1,1,1,1], 
  [1,1,1,1,1,1,1,1], 
  [1,1,0,0,0,0,0,0], 
  [1,1,1,1,1,1,1,1], 
  [1,1,1,1,1,1,1,1] 
];


function updateDisplay()
{
  var newImg = new Uint8Array(8);
  for(var j=0; j<8; j++) {
    newImg[j] = 0x00;
    for(var i=0; i<8; i++) {
      newImg[j] <<= 1;
      newImg[j] |= display[j][i];
    }
  }
  if(newImg != image) {
    for(var i=0; i<8; i++){
      image[i] = newImg[i];
    }
  }
}

function updateRow()
{
	if(counter==8) {
		counter = 0;
		currentRow = 0x80;
	}
	writeToRegister(0);
	writeToDriver(image[counter]);
	writeToRegister(currentRow);
	currentRow >>= 1;
	counter++;
}

function writeToDriver(dataOut)
{
    //console.log("Driver data:" + dataOut);
	digitalWrite(OE, HIGH);

	for(var x=0; x<=7; x++) {
      digitalWrite(CLK1, LOW);
      digitalWrite(DAT, (dataOut & (1<<x)) >> x);
      digitalWrite(CLK1, HIGH);
    }

	digitalWrite(LAT, HIGH);
	digitalWrite(LAT, LOW);
	digitalWrite(OE, LOW);
}

function writeToRegister(dataOut)
{
    //console.log("Register data:" + dataOut);
	digitalWrite(LAT, LOW);

	for(var y=0; y<=7; y++) {
      digitalWrite(DAT, (dataOut & (1<<y)) >> y);
      digitalWrite(CLK2, HIGH);
      digitalWrite(CLK2, LOW);
	}
	digitalWrite(LAT, HIGH);
	digitalWrite(LAT, LOW);
}

updateDisplay();

setInterval(function(){
  updateRow();
}, 1);

And it actually works, to a degree :) Right now, because it's using a bitshifter to update the LED rows one at a time, it seems the Espruino isn't firing quick enough to make it look seemless.

http://t.co/B9q0BoKey2

Is there anything that can be done to speed this up? or can anyone suggest any alternative way of updating the display in one burst?

Many thanks

Matt

[gfwilliams]

Posted at 2014-04-02 by @gfwilliams

is there a way to watch multiple pins and determine which one was triggered?

You'd just have to use setWatch multiple times...

should I be setting the pinMode myself or will watching the pins just be enough?

Nope, not unless you need to use the internal pullups (which I doubt?)

The last "simple" component to test is the light sensor. Does this mean I'm not able to watch the pin for changes? rather would need to setInterval and check the value periodically?

Yes, it's just software I'm afraid...

Is there anything that can be done to speed this up?

Yes... You can use SPI (if it's connected) otherwise the new Espruinos (from http://www.espruino.com/binaries/git) have software SPI. Simply doing:

var S1 = new SPI();
S1.setup({mosi:DAT, sck:CLK1});
var S2 = new SPI();
S2.setup({mosi:DAT, sck:CLK2});
...
function writeToDriver(dataOut) {
  digitalWrite(OE, HIGH);
  S1.send(dataOut);
  digitalWrite(LAT, HIGH);
  digitalWrite(LAT, LOW);
  digitalWrite(OE, LOW);
}
function writeToRegister(dataOut) {
  S2.send(dataOut, LAT);
  digitalWrite(LAT, LOW);
}

would help matters. You'd probably also find that 'inlining' the other functions into updateRow would speed things up a bit too.

[espruino-discuss3]

Posted at 2014-04-02 by mattbrailsford

Thanks Gordon

When you say use SPI if it's connected, do you mean if the device supports it? Or do you mean specific pins? (Sorry if dumb questions) If they are, is it the same process as the code sample above? Or is that just for software based SPI? To use the new Espruino bins I take it I just need to re flash the board? Is it as simple as setting the URL to the binary I want to use in the options window?

Cheers

Matt

[gfwilliams]

Posted at 2014-04-02 by @gfwilliams

Yes, sorry - I mean if SPI is on those specific pins (see the reference). Using hardware SPI is as simple as using the built-in SPI1/etc rather than saying new SPI. To get started, just use software though - there's really not much of a downside to it.

To use the new Espruino, yes - just copy the URL into the flasher and flash it as normal :)

[espruino-discuss3]

Posted at 2014-04-02 by DrAzzy

Yeah - reflash the board - disconnect, put espruino into bootloader mode (hold btn1 while resetting), connect again, put the URL into the flasher in the IDE, and tell it to flash. Then disconnect, reset espruino to leave bootloader mode, and you're ready to connect and play with the new software.
(to be clear - when I say "disconnect" and "connect", I'm talking about the connect/disconnect button in the IDE, not physically disconnecting it).

The last "simple" component to test is the light sensor. Does this mean I'm not able to watch the pin for changes? rather would need to setInterval and check the value periodically?

If/when I get around to it, I'll test out using an LM339 to convert analog value to digital pulse if it's above/below a certain value (either fixed with resistors, or from one of the DAC pins), and if I can make it work, i'll write it up.

[espruino-discuss3]

Posted at 2014-04-02 by mattbrailsford

So I've re-flashed as suggested (thanks for step by step guys) which all went well, and have updated the code to as follows:

var OE = B6;
var CLK1 = C6;
var CLK2 = C7;
var DAT = C8;
var LAT = C9;

var HIGH = 1;
var LOW = 0;

pinMode(OE,   'output');
pinMode(CLK1, 'output');
pinMode(CLK2, 'output');
pinMode(DAT,  'output');
pinMode(LAT,  'output');

var counter = 0;
var currentRow = 0;
var image = new Uint8Array(8);

var display = [
  [1,1,1,1,1,1,1,1], 
  [1,1,1,1,1,1,1,1], 
  [1,1,0,0,0,0,0,0], 
  [1,1,1,1,1,1,1,1], 
  [1,1,1,1,1,1,1,1], 
  [1,1,0,0,0,0,0,0], 
  [1,1,1,1,1,1,1,1], 
  [1,1,1,1,1,1,1,1] 
];

var S1 = new SPI();
S1.setup({mosi:DAT, sck:CLK1, mode:3});

var S2 = new SPI();
S2.setup({mosi:DAT, sck:CLK2, mode:0});


function updateDisplay()
{
  var newImg = new Uint8Array(8);
  for(var j=0; j<8; j++) {
    newImg[j] = 0x00;
    for(var i=0; i<8; i++) {
      newImg[j] <<= 1;
      newImg[j] |= display[j][i];
    }
  }
  if(newImg != image) {
    for(var i=0; i<8; i++){
      image[i] = newImg[i];
    }
  }
}

function updateRow()
{
	if(counter==8) {
		counter = 0;
		currentRow = 0x80;
	}
	writeToRegister(0);
	writeToDriver(image[counter]);
	writeToRegister(currentRow);
	currentRow >>= 1;
	counter++;
}

function writeToDriver(dataOut)
{
	digitalWrite(OE, HIGH);
	S1.send(dataOut);
	digitalWrite(LAT, HIGH);
	digitalWrite(LAT, LOW);
	digitalWrite(OE, LOW);
}

function writeToRegister(dataOut)
{
    S2.send(dataOut, LAT);
	digitalWrite(LAT, LOW);
}

updateDisplay();

setInterval(function(){
  updateRow();
}, 1000);

(Just put a 1s interval for now to test) but I get an error in the terminal window:

INTERNAL ERROR: Timeout on SPI TX
INTERNAL ERROR: Timeout on SPI TX
INTERNAL ERROR: Timeout on SPI RX
at line 2 col 25
    S2.send(dataOut, LAT);
                         ^
in function "writeToRegister" called from line 6 col 22
in function "updateRow" called from line 2 col 13
in function called from system
ERROR: Error processing interval - removing it.
Execution Interrupted during event processing.

@drazzy I'd love to see your write up if you get that working.

[gfwilliams]

Posted at 2014-04-03 by @gfwilliams

whoa. Sorry - regression :) Fixed now though.

Try the latest git commit from here in an hour or so when it's finished building.

[espruino-discuss3]

Posted at 2014-04-03 by mattbrailsford

Hey @gfwilliams

That works :)

Matt

[espruino-discuss3]

Posted at 2014-04-03 by mattbrailsford

So, this is much faster and I actually get a solid image being drawn now, but will need to try a few more speed tweaks as it's just not quite fast enough (like a monitor in too low a refresh rate, you see slight flickering in the corner of your eye).

Other than inlining the methods in update row, is there anything else you can suggest? (currently got setInterval at 0.05)

PS The image rendering out now seems to be backwards (compared to what I had before) is this something to do with config? or should I just compensate in my code?

Matt

[gfwilliams]

Posted at 2014-04-03 by @gfwilliams

It'll be because SPI outputs most significant bit first. It'd be easy enough to change updateDisplay to flip that around.

I'd also consider replacing currentRow with 1<<counter (or 128>>counter if it's backwards). You can then remove the currentRow variable.

I don't think you'll get much extra by decreasing setInterval past 1 - in fact if you're telling it to go faster than it wants to, it might adversely impact rendering of other stuff.

The hardware's a bit of a strange setup to be honest. It feels like a MAX7219 would have been way better (and would have only required a single chip to be soldered).

[espruino-discuss3]

Posted at 2014-04-03 by mattbrailsford

Cool, thanks @gfwilliams. I've inlined the two methods, and got rid of updateRow and moved all the logic within the setInterval function itself and it's a lot better. I think it could do with being a tiny bit faster (it does look solid now, but it's kinda like the old days of low res monitors, we you move your eyes, it looks a bit stuttery) but I'd say it's workable now at least.

I wondered the same about the MAX7129, but I'm guessing it was more about the looks than the functionality. It's fun to have a limitation though and try to work round it :)

Matt

Attachments:

• Photo 03-04-2014 13 08 00.jpg

[espruino-discuss3]

Posted at 2014-04-03 by mattbrailsford

cheers @gordon, that works a treat.

Just playing with some simple logic (capturing button presses) at the moment, and currently hitting what I feared, that the additional logic affects the display loop and so causes stuttering / flickering as it has stuff to compute.

Not sure what can be done here though as ultimately I guess it's coming down to computations and without uber optimizing everything, the fact we have to refresh the screen the way we do means this is always going to be the case isn't it?

Matt

[espruino-discuss3]

Posted at 2014-04-04 by DrAzzy

I'd love to see your write up if you get that working.

I tried it out and it's dead simple - Connect up LM339 to +3.3 and gnd, and pick one of the 4 comparators in it... Output goes to the pin you'll setWatch() on, one input goes to a reference voltage (you can make these with analogWrite() to the DAC pins), and the other input is the analog voltage you're reacting to. When the In+ is at a higher voltage than In-, the output goes high. For reasons not immediately clear to me, in my testing, I had to use the debounce option on setWatch(), otherwise the watch would be triggered repeatedly while the output was high. I'm sure there are improvements that can be made to this, but this should give you enough to get started with (since I'm not sure when I'll have a chance to write up the doc nicely - I'd like to include in the doc a "change detector" setup, for use with those 20 cent chinese vibration "sensors").

[gfwilliams]

Posted at 2014-04-04 by @gfwilliams

You can usually add 2 resistors to the LM339 (one between the DAC and it, and one from its output back to the pin the resistor from the DAC was connected to), and that'll give it some hysteresis and make it less likely to turn on and off.

Hmm... if only there was a markdown for circuits :(

@mattbrailsford If you do what I suggest with the fully unrolled loop (and call it maybe every 10ms) then it'll make the display a lot less glitchy (although a bit more dim).

[espruino-discuss3]

Posted at 2014-04-04 by mattbrailsford

@gfwilliams when you say unravel updateRow do you just mean call it 8 times all at once? Or is there a way to send a whole screen full of data? If so, do you have an example of how?

@drazzy that sounds cool. Think I might have to give that a go :)

Cheers

Matt

[gfwilliams]

Posted at 2014-04-04 by @gfwilliams

Yes, just add a loop inside it that repeats 8 times. You might need something at the end to turn off the last row of leds though.

[espruino-discuss3]

Posted at 2014-04-04 by mattbrailsford

Hey @gfwilliams, I thought that's what you meant, unfortunately it still struggles a bit :( It keeps a constant steady colour, but they you just get the odd moment where it just struggles and you get flickering (like an old tv in and out of reception).

I've got some other LED matrix screens on order so I'll see how they perform and maybe have a go at creating my own board. If you do have any other suggestions though, I'd be glad to hear them (you've been really helpful already).

Matt

[espruino-discuss3]

Posted at 2014-04-04 by Frida

Are you aware that the LM339 is open colektor, so it needs a pullup resistor.

[espruino-discuss3]

Posted at 2014-04-04 by DrAzzy

Hm, I wasn't, that's probably (part of) my problem. I'll try setting pinMode(pin,'input-pullup') and see if that improves things.

[gfwilliams]

Posted at 2014-04-07 by @gfwilliams

There's one more option, which is pretty hardcore:

• Create some in-line assembler to bit-bash out the display output
• Set up PWM on a pin with a frequency of 1kHz (to enable the timer)
• Use poke32 to set the interrupt vector table to point to your inline assembler
• Enable interrupts for that timer.

As I say, pretty hardcore, and probably not recommended :)

[espruino-discuss3]

Posted at 2014-04-12 by mattbrailsford

Hey Guys, so if you've seen any of my other posts on the forums, you'll know that I've now switched out the display for an Adafruit 8x8 BiColor matrix. The benefits are two fold. 1) it has more colours and 2) it has an in-built oscillator so there is no need to keep updating it row by row, instead I can just send it a picture to draw, and it'll keep drawing it till you tell it otherwise. This should hopefully take a lot of pressure off the Espruino.

So, I'm now playing with wiring up the buttons. I did some initial tests a while ago and could detect the buttons, however on playing with it today, there does seem to be some issues. Looking at the wiring, all the buttons are wired:

3.3v ADC PIN > BTN > Grnd

Now, when I setWatch on the buttons like so:

  setWatch(function(){ console.log("UP"); }, UP, { repeat:true, edge:'falling', debounce:10 });
  setWatch(function(){ console.log("LEFT"); }, LEFT, { repeat:true, edge:'falling', debounce:10 });
  setWatch(function(){ console.log("RIGHT"); }, RIGHT, { repeat:true, edge:'falling', debounce:10 });
  setWatch(function(){ console.log("DOWN"); }, DOWN, { repeat:true, edge:'falling', debounce:10 });
  setWatch(function(){ console.log("START"); }, START, { repeat:true, edge:'falling', debounce:10 });

I do get the words printing to the terminal, but I also get them printed quite a few times after letting go of the buttons (my initial thoughts were just to do with debounce, but as you can see, that is set). And more weird, the start button (which is a differen type of button to the up/down/left/right ones) will trace just by touching the metal casing on the button.

Would I be right in assuming then this sounds like a case of needing a pullup/pulldown resistor? if so, which kind would I need in this situation? and any suggestions on where best to wire them? (I wanna try and keep the gamer as stock looking as possible). If this isn't the issue, has anyone got any suggestions on what it might be?

Many thanks

Matt

[espruino-discuss3]

Posted at 2014-04-12 by mattbrailsford

Ok, figured it out :) So I just needed to pysically set the pin mode to input, and as the buttons are wired to ground, have the pin pull up by default, so adding the following, before registering the setWatches worked.

  pinMode(UP, 'input_pullup');
  pinMode(LEFT, 'input_pullup');
  pinMode(RIGHT, 'input_pullup');
  pinMode(DOWN, 'input_pullup');
  pinMode(START, 'input_pullup');

I can now capture buttons :) whoop!

[espruino-discuss3]

Posted at 2014-04-13 by mattbrailsford

Check it out, first game done. Frogger :)

http://youtu.be/ulyIF_csVTo

[gfwilliams]

Posted at 2014-04-14 by @gfwilliams

That looks fantastic - thanks :)

[espruino-discuss3]

Posted at 2014-04-14 by mattbrailsford

@gfwilliams the gamer board comes with a piezo buzzer on it. What would be the best tact on playing music whilst playing the game?

[gfwilliams]

Posted at 2014-04-14 by @gfwilliams

I'd suggest something like this: http://www.espruino.com/Making+Music as long as the buzzer is a speaker rather than a buzzer? It may be that all it does is beeps at one frequency?

I think individual beeps for music are the best way forwards - you can use Waveform to play sounds when something happens, but trying to use it for Music alongside something else may cause pain :)