Elusive CONFIG3H Setting

For toy project of mine I wanted to test PIC18F13K50. Nice fast PIC, lot of RAM, some ROM and USB connectivity. All that while working on good old 5V.

First order of business was to set configuration bits. Code should be familiar to anyone who used XC8:

#pragma config HFOFST = OFF
#pragma config MCLRE  = OFF

Unfortunately that did not work. I could set all bits other than those in CONFIG3H. And thus I could not make MCLR pin behave as normal input. Since PCB was already done, I could not just opt to use other pin. I had to have it my way.

I also tried to use:

__CONFIG(_CONFIG3H, HFOFST_OFF & MCLRE_OFF);

Hell, I even tried

 __PROG_CONFIG(3, 0x00);
```]

Nothing worked.

And than I noticed a curious thing. This PIC has CONFIG2H register followed by CONFIG3H. There is no CONFIG3L. Could that be an issue?

On a hunch I went to edit `18f13k50.cfgdata` (in `C:\Program Files\Microchip\xc8\v1.01\dat\`). There I added single line (highlighted) just before CONFIG3H declaration:

```plain
CWORD:300004:00:00:CONFIG3L
CWORD:300005:88:88:CONFIG3H
CSETTING:8:HFOFST:HFINTOSC Fast Start-up bit
CVALUE:8:ON:HFINTOSC starts clocking the CPU without waiting for the oscillator to stablize.
CVALUE:0:OFF:The system clock is held off until the HFINTOSC is stable.
CSETTING:80:MCLRE:MCLR Pin Enable bit
CVALUE:80:ON:MCLR pin enabled; RA3 input pin disabled
CVALUE:0:OFF:RA3 input pin enabled; MCLR disabled

With that simple change all was well and configuration bits were set.

And it works!

P.S. This workaround is valid for all other 18F family PICs that have CONFIG3L missing (e.g. PIC18F1220, PIC18F14K50…).

P.P.S. This should be solved in XC 1.10. Let’s hope. :)

[2012-08-11: As of XC8 1.10 this issue is fixed.]

No More Metro

Illustration

Those who are annoyed with Metro UI can rejojce. Microsoft will not use Metro interface for Windows 8.

Just joking, there is no real change here. Somehow Microsoft managed to step into trademark turd and now it is backpedaling out of it. I can imagine some poor guy going through all documentation, all articles and God knows what else (Windows 8 manual maybe) in order to replace any mention of Metro with “Windows 8-style UI”.

Windows Mobile related documents will get same treatment. With one stroke of a pen it will get it’s “New User Interface”. A bit stupid name for second iteration of same UI, but I guess that happens when lawyers crash the party.

While it might be funny to see Microsoft fry a bit, I do wonder why there is trademark issue here at all. Is the world going crazy?

[2012-10-05: Lately Microsoft started to refer to interface as Modern UI. Strangely appropriate since I feel like I am in Modern Times while using it.]

VHD Attach 3.50

VHD Attach screen

Here is new version of VHD Attach.

Due to popular demand, you can now change drive letter from within application. While this is not strictly VHD related task, I got it as suggestion from enough people. See, if you ask for something enough times, it is done eventually.

This version should also work on Windows 8 but do notice that there was no extensive testing. Probably new version will be out when Windows 8 is officially published.

ISO 8601 Week

For a program of mine I needed to get week number. Simple, I though, I’ll just use standard function. I knew from past that C# had one. I also knew that it offered me a choice of how to determine first week. I could start counting weeks starting from first day in year, first full week or first week that has four days in it.

Short trip to Wikipedia has shown that ISO 8601 date standard has part that deals with weeks. One of alternative definitions read that it is “the first week with the majority (four or more) of its days in the starting year”. With that sorted out, code was trivial:

private static int GetWeekNumber(DateTime date) {
    var cal = new GregorianCalendar();
    return cal.GetWeekOfYear(date, CalendarWeekRule.FirstFourDayWeek, DayOfWeek.Monday);
}

Nice, clean and wrong. Week numbers for all years that begin on Thursday were incorrect. For example, January 1 2009 is Thursday. According to ISO 8601 that means that this is first week and Monday, December 29 2008 is it’s first day. Result should have been 1 but .NET returned 53 instead. Probably something to do with United States and week starting on Sunday.

