Ganglia : configuration avancée

Magazine
Marque
GNU/Linux Magazine
HS n°
Numéro
42
Mois de parution
juin 2009
Spécialité(s)


Résumé

Dans cet article, nous allons aborder des éléments de configuration un peu plus avancée comme la sécurisation, l'ajout de métrique et surtout l'automatisation de la génération des graphiques de performance.


Body

1. Sécurisation

Même si Ganglia est un logiciel ayant eu peu de failles de sécurité découvertes, par défaut, les services gmond et gmetad laissent n'importe quel utilisateur les interroger et donnent donc un inventaire des serveurs, ainsi que des métriques associées. Il existe heureusement des paramètres de configuration qui permettent d'améliorer la situation à peu de frais.

1.1 Utilisation de l'unicast

Un problème connu du multicast est l'aspect sécurité. Il est très difficile de contrôler qui accède au flux. Il n'y a pas de mécanisme prévu pour empêcher une connexion à une adresse multicast. Dans certains environnements où j'ai travaillé, le multicast était banni par l'administrateur réseau sans même que j'aille jusqu'à lui parler de Ganglia.

Il est donc conseillé d'utiliser l'unicast dans les sections udp_send_channel et udp_recv_channel de gmond.

1.2 Rendre sourd gmond

En passant l'option deaf à yes dans la section globals du fichier gmond.conf, on désactive les sections udp_recv_channel et tcp_accept_channel du fichier de configuration. Concrètement, cela signifie que le service gmond ne répondra à aucune demande d'information par TCP et n'écoutera pas le statut des autres nœuds du cluster.

Cette option ne doit pas être activée sur les nœuds gmond interrogés par le service gmetad.

1.3 Mise en place des ACL

Pour sécuriser les connexions des nœuds sur lesquels gmond ne peut pas être sourd, il est possible de spécifier des ACL dans les sections udp_recv_channel et tcp_accept_channel.

Pour udp_recv_channel, si vous disposez d'un réseau dédié, on peut se contenter d'autoriser uniquement ce réseau en ajoutant cette entrée dans la section :

acl {

default = "deny"

access {

ip = 10.111.111.0

mask = 24

action = "allow"

}

}

Ici, on autorise gmond à écouter toutes les machines du réseau 10.111.111.0/24 en UDP.

Pour tcp_accept_channel, le seul serveur ayant besoin de l'interroger est celui hébergeant gmetad. La règle est donc encore plus simple :

acl {

default = "deny"

access {

ip = 10.111.111.110

mask = 32

action = "allow"

}

}

Ici, le serveur feddy10 a l'adresse IP 10.111.111.110.

1.4 Interface web

Je passerais sur toutes les possibilités de sécurisation possibles d'un serveur web, mais elles peuvent évidemment s'appliquer ici.

L'interface web dispose aussi d'un moyen de rendre l'accès à certains clusters dépendant d'un mot de passe. Dans le fichier /usr/share/ganglia/private_clusters, il faut mettre une ligne de ce type par cluster :

<nom_cluster> = <mot de passe au format md5>

Pour générer un mot de passe au format md5 sous Linux :

$ echo -n « test » |md5sum

098f6bcd4621d373cade4e832627b4f6 -

Si l’on prend l'exemple du cluster mes_serveurs et le mot de passe test, il faut ajouter la ligne suivante :

mes_serveurs = 098f6bcd4621d373cade4e832627b4f6

Ganglia demandera un compte et mot de passe pour accéder aux pages concernant ce cluster. Le nom de compte est le nom du cluster. Un joli message « This is a private cluster. » apparaîtra sur la page du grid si le grid est composé de plusieurs clusters.

2. Ajout de métriques

2.1 La commande gmetric

La commande gmetric permet de spécifier en ligne de commande des métriques supplémentaires. L'avantage est que la commande est très simple et s'intègre facilement dans un script shell.

