In the last post, I presented the initial ideas for powering the project. Now it is time to move on and start looking into the individual modules. I was impressed as to how quickly this part progressed since I had done the up-front thinking of the pin and port allocation. So much so, that before I knew it I had most of the schematic done making it unnecessary to span the development over several blog posts.
The high level diagram is now looking more complete with the use of hierarchical sheet pins to connect the respective module. This clearly demonstrates the communication between the modules and again, looks very similar to the initial block diagram. It should be iterated that the up-front work of the block diagram contributed significantly to the creation of this section of the schematic. Since I had previously thought out the pin and port allocation, it was a simple matter of aligning the labels on the sheets so that it is concise and descriptive.
The controller chosen for this project is the ATMega88p. I have to admit for no good reason other than I have a development board for this processor and have used the ATMega8 before. Unless there is a significant reason to re-think this decision, I will be staying with the ATMega.
The controller diagram, at this stage, describes the connection of the Serial Peripheral Interface (SPI) bus and interrupts using hierarchical labels. I have also added a pin header for on-board programming. I do need to clarify this further to be sure that this is the correct connection/mechanism for programming the chip on-board.
It has been mentioned often enough that a pre-fabricated module will be used for the Real-Time-Clock (RTC). This is the RTC-DCF from ELV. This module implements a RTC with built in calendar and has also a module to receive the DCF77 signal. When all things are working, then there is no need to set the time on the final clock appliance. It is envisaged that there will be a manual mode for the clock in cases where the signal is not received.
The symbol for the RTC in KiCad is a custom symbol for this module. Though the original kit is mounted in an Arduino shield type form factor, the module itself can be punched out and either soldered onto the application board or, as I envisage, connect it to the application board via a set of 2×6 pole pin headers.
This schematic implements the level shifter mechanism to shift the +5V signal from the controller to a 3V3 signal that the RTC requires. The RTC supports a couple of different mechanisms for communication. In this case, I am opting for SPI. The usage of the signal lines look to double up. This is only because when one communication mechanism is chosen (programmed via a DIP switch on the module) the other lines are used to support the extra interrupt features of the module. For the implementation and features I require, not all connections are necessary. The Tx line, for instance will not be required in this case.
Thinking back on the SysML block diagram, the level-shifter was not clearly visible on the block diagram. It was certainly defined in the model and was specified as the type of port on the 3V3 SPI bus. What is also not clear not the SysML model is that the SPI 3V3 bus requires both Vbb and Vcc to operate since it has to convert the signal between the two.
I am quite satisfied with the schematic so far. More needs to be done on the controller. The interface buttons and switches need to be added. Also some thought needs to go into the housing since four buttons and a switch are already available. What I am proposing requires some additional buttons for the extra features. I am sure my refurbishment of this appliance can include some modifications. At this stage, I don’t see it a major problem to add these at the back of the housing.
The next significant module is the display module. I have some initial thoughts on this but will save that for a future post.