Project - DL40 - I/O Module Firmware

Archive
81

@ Fradav - That is the correct documentation for the chip used on the DL40 (LPC1113/301)

You are correct, the UART TX/RX pins are exposed on the downstream socket. These pins are used to program the firmware using the UART, but they also connect to the I2C pins so I suspect that the DL40 cannot use the UART peripheral at runtime as there will be a conflict with the I2C and UART data.

It is a real pity, but I guess any other approach would have required the DL40 to have an additional socket, increasing the cost of the module. Of course the advantage would be that there would be a serial socket available for general use, which would be nice.

82

Another option is to do bit-banging like there is no tomorrow on the chip, as it is reasonably safe to assume it won’t do anything else on the cpu. But I don’t know if it has sufficient cpu power to bit-bang at 250kbauds like I’m trying to do, for example.

83

What’s the best way to pass a 512 byte array to DL40, through registers or I2C ?

84

@ Fradav - Since the register ID is a byte wide this would limit you to less than 255 elements (the first 8 registers are reserved for the DL protocol). Luckily, you can treat a register as a compound value, so a single register would hold the entire array of data, and one of the other registers would have the count of items for example. This also has the advantage that you are transferring data more efficiently, because once the register is selected you can “stream” the value to the register.

You can see how I have done exactly this in the implementation of this module driver/firmware, registers are have more complex value structures to build up commands that are sent to the module to configure the ports etc.

85

I think I got a problem with DL40IO IInterruptPorts. Here is the code :


        private DLIOModule dl40;
        private Thread weatherThread;

        private IInterruptPin WindSpeedPin;
        private IInterruptPin RainGaugePin;
        private IAnalogInputPin LumPin;
        private IAnalogInputPin WindVanePin;

        void ProgramStarted()
        {
            dl40 = new dotnetwarrior.NetMF.DL40.DLIOModule(2);

            WindSpeedPin = dl40.CreateInterruptPin(3, 1,
                Microsoft.SPOT.Hardware.Port.ResistorMode.PullUp,
                Microsoft.SPOT.Hardware.Port.InterruptMode.InterruptEdgeLevelHigh);

            WindSpeedPin.Interrupt += WindSpeedPin_Interrupt;

            RainGaugePin = dl40.CreateInterruptPin(3, 2,
                Microsoft.SPOT.Hardware.Port.ResistorMode.PullUp,
                Microsoft.SPOT.Hardware.Port.InterruptMode.InterruptEdgeLevelLow);

            RainGaugePin.Interrupt += RainGaugePin_Interrupt;

            LumPin = dl40.CreateAnalogInputPin(AnalogInputPinId.PIO1_4);
            WindVanePin = dl40.CreateAnalogInputPin(AnalogInputPinId.PIO0_11);

            weatherThread = new Thread(weatherRun);
            weatherThread.Start();


            // Use Debug.Print to show messages in Visual Studio's "Output" window during debugging.
            Debug.Print("Program Started");
        }

        private ushort rainCounter = 0;
        private long rainTempTime = DateTime.Now.Ticks;

        void RainGaugePin_Interrupt(IInterruptPin pin, uint interruptCount)
        {
            rainCounter++;
            dl40.DebugLed.Write(!dl40.DebugLed.Read());
        }

        double RainGauge()
        {
            double result;
            if (rainCounter != 0)
            {
                result = (2794000.0 * (float)rainCounter) / (float)(DateTime.Now.Ticks - rainTempTime);
                rainCounter = 0;
                rainTempTime = DateTime.Now.Ticks;
            }
            else
            {
                result = -1.0;
            }
            return result;
        }

        private ushort windCounter = 0;
        private long windTempTime = DateTime.Now.Ticks;

        void WindSpeedPin_Interrupt(IInterruptPin pin, uint interruptCount)
        {
            windCounter++;
            dl40.DebugLed.Write(!dl40.DebugLed.Read());
        }

        double WindSpeed()
        {
            double result;
            if (windCounter != 0)
            {
                result = (24000000.0 * (float)windCounter) / (float)(DateTime.Now.Ticks - windTempTime);
                windCounter = 0;
                windTempTime = DateTime.Now.Ticks;
            }
            else
            {
                result = -1.0;
            }
            return result;
        }

       void weatherRun()
        {
            while (true)
            {
                Thread.Sleep(4000);

                uint lum = (uint)(LumPin.Read() * 1000);
                Debug.Print("Light : " + lum);

                double U2 = WindVanePin.Read() * 3.3;
                double R2;
                if (U2 == 3.3) R2 = -1;
                else R2 = (1000.0 * U2) / (3.3 - U2);
                Debug.Print("WindVane : " + R2);

                double vv = WindSpeed();
                Debug.Print("WindSpeed : " w);

                double pp = RainGauge();
                Debug.Print("Rain Gauge : " + pp);
            }
        }

