Messages

16

TinyDuino Processors & TinyShields / Re: Need help creating Library

« on: January 18, 2016, 07:47:55 PM »

...
I would guess that including the tinyscreen-header at the top of your ino file, AND including it at the top of the cpp file for your library would do the trick perfectly, since by doing so the same header file would not be included twice in the same cpp file. (Or you could add the include guards in the tinyscreen header file to avoid redefining the symbols in case the header file would be included twice)

Thanks for reminding me that the include issue should be a "once per compilation unit" problem. Finally, thanks to your prodding, I realized that in my library's .cpp file, I had my includes in the wrong order -- I first had the library's .h file, so naturally, the "TinyScreen" type was unknown at the time. Once I put TinyScreen.h first, those errors went away.

17

TinyDuino Processors & TinyShields / Re: Audio on the TinyArcade

« on: January 18, 2016, 09:05:12 AM »

You're welcome! Hope it is helpful.

18

TinyDuino Processors & TinyShields / Re: Need help creating Library

« on: January 18, 2016, 09:04:02 AM »

Hi! Yes, I understand the basic mechanics, but since my library is built "on top of" TinyScreen, it needs it included. I understand why I get the re-defines when including it, although the usual means of fixing that is to use "include guards" in your header, e.g.:

#ifndef MYUNIQUELIBRARYSYMBOL

// include the meat of the header here...

#define MYUINQUELIBRARYSYBOL

#endif

And I believe if TinyScreen were done that way, it would solve my problem (guess I should test that theory!).

Anyway, lacking that, I did remove the #include from my library, and put it in my project, ahead of the inclusion of my library, but it still failed then with the "doesn't name a type" error. I'm guessing it's something to do with how they compile libraries, but don't know for sure.

19

TinyDuino Processors & TinyShields / Need help creating Library

« on: January 17, 2016, 10:32:49 PM »

I've been working on a library that is intended for projects that use the TinyScreen. So in my library's .h file, I started by saying:

#include <Arduino.h>
#include <TinyScreen.h>

In my test project, I include my library's .h file as well as TinyScreen.h and when I do so, I get a bunch of errors saying that I'm redefining stuff. However, if I remove it and instead rely on its inclusion in the test project, I get errors indicating that TinyScreen does not name a type. And if I add the #include <TinyScreen.h> in the library's .cpp file, I still get the "does not name a type" error.

What am I doing wrong? What's the right way to approach this?

20

TinyDuino Processors & TinyShields / Re: Compiler Errors in TinyDuino SmartWatch Example

« on: January 17, 2016, 10:07:04 PM »

It could be a different Time library. TinyCircuits seem to like the "codebender" site, and when I ask to include <time.h> on their platform, it appears to include one that starts off like this:

/*
  time.c - low level time and date functions
  Copyright (c) Michael Margolis 2009

So I don't think they're using Paul's Time library...

21

TinyDuino Processors & TinyShields / Re: Audio on the TinyArcade

« on: January 17, 2016, 10:03:38 PM »

I'm afraid I can't answer your question directly, but maybe some information is better than none. It is true that you won't find general multi-threading on micro-controller platforms, except perhaps as computer science demonstrations, or for very specific projects. A lot of times, when writing for a micro-controller, you are near the limits of RAM or some other resource anyway, so the overhead of a general-purpose multi-threading library isn't welcome. Instead, one way a similar capability can be fabricated is to simply make a function per "thread" and ensure that each "thread" function is cooperatively multi-tasking, which is to say, when you call into the function, it should have a quick check on whether it's time to do some piece of work, and exit quickly if not. That way, you can get to the next "thread" quickly. But it all has to be cooperative. Make sure you never call any "delay" function. If you need to "wait" you can take the current timestamp, add the "wait" time to it, and set a static variable with the wakeup time. Then, in your function, you can check to see if it's time to do that important thing you needed to do.

Another thing to note is that often times, we add "shields" to our projects that have processors on them that are much more capable than the main micro-controller itself! I've worked with the Rogue Robotics audio shield (traditional Arduino), and it has quite a lot of capabilities. So in those cases, you are handing off a complex task to a "co-processor" but you generally retain authority over what happens there. Think of all the intelligence that has to go into the kinds of Ethernet and WiFi shields where the entire TCP/IP stack is baked into the hardware. Those are a lot more capable than the Atmel on most Arduini!!

22

TinyDuino Processors & TinyShields / Re: Is the ANY way I can connect non-tinyduino i/o to the tinyduino processor?

« on: January 12, 2016, 12:01:39 PM »

Remember that even if you can't hook up the buttons to the same pin as the TinyScreen buttons, given that what any button does is defined by your software, in general you ought to be able to make two electrically independent buttons perform the same action...

23

TinyDuino Processors & TinyShields / Re: TinyScreen -- Is it possible to measure strings?

« on: January 08, 2016, 02:51:00 PM »

I've forked the repo and have written a TinyScreen::getStringMeasurements method. Once I'm sure it's working, I'll create a pull request, unless you'd rather I didn't bother.

24

TinyDuino Processors & TinyShields / TinyScreen -- Is it possible to measure strings?

« on: January 08, 2016, 11:31:01 AM »

In order to display strings centered, it'd be helpful to know how much space a given string will take up, esp. if they aren't known at build time. I see that there are 12 varieties of liberationSans available: 8, 10, 12, 14, 16, 22 pt in both "normal" and narrow. It looks like, for instance for the 8pt, you have a table "liberationSans_8ptDescriptors" which has these widths and the FONT_INFO struct tells me what the starting character is. So if I could retrieve that info, I could probably do what I need, but there appears to be no "getFont" method, and the font parameters in the class are all private. Oh the other piece of info I need is how much space there is between characters? Is it one pixel?

I guess what I am inclined to do at this point is to define my own function, e.g. setFontX which will call the TinyScreen's setFont method, but which will also remember it in a global so I can later retrieve it for measuring strings.

Any better ideas? Any chance of getting a getFont or getFontDescriptor method?

25

TinyDuino Processors & TinyShields / Re: Questions about "dumb watch" project

« on: January 02, 2016, 06:29:50 PM »

OMG, Ben, I just placed another order for a TinyScreen. Is there any way to ensure I get one from this production run??

26

TinyDuino Processors & TinyShields / Questions about "dumb watch" project

« on: January 02, 2016, 08:48:37 AM »

I have begun work on a watch project, but it is not a connected watch. I'm just using the TinyScreen for the display. I'm planning to have a TinyDuino, the RTC board, and the display. I guess my questions revolve around battery life, as I'd like to have it powered by the coin cell, and last a long time. In my plan, the display remains powered off until the user presses a button to have the time displayed. Here are a few questions for starters:

• Will those three boards fit just fine in the watch case?
• Can a button on the screen trigger an interrupt so the CPU can sleep?

I'm guessing that if the answer to 2 is no, I'm pretty much sunk already. And if that's so, I'd suggest that it might be nice for a future rev of the board to have one of those buttons available that way, perhaps by cutting a trace and soldering a jumper. Anyway, if I can't use the coin cell, I guess I can use the lithium battery, but that means having to also include the USB board for charging, and makes maintenance a hassle, unless *4* boards plus battery fit in the 3D printed case.

Any other thoughts/advice?