FEZ Domino and Phidgets boards

It was my intention to copy an existing page :wink: But as I’m more in a test phase than a finishing project, I was wondering if it was really a good time to post something : code is not complete nor optimized. And of course, not documented as expected.

Anyway, right now, I can use the 1018 board at 2/3 of its capacity, which is not that bad, afterall. So maybe I can pause my test and make clean code so that others can try it. Why not.

I will write classes that can be used, not only code snippets.

Best regards,


Christophe

Hello,

I’ve just updated the project wiki : (link removed)

It only misses some pictures. I will try to addthem asap.

The project files are 2 files : one class (Phidget1018) and a sample program. Which is very simple, btw:


using Microsoft.SPOT;
using System.Threading;

using FEZPhidgets;

namespace MFConsoleApplication1
{
    public class Program
    {
        static IF1018 Phidget1018 = new IF1018();
        
        public static void Main()
        {
            Phidget1018.InputChange += Phidget1018_InputChange;
            Phidget1018.SensorChange += Phidget1018_SensorChange;

            Thread.Sleep(Timeout.Infinite);
        }

        static void Phidget1018_SensorChange(object sender, Phidget1018SensorChangeEventArgs e)
        {
            Debug.Print("Sensor event. Index " + e.Index.ToString() + ", Value " + e.Value.ToString()+", Raw value = "+Phidget1018.RawSensor[e.Index].ToString());
        }

        static void Phidget1018_InputChange(object sender, Phidget1018InputChangeEventArgs e)
        {
            Debug.Print("Digital input event. Index " + e.Index.ToString() + ", Value " + e.Value.ToString());
        }
    }
}

It’s using the class to access the 1018 InterfaceKit, on which I’ve connected many analog sensors and a push button.
Each time an analog sensor value is changing, and if the change is greater than a user-defined sensitivity for analog sensors, an event is raised.

I will try to make a video of the whole project running, but it’s not easy to see the screen and the boards at the same time, though :frowning:

Anyway, if you think that something is wrong (or not good enough) with my project, please do not hesitate to tell it, as I’m a real beginner with FEZ Domino and USB management…

Best regards,


Christophe

[quote]Anyway, if you think that something is wrong (or not good enough) with my project, please do not hesitate to tell it, as I’m a real beginner with FEZ Domino and USB management…
[/quote]

You are doing great so do not worry plus everyone here is a beginner including myself :wink:

He he :slight_smile: You… a beginner ? In studies on the sexuality of white snails in Romania during 18th century drought, maybe, but not with Domino :wink:

Anyway, after posting pictures, I will add support for the 1052 digital encoder. This is almost done in my code. Only needs some clean-up.

So…

The project page has now a picture of the test setup and a video of the sample program running.

Here are the direct links :

(link removed)
http://www.lsp-fr.com/FEZ/DominoPhidgets.avi

Best regards,


Christophe

Very nice. You can add the video to youtube and then add it to the page if you like. See here for an example on how to add videos. (link removed)

Phidget 1052 Digital Encoder driver is now included. The project page has been updated accordingly.

FYI, this drivers enables :

  • reading the state of the push-button
  • reading the current encoder position

Via the PositionChange event you can know the current encoder position, the direction of the move and the relative move value.
Via the InputChange event, you will know when the push-button has been pressed/released

Best regards,


Christophe

Just FYI, I’ve got a very positive answer from Phidgets guys :slight_smile: They’ve sent me all the infos I needed to work on a driver for their Stepper controllers and DC controller.
These are Phidgets 1062 and 1060 :

I don’t know yet how long it will take to have these drivers functionning, but now it’s only a matter of time, not related anymore to try/fail or exploration of USB packets with a sniffer…

Btw, they also wish I could share my work on their forum as some members have already had some requests for MicroFramework support.
The only problem, if it works, is that I don’t know in which office I should work after that : GHI or Phidgets ? :wink:

GHI…we love you man :slight_smile:

