Messages

16

General Discussion / Re: Desoldering switches

« on: December 22, 2016, 07:12:14 PM »

Thanks Ben,

Good point on the traces lifting! I can just leave the plungers there as they will not be accessible. I'm going to take pics along the way with a write up and send it over to you when done in case it is of any use.

17

General Discussion / Desoldering switches

« on: December 22, 2016, 01:59:40 AM »

A quick question before I do this.

Any heads up before I desolder the switches on the TinyScreen+? I need to remove them, solder on leads that go to momentary switches that will be on the enclosure I will be making. I am unable to add a breakout board and tap off of that as I am keeping the profile as low as possible.

Thanks in advance if anyone has a "watch out for this..."

18

TinyDuino Processors & TinyShields / Re: TinyScreen+ and NFR8001

« on: December 21, 2016, 12:37:17 AM »

Hi Ben,

 I checked your new example and enabled the screen within it. Within the main loop I had it draw some simple animation while scanning / connecting with an Android 4.4.2 motorola phone, followed by some sends / recv's.

Everything works perfectly fine, and I'll be porting / rebuilding this project over the next couple of days.

Thanks for the speedy example update and reply!

Andy

19

TinyDuino Processors & TinyShields / TinyScreen+ and NFR8001

« on: December 20, 2016, 04:03:36 AM »

I've been trying (rather unsuccessfully) to get BLE working with the tinyScreen+. I've tried the tutorial (BLE), however under boards it does not list the TinyScreen+. I've downloaded the tutorial (NFR_Nordic_BLE*) and it won't even compile as it it thinking AVR.

Do these devices work together? If so, is there an ETA on sample /example? I've been hacking some stuff up, and can't even get things to compile right (see other post regarding compile errors) but being new to the platform etc... makes it an unpleasant slog.

I have a functional CGM receiver (falls under class 2 FDA, secondary display) put together since last week, but the form factor is far too thick to be usable due to multiple boards and was hoping to use the TinyScreen+ as it put the physical size into a good shape for the enclosure. My intent was a prototype by Jan 9th.

20

TinyDuino Processors & TinyShields / Re: Error during compile Question (Tinyscreen+)

« on: December 20, 2016, 12:59:11 AM »

Resolved....

For anyone else that hits this, you need to add includes to the files that pop with the type errors (obvious ones like uints) during compile.

Add this include to them:

#include <stdint.h>


Now.......It is not finding the define for NULL, anyone know where that one lives so I can do those includes?

21

TinyDuino Processors & TinyShields / Error during compile Question (Tinyscreen+)

« on: December 20, 2016, 12:48:26 AM »

Hopefully someone has seen this and knows the fix on it.

I am bolting a TinyScreen+ and the BLE board together. I am reusing what I did a few days ago. That used the watch HW set. I am trying to reduce thickness, thus the TinyScreen+.

The tinyScreen+ works fine on it's own.

The other board set works fine with what I put together based on the watch code example (lots of cannibalization).

I've added #define __SAM3X8E__ to the top of hal_aci_tl.cpp so the compile doesn't start trying to bring in the avr HW includes.

When I try to take my new code base and compile it for the tinyScreen+ & BLE board I get the following errors, if anyone has seen this and knows the fix and can pass it along, it would be very much appreciated.


==========================

Arduino: 1.6.12 (Windows 8.1), Board: "TinyScreen+, Default"

In file included from sketch\hal_aci_tl.h:46:0,

                 from sketch\aci_queue.cpp:26:

aci.h:265: error: 'uint16_t' does not name a type

   uint16_t min_conn_interval;   /**< Minimum connection interval requested from peer */

   ^

aci.h:269: error: 'uint16_t' does not name a type

   uint16_t max_conn_interval;   /**< Maximum connection interval requested from peer */

   ^

aci.h:273: error: 'uint16_t' does not name a type

   uint16_t slave_latency;       /**< Connection interval latency requested from peer */

   ^

(**** bunch of stuff removed to get below the 20,000 char max limit for posts****)

aci_queue.cpp:188: error: 'struct aci_queue_t' has no member named 'head'

   memcpy((uint8_t *)p_data, (uint8_t *)&(aci_q->aci_data[aci_q->head % ACI_QUEUE_SIZE]), sizeof(hal_aci_data_t));

                                                                 ^

aci_queue.cpp:188: error: 'memcpy' was not declared in this scope

   memcpy((uint8_t *)p_data, (uint8_t *)&(aci_q->aci_data[aci_q->head % ACI_QUEUE_SIZE]), sizeof(hal_aci_data_t));

                                                                                                                ^

exit status 1
'uint16_t' does not name a type

This report would have more information with
"Show verbose output during compilation"
option enabled in File -> Preferences.
 

22

General Discussion / New User

« on: December 14, 2016, 12:16:52 AM »

Hi there,

New to the platform and new to the forum. I received my initial kit 2 days ago (very well done design).

My goal / intention is on medical applications. I make class 1 through class 3 medical devices in several fields. I have a few items I am looking at prototyping.

I am roughly 30 to 40% of the way through to the first rough prototype.  I am using the setup to operate as a very small display for a continuous glucose monitor (CGM). The CGM is a class 3 PMA device which counts the ions shed off of a glucose / glucose oxidase reaction. These "counts" are aggregated for a period of time, then correlated to a blood sugar value. The device is a body worn sensor which reports wirelessly. A secondary display like I am putting together is class 2. I should have this proto complete and fully operational soon. It will be regular open boards at first. Once my next order arrives (I just put it in), I will use the reduced stack height to build the entire system into a keychain fob.

The goal is to give a diabetic a keychain fob that reports their blood sugar and trend every 5 minutes.  I may add a small pancake motor to draw attention for alerts. Then I will move onto the next device in the queue.

I can see these little systems being great for many practical purposes.

Suggestion:

Ribbon Cable Extenders: Can a person get them in short lengths? I am thinking in the range of 1 to 2 inches. I would need this for a later medical prototype.