travisgoodspeed / goodwatch Goto Github PK

The RTC module has a day-of-week counter, but it needs to be configured from the calendar clock. Close this issue when

• The RTCDOW register is properly shown when holding the 9 button.
• The RTCDOW register is properly set when the date is adjusted.

GoodWatch20 boards have been ordered. Close this issue when they safely arrive in Samland.

Because flashing a wrist-watch takes time, and because minor mistakes in power management can quickly murder our CR2016 battery, we will need an accurate simulator to test the firmware. We can build this either on msp430simu (Python) or mspsim (Java).

In the short term, a bit of unit testing and maybe an LCD display simulator might be sufficient. In the long term, we will want accurate models of the clocks and power management, with some mechanism for estimating power drain and comparing the power consumption of separate CPU branches.

Neighbor @cr has volunteered to tackle this issue.

Use this issue to track creation of simple demo application that send, and perhaps receives, Morse Code.

Use this issue to track reverse engineering of the keypad pinouts and close when:

• The cad layout for the keyboard pads is verified to be correct.
• The pads have all been traced and can be wired up to the CPU.

Close this issue when we have good API documentation generated by Doxygen.

Use this issue to track reverse engineering of the LCD pinouts and close when:

• The cad layout for the LCD pads is verified to be correct.
• The pads have all been traced and can be wired up to the CPU.

There's a bug in the modulus math when setting the century. Close this issue when it's fixed.

While a watch development kit can be constructed with fly wires and an old GoodFET, it would be far classier to have a programmer jig that could sit beneath a GoodWatch board to program it or remain beneath it for integration testing or to act as a radio host.

Close this issue when we have such a jig, constructed to match the GoodWatch10's layout. Friction and stiff wires should be used in lieu of pogo plugs, if possible.

Segment 0201 is mistakenly indexed as a decimal point, when it is actually the bottom segment of the second digit. Close this issue when fixed.

Close this issue when the CA53 board component is verified correct.

Assuming that I haven't screwed up power management, the only thing preventing us from actually wearing the watch is that the time is only set over BSL.

Close this issue when the time can be set using the calculator itself. Then we'll flash a board, drop it in a watch, and finally toss out those Casio boards.

We need a stopwatch app with roughly the same buttons as the original. Maybe not a lap timer, because I don't really understand what the hell a lap timer is.

Close this issue when it's complete and sturdy.

Not using a heap does wonders for our stability, but bugs like #29 still cause the device to reboot.

Close this issue when we gracefully crash, by which I mean that the RTC date and time are recovered rather than reverting to the initial time.

We need a calculator application to be a real watch, but all the cool kids use reverse polish notation, so let's do it that way rather than the infix notation of the original.

Close this issue when an RPN calculator is available for the watch.

We need a driver for the RTC_A peripheral that provides a realtime clock and calendar.

Close this issue when the following features are operational:

• RTC counts hours, minutes, and seconds.
• The RTC can be initialized from the host over BSL.
• The clock time can be displayed on the LCD.

Self assigning. Close when these features are available.

Our watch isn't any damned good without some firmware. Use this issue to track the creation of basic firmware, which can be flashed to device to light up the LCD and tell the time.

Close this issue when our watch is telling the time. We'll then refactor to ensure a clean base before continuing with other features and modes. Self-assigning.

The CC430 uses a different BootStrap Loader (BSL) protocol than the classic MSP430 of the GoodFET. I tried using the client from python-msp430-tools, but it has a number of severe bugs, such as incorrect checksums and incorrect error reporting. The protocol is documented thoroughly in SLAU319N.

Use this issue to track development of our own BSL client for the CC430F6137. Close the issue when the client is good enough to load hello world, though a refactor and rewrite will be handy in the future.

Every now and then, by act of god or mistake of soldering, the low frequency crystal might fail to oscillate. The watch will automatically switch to the DCO, displaying the division symbol to indicate the fault. Running POST by holding the 7 button will display an error message to the same effect.

