https://www.broadcastingcable.com/news/viacom-launches-campaign-backing-seeher-initiative-171480

I was watching the commercial and noticed that was TinyCircuits microcontroller. I'm not sure how it saved the mainframe, but that's what imagination is for

Hi Mike- missed this. We've had the SRAM/FRAM/FLASH boards built up since the EEPROM board was released, but have not had time to release those- we're hoping to do so early in the year after we increase our staff a bit. The 1Mbit FRAM will definitely be more expensive than the EEPROM unfortunately! The part cost is roughly 3x at low volume. I think the SRAM(1Mbit) and FLASH(8Mbit) can be the same relatively low cost as the EEPROM.

I'd be interested in an SRAM board. 2K is so tiny! A virtual memory layer such as https://github.com/rhelmus/virtmem would make working with it trivial, albeit a bit slower.

make rectangular case that fits between or individual tinydurino shields for a more finished look and keep dirt out.  Could be designed to replace screws by snapping together.  Might consider a bottom and top caps.  caps could be the mechanical interface for other devices like camera hotshoe or GPS antenna domes

A little late, but this sounds like an interesting project. I have access to laser-cutters, and I don't see any modular cases for tinyduino. The easiest would be to cut U-shape stackable sheets, so that one side is open for USB, switches, etc. Only problem is the exact height of each module. I'm not sure I can find acrylic to match exactly so they stack perfectly.

Only EEPROM is available on the memory tinyshield. When will FRAM become an option?  FRAM supports many, many more writes and is faster than EEPROM.  It is more expensive, of course.

I see links to games to put on the SD card, but how do you make games for the Tiny Arcade?  There's a link to setting up the TinyScreen+, but that would just wipe out the game loader.

For those of us who need more IO, and especially more hardware UARTS, how about a processor board based on the ATmega1280?

I would love more memory for sure!  I'm raising this thread from the dead

What would be your preferred way to make screenshots of the content of the tinyscreen?

Is that question directed to end users of the library, or the library developers (TinyCircuits)?  What would be nice is an API to specify a window and a pointer to memory to grab.  Something like:

readScreen(&array, x, y, width, height, bitDepth)

But maybe another thing to bring up is what you'd use it for.

https://www.hackster.io/tbatey_tiny-circuits/tinyscreen-assembly

"Ooops
Something that shouldn't have happened did happen. We got notified though and are probably already working on fixing it!"

The Wire library has unnecessary overhead, but we want to cause as few software conflicts as possible

Thanks for the response.  It does make sense to limit the number of pins used, and like you said I can make the I2C buffer very small.  It's always nice to understand the choices made, to have a little deeper knowledge.

Hi Chad and Mike, we now have the library maintained at https://github.com/TinyCircuits/TinyCircuits-TinyScreen_Lib

Thanks Ben!

My real reason for posting was that I was just wondering if there was an official place to always get the latest version of TineScreen.cpp and h as a library.

Ahh, I got mine by clicking "Download" from the embedded TinyScreen_Demo app.  It seems to be the official one, which is listed on the second page on codebender.  It's unfortunate there isn't a better naming system - it can get confusing if all the projects have the same name!

I've been playing around with it a bit more.. created a custom mono-spaced 3x5 font (uppercase-only).. not sure what I want to do yet   What about you?

Mike

You should be able to create a TinyScreen folder in Documents/Arduino/libraries and put TinyScreen.h and .cpp in in it.  Sure, it would be nice if it came that way, and with lots of other demos.  I assume some day they'll do that.

I haven't played with lines much yet, just a bunch of squares   Can you give a snippet of code and I can try it also.  It looks like it uses the same conversion from single byte to r:b:b as drawRect - is the color wrong even in the r g b version of the function?

So far I find the API is simple.. but could use some drawing circles and polygons.  Antialiased lines would be super cool, too.  I've implemented them before, but they're very slow if done in the client drawing each pixel (SPI byte per byte).

I'd also be interested in a less expensive, smaller package that fits the TinyDuino's size.  The smaller the better!

Just curious why both?  SPI is fast and used for data, while it looks like Wire is used for commands?  Wire has multiple 32 byte buffers that are not even used and take precious memory, while SPI hardly uses any.

Any reason for using both protocols?  I can change the buffer sizes if need be, at least

Mike

We are working on a SRAM TinyShield which will hopefully be out in early to mid January.

This would be awesome!  2K is so tight when you use WiFi, I2C and other libraries combined!  With C++, it would be possible to create wrappers/proxies to interface seamlessly with it.