Introducing modular openchronos (candidate for openchronos-ng)
Angelo Arrifano
Since I saw quite some movement lately in the mailing list, I thought
it was the best time to introduce the modular development of
openchronos done by me and Aljaz.
The experimental tree is at the *modular repository* in the *display branch*:
https://gitorious.org/openchronos/modular/trees/display
In a small summary, this is what have been accomplished:
* Removed A LOT OF CODE, the firmware is considerably smaller.
* The display, timer, menu API etc.. were greatly simplified.
* Have a working RTC API (no more inaccuracy in time keeping).
* Modular design: sources can simply be added/removed into/from the
modules directory without having to hack other source files.
* A new reworked build system which is faster.
* High power savings due to reworked display API.
* Single menu: We got rid of the two menu system, it made the code
more complex, make firmware larger and for these reasons we thought it
was not worth having it.
For more information see here: (ignore the display and menu sections
since they already have been implemented)
https://gitorious.org/openchronos/pages/ModularDev
For now, only the clock, alarm and wireless update are working. If you
are interested in helping please drop us an email. We need help
porting the remaining modules into the new framework. Mind you that
you need to be familiar with the openchronos code in order to help.
Thanks
--
Angelo Arrifano AKA MiKNiX
Doctorate at the I3S Laboratory / CNRS - France
Doctorate at the University of Beira Interior - Portugal
http://www.arrifano.com
PGP Pubkey 0x3D92BB0B
Paolo Di Prodi
Could you at least port the accelerometer module so that I have an idea about the usage
of the display functions.
After that I could also integrate the features I wanted like logging acceleration
while in time mode etc.
The code now looks better and cleaner.
I am working now on free fall and activity detection which are not supported in the driver section.
Cheers.
Dr. Paolo Di Prodi
Angelo Arrifano
I'll work on porting the accelerometer module then. For now have a
look at the date and clock modules since they already implement the
new API.
I'm going to try to provide a quick explanation on my work with Aljaž:
*basically it worked like this before:*
1) A module (logic/*.c) receives execution by user input (menu) or timer event.
2) If the module needs to update the screen, it then sets the global
display flag.
3) Execution goes back to the system.
4) Before going idle, the system calls the display_update function of
the module.
5) The module then updates the screen.
An exception to this would be the user setting values (for example,
setting the alarm using up/down buttons). This functionality was
provided by a ugly workaround (set_value() function in user.c) that
steals execution from the system while the display is in "setting
mode". There were also other ugly hacks like calling the update_time
function (from timer.c) in rfbsl.c
*now it works like this*
1) A module (logic/*.c) receives execution by user input (menu) or timer event.
2) If the module needs to update the screen then it should check if it
is active (the user selected it in the menu)
3) Execution goes back to the system.
Every module can update the screen as many times as they wish. For
example, the clock updates every minute, the date only updates when a
day or month digit changes - this is optimal for power savings. An
accelerometer, for example, can potentially update every half second
or even more frequently.
Since we got rid of the two menu system. Every module is free to draw
in the first or second row. A module can also touch display symbols
(like hear, R, wireless ...), however it *must* save the symbol state
when the module is activated and restore it when being deactivated
(there are activation and deactivation callbacks for every module, see
the source for more info).
For setting values, there are no workarounds. The module just needs to
call a function (I don't remember its name right now) which gives
execution back to the module when the up/down/set/cancel buttons are
pressed during the "setting mode"
I wrote this very quickly without looking at the actual code so pardon
me if the terminology does not match.
Let me know if you have any questions.
- Angelo
Andrey Ulanov
with best regards, Andrey Ulanov.
Aljaž Srebrnič
Just tried it: awesome! module API is really clean and simple, much better than before.
I primarily use my watch as skydiving altimeter so I'll work on porting the altimeter module.
michael gindonis
I have run into some problems. When I have time I will post more details.
I have compiled the latest mspgcc from sources ( April 2012 release).
I'll try it again with the Fedora packaged version.
...Mike
Regards...
...Mike
---
Michael Gindonis
Email: firstnam...@gmail.com
Aljaž Srebrnič
> Is anyone using mspgcc to build this?
>
> I have run into some problems. When I have time I will post more details.
> I have compiled the latest mspgcc from sources ( April 2012 release).
> I'll try it again with the Fedora packaged version.