uneTanche a écrit 17 commentaires

Merci pour ce retour riche en explications :D
Je vais mettre à jour mon article avec vos informations.

En effet, ma comparaison se limite à la partie simulation, ce qui ne représente qu'une partie des possibilité de matlab/simulink.

Un autre "bon point" pour Mathworks par rapports à de nombreux autres éditeurs de logiciel métier: ils proposent une version linux.

À titre pro et perso, j'ai d'ores et déjà remplacé le build système CMake par zig pour les projets embarqués. La gestion des dépendances via build.zig.zon et le système de cache en local est vraiment très appréciable. Le seul point problématique pour le moment est l'absence de compile_commands.json mais c'est en cours d'intégration.

En effet, c'est quelque chose de pénible.

Personnellement, pour python, j'essaie de gérer ça en limitant les dépendances et en ayant une copie local du dépôt (je n'y arrive pas toujours d'ailleurs).
Python propose aussi un système de "cache" pour gérer les dépendances mais je n'ai pas encore eu le temps de regarder de ce côté…

Merci 8-)

Pour le coup, je n'ai pas poussé assez loin mon expérimentation pour répondre à ta question. Tu parles d'utiliser printf pour sortir des logs sur une ligne d'UART ?

Merci pour ton commentaire. En effet, dans ce bout de code isolé le volatile n'est pas nécessaire. Mais l'idée était de faire une attente non bloquante, donc venir comparer régulièrement la valeur de COUNT avec une valeur de référence.

Par exemple:

static int count = 0;

// IRQ
void foo() {
    count+=1;
}

int main(){
    int a = 0;
    for(;;){
        if(count > 10){
            a = 10;
        }
    }
    return 0;
}

Et dans ce cas le volatile me semble indispensable.

Pour la remarque b, c'est aussi vrai. Cependant dans notre cas, il n'y a que l'interruption qui modifie la valeur de COUNT, tous les autres accès ne sont qu'en lecture.

C'est aussi ce que j'en ai déduit. Cependant, je n'ai pas trouvé comment utiliser matplotlib avec cette contrainte.
Je vais creuser encore de ce côté.

Merci pour votre réponse.

Je suis un utilisateur de SongRec, voici mon contexte d'utilisation:

J'écoute régulièrement des web radio comme hot mix ou radio meuh. Ces radios ne donnent pas d'informations en direct quant aux titres diffusés. Donc SongRec me permet de les identifier et quand j'entends un titre qui me plaît, je l'ajoute aux favoris.

Suite au commentaire ChocolatineFlying, voici le texte original du mémo:

[…]

Il me semble que le lien

cité sur LWN: https://lwn.net/Articles/370454/

ne pointe pas vers le bon article (je n'y ai pas trouvé de mention de offpunk).
Ne serait-ce pas plutôt cet article: https://lwn.net/Articles/1057766/ ?

Je découvre la plateforme crowdsupply avec ce projet. Alors soit je suis passé à côté de quelques choses, soit aucunes sources ne sont mises à dispositions ?

Il y a bien une section concernant l'"open source":

Open Source

Open Printer will use the Creative Commons BY-NC-SA 4.0 license for all of its files, including electronics and mechanical design files, firmware code, and the bill of materials. We hope that people will be able to repair, upgrade, and contribute improvements to their printers.

Après, l'usage du futur laisse présagé que les fichiers de conception seront mis à disposition ultérieurement.

Pour plus d'informations,

CoMaps est un fork d'Organic Map. L'origine de cette scission est expliqué dans ce post.

Le bon lien est https://www.economie.gouv.fr/actualites/osez-lia-un-plan-pour-diffuser-lia-dans-toutes-les-entreprises

Pour faire une description concise et imprécise du système mais qui permet de comprendre ce qui le différencie d'une solution clés USB:

• Le boîtier n'est qu'un "lecteur", il s'utilise avec une carte à puce et c'est sur cette carte que les données sont stockées.
• Les données sont exportables pour soit les copier sur une autre carte, soit les stockés en tant qu'archive (cette opération ce fait via le logiciel moolticute).
• En cas de trois échecs successif de saisi de code pin, les données stockées sur la carte à puce soit supprimées.

Dans les faits, le boîtier peut-être détruit, tant qu'on possède la carte à puce ou l'archive alors on peut récupérer ses données.

Pour ma part, une plus-value importante par rapport à une solution "clé USB" c'est l'intégration avec le navigateur et le remplissage automatique des champs de connexion.

Pour ma part, cela fait 6 ans que j'utilise un boîtier Mooltipass (open-hardware et opensource).

L'avantage de ce boîtier est qu'il est reconnu comme un clavier et est donc utilisable sur n'importe quel périphérique.
Si en plus, on installe l'extension pour navigateur et le logiciel "compagnon" moolticute, alors l'ensemble permet de:

• détecter la création d'un compte et proposer la sauvegarde de l'identifiant et du mot de passe associé à cette URL
• détecter les champs de connexion sur une page web et proposer la connexion si l'URL de la page correspond à une URL déjà enregistrée.

Dans l'ensemble c'est pratique, il faut simplement penser à prendre son boîtier lors des déplacements …

Pour le boitier qui lit les QR-Codes et qui génère une suite de chiffres (dans mon cas un boitier Digipass), il n'indique le destinataire de la transaction ni le montant.

En revanche, la page web où est affiché le QR-Code récapitule ces informations, mais comme pourrais le faire une page qui attend un code TOTP à la place d'attendre le code généré à partir d'un QR-Code.

Des projets un peu plus confidentiels mais non moins intéressants, le laboratoire LAAS du CNRS publie en open-source leurs logiciels de pilotage de robot.

Notamment Genom3 une alternative à ROS (si j'ai bien compris).

LAAS plateforme logicielles
Genom3

J'ai dernièrement eu besoin de me pencher sur l'édition de liens et les linker script. Je me suis fait une note sur les choses qui me semble importantes (pour mon utilisation). Je vous le partage au cas où cela puisse servir à d'autre.