mbed RTC module

[Thiago Naves]

I just created a branch called mbed with a RTC module for this platform.
This also adds interrupt support for the RTC alarm.

Also on this branch is the RTC module for the STR9 platform. I pushed this one by mistake, but I guess I'll just leave it there, in case someone wants to use it.

I have yet to write a doc for those and probably figure out a better API for the alarm ( as they are not the same in STR9 and mbed ).

Best,
Thiago

_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[Martin Guy]

On 5 June 2012 23:39, Thiago Naves <[hidden email]> wrote:
> I just created a branch called mbed with a RTC module for this platform.
> This also adds interrupt support for the RTC alarm.
>
> I have yet to write a doc for those and probably figure out a better API for
> the alarm ( as they are not the same in STR9 and mbed ).

Look at the mizar32 rtc.*() module and see if we can arrive at one
interface for both.
I put our pro-tem docs up at
http://simplemachines.it/martin/elua/en_refman_ps_mizar32_rtc.html

Our hardware has alarms, but I didn't understand enough to figure out
a Lua interface

Let me know

   M
_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[Thiago Naves]

I think we should have no problem to make a single interface for setting and getting dates and times.
I liked the mizar interface, but it seems a bit verbose having to create a table to set a date / time.

The interface on my branch ( I think Bogdan wrote it for str9 ) is a bit closer to the Lua interface, but without the string formatting options.
That is,
mbed.rtc.gettime("*t") returns a table with the fields hour, min, sec
mbed.rtc.gettime("*s") returns a string formated as HH:MM:SS
mbed.rtc.getdate("*t") returns a table with the fields year, month, day
mbed.rtc.getdate("*s") returns a string formated as DD/MM/YYYY

The set functions setdate and settime can receive a table with those fields or a string in that same format.
I could add day of week as Lua have, but str9 has no support for the day of year...

In the alarm part the case is a bit more complicated as the str9 alarm only have the hour, min, sec and day of month fields, while the mbed has full date and time support.
For now, I left different APIs for the alarm, as I have no idea how to unify that.


Best,
Thiago

On Tue, Jun 5, 2012 at 11:40 PM, Martin Guy <[hidden email]> wrote:

On 5 June 2012 23:39, Thiago Naves <[hidden email]> wrote:
> I just created a branch called mbed with a RTC module for this platform.
> This also adds interrupt support for the RTC alarm.
>

> I have yet to write a doc for those and probably figure out a better API for
> the alarm ( as they are not the same in STR9 and mbed ).

Look at the mizar32 rtc.*() module and see if we can arrive at one
interface for both.
I put our pro-tem docs up at
http://simplemachines.it/martin/elua/en_refman_ps_mizar32_rtc.html

Our hardware has alarms, but I didn't understand enough to figure out
a Lua interface

Let me know

  M
_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[Martin Guy]

On 6 June 2012 07:06, Thiago Naves <[hidden email]> wrote:
> I think we should have no problem to make a single interface for setting and
> getting dates and times.
> I liked the mizar interface, but it seems a bit verbose having to create a
> table to set a date / time.

Verbose? I aimed for the minimum of cruft and limiting the interface
to the essential information.

> The interface on my branch ( I think Bogdan wrote it for str9 ) is a bit
> closer to the Lua interface, but without the string formatting options.
> That is,
> mbed.rtc.gettime("*t") returns a table with the fields hour, min, sec
> mbed.rtc.gettime("*s") returns a string formated as HH:MM:SS
> mbed.rtc.getdate("*t") returns a table with the fields year, month, day
> mbed.rtc.getdate("*s") returns a string formated as DD/MM/YYYY

