It was my intention to copy an existing page 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.
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
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]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
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
Just FYI, I’ve got a very positive answer from Phidgets guys 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 ?
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
glad to see I’m not the only loony that is using Phidgets with FEZ
As for the answer, I’m still getting this error (many times) during a period at the beginning of execution
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
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
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
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]
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”
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 :
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
You’re right : there’s no toggle 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
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.