I’m writing a completely managed layer that pinvokes to the FTD2XX api. I have noticed that the pinouts declared on the schematic are different to the ones in the LnxS4 header file. which one, if either, are correct?
FTDI already has a managed NET Wrapper class for the FTD2XX DLL developed. See C# Examples - FTDI.
The managed wrapper can be downloaded from here.http://www.ftdichip.com/Support/SoftwareExamples/CodeExamples/CSharp/FTD2XX_NET_v1.0.14.zip
I have been using it for a while now and it is fairly straight forward.
let me rephrase, what are the correct FTD pinout to gadgeteer socket pins?
I know there is a managed FTD dll, that’s not my issue.
@ eddie_garmon - you can get these though the schematics but ideally you do not need to since the Software we provide maps the pins for you, even map virtual pins when you add a hub. So when you need to access pin 3 on socket 5, you just ask the library for it.
Welcome to the community.
Thanks for the welcome.
@ eddie_garmon - If you do not come right with the schematics, you can take a look at the code for the native library to get the pin mappings.
FEZLynxS4.h - Contains the definitions of the pins ie. pin name defined as the pin number
FEZLynzS4.cpp - Has a mapping of the pins to each socket, you can find this in the create_sockets() function.
For example
Socket 1:
From FEZLynxS4.h
static const cpu_pin DD4 = 16 * 3 + 4;
static const cpu_pin DD5 = 16 * 3 + 5;
static const cpu_pin DD6 = 16 * 3 + 6;
static const cpu_pin AD4 = 16 * 0 + 4;
static const cpu_pin AD5 = 16 * 0 + 5;
static const cpu_pin AD6 = 16 * 0 + 6;
static const cpu_pin AD7 = 16 * 0 + 7;
From FEXLynxS4.cpp
socket s1(1, socket::types::Y | socket::types::A);
s1.pins[3] = fez_lynx_s4::pins::DD4;
s1.pins[4] = fez_lynx_s4::pins::DD5;
s1.pins[5] = fez_lynx_s4::pins::AD4;
s1.pins[6] = fez_lynx_s4::pins::DD6;
s1.pins[7] = fez_lynx_s4::pins::AD5;
s1.pins[8] = fez_lynx_s4::pins::AD6;
s1.pins[9] = fez_lynx_s4::pins::AD7;
So you see that socket 1, pin 3 maps to MCU pin 52 (16 * 3 + 4) etc.
Yes,I understand that. And those number have changed this week also. and they still do not map to the pins in the schematic after decoding with FTDI_PIN macro
in the header file, don’t bother looking at the numeric value of the pin when trying to match with the schematic, use the [em]name [/em]of the pin in the header. Example:
in OLD .h file:
// Standard Pins Port A //
///////////////////////////////
static const CPUPin PA_0 = ((8 * 0) + 1);
static const CPUPin PA_1 = ((8 * 0) + 2);
static const CPUPin PA_2 = ((8 * 0) + 3);
static const CPUPin PA_3 = ((8 * 0) + 4);
static const CPUPin PA_4 = ((8 * 0) + 5);
static const CPUPin PA_5 = ((8 * 0) + 6);
static const CPUPin PA_6 = ((8 * 0) + 7);
static const CPUPin PA_7 = ((8 * 0) + 8);
decrypting: "PA_3"
P - ignore, prefix for pin
A - ADBUS
3 - Pin on ADBUS
===> pin 19 AD3/CS
===> LED on board
//////////////////////////////////////////////////////////////
int main()
{
FEZLynxS4 board;
for (;;) {
DigitalOutput(FEZLynxS4::Pins::PA_3,false);
System::SleepMicro(1*1000*1000);
DigitalOutput( FEZLynxS4::Pins::PA_3,true);
System::SleepMicro(1*1000*1000);
}
return 0;
}
in NEW (I GIT pulled today):
static const cpu_pin AD0 = 16 * 0 + 0;
static const cpu_pin AD1 = 16 * 0 + 1;
static const cpu_pin AD2 = 16 * 0 + 2;
static const cpu_pin AD3 = 16 * 0 + 3;
static const cpu_pin AD4 = 16 * 0 + 4;
static const cpu_pin AD5 = 16 * 0 + 5;
static const cpu_pin AD6 = 16 * 0 + 6;
static const cpu_pin AD7 = 16 * 0 + 7;
decrypting: "AD3"
AD - ADBUS
3 - Pin on ADBUS
Edit: code block markers around blinking LED
Edit: 2 new naming scheme
thanks Jeff. any reason you are not using branches? that’s what they are designed for. and with git you can set remotes to each ghi internal repo to share without polluting the public repo.
Given the magnitude of flux of both the structure and APIs, we decided it was most expedient (given our work-flow) to just move ahead. The beta sdk I published, was tagged with “v1.0”
P.S. this is really the first time we’ve exposed one of our git repositories to the public so we are learning as we go. I appreciate your pointers, keep 'em coming.
i’m not complaining about access. I love it 
suggestion about private branch sharing moving forward:
create an “internal origin” by copying one of your repos to an internal network share.
both you and john should add that remote, maybe as “internal”
then you can branch/merge and push/pull all day safely.
when pushing to bitbucket, I would recommend the following:
whatever master is, should be the stable release
if you want to push code for review, that should be in separate branch
also, you have a lot of line-ending issues in your repo currently.
mostly with *.ino files (which I would explicitly configure as text) but there are others.
I would use text and not text=auto
see this link for a quick pointer on how to clean it up:
thanks Jeff, I got it all together now, and filed one bug against the schematic in the tracker.