http://forums.leaflabs.com/topic.php?id=1277 A place to share, learn, and grow... en-US Fri, 22 Jan 2016 00:14:06 +0000 http://bbpress.org/?v=1.0.2 q http://forums.leaflabs.com/search.php http://forums.leaflabs.com/topic.php?id=1277&page=2#post-11496 Mon, 02 Jul 2012 14:11:19 +0000 mbolivar 11496@http://forums.leaflabs.com/ <p>Great, glad it's working for you! </p> http://forums.leaflabs.com/topic.php?id=1277&page=2#post-11495 Mon, 02 Jul 2012 13:47:23 +0000 feurig 11495@http://forums.leaflabs.com/ <p>Ok,</p> <p>This works in the latest libmaple (with the fixes that mbolivar: and bubulindo: discussed above). </p> <p>Thanks for fixing this!!</p> <p>Its so nice to be able to manipulate time in an an ansi kind of way!!!!</p> <p>Don. </p> http://forums.leaflabs.com/topic.php?id=1277&page=2#post-11170 Fri, 08 Jun 2012 14:57:29 +0000 feurig 11170@http://forums.leaflabs.com/ <p>bubulindo, </p> <p>It is in the newlib headers but it it is not in anything that installs in the ide or the version of libmaple that I have (whatever was stable a few months ago). </p> <p>Hence the question. </p> <p>I suppose I could see if the development branch fattens up wirish_time with more of the useful parts of the ansi time handling but I am working with production code and trying to avoid dev branches. </p> <p>FWIW the arduino and wiring pack around the full avr-libc which is complete in these areas. </p> http://forums.leaflabs.com/topic.php?id=1277&page=2#post-11151 Fri, 08 Jun 2012 00:03:42 +0000 mbolivar 11151@http://forums.leaflabs.com/ <p>gbulmer:</p> <blockquote><p> IMHO it should be _WIRISH_TIME_H_ in wirish_time.h to follow the convention; map non-identifier characters to '_', and add '_' start and end.</p> </blockquote> <p>The development branch does indeed follow this convention (actually, now we follow the <a href="http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#The__define_Guard">Google C++ #define guard guideline's</a> lead, which roughly says that some/path/header.h becomes <code>_SOME_PATH_HEADER_H_</code>, to allow for multiple files with the same name throughout the tree). </p> http://forums.leaflabs.com/topic.php?id=1277&page=2#post-11150 Thu, 07 Jun 2012 23:52:27 +0000 bubulindo 11150@http://forums.leaflabs.com/ <p>isn't it in time.h? :S </p> http://forums.leaflabs.com/topic.php?id=1277&page=2#post-11137 Thu, 07 Jun 2012 14:51:04 +0000 feurig 11137@http://forums.leaflabs.com/ <p>Ok so I am looking for gmtime and am not finding it in any of the maple libraries or the mapleRTC library. Does that mean that the rtc library has to be compiled against newlib? </p> http://forums.leaflabs.com/topic.php?id=1277#post-7740 Tue, 17 Jan 2012 17:11:10 +0000 poslathian 7740@http://forums.leaflabs.com/ <p>thanks! we will check in to it! </p> http://forums.leaflabs.com/topic.php?id=1277#post-7719 Tue, 17 Jan 2012 10:31:24 +0000 gbulmer 7719@http://forums.leaflabs.com/ <p>bubulindo - You've found it. Brilliant! Well done.</p> <p>You've found a bug. The convention on the <code>#ifdef _FOO_H_ ... #define _FOO_H_</code> has been broken. (This stops the file being processed twice if it is #included in several places.)</p> <p>IMHO it should be <code>_WIRISH_TIME_H_</code> in wirish_time.h to follow the convention; map non-identifier characters to '_', and add '_' start and end. </p> <p>It should not effect any other linking.<br /> If it does throw up another error, it is likely a bug which needs to be raised to LeafLabs anyway.</p> <p>Nice going :-) </p> http://forums.leaflabs.com/topic.php?id=1277#post-7703 Mon, 16 Jan 2012 21:45:07 +0000 bubulindo 7703@http://forums.leaflabs.com/ <p>Think I found it. </p> <p>In wirish_time.h: </p> <p>#ifndef _TIME_H_<br /> #define _TIME_H_</p> <p>In time.h: </p> <p>#ifndef _TIME_H_<br /> #define _TIME_H_</p> <p>If I change the TIME_H in the wirish file to WIRISH_TIME_H, it compiles (would have to test it back home).<br /> Would this change affect any other linking between functions? </p> http://forums.leaflabs.com/topic.php?id=1277#post-7697 Mon, 16 Jan 2012 19:29:03 +0000 gbulmer 7697@http://forums.leaflabs.com/ <p>bubildiono - you wrote</p> <blockquote><p>One thing that I need to think about is the support for dates before Epoch... if I could use the counting variable as unsigned and set the "new Epoch" to say 2010, would be nice.</p></blockquote> <p>I was trying to explain reasons for keeping the epoch start at midnight 1st Jan 1970.</p> <p>The usual way of finding bugs, when all else fails, is to binary chop the file.<br /> Identify the code that causes the error by removing sections.<br /> Because it is a header file, It will likely be easier to work from the back end, as parts earlier in the file may be defining things that are used later.</p> <p>I assume you know how to use the pre-processor.<br /> Use<br /> <pre><code>#if 0 ... #endif</code></pre> <p>to 'remove' sections of time.h. </p> <p>Remove any reference to functions defined in time.h in your sketch, but still include time.h. </p> <p>Start by effectively removing everything in time.h, and make sure you don't badly nest with the <code>#ifndef _TIME_H_</code>.<br /> This should make the build work.<br /> Then move the <code>#if 0</code> and <code>#endif</code> so that they 'remove' half the file, and add extra <code>#if 0</code> and <code>#endif</code> until you have narrowed down the line which makes the build break.</p> <p>It is crude, but can be quite quick. </p> http://forums.leaflabs.com/topic.php?id=1277#post-7694 Mon, 16 Jan 2012 17:42:17 +0000 bubulindo 7694@http://forums.leaflabs.com/ <p>Hi, </p> <p>I thought it was pretty obvious that my intention is to use time.h. Reason being that it's already there, it works and it has been tested. </p> <p>But so far, I wasn't able to include it without problems. So, the functions I took from there are temporary, but I would much rather find a way of including them in my file and work with that. </p> <p>Any ideas on how to achieve that? </p> http://forums.leaflabs.com/topic.php?id=1277#post-7686 Mon, 16 Jan 2012 14:06:03 +0000 gbulmer 7686@http://forums.leaflabs.com/ <p>bublindo - I'd recommend sticking with the types defined in time.h so that, when the bug (time.h and delay() or millis() clash) gets fixed, the 'real' time.h functions can be used. My assumption is your few functions extracted from time.h set are a temporary work around for something that should be fixed properly.</p> <p>I would not change time_t from the type exported by time.h.<br /> So it would only be a 64bit type iff the type exported by time.h is 64 bit.<br /> Otherwise, people who are accustomed to time.h will get a surprise, and it might break something in the time.h functions. I don't understand the benefit in changing stuff exported from time.h for the sake of it. I assume your functions are a temporary fix.</p> <p>I prefer the epoch to start at 12:00 midnight, January 1st, 1970, but I feel the key consideration is staying compatible with time.h. It is that which locks the epoch down.</p> <p>IMHO, most people either use the time.h functions to do input or output, or they compare timestamps. </p> <p>For timestamp comparison to work it doesn't matter much when the epoch started as long as the maths works. So any arbitrary epoch start, far enough back, but not too far works. </p> <p>For input or output using time.h functions, I believe they assume midnight, 1st Jan 1970, and you'd have work to do to change it. If you stick with that epoch start, everything works 'for free'.</p> <p>Choosing any other epoch start seems to create work, or make you incompatible with time.h, but I can see no benefit.</p> <p>HTH </p> http://forums.leaflabs.com/topic.php?id=1277#post-7680 Mon, 16 Jan 2012 09:00:14 +0000 r1s3n 7680@http://forums.leaflabs.com/ <p>I'm not sure if you've ever done any Unix programming or not but time 0 is 12:00:00 Jan 1 1970. Changing that could have some implications if people wanted to port other software and expected a standard behavior. Anything against typedef'ing a 64 bit signed int as time_t? That would take care of both ends of your problem, you could have dates in the positive integer ranges from jan 1 1970 to a *VERY* long time after you're dead (2^63 seconds after 1970). I get that it incurs more overhead having to deal with a 64 bit quantity on a 32 bit processor, but (and this is my opinion) it seems like a much cleaner solution than moving away from the standard. </p> http://forums.leaflabs.com/topic.php?id=1277#post-7679 Mon, 16 Jan 2012 05:38:58 +0000 bubulindo 7679@http://forums.leaflabs.com/ <p>Ok... </p> <p>I got the juice out of the newlib for the mktime and localtime, took the timezone support away to make the footprint smaller and at least localtime is working properly. </p> <p>The downside is that my code files look like down town Mogadishu. It'll take some time to clean up, test and release, but it's a good sign. I also didn't had to use any of the standard libraries. :)</p> <p>One thing that I need to think about is the support for dates before Epoch... if I could use the counting variable as unsigned and set the "new Epoch" to say 2010, would be nice.<br /> What do you guys think? </p> http://forums.leaflabs.com/topic.php?id=1277#post-7670 Sun, 15 Jan 2012 19:55:05 +0000 bubulindo 7670@http://forums.leaflabs.com/ <p>Yes, same error. </p> <p>It may be my include order maybe, or something to do with the include directories. </p> <p>I downloaded the newlib and I can get the conversion functions and time_t/struct tm definition in the .h file. </p> <p>I'll get started on that back home. </p>