Revisiting an old project

Some Background

TheOldDeviceI recently had the opportunity to revisit an old project of a doorbell extension that
used the ELV FS20-S4SUB to send a signal to the ELV FS20 SIG-2. At the time I did this with what I knew at the time to get the job done with the equipment I had. This meant nothing too sophisticated. Pretty much off the shelf modules for the “ELV Universal-Spannungsreglerplatine Komplettbausatz” as DC power supply, a 8 DIL 555 timer as a one-shot mounted on vero board. It certainly did not look nice and I knew there would be a better way, but it worked.

In this original implementation,  I had to go to these lengths of using the relay and oneshot as I found connecting a relay directly to the doorbell switch to drive the FS20-S4SUB was not reliable and needed a way to denounce the press button as well as being on long enough to trigger the FS20-S4SUB.




After four years of working without a hitch, this project was brought back to my attention, so I decided to redo this with what I know now. The major criteria is that I should not spend too much time on this. I had two choices 1) Go with with I have already done 2) move to an embedded solution. While 2) could be fun and would be more compact, I decided on option 1 since I could reuse the ELV FS20-S4SUB, which was still serviceable. All I needed to do was model the existing solution in KiCad as a single board.

New Design

As shown above, the existing solution was based on relays. I didn’t  want to bring these forward into the new design. There is an interesting solution put forward in ELV 06/2014 whereby they implement a door bell sensor by feeding the rectified signal into the base of a transistor (pins 1 and 3 of P2). Their solution also provided an addition possibility by sourcing the voltage as well so that a stand-along press button could be used (pins 1 and 2 of P2).


Here most doorbells are powered by a transformer delivering between 8 to 12V. So this system was designed sense the voltage from the doorbell button whereby the device itself is battery powered and the doorbell system is sourced by a 12V transformer. In my case I would be powering the device from the same transformer as I have done in the original solution, thereby saving the need to change batteries.

The part that was bugging me was the interface to the FS20-S4SUB. My first approach to this problem was to simply use the same reed relay. But in examining this set up, I started to have doubts about what I was actually doing in the original design.

My first problem was the power. The transformer is delivering about 15 Volts without load. I originally had set up the DC power supply with a LM7812. Everything worked fine, but in this design, there is no room for any error or movement. Something I had not considered before. After speaking with my tutor, Chris Gammell of Contextual Electronics, he confirmed the doubt. Under load, if the transformer voltage would go below 12V, there could be a chance of a “drop-out”. He suggested bringing the supply voltage down to 9V, which would be more reliable. The main reason for sticking with 12Volts was the availability of cheap reed relays. I had trouble finding anything for 6V. Chris suggested the use of an Opto-Coupler in place of the reed relay.

Choosing the Opto-Coupler

I decided to embrace the Opto-Coupler suggestion since it would solve the power supply issue. But I had to familiarise myself with Opto-Couplers where I have never had reason to implement one before. The FS20-S4SUB has five wires. One Ground and four inputs, presumably open-collector with internal pull-ups. The problem now was finding a suitable Opto-Coupler. The resources I was finding on the web all seemed to be from the perspective of driving some load through the collector-emitter side and would then base their calculations on that current flow.

Placing a DMM across the contacts, I see 2.9Volts @ 0.03mA. It seemed to me that I could place almost any Opto-Coupler there. I decided to take the selection the other way. I intend to drive the LED at 10mA (though the rated maximum will probably be 40mA). From that, I need to only ensure 0.03mA can be seen at Ic, I figured a current transfer rate of 50%@5mA will be more than enough.

Interestingly enough, this criteria ushered me to the LTV-817S, which I had been seeing in lots of places as a standard, easily available part. So I presumed this to be a good place to start.


The circuit above shows the implementation I will be using. The 1KΩ R11 is used to limit the current to the LED. The 10kΩ R12 is used to pull the value on the LED down to ground when not active. R13, which is marked as “NO-POPulate” is there was a “Just-in-case” 0Ω or Jumper in case I may need to tie the FS20-S4SUB ground to the system ground.

putting it all together

I took the liberty of compiling what were separate modules onto one board to create a self-contained solution and minimise its overall size. The layout below shows the remodelled DC Power supply, using a bridge rectifier and a LM7809 based on the ELV DC power supply, the One-shot trigger, using a SMD 555 timer and instead of the reed relay,  the LVT-817S is used. Instead of the bulky relay as seen in the photo above, will be the door bell sensor as showcased in the ELV HomeMatic®-Funk Klingelsignalsensor. Some additional enhancements that were not included on the original design are some test points for verifying the behaviour and an indicator LEDs to indicate power-on and to show when the FS20-S4SUB should be sending its signal.

