Homemade arduboy based on Itsybitsy (formerly Leonardo)

Hmm… Well that certainly makes some more sense, thanks! Sorry for another beginner question, i just was not even familiar with switch… case prior to this, but having looked into that as well the code is pretty cut-and dry. But also, just so I know i can follow what you are doing, what is this doing? Obviously you labelled it as player movement, but i just mean from a more literal aspect, is this simply designating each of these points of movement as another increment (and labeling it accordingly) to be called upon or is this calling upon something pre existing (function or object)? Thanks!

2 Likes

Right … the joysticks return an X and Y value on two different input pins. These values range between 0 and 1024 with the middle point somewhere but not exactly 512. Depending on how well the joystick is made and calibrated in may be way off 512. Of course those $2 joysticks you bought from China are super-accurate.

Anyhow, now that you have your two readings, what are you going to do with them? I have assumed that you want to move something (a player maybe?) around the screen at various different speeds depending on how far the stick has been pushed over. In my code, I have ‘carved’ the spectrum of 0 to 1023 into five bands - joystick pushed to the extreme left, somewhat to the left, not at all, somewhat to the right or to the extreme right.

In the function calls (movePlayer…() and so forth) you can do whatever you need to move your player, shoot your bullet or whatever!

1 Like

Well thanks! As far as getting it to work with pre existing arduboy code (as this is what I would like to do before I’m able to make games to ensure this is working properly first), could I simply rename the corresponding incremental movement to something that corresponds with a current button function (as written in that code)? Thanks!

1 Like

You would need to replace the Arduboy2 buttonsState() function, maybe something like:

uint8_t Arduboy2Core::buttonsState()
{
  uint8_t buttons = 0;

  static int value1;
  static int value2;

  value1 = analogRead(0);  
  delay(100);            
  value2 = analogRead(1); 

  // up, down, left, right
  if (value1 < 480) buttons |= UP_BUTTON;    // Up
  if (value1 > 540) buttons |= DOWN_BUTTON;  // Down
  if (value2 < 480) buttons |= LEFT_BUTTON;  // Left
  if (value2 > 540) buttons |= RIGHT_BUTTON; // Right

  // A
  if (bitRead(A_BUTTON_PORTIN, A_BUTTON_BIT) == 0) buttons |= A_BUTTON;
  // B
  if (bitRead(B_BUTTON_PORTIN, B_BUTTON_BIT) == 0) buttons |= B_BUTTON;

  return buttons;
}
3 Likes

Wonderful, thanks so much! I’ll have to test that when I get back home in a bit (if my brain isn’t too beat for today, it’s late here). If not, I’ll do that first thing tomorrow. Thanks again!

Where is here?  

Edit: The code:

uint8_t joyPin1 = 0;
uint8_t joyPin2 = 1;

really should be …

uint16_t joyPin1 = 0;
uint16_t joyPin2 = 1;

to support values between 0 and 1023.

1 Like

Those are just the pin numbers though? The values are already int

Don’t need them really anyway, I’ll edit them out…

1 Like

Oops … sorry. My mistake.

2 Likes

That’s +1 to the beers you owe me! :beer:

Total so far is 1. :slight_smile:

3 Likes

I don’t dare … you Irish can out drink most.

2 Likes

Have revised my suggested code (see below).

I had just copied the delay(100) between the two analogReads from the Joystick tutorial that was linked to above - but I later started wondering if the delay is really necessary?

Anyway, that is a rabbit-hole that I tried not to fall too deeply in to… but the general consensus is that the ADC needs time to ‘settle’ between reads, and even more so when switching between different analog inputs because they are all multiplexed to the one and only ADC and need time to switch over…

But a common ‘trick’ seems to be just taking two readings and discarding the first, instead of adding a delay, so that is what I have done here:

uint8_t Arduboy2Core::buttonsState()
{
  uint8_t buttons = 0;

  static int value1;
  static int value2;

  analogRead(0);
  value1 = analogRead(0);
  analogRead(1);
  value2 = analogRead(1); 

  // up, down, left, right
  if (value1 < 480) buttons |= UP_BUTTON;    // Up
  if (value1 > 540) buttons |= DOWN_BUTTON;  // Down
  if (value2 < 480) buttons |= LEFT_BUTTON;  // Left
  if (value2 > 540) buttons |= RIGHT_BUTTON; // Right

  // A
  if (bitRead(A_BUTTON_PORTIN, A_BUTTON_BIT) == 0) buttons |= A_BUTTON;
  // B
  if (bitRead(B_BUTTON_PORTIN, B_BUTTON_BIT) == 0) buttons |= B_BUTTON;

  return buttons;
}
3 Likes

