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.

Topics - Bullwinkle

Pages: 1
TinyDuino / baud-rate issues...
« on: August 27, 2018, 04:23:56 PM »
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, 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?"

TinyDuino / Nordic BLE Transmission issues
« on: September 16, 2017, 05:04:26 PM »
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
  Thanks for any help you can offer!

TinyDuino / PIXY + TinyDuino
« on: May 11, 2017, 02:19:25 PM »
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!

TinyDuino / Nordic BLE Sleep Mode
« on: January 27, 2017, 07:03:02 PM »
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!

TinyDuino / INPUT_PULLUP works for Pin3 but not Pin2
« on: January 25, 2017, 03:40:17 PM »
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:
...   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.

TinyDuino / Tiny SD Shield - standard library overhead
« on: December 26, 2016, 06:04:16 PM »
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!

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!

Pages: 1
SMF spam blocked by CleanTalk