Often, the fault is recoverable, and the watch can be restored without a reboot. Close this issue when that behavior is implemented, so that the POST will fix an errant XT1 oscillator.

We need a website for the public release of the project in January. It'll be arranged to compile statically with the Hugo template engine, deployed to http://goodwatch.org/ with photos and demos of the watch, but source code and documentation will remain at Github.

Whether for a momentary crystal fault, or for @skytee putting while(1){} in a rare branch of the code as a prank, sometimes you need to reboot despite all design intentions to the contrary.

Close this issue when holding the PRGM button for 10 seconds will reboot the watch.

After the GoodWatch10 is verified, we'll need to extend the design with a proper antenna and filter chain in order to make the radio functional. We'll use this issue to track the design, then close it when parts have been selected and the filter chain has been integrated.

Self-assigning this issue, but you two are welcome to join.

Use this issue to track development of an RSSI viewing app. Close this issue when the application is useful and functional.

Now that the radio is functional, we need a method to choose the operating frequency with VFO and a codeplug. Close this issue when we internally have a codeplug in the 512 bytes of Info Flash at 0x1800.

Because we are so strictly limited in size, we should keep things as small as possible. Channel names will be 8 bytes, because that's the size of the display. 3 bytes of the frequency in the radio's native format, one byte for flags allows for 42 channels. Unused channels should be filled with 0xFF, not null.

Modulation, packet len, etc are left to the application. They will not be included in the codeplug entry.

Separate from the construction, we need a small booklet that explains the functioning of the watch. It'll be rendered in LaTeX with separate files for each app.

A "hacking" watch moves the second hand to zero while it is being set. Close this issue when clock.c is modified to make the watch hack.

Close this issue when:

• We have a kernel debug message buffer.
• printf() will write to it.
• It persists across reboots.
• The BSL client will dump the log.

It would also be nice to have an applet for reading the buffer, but that will only work if the log is not very verbose. Later, we'll add support for exporting the log by radio.

The two side buttons are not supported in software. These would be good for setting the time with the keypad and allowing app switching without needing a key on the keypad.

According to the schematic, P1.5 is the mode button (raised) and P1.6 is the set button (recessed).

When the RTC is given garbage values, those outside the legal range, it can fault or revert to hex mode, triggering some very funny times. The POST should check for this condition, and perhaps correct it if that's possible.

We should have an app to view the contents of memory in hexadecimal, showing the 16-bit address on the left and the 16-bit data on the right.

• Interactive hex viewer works.
• Aware of forbidden ranges, it won't trigger reboots.

Replace Johanson 0433BM15A0001 433MHz balun with Anaren B0310J50100AHF 300-1000MHz balun. Same dimensions, almost same pinout (do not connect pin 5 and 6).

It will be pretty damned nifty to have a disassembler built into the hex editor. Use this issue to track its development, and close when it's ready.

--Travis

The CC430's UCS (Unified Clock System) allows for quickly spinning up to a faster CPU frequency, then dropping back down, without changing the rates of the RTC or keypad interrupts. Unfortunately, power consumption scales linearly with CPU frequency, so we need to be DAMNED CAREFUL not to leave it in the high frequency state.

Close this issue when we have a library for convenient reclocking, with the following features:

• ucs_slow() drops the frequency to 32kHz and disables all faster clocks.
• ucs_fast() switches to the DCO at roughly 1MHz.
• ucs_turbo() switches to the DCO or external clock (GW20) at the fastest available speed.

Also,

• clock_init() in the clock application will call ucs_slow().
• LCD indicators will display clock warnings, to ensure that a bug doesn't silently screw up battery life.

Close this issue when all the fancy clocking is ready. We might as well use ucs_fast() in the RPN app.

The self test is supposed to identify clock faults, but it isn't checking UCSCTL7&2. The black watch in this photograph has such a fault, causing it to lose minutes a day.