I saw this, and couldn't bring myself to use it because it has two defects:
1. You can't set the date and time in a single call, and making two
calls sets the date wrong by a day at midnight when 00:00:00 falls
between the calls. Time-and-date-setting (and reading) needs to be a
single atomic operation
2. DD/MM/YYYY is MM/DD/YYYY in the USA, so you can't write code
without knowing the date-printing conventions in your
internationalization locale, which is not something that eLua does
because the tables of info for it to work is huge, the same as the
daylight time stuff, unless you do this at compile-time to produce
i18n-zone-specific firmware, again something I would prefer to avoid
if possible.

> The set functions setdate and settime can receive a table with those fields
> or a string in that same format.
> I could add day of week as Lua have, but str9 has no support for the day of
> year...

Our clocks don't have DOY either (and shouldn't as it's a value
derived from other fields.
I have a short magic formula somewhere that will calculate it if you
need it for some reason.
Actually, DOW is redundant too, but both Lua and the hardware have it,
so i just pass it on.
Presumably a hypothetical clock with a DOY register could take note of
that field if present, and return it, but it looks like a non-problem
to me at present

> In the alarm part the case is a bit more complicated as the str9 alarm only
> have the hour, min, sec and day of month fields, while the mbed has full
> date and time support.

That's easy - just ignore fields that the hardware does not support.

> For now, I left different APIs for the alarm, as I have no idea how to unify
> that.

I see not a lot has changed in eLua-API-discussion world!  :)

   M
_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[Thiago Naves]

On Wed, Jun 6, 2012 at 6:05 AM, Martin Guy <[hidden email]> wrote:

On 6 June 2012 07:06, Thiago Naves <[hidden email]> wrote:
> I think we should have no problem to make a single interface for setting and
> getting dates and times.
> I liked the mizar interface, but it seems a bit verbose having to create a
> table to set a date / time.

Verbose? I aimed for the minimum of cruft and limiting the interface
to the essential information.

Yes, but I was comparing the table interface to a string interface.
Actually, I think the table interface is good to store various datetimes ( in a scheduler for example ),
while the string interface is better for debugging ( hard coded dates, setting via terminal, ... ) and
writing to an LCD or terminal for example.
 

> The interface on my branch ( I think Bogdan wrote it for str9 ) is a bit
> closer to the Lua interface, but without the string formatting options.
> That is,
> mbed.rtc.gettime("*t") returns a table with the fields hour, min, sec
> mbed.rtc.gettime("*s") returns a string formated as HH:MM:SS
> mbed.rtc.getdate("*t") returns a table with the fields year, month, day
> mbed.rtc.getdate("*s") returns a string formated as DD/MM/YYYY

I saw this, and couldn't bring myself to use it because it has two defects:
1. You can't set the date and time in a single call, and making two
calls sets the date wrong by a day at midnight when 00:00:00 falls
between the calls. Time-and-date-setting (and reading) needs to be a
single atomic operation

True. I'll change that.
 

2. DD/MM/YYYY is MM/DD/YYYY in the USA, so you can't write code
without knowing the date-printing conventions in your
internationalization locale, which is not something that eLua does
because the tables of info for it to work is huge, the same as the
daylight time stuff, unless you do this at compile-time to produce
i18n-zone-specific firmware, again something I would prefer to avoid
if possible.

I think we could choose a format and document it, rather than having none.
I agree we should not try to support all of them.
 

> The set functions setdate and settime can receive a table with those fields
> or a string in that same format.
> I could add day of week as Lua have, but str9 has no support for the day of
> year...

Our clocks don't have DOY either (and shouldn't as it's a value
derived from other fields.
I have a short magic formula somewhere that will calculate it if you
need it for some reason.

It's not hard to calculate that, but I don't need it right now too...I was just comparing to the Lua functions.
 

Actually, DOW is redundant too, but both Lua and the hardware have it,
so i just pass it on.

Same here ( I have to add that yet ).
 

Presumably a hypothetical clock with a DOY register could take note of
that field if present, and return it, but it looks like a non-problem
to me at present

Me too.
 