Small disclaimer:
This isn’t standard C++, it’s a compiler extension.
This syntax probably work on other compilers,
and it won’t work on gcc with compiler extensions turned off.

@CatDadJynx
If you’re only using the ArduinoIDE for your code then you can use that, but that’s not how switch statements normally work.

It would be more portable to do:

if(value <= 240)
     moveplayerFastToLeft();
else if(value <= 480)
     movePlayerSlowlyToLeft();
else if(value <= 540)
     ; // An empty statement
else if(value <= 760)
    movePlayerSlowlyToRight();
else if(value <= 1024)
    movePlayerFastToRight();

Note that the order is important.
You could include both ends of the ranges to be safe,
the compiler will optimise them out.
I left them out because I’m lazy.

The static isn’t necessary, and might increase the code size (because static gives it static storage duration, which means a global variable, which means it has to be written back into RAM instead of just living in a register pair for its lifetime).

This should work fine:

analogRead(0);
int value1 = analogRead(0);

analogRead(1);
int value2 = analogRead(1); 

Or optionally:

analogRead(0);
const int value1 = analogRead(0);

analogRead(1);
const int value2 = analogRead(1); 
2 Likes

Thanks so much, guys! Yeah, I gathered as much about the switch statement having different syntax outside the Arduino IDE (I looked it up as throughly as I could after the fact), so thanks for the additional info! I’ll be sinking my teeth into it this afternoon and will update. Thanks again for all the help!

2 Likes

Sorry for the delay, but just a quick update- been looking at the games to figure which I should use, and saw that a some rely on the arduboy library and some on the arduboy 2, additionally, some use other utilities as well. For some reason, I’m having a hard time with my a and b buttons as well (which in my initial setup worked fine), so I’ll have to figure out what went wrong somewhere along the lines the second time around.

But once I get this squared away I’ll post the code I’m working with and what game, to see the directional button mapping I’ll be working with. I can certainly see memory limitations being a factor as well, so in the meantime I’ll do some additional homework for the best structure (and pondering what everyones said so far). And I’ll get started on sketching out a potential framework of the joystick mapping I’m trying to integrate. Thanks again everyone, for the especially helpful help!

Alright, unfortunately im just getting even more confused here… When I first prototyped my DIY arduboy, I just used the default brick break example… Now, I’m seeing some with extra utilities or things missing, and alternately I’ve found arduboy manager software that can upload raw hex files directly to the arduboy. My screen is working (as it shows up) but my joystick registers two axes (which I believe are being confused for other inputs) and my buttons don’t work at all. Since I don’t have access to the code, Im a bit at a loss as to what I would modify to fix the directional button mapping, or even why my buttons aren’t working

Alright, so I’ve gotten the buttons working, and gotten hex files (and regular arduino.ino files) to.upload through the manager. Is the button mapping in the header or CPP files for the library? I’m just not sure where I’d even go about looking to make these changes.

Also, just a footnote, two of the axes of my joystick actually work already (but only half of each axis, right and up but not down or left), not sure why this is.

Edit: nevermind, now i.see that the reason why they work on those two axes is because in the arduboy core files, up and right buttons are mapped to the same analogue pins. Nonetheless I’m not sure how to insert my code in place of this. Likely I would insert all the setup in the first joystick test i did, then replace these button commands with those aforementioned?

Double edit: alright, obviously the reason the two axes are working is because of the core file button definitions, but as for the rest I’m just confusing myself at this point

(and sorry for the spam)

That’s how it should be.
One horizontal and one vertical.

Both Arduboy and Arduboy2 are open source and have their source available.

The headers.


What you’re experiencing is the ‘rubber duck’ effect.
Buy yourself a duck.

1 Like

What I meant was it was only responding to half of each axis, as in x and y but only in one direction of the stickz as in x+ and y+ but not x- and y-. But this is because it’s just treating it like a digital input rather than analog. As for the arduboy and arduboy 2 libraries, they just needed updated.

And I didn’t know there was a name for it, but thanks for having the patience to humor me :stuck_out_tongue: I just get a little overzealous, sorry

And I’ll go back and take a look at the header files, but is it for each individual game or for the arduboy library itself? Sorry for sommany questions, just not sure where along the chain I should start looking. Thanks!

Rather than asking me that, ask yourself this:
“Why would pins be defined per-game if all games are targetting the same device?”


Out of interest, have you tried writing an Arduboy game yet?

I think if you wrote a simple Arduboy game first and then came back to trying to make your DIY unit, you’d have a better idea of which library functions do what and thus a better idea of what you’d need to modify.

At the very least, perhaps you ought to sit down and write a list of all the things you don’t know/need to know so you’re a bit more organised and know how far away you are from your goal.