The Main Board

I created the main board in the same pattern as the original. That made for quite an expensive prototype as there is a lot of empty space. This size is needed to fit the tactile switches in their proper places. Now that I have Revision 2 up and running, a write up of what I have learned along the way is over due.

The assembly was not without issues. There were some lessons to learn with KiCad and circuit design and layout as I did make some mistakes but I was able to identify the issue and make some corrections. Here are some of the things I picked up along the way

Check the pin outs

This might sound like an obvious thing and it hind-sight, it was. Complacency crept in on more than one occasion and I did not verify the pin allocations between the datasheet, symbol and footprint for the linear regulator. As it was a three pinned device, I only needed to reset it and run a bridge to ground.

LEDs

I did not factor any indicator LEDs on the main board. While this is not a mistake, the addition of an LED to blink to show that something is happening is well worth the few seconds it takes to model it in the schematic and layout.

Don’t leave GPIO pins unconnected

This is just to say for any prototyping board, it would be worthwhile to expose any spare pins to headers, and or coupled with 0Ω resistors. When troubleshooting, you never know when you might need something. Of course in the production board, these would not be populated.

Getting Things up and Running

Heartbeat-Bodge-bOnce the power rails were reading the correct voltage, I connected in the RTC module. This fired up OK. I.e. Its LED lit up for a second. This is when I realised I was missing a heartbeat LED. I simply connected a piece of through hole lead to Port B0. This was the output that was configured as the heartbeat on the myAVR development board.

 

Using the procedure I used for the previous boards, I tested the connection between the PC and the AVRISP mkII using the Atmel Studio. If I could read the serial number of the micro, then I knew I was in good form.

SystemTest-01b
Main Board and Rev1 of the Display Module

I flashed the program I was using on the myAVR Dev board. Straight away the heartbeat started pulsing. Another good sign. The display did not react, or when it did, it was with garbage.

The issue with the display module as due to a mismatch between the main board and the display module. Since communication was OK to the RTC, I could assume that the SPI was largely OK. The obvious place the issue would be was with the actual signalling and or timing.

This issue has kept me occupied for some time. The biggest help was the Salea Logic Analyzer. To be able to capture the signals and have the digital values interpreted is a huge advantage. I could read the values being sent to the clock and display to ensure they were correct. I was able to tweak the code so that I could match the SPI specifications described on the RTC datasheet. I used this as a base to then configure the display module. Everything started to fall into place then and the display was more stable.

I found that to get the flexibility out of BASCOM, I needed to set up the Master i.e. the main board using software controlled SPI. Whereas, I could simply rely on the hardware SPI for the slave (display board).

Main Board SPI Setup

Fir the main board, the software controlled SPI was preferred since I could then use the SS = None property on the configuration. I then had to allocate my own chip-select lines for each of the RTC and the display module.

Config Spi = Soft , Din = Pinb.4 , Dout = Portb.3 , Ss = None , Clock = Portb.5 , Setup = 40 , Mode = 1

Display_ss Alias Portb.2
Config Display_ss = Output : Display_ss = 1

Dcf_ss Alias Portb.1
Config Dcf_ss = Output : Dcf_ss = 1

Spiinit

Display Board SPI setup

The key to the display board setup was to use the Master = no to ensure that this would be configured as a slave. All pin allocations were as per the datasheet for the micro controller.

Config Pinb.4 = Output
Config Pinb.3 = Input                                       ' MISO
Config Spi = Hard , Interrupt = On , Data Order = Msb , Master = No , Polarity = Low , Phase = 0       ' , Clockrate = 128

Spiinit

On Spi Spi_isr                                              'Nosave

In principle, things were good. I know I can flash the display module and I know I can flash the main board. I also know that communication is happening between the main board and the RTC.However there is still a niggling problem between the controller board and the display unit. After a while, the data seems to get out of sync and the display starts to display wrong values. SignalToDisplay Examining the SPI signals, I could be satisfied that the data presented and received by the display module is correct. There is something else happening inside the display module that is causing the information to be gabled. This is where I am reaching another boundary on my tool-set. The myAVR and the AVRISP MkII do not support any debugger. This is a set of tools I have yet to expose myself to and learn. Thinking around the problem, I am sure that this is some type of synchronisation issue. The actual cause, I can’t be sure. One thought would be some interference with the interrupt service routines. Since the data presented to and received by the display module is correct, I am willing to exclude the actual controller from the equation, for the moment. The problem has lead to some optimisations on the display module. One of the first improvements was seen when removing the NOSAVE from the On spi Spi_isr statement. This reduced the Spi_isr down to the following