> In the alarm part the case is a bit more complicated as the str9 alarm only
> have the hour, min, sec and day of month fields, while the mbed has full
> date and time support.

That's easy - just ignore fields that the hardware does not support.

Either that or store in memory the fields not supported by the hardware and compare those
when a interrupt arrives and only add a eLua interrupt if it matches.
 

> For now, I left different APIs for the alarm, as I have no idea how to unify
> that.

I see not a lot has changed in eLua-API-discussion world!  :)

:)
 

Thiago
 

  M
_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev<span onmouseout="cancel = false; window.setTimeout(WRCHideContent, 1000); clearTimeout(showTimer);" onmouseover=" var self = this; showTimer = window.setTimeout(function(){WRCShowContent({&#39;rating&#39;:{&#39;value&#39;:100,&#39;weight&#39;:13},&#39;flags&#39;:{},&#39;single&#39;:false,&#39;ttl&#39;:7200,&#39;expireTime&#39;:&#39;20120605174937&#39;}, self.className)},600);" class="wrc11" style="padding-right:16px;width:16px;height:16px">

_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[Thiago Naves]

So, I've made some changes here.
The new API is similar to the Mizar:
mbed.rtc.set sets the date and time ( can receive a table with the 'day', 'month', 'year', 'hour', 'minute' and 'second' fields or a string formatted as dd/mm/yyyy hh:mm:ss )
mbed.rtc.get("*t") returns a table with the date and time ( same fields as the set function )
mbed.rtc.get("*s") returns the date and time as a string ( same as the set )
mbed.rtc.setalarm sets the alarm date and time ( same parameters as the set function )
mbed.rtc.alarmed() returns true if the alarm was fired ( in case you're not using interrupts ) and clears the alarm flag

I intend to change the get function to be able to format the string ( as Lua does ).
We already have that in the C lib, so it should not be hard nor take much flash space.
I think the get() should return a string with a default format ( so we don't have locales. we could vote on which one ) as Lua does ( except for the locale ).
That format would also be the format expected by the set function.

--
Thiago

On Wed, Jun 6, 2012 at 2:34 PM, Thiago Naves <[hidden email]> wrote:

On Wed, Jun 6, 2012 at 6:05 AM, Martin Guy <[hidden email]> wrote:

On 6 June 2012 07:06, Thiago Naves <[hidden email]> wrote:
> I think we should have no problem to make a single interface for setting and
> getting dates and times.
> I liked the mizar interface, but it seems a bit verbose having to create a
> table to set a date / time.

Verbose? I aimed for the minimum of cruft and limiting the interface
to the essential information.

Yes, but I was comparing the table interface to a string interface.
Actually, I think the table interface is good to store various datetimes ( in a scheduler for example ),
while the string interface is better for debugging ( hard coded dates, setting via terminal, ... ) and
writing to an LCD or terminal for example.
 

> The interface on my branch ( I think Bogdan wrote it for str9 ) is a bit
> closer to the Lua interface, but without the string formatting options.
> That is,
> mbed.rtc.gettime("*t") returns a table with the fields hour, min, sec
> mbed.rtc.gettime("*s") returns a string formated as HH:MM:SS
> mbed.rtc.getdate("*t") returns a table with the fields year, month, day
> mbed.rtc.getdate("*s") returns a string formated as DD/MM/YYYY

I saw this, and couldn't bring myself to use it because it has two defects:
1. You can't set the date and time in a single call, and making two
calls sets the date wrong by a day at midnight when 00:00:00 falls
between the calls. Time-and-date-setting (and reading) needs to be a
single atomic operation

True. I'll change that.
 

2. DD/MM/YYYY is MM/DD/YYYY in the USA, so you can't write code
without knowing the date-printing conventions in your
internationalization locale, which is not something that eLua does
because the tables of info for it to work is huge, the same as the
daylight time stuff, unless you do this at compile-time to produce
i18n-zone-specific firmware, again something I would prefer to avoid
if possible.

I think we could choose a format and document it, rather than having none.
I agree we should not try to support all of them.
 

> The set functions setdate and settime can receive a table with those fields
> or a string in that same format.
> I could add day of week as Lua have, but str9 has no support for the day of
> year...

Our clocks don't have DOY either (and shouldn't as it's a value
derived from other fields.
I have a short magic formula somewhere that will calculate it if you
need it for some reason.

It's not hard to calculate that, but I don't need it right now too...I was just comparing to the Lua functions.
 

Actually, DOW is redundant too, but both Lua and the hardware have it,
so i just pass it on.

Same here ( I have to add that yet ).
 

Presumably a hypothetical clock with a DOY register could take note of
that field if present, and return it, but it looks like a non-problem
to me at present

Me too.
 

> In the alarm part the case is a bit more complicated as the str9 alarm only
> have the hour, min, sec and day of month fields, while the mbed has full
> date and time support.

That's easy - just ignore fields that the hardware does not support.

Either that or store in memory the fields not supported by the hardware and compare those
when a interrupt arrives and only add a eLua interrupt if it matches.
 

> For now, I left different APIs for the alarm, as I have no idea how to unify
> that.

I see not a lot has changed in eLua-API-discussion world!  :)

:)
 

