Dealing with multiple uncoordinated inputs

cpedw

Senior Member
I'm trying to develop a "Dawn Simulator " clock using an MSF receiver for the clock with an OLED 20 by 4 display and PWM of a halogen bulb simulating dawn at the set time.

I have succeeded in getting the time using this module http://universal-solder.com/product/60khz-wwvb-atomic-radio-clock-receiver-replaces-c-max-cmmr-6p-60/ and Hippy's software, post 36 here http://www.picaxeforum.co.uk/showthread.php?11334-Decoding-UK-s-NPL-MSF-Time-Signal/page4

For that to work, it needs a Picaxe constantly monitoring the clock data. But the overall system needs to be able to adjust the alarm time; I think 3 push button inputs will serve here.

Then we also need a PWM output to slowly adjust the bulb brightness.

I tried to use 4 bit driving of the OLED (AXE134) but it seems that isn't possible with the West European Table 2 font - which I'm using to help draw big numbers (2 and a half lines high).

I have concluded that I must use at least one other Picaxe in addition to the 18M2 with the display. But how best to read the MSF time while keeping the display up-to-date, being available for alarm time adjustment and driving the PWM output? Will I be able to do all that with just one other Picaxe? How best to manage the different inputs? What's the best way to interface between Picaxes? Or can anyone suggest how I could fit all these functions into the 18M2 of the OLED?

I expect there's more than one answer; I'm most interested in the simplest!

Derek
 

geoff07

Senior Member
PWM doesn't need to be updated unless it changes (it is controlled by a separate peripheral in the chip, once set up). So you have an event-driven system, where the events are the time and the push-buttons, and the outcomes are the display and the pwm duty. Each can be sampled in turn until the time or the buttons change, then process the change and keep scanning.

There are different ways to be simple. Mine would be to have simple code at the expense of hardware, so thus one 08m2 to receive the time, and one to manage the buttons, the light and the display based on the time, and then the display itself. Three chips but each with a defined task. Merging them would be possible with more complex software but then the larger chip would cost more and debugging would take more time. Suitable maybe for mass production where development cost is spread but not needed for a one-off.

The interface between them is simply the serial commands to the display and maybe a serial message from the clock chip that interrupts when the time changes. You can send a serial message and have that trigger an interrupt which then reads the serial in the isr quite easily, so no need to scan the clock.
 

cpedw

Senior Member
Thanks geoff, that all sounds comendably simple and manageable to me. One bit, before I get stuck into the harsh reality, that I don't follow is "isr". Will the transmitter do a bit of handshaking to get the receiver listening; I can see how an interrupt might handle that, though if 2 transmissions clash there might be a problem. I suppose that prioritising one could force the other to wait until the first has completed. Does that sound about right?

Derek
 

geoff07

Senior Member
the isr (jargon) is the interrupt service routine, i.e. the INTERRUPT: subprogram at the end of your code. It runs invisibly to the rest of your code. So if a chip sends a message that is read by the isr, it can update a value and then exit. The main program loop can look at the value and if it sees that it has changed (e.g. the time) it can then do something. But the main code need not worry about how the new info got there. This is all handled by the firmware. All you do is code the isr and code the main loop. The relationship between them is magic.
 

hippy

Technical Support
Staff member
It may be possible to have a single PICAXE running all the main code and doing everything with MSF read and handled by interrupts.

That may require using the on-chip timer to determine how long between MSF going high and low or one could perhaps interrupt with an X2 at say a 250ms rate, sample the input, put that in a simple word variable acting as a bit FIFO and have the main program handle that.
 
Top