Cela dépend, et cela est généralement vrai pour tous les outils, pas seulement C30.
Les optimisations suppriment et / ou restructurent souvent le code de diverses manières. Votre instruction switch peut être réimplémentée avec une construction if / else ou dans certains cas peut être supprimée tous ensemble. y = x * 16 peut être remplacé par une série de décalages à gauche, etc. bien que ce dernier type d'optimisation puisse généralement encore être franchi, c'est principalement la restructuration de la déclaration de contrôle qui y parvient.
Cela peut rendre impossible le passage d'un débogueur dans votre code C car les structures que vous avez définies en C n'existent plus, elles ont été remplacées ou réorganisées par le compilateur en quelque chose que le compilateur pense être plus rapide ou utiliser moins d'espace. Cela peut également rendre les points d'arrêt impossibles à définir à partir de la liste C, car l'instruction sur laquelle vous appuyez peut ne plus exister. Par exemple, vous pouvez essayer de définir un point d'arrêt dans une instruction if, mais le compilateur peut l'avoir supprimé if. Vous pouvez essayer de définir un point d'arrêt à l'intérieur d'une boucle while ou for mais le compilateur a décidé de dérouler cette boucle afin qu'elle n'existe plus.
Pour cette raison, si vous pouvez déboguer avec des optimisations désactivées, c'est généralement plus facile. Vous devez toujours retester avec les optimisations activées. C'est à peu près la seule façon de découvrir que vous avez raté un important volatile
et que cela provoque des échecs intermittents (ou une autre bizarrerie).
Dans le cas du développement intégré, vous devez quand même faire attention aux optimisations. Plus précisément dans les sections de code dont le timing est critique, certaines interruptions par exemple. Dans ces cas, vous devez soit coder les bits critiques de l'assembly, soit utiliser des directives de compilation pour vous assurer que ces sections ne sont pas optimisées afin que vous sachiez qu'elles ont un temps d'exécution fixe ou un temps d'exécution du pire cas fixe.
L'autre gotcha peut être l'adaptation de code dans l'UC, vous pouvez avoir besoin d'optimisations de densité de code pour adapter simplement votre code dans la puce. C'est une des raisons pour lesquelles c'est généralement une bonne idée de commencer avec la plus grande capacité de ROM uC d'une famille et de n'en choisir qu'une plus petite pour la fabrication, une fois votre code verrouillé.