Im confused about CPU.PIN #'s in GHI.PIN’s and how they relate to the physical CPU pin #'s,
For example,
I have a button wired up on GHI.Pins.G80.Gpio.PE0 that is working correctly on the dev board and when pushed is being read correctly.
Its connected to PE0 which is physically pin 97 on the G80 SOC
[url]http://www.ghielectronics.com/downloads/schematic/G80_Dev_Board_SCH.pdf[/url]
But looking at the definition for
```cs]public const Cpu.Pin PE0 = (Cpu.Pin)64;[/code
it is equal to 64?
How can CPU.PIN 64 some how magically get mapped to physical pin 97???
Why?
“Why does the Microsoft.SPOT.Hardware.Cpu.Pin number have no relation to the CPU’s physical Pin number, and where is that translation instide the Net MF done?” I would have though it was the reason for the GHI.Pins.[CHIP].Gpio enum ? But is there yet another translation done when Read/Write to ports which converts to Pin# there?
It confuses me, as if I want to debug a phycically connected device, say to PE0 on the G80 chip, which is phy pin #97, the enum for for G80 in GHI.Pins.G80.Pins is (Cpu.Pin)64 ???
Even MS remarks on mapping GPIO pins seems to suggest a one to one mapping when implimenting the enum for a particular chip?
[quote]Remarks
Because pin assignments are implementation-specific, this enumeration defines only constant for the first 16 pins and well as GPIO_NONE. When the SDK is ported to a specific hardware platform, it is expected that those who do the port will use this enumeration as the basis of an enumerated type for that platform that defines the GPIO pin assignments. Doing so will enable the platform-specific enumeration to be cast to the type Cpu..::..Pin. In this way, all SDK methods maintain type safety while still enabling full portability.
[/quote]
PE0 is the pin name you want to use. Arbitrarily (not really), PE0 happens to be at some random location around the physical processor, but it doesn’t have to be. Many processors have the same pin available on multiple chip packaging format, but you can be almost sure it won’t be in the same physical location. PE0 is the important name you want, not where it’s exposed. PE0 will always be PE0, whereas once that pin gets routed out to a header or a connector on a physical device, that’s totally at the whim of the person doing the layout, so again it’s physical location is irrelevant, it’s the logical PE0 signal that’s important.
In NETMF, PE0 gets mapped to a CPU.Pin number that is mapped by the person producing the NETMF port. With the STM32F4’s, there’s a common equation that helps you figure out the cpu.pin, but again if you just use the GHI.Pins enums there’s no chance of confusion - PE0 will be PE0 no matter if you’re using the G80Dev board or a Panda3 or a Raptor. It’s physical location will be different, but that’s documented on the board.
Its physical location of course matters. OK, As a hardware guy I have a CPU, I have a Schematic diagram.
Im connecting up some electronics to port PE0.
I go to test it… nothing happens…
OK, so whats wrong, my hardware or my code???
I have PE0, it says on the Schematic it goes to Pin 97, great!
Look throug the code and I discover Cpu.Pin PE0 = (CPU.Pin) 64 ??? HUH? its not pin 64, but pin 97, so for this to work there must be some other mapping translation some where… Where is it??? How do I see it?
What my next step in fault finding this? This is my question.
I tottally get CPU pins get assigned different pins for different case design packages.
And when you use machine code to send output on a port, you use the port number (not the Pin #)
Sure.
But why does .Net MF have this CPU.Pin = # if it doesnt relate to CPU pin numbers?
(My Guess is the Pin # does not match the actual pin # becuase of the first GPIO pins are assigned int he frame work by Microsoft 0-15,
and what the # actuall represents is just a enum index, and its not meant to represent the actual Cpu Pin #, even though they have called it that as a variable name)
But its confusing me from looking at it from a Hardware First Prospective when trying to fault find… so I just want to understand it
If you look at the schematic, and you instantly go to “pin 97”, then you’re looking in the wrong place (edit: and by this I think you should be looking at hardware first )
You want to look at the point where the signal in question is on a physical pin / header where you can join something to that signal.
CPU.Pin in NETMF is an abstraction. It’s there so you don’t need to think about the processor’s pinout. Many processors will also let you remap functions to the external pin, so there’s even less value in knowing the pinout.
Think of the sequence of abstractions in this way… The dev board you have in front of you maps the processors pins to physical locations on hardware; it abstracts the processor pin ID away from you so you need not worry about it. The GHI.Pins mapping abstracts you knowing anything about a CPU.Pin value, because the GHI team made some decisions when they built the firmware that you don’t need to know.
So, back to PE0. From everything I can see, that pin is not exposed on the dev board. Why did you start wanting to use it? I simply opened the schematic PDF and searched for PE0, and got nothing (other than the pin on the processor), which means it’s not routed anywhere. You really need to just look at the headers on the schematic - it’ll show you what is “user accessible”.
Hi,
must start from the mnemonic of the pin as shown in the diagrams of the various modules.
The PE0 to which you refer is the pin 97 of the G80 soc (and has as UART8-RX features), starting from this pin patterns:
in G80TH version is not connected to anything
in FezPanda 3 is connected to X3 34-pin connector and so you can find it in FezPanda 3 pins enum.
in the dev board is internally connected to BTN1 user button and is not connected to X11 connector.
(edit: and by this I think you should be looking at hardware first )