Stefan W.

Also not a book, but for me, when I started with electronics, a simulator like LTSpice has been invaluable - you can try stuff without frying things i.e. test if your transistor switch works and how much current is drawn from the microcontroller etc. But that's just in addition to a book, it obviously does not teach you physics

Well, colors are not absolute, especially on LCD screens colors depend a lot on the screen - the links are readable for me (although i'll say that the choice is suboptimal and a darker color would be better)

7.2V is below the specs - the netduino asks for at least 7.5V as unregulated input (which means in case of battery you should aim for more since the voltage drops as the battery discharges). This might be the cause for your stability issues ...

You have only three choices:
make all the devices working under the same supply;
use two different I2C buses for each supply;
insert a double bidi-level adapter to decouple the different supplies.
Of course, I suggest to follow the first one, which is the simplest.

I disagree here, it's not the simplest simply because there are devices which do use different supplies ... but a bidirectional level adapter is pretty simple, have a look at the tx line from http://www.sparkfun....nverter-v10.pdf - two resistors, one mosfet, and you're done (note the resistors act as pullups, so if you already have pullups on both sides - as you have - you can ditch them, so your level converter becomes a single transistor.

No, the custom firmware just increases clock resolution, it does not make code run magically faster. Seriously, you are wasting your time. I don't get why you think this is a reasonable goal ... you will not be able to count pulses coming in at 1mhz in managed code. Why are you so fixated on directly interfacing this sensor with the netduino? As was already suggested in the beginning: Use another sensor, e.g. with a phototransistor or photoresistor (it does not get much cheaper or easier than this) or use another MCU to do the counting for you.

Not wanting to spoil something, but be careful. It's not "so close to working" - you are still more than an order of magnitude away from your target (500khz). The trick from CW2 is an interesting one, but as you've seen there are limitations - it builds on disabling the interrupt handler before the queue fills up, which it can't if the frequency is very high (as you've seen) and which gets also harder should the GC decide to kick in before the handler start and the removal of the handler. Also, a limitation of that approach is that you only sample for a short time, so you're susceptible to "noisy light" (if the sensor is fast enough for that, didn't check that).

In case someone is searching for this in the future, this is the very simple software glitch filter i talked about:

    public class Program
    {
        private static readonly InterruptPort Button1 = new InterruptPort(Pins.GPIO_PIN_D0, false, Port.ResistorMode.PullUp,
                                                                Port.InterruptMode.InterruptEdgeLow);
        private static DateTime Button1LastPushed;

        public static void Main()
        {
            Button1.OnInterrupt += Button1_OnInterrupt;
            // ... main loop
        }
        private static void Button1_OnInterrupt(uint data1, uint data2, DateTime time)
        {
            // glitch filter. events within 50 milliseconds of the first event are discarded
            if (Button1LastPushed.AddMilliseconds(50) > time)
                return;
 //         Debug.Print("Button 1 Interrupt");
            Button1LastPushed = time;
            // actions on interrupt here
        }
    }

Also, Mario, i definitively did read an application note for a microswitch that strongly advised against putting a "naked" capacitor across a switch because of damaging effects. If i can turn it up again (I don't recall where I found it ...) i'll link it here.

Also for the record, if someone wants to do the hardware debouncing "cleanly" it should be probably done like in this article (german text, the schematic should be understandable though) using a RC filter with a schmitt trigger. However, as software debouncing is so easy and doesn't require additional components, i just do that Another useful bit of information in that (german) article is that switches usually bounce for up to 10ms, so the time constants for the debouncing (software or hardware) should be chosing according to that (and no human operates a switch 100 times a second anyway)

A capacitor across the switch works, however keep in mind that this means that by pressing the switch you are shortening the capacitor, which can lead to high currents through the switch. This effect can (does not have to) lead to damaged (stuck in "on" position) switches (won't likely happen the first time you try it, however if this is something that should live a long time, you might see this), you can prevent that by putting a resistor in series to the capacitor to limit the current (100 ohm should do fine). A software filter is what i'm using - i store date of the last edge, and if the timespan between the last date or the current date is too low, i discard the event. What the glitch filter does is polling multiple times, i don't know over which time domain, maybe it's too short.