Revision 2

The Gerbers for the board was sent off to OSH Park and a couple of weeks later, The first set of prototype boards arrived. I ran into a small issue with my footprints. This has happened before where a I model the footprint as per the data sheet. However, there is a margin of error in the holes required for the leads and a margin of error for the holes drilled by OSH Park. Neither are wrong. It is just that one should take that into account and model the holes on the larger side. As it was, it was not too bad since I could solder some leads in the holes for the rectifier bridge and solder the rectifier bridge to the leads. The result looked quite neat.

Bringing the board up went smoothly and all aspects of the device tested out fine including driving the FS20-S4SUB through the Opto-Coupler.I was confident with the board that I proceeded with the second and final revision – the layout is shown above.

The connection of the device can be configured in a couple of ways which was a offshoot of using mechanism provided in the door bell sensor. However, I was only intending to use the configuration where by I power the system from the existing doorbell transformer and only need then the return wire from the actual doorbell switch.



I found an appropriate case which happened to fit the board just nicely. Since I was using SMD LEDs for the indicators, I had the challenge of trying to work out where I should drill the holes for the Light-Pipes. I then decided to sacrifice a couple of the light pipes. Since Osh Park send three boards, I took one of the spare boards and hot glued the light pipes to the footprint location for the LEDs. I then coloured the tops with some ink and placed the cover in place. This provided some marks on the inner side of the casing and a closer than rough indicator as to where to drill.

The end result I considered was very good. The light pipes pick up the individual LEDs very well. I have put aside the light-pipes that I used to locate the holes in case I need them again one day.


I have now the completed board and the FS20-4SUB neatly in the casing. I shortened the leads for the GND and TA1 on the FS20-4SUB but I still don’t have the heart to cut back the leads for the unused channels.


It was a lot of fun and very rewarding to revisit this old project. It is especially rewarding to compare what I knew then to what I have learned since then.

One of the goals was to see how quickly this could be completed. The first commit on Git-Hub was June 5, 2016 and I am writing this 49 days later (1 month, 2 weeks and 5 days), I did not record actual time spent on the project. I will leave that discipline for another project. This time includes the turnaround for two revisions of the board. Going through the BOM and adding up the parts used in the final device, the cost comes to 19,09€.

One Year of Contextual Electronics

Before Contextual Electronics, I knew I wanted to get back into practical electronics, after a very long break. But I still had a lot to learn or re-learn. My study days left my head spinning trying to grasp operational amplifiers with two or three pages of algebra and still did not know exactly how they are applied. So the whole thing was a little daunting. I found gEDA and tried using it. It was not very stable, even on Ubuntu and then It was in December of 2014 that I came across KiCad. This is also when I discovered Chris’s tutorial, “Getting into Blinky”, the AmpHour and of course Contextual Electronics. So I signed up January 2015, not knowing where it would take me or if I could even keep up. Reflecting back, my goals were to understand better how to implement components like transistors and op-amps etc. Particularly to take a design from schematic to PCB. Local Fabs (Germany) are prohibitively expensive, so I was after any tips I could get along the way.
When Chris announced the Roll-With-It project, I had a small panic attack. I wanted just to learn how to implement a transistor correctly and now I am supposed to build a tele-presense robot? So that is where my journey began. Since January 2015, I have been part of the subscription based Contextual-Electronics and have seen it change its appearance and evolve to the current site. I don’t know if it has always been subscription based but this works well for me. I am liking the “workshop” approach to the projects as opposed to a fixed time period school-term like approach.

In terms of ticking off goals achieved, that list is much larger than when I started. Over the last twelve months, I have learned about applying an op-amp (yay!) and even a comparator. I have learned about PCB layout and where I can get them created for a reasonable price. I have also learned about SMD and how to solder them by hand and now using reflow. I think one of the biggest lessons is prototyping though board design and not necessarily with bread or vero board. Other things added to the list are In System Programming of micro controllers i.e. outside the safe-haven of a dev-board such as Arduino. These things I would not have dreamed of twelve months ago.

Now we are starting a new year and can think about “what would I like out of Contextual Electronics?”: The direction of the course seems to be heading towards a more micro/digital based. I was probably expecting more of an analog component. However, when everything that is published is interesting, relevant and seems to just flow with the ultimate goal in mind (Roll-With-It), the question of what do I want from the course become a difficult question to give a direct answer to. The work by Ron and Eric providing professional instruction in Embedded system design and coding has given the course a whole new dimension. I have not taken the opportunity to work through the material properly but that is a goal for 2016!