Le paramètre --type permet de spécifier le type de valeur que l'on va passer. gmetric permet de spécifier des entiers et des flottants de différentes tailles et signés ou non. La liste des types disponibles est dans le man de la commande.

Le paramètre --value donne la valeur de la métrique et --name spécifie le nom de la métrique. À chaque nouveau nom, gmetad crée la base RRD correspondante.

Par exemple, voici un script pour ajouter une métrique indiquant le nombre de sessions ssh ouvertes :

#!/bin/bash

###

### STATISTIQUES SUR SESSIONS SSH

###

gmetric="/usr/bin/gmetric"

### Nombre total de sessions SSH

sessions=$(ps -ef|grep -v grep|grep -ice "ssh.*pts")

$gmetric --name=ssh_sessions --value=$sessions --type=uint8 --units=sessions

Un côté pratique de gmetric est qu'il n'est pas nécessaire de spécifier l'intervalle de temps entre chaque mesure. gmetad calcule lui-même tout ça.

Il suffit donc d'ordonnancer le job en Crontab, ici toutes les 5 minutes :

*/5 * * * * /usr/local/bin/ganglia_ssh_sessions.sh

La commande peut être exécutée par un utilisateur lambda. Il a uniquement besoin de pouvoir lire le fichier gmond.conf. Pensez à adapter les droits du fichier si la sécurisation de Ganglia est une préoccupation pour vous.

Le graphique est automatiquement ajouté à la page concernant le serveur.

2.2 Par modules Python

gmetric est très pratique, mais lorsqu'on l'utilise de manière assez intensive, on se retrouve vite avec des dizaines de métriques supplémentaires et cela devient vite une corvée de maintenir tous les scripts et tous les ordonnancements sur chaque serveur. De plus, on aimerait bien avoir certaines métriques avec une précision de l'ordre de la dizaine de secondes.

C'est pour cela qu'à partir de la version 3.1 de Ganglia a intégré officiellement le support des modules Python et C (il était possible de les incorporer avant, mais de manière moins évidente).

On va décrire la mise en place d'un module Python qui indique le nombre de pages mémoire allant dans le paging space. Ganglia, vu son orientation HPC, manque de métrique par défaut pour mesurer l'activité disque des systèmes.

Sous Fedora, il est nécessaire d'installer le package ganglia-gmond-python.

