I²C is a fun protocol. It's great for interfacing to real time clocks, sensors, displays etc. My personal favorite right now is the Si5351 frequency generator chip. In a world of ever increasing number of I²C compatible micro-controllers, I though that my MC3 should learn to speak I²C as well. I have chosen a chip from Philips that is a self-contained I²C interface. It's much faster than bit-banging an I/O port. The chip, PCF8584, can still be obtained from various suppliers but I don't think it's being manufactured anymore. Therefore I have taken extra care to protect it. The interface schematic can be seen below. The tricky part about buffering I²C signals is that they are bi-directional. A buffer that is both bi-directional and has open collector input/outputs needs some extra thinking. It is not possible to just put to buffers back to back and expect it to work. As soon as one of the buffers trigger the opposite buffer will also trigger and the circuit will enter a locked state. To solve this I have designed the buffer stages using two comparators (LM339) with open collector outputs. By using comparators it is possible to carefully adjust the trigger levels so that one buffer does not affect the buffer in opposite direction. A reference voltage of 0.65V is used for the comparators, but the output from the comparators facing the PCF8584 has a series resistor that together with the pull-up resistor creates a voltage divider. When the comparator tries to pull the line low the divider will limit the voltage to around 1.2V, enough for the PCF8584 to register a 'low' level but not enough to trigger the opposite comparator. This is the finished MC3 I/O board. I added an 8-pin socket (not in the schematic) for connecting EEPROMs directly on the board. As always, don't forget to add 100nF decoupling capacitors across the supply on all chips. Sample program for testing the interface This program interfaces to a DS1307 RTC chip but I have made the I²C driver routines generic so they can be used for accessing any other I²C device as well. - source - listing - s19

Even though the MC3 is in its core a Motorola 68xx design it can use 65xx parts. The bus and timings are the same. I initially planed on building an I/O board around the 6321 PIA but ended up trying out the feature packed 6522 VIA instead. The 6522 is actually still being manufactured by WDC! The 6522 is familiar to anyone working with the 6502 or MOS/Commodore machines. In general it's a souped up 6821 with two timers and a shift register. The 6522 consumes more address space than the 6821 but each register can be directly addressed, thus making it faster for certain tasks. It requires four address pins instead of only two but for me that's a perfect match since my I/O boards each have 4 address lines making it a 1:1 match. Connecting the 6522 to the MC3 20-pin I/O expansion bus require no extra circuitry. It's only a matter of connecting the corresponding pins together. Since there is no IRQ line on the I/O bus I will have to settle for polling the 6522. Thank you Douglas Beattie for sharing your Eagle 65xx library. The 40-pin chip is a tight fit on the small 20-pin I/O board but it worked. For now there are no connectors for the 6522 ports. Not much space left but I should be able to mount a suitable connector at the top of the board. I really like how the 6522 engineers have separated the bus pins and the I/O pins to different sides of the chip.

Inside the 6522

Above is the block diagram as seen in the G65SC22 datasheet. The 6522 has two 8-bit ports with two handshake lines each. Both ports are controlled by their corresponding data register and data direction register (just like the 6821 and many other designs based on the same concept). It also has two 16-bit timers and a shift register. Care must be taken to avoid the infamous shift register bug happening in mode 011, external clocking of the shift register. The bug occurs when the shift register clock input falls at about the same time as the Φ2 clock falls, making the shift register lose one data bit. Very strange framing errors can occur when it happens. Garth Wilson has proposed a neat solution for this that involves an external latch. Rumors has it that some variants of the 6522 does not suffer from this bug. I have a used the G65SC22 from CMD in my design that supposedly have this bug fixed. I need to set up a test to see if this is the case. In general, when dealing with the 6522 you have to assume all of them contains the bug in mode 011. The other shift register modes are unaffected as far as I know.

