Panda system type enum

Archive
1

The Panda GHIElectronics.NETMF.FEZ.FEZ_System.GetSystemType() return 1. Which is same as Mini. Shouldn’t that return 5 or something else?

2

The Panda uses the same processor as the Mini, so that’s the reason for it returning the same system type.

3

The system is the processor, think of it in terms of your PC. If you have the same intel i7 in 2 different brands or model of PC, it’s still going to say it’s that Intel i7 processor. It doesn’t know what hardware it is on/in.

4

There is one exception, the EMX does know the Cobra apart from the EMX dev board. If you look at the schematics, there is a resistor on the Cobra marked for Cobra identification to the EMX.

5

If so, what is the point of having system type enumeration in GHIElectronics.NETMF.FEZ

 public enum FEZ_Type
    {
        Unknown = 0,
        Mini = 1,
        Domino = 2,
        Cobra = 3,
        Rhino = 4,
    }
6

I think that enum was introduced when there was no Panda. So it is sort of a legacy thing. Worked OK when there was just a single board per proc,but now it causes the confusion.

Cheers,
Valentin

7

With the potential explosion in the variety of FEZ-alike, I’m not sure this kind of approach is very useful, because the difference in capabilities of the boards is only partly due to the processor in use.

What would the correct enumeration be for a a FEZ Hacker? What about a custom-built FEZ variant that uses a Bizi144 but hasn’t had a physical USB port implemented?

It strikes me that maybe this should be deprecated in favor or either a ‘straight’ processor enumeration (which is pretty much the point we’re at now, except it looks like it’s outgrown its usefulness) or go for a more complex ‘BoardCap’ kind of approach that explicitly records the hardware functionality that’s been exposed on the board. Hence, you’d be looking more correctly at a Enum like this:


public enum FEZ_processor 
{
unknown  = 0,
USBizi100 = 1,
USBizi144 = 2,
EMXCobra = 3,
EMX = 4
}

… with additional enumerations to cover Ethernet availability etc.

Assuming of course that the distinctions between the EMX and the ‘EMXCobra’ are not merely due to what hardware the EMX module just happens to be hooked up to based on the product shipped by GHI.

An alternative would be (of course, this is an architectural change, unless it’s already embedded somewhere in the code) - to return a string or struct in the same way as a PCI does. OTOH, I’ve only just started to wade thru’ the documentation - so these suggestions might be redundant.