2016-12-06 5 views
-1

Dites que je suis en train de développer un firmware pour un thermostat intelligent chez quelqu'un. L'implémentation actuelle est une solution multithread fonctionnant sur un processeur single core (abandonnons simplement Cortex-M car c'est ce que je connais) et j'utilise un RTOS standard.Développement de microprogrammes sur processeur monocœur vs multicœur

Si je prends ce projet et que je le déplace/le transfère vers un processeur dual/multi-core, comment cela fonctionne-t-il? Est-ce que je dis juste au RTOS quels threads devraient fonctionner sur chaque noyau et le RTOS gère tout à partir de là? Y a-t-il une certaine quantité de refactoring qui doit être faite sur chaque thread afin qu'il fonctionne plus efficacement dans un environnement multi-core? Ou le RTOS ne prend-il que le thread qui est dans l'état READY et exécute cette tâche sur un noyau avec du temps libre disponible?

+1

Sans réplique, je dirais. Certes, cela dépend entièrement du support et des capacités du planificateur ("RTOS") que vous utilisez. Avez-vous regardé dans la documentation pour les "RTOS" que vous envisageriez? – JimmyB

+1

En outre, une application «thermostat intelligent» ne semble pas justifier l'utilisation d'un multi-core en premier lieu. – JimmyB

+0

@JimmyB Compte tenu du prix et de la disponibilité des systèmes sur puce multi-core, je ne pense pas qu'il y ait beaucoup de "justification" nécessaire. Vous pouvez en obtenir un pour 10 $ en quantité, DRAM inclus. Pensez au thermostat qui fonctionne sur une plate-forme comme Raspberry Pi. –

Répondre

0

En règle générale, le fait que vous exécutez sur une machine multi-core ne devrait pas importer. Il appartient à l'OS de programmer les threads aux cœurs disponibles. Bien sûr, votre RTOS doit prendre en charge la plate-forme multi-core! Il ya un problème: si votre code ne gère pas la concurrence correctement, et en particulier s'il ne gère pas les barrières de mémoire correctement, vous pourriez rencontrer des bogues qui étaient cachés par le fait que tout courait en série sur un seul noyau. Une fois que vous avez lancé un deuxième noyau dans le mixage, tous les bugs ont tendance à apparaître, mais ils le font d'habitude pendant une démo importante ou après la sortie. Donc, concevez votre code de manière à ce qu'il soit concomitant - sans bug par construction.