Bec… I also use Phidgets but I have the 1203 PhidgetTextLCD 20X2 : White : Integrated PhidgetInterfaceKit 8/8/8 - 1203_2B at Phidgets

Its the same as the 888 interface that you use but with an lcd attached to it… Im getting

A first chance exception of type ‘System.Exception’ occurred in GHIElectronics.NETMF.USBHost.dll
#### Exception System.Exception - 0xffffffff (9) ####
#### GHIElectronics.NETMF.USBHost.USBH_RawDevice+Pipe::TransferPipe_Helper [IP: 0000] ####
#### GHIElectronics.NETMF.USBHost.USBH_RawDevice+Pipe::TransferData [IP: 001c] ####
#### FEZPhidgets.Phidget1203::_1203Thread [IP: 0039] ####
A first chance exception of type ‘System.Exception’ occurred in GHIElectronics.NETMF.USBHost.dll

Any ideas here?

FYI, I changed the class name from 1018 to 1203…

Hello,

glad to see I’m not the only loony that is using Phidgets with FEZ :wink:

As for the answer, I’m still getting this error (many times) during a period at the beginning of execution :confused:
I think it has to do with the 8/8/8 not being “ready” yet. I don’t have a solution right now but I was testing something yesterday (!) for the 1052 : instead of waiting an unknown time for the device being ready, I send commands till I don’t get any exception in return. Then I know the 8/8/8 is ready.
I think I will be able to post a modified version of the driver by the end of the week.

You have to keep in mind two things, though :

  • Phidgets board don’t send any “ready” signal (I know this from the Phidgets staff), so I have to poll until I don’t get any error.
  • the debug.print method is good but only if there are not many messages… Here, you get plenty of exception just because the FEZ board is trying to communicate with the Phidgets too quickly before the Phidget gets ready. Hence the number of exceptions.

You can try to comment the Debug.Print line and add a small delay, say 2sec, before the first real access to the board. This should keep the number of exceptions very low. Though I still can’t eliminate all of them for now :frowning:

I think I should explore the USB stream (flow) to see where something is changing that would signal a ready state, but that’s very boring… And I don’t have that time right now, as we’re moving our factory to a new location in less than a month
:confused:

Keep in mind that errors can happen in on USB like any other bus so the code should have exception handlers to recover from errors.

Yes, of course. But in this particular case, I know that there’s some delay before the board (and other Phidgets board, btw) is really ready and because of that I get errors at startup.

I’m still trying to figure out how to minimize these errors. But the fact that they are echoed in the debug window may make people think something is wrong where in fact it’s not (really) the case.

You can think at the delay when you plug an USB device on Windows : you can’t use it until the small window “Device is ready to use” appears. It’s the same here, though right now I don’t know how to tell/check that the device is ready. That’s why I’m polling and sending commands until I don’t get any exception in return.

There’s still something weird : using the same program, without any code change, I can get no exception or one or many. In case I have exceptions, it stops by itself after a short time :confused:

When I say “no code change”, I mean that I only stop the debugging session and start another one just after that.

Here’s the exception thrown :

[quote]#### Exception System.Exception - 0xffffffff (4) ####
#### GHIElectronics.NETMF.USBHost.USBH_RawDevice+Pipe::TransferPipe_Helper [IP: 0000] ####
#### GHIElectronics.NETMF.USBHost.USBH_RawDevice+Pipe::TransferData [IP: 001c] ####
#### FEZPhidgets.Phidget1018::_1018Thread [IP: 0039] ####
A first chance exception of type ‘System.Exception’ occurred in GHIElectronics.NETMF.USBHost.dll[/quote]

The line 39 is this one :

and the thread looks like this :

