Storing images or image data on SD (gaming)

Status
Not open for further replies.
Ok thank you!!!

One more request...... can you link me to where you got the resistors? Im looking on evay and all i can find is 100m ohm resistors. And the capacitors too please!
 
I mean a 10 mega ohm resistor. That and the capacitor are just for measuring the battery voltage which is above 3.3v. You could use 10k ohm resistors but it will drain the battery faster. It's all described in this article: https://jeelabs.org/2013/05/16/measuring-the-battery-without-draining-it/

Two stores that I tend to buy things like resistors, capacitors, headers, etc. at are dipmicro and tayda.

Giving that shipping for Tayda was $4.75 (for US delivery) the last time I ordered, and a 10M resistor is $0.01 to $010, you may want to see what other components these stores stock that you might need to save on shipping (Tayda, may have a $10 minimum order).

In my last shipment from Tayda, I ordered it on Tuesday November 7th, it was put in the mail on Thursday November 9th, and I received it on Monday November 13th. Shipping was $4.75.

I haven't ordered from dipmicro in two years. I bought a giant bag of various resistors, and I still have most of them (I do use 2.2K resistors for Teensy i2c setup, and occasionally I will use 10 ohm, 330 ohm, etc. resistors). In Dipmicro, resistors are listed under 'passive components'.

Dipmicro is a Canadian company, in Niagara Falls, and they have somebody cross to the USA side of the falls 3 times a week to mail US stuff from a US post office. Because I live in New England (near Niagara Falls), stuff generally got to me in a few days.

I have a complicated setup in that my credit/debit cards are listed with my PO box as my official address (when I moved into the house, we didn't get mail delivery due to living on a private road and I had to use a PO box -- we get mail delivery now to a row of boxes by the side of the road, but I keep the PO box because the delivery people seem to leave neighbor's goods at random houses, and I don't trust package delivery to get the right house). IIRC, when I last ordered from dipmicro, I could only send it to the PO box and not use my work address.
 
Last edited:
I'm actually looking at the wiring diagram now. trying to figure out which w on the resistor and what v on the capacitor. the resistors shown in the schem has a gold bar on the end which is a 2m ohm 1/2w. the cap idk?
 
The wiring diagram may not have the correct resistor value displayed. It was a 10mega-ohm 1/4w resistor. You can substitute anything from 1 to 10 mega-ohm values. Lower values just draw more current from the battery. Getting a resistor variety pack is a good way to go. It will last you a long while.
 
Its says in docs for the joy that it uses 12c and that you need a pull up resistor. Did you use the teensys on board pullup or do i need a 10k resistor? Also do i need to bridge the gap on the address pads to use two feathers?
 
For i2c on Teensy there must be an external resistor 'once' somewhere on the shared lines - internal pullups are not sufficient. Check the values - it shouldn't be over 4700 Ohm IIRC - 2.2K is noted above p#27.

To use two similar devices that start with the same default address one must move to a unique address to share the i2c lines - sounds like that is what the solder jumper will do for one of them.
 
Ive actually got some blue 10k resistors, would those be sufficient? Or would that be over kill?
 
AFAIK that would result in a weak/slow pull-up voltage. If you have 4 of them putting 2 in parallel in both places would give a net 5000 Ohms that might be better. Very ugly and not easy perhaps depending on where you are soldering - but better than doing 3 to get 3333. You can try 10K but it will likely fail at higher speeds if it works at all.

Those resistor packs from SparkFun or other noted above are very handy.
 
I really liked the idea of the joy featherwing. It definitely reduces the wiring for buttons a great deal. The onboard ATSAMD09 seems to take care of the debouncing too. Bad news for me is that it adds a good amount of delay on receiving the input (for whatever reason). You have to make three separate i2c requests, one for the buttons and another two for each analog axis.

I ended up wiring each joy feather wing to their own i2c bus on the teensy using i2c_t3. That lets me make direct i2c requests on each bus in parallel. I used the code in the Adafruit_Seesaw lib for reference. The status of each controller can be read in under 6870 microseconds with the i2c buses set to run at 1MHz.

Here is a demo video: https://www.youtube.com/watch?v=RK0VyQ14qFc

With the teensy3.6 running at 240MHz writing to the SPI screen at 120MHz takes about 22400 microseconds. The game logic and drawing to the framebuffer only takes 1600 or so microseconds. So now I want a faster screen and input handling. Maybe run the tft in parallel mode and use raw buttons and analog joysticks. That would require a bunch of pins but the Teensy 3.6 can handle it :)
 
