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

Pages: 1 2
General Discussion / Serial line noise
« on: May 31, 2018, 04:55:49 PM »
On the TinyScreen+, I have it connected to the terminal block breakout. I am using lines 0 and 1 for Serial communication. However, I am experiencing a lot of noise on this. The lines are extremely short and I haven't had this kind of issues in the past with other Arduino hardware.

I do not have any other boards connected. Are there some issues on these pins that I should be aware of?

General Discussion / Can't read battery voltage
« on: May 31, 2018, 04:54:14 PM »
I have a TinyScreen+

I am reading the ADC line A4 (thats what appears to be wired up in the schematic), but I am getting a bunch of random values.

Is there any particular trick to obtaining the voltage?

User Projects / Code Examples / Re: TinyDuino Game Kit Case
« on: May 20, 2015, 10:53:19 PM »
Great progress!

I am trying to use BLE shield (Rev2) but I don't get to work it.
I have tried this examples: but my phone (iPhone 5c) doesn't find BLE.
Do anyone know what I am doing wrong?
Thank you.

I used the exact examples on the TinyDuino BLE page and although I do get a boot message:

###   system_boot: { major: FF, minor: FF08, patch: DEFE, build: 3DA, ll_version: 3E6, protocol_version: 1, hw: 11 }

It does absolutely nothing and is not discoverable.

Has anyone played with BG Script on the BLE112?

The BGLib example is compiling in at 13kB, not to mention with some significant complexity.

The idea is simple: offload as much functionality as possible onto the BLE112 and run it in stand alone mode. Create a very simple UART control interface for transmitting and receiving data.

Before I start, has anyone already done this?

I did something very similar with the Telit GSM module (Python variant), and I was able to quickly hammer out new sketches without having to bother with all of the overhead.


7.5.3 says that if you are using 8 bit color mode, the 16 bit color is generated into RAM.

In 8.1, it indicates you can read via parallel, but not in serial mode.

I really wonder how true this 'read' condition is. I guess it's worth a shot.

User Projects / Code Examples / Re: TinyDuino Game Kit Case
« on: May 12, 2015, 09:24:57 PM »
I've uploaded the files to my blog: I have ordered the version with the changes (not sure if they turn out to work) to see if they work. I should have it at the end of next week. It's really annoying without access to a printer.

Do you have any maker spaces in your area? We have a couple of them here in Seattle and that is who i typically send 3D print jobs to. I can't say the price is much cheaper, but at least the results are fast.

Do you have a link to the datasheet?

As I wrote earlier - right now I am solely trusting my scanline renderer with which I can do quite many sprite renderings with reasonable frame rates. It's is quite optimized so I am fine for most games I was thinking of.

Feel free to do what you want. From what I saw earlier, it is working out great for you.

My goal is to post as many details as I can about the hardware to assist others. There are probably a bunch of people asking themselves the same question.

Hm. Hardware copy sounds neat but without double buffering, the uses are a bit limited. I am most annoyed by the flickering - therefore I just use the scanline rendering for everything. It's fast enough to scroll all sprites/texts that I draw in any direction anyway.

It would be much more useful if the screen had

