openchronos-ng

I just pushed a new patch into the BUTTONS branch which mainly implements: More responsive button input. No more long button presses for STAR and NUM buttons, use STAR+UP and NUM+DOWN respectively instead. Support for continuous (auto-repeated) button presses. Please let us know if you like the changes. For the non-lazy, see the commit log

For those of you following the development of openchronos-ng, we got some feedback from users at our IRC channel, saying that sometimes they could not flash the watch over RF (rfbsl). They also said this didn't happen with original TI's firmware. ... [More] Since sometimes we also have been unable to use rfbsl, I figured out that it was probably because the wireless updater didn't have enough RAM to store the firmware image. This makes sense because openchronos-ng uses more RAM to minimize the overall (RAM+flashmem) usage. So basically I ended up doing the following things, which are already available in the testing branch: Renamed the rbfsl module to reset module. As it name implies, this module only has one function, to reset the watch. When the watch is reset (or applied power for the first time, from battery etc..) instead of going directly into the main openchronos-ng menu. It displays BOOT in the screen. At this boot menu you can do two things: If you press the backlight button, you will enter the wireless updater mode. If you press any other button, you will get the regular openchronos-ng menu. This fixes the memory problem referred above because at boot we do not have anything allocated in the heap. Also, it is very handy if your watch crashes, because you will be able to still use the wireless updater instead of having to disassemble the watch.. [Less]

Hello everybody, The openchronos-ng team has the pleasure to announce that the development efforts to replace simpliciTI with another wireless stack have already started. The new stack, called [swap](http://code.google.com/p/panstamp/wiki/SWAP). ... [More] What is swap? The Simple Wireless Abstract protocol is a simple protocol that enables mesh-like wireless functionality using a very low firmware footprint. The current implementation of the swap stack in openchronos-ng takes only a fraction of the simpliciTI size on the firmware. Swap was developed by Daniel Berenguer, the guy behind the [panstamps](http://www.panstamp.com/). Daniel already had a implementation of the swap stack for the ez430-chronos which was later fine-tuned by Paolo Di Prodi. We are in the process of integrating the wireless stack into openchronos-ng. For more details, have a look to the swap git branch. In a nutshell, the new wireless stack will take considerably less space in the firmware, the code is cleaner and easier to read, the stack will also be protocol compatible with the panstamps and many other commercially available devices. My favorite will probably be the ability to enumerate device properties remotely, in other words, you will be able to enumerate all ez430-chronos properties (time, accelerometer data, etc..) in your computer using a user interface that is common to all other swap enabled devices. For more information about swap on the ez430 chronos, have a look [here](http://panstamp.blogspot.fr/2011/06/openchronos-is-finally-swap-enabled.html) However there are three important drawbacks 1) The swap stack will not work in the 433Mhz ez430-chronos versions. Unfortunately this doesn't have a solution. 2) The access point bundled with the ez430-chronos will not be able to communicate with a swap-enabled version of the ez430-chronos. Currently, the openchronos-ng team is using a panstick+panstamp (offered by the panstamp team - thank you!) to make computer chronos communication. People willing to help development or just test the swap enabled openchronos-ng will have to buy a panstick. However, it is not our objective to force openchronos-ng developers and users to buy panstamps. For that reason, we are going to develop a new firmware for the ez430-chronos access point, that supports the swap stack; allowing communication between the swap enabled ez430-chronos and access point again. The good news is that we already managed to find the source code for the access point dongle (it is publicity available), which will make our task considerably easier. More news on this will come in the future. 3) The swap stack does not support wireless updates. In fact, neither did simpliciTI. The wireless update is a binary blob made available by BMi which is flashed into the BSL memory of the ez430-chronos. Regular flashing of the ez430-chronos with openchronos does not touch this memory region. On openchronos, the wireless update is executed by simply jumping into the BSL memory address. The ez430-chronos access point firmware then supports simpliciTI and the wireless update mode (which is also a binary blob in the AP source code), using the corresponding wireless stack if the AP is in sync or flash (rfbsl) mode. We will need to evaluate if either: a) it is feasible to add support for our own wireless update routine into the swap stack. b) we keep using the binary blob in the BSL memory of the ez430-chronos and we reflash the ez430-chronos access point with swap+rfbsl support. Leave your ideas and questions in our mailing list. Angelo Arrifano and Paolo Di Prodi on behalf of the openchronos-ng team. [Less]

Hello everybody, First of all excuse my poor blogging ability because honestly this is the first time ever I'm writing to something resembling a blog. Now straight to the topic, I just [pushed a ... [More] commit](http://sourceforge.net/p/openchronos-ng/code/ci/5a5a59123cf8e4aba55d02671b841c71b29fa419/) that introduces a very cool feature. Basically it introduces virtual screens. What is a virtual screen? A virtual screen is a pointer to a memory region created by _lcd_screen_create()_. You can pass that pointer to all of the display functions: display_symbol() display_char() display_chars() display_clear() when you do that, the data is not actually written to the real LCD memory but to a dynamic memory region. If you want to directly write to the real screen, just set the screen parameter of any of the above functions to NULL. You can also copy, at any time, the contents of a virtual screen into the real screen and vice-versa, using the _lcd_screen_virtual_to_real()_ and _lcd_screen_real_to_virtual()_ functions respectively. You may now ask, alright but why do we need this? Suppose you are developing a module which uses the num button to switch between several "screens". An actual example is the clock module, where in the first screen it shows the time, day and month and in the second screen it shows the year. As I was implementing that functionality, I realized the code was getting too complex. I started wondering if there was a more efficient way of doing it and here we are! If you look to the clock module, where I'm already using this functionality, you can see that two virtual screens are created. Each virtual screen saves both segment and blinking information. So I actually display stuff in the two virtual screens (time, day and month in screen0 and year in screen1) without worrying which screen is actually being shown. At each point where the real screen actually needs to be refreshed, I just copy the contents of the "active" virtual screen into the real screen using _lcd_screen_virtual_to_real()_. Now some technical notes: Each virtual screen actually takes 24bytes of memory. It might seem a lot but if you consider the size of the code that you would actually need to write to handle the cases where these functions are meant to be used, I'm pretty sure the size of the code you would need to write would be way bigger. Hence we are saving flash by using a little more RAM. One final note for those not familiar with openchronos-ng: Openchronos-ng doesn't have the "two independent menus" functionality anymore. We found that its implementation made the firmware bigger than it was worth. So at openchronos-ng we actually only have one menu where modules (applications) can use the entire screen. [Less]

Well, we just moved to SourceForge, and we are quite excited about that! Just finishing setting everything up, we still have to come up with a nice logo and enrich the wiki pages. But we got the doxygen API working, and code is imported! We still need to create a nice website ;)