In terms of screen speed, are you using one of the screen drivers that uses the SPI DMA mechanism to speed up the transfers? You need to use the 5 special pins (9, 10, 15/A1, 20/A6, 21/A7) for the CS and DC pins in order to use the DMA support. I discovered in writing to 2 128x128 OLED screens, that the Teensy 3.5/3.6 can write faster than the screen can process, and I had to slow down the SPI bus so that the screen could handle the data. I also used TFT displays, and those displays could be run at any Teensy clock speed (I didn't try changing the SPI bus for those displays, since they worked).
 
Last edited:
Thanks for the heads up! I did originally try the DMA approach. Here are the pins I'm using:

Code:
#define TFT_DC 20
#define TFT_CS 9
#define TFT_MOSI 7
#define TFT_MISO 12
#define TFT_SCLK 14

DMA output had a lot of tearing when running in continuous mode. The main game loop on the teensy would cycle 6-8 times during the course of a single screen refresh. I also tried the one-shot update in DMA mode from ILI9341_t3n. This worked well and eliminated the tearing.

In the end I'm now using a 160x120 framebuffer (larger pixels / less ram usage) and scaling it up 2x while writing to the screen. Here are the changes for that: https://github.com/AnthonyDiGirolamo/ILI9341_t3n/commit/674eb0414360390b26fc4e8ab04a4717d0b8819b
 
You know the GameR library has a lot of neat stuff inside and it was created here with the expert help of the people just for gaming . I love the case!! Will you be releasing the .stl files? I also like the idea of the i2c’s less wiring but im lil worried about the reaction time. Both gamebuino and its diy counterpart makerbuino use i2c for its controls.

https://github.com/Duhjoker/GameR-Iot_T3

Im a lil confused on how to build the battery monitor/charging system. Is there any way you could make a diagram or something to show the right way? I know im asking for alot but that would be awesome!!!
 
No problem. Here is a fritzing diagram.

LipoCharger_3.3vRegulator_with_monitoring_bb.jpg

LipoCharger_3.3vRegulator_with_monitoring_schem.jpg

Since building this I've learned that you can't simultaneously charge the battery and use the teensy at the same time. Power to the voltage regulator has to be turned off while charging. I'll post another diagram with the charge sharing soon. Same method as described here: http://blog.zakkemble.co.uk/a-lithium-battery-charger-with-load-sharing/

You could also probably use this: https://www.adafruit.com/product/3200 It does pretty much the same thing but can charge while using the device. It also has similar voltage divider monitoring on pin A7.

This may also work: https://www.tindie.com/products/onehorse/stbc08-high-current-lipo-battery-charger/
 
Do the I2c lines take care of the tactile switches as well? Also do you gyts know of any humanized tutorials on I2C? Like setting up pins and stuff?!

Im having trouble understanding which vias besides the power pins need need header pins. Ive got sda and sdl populated. Do i need another set of pins
 
Last edited:
I'm looking at the pic below of the I2c wiring and why does the green wire use two pins? Also the left side hits the second pinright of the first while the green wire on the right hits the second pin 1 down? What is the white wire?

View attachment 12051
 
That diagram isn't great. I kept the wires at right angles because of the type of prototyping board I was using. The i2c connections only connect from each joypad to the teensy i2c pins. The connection order between the three doesn't matter but it's good to keep the wires short. The white wires are the interrupt pin connections and are optional. Read the pinout description here https://learn.adafruit.com/joy-featherwing?view=all#pinouts
 
Ohhh ok i see it now. Ive been reading about I2c hardware and am i to understand that when i use two different sets of i2c pins that one needs to be an output capable pin and an input capable pin? Do these pin sets need to be analog or digital IO’s? Im not seeing the pin declarations on the seesaw for the sda and sdl pins. I see the interrupt pin but not the sda sdl pins.
 
i2c pins are marked on the Teensy Card as SDA# and SCL#. One is DAta in and out - the other is the CLock pin. Each i2c set is unique and needs both pins - each set can have one or more uniquely addressed devices. As you learned - somewhere in the mix one device must offer physical pull up resistors on the lines. And GND must be common as well.
 
What all did you have to change in the seesaw library to account for the second set of pin? If you don't mind
 
duhjoker, you can share ~ 127 different addressed i2c devices (more if you use a multiplexer, but that deserves its own thread). i wouldnt worry about “reaction” times with human touch interfaced games, i was streaming fastled payloads of 500 bytes over the bus to a strip and it was running smooth. if you wanna go overkill you could hit up the spi bus, but for a human response you wont see much difference in your game

btw, the Wii nunchuck uses I2C

Tony
 
Status
Not open for further replies.
Back
Top