Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - HunterHykes

Pages: 1 2
Hi Steve,

As can be seen in the TinyZero schematic and board files, the INT1 pin of the BMA250 accelerometer is only broken out to a solder pad on the bottom side of the board. This is the small copper circle labeled "INT1" next to the "BOOT" button.

Because of this, a wire would have to be soldered to this pad and then input to the processor via a Proto Board TinyShield. According to the official Arduino documentation for interrupts, any digital pin except for digital pin 4 is usable for interrupt input to the TinyZero processor.

If this is something you'd still like to pursue, I can look into getting some sample code for this.

Hope this helps.
- Hunter

Hi Michael,

The code for this kit has been updated and is available for download here and can be viewed here. We came across a software issue related to the buzzer that would cause the program to freeze. This issue has been resolved and will be documented on the Learn page soon.

If you're not familiar with how to upload code to the WirelingZero, there are instructions available on our Learn site here.

Hope this helps.


TinyDuino Processors & TinyShields / Re: TinyZero with NeoPixels
« on: June 25, 2019, 12:12:40 PM »
This is simply because the NeoPixels require 5V to operate and the Li-Po battery only supplies 3.7V. USB power would supply 5V, but if you want to power this project from a battery, look into a higher voltage battery or battery pack.

Hope this helps.

TinyDuino Processors & TinyShields / Re: TinyZero with LED
« on: June 10, 2019, 11:36:59 AM »
Almost every LED has about a 0.7V voltage drop across it. You should always use a current limiting resistor in series with any LED. There are specific resistances for each color LED as the current required for each is different. Typically a resistor from about 300 ohms to 1k ohm will do the trick.

Hope this helps.

General Discussion / Re: Tiny Screen
« on: January 07, 2019, 01:29:43 PM »
Hi jmontoya,

Due to the hardware setup of the TinyScreen and TinyScreen+, it is not possible to read data from the registers in the Graphic Display Data RAM via SPI. The only way to read a specific pixel's color would rely on the use of a buffer array and reference the specific index corresponding to the desired coordinate.

However, if you just chose the pixel on the center of the screen to detect the color of the entire screen, here's something you could do.

uint16_t color;