Thiago
 

  M
_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev<span onmouseout="cancel = false; window.setTimeout(WRCHideContent, 1000); clearTimeout(showTimer);" onmouseover=" var self = this; showTimer = window.setTimeout(function(){WRCShowContent({&#39;rating&#39;:{&#39;value&#39;:100,&#39;weight&#39;:13},&#39;flags&#39;:{},&#39;single&#39;:false,&#39;ttl&#39;:7200,&#39;expireTime&#39;:&#39;20120614192925&#39;}, self.className)},600);" class="wrc11" style="padding-right:16px;width:16px;height:16px">

_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[Martin Guy]

On 23 June 2012 00:13, Thiago Naves <[hidden email]> wrote:
> a string formatted as dd/mm/yyyy hh:mm:ss

That still falls foul of meaning MM/DD/YYYY in the USA to people's eyes.

> mbed.rtc.setalarm sets the alarm date and time ( same parameters as the set
> function )
> mbed.rtc.alarmed() returns true if the alarm was fired ( in case you're not
> using interrupts ) and clears the alarm flag

Thanks for this. I think some hardware can cause interrupts when the
alarm fires.
Do you have any ideas for that?

> I intend to change the get function to be able to format the string ( as Lua
> does ).

I think there are already date-formatting routines in the Lua library which will
format the same table as we are using. You go:

print(os.date("%x", os.time(rtc.get()))

however I agree that condensing that to rtc.get("%x"), if they want
mm/dd/yyyy or dd/mm/yyyy or whatever Lua gives by default.

I have a nasty feeling though that the os.*() library is not present
in eLua, so a custom hack may result in being smaller code.

> I think the get() should return a string with a default format ( so we don't
> have locales. we could vote on which one )

the only unambiguous one is yyyy-mm-dd but it's a bit shocking to mortals :)

   M
_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[Martin Guy]

On 23 June 2012 05:00, Martin Guy <[hidden email]> wrote:
> I have a nasty feeling though that the os.*() library is not present
> in eLua

PS I think it should be, for the standard Lua few primitives for file
rename and remove, apart from the time stuff.
`
_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[BogdanM]

On Sat, Jun 23, 2012 at 6:08 AM, Martin Guy <[hidden email]> wrote:
> On 23 June 2012 05:00, Martin Guy <[hidden email]> wrote:
>> I have a nasty feeling though that the os.*() library is not present
>> in eLua
>
> PS I think it should be, for the standard Lua few primitives for file
> rename and remove, apart from the time stuff.

You are right, and that's coming.
Keep the RTC discussion alive, please. I don't know much about RTCs
and this is why I didn't say anything until now, I want to see where
this is going. It might well be the very first eLua module which API
has been discussed and established by the community. I do have one
small comment though :) I'd really like to avoid locale issues if at
all possible. That is, I'd like to have a definite date format and not
care too much that Europe uses dd/mm/yyyy, US uses mm/dd/yyyy and
other variations. For me, the only format that truly makes sense is
yyyy/mm/dd, simply because it's very easy (even natural) to order
dates written in this format.
Please let me know if you need help with RTC interrupts.

Best,
Bogdan

> `
> _______________________________________________
> eLua-dev mailing list
> [hidden email]
> https://lists.berlios.de/mailman/listinfo/elua-dev
_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[Pito]

> yyyy/mm/dd, simply because it's very easy (even
> natural) to order
> dates written in this format.
Or you may use unix time :)
Written on 1340452352
p.

