Hi Rena,
   Please "refresh" this topic/post - I updated it 20 mins before you replied
readStringUntil('\n') works just fine.
Thanks for the reply!
Jim

UPDATE! Now I *am* embarassed!  I myself had posted a solution / workaround to this problem 3 Years ago! LOL!!   See the post, "Serial.read baud-rate issues..." in this forum.  In a nutshell, as Ben Rose pointed out, the processor just can't accurately do high baud rates (at least on Input).
So, the workaround is: USE 9600 Baud!   I just tested it, and it's working!
-------------
Hi y'all!  This question is embarassingly simple, but I'm stumped!  I'm talking to TinyDuino via USB Serial connection 115200 baud.  I send single-character "commands" from a Windows program to the tiny, pull them off the wire in the main loop() with:
  if (Serial.available() > 0)
      processIncomingByte(Serial.read());
and all is well.  Works great, no issues.   I've decided to expand my "protocol" a bit, to consist of multi-character "strings", e.g. - "DELAY 500", etc.  So I have tried this:
String str; // module declaration
in loop():
   if (Serial.available() > 0)
   {
     str = Serial.readStringUntil('\n');
     Serial.print("str = "); Serial.println(str);
     // also tried:  Serial.print("str = "); Serial.println(str.c_str());
   }
An example of the result (from the input, "M1234") is:
str = L⸮⸮
   I've also tried using char buffer[32], and appending single chars to that buffer, with a check for the '\n'.  Similar result.
What the heck am I missing here?  This ought to be falling-off-a-rock simple!
This doesn't work even with the Arduino serial monitor either; tho single-char inputs are fine, and all println outputs from the tiny.
  Any thoughts?

I plan on running an IR LED off of the VCC pin (~5V), with appropriate limiting R.  But I also want to run VCC to a few LED driver transistors, to be switched on/off using IO pins.  Total current for all would be ~100mA.  Am I right in thinking that, when this combo is powered directly from USB, that the VCC *is* the raw USB 5v?  Even if so, there could be current limits imposed by trace widths etc.   I've looked around quite a bit but haven't seen anything definitive about this.  Thanks for any help!

Ben,
  Thanks for the confirmation!  (I hadn't been back to this in quite a while, either!
I appreciate the follow-up!
Jim
Happy New Year!!!

Well, perhaps I wasn't clear when I said "knocking my port speed down to 9600...": I should have said "I changed both the port speed AND the baud-rate specified in the code" from 115200 to 9600.  There was No mismatch at any time.
As for conflicts, there are none.  Also, I'm not using a hub or intermediate USB connection; I suspect a hardware issue of some sort, but don't have time to worry about it at this point.  Still, would be nice to understand what's going on.

I've been using a TinyDuino setup successfully for quite a while now, with the Arduino Console set to 115200 baud.
I have had NO problems with OUTput spewing lots of data, with no garbled characters.  I recently decided to add code to accept a user (Console Serial) input ("serial number") to be written to EEPROM.  After wasting far too much time trying to figure out why i was reading back GARBAGE from the EEPROM after (supposedly) writing it, I backtracked to the simple loop using Serial.read(), where I built the user-supplied S/N string.   It was GARBAGE.  After lots of Google finger exercises, I found that some people apparently had (output-related) problems with higher baud-rates; but not much discussion of INput scenarios.  But I decided to try knocking my port speed down to 9600 just for giggles. VOILA!  It works with no problems. HA.
I'm writing this a) to inform others who might go down this path, and b) to pose the question: "is this a possible Hardware issue, or a Arduino/Library Software issue?"

I've had a lot of problems with "Pipe Errors (0x91)" despite the fact that I am testing
the "credits" available before sending data.
My code basically uses:
aci_state_t* _aci_state;
_aci_state = BLESetup();
...
// in the "send" operation:
   if (clientConnected && lib_aci_is_pipe_available(_aci_state, PIPE_UART_OVER_BTLE_UART_TX_TX) &&
      (_aci_state->data_credit_available >= 1))
    {
      if (!lib_aci_send_data(PIPE_UART_OVER_BTLE_UART_TX_TX, (uint8_t*)msg, sendLength))
      {
        SerialMonitorInterface.println(F("TX dropped!"));
        ...
      }
    }
-- is there some other approach I should be using for data transmission?
+++ MODIFIED! +++
(Dunno why it always happens, but as soon as I ask a question, I often get to
answer it myself!!!!)
-- I found that I'm "poking the bear" at too low a level: calling lib_aci_send_data
requires that "I" maintain the "credits" counter!  Didn't realize that; replacing with
a call to "uart_tx" seems to reliably solve the problem!   Sometimes hard to see
what level of an API you're supposed to be dealing with!
---------------- but the remainder of my question still stands: does the ST version
of the module offer better [reliability/ease-of-use/performance/features/etc]?
.............
I've been using the Nordic BLE module for a while now, with "some" success.
I just noticed that you folks are replacing that with an "ST"-based module, that's
supposed to be "drop in compatible" but also allows Arduino sketch to muck with
connection parameters.
   Do I assume correctly that this uses different library code?  Would the ST module
give me a better shot at getting past these silly (what appear to be) data-overrun
issues?
  Thanks for any help you can offer!

Has anyone successfully interfaced a PIXY camera board with a TinyDuino OR TinyScreen?
If so, what libraries are compatible, and is there any example code available?
I don't need video frame rate processing; relatively long-interval still image is fine; the
PIXY seems like it ought to be reasonably straightforward, as it has I2C interface (and others).
Thanks for any insights!
Jim

You could use the proto board with the headers mounted on it... it has feed-through connectors.

Thanks for the pointer... lib_aci_sleep() does exactly what I was looking for.  Since I post a "shutdown" message to my client prior to sleeping, I don't need to use wakeup()... I just go thru my normal startup/connect sequence for reconnect.
Appreciate the help!
Jim

I've been searching for example of how to implement sleep/wake operation for the Tiny's Nordic BLE module.
If an API function(s) exists at the same level as "BLEsetup()", I can't find it.  (for that matter, I'm not sure where
the BLEsetup() signature is defined).   In my application, I've gotten my processor sleep/wake operations working
as desired, but the BLE connection remains active when the cpu sleeps -- I need to disconnect it, and have the client
code reconnect after cpu wakes up.
   Any ideas are appreciated!

