RTC pull request

[Thiago Naves]

Hi,
I've posted a pull request on the eLua repo about a month ago adding a RTC module for the STR9 platform.
Did anyone have a look at it?


Best,
Thiago

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

[Martin Guy]

On 20 March 2012 17:51, Thiago Naves <[hidden email]> wrote:
> Hi,
> I've posted a pull request on the eLua repo about a month ago adding a RTC
> module for the STR9 platform.
> Did anyone have a look at it?

Hi. I just had a look at it. This explains where the documentation for
str9.rtc.*() came from, whose code didn't exist in the repo

I removed the docs for the codeless str9.rtc.*() functions in commit
a05c209ab2e14e7879f8f5f49064f5b87fa7367e so I guess you'll need to
fish that out again and include it, extended to include the spec for
the alarm functions.

One problem with it is that is has separate setdate() and settime()
functions, which means that you can'r reliably set the time and date:
if a program sets or gets both at midnight and the time rolls over
between the two calls, the date is set or returned 24 hours wrong. A
better interface would be one call that handles both in one go.
   For Mizar32 I did this using the same table structure as is used in
the strangely named standard Lua functions os.date() and os.time()
(which *don't* handle time and date respectively!). To adjust only
some fields, you call it with the parameters you want to change:
   mizar32.rtc.set( { hour=12, min=34 } )
and it does read-modify-write of all fields atomically.

The other problem is with its time formats: "03/04/2012" is ambiguous
since in America it means the 4th of March and in the rest of the
world the 3rd of April, whereas the Lua-like table is unambiguous,
time zones apart. But I doubt we want to get into internationalization
and timezones inside eLua...

If we aim at ending up with a single rtc.*() module ultimately, it
might be good to make the platform modules as similar as possible in
preparation for the merge.

Thanks for the suggestion for an interface to RTC alarm interrupts. I
hadn't figured out how to handle this. The DS1337 and PCF8653 have
multiple alarm timers and interrupts. Am I reading your code examples
right, that the first parameter for the setalarm() method is the alarm
timer ID?

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

[Thiago Naves]

On Mar 20, 2012 6:32 PM, "Martin Guy" <[hidden email]> wrote:
>
> On 20 March 2012 17:51, Thiago Naves <[hidden email]> wrote:
> > Hi,
> > I've posted a pull request on the eLua repo about a month ago adding a RTC
> > module for the STR9 platform.
> > Did anyone have a look at it?
>
> Hi. I just had a look at it. This explains where the documentation for
> str9.rtc.*() came from, whose code didn't exist in the repo
>

Ah, yeah "^^ we've been using that since eLua pre 0.7 I think...

> I removed the docs for the codeless str9.rtc.*() functions in commit
> a05c209ab2e14e7879f8f5f49064f5b87fa7367e so I guess you'll need to
> fish that out again and include it, extended to include the spec for
> the alarm functions.
>

Yes. I'll take a look at that later. Had totally forgot.

> One problem with it is that is has separate setdate() and settime()
> functions, which means that you can'r reliably set the time and date:
> if a program sets or gets both at midnight and the time rolls over
> between the two calls, the date is set or returned 24 hours wrong. A
> better interface would be one call that handles both in one go.
>   For Mizar32 I did this using the same table structure as is used in
> the strangely named standard Lua functions os.date() and os.time()
> (which *don't* handle time and date respectively!). To adjust only
> some fields, you call it with the parameters you want to change:
>   mizar32.rtc.set( { hour=12, min=34 } )
> and it does read-modify-write of all fields atomically.
>

This mimics the ST library I think. (Not that its a good thing =P)

> The other problem is with its time formats: "03/04/2012" is ambiguous
> since in America it means the 4th of March and in the rest of the
> world the 3rd of April, whereas the Lua-like table is unambiguous,
> time zones apart. But I doubt we want to get into internationalization
> and timezones inside eLua...
>

This is in the DD/MM/YYYY format, if I'm not mistaken.

> If we aim at ending up with a single rtc.*() module ultimately, it
> might be good to make the platform modules as similar as possible in
> preparation for the merge.
>

Yes. I only wrote the alarm part, and had nothing to do with the API...I don't really have the time to change this right now, but maybe in the future...

> Thanks for the suggestion for an interface to RTC alarm interrupts. I
> hadn't figured out how to handle this. The DS1337 and PCF8653 have
> multiple alarm timers and interrupts. Am I reading your code examples
> right, that the first parameter for the setalarm() method is the alarm
> timer ID?
>

No, that's actually the day number.
The str9 only has 1 rtc timer with 1 alarm, but it handles day and time. I have no idea what happens if you set a day earlier than the current. It may do nothing or alert you next month...idk.

Also I should note that I haven't implemented the table version of the api (like the setdate and settime have).

Thiago

>    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]

> Also I should note that I haven't implemented the table version of the api

I'd tend to make the platform layer as thin as possible not as helpful
as possible, more like an OS layer with one way of doing each thing,
to reduce code size for the benefit of platforms with limited space -
assuming we're going for one interface in the end. I also tend towards
Lua-like constructs like the existing time and date tables or, I
suppose, seconds of time since some epoch. The table seems nicer - I
have small C routines for gmtime and mktime that convert between
seconds and the broken-out fields if some platform only has a seconds
counter (maybe for a backup software RTC on boards with no RTC
hardware, which keeps the tie as long as it's on, running off the
1-sec system interrupt.

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

[Ivan - Omnima]

Hi,

I'm in the process of testing the LuaRPC functions - all is working well apart from one edge case.

This happens if a function in an unknown/unregistered module is called. In this case eLua would hang.

Under normal operation this should not happen but a user could by mistake enter an incorrect name.

For example:

#Successful call to a known function - ok
#Call executes and returns ok - as it's a function implemented in the registered 'ox' module
slave.ox.enable_zwave(true)

#Call to a non-existent function within a module - returns ok
#Correctly returns an error (indicates: stdin:1: undefined function)
slave.ox.newfunction1234()

But calling a function in an undefined module hangs in the call to lua_getfield(L,-1,token) in read_cmd_call(..) within luarpc.c:

slave.oxnew.newfunction1234() #This would hang on the server side of LuaRPC as oxnew is not known - is not implemented in eLua.

Any suggestions on how we can lookup whether a module is registered - to prevent the hang?

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

[jbsnyder]

This is definitely a bug, but I think it should be pretty simple to fix in the remote indexing code. My first run approach would be to check that each indexing step goes as expected and returns the first error. I believe right now it might only return, or try to handle the error on the calling. 

I'm just getting back into town today and I can try a fix. 

-- 
James Snyder

On Monday, March 26, 2012 at 9:09, Ivan - Omnima wrote:

Hi,

I'm in the process of testing the LuaRPC functions - all is working well apart from one edge case.

This happens if a function in an unknown/unregistered module is called. In this case eLua would hang.

Under normal operation this should not happen but a user could by mistake enter an incorrect name.

For example:

#Successful call to a known function - ok
#Call executes and returns ok - as it's a function implemented in the registered 'ox' module
slave.ox.enable_zwave(true)

#Call to a non-existent function within a module - returns ok
#Correctly returns an error (indicates: stdin:1: undefined function)
slave.ox.newfunction1234()

But calling a function in an undefined module hangs in the call to lua_getfield(L,-1,token) in read_cmd_call(..) within luarpc.c:

slave.oxnew.newfunction1234() #This would hang on the server side of LuaRPC as oxnew is not known - is not implemented in eLua.

Any suggestions on how we can lookup whether a module is registered - to prevent the hang?

Regards,
Ivan

Omnima Limited
Ivan Ignjatic
176 Kennington Road
Oxford OX1 5PG

Tel. [phone]
Fax. [phone]

Web: www.omnima.co.uk
Skype: omnimaautomation

_______________________________________________

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

[jbsnyder]

On Mon, Mar 26, 2012 at 9:09 AM, Ivan - Omnima <[hidden email]> wrote:
> Hi,
>
> I'm in the process of testing the LuaRPC functions - all is working well
> apart from one edge case.
>
> This happens if a function in an unknown/unregistered module is called. In
> this case eLua would hang.

I've just committed some changes on the master repository that I think
should correct a few issues, both of which are mentioned in the commit
message:
https://github.com/elua/elua/commit/fbebb2949efe548e457da8dcce53c319ce5a0880

I may opt for a more permanent or flexible approach to deal with this
problem in the future, but in testing it seemed to be handling a
couple different test conditions correctly.  Another thing that might
make sense is allowing the user to catch this error with the handler
they've set rather than just dumping a stack trace.

>
> Under normal operation this should not happen but a user could by mistake
> enter an incorrect name.
>
> For example:
>
> #Successful call to a known function - ok
> #Call executes and returns ok - as it's a function implemented in the
> registered 'ox' module
> slave.ox.enable_zwave(true)
>
> #Call to a non-existent function within a module - returns ok
> #Correctly returns an error (indicates: stdin:1: undefined function)
> slave.ox.newfunction1234()
>
> But calling a function in an undefined module hangs in the call to
> lua_getfield(L,-1,token) in read_cmd_call(..) within luarpc.c:
>
> slave.oxnew.newfunction1234() #This would hang on the server side of LuaRPC
> as oxnew is not known - is not implemented in eLua.
>
> Any suggestions on how we can lookup whether a module is registered - to
> prevent the hang?
>
> Regards,
> Ivan
>
> Omnima Limited
> Ivan Ignjatic
> 176 Kennington Road
> Oxford OX1 5PG
>
> Tel. [phone]
> Fax. [phone]
>
> Web: www.omnima.co.uk
> Skype: omnimaautomation
>
>
> _______________________________________________
> eLua-dev mailing list
> [hidden email]
> https://lists.berlios.de/mailman/listinfo/elua-dev

--
James Snyder
Biomedical Engineering
Northwestern University
http://fanplastic.org/key.txt
ph: [phone]
_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev