Je pense que vous devez peser vos options de coût ici.
ARM + linux est une option, mais vous allez payer un très haut frais généraux d'exploitation pour un simple (à partir de votre description) ensemble de fonctionnalités. Vous ne pouvez pas seulement regarder le coût de la puce ARM, mais vous devez également considérer la RAM externe qui sera très probablement nécessaire ainsi que le flash pour avoir suffisamment d'espace disponible pour exécuter les applications du noyau +.
REMARQUE: vous pouvez être en mesure d'éviter les exigences externes avec un noyau très minime et des applications simples combinées avec un uC avec de grandes ressources internes.
Une deuxième option est un microcontrôleur beaucoup plus simple avec un OS léger. Cela réduira vos coûts de matériel sur le CPU et vous pouvez probablement exécuter quelque chose comme ça sans RAM ou flash externe (en fonction de la RAM de l'application et de l'espace requis)
troisième option: je ne vois rien dans vos exigences exige tout OS à tous être utilisé. Les systèmes de fichiers de base sont très simples, par exemple il existe même des pilotes FAT pour les PICs 8 bits. L'interfaçage avec une carte SD nécessite uniquement un port SPI et un circuit externe minimal.
Le bit d'application peut être simple ou complexe. J'ai construit des systèmes autour des microcontollers PIC18 qui exécutent un serveur web et permettent des mises à jour de programme via un simple écran de téléchargement, il stocke simplement le nouveau programme dans une mémoire EEPROM ou flash, redémarre dans un bootloader et copie le nouveau programme dans la mémoire interne du programme. Vous pourriez probablement concevoir un moyen de le faire sans le redémarrage via une architecture coopérative multitâche. De toute façon, les programmeurs qui écrivent les applications auront besoin de connaître l'architecture et l'accès aux bibliothèques/pilotes que vous écrivez. Votre meilleur pari pour simplifier ceci est de fournir une API aussi simple que possible et d'essayer d'automatiser le processus de construction pour eux.
La troisième option sera "la moins chère" en termes de matériel car il y aura très peu de frais généraux dans le traitement de vos applications vous permettant de vous en sortir avec une puissance de traitement et une mémoire minimales. Il faudra probablement plus de programmation/architecture de logiciel de votre part, mais n'exigera pas presque la recherche que vous aurez besoin d'entreprendre pour faire fonctionner Linux en plus d'apprendre à écrire les pilotes de périphériques nécessaires sous un paradigme Linux.
Comme toujours, vous devez inclure les coûts de développement logiciel dans le coût de construction de l'appareil. Si vous envisagez d'en construire plus de 10 000, mieux vaut probablement réduire les coûts de matériel et mettre plus de puissance dans la conception d'une solution logicielle permettant à ce matériel d'atteindre les objectifs de conception. Si vous construisez 10 d'entre eux, mieux vaut dépenser 15-20 $ de plus pour le matériel si cela peut réduire les coûts de développement de votre logiciel. Par exemple, un ARM avec MMU avec prise en charge complète du noyau Linux et pilotes de périphériques disponibles.
J'ai l'impression que vous choisissez le pire des deux mondes en ce moment, votre paiement supplémentaire pour obtenir un UC, vous pouvez exécuter Linux mais en faisant ainsi votre sélection également une partie qui sera probablement le plus complexe à obtenir Linux en cours d'exécution, en particulier n'ayant pas travaillé avec linux sur des plateformes embarquées auparavant.
Pouvez-vous fournir quelques informations sur l'application? Si vous vous contentez de parler à quelques périphériques série et de transmettre des informations autour de ARM + linux, vous risquez de perdre en complexité et en coût, surtout si vous n'êtes pas familier avec les chaînes d'outils et la configuration du système d'exploitation. – Mark