Presently, we can render hexadecimal to the screen or manually flip segments. Close this issue when we can also draw text to the screen, with a font that's legible even if it requires some training.

Currently, the getchar() function manually polls the keypad to determine which key is being pressed, and some--but not all--apps will debounce this reading to avoid duplicate presses. Unfortunately, while rendering the screen at four frames per second looks fine, sampling the keypad only four times per second is a bit annoying.

Close this issue when we use GPIO interrupts to trigger button sampling, so that we can sample away from frame rendering.

Close this issue when there are matching 3D models to every part.

Now that we have input and output working, we need a task manager for switching between different applications on the watch, such as the clock, alarm and calculator.

• Mode/Program buttons.
• App table, with callback functions.
• Status flags for clocks, power management.

Use this issue to track development of a library for the CC430F6137's RF1A module, which has a similar design to the CC1101. The library should isolate radio events to the active application, including appropriate callbacks and power management. Close this issue when the library is functional and not a risk to power management.

• Gracefully fails on devices without an XT2 crystal.
• Buffered Transmit
• Buffered Receive
• Graceful shutdown in non-RF modes.
• First useful application.
• Morse Code

So the LCD can either run directly from the battery or from a charge pump internal the CC430. I think we've been running directly from the battery, in which case we should either abandon C4 from the BOM or enable to charge pump to provide better contrast.

Close this issue when we understand the charge pumps and voltage selection, and have either rejected C4 or enabled the CC430's LCD charge pump.

The cc430-bsl script has a --password argument, but it is unused.

Close when the script can use a password provided with the --password argument.

The following capacitors used in the 10 and 20 BOMs are both showing out of stock at digikey and mouser:

• CL10A476MQENRBE (Lead time: estimated 6 weeks at digikey)
• 02016D104KAT2A (Lead time: estimated 2 weeks at digikey)

Might want to find some equivalent parts if there's any plans to release this publicly before the end of the year.

We need documentation for how to build a GoodWatch10 board and flash its CC430 with the right firmware. Close this issue when then documentation is in the wiki.

Close this issue when the CC430 chip is properly rendered in Kicad.

• Corners need to be rounded to fit within plastic tray.
• Drill holes are too small for the Casio plastic.
• The 32kHz xtal needs to move slightly to fit the plastics.

Close this issue when layout is complete. See #7 for radio details.

Now that the Codeplug tuning works well, we should add support for typing in an arbitrary frequency.

Close this issue when that works reliably.

The RTC3 errata, documented in SLAZ094V, causes some writes to the realtime clock registers to misbehave. In my case, it is currently causing writes to the RTCDAY register to be missed when first booting. Close this issue when we have a stable workaround that causes all writes to be reliable.

Description:

A write access to the RTC registers (SEC, MIN, HOUR, DATE, MON, YEAR, DOW) may
result in unexpected results. As a consequence the addressed register might not contain
the written data, or some data can be accidentally written to other RTC registers.

Workaround:

Use the RTC library routines, available as F541x/F543x code examples on the MSP430
Code Examples page (www.ti.com/msp430 > Software > Code Examples), which use
carefully aligned MOV instructions. Library is listed as RTC_Workaround.zip and
includes both CCE and IAR example projects that show proper usage. Using this library,
full access to RTC registers is possible.

The RTC on my prototype is drifting by a couple minutes each day. We need to figure out how to trim it, and the proper way to calibrate that trim in a reasonable time.

The hex viewer will avoid some regions, such as the BSL ROM, which trigger interrupts on a read. Unfortunately, other ranges exist, so viewing 0x1b10 or other unlucky addresses will crash the watch.

Close this issue when all illegal ranges have been blacklisted, and also the blacklisting is made explicit, rather than just by a funny constant.

Use this issue to track the PCB manufacturing and initial assembly. Close when the design is complete and we move on to the '11 or '20.