The journey with Contextual Electronics has been a very inspirational one and the support from Chris has been motivating. I probably would not have gotten so far with my own project without his encouragement – I certainly would not have started a blog on it! So it has been an a amazing journey, though I now have to say, I don’t remember what I did in my spare time before Contextual Electronics, as there seems to have been little time for anything else 🙂

I look forward to 2016 and our first CE all-in, live, tele-seminar with our RWIs.

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.


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.

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


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


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

   Set Rbit
   Mosi = SPDR

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!

   If Rbit = 1 Then
      Reset Rbit
      Spdr = Mosi

      If Mosi.7 = 1 Then
         Idx = Mosi And &B00001111
         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.



Further testing the μController Display Module

In the last post, I was able to get the μController version of the display module working with a basic test routine that proved that 1. the controller could be programmed and 2. the display was being driven correctly. The next stage is to flesh this out to replicate the MAX2771 API. The purpose here is not to simply create a duplicate of the MAX2771 which does a great job on its own. This approach means that I can re-use the code I created for the MAX2771 display module project. The additional goal of this small project was to gain experience in creating a SPI slave! Interfacing with the MAX2771 was simple since that is already a SPI slave unit. All I needed was to just create the master.

Connecting things together

I still have things set up from the previous tests so it was just a matter of connecting things back up again. Though this time I had two units to program instead of just one. I still have the main controller board for the clock to complete so I used the myAVR Dev board as a provisional main controller. Luckly, the myAVR dev board comes with its own programmer. I had to program this via the myAVR ProgTool since the BASCOM-AVR IDE was in use with programming the display module via the AVRISP mkII. It sounds more awkward than what it turned out to be. The part that was awkward was that the AVRISP mkII had trouble programming the display module while the SPI connection was still made to the myAVR dev board (my provisional mainboard). I had to disconnect the /SS, MOSI and CLK from the display module before being able to program. This would be a point of research to work out what is involved to be able to program the display module while still connected!

μControlled Display Driver Integration Test
μControlled Display Driver Integration Test

Once the infrastructure of programmers and connections was sorted, it was just then a matter of piecing together the code to enable the slave unit to start servicing the requests of the master i.e to start displaying the time. With the Real Time Clock still connected (via an I2C bus) I had a neat source of test data.

Getting thing up and running was rewarded with a red blinking LED on the dev board. This was my signal that the communication with the Real Time Clock was functioning. The next was the display module itself.To keep things simple,  I am opting to use the basic BASCOM constructs for SPI. The logic analyzer was useful for seeing that the SPI messages were being sent. Though my particular logic analyzer only shows that there was activity. It lacks the sophistication of being able to see exactly what was being sent. Thankfully, I have been able to get things working without that level of sophistication.


Creating the Slave

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

On Spi Spi_isr Nosave

Enable Timer0
Enable Timer1
Enable Interrupts

The snippet above shows how the slave was defined. Basically I used the same construct in the master. The “Master = yes” property is the only difference. Once data is available for the slave to read, the spi_isr interrupt routine is executed. Here I just grab the data into a Regisiter array. The API I was wanting to implement was to read a two byte command i.e. a register address and then a value. I was not sure on how this is to be done since BASCOM-AVR documentation only really talks about receiving one byte at a time for slave. In comparison, sending multiple bytes from the master is not difficult at all.

   PUSH r24    ; save used register
   IN r24, SREG; save SREG
   PUSH r24
   Set Rbit                         ' we received something
      If Spi_idx = 0 Then
         Idx = SPDR
         Set Spi_idx
         Register(idx) = SPDR
         Reset Spi_idx
      End If
   POP r24
   !OUT SREG, r24 ; restore sreg
   POP r24       ; and the used register

Here I had a variable to track which element of the command was being received spi_idx. When reset, then the first value from the master is expected and therefore that value is recorded as an index value i.e the register address. When spi_idx is set, then it is expected that the value from the master is the register value and that is then directly recorded in the Register array.

With the register address and value for the register obtained from the master, then it was a matter of interpreting the newly arrived information. I implemented this using a case construct.

   If Spi_idx = 0 Then
      Select Case Idx
         Case Hours_10:
            Digits(1) = Register(idx)
         Case Hours_unit:
             Digits(2) = Register(idx)
         Case Minutes_10:
            Digits(3) = Register(idx)
         Case Minutes_unit:
            Digits(4) = Register(idx)
         Case Colon:
            Digits(5) = Register(idx)
         Case Indicators:
            Digits(6) = Register(idx)
         ' Case Intensity:
         ' Case Power_mode:
         Case Digit_blink:
             Blink_mask = Register(idx)
         ' Case Blink_rate:
         Case Test_mode:
            If Register(idx) = Enabled Then
               Digits(1) = 8
               Digits(2) = 8
               Digits(3) = 8
               Digits(4) = 8
               Digits(5) = 8
               Digits(6) = 8
               Digits(1) = 0
               Digits(2) = 0
               Digits(3) = 0
               Digits(4) = 0
               Digits(5) = 0
               Digits(6) = 0
            End If
         Case Else
      End Select
      End If
   End If