--
- - Reklama - - - - - - - - - - - - - -
Maturity, přijímací zkoušky, státnice, diplomky... Vše o závěru
studia na středních a vysokých školách čtěte na portálu VOLNÝ.cz na
http://bit.ly/LfImCR

_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[BogdanM]

On Sat, Jun 23, 2012 at 2:54 PM, pito <[hidden email]> wrote:
>> yyyy/mm/dd, simply because it's very easy (even
>> natural) to order
>> dates written in this format.
> Or you may use unix time :)
> Written on 1340452352

That's much hader to read, unfortunately. Plus, there is the epoch
problem. That number is the time that has passed since a moment in the
past, called "epoch". Not all epoch dates are created equal:

http://en.wikipedia.org/wiki/Epoch_%28reference_date%29#Notable_epoch_dates_in_computing

This can easily lead to confusion.

Best,
Bogdan

> p.
>
> --
> - - Reklama - - - - - - - - - - - - - -
> Maturity, přijímací zkoušky, státnice, diplomky... Vše o závěru
> studia na středních a vysokých školách čtěte na portálu VOLNÝ.cz na
> http://bit.ly/LfImCR
>
_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[Pito]

I think there is only one unix time in the unix epoch :)
Moreover, you need only one eLua number to store the whole stuff -
and - while we have a lot of spare bits within the number we may
have a tick timer with better resolution as 1 sec.
So internally - unix time - and the presentation level done via
simple conversion routines if required. The only issue I see is 2038
- but I am in doubt we will deal with eLua at that time :) (nono,
just kidding - we will!).p.


----- PŮVODNÍ ZPRÁVA -----
Od: "Bogdan Marinescu" <[hidden email]>
Komu: "pito" <[hidden email]>
Předmět: Re: [eLua-dev] mbed RTC module
Datum: 23.6.2012 - 14:18:18

> On Sat, Jun 23, 2012 at 2:54 PM, pito
> <[hidden email]> wrote:
> >> yyyy/mm/dd, simply because it's very easy (even
> >> natural) to order
> >> dates written in this format.
> > Or you may use unix time :)
> > Written on 1340452352
>
> That's much hader to read, unfortunately. Plus,
> there is the epoch
> problem. That number is the time that has passed
> since a moment in the
> past, called "epoch". Not all epoch dates are
> created equal:
>
> http://en.wikipedia.org/wiki/Epoch_%28reference_date%29#Notable_epoch_dates_in_computing
> >
> This can easily lead to confusion.
>
> Best,
> Bogdan
>
> > p.
> >
> > --
> > - - Reklama - - - - - - - - - - - - - -
> > Maturity, přijímací zkoušky, státnice,
> > diplomky... Vše o závěru
> > > studia na středních a vysokých školách čtěte na
> > portálu VOLNÝ.cz na
> > > http://bit.ly/LfImCR
> >
>

--
- - Reklama - - - - - - - - - - - - - -
Maturity, přijímací zkoušky, státnice, diplomky... Vše o závěru
studia na středních a vysokých školách čtěte na portálu VOLNÝ.cz na
http://bit.ly/LfImCR