- Selectable 8bit palettes (currently it's 2-3-3)
- Double buffering
- Uploadable sprites that can be used as textures (32kb or so would suffice)

Essentially the Double buffering would make the difficult-to-use scanline renderer obsolete - which uses also quite a bit of precious ram. And it would make the hardware commands more attractive again - right now I chose not to use them.

Is there an overview what hardware commands are supported?

The good news is that hardware copy does not result in any flickering or tearing. I am using it for several smooth scrolling scenes in my game intro. I have been conveyer belting in the pixels (you do this simply using a static scanline and copying the screen over itself) and it looks great. Since the full resolution bitmap is almost 1/5 of the total available flash memory on the 328, I have been scaling up all of my full screen images by 4x.

The hardware copy is also very fast. If you do not have delays, you may not even see it.

There is a datasheet for the chip. It has a few other modes which are useful for hardware acceleration of graphics.

There are also several different color modes, including a 16 bit mode. The framebuffer on board is actually 96 x 64 x 16 bit.

One major compliant I have with this display driver is there is no way to read back the frame buffer. This makes it very difficult to efficiently draw graphics on the screen, implement sprites, and use windows. I mitigate this by using SetX() and SetY() and calculating what should be replaced.


User Projects / Code Examples / Re: TinyDuino Game Kit Case
« on: May 12, 2015, 04:44:26 PM »
You mean having the STL files? I am working with Cinema 4d, which isn't a CAD software but an editor for rendering purposes, hence it's a bit clunky from time to time.

I have made changes by now and ordered a new version. It's annoying me that I still have no 3d printer myself since it costs 30€ each time I order it. Of course the delivered quality exceeds private 3d printers in detail by far... therefore I am also unsure how useful the design would be for you.

Yes, any format would actually work, as they can be converted. STL does help but I can work with others.

I have access to high end 3D printing locally, so it would be quite helpful rather than starting from scratch. I also think the rest of the community would appreciate the contribution.

I would actually recommend you make a submission to

General Discussion / GPS or WiFi product availability?
« on: May 11, 2015, 05:09:30 PM »
Any idea when GPS or WiFi modules will be back in stock?

User Projects / Code Examples / Re: TinyDuino Game Kit Case
« on: May 11, 2015, 12:41:05 AM »
Hey there, if you are interested in having a case for the TinyDuino Game Kit - I am working on something, here's the video:

Would you mind sharing the 3D print files for this? I would love to have a similar case, even if it needed some work.

Looks cool. What do you mean with hardware copy?

I also have implemented a scanline renderer - it's opensource and is available here:

There is a screen command to take a screen X,Y and size and copy it to another position. You can use this as a way to implement a hardware scroll. You can also "conveyer belt" scanlines into a copy command and implement a very low overhead sideways scroller.

General Discussion / Re: Tinyduino aircraft gauges?
« on: May 08, 2015, 03:40:07 PM »
Thanks, I think a few of the existing sensors could be used and others could be added to one of the standard TinyShield proto boards.  I am not convinced that the TinyScreen would be a good fit, as it's awfully small and I am not sure it would remain readable in direct sunlight. I am pretty sure that the LED matrix and a 7-segment or alphanumeric LED module behind a clear or translucent anti-glare cover would still be readable in direct sunlight.

I think a sensor input and display output is the best way to learn Arduino. It's practical, you will see the results quickly, and you will learn to tweak your code to get the output you need.

Accelerometer output, outside of tilt/etc, is very hard to process if you are looking to create some sort of INS, get a feet per minute output, etc. Still, I have experimented with accelerometers on planes before, so a false horizon is possible and an uncalibrated feet per minute gauge should be very possible.

There are libraries out there though that have been used in UAV projects would really be a big help in your case. 

Nice work! I have been doing something similar.

I ended up forking the TinyScreen library to add support for tile maps, sprites, and a very useful drawBitmap(image,x,y). There are also some powerful screen functions that I added support to, especially the hardware copy.  I also have support for cropping tiles, which makes way for scrolling.. my goal is to add native side scrolling support.

My current implementation supports alpha sprites, but they draw after the tile map. This does introduce some flicker, so I am going to work them into my scanline routine.

One thing I noticed right away is that PROGMEM is where everything must be stored, otherwise, you can quickly run out of RAM. This introduces a little bit more latency, but it is tolerable.

Here is a game I have been working on. Tile graphics need work, and the sprite call is a bit sloppy (I call it several times in a loop, rather than once, making it flicker like crazy), but it's playable. I have about 20 screens now today.

I am using a homegrown pixel and map editor I wrote in HTML5. It needs work, but its usable. It generates C code for the graphics.

8x8 tile editor:

map editor:

Pages: 1 2
SMF spam blocked by CleanTalk