The idea here is to simply  react if there is a new value arrived. Based on the value of idx (the register address) to then assign the value from the register to a variable that will result in the desired behaviour. i.e. setting a digit value etc.

One feature I have implemented that is not part of the MAX2771 API is a Blink feature. i.e. to enable a digit or colon to blink. I managed this with a mask with one bit for each element of the display. This seems to work quite well.

   Timer0 = Timer0_count
   Incr Position
   If Position > 5 Then
      Position = 0
   End If

   Digit = Position + 1
   PORTD = &H0A          ' Set all segments off
   PORTC = Makebcd(position)

   Blink_test = &B00000001
   Shift Blink_test , Left , Position
   Blink_test = Blink_test And Blink_mask
   If blink_flag = 1 and blink_test > 0 Then
      Value = Digit_off
      Value = Digits(digit)
   End If
   PORTD = Value

Next Steps

The μController version of the display module is working, I have to admit, in principle. There is still a bit more work to do to clean up its behaviour and possibly implement more tests and features i.e. the indicators on the top and bottom left of the display.

The actual main board still needs to be done. This will be presented in future posts. There are some considerations to be done with that in terms of its physical size for the existing casing. Another task that is outstanding is the interfacing of the Real Time Clock with SPI rather than I2C. I have been using I2C since that is what I used on the very first trial. My goal is to have a multiple slave SPI implementation. This too can be prototyped with my current set up before finalising on the actual main controller board.

The advantage I have with the current approach is that the firmware for the main board is progressively being done with the testing of the modules. It is just missing the implementation of the various push buttons. Even this can be implemented in the myAVR Development board.

Powering up the μController Display Module

In the last post, I set up the infrastructure on my newly configured PC to make sure that it can at least communicate and program a chip. I needed to do this before jumping in and starting to program the μControll based display module to minimise the number of issues to be encountered.

Initial Check and Power up.

Initial testI am happy with the approach and it certainly did help. Though it did not minimise the number of issues encountered, it made them more manageable to solve.

Before powering up I went back over the schematic and lay out to be sure that there were any issues. I did have a doubt about the way in which I was handling the programmer pin header. As it turned out, my concern was correct but I could work around it. I just had to break out the pin header to another and connect up the reset pin correctly. The status lights of the AVRISP were a bit of a guide that there were still problems. As I worked through them, I finally got the all green lights! Now it was time to try my first on-board program. The image shows my basic test harness. To bread-board the controller board with a single seven segment display.

This was the first time I would be programming a micro controller on-board. This also mean verifying the tool chain as well. I had already mentioned about setting up a controller on the bread board and proving the setup with that. This time there is no easy way to swap a jumper lead if something is wrong. What I did learn was that the BASCOM IDE is not very helpful for connection issues. I did find the AVR Studio was much more informative. Only from the point of view that using their programmer, you can read the signature of the device. When that returns OK, then you know that the basic infrastructure is ready.

Integration Test

Integration TestNow that the board can be connected to and programmed, the next step was to connect the controller to the seven segment display board. Here I discovered another issue. Since this is all on the bread board, then it was easy to work around – Going back on the schematic I could see that I really did miss translating the pin-header changes I made to the controller board to the display board. A silly oversight but something to keep in mind for next time.

$regfile = "m88pdef.dat"
$crystal = 1000000
$hwstack = 40
$swstack = 16
$framesize = 32

' $baud = 4800

Config Portc = Output                       ' Digits
Config Portd = Output                       ' Segments

Dim Digit As Byte
Dim Count As Byte

   For Count = 0 To 9
      Portd = Count                             
      For Digit = 0 To 5
         Portc = Digit
         Waitms 500
      Next                                  ' digit
   Next                                     ' count

Next Steps

I don’t need to go back and re-work the boards just yet. I can move on in their current state. The next step is to start the build the real firmware that will implement the expected API for the display module. Though now that I am this far, there is an interesting diversion to make with the project. Since this module has a SPI interface, it is possible to set this up as the main controller after all. That is to interface the Real Time Clock directly to this module so it displays the real time. This does not achieve the full objectives of the project though since it will not be able to implement any of the switches that are intended in the original design. But this could be an interesting way to test the digit display code.