On va commencer par créer le fichier pgspin.py dans le répertoire /usr/lib/ganglia/python_modules. Voici le contenu du script (pour des questions de lisibilité, le code de gestion d'erreur/exception a été supprimé) :

import os

import time

# temps d'attente entre les mesures

_wait_secs = 5

# fonction de lecture du fichier /proc/vmstat

# prend en parametre le metrique que l'on souhaite

# et retouren sa valeur

def read_vmstat(stat):

vmstat_file = "/proc/vmstat"

vmstats = {}

if os.path.exists(vmstat_file):

fp = open( vmstat_file, 'r' )

lines = fp.readlines()

fp.close()

for line in lines:

(key,val) = line.split()

vmstats[key] = val

return int( vmstats[stat] )

#fonction _handler necessaire pour gerer metrique pswpin

def pswpin_handler(name):

pswpin = {}

#premiere mesure

pswpin['val1'] = read_vmstat('pswpin')

# on attend wait_secs secondes

time.sleep(_wait_secs)

#seconde mesure

pswpin['val2'] = read_vmstat('pswpin')

return int(pswpin['val2'] - pswpin['val1'] / _wait_secs)

# fonction d'initialisation du metrique

def metric_init(params):

global descriptors

#recuperation de la valeur wait_secs a partir du fichier de conf

if 'wait_secs' in params:

_wait_secs = int(params['wait_secs'])

# description du metrique

d1 = {'name': 'pswpin',

'call_back': pswpin_handler,

'time_max': 90,

'value_type': 'uint',

'units': 'p/s',

'slope': 'both',

'format': '%u',

'description': 'Paging Space in',

'groups': 'io'}

descriptors = [d1]

return descriptors

#fonction de nettoyage du metrique

def metric_cleanup():

pass

Un script Python doit contenir trois fonctions spécifiques pour pouvoir être utilisé comme un module par Ganglia.

La fonction metric_init qui décrit les métriques produites par le module à travers la variable descriptor. Ici, une seule métrique est fournie par le module, mais il est possible d'en fournir plusieurs. C'est aussi dans cette fonction que l'on récupère les valeurs passées à travers le fichier de configuration.

Les paramètres pour chaque métrique sont similaires à ceux de la commande gmetric. On ne s'étendra donc pas dessus. Le paramètre call_back par contre spécifie le nom de la deuxième fonction nécessaire au module. Ici, elle se nomme pswpin_handler, mais le nom est à la discrétion du créateur. L'important est qu'une fonction portant le nom défini dans le paramètre call_back existe et dispose d'une valeur en retour. C'est elle qui doit retourner la valeur de la métrique à gmond.

La dernière fonction est metric_cleanup et contient les opérations de nettoyage nécessaires lors de l'arrêt.

En dehors de ces 3 fonctions, on peut définir autant de fonctions que l'on veut. Ici, la fonction read_vmstat a été définie pour aller lire le fichier /proc/vmstat sous Linux et renvoyer la valeur pour le champ que l'on passe en paramètre.

On peut aussi charger les bibliothèques Python disponibles sur le système dont on a besoin. Ici, os pour tester l'existence du fichier /proc/vmstat et time pour pouvoir utiliser la fonction sleep.

Il est aussi nécessaire de créer un fichier de configuration dans le répertoire /etc/ganglia/conf.d avec une extension .pyconf.

modules {

module {

name = "pgsp"

language = "python"

param wait_secs {

value = 1

}

}

}

collection_group {

collect_every = 30

time_threshold = 10

metric {

name = "pswpin"

title = "Paging Space in"

}

}

Le fichier se décompose en deux sections :

- La section modules qui permet de spécifier le nom du module Python. Ici, name=pgsp indique que le nom du fichier est pgsp.py. L'extension n'est pas prise dans le nom.

language indique que le module a été écrit en Python. Il est possible de faire passer des paramètres au module sous la forme :

param <nom param> {

value = <le type de données que l'on désire>

}

- La section collection_group qui détermine la fréquence d'interrogation des métriques en secondes grâce au paramètre collect_every et spécifie dans chaque sous-section le nom de la métrique que l'on souhaite collecter ainsi qu'une description de la métrique.

L'exemple ci-dessus pourrait être largement amélioré en utilisant des threads et en rendant persistant la collecte des données, mais cela déborderait du cadre de l'article. Un bon exemple pour aller plus loin est le module tcpconn.py fourni en standard.

3. Génération automatisée de rapports

Il est très intéressant de pouvoir accéder rapidement aux diagrammes de performance de ces serveurs. Un outil de ce type devient donc assez vite populaire. Et, avec la popularité, viennent rapidement les notions de capacity planning et les fameuses demandes de rapport de performance. Bien que l'interface web soit plutôt pratique d'utilisation, il devient vite fastidieux de générer plusieurs graphiques par serveur surtout si l'on a un parc de plusieurs dizaines voire centaines de serveurs. Nous allons voir comment réaliser cela d'une manière automatisée.

3.1 Mode debug interface web

L'automatisation est possible grâce au mode debug.

Les scripts de l'interface web de Ganglia sont prévus pour fournir un mode debug qui donne la commande rrdtool utilisée pour générer le graphique.

Dans le fichier graph.php, il suffit de modifier la ligne :

$debug = 0;

par :

$debug = 1;

Cela fait en sorte que les graphiques soit remplacés par un lien pointant sur la page contenant la commande rrdtool qui génère le graphique.

 

ganglia_debug

 

Fig. 1

Voici un exemple de commande pour le graphique de l'activité réseau :

/usr/bin/rrdtool graph - --start 'Jan 18 2009 15:00' --end 'Jan 18 2009 16:00' --width 1000 --height 600 --lower-limit 0 --rigid --title 'osol Packets last custom' --vertical-label 'Packets/sec' --base 1024 --color BACK#'ffffff' DEF:'bytes_in'='/ganglia/rrds/mes_serveurs/osol/bytes_in.rrd':'sum':AVERAGE DEF:'bytes_out'='/ganglia/rrds/mes_serveurs/osol/bytes_out.rrd':'sum':AVERAGE LINE2:'bytes_in'#33cc33:'In' LINE2:'bytes_out'#5555cc:'Out'

On obtient la syntaxe exacte de la commande.

Les personnes connaissant rrdtool peuvent penser qu'il n'est pas nécessaire de passer par le mode debug pour générer ce type de graphique. Si cela n'est pas tout à fait faux pour certains graphiques standards, l'intérêt du mode debug prend tout son sens quand on voit que l'addon custom_graph dispose aussi de cette fonction.

Il suffit d'effectuer la même modification que précédemment dans le fichier addons/custom_graph_processing.php.

On obtient ainsi littéralement une interface de développement pour des graphiques exploitant au mieux les fonctionnalités de rrdtool.

Voici un exemple de commande rrdtool reprenant les débits réseau en entrée/sortie sur une période de 1 mois :

usr/bin/rrdtool graph - --start 'Dec 18 2008 00:00' --end 'Jan 18 2009 23:59' \

--width 895 --height 295 --lower-limit 1 –rigid \

--title 'debit reseau (Dec 18 2008 00:00 till Jan 18 2009 23:59)' \

COMMENT:"\t\t\t" COMMENT:"Minimum " COMMENT:"Average " COMMENT:"Maximum\n"\ DEF:'bytes_in'='/ganglia/rrds/mes_serveurs/osol/bytes_in.rrd':sum:AVERAGE \

AREA:'bytes_in'#0000FF:'bytes_in':STACK VDEF:'bytes_inmin'=bytes_in,MINIMUM \

VDEF:'bytes_inavg'=bytes_in,AVERAGE VDEF:'bytes_inmax'=bytes_in,MAXIMUM \ GPRINT:'bytes_inmin':"%12.2lf" GPRINT:'bytes_inavg':" %10.2lf" \

GPRINT:'bytes_inmax':" %10.2lf\n" \ DEF:'bytes_out'='/ganglia/rrds/mes_serveurs/osol/bytes_out.rrd':sum:AVERAGE \ AREA:'bytes_out'#FF0000:'bytes_out':STACK VDEF:'bytes_outmin'=bytes_out,MINIMUM \ VDEF:'bytes_outavg'=bytes_out,AVERAGE VDEF:'bytes_outmax'=bytes_out,MAXIMUM \ GPRINT:'bytes_outmin':"%11.2lf" GPRINT:'bytes_outavg':" %10.2lf" \

GPRINT:'bytes_outmax':" %10.2lf\n"

 

ganglia_custom_graph

 

Fig. 2 : Options d'un graphique customisé

La syntaxe de rrdtool devient tout de suite plus complexe. Il suffit de regarder la capture d'écran du menu custom_graph pour imaginer le gain de temps obtenu.

Il faut savoir que l'on peut choisir toutes les métriques disponibles d'un serveur, effectuer des calculs dessus et choisir l'aspect du graphique.

On obtient ainsi un outil permettant d'exploiter de manière « simple » les bases RRD.

3.2 Automatisation

Une fois la commande rrdtool au point, il devient facile d'automatiser la génération des graphiques.

Si l’on reprend le cluster de l'article précédent, les bases rrds se trouvent dans /ganglia/rrds. Sous ce répertoire, se trouvent l'ensemble des clusters définis dans gmetad. On trouvera donc un répertoire mes_serveurs qui lui-même contient un répertoire portant le nom de chaque serveur faisant partie du cluster. Ces répertoires contiennent les bases rrds de chaque métrique. Il y a aussi un répertoire __SummaryInfo__ qui contient les bases rrds des données consolidées du grid et des clusters.

Voici l'arborescence des répertoires pour notre cluster :

/ganglia/rrds/mes_serveurs

/ganglia/rrds/mes_serveurs/feddy10

/ganglia/rrds/mes_serveurs/__SummaryInfo__

/ganglia/rrds/mes_serveurs/osol

/ganglia/rrds/mes_serveurs/debian

/ganglia/rrds/__SummaryInfo__

Si l’on prend comme exemple la commande rrdtool précédente, on repère assez rapidement les constantes suivantes :

- –start 'Dec 18 2008 00:00' : date de début ;

- –end 'Dec 18 2009 23:59' : date de fin ;

- –title ” debit reseau (Dec 18 2008 00:00 till Jan 18 2009 23:59) ” : titre du graphique.

On voit les modifications à faire pour automatiser cela.

Il y a aussi deux lignes définissant les bases RRD sources :

DEF:''bytes_in'='/ganglia/rrds/mes_serveurs/osol/bytes_in.rrd':sum:AVERAGE

DEF:'bytes_out'='/ganglia/rrds/mes_serveurs/osol/bytes_out.rrd':sum:AVERAGE

Ces lignes contiennent le nom du serveur dans le chemin. Il reste à créer un script générant exactement le même graphique pour l'ensemble des serveurs d'un cluster.

Voici un script simple qui génère les graphiques dans /ganglia/report :

#!/bin/bash

# 1er parametre: nom du cluster

CLUSTER=$1

# 2eme parametre: date debut

STARTDATE=$2

# 3eme parametre: date de fin

ENDDATE=$3

#repertoire contenant les bases RRD

RRDDIR=/ganglia/rrds

#conversion des dates pour creer un repertoire

DATEDIR=$(echo "${STARTDATE}_to_${ENDDATE}"|sed 's/ /_/g')

#creation du repertoire du rapport

mkdir -p /ganglia/report/${CLUSTER}/${DATEDIR}

cd $RRDDIR

# generation du graphique pour tout les serveurs du cluster

for i in $(ls $CLUSTER|grep -v "__")

do

/usr/bin/rrdtool graph - --start "$STARTDATE" --end "$ENDDATE" \

--width 350 --height 200 --lower-limit 0.1 --rigid \

--title " ($i network report)" \

COMMENT:"\t\t\t" COMMENT:"Minimum " COMMENT:"Average " COMMENT:"Maximum\n" \

DEF:'bytes_in'="${RRDDIR}/${CLUSTER}/$i/bytes_in.rrd":sum:AVERAGE \

AREA:'bytes_in'#0000FF:'bytes_in':STACK VDEF:'bytes_inmin'=bytes_in,MINIMUM \

VDEF:'bytes_inavg'=bytes_in,AVERAGE VDEF:'bytes_inmax'=bytes_in,MAXIMUM \

GPRINT:'bytes_inmin':"%12.2lf" GPRINT:'bytes_inavg':" %10.2lf" \

GPRINT:'bytes_inmax':" %10.2lf\n" \

DEF:'bytes_out'="${RRDDIR}/${CLUSTER}/$i/bytes_out.rrd":sum:AVERAGE \

AREA:'bytes_out'#FF0000:'bytes_out':STACK VDEF:'bytes_outmin'=bytes_out,MINIMUM \

VDEF:'bytes_outavg'=bytes_out,AVERAGE VDEF:'bytes_outmax'=bytes_out,MAXIMUM \

GPRINT:'bytes_outmin':"%11.2lf" GPRINT:'bytes_outavg':" %10.2lf" \

GPRINT:'bytes_outmax':" %10.2lf\n" > /ganglia/report/${CLUSTER}/${DATEDIR}/${i}_net.png

done

Voici un exemple d'utilisation pour le cluster mes_serveurs :

./ganglia_report.sh mes_serveurs "Dec 18 2008 00:00" "Jan 18 2009 23:59"

3.3 Extension de l'interface web

Le script shell permet d'automatiser la génération de graphiques dans le but de faire des rapports, mais il est aussi possible de générer ses propres pages PHP pour étendre l'interface web.

Le code PHP d'une page doit être du type :

<?php

header("Content-type: image/gif");

passthru($command);

?>

Et, comme on peut s'en douter, $command correspond exactement à la sortie que l'on obtient avec le mode debug précédemment évoqué. On peut ainsi mettre en place des pages PHP qui génèrent directement les graphiques que l'on a mis au point dans l'interface custom_graph.

On peut aussi passer des paramètres au script PHP. Voici un exemple qui montre comment contourner une limitation de Ganglia qui empêche de consolider les données de serveurs de différents clusters. En se basant sur les éléments précédents, nous allons créer une nouvelle page PHP corrigeant ce problème.

En considérant que le serveur Debian fait partie du cluster debians et que le serveur feddy10 fait partie du cluster mes_serveurs, on obtient le code PHP suivant :

<?php

# recuperation du parametre mois

$month = isset($_GET["m"]) ?

escapeshellcmd( rawurldecode( $_GET["m"] )) : NULL;

$rrddir = "/ganglia/rrds";

$startdate = "$month 01 2009 00:00";

$enddate = "$month 31 2009 23:59";

#definition du titre

$title = "$month debian and feddy10 network report";

#definition des bases rrd sources

$debian_in = "$rrddir/debians/debian/bytes_in.rrd";

$debian_out = "$rrddir/debians/debian/bytes_out.rrd";

$fedora_in = "$rrddir/mes_serveurs/feddy10/bytes_in.rrd";

$fedora_out = "$rrddir/mes_serveurs/feddy10/bytes_out.rrd";

#entete html

header("Content-type: image/gif");

passthru("/usr/bin/rrdtool graph - --start '$startdate' --end '$enddate' --width 1000 --height 600 --lower-limit 0 --rigid --title '$title' --vertical-label 'Bytes/sec' --base 1024 DEF:'debian_in'='$debian_in':'sum':AVERAGE AREA:'debian_in'#0000FF:'debby_in':STACK DEF:'debian_out'='$debian_out':'sum':AVERAGE AREA:'debian_out'#FF0000:'debby_out':STACK DEF:'fedora_in'='$fedora_in':'sum':AVERAGE AREA:'fedora_in'#FFA500:'feddy_in':STACK DEF:'fedora_out'='$fedora_out':'sum':AVERAGE AREA:'fedora_out'#4682B4:'feddy_out':STACK

");

?>

Ce code PHP ne prend en paramètre que le mois de génération du rapport, mais l'idée est là. Il suffit de définir les métriques sur lesquelles on se base pour générer cela.

À noter l'utilisation de label si on le souhaite, ici pour changer les noms des métriques dans la légende.

La syntaxe est du type :

AREA:'<source>':#<code couleur>:'<label>:STACK

Le code PHP de l'interface web est suffisamment clair pour être facilement extensible. Il y a des exemples des modifications nécessaires dans l'interface web customisé. Il suffit de comparer le fichier graph.php et graph.php.POWER5 qui inclut des graphiques spécifiques à l'architecture POWER5.

3.4 Scribus

Un petit mot pour conseiller Scribus à ceux qui sont intéressés par la génération de rapports de performance. Scribus est un logiciel de PAO libre de qualité professionnelle. L'avantage de l'utilisation d'un outil de ce type pour générer des rapports est qu'il est possible de positionner un cadre pour les images. Cela permet de positionner exactement les images sur une page.

Mais, son véritable point fort en ce qui nous concerne est le fait que Scribus ne stocke pas directement les images dans son format de fichier, mais juste le chemin d'accès au fichier. Donc, dans le cadre de génération de rapports mensuels, il suffit de changer les images du mois précédent par les nouvelles pour que le document soit mis à jour automatiquement.

Je ne connais pas de méthode plus rapide à ce jour. Il suffit juste de remplacer les commentaires. Et on peut utiliser OpenOffice pour écrire ces textes.

4. Conclusion

Ce deuxième article a essayé de couvrir quelques-unes des possibilités de Ganglia qui font que ce logiciel est ma solution de choix pour la surveillance système. J'apprécie beaucoup ses capacités d'adaptation et son coté « tout terrain » qui ne le limite pas à un OS. Bien que j'ai essayé d'être relativement complet, il reste encore beaucoup de choses à dire sur les possibilités de Ganglia et de rrdtool. Je vous invite à suivre les liens mis en annexe pour approfondir le sujet.

Références

- http://ganglia.sourceforge.net/gmetric/ : contient des scripts utilisant gmetric

- http://www.ibm.com/developerworks/wikis/display/WikiPtype/ganglia : article DeveloperWorks sur Ganglia.

- http://oss.oetiker.ch/rrdtool/ : le site de RRDtool

 



Article rédigé par

Les derniers articles Premiums

Les derniers articles Premium

Cryptographie : débuter par la pratique grâce à picoCTF

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

L’apprentissage de la cryptographie n’est pas toujours évident lorsqu’on souhaite le faire par la pratique. Lorsque l’on débute, il existe cependant des challenges accessibles qui permettent de découvrir ce monde passionnant sans avoir de connaissances mathématiques approfondies en la matière. C’est le cas de picoCTF, qui propose une série d’épreuves en cryptographie avec une difficulté progressive et à destination des débutants !

Game & Watch : utilisons judicieusement la mémoire

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Au terme de l'article précédent [1] concernant la transformation de la console Nintendo Game & Watch en plateforme de développement, nous nous sommes heurtés à un problème : les 128 Ko de flash intégrés au microcontrôleur STM32 sont une ressource précieuse, car en quantité réduite. Mais heureusement pour nous, le STM32H7B0 dispose d'une mémoire vive de taille conséquente (~ 1,2 Mo) et se trouve être connecté à une flash externe QSPI offrant autant d'espace. Pour pouvoir développer des codes plus étoffés, nous devons apprendre à utiliser ces deux ressources.

Raspberry Pi Pico : PIO, DMA et mémoire flash

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Le microcontrôleur RP2040 équipant la Pico est une petite merveille et malgré l'absence de connectivité wifi ou Bluetooth, l'étendue des fonctionnalités intégrées reste très impressionnante. Nous avons abordé le sujet du sous-système PIO dans un précédent article [1], mais celui-ci n'était qu'une découverte de la fonctionnalité. Il est temps à présent de pousser plus loin nos expérimentations en mêlant plusieurs ressources à notre disposition : PIO, DMA et accès à la flash QSPI.

Les listes de lecture

8 article(s) - ajoutée le 01/07/2020
Découvrez notre sélection d'articles pour faire vos premiers pas avec les conteneurs, apprendre à les configurer et les utiliser au quotidien.
11 article(s) - ajoutée le 02/07/2020
Si vous recherchez quels sont les outils du DevOps et comment les utiliser, cette liste est faite pour vous.
8 article(s) - ajoutée le 02/07/2020
Il est essentiel d'effectuer des sauvegardes régulières de son travail pour éviter de perdre toutes ses données bêtement. De nombreux outils sont disponibles pour nous assister dans cette tâche.
Voir les 49 listes de lecture

Abonnez-vous maintenant

et profitez de tous les contenus en illimité

Je découvre les offres

Déjà abonné ? Connectez-vous