private void _1018Thread()
        {
            int count;

            while (true)
            {
                Thread.Sleep(_IF1018_Pipe.PipeEndpoint.bInterval);  // Read every bInterval
                count = 0;
                lock (IFKit)
                {
                    try
                    {
                        count = _IF1018_Pipe.TransferData(IFKit, 0, IFKit.Length);
                    }
                    catch (Exception ex)
                    {
                        //USBH_ERROR e = USBHostController.GetLastError();
                        //Debug.Print("CHG ERROR " + e);
                        Debug.Print("CHG ERROR " + ex.Message);
                        Array.Clear(IFKit, 0, IFKit.Length);
                        count = 0;
                    }
                }

I’m sure I miss something obvious, but what ? X(

Edit: I’m using the beta firmware, but it was the same with the current firmware.

It is possible that there is an interrupt EP on USB that you must read at fixed interval and if you are late then you will miss a paket which gives you “toggle error”

Here’s the USB description for this device :

[quote]Configuration Descriptor
bLength: 0x9
bDescriptorType: USB_CONFIGURATION_DESCRIPTOR_TYPE
wTotalLength: 0x22
bNumInterfaces: 0x1
iConfiguration: 0x0
bmAttributes: 0x80 ( Bus_Powered )
MaxPower: 0xFA

Interface Descriptor
bLength: 0x9
bInterfaceNumber: 0x0
bAlternateSetting: 0x0
bNumEndpoints: 0x1
bInterfaceClass: 0x3 (Human Interface Device)
bInterfaceSubClass: 0x0 (No Subclass)
bInterfaceProtocol: 0x0 (None)
iInterface: 0x0

Endpoint Descriptor
bLength: 0x7
bEndpointAddress: 0x81 [IN]
bmAttributes: 0x3 (USB_ENDPOINT_TYPE_INTERRUPT)
wMaxPacketSize: 0x8
bInterval: 0x8[/quote]

Only one EP. Very simple device, in fact.

With the help of a (software) USB tracer, I can see some things that may explain the errors. If we agree on the fact that a data PID that is not toggled can be seen as an error or at least that it’s not corresponding to real data and hence to a “device ready” state, maybe the following can throw the exceptions :

http://www.lsp-fr.com/FEZ/ScreenShot516.jpg

while this part won’t throw any exception and just work as expected :

http://www.lsp-fr.com/FEZ/ScreenShot517.jpg

If I’m right, I may then consider every toggle error as a “device not ready” information. What do you think ?

Look at “interval” in your interrupt endpoint. You must read the endpoint at the correct interval or you may see toggle errors. Now, can you just ignore the errors? I most cases yes but I do not know what is this device sending back

toggle error = lost packets because read is not fast enough

Where are the toggles in the screen shots? I cannot find them.

You’re right : there’s no toggle :frowning: What I thought being toggles is in fact the way the board is sending analog values : 2 times 4 values (analog 0-3, then analog 4-7, in 2 different packets). What I thought was the PID (first byte 0x00-0x01) is only there to tell for which analog outputs the board is sending infos…
Sorry for this misunderstanding :confused:

Btw, I’ve added a loop in my code before starting the listening thread and it seems to work as expected. The loop, which is mainly containing a try/catch block, is waiting until no error is reported.
After roughly 20 tests, I don’t have any exception in the listening thread. I know/feel this is not a very good soultion, though. But it works.

So I’m currently adding a new event to the class. It will be fired as soon as the board is ready for use. It will act like the original Phidgets code and will have the same name : Attached.
Their Open() method is asynchronous, so we have to wait for the Attached event to be thrown before using the board. Here it will be the same, even though the program won’t have access to the board before (kind of synchronous Open() ). It just won’t disturb Windows programmers.

You can download the source code for the Phidgets drivers…

for Linux: http://www.phidgets.com/downloads/libraries/libphidget_2.1.7.20100621.tar.gz
for WinCE: http://www.phidgets.com/downloads/libraries/Phidget21CEkernalsource_2.1.7.20100525.zip
for Phidgets SBC: http://www.phidgets.com/downloads/libraries/buildroot-phidgetsbc_1.0.4.20100628.tar.gz

Those might give you a better understanding of how they are packing/sending the packets…