Testing the μController Based Display – The Environment

This post is about bringing up the μController based display module for the Clock. In a previous post, I outlined the approach that I would be taking. Since this will be my first attempt at in-board programming on a “real” project, the idea is to take a systematic approach to try to quickly resolve any issues that might arise.

Setting up the Environment

muAVR mkII
muAVR mkII

To date, I have been working in the safe, insular world of myAVR and BASCOM on a newly configured PC. I have been lucky in that everything has “simply worked”. In order to start programming directly onto a project’s board, I need to start using the AVRISP mkII. Like I outlined in the previous post, the idea is to bread-board a controller with a LED. Using a simple “Blinker” program, I can ensure that the communication from PC to ISP to μController is correct without having to involve any issues that might be present on the display module board.

Rough and ready test harness

As it turned out, this exercise was worth while. In order to communicate with the AVRISP mkII, I needed the appropriate drivers. This are installed with when installing the AVR Studio. This is a C/C++ IDE. My objective, at this stage is to stick with BASCOM. I will move to C at some later stage. In order to use the BASCOM-AVR IDE, I had to install the USB_LIB and set up a device filter, as per the BASCOM help document.

With the drivers installed correctly, I was able to see the AVRISP mkII display the correct status on its LEDs and I could then start programming the minimal “bread-boarded” μController.


' $baud = 4800
Config Portb = Output

Portb.0 = 1

   Set Portb.0
   Waitms 1000
   Reset Portb.0

Next Step

The next steps will be to bring the board up slowly. That is to apply power and check that power is where it is intended to be. Once that checks out, the same test program used to verify the environment will be used to ensure that the board can actually be programmed. The test program will be the same “blink” example.

Getting Some Order in the House

It is now exactly six months since I joined up with Contextual Electronics. In that time I have three course related boards finished and tested, with two in the post. The tutor and mentor Chris Gammell also encourages own-projects, which is the main topic of this blog. For that I have two boards completed and tested and one ready for testing. Six boards in six months … and before that I was scratching my head how to get one done, let alone attempt SMD soldering.

Each board also means ordering more parts. I have learned that, within reason, it does pay to take up the price breaks. Especially for parts that are likely to be reordered from time to time like LEDs or perhaps transistors (and maybe those parts that are easy to damage?). One clear advantage is that it is really nice to be able to tick off the BOM and say “got it”, and move on. The draw back, though is the growing collection of small, silver bags, each with three or four inches of cut tape, lying around the work bench. We all see these and think “I will get to them later”.

I do have some racks of drawers for parts, and even have some empty drawers, but at the rate that my inventory is growing, this was not going to be a solution. I don’t have the space for more racks. I needed to do something before I lost the overview. Inspired by the SMD kits that come in folders, it dawned on me that I could do something about this. I grabbed a lever-arch folder that I had, along with some A4 plastic document holders and started to file these parts away. With some dividers, I have loosely separated the parts into Op Amps, Regulators and Chargers, Transistors and FETs, Diodes, Capacitors and Resistors. This is just the classification for the parts I have yet on hand and will surely change over time.

SMD Parts Folder
SMD Parts Folder (volume I)

I have found that the A4 plastic document holders, while suitable for the larger bags, are only part way there. I had some CD holder pages. They are somewhat better as I can have more than one part per page. I insert the cut tape portion where the CD would go and the suppliers part label into the space for the CD label. It is still not perfect as the shape of the holder means it is easy for the larger cut tape portions to fall out.

CD Holder
CD Holder
A4 Plastic Document Holder
A4 Plastic Document Holder

 Continuing with the experiment, I have discovered post card holders. These are an A4 plastic page divided into 4 individual holders. These seem really ideal for the small pieces of cut tape I have. For organising, where possible I apply the product label, however, since the envelopes are clear, there is nothing wrong with just leaving the part in the bag – especially if it is anti-static.

4 Part Post Card Holder
4 Part Post Card Holder

A couple of extra tips I have found useful, small stick-on labels with the project name helps to remind me what the part was originally for. The other tip is to keep the original vendor label. This helps with locating the data sheet quickly and will also help for any re-order.

Of course, this is just the start. It still takes a bit of effort to keep the folder in order. Especially when it starts to get full and I will have to branch out to Volume II. In the mean time I am still on the look out for that perfect holder page. Perhaps pages for holding Negative strips might also work for some cases but they are harder to come by these days.

You never know, maybe there is already anti-static document or post card holders already available?