The MC3 had expanded way beyond the initial enclosure and really needed to move into something bigger. Having exposed boards feels risky. Especially with these scarce old components. I really do not want to accidentally kill anything. Also I did not want to just put everything in a standard boring electronic box. The all CMOS based MC3 does not generate much heat so active cooling is not needed but a well ventilated case also ables for some peeking inside which is fun. Isolation to reduce RFI and protect from ESD was also added to the requirement specification. It looked like I would need to design something from scratch. Old wooden TV-sets have always fascinated me. Dad worked as a TV repairman many years ago and as a kid I remember watching him working with those old wooden TV's. That's my inspiration for the MC3 enclosure. Time to warm up the Festools and get cutting! First off I decided to use edge glued oak as the base for the enclosure. It makes it all pretty robust and also look a bit more furniture-ish. The construction is a plain wooden frame with perforated side panels of aluminum. Those panels are actually ventilated sides made for Schroff 19" enclosures that I found in the scrap pile at work. Oak does not provide any ESD protection or RFI isolation to speak of so I dressed the inside of the wooden parts with aluminum tape. The front side of the box has no buttons for a clean look. Since I use the RS-232 reset circuit I very rarely need to access the physical reset switch anyway. On the back there is a cut-out in the wood for an access panel containing all connectors and buttons. A view of the back panel. Some space left for expansion. Both aluminum side panels can be removed. The main boards are stacked and screwed to the bottom with screws that go all the way through. Even when the aluminum sides are on it's possible to get a glimpse of what's inside. Also visible here is the aluminum tape on the wooden parts. Boards mounted here are from top to bottom; I/O expansion board with a few mini I/O boards on top, video board, CPU board and extended RAM board. The two boards on the bottom are empty for further expansion. Now it feels safe to let the cat stroll around the computer again!

Jessie has reached stable and for those of you who don't want to reinstall your system the upgrade procedure is quite straight forward. As always make sure you have a backup before you start in case something goes wrong. First step is to make sure you have no special packages installed. Packages from the standard Debian repositories should be safe as well as most of the backports but I strongly recommend to remove packages from third party sources before starting. You also have to be logged in as root to perform the update. Step 1 - Make sure your Wheezy system is up to date This is done using the regular apt upgrade procedures. # apt-get update # apt-get upgrade # apt-get dist-upgrade Also make sure you have the latest keyrings installed. # apt-get install debian-keyring debian-archive-keyring Step 2 - Update apt sources and change wheezy to jessie Edit your /etc/apt/sources.list and change all 'wheezy' to 'jessie'. Also don't forget to take a look at the files in /etc/apt/sources.list.d/ (if there are any) and perform the same replace procedure. Step 3 - Disable X Since a lot of packages will be updated and daemons will be restarted there is a potential risk of screwing something up when running under X. Go to a regular TTY console and continue the upgrade from there. Alt+F1 or Alt+Ctrl+F1 should get you to the first console. Log in as root and continue to the next step. Step 4 - Perform the actual upgrade When you are logged in to the TTY console. The upgrade process may be initiated. First we must update the latest sources. # apt-get clean # apt-get update The next two steps is the actual upgrade that will alter the system. First we perform a normal upgrade. A lot of packages will be replaced and also quite a lot will be kept back. This is normal. # apt-get upgrade This is the first step of the actual upgrade. The installer may ask questions that I can not foresee here but as long as you are in a TTY console it should be safe to restart daemons etc. Also there may be questions about configuration files that is edited by the user and set to be replaced by the upgrade. If unsure, sticking to the default value is often a safe choice. If the screen goes back to X press Alt+F1 (or Alt+Ctrl+F1) to get back to the install console. When the first upgrade step is complete we can go on to the next one. # apt-get dist-upgrade This step will also upgrade those packages earlier reported as kept back. Step 5 - Reboot into the new system # reboot This is it. I have performed this upgrade on several systems now with good results as long as no third party packages or user modifications screws something up. As always, to get the cleanest possible system the only way is to start from scratch and do a clean install from the new installation media. A note about systemd Debian Jessie is shipped with systemd. Yes, that's true. Without getting into a discussion about systemd itself I will just add that it is possible to remove systemd from jessie (well, most of it at least). See this link for more info. I will post the instructions here directly from the link above in case something happens. First install the SysV init packages # apt-get install sysvinit-core sysvinit sysvinit-utils Then reboot your machine and remove all of the systemd packages. BE AWARE that the following command removes packages that depend on systemd itself or things like libpam-systemd! # apt-get remove --purge --auto-remove systemd Prevent apt from installing systemd packages in the future. # echo -e 'Package: systemd\nPin: origin ""\nPin-Priority: -1' > /etc/apt/preferences.d/systemd Prevent apt from installing any systemd like packages in the future (note the star before and after systemd) # echo -e 'Package: *systemd*\nPin: origin ""\nPin-Priority: -1' > /etc/apt/preferences.d/systemd