if(x < 120){
     color = TS_8b_Yellow;   
     color = TS_8b_Red;   

display.drawRect(0, 0, 96, 64, TSRectangleFilled, color);

if (color != TS_8b_Yellow)

I more or less made an assumption of what you were trying to do, but I hope this helps!


General Discussion / Re: BMP file on Tinyscreen
« on: September 21, 2018, 11:34:51 AM »
I don't have experience with switching bitmaps on a button push like you're trying to do. However, I believe the quick switching between images is something controlled within the TSV Converter. There should be a "Duration" option that controls this. Now I know this doesn't necessarily solve your problem, which brings me to this next question: are you only going to be working with still images on this project? If so, you may be able to create "sprites" to act as these images for easier switching upon a button push. There may also be another option with the code found within the "TSV Converter Tutorial," however, I haven't explored that much myself.

Let me know what you think!


General Discussion / Re: BMP file on Tinyscreen
« on: September 12, 2018, 04:56:54 PM »
You may want to check out our .tsv video converter tutorial ( The process detailed in the tutorial works for displaying videos and images from a micro SD card. In my experience, still images just have to be saved as .gif files in order for the program to work properly. This can easily be done with other file formats by opening them in an image editing program such as Paint and saving them as a .gif file. After that, simply follow the tutorial above and you should be able to figure it out!

I hope this helps.


General Discussion / Re: From landscape to portrait
« on: August 17, 2018, 07:06:15 PM »
Hey Martin,

I'm not completely sure of the application you're going for, but I hope I can provide some insight you may find useful. This may get mildly confusing, but I'll do my best to make everything as clear as possible.

As of now, there is no existing low-level code to "flip" the screen 90 degrees into a "portrait mode." This is because such a function isn't exactly necessary. Regardless of the orientation of the screen, any desired image or display (within the capabilities of the screen) can be shown on the screen. Basically, you either have to think through how to display the proper image by using the default coordinates, OR write a function that will convert coordinates in your desired "portrait mode" format to the default-style coordinates such that the lower-level code is able to work with it.

It's a little difficult to explain so I understand if you have more questions. Feel free to reach out.

Also, I'm not sure how much you plan on working with the TinyScreen, but I gained a significantly better understanding of how to use the TinyScreen+ by going through the "How to Develop a Game for the TinyArcade" tutorial found at (

I hope this helps.


Hi John,

I'll be honest--this question is a difficult one for me, but I'll attempt to answer it to the best of my ability. The number of sprites that can be rendered on the screen has many different variables to consider.

For reference, keep in mind that a bitmap is just a list of bits (or bytes technically) that represent certain colors in a specific order; whereas a sprite is an object that references the bitmap to have some sort of appearance onscreen with a set of coordinates, as well as a few other features.

First we have to consider a few things about the bitmap itself. Bit depth and resolution are the main contributors here in terms of size. 16-Bit bitmaps of a certain resolution will always be two times larger than an 8-Bit bitmap of the same resolution. Then we must consider the resolution of each individual bitmap as this will impact how many bits will be used by said bitmap. If you would like to figure out the size of a specific sprite you are working with, you can use Arduino's built in sizeof() function which returns the number of bytes that a specific instance of a data type or object is using.

Now we can look into actual sprites rather than bitmaps. There is a possibility of all sprite objects having unique bitmaps, therefore causing significantly more memory to be used as the number of sprites increases. There is also the possibility of having multiple sprite objects use the same bitmap (such as identical enemies onscreen). If the latter is the case, then each sprite doesn't use as much total memory as mentioned in the former. Technically, all sprite objects are the same size; however, by reusing bitmaps for these sprites, you will decrease the overall memory footprint.

I hope you can understand why this question is rather difficult for me to answer, as there are many possible variances that impact the answer to your question.

If you are curious as to how much program storage space is still available on your TinyArcade, you can go to File > Preferences within the Arduino IDE, and select the check-boxes under "Show verbose output during" and next to "compilation" and "upload" then click "OK" to save these changes. Now whenever you verify or upload your sketch, the IDE will tell you what percentage of memory space was used.

Although I wasn't able to fully answer your question, I hope that this in some way assisted you in understanding some of the limitations of the TinyArcade hardware. Overall, you shouldn't have to worry too much about it.


Tiny Arcade & Pocket Arcade / Re: Font use on screen
« on: August 14, 2018, 12:24:48 PM »
Hey John,

In order to assign a new bitmap to the sprite, you need to create the bitmap(s) for the ts_sprite objects to take on. Once you have the bitmap(s) created, the assignment would look something like this:

(Given that "ones" is an instance of a ts_sprite object and "digitOneBitmap" is the bitmap for the number one)
ones.bitmap = digitOneBitmap;

This way, you will be directly assigning the unsigned int pointer named "bitmap" within the instance of a ts_sprite object named "ones" to the desired bitmap.

I hope this helps!


Tiny Arcade & Pocket Arcade / Re: Font use on screen
« on: August 09, 2018, 02:30:59 PM »
If need be, an easy fix could be done by creating sprites for your text and loading in the numbers in that way. You would load in the score sprites just like any other sprite by adding it to the spriteList[] array. You would have a sprite for the ones place, tens place, hundreds place, and so on. Then, depending on the value of the score variable, you would make the sprite point to the proper bitmap.

I hope this helps.


Tiny Arcade & Pocket Arcade / Re: Font use on screen
« on: August 08, 2018, 12:56:51 PM »
Hi John,

When I looked into your issue myself, I came to the conclusion that the flickering is due to the drawBuffer() function and the display.print() function interfering with one another. If you would like to display the score in this manner, you will have to find a way to do so within the drawBuffer() function.

Personally, I am no expert on the font library. However, with some investigation into their hex values as arrays, you should be able to figure out how each character is represented and possibly work it into the drawBuffer() function. If this seems overwhelming, I can look into the issue myself to see if I can find a solution to your problem.


Hi John,

What you have here looks pretty good! There are a few minor things you could do to save on memory and minor execution time.

As far as saving memory goes, the game could function the same using just one sprite array. All instances in which the playBulletList[] array is used, you could just use the spriteList[] array. My recommendation if you do choose to make this change is to save a global variable for the index at which the bullet sprites begin along with another global variable for the number of bullets. This way you can still iterate through the bullets section of the array from startingBulletIndex through startingBulletIndex + numberOfBullets. This would save on memory as it would remove the array of pointers to the bitmaps already being referenced within the spriteList[] aray.

A very, very minor change you could also make is modifying the offscreen variable to the negative value of the bullet height (bullet1.y). This way the program will have to preform fewer calculations between when the bullet is fired and when it reached its offscreen position. This is a minor change, but if you plan on adding more to the game, this could make a difference.

I hope this helps. Things seem to be coming together well!


Hi John,

The reason you're getting strange colors is because the TinyScreen's default state displays colors in a BGR format rather than an RGB. This is mentioned in the TinyScreen library documentation found at Essentially what must be done is the hexadecimal representation must be converted to binary. Then, note that the first 5 bits are your Red bits, the next 6 are your Green bits, and the final 5 bits are your Blue bits. After taking note of this, you will rearrange the bits into a BGR format from the RGB.

For example:
1110 0110 1100 1010   (0xE6CA) RGB becomes
0101 0110 1101 1100   (0x56DC) BGR

You could do this in order to keep using the predefined colors, or you could also switch to the RGB color mode using display.setColorMode(TSColorModeRGB) where display is an instance of a TinyScreen object.

I hope this helps.


Hi John,

I'm excited to see the progress you make on the game you're developing! Here is a link to a freshly published tutorial on an RPG-style gameplay. This may not pertain specifically to your project, but it's possible that some of the concepts may come in handy so I figured I'd let you have a look.

Good luck!

Pages: 1 2
SMF spam blocked by CleanTalk