_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[Pito]

from wikipedia:
...In some newer operating systems, time_t has been widened to 64
bits. In the negative direction, this goes back more than twenty
times the age of the universe and in the positive direction for
approximately 293 billion years...
Let eLua be new!



----- PŮVODNÍ ZPRÁVA -----
Od: "pito" <[hidden email]>
Komu: [hidden email], [hidden email],
[hidden email]
Předmět: Re: [eLua-dev] mbed RTC module
Datum: 23.6.2012 - 14:26:50

> I think there is only one unix time in the unix
> epoch :)
> Moreover, you need only one eLua number to store
> the whole stuff -
> and - while we have a lot of spare bits within the
> number we may
> have a tick timer with better resolution as 1 sec.
> So internally - unix time - and the presentation
> level done via
> simple conversion routines if required. The only
> issue I see is 2038
> - but I am in doubt we will deal with eLua at that
> time :) (nono,
> just kidding - we will!).p.
>
>
> ----- PŮVODNÍ ZPRÁVA -----
> Od: "Bogdan Marinescu"
> <[hidden email]>
> Komu: "pito" <[hidden email]>
> Předmět: Re: [eLua-dev] mbed RTC module
> Datum: 23.6.2012 - 14:18:18
>
> > On Sat, Jun 23, 2012 at 2:54 PM, pito
> > <[hidden email]> wrote:
> > >> yyyy/mm/dd, simply because it's very easy
> > >> (even
> > >> > >> natural) to order
> > >> dates written in this format.
> > > Or you may use unix time :)
> > > Written on 1340452352
> >
> > That's much hader to read, unfortunately. Plus,
> > there is the epoch
> > problem. That number is the time that has passed
> > since a moment in the
> > past, called "epoch". Not all epoch dates are
> > created equal:
> >
> > http://en.wikipedia.org/wiki/Epoch_%28reference_date%29#Notable_epoch_dates_in_computing
> > > > > >
> > This can easily lead to confusion.
> >
> > Best,
> > Bogdan
> >
> > > p.
> > >
> > > --
> > > - - Reklama - - - - - - - - - - - - - -
> > > Maturity, přijímací zkoušky, státnice,
> > > diplomky... Vše o závěru
> > > > studia na středních a vysokých školách čtěte
> > > > na
> > > > > > portálu VOLNÝ.cz na
> > > > http://bit.ly/LfImCR
> > >
> >
>
> --
> - - Reklama - - - - - - - - - - - - - -
> Maturity, přijímací zkoušky, státnice, diplomky...
> Vše o závěru
> studia na středních a vysokých školách čtěte na
> portálu VOLNÝ.cz na
> http://bit.ly/LfImCR
>
>

--
- - Reklama - - - - - - - - - - - - - -
Maturity, přijímací zkoušky, státnice, diplomky... Vše o závěru
studia na středních a vysokých školách čtěte na portálu VOLNÝ.cz na
http://bit.ly/LfImCR

_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[Martin Guy]

On 23 June 2012 14:26, pito <[hidden email]> wrote:
> I think there is only one unix time in the unix epoch :)

Apart from the fact that this is a silly suggestion...

> The only issue I see is 2038

On Jan 19 03:14:08 2038 we have Y2.038K :)

And there's a party at my house :)

   M
_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[Thiago Naves]