In any case, new algorithm was needed. Simplest thing would be to do all steps that a person would do in order to calculate it:

private static int GetWeekNumber(DateTime date) {
    var currNewYear = new DateTime(date.Year, 1, 1);
    var currFirstThursday = currNewYear.AddDays((14 - (int)currNewYear.DayOfWeek - 3) % 7);
    var currFirstMonday = currFirstThursday.AddDays(-3);

    if (date >= currFirstMonday) {
        var nextNewYear = new DateTime(date.Year + 1, 1, 1);
        var nextFirstThursday = nextNewYear.AddDays((14 - (int)nextNewYear.DayOfWeek - 3) % 7);
        var nextFirstMonday = nextFirstThursday.AddDays(-3);
        if (date >= nextFirstMonday) {
            return 1 + (date.Date - nextFirstMonday).Days / 7;
        } else {
            return 1 + (date.Date - currFirstMonday).Days / 7;
        }
    } else {
        var prevNewYear = new DateTime(date.Year - 1, 1, 1);
        var prevFirstThursday = prevNewYear.AddDays((14 - (int)prevNewYear.DayOfWeek - 3) % 7);
        var prevFirstMonday = prevFirstThursday.AddDays(-3);
        if (date >= prevFirstMonday) {
            return 1 + (date.Date - prevFirstMonday).Days / 7;
        } else {
            return 1 + (date.Date - currFirstMonday).Days / 7;
        }
    }
}

Can this code be written shorter? Of course:

private static int GetWeekNumber(DateTime date) {
    var day = (int)date.DayOfWeek;
    if (day == 0) { day = 7; }
    var nearestThu = date.AddDays(4 - day);
    var year = nearestThu.Year;
    var janFirst = new DateTime(year, 1, 1);
    return 1 + (nearestThu - janFirst).Days / 7;
}

This algorithm is described on Wikipedia so I will not get into it here. It is enough to say that it is gives same results as first method but in smaller volume.

Finally I could sleep at night knowing that my weeks are numbered. :)

P.S. If someone is eager to setup their own algorithm, here is test data that I have used. Most of them were taken from ISO 8601 week date Wikipedia entry but I also added a few:

Sat 01 Jan 2005  2004-W53-6
Sun 02 Jan 2005  2004-W53-7
Mon 03 Jan 2005  2005-W01-1
Mon 10 Jan 2005  2005-W02-1
Sat 31 Dec 2005  2005-W52-6
Mon 01 Jan 2007  2007-W01-1
Sun 30 Dec 2007  2007-W52-7
Tue 01 Jan 2008  2008-W01-2
Fri 26 Sep 2008  2008-W39-5
Sun 28 Dec 2008  2008-W52-7
Mon 29 Dec 2008  2009-W01-1
Tue 30 Dec 2008  2009-W01-2
Wed 31 Dec 2008  2009-W01-3
Thu 01 Jan 2009  2009-W01-4
Mon 05 Jan 2009  2009-W02-1
Thu 31 Dec 2009  2009-W53-4
Sat 02 Jan 2010  2009-W53-6
Sun 03 Jan 2010  2009-W53-7

P.P.S. Getting year and day in week is quite simple and thus left for exercise of reader. :)

Padding Length

Quite a lot of modern protocols have padding requirements. One great example is Diameter. All attribute values there are aligned on 4-byte boundary. Reason behind such complication is in data structure alignment. While only benefit on x86 architecture is (usually minor) speed increase, on RISC processor it makes difference between doing some work or crashing in flames.

Most common alignment is on 4-byte boundaries. If we have something with length of 5, aligned length will be 8. However for length of 4, aligned length is also 4. Code is as simple as it gets:

public int GetPaddedLength(int len) {
    if ((len % 4) == 0) {
        return len;
    } else {
        return len + 4 - (len % 4);
    }
}

Lengths that fall into alignment by their own devices are not touched while all other get small boost. Of course that code can be a bit shorter if one is comfortable with C# ternary operator (present in almost all C-like languages):

public int GetPaddedLength(int len) {
    return ((len % 4) == 0) ? len : len + 4 - (len % 4);
}

And, if other alignment is needed, small generalization is all it takes:

public int GetPaddedLength(int len, int align) {
    return ((len % align) == 0) ? len : len + align - (len % align);
}