The way I fix it was to do the following:

Don't have a battery attached
Plug into USB
Turn power off on the TinyScreen+
Hold down button nearest USB
Turn power on for the TinyScreen+

If I held down the button and just unplugged / plugged it in, it remained unresponsive for me too. The above steps worked (I rebricked it on purpose 3x and redid those steps to make sure I had them correct).

Credit to Beermat & Ben for pointing me in the right direction.

I'm unable to get the wifi board to be recognized by a TinyScreen+. I can use the same wifi board on a tinyDuino with the CC3000 code and get it to operate client or server, but no joy when using wifi101 on a tinyScreen+. Here is the FW Check that I tried amongst other things, if someoen can see a problem, do let me know. Thanks.
==================
#include <SPI.h>
#include <WiFi101.h>

#define USB_SERIAL

#if defined(USB_SERIAL)
  #define SerialOut SerialUSB
#else
  #define SerialOut Serial
#endif

void setup() {
  WiFi.setPins(8,2,A3,-1);
  SerialOut.begin(115200);
  delay(1000);

  SerialOut.println("WiFi101 FW check.");
  SerialOut.print("WiFi101 shield: ");

// **** the board is not found, we get "NOT PRESENT" ****
 
  if (WiFi.status() == WL_NO_SHIELD) {
    SerialOut.println("NOT PRESENT");
    return; // don't continue
  }
  SerialOut.println("DETECTED");

  String fv = WiFi.firmwareVersion();
  SerialOut.print("FW version installed: ");
  SerialOut.println(fv);

  // Print required firmware version
  SerialOut.print("FW version required : ");
  SerialOut.println(WIFI_FIRMWARE_REQUIRED);

  // Check if the required version is installed
  SerialOut.println();
  if (fv == WIFI_FIRMWARE_REQUIRED) {
    SerialOut.println("Result: PASSED");
  } else {
    SerialOut.println("Result: NOT PASSED");
    SerialOut.println(" FW version too low.");
  }
}

void loop() {
  // do nothing
}

I am hoping there is a factory reset or method to halt an upload when the board is powered (so I can clear / replace what I uploaded).

What I uploaded has some code in the loop which causes the board to get stuck (ie: an infinite loop). Thus the TinyScreen+ does not show up as a USB recognizable device, and I can not upload anything to it.

Anyone know how to clear this situation?

Thanks

I have SDFat working fine (thanks for pointing me in that direction). The built in SD support is not seeing files or creating them, but that is now a low priority.

For the wifi board, I am using the built in Example code for ScanNetworks. It is popping up a "WiFi shield not present" within setup(). If there is a different library that works, and you can point me that way, much appreciated.

I tested the wifi card and it works with the tinyDuino, but not the the TinyScreen+ as well.

It is likely there is a solution in a setting, define or otherwise. Can someone look into this?

My intent is to combine a tinyScreen+, SDCard board and wifi board.

The lib works with the old board (I verified). But still locks up with the tinyScreen+ over here on my end. I can't use the old board for this project.

Anyone?

Is this the demo from the File->Examples menu?

If so, I just compiled / deployed it.

A couple of things to double check, since the IDE can reset your settings to an old one. I am copying down some things I have set on my IDE for uploading the demo. Hopefully it will help you. Kind of tough to get help here on this forum.

Off the menu

Tools->Board:TinyScreen+
Tools->Programmer->AVRISP mkII
Tools->Build Option: Default

I hope that helps (it may be thinking the older board perhaps).

I am working on something where I need to have a microSD board.

I have a tinyScreen+ and an SD board only so far. If I do any calls the the SD library, everything locks up and everything is dead. I can recompile, reload etc... I can read buttons and everything, but again, once I try to create a file or read a directory the whole thing locks up.

I've verified this with serial comms to do println debugging and it is 100% reproducible.

This is the lib I am using:

https://www.arduino.cc/en/Reference/SD

If anyone has any suggestions on how to get this beyond a lockup and can share, very much appreciated.

It was more of a "can it be done" type of project, with less of an eye on usefulness.

If a diabetic checks their blood sugar 30 times a day with a CGM, then digging out your phone, pressing power, getting past the lock screen, opening the app each time is 8+ seconds of annoying. The premise is to get the information with less steps.

Also, at home a person is not always carrying their cell phone around. A lot of the human factors for such things I wrap around less steps, less work for the user.

This is more a shout out to Tiny Circuits than anything for making such an awesome platform.

As I was looking for a tiny full featured platform I jumped on the Tiny Circuits platform for prototyping! I love these things. Part of me wants to shout this out as the folks running Tiny Circuits don't have time to do this kind of thing, they are running a business, and I commend them for it (I've run shops and it is not easy).

My first creation with tiny circuits is the worlds smallest Diabetic Glucose monitor (CGM).

The basics of this are that the body worn sensors data is sent to a server (that is the CGM vendors stuff). From there, I pull it down to an android device, and send the data via BLE to a TinyScreen+ with a BLE board and battery.

The Articles can be found here:

Part 1:
https://www.linkedin.com/pulse/building-worlds-smallest-diabetic-cgm-receiver-part-1-andy-pal?trk=hp-feed-article-title-publish

Part 2:
https://www.linkedin.com/pulse/building-worlds-smallest-diabetic-cgm-receiver-part-2-andy-pal?trk=hp-feed-article-title-publish

There will be a #3 in the series as the enclosure issue has finally been solved. And more coming yet using these excellent devices ( I have a full series of tiny medical devices in mind!).

Cheers and happy new year all!

Andy

Are there any comms for the TinyLily boards? BLE perhaps?

I am thinking of medical jewelry for sensing and/or display.

My wife has been looking at "dog tracking" for our 2 dogs, however everything out there requires a monthly subscription. We do not want huge range and a cell tower connection.

A simple solution using Tiny Circuits would be to use a CPU board, GPS module and the low frequency board as it can do up to 1/2 mile (depending on obstacles, humidity etc..). The device would only send (less power usage). It would sleep for a period of time, read the gps and fire out the Lat/Long string.

On the other side, another CPU board with radio board in listen mode could send the received data via a BLE board to an Android phone which would parse the string and plunk the location onto a map.

Only risk is battery life on the "dog" unit, so a low duty cycle and send only would be necessary, and no UI to push.

I've been testing run times with the rechargeable battery. I am running the tinyScreen+ with the BLE board and the screen set to a brightness of 10. I was able to get 18 hrs on a battery before doing any power management/optimization.

You would not be running any comms (wifi, bt etc..) so your mileage should be better than that.

If you keep the main loop fairly empty, and redraw as little as possible (don't redraw on each loop, either check time, or even be super cheesy and do a count down, redraw) you should be able to stretch the battery out.

Unfortunately the base of the switch is plastic with those 2 little plugs going into the board. That plastic melts and makes a mess (like glue gun poop) so I wound up having to completely remove the switches down to the solder pads. That gave me more room to use as I put 30 gauge leads on them. Since the switches are surface mount they don't really tear up the solder pads or traces fortunately when removed.

Next time you are getting panels, could you have 2 boards on a panel not have the switches populated for me? That would save me the desoldering.

From an android phone, when I scan the Tinyscreen+ publishes a name of "URT". I've grepped the example project and am unable to locate that string. Is it possible to change the name for a  BLE scan?

Thanks,
Andy