On Jun 23, 2012 7:18 AM, "Bogdan Marinescu" <[hidden email]> wrote:
>
> On Sat, Jun 23, 2012 at 6:08 AM, Martin Guy <[hidden email]> wrote:
> > On 23 June 2012 05:00, Martin Guy <[hidden email]> wrote:
> >> I have a nasty feeling though that the os.*() library is not present
> >> in eLua
> >
> > PS I think it should be, for the standard Lua few primitives for file
> > rename and remove, apart from the time stuff.
>
> You are right, and that's coming.
> Keep the RTC discussion alive, please. I don't know much about RTCs
> and this is why I didn't say anything until now, I want to see where
> this is going. It might well be the very first eLua module which API
> has been discussed and established by the community. I do have one
> small comment though :) I'd really like to avoid locale issues if at
> all possible. That is, I'd like to have a definite date format and not
> care too much that Europe uses dd/mm/yyyy, US uses mm/dd/yyyy and
> other variations. For me, the only format that truly makes sense is
> yyyy/mm/dd, simply because it's very easy (even natural) to order
> dates written in this format.

I agree. As I said, I would like an api close to the Lua's os.date but without the locales.

I don't really care which format it is, as long it's documented.

> Please let me know if you need help with RTC interrupts.

That's already working on mbed and str9 ;)

Best,
Thiago