1/ I have to use different edge detections for interrupts 3_1 and 3_2 otherwise 3_2 is never detected,; are they multiplexed from the same interrupt channel ? I got the impression that channels are multiplexed across ports not pins from the same port, correct ?

2/ what is the meaning of the interruptCount ? it is usually a very high number, completely irrelated to the real interrupts (typically a few per seconds)

3/ Sometimes, but especially when debugging, after a mainboard reset, the DL40 module doesn’t respond anymore, and I had to unplug/plug it to get it back. This is making debug sessions very unpleasant.

86

@ fradav - It is a little late here, I will try run this through the debugger tomorrow.

With regard to the need to recycle the DL40, the core firmware seems to have a problem with resetting I have actually started implementing the DaisyLink protocol from the ground up so that I can see if I can resolve this and other issues from the standard DaisyLink implementation available with the DL40 and which was used as the starting point for this firmware. It is also building with GCC rather than requiring MDK.

87

@ fradav - Are you sure you want to use the edge level interrupts? That means that the interrupt will continuously be generated for the entire time that the pin is at that level. This would explain the crazy interrupt counts you are seeing, if your pin is at the interrupt level the interrupts will be generated and counted continuously for that period at a very high rate.

If you only want an interrupt when the state transitions then you should, for example, be using ‘InterruptMode.InterruptEdgeHigh’ which will only trigger an interrupt at the point that the pin goes high.

The code below has both pin 3.1 and 3.2 configured to interrupt when the pin goes high and from the tests I did here I get both interrupts. Could you possibly test this and see if it works for you?


using System;
using Microsoft.SPOT;
using dotnetwarrior.NetMF.DL40;
using System.Threading;

namespace DLIOTest
{
    class TestInterruptPin
    {
        static DLIOModule Module;
        static IInterruptPin InterruptPin;
        static IInterruptPin InterruptPin2;
        static IOutputPin LedPin;

        public static void Run(DLIOModule module)
        {
            Module = module;
            LedPin = Module.CreateOutputPin(2, 3, false);
            InterruptPin = Module.CreateInterruptPin(3, 1, Microsoft.SPOT.Hardware.Port.ResistorMode.PullDown, Microsoft.SPOT.Hardware.Port.InterruptMode.InterruptEdgeHigh);
            InterruptPin.Interrupt += new PinInterruptHandler(Pin_Interrupt);

            InterruptPin2 = Module.CreateInterruptPin(3, 2, Microsoft.SPOT.Hardware.Port.ResistorMode.PullDown, Microsoft.SPOT.Hardware.Port.InterruptMode.InterruptEdgeHigh);
            InterruptPin2.Interrupt += new PinInterruptHandler(Pin_Interrupt2);
        }

        static void Pin_Interrupt(IInterruptPin pin, uint interruptCount)
        {
            Debug.Print("3.1");
            LedPin.Write(!LedPin.Read());
        }

        static void Pin_Interrupt2(IInterruptPin pin, uint interruptCount)
        {
            Debug.Print("3.2");
            LedPin.Write(!LedPin.Read());
        }

    }
}
88

@ taylorza - of course, I should have used InterruptEdgeHigh for counting simple circuit switch, I misread the doc, my bad… A quick question though, the interruptcount argument of the event delegate will be always 1 in this case or we shouldn’t assume this ?

89

@ fradav - There is some latency between the interrupts on the module and them being raised on the mainboard so it is possible if the interrupts are being generated at a high rate that more than one interrupt occurred by the time the mainboard actually gets to handle the interrupt, in this case you would get a count of the number of interrupts seen by the module at the time the interrupt is raised on the mainboard.

90

@ taylorza - ok, so I have to increment my counter with this then to have the exact count of interrupt over a time. Thanks you very much for your explanation.

91

@ fradav - It is a pleasure, I am glad to see the firmware being used.

92

Hi Taylorza. Nice to meet another Afrikaans person here. I’m very impressed with what you’ve done with the DL40. I ordered two modules to play with as I can see how useful they be. But I can also see there is still a lot for me to learn. For now I just have a few basic questions:

  1. What is the resolution of the A/D’s on the DL40 boards?
  2. Is there some instructions somewhere how to compile the source code for you I/O code?
  3. I presume latest code is found on CodePlex and not here on CodeShare?

Anyway, thanks again for making all this available to us.

93

Hi KiwiSaner.

  1. DL40 have LPC1113/301 processor with 10bit ADC
  1. True, codeplex is the latest and gratest :slight_smile:
94

@ jernejk - Thank you very much for the detailed info. I’m definitely going to give it a go.

I suppose that if you do not yet own a JTAG emulator, then you can still use Taylorza’s Cerberus DL40 Programmer ( (https://www.ghielectronics.com/community/codeshare/entry/641) to program the DL40. The only drawback will be that cannot debug your code. I would just like to try first to simply compile your source code myself and then program it to the DL40, before I invest in a JTAG emulator as well.

Oh, and by the way that link that you supplied to get the free Keil tool did not allow me to download with having a license code. But I think I found the free download here:
MDK-ARM Version 5.38a Evaluation Software Request

95

@ KiwiSaner – be carefull! It is very addictive! :slight_smile:

After build in uVision you fill find DL40.bin. Than you use DL40 programmer you mentioned.

Have fun!

96

I think I know of an ideal application for the DL40… It is an HPIB bus controller to talk to Agilent Instruments etc. It will allow you use your Gadgeteer board to control test instruments like multimeters and power supplies in automated test equipment. There are some commercial USB HPIB bus controllers available at a cost of about $150. But controlling it via a Gadgeteer board opens up so much more possibilities.

I had a look at what a HPIB controller does and it is really not complex. But it requires a lot of I/O pins and speed. Both things that the DL40 board offers plenty of.

97

Sorry for not replying sooner, I literally just got back home from a trip to the States. You got excellent advice from @ jernejk, in fact he is the expert on the ADC side of the firmware as that was implemented by him.

There are a few chaps here from SA, it is a pity .NETMF/Gadgeteer does not get more visibility out there.

Thank you and credit goes to @ jernejk for his contributions and fixes as well. It is my favorite module to work with I even use it as a more general purpose chip and ignore the daisylink aspect. I keep trying to convince someone to build us a DL40 with the pins broken out to Gadgeteer sockets but alas… :slight_smile:

Your idea on the HPIB bus sounds interesting, now I have to go learn what a HBIP bus is :slight_smile:

98

[quote=“taylorza”] I even use it as a more general purpose chip and ignore the daisylink aspect.
[/quote]
Thanks, this is great to hear because confirms what I hoped for. That it can make a very nice low cost standalone CPU board. It would be very cool to get something like a Bluetooth or RFpipe interface going on it. Then it can still wirelessly talk to a Gadgeteer mainboard but can work completely independently as well.

Actually I incorrectly called it HPIB but what I should have said was GPIB (General Purpose Interface Bus). It used to be called HPIB a long time ago when HP was still the driving force behind it. A lot of automation instrumentation still use GPIB although these days some instruments provide more modern interfaces. Basically it was loosely based on the old Centronics printer interface and they chose a parallel interface rather than a serial interface. (My guess is that the fast interfaces like we get today was unheard of when this was designed).

You can sometimes buy very nice GPIB capable instruments cheaply second hand on places like Ebay. I recently bought myself two Agilent power supplies on which you can control and measure current and voltage very precisely.

99

Just one last bit of feedback… everything worked. I used the free version of the Keil compiler to re-compile your source code and program my DL40 boards using the Cerberus DL40 codeshare project and finally tested that I could read some A/D values coming from the DL40 board. I’m surprized there is not a lot more people using the DL40 module as it makes all this extra I/O capability available and only uses a single socket.

100

That makes two of us, especially when you start thinking of off-loading actual work to the device while the mainboard carries on with other tasks.