Spi_isr:
   Set Rbit
   Mosi = SPDR
Return

The same routine as described in a previous blog entry also contained logic to arbitrate whether the incoming data was a register address or a value for the register. in fact, this was always a concern. How to reliably determine the name from the value. The very first entry after start-up is going to be an address. After that, if something happens to the timing, it is not so clear cut.

After trying several ways to analyse the problem and make changes that were not always successful, I have determined the most effective way would be to flag the address. This means the API to the display module has now changed such that the first byte send to it, as address, must have the most significant bit set. This is a major improvement on reliability, but still no solution!

Do
   If Rbit = 1 Then
      Reset Rbit
      Spdr = Mosi

      If Mosi.7 = 1 Then
         Idx = Mosi And &B00001111
      Else
         Register(idx) = Mosi ' Assign the data to the register
         Select Case Idx      ' Based on the register/value, set the affected variables
            Case Hours_10:
               Digits(1) = Register(idx)
       ...

There are still some issues to solve with this. For the above change, the controller board was not considered. However, the problem now comes back to the controller board to understand what the interaction is between the RTC, the controller board and the display board really is. Only once in a while at the transition of a minute, the display will be corrupted for a second or two. This does not happen often. Perhaps three to four times in an hour. But it shows there is still some form of timing race condition happening.

Where to from here?

I am happy that the communication is happening but I can’t call the job complete as there are some odd issues still persisting. I could work around them by sending only one byte rather than two so that the high end nibble is the address and the low end nibble is the value to be set. This would work for most of my values, but no all. Besides – that would be a work around and not a solution. I need to find a way to better understand what is happening with the data between the RTC, main board and display module such that the display modules register address and values are being skewed. At least that is my current understanding of the issue.

 

 

Back to the Drawing Board

Well, not exactly back to the drawing board for everything… What has developed since doing the actual schematic is that the display module was treated as a black box. Now it is time to open this up and understand how this is to work. The beauty of this approach is that not knowing anything about the display module has not held me up on the other, simpler aspects of the project. This module is possibly going to be the most challenging. There are several dynamic elements to it and it is also going to be the module that will draw the most current. So far I have indicated that this module will be supplied by Vbb i.e. +5V and will be interfaced with the controller via a SPI bus.

The first challenge is which direction to take this. I find myself at a bit of a cross roads. Searching the internet for a suitable example as a starting point, I see there are already 7-segment display driver from Maxim i.e. Display module - MaximMAX7221. The advantage here is that it provides many features that make the implementation of a clock display relatively simple.  I have quickly put together the block diagram that shows the intended implementation. It seems I could use the fourth and fifth digits to drive the colon and auto-time and alarm enabled indicators. The implications on the driving current need to be ratified.

The down side is the cost and the power consumption. It would mean rethinking my use of the MCP1703T-5002E/CB as the main regulator since this is limited to 250mA only. In reality, for practical purposes, even 250mA is to high for an appliance that is expected to be running 24×7 such as a digital alarm clock.

The alternative to using the display driver is to implement this myself. The advantage there is I am free to introduce what behaviour I need for the module to work within this project. The disadvantage is additional complexity in firmware updates. There will be two micro-controllers to contend with. At this stage, I have not done any calculations to see if there would be a saving in cost or power drawn by going the home-made route.

Display module - Controller

The block diagram for the micro controller based display module is very similar. The micro controller is used to replace the behaviour of the display driver chip. Although an ATMega88 is depicted here, any suitable i.e. low powered micro controller would suffice. As long as the duty cycle on the LED segments and indicator lamps is enough to provide a clear display.

Where to now?

Since I am at a cross road, the best way forward is to try things out. This is probably not good SysML practice since the design is not actually complete. But prototyping must be considered a part of design. I don’t have enough information to make a sensible decision as to the direction. The best way forward is to implement a prototype of the two possibilities and make the best choice from there. In this case I will be able to measure physical performance and power consumption and not relay on theoretical calculations.

Wired for Action – almost

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.

sch-top-02The 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.

Controller

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.

sch-controller-01

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.

RTC Module

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.

IMG_1054The 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.

sch-display-01

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.

What’s next

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.