MinnowBoard Max Pin Mappings
Remarque
Pour comparer ce mappage d’épingles à des versions plus récentes du Minnowboard, consultez la documentation ici.
Vue d’ensemble
Les interfaces matérielles pour MinnowBoard Max sont exposées via l’en-tête JP1 de 26 broches sur la carte. Les fonctionnalités incluent :
- 10x - Broches GPIO
- 2x - UARTs série
- 1x - Bus SPI
- 1x - Bus I2C
- 1x - Broche d’alimentation 5V
- 1x - Broche d’alimentation 3,3V
- 2x - Broches au sol
MinnowBoard Max utilise des niveaux de logique 3.3V sur toutes les broches d’E/S. En outre, toutes les broches sont mises en mémoire tampon par des shifters de niveau TXS0104E , à l’exception des broches de puissance et de sol. Ces shifters de niveau apparaissent sous forme de sorties de collecteur ouvertes avec une extraction résistive de 10 000 ko, et le pull-up est présent, que l’E/S soit définie sur entrée ou sortie.
La nature open-collector des shifters de niveau signifie que les broches peuvent générer un « 0 » fortement, mais seulement faiblement une « 1 ». Il est important de garder à l’esprit lors de l’attachement d’appareils qui dessinent le courant à partir des broches (par exemple, une LED). Consultez l’exemple Blinky pour obtenir la bonne façon d’interfacer une LED vers minnowBoard Max.
Broches GPIO
Les broches GPIO suivantes sont accessibles via des API :
GPIO# Épingle d’en-tête 0 21 1 23 2 25 3 14 4 16 5 18 6 20 7 22 8 24 9 26
Remarque : GPIO 4 et GPIO 5 sont utilisés par minnowBoard Max comme broches de configuration bootstrap pour le BIOS. Assurez-vous que les appareils attachés ne pilotent pas ces gpIO bas pendant le démarrage, car cela peut empêcher le démarrage du moM. Une fois que le MBM a démarré au-delà du BIOS, ces GPIO peuvent être utilisés normalement.
Exemple GPIO
Par exemple, le code suivant ouvre GPIO 5 en tant que sortie et écrit un « 1 » numérique sur la broche :
using Windows.Devices.Gpio;
public void GPIO()
{
GpioController Controller = GpioController.GetDefault(); /* Get the default GPIO controller on the system */
GpioPin Pin = Controller.OpenPin(5); /* Open GPIO 5 */
Pin.SetDriveMode(GpioPinDriveMode.Output); /* Set the IO direction as output */
Pin.Write(GpioPinValue.High); /* Output a digital '1' */
}
UART série
Il existe deux UARTS série disponibles sur le moM : UART1 et UART2
UART1 a les lignes UART1 TX et UART1 RX standard, ainsi que les signaux de contrôle de flux UART1 CTS et UART1 RTS.
- Épingle 6 - UART1 TX
- Épingle 8 - UART1 RX
- Épingle 10 - UART1 CTS
- Épingle 12 - UART1 RTS
UART1 ne fonctionne pas à partir de la build 10240. Utilisez UART2 ou un convertisseur USB-Serial.
UART2 inclut uniquement les lignes UART2 TX et UART2 RX.
- Épingle 17 - UART2 TX
- Épingle 19 - UART2 RX
UART2 ne prend pas en charge le contrôle de flux. Par conséquent, l’accès aux propriétés suivantes de SerialDevice peut entraîner une exception levée :
- BreakSignalState
- IsDataTerminalReadyEnabled
- IsRequestToSendEnabled
- Établissement d’une liaison : seul SerialHandshake.None est pris en charge
L’exemple ci-dessous initialise UART2 et effectue une écriture suivie d’une lecture :
using Windows.Storage.Streams;
using Windows.Devices.Enumeration;
using Windows.Devices.SerialCommunication;
public async void Serial()
{
string aqs = SerialDevice.GetDeviceSelector("UART2"); /* Find the selector string for the serial device */
var dis = await DeviceInformation.FindAllAsync(aqs); /* Find the serial device with our selector string */
SerialDevice SerialPort = await SerialDevice.FromIdAsync(dis[0].Id); /* Create an serial device with our selected device */
/* Configure serial settings */
SerialPort.WriteTimeout = TimeSpan.FromMilliseconds(1000);
SerialPort.ReadTimeout = TimeSpan.FromMilliseconds(1000);
SerialPort.BaudRate = 9600;
SerialPort.Parity = SerialParity.None;
SerialPort.StopBits = SerialStopBitCount.One;
SerialPort.DataBits = 8;
/* Write a string out over serial */
string txBuffer = "Hello Serial";
DataWriter dataWriter = new DataWriter();
dataWriter.WriteString(txBuffer);
uint bytesWritten = await SerialPort.OutputStream.WriteAsync(dataWriter.DetachBuffer());
/* Read data in from the serial port */
const uint maxReadLength = 1024;
DataReader dataReader = new DataReader(SerialPort.InputStream);
uint bytesToRead = await dataReader.LoadAsync(maxReadLength);
string rxBuffer = dataReader.ReadString(bytesToRead);
}
Notez que vous devez ajouter la fonctionnalité suivante au fichier Package.appxmanifest dans votre projet UWP pour exécuter le code UART série :
Visual Studio 2017 a un bogue connu dans le Concepteur de manifeste (l’éditeur visuel pour les fichiers appxmanifest) qui affecte la fonctionnalité de communication en série. Si votre appxmanifest ajoute la fonctionnalité de communication en série, la modification de votre appxmanifest avec le concepteur endommage votre appxmanifest (l’enfant xml de l’appareil est perdu). Vous pouvez contourner ce problème en modifiant manuellement l’appxmanifest en cliquant avec le bouton droit sur votre appxmanifest et en sélectionnant Afficher le code dans le menu contextuel.
<Capabilities>
<DeviceCapability Name="serialcommunication">
<Device Id="any">
<Function Type="name:serialPort" />
</Device>
</DeviceCapability>
</Capabilities>
Bus I2C
Examinons le bus I2C disponible sur cet appareil.
Vue d’ensemble d’I2C
Il existe un contrôleur I2C5 exposé sur l’en-tête de broche avec deux lignes SDA et SCL. 10KΩ résistances internes pull-up sont déjà présents sur ces lignes.
- Épingle 15 - I2C5 SDA
- Épingler 13 - I2C5 SCL
Exemple I2C
L’exemple ci-dessous initialise I2C5 et écrit des données sur un appareil I2C avec l’adresse 0x40 :
using Windows.Devices.Enumeration;
using Windows.Devices.I2c;
public async void I2C()
{
// 0x40 is the I2C device address
var settings = new I2cConnectionSettings(0x40);
// FastMode = 400KHz
settings.BusSpeed = I2cBusSpeed.FastMode;
// Create an I2cDevice with the specified I2C settings
var controller = await I2cController.GetDefaultAsync();
using (I2cDevice device = controller.GetDevice(settings))
{
byte[] writeBuf = { 0x01, 0x02, 0x03, 0x04 };
device.Write(writeBuf);
}
}
Problèmes I2C
Le MinnowBoard Max a un problème connu avec le bus I2C, ce qui provoque des problèmes de communication avec certains appareils I2C. Normalement, un appareil I2C accuse réception de son adresse lors d’une demande de bus. Toutefois, dans certaines conditions, cet accusé de réception ne parvient pas à se propager à travers les shifters de niveau vers le moM, et par conséquent, le processeur pense que l’appareil n’a pas répondu et annule la transaction de bus. Le problème semble être lié aux TXS0104E shifters de niveau sur les broches d’E/S, ce qui peut se déclencher prématurément en raison de pics de tension sur la ligne. La solution de contournement actuelle consiste à insérer un résistance de 100 millisecondes en série avec la ligne SCK I2C, ce qui permet de supprimer les pics. Tous les appareils ne sont pas affectés. Cette solution de contournement n’est donc requise que si vous rencontrez des difficultés pour obtenir une réponse de bus. Un appareil connu pour exiger cette solution de contournement est le HTU21D.
Bus SPI
Examinons le bus SPI disponible sur cet appareil.
Vue d’ensemble de SPI
Il existe un contrôleur SPI0 disponible sur le moM :
- Épingle 9 - SPI0 MOSI
- Épingle 7 - SPI0 MISO
- Épingle 11 - SPI0 SCLK
- Épingle 5 - SPI0 CS0
Exemple SPI
Un exemple sur l’exécution d’une écriture SPI sur bus SPI0 est illustré ci-dessous :
using Windows.Devices.Enumeration;
using Windows.Devices.Spi;
public async void SPI()
{
// Use chip select line CS0
var settings = new SpiConnectionSettings(0);
// Set clock to 10MHz
settings.ClockFrequency = 10000000;
// Create an SpiDevice with the specified Spi settings
var controller = await SpiController.GetDefaultAsync();
using (SpiDevice device = controller.GetDevice(settings))
{
byte[] writeBuf = { 0x01, 0x02, 0x03, 0x04 };
device.Write(writeBuf);
}
}