Including time.h from a library.

LeafLabs Garden » Community » The Garden

Including time.h from a library.

(21 posts) (6 voices)

Started 4 years ago by bubulindo
Latest reply from mbolivar

12 Next »

bubulindo
Member

Hello,

As you can see from another post, I'm working with Rod on a library to get RTC support in the Maple.

I'm having some problems right now that I'd like some guru help with.

First, the RTC is counting seconds, so having a function that converts seconds to date/time from Epoch would be awesome. I created a sketch including time.h (and not including my RTC library) and I can access localtime(), mktime(), time_t and struct tm from that sketch, but if I include the time.h in my library I get an error saying that time_t is not defined (or any time.h functions).

Second, when I use time.h, delay() and millis() link gets broken. if I include time.h, I cannot use any of those functions.

Third, during the development of the low level functions for the RTC we changed rcc.h files by including the LSI clock selection and functions to start LSI and LSE (HSE only gets checked). I did these changes in the rcc.h file inside the libmaple directory and it works perfectly if I run the compilation from the command line. However, when I try to run this from a library, these rcc.h changes aren't visible to the IDE. Why is that?

Any help is much appareciated.

Posted 4 years ago #
bubulindo
Member

Ok, found the problem on the third issue, I was compiling libmaple, and the IDE is in a different directory.

Any help on the other two items?

Posted 4 years ago #
gbulmer
Moderator

second problem - What does the link error message say?
We might be able to help if you give some more information.

Presumably something in time.h is either defining or pulling in something which conflicts with the implementation of delay() or millis().
The tidiest solution might be to change libmaple source so that the time.h functions work.

first problem - depending on the solution to your second problem, you would use one of the newlib functions documented in the Timefns section of Docs -> Red Hat newlib C Library Documentation at
http://sourceware.org/newlib/

gmtime will convert the number of seconds since January 1 1970 to a time structure (struct tm) (you might have to initialise something to keep track of the time, in seconds, at which the real time clock started, and add that offset)
asctime will convert that structure to a standard format string
strftime will convert that structure to a string using a format that you specify

The source of newlib is available, so if you can't figure out how to fix the conflict between time.h and delay() and millis(), then you could extract the few functions that you need, and cut it down to a point where the link error can be fixed.
I'd guess that fixing the link error due to delay() and millis() may be easier though.

Posted 4 years ago #
bubulindo
Member

Right, I should have given a bit more info. Sorry.

The RTC library I am using is in github at https://github.com/bubulindo/MapleRTC. I place these in the MapleIDE sketch folder inside libraries.

I have to run now, but I'll post all examples of this here soon.

Posted 4 years ago #
bubulindo
Member

Ok, so here's what's happening:

If I include <time.h> in my RTClock.h file and define a time_t variable inside then my program (without delay or millis) in the IDE compiles. If I had delay or millis (or possibly any other function), it says:

In function 'void loop()':
error: 'millis' was not declared in this scope

Listing of all compiler output follows.
Note: <BUILD> stands for the temporary build directory used to compile your sketch, which is:
C:\DOCUME~1\cardosoc\LOCALS~1\Temp\build6740197683448982665.tmp

Also note that because of preprocessing, line numbers won't match up exactly. We're working on a fix.
<BUILD>\test_RTClock.cpp: In function 'void loop()':
<BUILD>\test_RTClock.cpp:13: error: 'millis' was not declared in this scope

If I remove the include to time.h, millis works fine.

Rod has created the low level support for the RTC, so we now have the RTC counting seconds in hardware, so what we really need is just the functions to convert to a "friendly" format, but keeping the footprint low. And for that, the mktime() and localtime (or gmtime) would be enough for what we need.

I'll have a look at these conversion functions in the link posted by you.

Posted 4 years ago #
gbulmer
Moderator

bubulindo - okay.
Do you get exactly the same type of error if you call delay() instead of millis()?

Nasty error.
I keep meaning to write a tool to help find these sorts of errors, but I never get around to it :-(

Getting your system working, and raising a bug report to Leaflabs would be excellent :-)

The newlib code might look a bit odd, but I believe it is usable, and does the job. It is the code Maple uses.

Posted 4 years ago #
bubulindo
Member

Yes, same error.

It may be my include order maybe, or something to do with the include directories.

I downloaded the newlib and I can get the conversion functions and time_t/struct tm definition in the .h file.

I'll get started on that back home.

Posted 4 years ago #
bubulindo
Member

Ok...

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.

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. :)

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.
What do you guys think?

Posted 4 years ago #
r1s3n
Member

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.

Posted 4 years ago #
gbulmer
Moderator

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.

I would not change time_t from the type exported by time.h.
So it would only be a 64bit type iff the type exported by time.h is 64 bit.
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.

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.

IMHO, most people either use the time.h functions to do input or output, or they compare timestamps.

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.

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'.

Choosing any other epoch start seems to create work, or make you incompatible with time.h, but I can see no benefit.

HTH

Posted 4 years ago #
bubulindo
Member

Hi,

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.

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.

Any ideas on how to achieve that?

Posted 4 years ago #
gbulmer
Moderator
bubildiono - you wrote

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.

I was trying to explain reasons for keeping the epoch start at midnight 1st Jan 1970.

The usual way of finding bugs, when all else fails, is to binary chop the file.
Identify the code that causes the error by removing sections.
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.

I assume you know how to use the pre-processor.
Use
```
#if 0
   ...
#endif
```
to 'remove' sections of time.h.

Remove any reference to functions defined in time.h in your sketch, but still include time.h.

Start by effectively removing everything in time.h, and make sure you don't badly nest with the #ifndef _TIME_H_.
This should make the build work.
Then move the #if 0 and #endif so that they 'remove' half the file, and add extra #if 0 and #endif until you have narrowed down the line which makes the build break.

It is crude, but can be quite quick.
Posted 4 years ago #
bubulindo
Member

Think I found it.

In wirish_time.h:

#ifndef _TIME_H_
#define _TIME_H_

In time.h:

#ifndef _TIME_H_
#define _TIME_H_

If I change the TIME_H in the wirish file to WIRISH_TIME_H, it compiles (would have to test it back home).
Would this change affect any other linking between functions?

Posted 4 years ago #
gbulmer
Moderator

bubulindo - You've found it. Brilliant! Well done.

You've found a bug. The convention on the #ifdef _FOO_H_ ... #define _FOO_H_ has been broken. (This stops the file being processed twice if it is #included in several places.)

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.

It should not effect any other linking.
If it does throw up another error, it is likely a bug which needs to be raised to LeafLabs anyway.

Nice going :-)

Posted 4 years ago #
poslathian
LeafLabs

thanks! we will check in to it!

Posted 4 years ago #

RSS feed for this topic

12 Next »

Reply »

You must log in to post.