After growing tired of lugging my big and bulky DSLR camera around everywhere I began looking into smaller alternatives and picked up a Panasonic DMC-G6. A relatively cheap mirror-less MFT camera. The GH2/GH3/GH4 series cameras from Panasonic have proven to be quite successful both for photo and video so I figured the G6 might be a good and cheap starting model to get to know the Panasonic world a bit. The G6 is similar to the GH4 with regards to handling and menus etc. After using it for over six months I must say that I'm quite pleased. It's performing very well an has a lot of features I would rather expect to see in a higher-end camera. It comes at a somewhat buggy price though but the only really serious bug I've encountered so far is in the "Pixel Refresh" feature. It annoyed me for a long time but now I may finally have found a solution.

Image sensors and pixels

Every CMOS and CCD image sensor today have random faults. Even the high-end ones. All pixels are not equally sensitive and some may even be completely dead and locked at a full black or full white level. Every sensor manufacturer has a threshold on how many errors are acceptable in production. Sensors that does not reach this threshold are trashed and it is safe to assume that no sensor have 100% working pixels. Especially over time since age and radiation will create more defects. The most devestating defect is when pixels are too bright. They are easily spotted by the human eye. This is what is commonly referred to as hot pixels or stars. Camera manufacturers use software algorithms to calibrate each sensor individually to compensate for pixel defects. Some camera models require a service technician and/or special tools to perform this calibration and some models can perform the calibration in-camera, either initiated by the user or automatically.

Discovering the Pixel Refresh function

Panasonic have decided not to hide the sensor calibration feature from the user and they call it "Pixel Refresh". The details around this function is very vague and the manual is not very helpful. The manual does however say the following: "Imaging device and image processing is optimised when the camera is purchased. Use this function when bright spots that do not exist in the subject get recorded." Okay, Pixel Refresh is clearly meant to hide hot pixels. That's great! Eventually a few bright pixels showed up on my video footage and I decided it was time to try out the Pixel Refresh feature and YIKES! After this all my pictures and videos looked like the milky way! I immediately realized that something must have gone very very wrong. There were several extremely bright pixels clearly visible even at ISO 200. What was even more baffling was that the hot pixels moved around when changing the sensitivity/ISO and some pixels were only visible on the LCD/WF and some were only visible on the recorded media. Running Pixel Refresh again did not really improve the situation but after countless other attempts I really began to suspect that this had to be a software error. Spending a several hours factory resetting, updating firmware (to v1.2) and speaking to Panasonic tech support did not help either. Eventually Panasonic called for a warranty repair and after a few weeks I got my camera back with a new sensor and even more hot pixels. The service center clearly did not get the situation at all...

My solution

Almost ready to give up on the G6 I started to methodically execute the Pixel Refresh function after placing the camera in different operating modes and settings. I eventually found a combination that actually worked! The most important lesson learned here is that camera settings severely effects the Pixel Refresh function. In general, when executed, the function will display a progress bar. If this progress bar does not progress smoothly and ends with a big jump to 100% it means that the process has failed in one way or another. It took a lot of trial but here is my procedure for running Pixel Refresh on the G6 that actually provides usable results. - Let the camera reach operating temperature - Enter manual photo mode "M" (not manual video mode!!) - Turn electronic shutter ON - Set ISO to 1600 - Put lens cap on (keep stray light away from the sensor) After performing the steps above run Pixel Refresh. The process may need to be repeated in order to get rid of all hot pixels. The procedure above has worked several times now on my G6. I can not tell if it will be the same for other G6's or other Panasonic cameras but it would be interesting to know.