I was intending to use pins 2 AND 3 for interrupt signals that are active LOW.
simplified code:
const int srcOne = 2; // first interrupt source
const int srcTwo = 3; // 2nd interrupt source
void setup() {
  pinMode(srcOne, INPUT_PULLUP);
  pinMode(srcTwo, INPUT_PULLUP);
}
void loop() {
  int s1State = digitalRead(srcOne);
  int s2State = digitalRead(srcTwo);
  SerialMonitorInterface.print("s1:"); SerialMonitorInterface.println(s1State);
  SerialMonitorInterface.print("s2:"); SerialMonitorInterface.println(s2State);
}
....
The result is:
s1:0
s2:1
...   any idea why pin2 behaves differently than expected?  (and Yes, pulling Pin3 LOW is
recognized... s2:0)   I can't conveniently put an external pullup on my Pin2 (due to wiring
constraints) but didn't think I'd need to.  thanks for any inputs! (Pun Intended!

===>>> UPDATE:
I *think* I may have identified the source of the behavior I'm seeing.  One of the items
that I've stacked is the Nordic BLE module, which I found uses pin 2 for interrupts.  So,
perhaps the order of my "pinMode(2, INPUT_PULLUP)" then call to BLEsetup() has the pin
function being "superseded"?  I guess I'll have to try eliminating the BLE from the stack and
see if the behavior changes.  I'll post my findings.

I am contemplating adding SD support to a "Tiny" project that is now using
Nordic BLE, 9-axis IMU and USB.  I've not yet completed the logic code
that I need, and I see that I've got about 5KB of program space remaining!
Does anyone know how much of that would be eaten up by the SD support?
I may have to re-architect, but hope to avoid that!
Thanks!

I've been using the "TinyShield_NRF8001_BLE_Example" project as a starting point for a new project.
I've added "assert" code with serial port output to verify that LED_BUILTIN is in fact pin13 in my build.
I've also put pinMode(LED_BUILTIN, OUTPUT) in my Setup method.   If I replace my "loop" method with
the simple "blink led" using digitalWrite and delays, it works fine UNLESS I make a call to BLEsetup() in
my Setup() method!   I have looked at UART.h (which is where BLEsetup is apparently defined) and I don't
see any "pin" definitions or anything that would seem to conflict with pin 13 being used for the processor
board's LED.
A side note: looking at what appears to be the Tiny's processor board schematic on that page's link, "SCK"
is marked as the driver of the LED; "SCK" on the chip is pin 17.   Since I *know* that pin 13 works correctly
(per the "assert(LED_BUILTIN == 13)" not failing in my code), I can only conclude the schematic may be wrong.
   Anyone have thoughts on this one?
Thanks very much!
Jim