>
> Best,
> Bogdan
>
> > `
> > _______________________________________________
> > eLua-dev mailing list
> > [hidden email]
> > https://lists.berlios.de/mailman/listinfo/elua-dev
> _______________________________________________
> eLua-dev mailing list
> [hidden email]
> https://lists.berlios.de/mailman/listinfo/elua-dev

_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[Thiago Naves]

On Jun 23, 2012 8:54 AM, "pito" <[hidden email]> wrote:
>
> > yyyy/mm/dd, simply because it's very easy (even
> > natural) to order
> > dates written in this format.
> Or you may use unix time :)
> Written on 1340452352

We could add that as another function, like Lua's os.time

> p.
>
> --
> - - Reklama - - - - - - - - - - - - - -
> Maturity, přijímací zkoušky, státnice, diplomky... Vše o závěru
> studia na středních a vysokých školách čtěte na portálu VOLNÝ.cz na
> http://bit.ly/LfImCR
>
> _______________________________________________
> eLua-dev mailing list
> [hidden email]
> https://lists.berlios.de/mailman/listinfo/elua-dev

_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[Martin Guy]

> We could add that as another function, like Lua's os.time

Mmm. If there's space to reuse that module it would provide the same
format strings that people know already from standard Lua, thereby
leaving the decisions about date formats to the programmer and the C
library in use (i.e. whatever the embedded C library's strftime() does
by default in the case of the ambiguous %x and %c formats, presumably
in the absence of locale and timezone settings)

    M
_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[Thiago Naves]

So, I've added strftime formatting to the get function.
I had to calc Day of Week and Day of Year in the get function ( probably not the best place for that ) in order to fill the C time struct ( or else strftime hangs ).
The get() with no parameter returns strftime("%c") like lua formated as:
Wed Jun 27 15:25:11 2012

Now the get("*t") returns the table and get("something_else") returns a formatted string.

I've only added this for mbed. I'll update str9 when we decide an interface.

Best,
Thiago

On Sat, Jun 23, 2012 at 5:35 PM, Martin Guy <[hidden email]> wrote:

> We could add that as another function, like Lua's os.time

Mmm. If there's space to reuse that module it would provide the same
format strings that people know already from standard Lua, thereby
leaving the decisions about date formats to the programmer and the C
library in use (i.e. whatever the embedded C library's strftime() does
by default in the case of the ambiguous %x and %c formats, presumably
in the absence of locale and timezone settings)

   M
_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev<span onmouseout="cancel = false; window.setTimeout(WRCHideContent, 1000); clearTimeout(showTimer);" onmouseover=" var self = this; showTimer = window.setTimeout(function(){WRCShowContent({&#39;rating&#39;:{&#39;value&#39;:100,&#39;weight&#39;:13},&#39;flags&#39;:{},&#39;single&#39;:false,&#39;ttl&#39;:7200,&#39;expireTime&#39;:&#39;20120614192925&#39;}, self.className)},600);" class="wrc11" style="padding-right:16px;width:16px;height:16px">

_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[BogdanM]

So, are you ready to come up with a proposal for a platform independet
RTC module? Thiago, Martin, pito and whoever else is interested ...

Best,
Bogdan

On Wed, Jun 27, 2012 at 9:30 PM, Thiago Naves <[hidden email]> wrote:

> So, I've added strftime formatting to the get function.
> I had to calc Day of Week and Day of Year in the get function ( probably not
> the best place for that ) in order to fill the C time struct ( or else
> strftime hangs ).
> The get() with no parameter returns strftime("%c") like lua formated as:
> Wed Jun 27 15:25:11 2012
>
> Now the get("*t") returns the table and get("something_else") returns a
> formatted string.
>
> I've only added this for mbed. I'll update str9 when we decide an interface.
>
> Best,
> Thiago
>
>
>
> On Sat, Jun 23, 2012 at 5:35 PM, Martin Guy <[hidden email]> wrote:
>>
>> > We could add that as another function, like Lua's os.time
>>
>> Mmm. If there's space to reuse that module it would provide the same
>> format strings that people know already from standard Lua, thereby
>> leaving the decisions about date formats to the programmer and the C
>> library in use (i.e. whatever the embedded C library's strftime() does
>> by default in the case of the ambiguous %x and %c formats, presumably
>> in the absence of locale and timezone settings)
>>
>>    M
>> _______________________________________________
>> eLua-dev mailing list
>> [hidden email]
>> https://lists.berlios.de/mailman/listinfo/elua-dev
>
>
>
> _______________________________________________
> eLua-dev mailing list
> [hidden email]
> https://lists.berlios.de/mailman/listinfo/elua-dev

_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[Thiago Naves]

I liked the last interface I implemented, with the formatting.
I think I would just change the set function, so that the string
format expected would be yyyy-mm-dd hh:mm:ss

Best,
Thiago

On Fri, Jul 20, 2012 at 10:49 AM, Bogdan Marinescu
<[hidden email]> wrote:

> So, are you ready to come up with a proposal for a platform independet
> RTC module? Thiago, Martin, pito and whoever else is interested ...
>
> Best,
> Bogdan
>
> On Wed, Jun 27, 2012 at 9:30 PM, Thiago Naves <[hidden email]> wrote:
>> So, I've added strftime formatting to the get function.
>> I had to calc Day of Week and Day of Year in the get function ( probably not
>> the best place for that ) in order to fill the C time struct ( or else
>> strftime hangs ).
>> The get() with no parameter returns strftime("%c") like lua formated as:
>> Wed Jun 27 15:25:11 2012
>>
>> Now the get("*t") returns the table and get("something_else") returns a
>> formatted string.
>>
>> I've only added this for mbed. I'll update str9 when we decide an interface.
>>
>> Best,
>> Thiago
>>
>>
>>
>> On Sat, Jun 23, 2012 at 5:35 PM, Martin Guy <[hidden email]> wrote:
>>>
>>> > We could add that as another function, like Lua's os.time
>>>
>>> Mmm. If there's space to reuse that module it would provide the same
>>> format strings that people know already from standard Lua, thereby
>>> leaving the decisions about date formats to the programmer and the C
>>> library in use (i.e. whatever the embedded C library's strftime() does
>>> by default in the case of the ambiguous %x and %c formats, presumably
>>> in the absence of locale and timezone settings)
>>>
>>>    M
>>> _______________________________________________
>>> eLua-dev mailing list
>>> [hidden email]
>>> https://lists.berlios.de/mailman/listinfo/elua-dev
>>
>>
>>
>> _______________________________________________
>> eLua-dev mailing list
>> [hidden email]
>> https://lists.berlios.de/mailman/listinfo/elua-dev
> _______________________________________________
> eLua-dev mailing list
> [hidden email]
> https://lists.berlios.de/mailman/listinfo/elua-dev

_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev